RFC Abstracts
RFC3963 - Network Mobility (NEMO) Basic Support Protocol
This document describes the Network Mobility (NEMO) Basic Support protocol that enables Mobile Networks to attach to different points in the Internet. The protocol is an extension of Mobile IPv6 and allows session continuity for every node in the Mobile Network as the network moves. It also allows every node in the Mobile Network to be reachable while moving around. The Mobile Router, which connects the network to the Internet, runs the NEMO Basic Support protocol with its Home Agent. The protocol is designed so that network mobility is transparent to the nodes inside the Mobile Network. [STANDARDS-TRACK]
RFC3962 - Advanced Encryption Standard (AES) Encryption for Kerberos 5
The United States National Institute of Standards and Technology (NIST) has chosen a new Advanced Encryption Standard (AES), which is significantly faster and (it is believed) more secure than the old Data Encryption Standard (DES) algorithm. This document is a specification for the addition of this algorithm to the Kerberos cryptosystem suite. [STANDARDS-TRACK]
RFC3961 - Encryption and Checksum Specifications for Kerberos 5
This document describes a framework for defining encryption and checksum mechanisms for use with the Kerberos protocol, defining an abstraction layer between the Kerberos protocol and related protocols, and the actual mechanisms themselves. The document also defines several mechanisms. Some are taken from RFC 1510, modified in form to fit this new framework and occasionally modified in content when the old specification was incorrect. New mechanisms are presented here as well. This document does NOT indicate which mechanisms may be considered "required to implement". [STANDARDS-TRACK]
RFC3960 - Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)
This document describes how to manage early media in the Session Initiation Protocol (SIP) using two models: the gateway model and the application server model. It also describes the inputs one needs to consider in defining local policies for ringing tone generation. This memo provides information for the Internet community.
RFC3959 - The Early Session Disposition Type for the Session Initiation Protocol (SIP)
This document defines a new disposition type (early-session) for the Content-Disposition header field in the Session Initiation Protocol (SIP). The treatment of "early-session" bodies is similar to the treatment of "session" bodies. That is, they follow the offer/answer model. Their only difference is that session descriptions whose disposition type is "early-session" are used to establish early media sessions within early dialogs, as opposed to regular sessions within regular dialogs. [STANDARDS-TRACK]
RFC3958 - Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)
This memo defines a generalized mechanism for application service naming that allows service location without relying on rigid domain naming conventions (so-called name hacks). The proposal defines a Dynamic Delegation Discovery System (DDDS) Application to map domain name, application service name, and application protocol dynamically to target server and port. [STANDARDS-TRACK]
RFC3957 - Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4
Authentication, Authorization, and Accounting (AAA) servers, such as RADIUS and DIAMETER, are in use within the Internet today to provide authentication and authorization services for dial-up computers. Mobile IP for IPv4 requires strong authentication between the mobile node and its home agent. When the mobile node shares an AAA Security Association with its home AAA server, however, it is possible to use that AAA Security Association to create derived Mobility Security Associations between the mobile node and its home agent, and again between the mobile node and the foreign agent currently offering connectivity to the mobile node. This document specifies extensions to Mobile IP registration messages that can be used to create Mobility Security Associations between the mobile node and its home agent, and/or between the mobile node and a foreign agent. [STANDARDS-TRACK]
RFC3956 - Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address
This memo defines an address allocation policy in which the address of the Rendezvous Point (RP) is encoded in an IPv6 multicast group address. For Protocol Independent Multicast - Sparse Mode (PIM-SM), this can be seen as a specification of a group-to-RP mapping mechanism. This allows an easy deployment of scalable inter-domain multicast and simplifies the intra-domain multicast configuration as well. This memo updates the addressing format presented in RFC 3306. [STANDARDS-TRACK]
RFC3955 - Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX)
This document contains an evaluation of the five candidate protocols for an IP Flow Information Export (IPFIX) protocol, based on the requirements document produced by the IPFIX Working Group. The protocols are characterized and grouped in broad categories, and evaluated against specific requirements. Finally, a recommendation is made to select the NetFlow v9 protocol as the basis for the IPFIX specification. This memo provides information for the Internet community.
RFC3954 - Cisco Systems NetFlow Services Export Version 9
This document specifies the data export format for version 9 of Cisco Systems' NetFlow services, for use by implementations on the network elements and/or matching collector programs. The version 9 export format uses templates to provide access to observations of IP packet flows in a flexible and extensible manner. A template defines a collection of fields, with corresponding descriptions of structure and semantics. This memo provides information for the Internet community.
RFC3953 - Telephone Number Mapping (ENUM) Service Registration for Presence Services
This document registers a Telephone Number Mapping (ENUM) service for presence. Specifically, this document focuses on provisioning pres URIs in ENUM. [STANDARDS-TRACK]
RFC3952 - Real-time Transport Protocol (RTP) Payload Format for internet Low Bit Rate Codec (iLBC) Speech
This document describes the Real-time Transport Protocol (RTP) payload format for the internet Low Bit Rate Codec (iLBC) Speech developed by Global IP Sound (GIPS). Also, within the document there are included necessary details for the use of iLBC with MIME and Session Description Protocol (SDP). This memo defines an Experimental Protocol for the Internet community.
RFC3951 - Internet Low Bit Rate Codec (iLBC)
This document specifies a speech codec suitable for robust voice communication over IP. The codec is developed by Global IP Sound (GIPS). It is designed for narrow band speech and results in a payload bit rate of 13.33 kbit/s for 30 ms frames and 15.20 kbit/s for 20 ms frames. The codec enables graceful speech quality degradation in the case of lost frames, which occurs in connection with lost or delayed IP packets. This memo defines an Experimental Protocol for the Internet community.
RFC3950 - Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type Registration
This document describes the registration of the MIME sub-type image/tiff-fx. The encodings are defined by File Format for Internet Fax and its extensions. [STANDARDS-TRACK]
RFC3949 - File Format for Internet Fax
This document is a revised version of RFC 2301. The revisions, summarized in the list attached as Annex B, are based on discussions and suggestions for improvements that have been made since RFC 2301 was issued in March 1998, and on the results of independent implementations and interoperability testing.
RFC3948 - UDP Encapsulation of IPsec ESP Packets
This protocol specification defines methods to encapsulate and decapsulate IP Encapsulating Security Payload (ESP) packets inside UDP packets for traversing Network Address Translators. ESP encapsulation, as defined in this document, can be used in both IPv4 and IPv6 scenarios. Whenever negotiated, encapsulation is used with Internet Key Exchange (IKE). [STANDARDS-TRACK]
RFC3947 - Negotiation of NAT-Traversal in the IKE
This document describes how to detect one or more network address translation devices (NATs) between IPsec hosts, and how to negotiate the use of UDP encapsulation of IPsec packets through NAT boxes in Internet Key Exchange (IKE). [STANDARDS-TRACK]
RFC3946 - Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control
This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling. It defines the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology specific information needed when using GMPLS signaling. [STANDARDS-TRACK]
RFC3945 - Generalized Multi-Protocol Label Switching (GMPLS) Architecture
Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques.
RFC3944 - H.350 Directory Services
The International Telecommunications Union Standardization Sector (ITU-T) has created the H.350 series of Recommendations that specify directory services architectures in support of multimedia conferencing protocols. The goal of the architecture is to 'directory enable' multimedia conferencing so that these services can leverage existing identity management and enterprise directories. A particular goal is to enable an enterprise or service provider to maintain a canonical source of users and their multimedia conferencing systems, so that multiple call servers from multiple vendors, supporting multiple protocols, can all access the same data store. Because SIP is an IETF standard, the contents of H.350 and H.350.4 are made available via this document to the IETF community. This document contains the entire normative text of ITU-T Recommendations H.350 and H.350.4 in sections 4 and 5, respectively. The remaining sections are included only in this document, not in the ITU-T version. This memo provides information for the Internet community.
RFC3943 - Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS)
The Transport Layer Security (TLS) protocol (RFC 2246) includes features to negotiate selection of a lossless data compression method as part of the TLS Handshake Protocol and then to apply the algorithm associated with the selected method as part of the TLS Record Protocol. TLS defines one standard compression method, which specifies that data exchanged via the record protocol will not be compressed. This document describes an additional compression method associated with the Lempel-Ziv-Stac (LZS) lossless data compression algorithm for use with TLS. This document also defines the application of the LZS algorithm to the TLS Record Protocol. This memo provides information for the Internet community.
RFC3942 - Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options
This document updates RFC 2132 to reclassify Dynamic Host Configuration Protocol version 4 (DHCPv4) option codes 128 to 223 (decimal) as publicly defined options to be managed by IANA in accordance with RFC 2939. This document directs IANA to make these option codes available for assignment as publicly defined DHCP options for future options. [STANDARDS-TRACK]
RFC3941 - Negative-Acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Building Blocks
This document discusses the creation of negative-acknowledgment (NACK)-oriented reliable multicast (NORM) protocols. The rationale for NORM goals and assumptions are presented. Technical challenges for NACK-oriented (and in some cases general) reliable multicast protocol operation are identified. These goals and challenges are resolved into a set of functional "building blocks" that address different aspects of NORM protocol operation. It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols. This memo defines an Experimental Protocol for the Internet community.
RFC3940 - Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol
This document describes the messages and procedures of the Negative-acknowledgment (NACK) Oriented Reliable Multicast (NORM) protocol. This protocol is designed to provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services. NORM uses a selective, negative acknowledgment mechanism for transport reliability and offers additional protocol mechanisms to allow for operation with minimal "a priori" coordination among senders and receivers. A congestion control scheme is specified to allow the NORM protocol to fairly share available network bandwidth with other transport protocols such as Transmission Control Protocol (TCP). It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity (possibly a unicast return path) between the senders and receivers. The protocol offers a number of features to allow different types of applications or possibly other higher level transport protocols to utilize its service in different ways. The protocol leverages the use of FEC-based repair and other IETF reliable multicast transport (RMT) building blocks in its design. This memo defines an Experimental Protocol for the Internet community.
RFC3939 - Calling Line Identification for Voice Mail Messages
This document describes a method for identifying the originating calling party in the headers of a stored voice mail message. Two new header fields are defined for this purpose: Caller_ID and Called_Name. Caller_id is used to store sufficient information for the recipient to callback, or reply to, the sender of the message. Caller-name provides the name of the person sending the message. [STANDARDS-TRACK]
RFC3938 - Video-Message Message-Context
The Message-Context header defined in RFC 3458 describes the context of a message (for example: fax-message or voice-message). This specification extends the Message-Context header with one additional context value: "video-message".
RFC3937 - A Uniform Resource Name (URN) Namespace for the International Press Telecommunications Council (IPTC)
This document describes a URN (Uniform Resource Name) namespace for identifying persistent resources published by the International Press Telecommunications Council (IPTC). These resources include XML Data Type Definition files (DTD), XML Schema, Namespaces in XML, XSL stylesheets, other XML based document and documents of other data formats like PDF documents, Microsoft Office documents and others. This memo provides information for the Internet community.
RFC3936 - Procedures for Modifying the Resource reSerVation Protocol (RSVP)
This memo specifies procedures for modifying the Resource reSerVation Protocol (RSVP). This memo also lays out new assignment guidelines for number spaces for RSVP messages, object classes, class-types, and sub-objects. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC3935 - A Mission Statement for the IETF
This memo gives a mission statement for the IETF, tries to define the terms used in the statement sufficiently to make the mission statement understandable and useful, argues why the IETF needs a mission statement, and tries to capture some of the debate that led to this point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC3934 - Updates to RFC 2418 Regarding the Management of IETF Mailing Lists
This document is an update to RFC 2418 that gives WG chairs explicit responsibility for managing WG mailing lists. In particular, it gives WG chairs the authority to temporarily suspend the mailing list posting privileges of disruptive individuals. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC3933 - A Model for IETF Process Experiments
The IETF has designed process changes over the last ten years in one of two ways: announcement by the IESG, sometimes based on informal agreements with limited community involvement and awareness, and formal use of the same mechanism used for protocol specification. The first mechanism has often proven to be too lightweight, the second too heavyweight.
RFC3932 - The IESG and RFC Editor Documents: Procedures
This document describes the IESG's procedures for handling documents submitted for RFC publication via the RFC Editor, subsequent to the changes proposed by the IESG at the Seoul IETF, March 2004.
RFC3931 - Layer Two Tunneling Protocol - Version 3 (L2TPv3)
This document describes "version 3" of the Layer Two Tunneling Protocol (L2TPv3). L2TPv3 defines the base control protocol and encapsulation for tunneling multiple Layer 2 connections between two IP nodes. Additional documents detail the specifics for each data link type being emulated. [STANDARDS-TRACK]
RFC3930 - The Protocol versus Document Points of View in Computer Protocols
This document contrasts two points of view: the "document" point of view, where digital objects of interest are like pieces of paper written and viewed by people, and the "protocol" point of view where objects of interest are composite dynamic network messages. Although each point of view has a place, adherence to a document point of view can be damaging to protocol design. By understanding both points of view, conflicts between them may be clarified and reduced. This memo provides information for the Internet community.
RFC3929 - Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF
This document proposes an experimental set of alternative decision-making processes for use in IETF working groups. There are a small number of cases in IETF working groups in which the group has come to consensus that a particular decision must be made but cannot agree on the decision itself. This document describes alternative mechanisms for reaching a decision in those cases. This is not meant to provide an exhaustive list, but to provide a known set of tools that can be used when needed. This memo defines an Experimental Protocol for the Internet community.
RFC3928 - Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP)
This document defines the Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP). The protocol is intended to allow an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content. [STANDARDS-TRACK]
RFC3927 - Dynamic Configuration of IPv4 Link-Local Addresses
To participate in wide-area IP networking, a host needs to be configured with IP addresses for its interfaces, either manually by the user or automatically from a source on the network such as a Dynamic Host Configuration Protocol (DHCP) server. Unfortunately, such address configuration information may not always be available. It is therefore beneficial for a host to be able to depend on a useful subset of IP networking functions even when no address configuration is available. This document describes how a host may automatically configure an interface with an IPv4 address within the 169.254/16 prefix that is valid for communication with other devices connected to the same physical (or logical) link.
RFC3926 - FLUTE - File Delivery over Unidirectional Transport
This document defines FLUTE, a protocol for the unidirectional delivery of files over the Internet, which is particularly suited to multicast networks. The specification builds on Asynchronous Layered Coding, the base protocol designed for massively scalable multicast distribution. This memo defines an Experimental Protocol for the Internet community.
RFC3925 - Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)
The Dynamic Host Configuration Protocol (DHCP) options for Vendor Class and Vendor-Specific Information can be limiting or ambiguous when a DHCP client represents multiple vendors. This document defines two new options, modeled on the IPv6 options for vendor class and vendor-specific information, that contain Enterprise Numbers to remove ambiguity. [STANDARDS-TRACK]
RFC3924 - Cisco Architecture for Lawful Intercept in IP Networks
For the purposes of this document, lawful intercept is the lawfully authorized interception and monitoring of communications. Service providers are being asked to meet legal and regulatory requirements for the interception of voice as well as data communications in IP networks in a variety of countries worldwide. Although requirements vary from country to country, some requirements remain common even though details such as delivery formats may differ. This document describes Cisco's Architecture for supporting lawful intercept in IP networks. It provides a general solution that has a minimum set of common interfaces. This document does not attempt to address any of the specific legal requirements or obligations that may exist in a particular country. This memo provides information for the Internet community.
RFC3923 - End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)
This memo defines methods of end-to-end signing and object encryption for the Extensible Messaging and Presence Protocol (XMPP). [STANDARDS-TRACK]
RFC3922 - Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)
This memo describes a mapping between the Extensible Messaging and Presence Protocol (XMPP) and the Common Presence and Instant Messaging (CPIM) specifications. [STANDARDS-TRACK]
RFC3921 - Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence
This memo describes extensions to and applications of the core features of the Extensible Messaging and Presence Protocol (XMPP) that provide the basic instant messaging (IM) and presence functionality defined in RFC 2779. [STANDARDS-TRACK]
RFC3920 - Extensible Messaging and Presence Protocol (XMPP): Core
This memo defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a protocol for streaming Extensible Markup Language (XML) elements in order to exchange structured information in close to real time between any two network endpoints. While XMPP provides a generalized, extensible framework for exchanging XML data, it is used mainly for the purpose of building instant messaging and presence applications that meet the requirements of RFC 2779. [STANDARDS-TRACK]
RFC3919 - Remote Network Monitoring (RMON) Protocol Identifiers for IPv6 and Multi Protocol Label Switching (MPLS)
This memo defines additional (to those in RFC 2896) protocol identifier examples for IP version 6 and MPLS protocols. These can be used to produce valid protocolDirTable ``INDEX`` encodings, as defined by the Remote Network Monitoring MIB (Management Information Base) Version 2 [RFC2021] and the RMON Protocol Identifier Reference [RFC2895].
RFC3918 - Methodology for IP Multicast Benchmarking
The purpose of this document is to describe methodology specific to the benchmarking of multicast IP forwarding devices. It builds upon the tenets set forth in RFC 2544, RFC 2432 and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the multicast paradigm.
RFC3917 - Requirements for IP Flow Information Export (IPFIX)
This memo defines requirements for the export of measured IP flow information out of routers, traffic measurement probes, and middleboxes. This memo provides information for the Internet community.
RFC3916 - Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)
This document describes base requirements for the Pseudo-Wire Emulation Edge to Edge Working Group (PWE3 WG). It provides guidelines for other working group documents that will define mechanisms for providing pseudo-wire emulation of Ethernet, ATM, and Frame Relay. Requirements for pseudo-wire emulation of TDM (i.e., "synchronous bit streams at rates defined by ITU G.702") are defined in another document. It should be noted that the PWE3 WG standardizes mechanisms that can be used to provide PWE3 services, but not the services themselves. This memo provides information for the Internet community.
RFC3915 - Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)
This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the management of Domain Name System (DNS) domain names subject to "grace period" policies defined by the Internet Corporation for Assigned Names and Numbers (ICANN). Grace period policies exist to allow protocol actions to be reversed or otherwise revoked during a short period of time after the protocol action has been performed. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for grace period processing. [STANDARDS-TRACK]
RFC3914 - Open Pluggable Edge Services (OPES) Treatment of IAB Considerations
IETF Internet Architecture Board (IAB) expressed nine architecture-level considerations for the Open Pluggable Edge Services (OPES) framework. This document describes how OPES addresses those considerations. This memo provides information for the Internet community.
This document describes the Network Mobility (NEMO) Basic Support protocol that enables Mobile Networks to attach to different points in the Internet. The protocol is an extension of Mobile IPv6 and allows session continuity for every node in the Mobile Network as the network moves. It also allows every node in the Mobile Network to be reachable while moving around. The Mobile Router, which connects the network to the Internet, runs the NEMO Basic Support protocol with its Home Agent. The protocol is designed so that network mobility is transparent to the nodes inside the Mobile Network. [STANDARDS-TRACK]
RFC3962 - Advanced Encryption Standard (AES) Encryption for Kerberos 5
The United States National Institute of Standards and Technology (NIST) has chosen a new Advanced Encryption Standard (AES), which is significantly faster and (it is believed) more secure than the old Data Encryption Standard (DES) algorithm. This document is a specification for the addition of this algorithm to the Kerberos cryptosystem suite. [STANDARDS-TRACK]
RFC3961 - Encryption and Checksum Specifications for Kerberos 5
This document describes a framework for defining encryption and checksum mechanisms for use with the Kerberos protocol, defining an abstraction layer between the Kerberos protocol and related protocols, and the actual mechanisms themselves. The document also defines several mechanisms. Some are taken from RFC 1510, modified in form to fit this new framework and occasionally modified in content when the old specification was incorrect. New mechanisms are presented here as well. This document does NOT indicate which mechanisms may be considered "required to implement". [STANDARDS-TRACK]
RFC3960 - Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)
This document describes how to manage early media in the Session Initiation Protocol (SIP) using two models: the gateway model and the application server model. It also describes the inputs one needs to consider in defining local policies for ringing tone generation. This memo provides information for the Internet community.
RFC3959 - The Early Session Disposition Type for the Session Initiation Protocol (SIP)
This document defines a new disposition type (early-session) for the Content-Disposition header field in the Session Initiation Protocol (SIP). The treatment of "early-session" bodies is similar to the treatment of "session" bodies. That is, they follow the offer/answer model. Their only difference is that session descriptions whose disposition type is "early-session" are used to establish early media sessions within early dialogs, as opposed to regular sessions within regular dialogs. [STANDARDS-TRACK]
RFC3958 - Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)
This memo defines a generalized mechanism for application service naming that allows service location without relying on rigid domain naming conventions (so-called name hacks). The proposal defines a Dynamic Delegation Discovery System (DDDS) Application to map domain name, application service name, and application protocol dynamically to target server and port. [STANDARDS-TRACK]
RFC3957 - Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4
Authentication, Authorization, and Accounting (AAA) servers, such as RADIUS and DIAMETER, are in use within the Internet today to provide authentication and authorization services for dial-up computers. Mobile IP for IPv4 requires strong authentication between the mobile node and its home agent. When the mobile node shares an AAA Security Association with its home AAA server, however, it is possible to use that AAA Security Association to create derived Mobility Security Associations between the mobile node and its home agent, and again between the mobile node and the foreign agent currently offering connectivity to the mobile node. This document specifies extensions to Mobile IP registration messages that can be used to create Mobility Security Associations between the mobile node and its home agent, and/or between the mobile node and a foreign agent. [STANDARDS-TRACK]
RFC3956 - Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address
This memo defines an address allocation policy in which the address of the Rendezvous Point (RP) is encoded in an IPv6 multicast group address. For Protocol Independent Multicast - Sparse Mode (PIM-SM), this can be seen as a specification of a group-to-RP mapping mechanism. This allows an easy deployment of scalable inter-domain multicast and simplifies the intra-domain multicast configuration as well. This memo updates the addressing format presented in RFC 3306. [STANDARDS-TRACK]
RFC3955 - Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX)
This document contains an evaluation of the five candidate protocols for an IP Flow Information Export (IPFIX) protocol, based on the requirements document produced by the IPFIX Working Group. The protocols are characterized and grouped in broad categories, and evaluated against specific requirements. Finally, a recommendation is made to select the NetFlow v9 protocol as the basis for the IPFIX specification. This memo provides information for the Internet community.
RFC3954 - Cisco Systems NetFlow Services Export Version 9
This document specifies the data export format for version 9 of Cisco Systems' NetFlow services, for use by implementations on the network elements and/or matching collector programs. The version 9 export format uses templates to provide access to observations of IP packet flows in a flexible and extensible manner. A template defines a collection of fields, with corresponding descriptions of structure and semantics. This memo provides information for the Internet community.
RFC3953 - Telephone Number Mapping (ENUM) Service Registration for Presence Services
This document registers a Telephone Number Mapping (ENUM) service for presence. Specifically, this document focuses on provisioning pres URIs in ENUM. [STANDARDS-TRACK]
RFC3952 - Real-time Transport Protocol (RTP) Payload Format for internet Low Bit Rate Codec (iLBC) Speech
This document describes the Real-time Transport Protocol (RTP) payload format for the internet Low Bit Rate Codec (iLBC) Speech developed by Global IP Sound (GIPS). Also, within the document there are included necessary details for the use of iLBC with MIME and Session Description Protocol (SDP). This memo defines an Experimental Protocol for the Internet community.
RFC3951 - Internet Low Bit Rate Codec (iLBC)
This document specifies a speech codec suitable for robust voice communication over IP. The codec is developed by Global IP Sound (GIPS). It is designed for narrow band speech and results in a payload bit rate of 13.33 kbit/s for 30 ms frames and 15.20 kbit/s for 20 ms frames. The codec enables graceful speech quality degradation in the case of lost frames, which occurs in connection with lost or delayed IP packets. This memo defines an Experimental Protocol for the Internet community.
RFC3950 - Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type Registration
This document describes the registration of the MIME sub-type image/tiff-fx. The encodings are defined by File Format for Internet Fax and its extensions. [STANDARDS-TRACK]
RFC3949 - File Format for Internet Fax
This document is a revised version of RFC 2301. The revisions, summarized in the list attached as Annex B, are based on discussions and suggestions for improvements that have been made since RFC 2301 was issued in March 1998, and on the results of independent implementations and interoperability testing.
RFC3948 - UDP Encapsulation of IPsec ESP Packets
This protocol specification defines methods to encapsulate and decapsulate IP Encapsulating Security Payload (ESP) packets inside UDP packets for traversing Network Address Translators. ESP encapsulation, as defined in this document, can be used in both IPv4 and IPv6 scenarios. Whenever negotiated, encapsulation is used with Internet Key Exchange (IKE). [STANDARDS-TRACK]
RFC3947 - Negotiation of NAT-Traversal in the IKE
This document describes how to detect one or more network address translation devices (NATs) between IPsec hosts, and how to negotiate the use of UDP encapsulation of IPsec packets through NAT boxes in Internet Key Exchange (IKE). [STANDARDS-TRACK]
RFC3946 - Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control
This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling. It defines the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology specific information needed when using GMPLS signaling. [STANDARDS-TRACK]
RFC3945 - Generalized Multi-Protocol Label Switching (GMPLS) Architecture
Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques.
RFC3944 - H.350 Directory Services
The International Telecommunications Union Standardization Sector (ITU-T) has created the H.350 series of Recommendations that specify directory services architectures in support of multimedia conferencing protocols. The goal of the architecture is to 'directory enable' multimedia conferencing so that these services can leverage existing identity management and enterprise directories. A particular goal is to enable an enterprise or service provider to maintain a canonical source of users and their multimedia conferencing systems, so that multiple call servers from multiple vendors, supporting multiple protocols, can all access the same data store. Because SIP is an IETF standard, the contents of H.350 and H.350.4 are made available via this document to the IETF community. This document contains the entire normative text of ITU-T Recommendations H.350 and H.350.4 in sections 4 and 5, respectively. The remaining sections are included only in this document, not in the ITU-T version. This memo provides information for the Internet community.
RFC3943 - Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS)
The Transport Layer Security (TLS) protocol (RFC 2246) includes features to negotiate selection of a lossless data compression method as part of the TLS Handshake Protocol and then to apply the algorithm associated with the selected method as part of the TLS Record Protocol. TLS defines one standard compression method, which specifies that data exchanged via the record protocol will not be compressed. This document describes an additional compression method associated with the Lempel-Ziv-Stac (LZS) lossless data compression algorithm for use with TLS. This document also defines the application of the LZS algorithm to the TLS Record Protocol. This memo provides information for the Internet community.
RFC3942 - Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options
This document updates RFC 2132 to reclassify Dynamic Host Configuration Protocol version 4 (DHCPv4) option codes 128 to 223 (decimal) as publicly defined options to be managed by IANA in accordance with RFC 2939. This document directs IANA to make these option codes available for assignment as publicly defined DHCP options for future options. [STANDARDS-TRACK]
RFC3941 - Negative-Acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Building Blocks
This document discusses the creation of negative-acknowledgment (NACK)-oriented reliable multicast (NORM) protocols. The rationale for NORM goals and assumptions are presented. Technical challenges for NACK-oriented (and in some cases general) reliable multicast protocol operation are identified. These goals and challenges are resolved into a set of functional "building blocks" that address different aspects of NORM protocol operation. It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols. This memo defines an Experimental Protocol for the Internet community.
RFC3940 - Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol
This document describes the messages and procedures of the Negative-acknowledgment (NACK) Oriented Reliable Multicast (NORM) protocol. This protocol is designed to provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services. NORM uses a selective, negative acknowledgment mechanism for transport reliability and offers additional protocol mechanisms to allow for operation with minimal "a priori" coordination among senders and receivers. A congestion control scheme is specified to allow the NORM protocol to fairly share available network bandwidth with other transport protocols such as Transmission Control Protocol (TCP). It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity (possibly a unicast return path) between the senders and receivers. The protocol offers a number of features to allow different types of applications or possibly other higher level transport protocols to utilize its service in different ways. The protocol leverages the use of FEC-based repair and other IETF reliable multicast transport (RMT) building blocks in its design. This memo defines an Experimental Protocol for the Internet community.
RFC3939 - Calling Line Identification for Voice Mail Messages
This document describes a method for identifying the originating calling party in the headers of a stored voice mail message. Two new header fields are defined for this purpose: Caller_ID and Called_Name. Caller_id is used to store sufficient information for the recipient to callback, or reply to, the sender of the message. Caller-name provides the name of the person sending the message. [STANDARDS-TRACK]
RFC3938 - Video-Message Message-Context
The Message-Context header defined in RFC 3458 describes the context of a message (for example: fax-message or voice-message). This specification extends the Message-Context header with one additional context value: "video-message".
RFC3937 - A Uniform Resource Name (URN) Namespace for the International Press Telecommunications Council (IPTC)
This document describes a URN (Uniform Resource Name) namespace for identifying persistent resources published by the International Press Telecommunications Council (IPTC). These resources include XML Data Type Definition files (DTD), XML Schema, Namespaces in XML, XSL stylesheets, other XML based document and documents of other data formats like PDF documents, Microsoft Office documents and others. This memo provides information for the Internet community.
RFC3936 - Procedures for Modifying the Resource reSerVation Protocol (RSVP)
This memo specifies procedures for modifying the Resource reSerVation Protocol (RSVP). This memo also lays out new assignment guidelines for number spaces for RSVP messages, object classes, class-types, and sub-objects. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC3935 - A Mission Statement for the IETF
This memo gives a mission statement for the IETF, tries to define the terms used in the statement sufficiently to make the mission statement understandable and useful, argues why the IETF needs a mission statement, and tries to capture some of the debate that led to this point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC3934 - Updates to RFC 2418 Regarding the Management of IETF Mailing Lists
This document is an update to RFC 2418 that gives WG chairs explicit responsibility for managing WG mailing lists. In particular, it gives WG chairs the authority to temporarily suspend the mailing list posting privileges of disruptive individuals. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC3933 - A Model for IETF Process Experiments
The IETF has designed process changes over the last ten years in one of two ways: announcement by the IESG, sometimes based on informal agreements with limited community involvement and awareness, and formal use of the same mechanism used for protocol specification. The first mechanism has often proven to be too lightweight, the second too heavyweight.
RFC3932 - The IESG and RFC Editor Documents: Procedures
This document describes the IESG's procedures for handling documents submitted for RFC publication via the RFC Editor, subsequent to the changes proposed by the IESG at the Seoul IETF, March 2004.
RFC3931 - Layer Two Tunneling Protocol - Version 3 (L2TPv3)
This document describes "version 3" of the Layer Two Tunneling Protocol (L2TPv3). L2TPv3 defines the base control protocol and encapsulation for tunneling multiple Layer 2 connections between two IP nodes. Additional documents detail the specifics for each data link type being emulated. [STANDARDS-TRACK]
RFC3930 - The Protocol versus Document Points of View in Computer Protocols
This document contrasts two points of view: the "document" point of view, where digital objects of interest are like pieces of paper written and viewed by people, and the "protocol" point of view where objects of interest are composite dynamic network messages. Although each point of view has a place, adherence to a document point of view can be damaging to protocol design. By understanding both points of view, conflicts between them may be clarified and reduced. This memo provides information for the Internet community.
RFC3929 - Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF
This document proposes an experimental set of alternative decision-making processes for use in IETF working groups. There are a small number of cases in IETF working groups in which the group has come to consensus that a particular decision must be made but cannot agree on the decision itself. This document describes alternative mechanisms for reaching a decision in those cases. This is not meant to provide an exhaustive list, but to provide a known set of tools that can be used when needed. This memo defines an Experimental Protocol for the Internet community.
RFC3928 - Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP)
This document defines the Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP). The protocol is intended to allow an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content. [STANDARDS-TRACK]
RFC3927 - Dynamic Configuration of IPv4 Link-Local Addresses
To participate in wide-area IP networking, a host needs to be configured with IP addresses for its interfaces, either manually by the user or automatically from a source on the network such as a Dynamic Host Configuration Protocol (DHCP) server. Unfortunately, such address configuration information may not always be available. It is therefore beneficial for a host to be able to depend on a useful subset of IP networking functions even when no address configuration is available. This document describes how a host may automatically configure an interface with an IPv4 address within the 169.254/16 prefix that is valid for communication with other devices connected to the same physical (or logical) link.
RFC3926 - FLUTE - File Delivery over Unidirectional Transport
This document defines FLUTE, a protocol for the unidirectional delivery of files over the Internet, which is particularly suited to multicast networks. The specification builds on Asynchronous Layered Coding, the base protocol designed for massively scalable multicast distribution. This memo defines an Experimental Protocol for the Internet community.
RFC3925 - Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)
The Dynamic Host Configuration Protocol (DHCP) options for Vendor Class and Vendor-Specific Information can be limiting or ambiguous when a DHCP client represents multiple vendors. This document defines two new options, modeled on the IPv6 options for vendor class and vendor-specific information, that contain Enterprise Numbers to remove ambiguity. [STANDARDS-TRACK]
RFC3924 - Cisco Architecture for Lawful Intercept in IP Networks
For the purposes of this document, lawful intercept is the lawfully authorized interception and monitoring of communications. Service providers are being asked to meet legal and regulatory requirements for the interception of voice as well as data communications in IP networks in a variety of countries worldwide. Although requirements vary from country to country, some requirements remain common even though details such as delivery formats may differ. This document describes Cisco's Architecture for supporting lawful intercept in IP networks. It provides a general solution that has a minimum set of common interfaces. This document does not attempt to address any of the specific legal requirements or obligations that may exist in a particular country. This memo provides information for the Internet community.
RFC3923 - End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)
This memo defines methods of end-to-end signing and object encryption for the Extensible Messaging and Presence Protocol (XMPP). [STANDARDS-TRACK]
RFC3922 - Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)
This memo describes a mapping between the Extensible Messaging and Presence Protocol (XMPP) and the Common Presence and Instant Messaging (CPIM) specifications. [STANDARDS-TRACK]
RFC3921 - Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence
This memo describes extensions to and applications of the core features of the Extensible Messaging and Presence Protocol (XMPP) that provide the basic instant messaging (IM) and presence functionality defined in RFC 2779. [STANDARDS-TRACK]
RFC3920 - Extensible Messaging and Presence Protocol (XMPP): Core
This memo defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a protocol for streaming Extensible Markup Language (XML) elements in order to exchange structured information in close to real time between any two network endpoints. While XMPP provides a generalized, extensible framework for exchanging XML data, it is used mainly for the purpose of building instant messaging and presence applications that meet the requirements of RFC 2779. [STANDARDS-TRACK]
RFC3919 - Remote Network Monitoring (RMON) Protocol Identifiers for IPv6 and Multi Protocol Label Switching (MPLS)
This memo defines additional (to those in RFC 2896) protocol identifier examples for IP version 6 and MPLS protocols. These can be used to produce valid protocolDirTable ``INDEX`` encodings, as defined by the Remote Network Monitoring MIB (Management Information Base) Version 2 [RFC2021] and the RMON Protocol Identifier Reference [RFC2895].
RFC3918 - Methodology for IP Multicast Benchmarking
The purpose of this document is to describe methodology specific to the benchmarking of multicast IP forwarding devices. It builds upon the tenets set forth in RFC 2544, RFC 2432 and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the multicast paradigm.
RFC3917 - Requirements for IP Flow Information Export (IPFIX)
This memo defines requirements for the export of measured IP flow information out of routers, traffic measurement probes, and middleboxes. This memo provides information for the Internet community.
RFC3916 - Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)
This document describes base requirements for the Pseudo-Wire Emulation Edge to Edge Working Group (PWE3 WG). It provides guidelines for other working group documents that will define mechanisms for providing pseudo-wire emulation of Ethernet, ATM, and Frame Relay. Requirements for pseudo-wire emulation of TDM (i.e., "synchronous bit streams at rates defined by ITU G.702") are defined in another document. It should be noted that the PWE3 WG standardizes mechanisms that can be used to provide PWE3 services, but not the services themselves. This memo provides information for the Internet community.
RFC3915 - Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)
This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the management of Domain Name System (DNS) domain names subject to "grace period" policies defined by the Internet Corporation for Assigned Names and Numbers (ICANN). Grace period policies exist to allow protocol actions to be reversed or otherwise revoked during a short period of time after the protocol action has been performed. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for grace period processing. [STANDARDS-TRACK]
RFC3914 - Open Pluggable Edge Services (OPES) Treatment of IAB Considerations
IETF Internet Architecture Board (IAB) expressed nine architecture-level considerations for the Open Pluggable Edge Services (OPES) framework. This document describes how OPES addresses those considerations. This memo provides information for the Internet community.