RFC Abstracts
RFC4117 - Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc)
This document describes how to invoke transcoding services using Session Initiation Protocol (SIP) and third party call control. This way of invocation meets the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing and speech-impaired individuals. This memo provides information for the Internet community.
RFC4116 - IPv4 Multihoming Practices and Limitations
Multihoming is an essential component of service for many Internet sites. This document describes some implementation strategies for multihoming with IPv4 and enumerates features for comparison with other multihoming proposals (particularly those related to IPv6). This memo provides information for the Internet community.
RFC4115 - A Differentiated Service Two-Rate, Three-Color Marker with Efficient Handling of in-Profile Traffic
This document describes a two-rate, three-color marker that has been in use for data services including Frame Relay services. This marker can be used for metering per-flow traffic in the emerging IP and L2 VPN services. The marker defined here is different from previously defined markers in the handling of the in-profile traffic. Furthermore, this marker doesn't impose peak-rate shaping requirements on customer edge (CE) devices. This memo provides information for the Internet community.
RFC4114 - E.164 Number Mapping for the Extensible Provisioning Protocol (EPP)
This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of E.164 numbers that represent domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of E.164 numbers. [STANDARDS-TRACK]
RFC4113 - Management Information Base for the User Datagram Protocol (UDP)
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the User Datagram Protocol (UDP) in an IP version independent manner. This memo obsoletes RFCs 2013 and 2454. [STANDARDS-TRACK]
RFC4112 - Electronic Commerce Modeling Language (ECML) Version 2 Specification
Electronic commerce frequently requires a substantial exchange of information in order to complete a purchase or other transaction, especially the first time the parties communicate. A standard set of hierarchically-organized payment-related information field names in an XML syntax is defined so that this task can be more easily automated. This is the second version of an Electronic Commerce Modeling Language (ECML) and is intended to meet the requirements of RFC 3505. [STANDARDS-TRACK]
RFC4111 - Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)
This document addresses security aspects pertaining to Provider-Provisioned Virtual Private Networks (PPVPNs). First, it describes the security threats in the context of PPVPNs and defensive techniques to combat those threats. It considers security issues deriving both from malicious behavior of anyone and from negligent or incorrect behavior of the providers. It also describes how these security attacks should be detected and reported. It then discusses possible user requirements for security of a PPVPN service. These user requirements translate into corresponding provider requirements. In addition, the provider may have additional requirements to make its network infrastructure secure to a level that can meet the PPVPN customer's expectations. Finally, this document defines a template that may be used to describe and analyze the security characteristics of a specific PPVPN technology. This memo provides information for the Internet community.
RFC4110 - A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)
This document provides a framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs). This framework is intended to aid in the standardization of protocols and mechanisms for support of layer 3 PPVPNs. It is the intent of this document to produce a coherent description of the significant technical issues that are important in the design of layer 3 PPVPN solutions. Selection of specific approaches, making choices regarding engineering tradeoffs, and detailed protocol specification, are outside of the scope of this framework document. This memo provides information for the Internet community.
RFC4109 - Algorithms for Internet Key Exchange version 1 (IKEv1)
The required and suggested algorithms in the original Internet Key Exchange version 1 (IKEv1) specification do not reflect the current reality of the IPsec market requirements. The original specification allows weak security and suggests algorithms that are thinly implemented. This document updates RFC 2409, the original specification, and is intended for all IKEv1 implementations deployed today. [STANDARDS-TRACK]
RFC4108 - Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages
This document describes the use of the Cryptographic Message Syntax (CMS) to protect firmware packages, which provide object code for one or more hardware module components. CMS is specified in RFC 3852. A digital signature is used to protect the firmware package from undetected modification and to provide data origin authentication. Encryption is optionally used to protect the firmware package from disclosure, and compression is optionally used to reduce the size of the protected firmware package. A firmware package loading receipt can optionally be generated to acknowledge the successful loading of a firmware package. Similarly, a firmware package load error report can optionally be generated to convey the failure to load a firmware package. [STANDARDS-TRACK]
RFC4107 - Guidelines for Cryptographic Key Management
The question often arises of whether a given security system requires some form of automated key management, or whether manual keying is sufficient. This memo provides guidelines for making such decisions. When symmetric cryptographic mechanisms are used in a protocol, the presumption is that automated key management is generally but not always needed. If manual keying is proposed, the burden of proving that automated key management is not required falls to the proposer. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC4106 - The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)
This memo describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality and data origin authentication. This method can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations. [STANDARDS-TRACK]
RFC4105 - Requirements for Inter-Area MPLS Traffic Engineering
This document lists a detailed set of functional requirements for the support of inter-area MPLS Traffic Engineering (inter-area MPLS TE). It is intended that solutions that specify procedures and protocol extensions for inter-area MPLS TE satisfy these requirements. This memo provides information for the Internet community.
RFC4104 - Policy Core Extension Lightweight Directory Access Protocol Schema (PCELS)
This document defines a number of changes and extensions to the Policy Core Lightweight Directory Access Protocol (LDAP) Schema (RFC 3703) based on the model extensions defined by the Policy Core Information Model (PCIM) Extensions (RFC 3460). These changes and extensions consist of new LDAP object classes and attribute types. Some of the schema items defined in this document re-implement existing concepts in accordance with their new semantics introduced by RFC 3460. The other schema items implement new concepts, not covered by RFC 3703. This document updates RFC 3703. [STANDARDS-TRACK]
RFC4103 - RTP Payload for Text Conversation
This memo obsoletes RFC 2793; it describes how to carry real-time text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140.
RFC4102 - Registration of the text/red MIME Sub-Type
This document defines the text/red MIME sub-type. "Red" is short for redundant. The actual RTP packetization for this MIME type is specified in RFC 2198. [STANDARDS-TRACK]
RFC4101 - Writing Protocol Models
The IETF process depends on peer review. However, IETF documents are generally written to be useful for implementors, not reviewers. In particular, while great care is generally taken to provide a complete description of the state machines and bits on the wire, this level of detail tends to get in the way of initial understanding. This document describes an approach for providing protocol "models" that allow reviewers to quickly grasp the essence of a system. This memo provides information for the Internet community.
RFC4098 - Terminology for Benchmarking BGP Device Convergence in the Control Plane
This document establishes terminology to standardize the description of benchmarking methodology for measuring eBGP convergence in the control plane of a single BGP device. Future documents will address iBGP convergence, the initiation of forwarding based on converged control plane information and multiple interacting BGP devices.This terminology is applicable to both IPv4 and IPv6. Illustrative examples of each version are included where relevant. This memo provides information for the Internet community.
RFC4097 - Middlebox Communications (MIDCOM) Protocol Evaluation
This document provides an evaluation of the applicability of SNMP (Simple Network Management Protocol), RSIP (Realm Specific Internet Protocol), Megaco, Diameter, and COPS (Common Open Policy Service) as the MIDCOM (Middlebox Communications) protocol. A summary of each of the proposed protocols against the MIDCOM requirements and the MIDCOM framework is provided. Compliancy of each of the protocols against each requirement is detailed. A conclusion summarizes how each of the protocols fares in the evaluation. This memo provides information for the Internet community.
RFC4096 - Policy-Mandated Labels Such as "Adv:" in Email Subject Headers Considered Ineffective At Best
This memo discusses policies that require certain labels to be inserted in the "Subject:" header of a mail message. Such policies are difficult to specify accurately while remaining compliant with key RFCs and are likely to be ineffective at best. This memo discusses an alternate, \%standards-compliant approach that is significantly simpler to specify and is somewhat less likely to be ineffective. This memo provides information for the Internet community.
RFC4095 - Attaching Meaning to Solicitation Class Keywords
This document proposes a mechanism for finding a URI associated with a solicitation class keyword, which is defined in RFC 3865, the No Soliciting SMTP Service Extension. Solicitation class keywords are simple labels consisting of a domain name that has been reversed, such as "org.example.adv". These solicitation class keywords are inserted in selected header fields or used in the ESMTP service extension, including a new \%"No-Solicit:" header, which can contain one or more solicitation class keywords inserted by the sender.
RFC4094 - Analysis of Existing Quality-of-Service Signaling Protocols
This document reviews some of the existing Quality of Service (QoS) signaling protocols for an IP network. The goal here is to learn from them and to avoid common misconceptions. Further, we need to avoid mistakes during the design and implementation of any new protocol in this area. This memo provides information for the Internet community.
RFC4093 - Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways
Deploying Mobile-IP v4 in networks that are connected to the Internet through a Virtual Private Network (VPN) gateway presents some problems that do not currently have well-described solutions. This document aims to describe and illustrate these problems, and to propose some guidelines for possible solutions. This memo provides information for the Internet community.
RFC4092 - Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP)
This document describes how to use the Alternative Network Address Types (ANAT) semantics of the Session Description Protocol (SDP) grouping framework in SIP. In particular, we define the sdp-anat SIP option-tag. This SIP option-tag ensures that SDP session descriptions that use ANAT are only handled by SIP entities with ANAT support. To justify the need for such a SIP option-tag, we describe what could possibly happen if an ANAT-unaware SIP entity tried to handle media lines grouped with ANAT. [STANDARDS-TRACK]
RFC4091 - The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework
This document defines the Alternative Network Address Types (ANAT) semantics for the Session Description Protocol (SDP) grouping framework. The ANAT semantics allow alternative types of network addresses to establish a particular media stream. [STANDARDS-TRACK]
RFC4090 - Fast Reroute Extensions to RSVP-TE for LSP Tunnels
This document defines RSVP-TE extensions to establish backup label-switched path (LSP) tunnels for local repair of LSP tunnels. These mechanisms enable the re-direction of traffic onto backup LSP tunnels in 10s of milliseconds, in the event of a failure.
RFC4089 - IAB and IESG Recommendation for IETF Administrative Restructuring
This document describes a joint recommendation of the Internet Architecture Board and the Internet Engineering Steering Group for administrative restructuring of the Internet Engineering Task Force. The IETF Chair declared that the IETF had consensus to follow this recommendation on November 11, 2004. Further work has been done to revise and refine the structures proposed. The recommendation is being published for the record. This memo provides information for the Internet community.
RFC4088 - Uniform Resource Identifier (URI) Scheme for the Simple Network Management Protocol (SNMP)
The Simple Network Management Protocol (SNMP) and the Internet Standard Management Framework are widely used for the management of communication devices, creating a need to specify SNMP access (including access to SNMP MIB object instances) from non-SNMP management environments. For example, when out-of-band IP management is used via a separate management interface (e.g., for a device that does not support in-band IP access), a uniform way to indicate how to contact the device for management is needed. Uniform Resource Identifiers (URIs) fit this need well, as they allow a single text string to indicate a management access communication endpoint for a wide variety of IP-based protocols.
RFC4087 - IP Tunnel MIB
This memo defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing tunnels of any type over IPv4 and IPv6 networks. Extension MIB modules may be designed for managing protocol-specific objects. Likewise, extension MIB modules may be designed for managing security-specific objects. This MIB module does not support tunnels over non-IP networks. Management of such tunnels may be supported by other MIB modules. This memo obsoletes RFC 2667. [STANDARDS-TRACK]
RFC4086 - Randomness Requirements for Security
Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.
RFC4085 - Embedding Globally-Routable Internet Addresses Considered Harmful
This document discourages the practice of embedding references to unique, globally-routable IP addresses in Internet hosts, describes some of the resulting problems, and considers selected alternatives. This document is intended to clarify best current practices in this regard. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC4084 - Terminology for Describing Internet Connectivity
As the Internet has evolved, many types of arrangements have been advertised and sold as "Internet connectivity". Because these may differ significantly in the capabilities they offer, the range of options, and the lack of any standard terminology, the effort to distinguish between these services has caused considerable consumer confusion. This document provides a list of terms and definitions that may be helpful to providers, consumers, and, potentially, regulators in clarifying the type and character of services being offered. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC4083 - Input 3rd-Generation Partnership Project (3GPP) Release 5 Requirements on the Session Initiation Protocol (SIP)
The 3rd-Generation Partnership Project (3GPP) has selected Session Initiation Protocol (SIP) as the session establishment protocol for the 3GPP IP Multimedia Core Network Subsystem (IMS). IMS is part of Release 5 of the 3GPP specifications. Although SIP is a protocol that fulfills most of the requirements for establishing a session in an IP network, SIP has never been evaluated against the specific 3GPP requirements for operation in a cellular network. In this document, we express the requirements identified by 3GPP to support SIP for Release 5 of the 3GPP IMS in cellular networks. This memo provides information for the Internet community.
RFC4082 - Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction
This document introduces Timed Efficient Stream Loss-tolerant Authentication (TESLA). TESLA allows all receivers to check the integrity and authenticate the source of each packet in multicast or broadcast data streams. TESLA requires no trust between receivers, uses low-cost operations per packet at both sender and receiver, can tolerate any level of loss without retransmissions, and requires no per-receiver state at the sender. TESLA can protect receivers against denial of service attacks in certain circumstances. Each receiver must be loosely time-synchronized with the source in order to verify messages, but otherwise receivers do not have to send any messages. TESLA alone cannot support non-repudiation of the data source to third parties.
RFC4081 - Security Threats for Next Steps in Signaling (NSIS)
This threats document provides a detailed analysis of the security threats relevant to the Next Steps in Signaling (NSIS) protocol suite. It calls attention to, and helps with the understanding of, various security considerations in the NSIS Requirements, Framework, and Protocol proposals. This document does not describe vulnerabilities of specific parts of the NSIS protocol suite. This memo provides information for the Internet community.
RFC4080 - Next Steps in Signaling (NSIS): Framework
The Next Steps in Signaling (NSIS) working group is considering protocols for signaling information about a data flow along its path in the network. The NSIS suite of protocols is envisioned to support various signaling applications that need to install and/or manipulate such state in the network. Based on existing work on signaling requirements, this document proposes an architectural framework for these signaling protocols.
RFC4079 - A Presence Architecture for the Distribution of GEOPRIV Location Objects
GEOPRIV defines the concept of a 'using protocol' -- a protocol that carries GEOPRIV location objects. GEOPRIV also defines various scenarios for the distribution of location objects that require the concepts of subscriptions and asynchronous notifications. This document examines some existing IETF work on the concept of presence, shows how presence architectures map onto GEOPRIV architectures, and moreover demonstrates that tools already developed for presence could be reused to simplify the standardization and implementation of GEOPRIV. This memo provides information for the Internet community.
RFC4078 - The TV-Anytime Content Reference Identifier (CRID)
The Uniform Resource Locator (URL) scheme "CRID:" has been devised to allow references to current or future scheduled publications of broadcast media content over television distribution platforms and the Internet.
RFC4077 - A Negative Acknowledgement Mechanism for Signaling Compression
This document describes a mechanism that allows Signaling Compression (SigComp) implementations to report precise error information upon receipt of a message which cannot be decompressed. This negative feedback can be used by the recipient to make fine-grained adjustments to the compressed message before retransmitting it, allowing for rapid and efficient recovery from error situations. [STANDARDS-TRACK]
RFC4076 - Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
IPv6 hosts using Stateless Address Autoconfiguration are able to configure their IPv6 address and default router settings automatically. However, further settings are not available. If these hosts wish to configure their DNS, NTP, or other specific settings automatically, the stateless variant of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) could be used. This combination of Stateless Address Autoconfiguration and stateless DHCPv6 could be used quite commonly in IPv6 networks. However, hosts using this combination currently have no means by which to be informed of changes in stateless DHCPv6 option settings; e.g., the addition of a new NTP server address, a change in DNS search paths, or full site renumbering. This document is presented as a problem statement from which a solution should be proposed in a subsequent document. This memo provides information for the Internet community.
RFC4075 - Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6
This document describes a new DHCPv6 option for passing a list of Simple Network Time Protocol (SNTP) server addresses to a client. [STANDARDS-TRACK]
RFC4074 - Common Misbehavior Against DNS Queries for IPv6 Addresses
There is some known misbehavior of DNS authoritative servers when they are queried for AAAA resource records. Such behavior can block IPv4 communication that should actually be available, cause a significant delay in name resolution, or even make a denial of service attack. This memo describes details of known cases and discusses their effects. This memo provides information for the Internet community.
RFC4073 - Protecting Multiple Contents with the Cryptographic Message Syntax (CMS)
This document describes a convention for using the Cryptographic Message Syntax (CMS) to protect a content collection. If desired, attributes can be associated with the content. [STANDARDS-TRACK]
RFC4072 - Diameter Extensible Authentication Protocol (EAP) Application
The Extensible Authentication Protocol (EAP) provides a standard mechanism for support of various authentication methods. This document defines the Command-Codes and AVPs necessary to carry EAP packets between a Network Access Server (NAS) and a back-end authentication server. [STANDARDS-TRACK]
RFC4071 - Structure of the IETF Administrative Support Activity (IASA)
This document describes the structure of the IETF Administrative Support Activity (IASA) as an activity housed within the Internet Society (ISOC). It defines the roles and responsibilities of the IETF Administrative Oversight Committee (IAOC), the IETF Administrative Director (IAD), and ISOC in the fiscal and administrative support of the IETF standards process. It also defines the membership and selection rules for the IAOC. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC4070 - Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Multiple Carrier Modulation (MCM) Line Coding
This document defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing the Line Code Specific parameters of Very High Speed Digital Subscriber Line (VDSL) interfaces using Multiple Carrier Modulation (MCM) Line Coding. It is an optional extension to the VDSL-LINE-MIB, RFC 3728, which handles line code independent objects. [STANDARDS-TRACK]
RFC4069 - Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Single Carrier Modulation (SCM) Line Coding
This document defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing the Line Code Specific parameters of Very High Speed Digital Subscriber Line (VDSL) interfaces using Single Carrier Modulation (SCM) Line Coding. It is an optional extension to the VDSL-LINE-MIB, RFC 3728, which handles line code independent objects. [STANDARDS-TRACK]
RFC4068 - Fast Handovers for Mobile IPv6
Mobile IPv6 enables a Mobile Node to maintain its connectivity to the Internet when moving from one Access Router to another, a process referred to as handover. During handover, there is a period during which the Mobile Node is unable to send or receive packets because of link switching delay and IP protocol operations. This "handover latency" resulting from standard Mobile IPv6 procedures, namely movement detection, new Care of Address configuration, and Binding Update, is often unacceptable to real-time traffic such as Voice over IP. Reducing the handover latency could be beneficial to non-real-time, throughput-sensitive applications as well. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. This document does not address improving the link switching latency. This memo defines an Experimental Protocol for the Internet community.
RFC4067 - Context Transfer Protocol (CXTP)
This document presents the Context Transfer Protocol (CXTP) that enables authorized context transfers. Context transfers allow better support for node based mobility so that the applications running on mobile nodes can operate with minimal disruption. Key objectives are to reduce latency and packet losses, and to avoid the re-initiation of signaling to and from the mobile node. This memo defines an Experimental Protocol for the Internet community.
RFC4066 - Candidate Access Router Discovery (CARD)
To enable seamless IP-layer handover of a mobile node (MN) from one access router (AR) to another, the MN is required to discover the identities and capabilities of candidate ARs (CARs) for handover prior to the initiation of the handover. The act of discovery of CARs has two aspects: identifying the IP addresses of the CARs and finding their capabilities. This process is called "candidate access router discovery" (CARD). At the time of IP-layer handover, the CAR, whose capabilities are a good match to the preferences of the MN, is chosen as the target AR for handover. The protocol described in this document allows a mobile node to perform CARD. This memo defines an Experimental Protocol for the Internet community.
This document describes how to invoke transcoding services using Session Initiation Protocol (SIP) and third party call control. This way of invocation meets the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing and speech-impaired individuals. This memo provides information for the Internet community.
RFC4116 - IPv4 Multihoming Practices and Limitations
Multihoming is an essential component of service for many Internet sites. This document describes some implementation strategies for multihoming with IPv4 and enumerates features for comparison with other multihoming proposals (particularly those related to IPv6). This memo provides information for the Internet community.
RFC4115 - A Differentiated Service Two-Rate, Three-Color Marker with Efficient Handling of in-Profile Traffic
This document describes a two-rate, three-color marker that has been in use for data services including Frame Relay services. This marker can be used for metering per-flow traffic in the emerging IP and L2 VPN services. The marker defined here is different from previously defined markers in the handling of the in-profile traffic. Furthermore, this marker doesn't impose peak-rate shaping requirements on customer edge (CE) devices. This memo provides information for the Internet community.
RFC4114 - E.164 Number Mapping for the Extensible Provisioning Protocol (EPP)
This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of E.164 numbers that represent domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of E.164 numbers. [STANDARDS-TRACK]
RFC4113 - Management Information Base for the User Datagram Protocol (UDP)
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the User Datagram Protocol (UDP) in an IP version independent manner. This memo obsoletes RFCs 2013 and 2454. [STANDARDS-TRACK]
RFC4112 - Electronic Commerce Modeling Language (ECML) Version 2 Specification
Electronic commerce frequently requires a substantial exchange of information in order to complete a purchase or other transaction, especially the first time the parties communicate. A standard set of hierarchically-organized payment-related information field names in an XML syntax is defined so that this task can be more easily automated. This is the second version of an Electronic Commerce Modeling Language (ECML) and is intended to meet the requirements of RFC 3505. [STANDARDS-TRACK]
RFC4111 - Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)
This document addresses security aspects pertaining to Provider-Provisioned Virtual Private Networks (PPVPNs). First, it describes the security threats in the context of PPVPNs and defensive techniques to combat those threats. It considers security issues deriving both from malicious behavior of anyone and from negligent or incorrect behavior of the providers. It also describes how these security attacks should be detected and reported. It then discusses possible user requirements for security of a PPVPN service. These user requirements translate into corresponding provider requirements. In addition, the provider may have additional requirements to make its network infrastructure secure to a level that can meet the PPVPN customer's expectations. Finally, this document defines a template that may be used to describe and analyze the security characteristics of a specific PPVPN technology. This memo provides information for the Internet community.
RFC4110 - A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)
This document provides a framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs). This framework is intended to aid in the standardization of protocols and mechanisms for support of layer 3 PPVPNs. It is the intent of this document to produce a coherent description of the significant technical issues that are important in the design of layer 3 PPVPN solutions. Selection of specific approaches, making choices regarding engineering tradeoffs, and detailed protocol specification, are outside of the scope of this framework document. This memo provides information for the Internet community.
RFC4109 - Algorithms for Internet Key Exchange version 1 (IKEv1)
The required and suggested algorithms in the original Internet Key Exchange version 1 (IKEv1) specification do not reflect the current reality of the IPsec market requirements. The original specification allows weak security and suggests algorithms that are thinly implemented. This document updates RFC 2409, the original specification, and is intended for all IKEv1 implementations deployed today. [STANDARDS-TRACK]
RFC4108 - Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages
This document describes the use of the Cryptographic Message Syntax (CMS) to protect firmware packages, which provide object code for one or more hardware module components. CMS is specified in RFC 3852. A digital signature is used to protect the firmware package from undetected modification and to provide data origin authentication. Encryption is optionally used to protect the firmware package from disclosure, and compression is optionally used to reduce the size of the protected firmware package. A firmware package loading receipt can optionally be generated to acknowledge the successful loading of a firmware package. Similarly, a firmware package load error report can optionally be generated to convey the failure to load a firmware package. [STANDARDS-TRACK]
RFC4107 - Guidelines for Cryptographic Key Management
The question often arises of whether a given security system requires some form of automated key management, or whether manual keying is sufficient. This memo provides guidelines for making such decisions. When symmetric cryptographic mechanisms are used in a protocol, the presumption is that automated key management is generally but not always needed. If manual keying is proposed, the burden of proving that automated key management is not required falls to the proposer. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC4106 - The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)
This memo describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality and data origin authentication. This method can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations. [STANDARDS-TRACK]
RFC4105 - Requirements for Inter-Area MPLS Traffic Engineering
This document lists a detailed set of functional requirements for the support of inter-area MPLS Traffic Engineering (inter-area MPLS TE). It is intended that solutions that specify procedures and protocol extensions for inter-area MPLS TE satisfy these requirements. This memo provides information for the Internet community.
RFC4104 - Policy Core Extension Lightweight Directory Access Protocol Schema (PCELS)
This document defines a number of changes and extensions to the Policy Core Lightweight Directory Access Protocol (LDAP) Schema (RFC 3703) based on the model extensions defined by the Policy Core Information Model (PCIM) Extensions (RFC 3460). These changes and extensions consist of new LDAP object classes and attribute types. Some of the schema items defined in this document re-implement existing concepts in accordance with their new semantics introduced by RFC 3460. The other schema items implement new concepts, not covered by RFC 3703. This document updates RFC 3703. [STANDARDS-TRACK]
RFC4103 - RTP Payload for Text Conversation
This memo obsoletes RFC 2793; it describes how to carry real-time text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140.
RFC4102 - Registration of the text/red MIME Sub-Type
This document defines the text/red MIME sub-type. "Red" is short for redundant. The actual RTP packetization for this MIME type is specified in RFC 2198. [STANDARDS-TRACK]
RFC4101 - Writing Protocol Models
The IETF process depends on peer review. However, IETF documents are generally written to be useful for implementors, not reviewers. In particular, while great care is generally taken to provide a complete description of the state machines and bits on the wire, this level of detail tends to get in the way of initial understanding. This document describes an approach for providing protocol "models" that allow reviewers to quickly grasp the essence of a system. This memo provides information for the Internet community.
RFC4098 - Terminology for Benchmarking BGP Device Convergence in the Control Plane
This document establishes terminology to standardize the description of benchmarking methodology for measuring eBGP convergence in the control plane of a single BGP device. Future documents will address iBGP convergence, the initiation of forwarding based on converged control plane information and multiple interacting BGP devices.This terminology is applicable to both IPv4 and IPv6. Illustrative examples of each version are included where relevant. This memo provides information for the Internet community.
RFC4097 - Middlebox Communications (MIDCOM) Protocol Evaluation
This document provides an evaluation of the applicability of SNMP (Simple Network Management Protocol), RSIP (Realm Specific Internet Protocol), Megaco, Diameter, and COPS (Common Open Policy Service) as the MIDCOM (Middlebox Communications) protocol. A summary of each of the proposed protocols against the MIDCOM requirements and the MIDCOM framework is provided. Compliancy of each of the protocols against each requirement is detailed. A conclusion summarizes how each of the protocols fares in the evaluation. This memo provides information for the Internet community.
RFC4096 - Policy-Mandated Labels Such as "Adv:" in Email Subject Headers Considered Ineffective At Best
This memo discusses policies that require certain labels to be inserted in the "Subject:" header of a mail message. Such policies are difficult to specify accurately while remaining compliant with key RFCs and are likely to be ineffective at best. This memo discusses an alternate, \%standards-compliant approach that is significantly simpler to specify and is somewhat less likely to be ineffective. This memo provides information for the Internet community.
RFC4095 - Attaching Meaning to Solicitation Class Keywords
This document proposes a mechanism for finding a URI associated with a solicitation class keyword, which is defined in RFC 3865, the No Soliciting SMTP Service Extension. Solicitation class keywords are simple labels consisting of a domain name that has been reversed, such as "org.example.adv". These solicitation class keywords are inserted in selected header fields or used in the ESMTP service extension, including a new \%"No-Solicit:" header, which can contain one or more solicitation class keywords inserted by the sender.
RFC4094 - Analysis of Existing Quality-of-Service Signaling Protocols
This document reviews some of the existing Quality of Service (QoS) signaling protocols for an IP network. The goal here is to learn from them and to avoid common misconceptions. Further, we need to avoid mistakes during the design and implementation of any new protocol in this area. This memo provides information for the Internet community.
RFC4093 - Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways
Deploying Mobile-IP v4 in networks that are connected to the Internet through a Virtual Private Network (VPN) gateway presents some problems that do not currently have well-described solutions. This document aims to describe and illustrate these problems, and to propose some guidelines for possible solutions. This memo provides information for the Internet community.
RFC4092 - Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP)
This document describes how to use the Alternative Network Address Types (ANAT) semantics of the Session Description Protocol (SDP) grouping framework in SIP. In particular, we define the sdp-anat SIP option-tag. This SIP option-tag ensures that SDP session descriptions that use ANAT are only handled by SIP entities with ANAT support. To justify the need for such a SIP option-tag, we describe what could possibly happen if an ANAT-unaware SIP entity tried to handle media lines grouped with ANAT. [STANDARDS-TRACK]
RFC4091 - The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework
This document defines the Alternative Network Address Types (ANAT) semantics for the Session Description Protocol (SDP) grouping framework. The ANAT semantics allow alternative types of network addresses to establish a particular media stream. [STANDARDS-TRACK]
RFC4090 - Fast Reroute Extensions to RSVP-TE for LSP Tunnels
This document defines RSVP-TE extensions to establish backup label-switched path (LSP) tunnels for local repair of LSP tunnels. These mechanisms enable the re-direction of traffic onto backup LSP tunnels in 10s of milliseconds, in the event of a failure.
RFC4089 - IAB and IESG Recommendation for IETF Administrative Restructuring
This document describes a joint recommendation of the Internet Architecture Board and the Internet Engineering Steering Group for administrative restructuring of the Internet Engineering Task Force. The IETF Chair declared that the IETF had consensus to follow this recommendation on November 11, 2004. Further work has been done to revise and refine the structures proposed. The recommendation is being published for the record. This memo provides information for the Internet community.
RFC4088 - Uniform Resource Identifier (URI) Scheme for the Simple Network Management Protocol (SNMP)
The Simple Network Management Protocol (SNMP) and the Internet Standard Management Framework are widely used for the management of communication devices, creating a need to specify SNMP access (including access to SNMP MIB object instances) from non-SNMP management environments. For example, when out-of-band IP management is used via a separate management interface (e.g., for a device that does not support in-band IP access), a uniform way to indicate how to contact the device for management is needed. Uniform Resource Identifiers (URIs) fit this need well, as they allow a single text string to indicate a management access communication endpoint for a wide variety of IP-based protocols.
RFC4087 - IP Tunnel MIB
This memo defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing tunnels of any type over IPv4 and IPv6 networks. Extension MIB modules may be designed for managing protocol-specific objects. Likewise, extension MIB modules may be designed for managing security-specific objects. This MIB module does not support tunnels over non-IP networks. Management of such tunnels may be supported by other MIB modules. This memo obsoletes RFC 2667. [STANDARDS-TRACK]
RFC4086 - Randomness Requirements for Security
Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.
RFC4085 - Embedding Globally-Routable Internet Addresses Considered Harmful
This document discourages the practice of embedding references to unique, globally-routable IP addresses in Internet hosts, describes some of the resulting problems, and considers selected alternatives. This document is intended to clarify best current practices in this regard. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC4084 - Terminology for Describing Internet Connectivity
As the Internet has evolved, many types of arrangements have been advertised and sold as "Internet connectivity". Because these may differ significantly in the capabilities they offer, the range of options, and the lack of any standard terminology, the effort to distinguish between these services has caused considerable consumer confusion. This document provides a list of terms and definitions that may be helpful to providers, consumers, and, potentially, regulators in clarifying the type and character of services being offered. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC4083 - Input 3rd-Generation Partnership Project (3GPP) Release 5 Requirements on the Session Initiation Protocol (SIP)
The 3rd-Generation Partnership Project (3GPP) has selected Session Initiation Protocol (SIP) as the session establishment protocol for the 3GPP IP Multimedia Core Network Subsystem (IMS). IMS is part of Release 5 of the 3GPP specifications. Although SIP is a protocol that fulfills most of the requirements for establishing a session in an IP network, SIP has never been evaluated against the specific 3GPP requirements for operation in a cellular network. In this document, we express the requirements identified by 3GPP to support SIP for Release 5 of the 3GPP IMS in cellular networks. This memo provides information for the Internet community.
RFC4082 - Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction
This document introduces Timed Efficient Stream Loss-tolerant Authentication (TESLA). TESLA allows all receivers to check the integrity and authenticate the source of each packet in multicast or broadcast data streams. TESLA requires no trust between receivers, uses low-cost operations per packet at both sender and receiver, can tolerate any level of loss without retransmissions, and requires no per-receiver state at the sender. TESLA can protect receivers against denial of service attacks in certain circumstances. Each receiver must be loosely time-synchronized with the source in order to verify messages, but otherwise receivers do not have to send any messages. TESLA alone cannot support non-repudiation of the data source to third parties.
RFC4081 - Security Threats for Next Steps in Signaling (NSIS)
This threats document provides a detailed analysis of the security threats relevant to the Next Steps in Signaling (NSIS) protocol suite. It calls attention to, and helps with the understanding of, various security considerations in the NSIS Requirements, Framework, and Protocol proposals. This document does not describe vulnerabilities of specific parts of the NSIS protocol suite. This memo provides information for the Internet community.
RFC4080 - Next Steps in Signaling (NSIS): Framework
The Next Steps in Signaling (NSIS) working group is considering protocols for signaling information about a data flow along its path in the network. The NSIS suite of protocols is envisioned to support various signaling applications that need to install and/or manipulate such state in the network. Based on existing work on signaling requirements, this document proposes an architectural framework for these signaling protocols.
RFC4079 - A Presence Architecture for the Distribution of GEOPRIV Location Objects
GEOPRIV defines the concept of a 'using protocol' -- a protocol that carries GEOPRIV location objects. GEOPRIV also defines various scenarios for the distribution of location objects that require the concepts of subscriptions and asynchronous notifications. This document examines some existing IETF work on the concept of presence, shows how presence architectures map onto GEOPRIV architectures, and moreover demonstrates that tools already developed for presence could be reused to simplify the standardization and implementation of GEOPRIV. This memo provides information for the Internet community.
RFC4078 - The TV-Anytime Content Reference Identifier (CRID)
The Uniform Resource Locator (URL) scheme "CRID:" has been devised to allow references to current or future scheduled publications of broadcast media content over television distribution platforms and the Internet.
RFC4077 - A Negative Acknowledgement Mechanism for Signaling Compression
This document describes a mechanism that allows Signaling Compression (SigComp) implementations to report precise error information upon receipt of a message which cannot be decompressed. This negative feedback can be used by the recipient to make fine-grained adjustments to the compressed message before retransmitting it, allowing for rapid and efficient recovery from error situations. [STANDARDS-TRACK]
RFC4076 - Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
IPv6 hosts using Stateless Address Autoconfiguration are able to configure their IPv6 address and default router settings automatically. However, further settings are not available. If these hosts wish to configure their DNS, NTP, or other specific settings automatically, the stateless variant of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) could be used. This combination of Stateless Address Autoconfiguration and stateless DHCPv6 could be used quite commonly in IPv6 networks. However, hosts using this combination currently have no means by which to be informed of changes in stateless DHCPv6 option settings; e.g., the addition of a new NTP server address, a change in DNS search paths, or full site renumbering. This document is presented as a problem statement from which a solution should be proposed in a subsequent document. This memo provides information for the Internet community.
RFC4075 - Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6
This document describes a new DHCPv6 option for passing a list of Simple Network Time Protocol (SNTP) server addresses to a client. [STANDARDS-TRACK]
RFC4074 - Common Misbehavior Against DNS Queries for IPv6 Addresses
There is some known misbehavior of DNS authoritative servers when they are queried for AAAA resource records. Such behavior can block IPv4 communication that should actually be available, cause a significant delay in name resolution, or even make a denial of service attack. This memo describes details of known cases and discusses their effects. This memo provides information for the Internet community.
RFC4073 - Protecting Multiple Contents with the Cryptographic Message Syntax (CMS)
This document describes a convention for using the Cryptographic Message Syntax (CMS) to protect a content collection. If desired, attributes can be associated with the content. [STANDARDS-TRACK]
RFC4072 - Diameter Extensible Authentication Protocol (EAP) Application
The Extensible Authentication Protocol (EAP) provides a standard mechanism for support of various authentication methods. This document defines the Command-Codes and AVPs necessary to carry EAP packets between a Network Access Server (NAS) and a back-end authentication server. [STANDARDS-TRACK]
RFC4071 - Structure of the IETF Administrative Support Activity (IASA)
This document describes the structure of the IETF Administrative Support Activity (IASA) as an activity housed within the Internet Society (ISOC). It defines the roles and responsibilities of the IETF Administrative Oversight Committee (IAOC), the IETF Administrative Director (IAD), and ISOC in the fiscal and administrative support of the IETF standards process. It also defines the membership and selection rules for the IAOC. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC4070 - Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Multiple Carrier Modulation (MCM) Line Coding
This document defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing the Line Code Specific parameters of Very High Speed Digital Subscriber Line (VDSL) interfaces using Multiple Carrier Modulation (MCM) Line Coding. It is an optional extension to the VDSL-LINE-MIB, RFC 3728, which handles line code independent objects. [STANDARDS-TRACK]
RFC4069 - Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Single Carrier Modulation (SCM) Line Coding
This document defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing the Line Code Specific parameters of Very High Speed Digital Subscriber Line (VDSL) interfaces using Single Carrier Modulation (SCM) Line Coding. It is an optional extension to the VDSL-LINE-MIB, RFC 3728, which handles line code independent objects. [STANDARDS-TRACK]
RFC4068 - Fast Handovers for Mobile IPv6
Mobile IPv6 enables a Mobile Node to maintain its connectivity to the Internet when moving from one Access Router to another, a process referred to as handover. During handover, there is a period during which the Mobile Node is unable to send or receive packets because of link switching delay and IP protocol operations. This "handover latency" resulting from standard Mobile IPv6 procedures, namely movement detection, new Care of Address configuration, and Binding Update, is often unacceptable to real-time traffic such as Voice over IP. Reducing the handover latency could be beneficial to non-real-time, throughput-sensitive applications as well. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. This document does not address improving the link switching latency. This memo defines an Experimental Protocol for the Internet community.
RFC4067 - Context Transfer Protocol (CXTP)
This document presents the Context Transfer Protocol (CXTP) that enables authorized context transfers. Context transfers allow better support for node based mobility so that the applications running on mobile nodes can operate with minimal disruption. Key objectives are to reduce latency and packet losses, and to avoid the re-initiation of signaling to and from the mobile node. This memo defines an Experimental Protocol for the Internet community.
RFC4066 - Candidate Access Router Discovery (CARD)
To enable seamless IP-layer handover of a mobile node (MN) from one access router (AR) to another, the MN is required to discover the identities and capabilities of candidate ARs (CARs) for handover prior to the initiation of the handover. The act of discovery of CARs has two aspects: identifying the IP addresses of the CARs and finding their capabilities. This process is called "candidate access router discovery" (CARD). At the time of IP-layer handover, the CAR, whose capabilities are a good match to the preferences of the MN, is chosen as the target AR for handover. The protocol described in this document allows a mobile node to perform CARD. This memo defines an Experimental Protocol for the Internet community.