RFC Abstracts
RFC4243 - Vendor-Specific Information Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option
This memo defines a new Vendor-Specific Information suboption for the Dynamic Host Configuration Protocol's (DHCP) relay agent information option. The suboption allows a DHCP relay agent to include vendor-specific information in the DHCP messages it forwards, as configured by its administrator. [STANDARDS-TRACK]
RFC4242 - Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
This document describes a Dynamic Host Configuration Protocol for IPv6 (DHCPv6) option for specifying an upper bound for how long a client should wait before refreshing information retrieved from DHCPv6. It is used with stateless DHCPv6 as there are no addresses or other entities with lifetimes that can tell the client when to contact the DHCPv6 server to refresh its configuration. [STANDARDS-TRACK]
RFC4241 - A Model of IPv6/IPv4 Dual Stack Internet Access Service
This memo is a digest of the user network interface specification of NTT Communications' dual stack ADSL access service, which provide a IPv6/IPv4 dual stack services to home users. In order to simplify user setup, these services have a mechanism to configure IPv6 specific parameters automatically. The memo focuses on two basic parameters: the prefix assigned to the user and the addresses of IPv6 DNS servers, and it specifies a way to deliver these parameters to Customer Premises Equipment (CPE) automatically. This memo provides information for the Internet community.
RFC4240 - Basic Network Media Services with SIP
In SIP-based networks, there is a need to provide basic network media services. Such services include network announcements, user interaction, and conferencing services. These services are basic building blocks, from which one can construct interesting applications. In order to have interoperability between servers offering these building blocks (also known as Media Servers) and application developers, one needs to be able to locate and invoke such services in a well defined manner.
RFC4239 - Internet Voice Messaging (IVM)
This document describes the carriage of voicemail messages over Internet mail as part of a unified messaging infrastructure.
RFC4238 - Voice Message Routing Service
Voice messaging is traditionally addressed using telephone number addressing. This document describes two techniques for routing voice messages based on a telephone number. The complete service uses the Voice Profile for Internet Mail (VPIM) Directory service to lookup a VPIM email address with a telephone number and confirm that the address is both valid and associated with the intended recipient. However, this service will take time to become widely deployed in the near term. This document also describes a basic send-and-pray service that routes and delivers messages using only the ENUM telephone number resolution service and the existing DNS mail routing facilities. [STANDARDS-TRACK]
RFC4237 - Voice Messaging Directory Service
This document provides details of the Voice Profile for Internet Mail (VPIM) directory service. The service provides the email address of the recipient that is given a telephone number. It optionally provides the spoken name of the recipient and the media capabilities of the recipient.
RFC4236 - HTTP Adaptation with Open Pluggable Edge Services (OPES)
Open Pluggable Edge Services (OPES) framework documents several application-agnostic mechanisms such as OPES tracing, OPES bypass, and OPES callout protocol. This document extends those generic mechanisms for Hypertext Transfer Protocol (HTTP) adaptation. Together, application-agnostic OPES documents and this HTTP profile constitute a complete specification for HTTP adaptation with OPES. [STANDARDS-TRACK]
RFC4235 - An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)
This document defines a dialog event package for the SIP Events architecture, along with a data format used in notifications for this package. The dialog package allows users to subscribe to another user and to receive notification of the changes in state of INVITE-initiated dialog usages in which the subscribed-to user is involved. [STANDARDS-TRACK]
RFC4234 - Augmented BNF for Syntax Specifications: ABNF
Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity, with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]
RFC4233 - Integrated Services Digital Network (ISDN) Q.921-User Adaptation Layer
This document defines a protocol for backhauling of Integrated Services Digital Network (ISDN) Q.921 User messages over IP using the Stream Control Transmission Protocol (SCTP). This protocol would be used between a Signaling Gateway (SG) and Media Gateway Controller (MGC). It is assumed that the SG receives ISDN signaling over a standard ISDN interface.
RFC4231 - Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512
This document provides test vectors for the HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 message authentication schemes. It also provides ASN.1 object identifiers and Uniform Resource Identifiers (URIs) to identify use of these schemes in protocols. The test vectors provided in this document may be used for conformance testing. [STANDARDS-TRACK]
RFC4230 - RSVP Security Properties
This document summarizes the security properties of RSVP. The goal of this analysis is to benefit from previous work done on RSVP and to capture knowledge about past activities. This memo provides information for the Internet community.
RFC4229 - HTTP Header Field Registrations
This document defines the initial contents of a permanent IANA registry for HTTP header fields and a provisional repository for HTTP header fields, per RFC 3864. This memo provides information for the Internet community.
RFC4228 - Requirements for an IETF Draft Submission Toolset
This document specifies requirements for an IETF toolset to facilitate Internet-Draft submission, validation, and posting. This memo provides information for the Internet community.
RFC4227 - Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)
This memo specifies a Simple Object Access Protocol (SOAP) binding to the Blocks Extensible Exchange Protocol (BEEP) core. A SOAP binding describes how SOAP messages are transmitted in the network.
RFC4226 - HOTP: An HMAC-Based One-Time Password Algorithm
This document describes an algorithm to generate one-time password values, based on Hashed Message Authentication Code (HMAC). A security analysis of the algorithm is presented, and important parameters related to the secure deployment of the algorithm are discussed. The proposed algorithm can be used across a wide range of network applications ranging from remote Virtual Private Network (VPN) access, Wi-Fi network logon to transaction-oriented Web applications.
RFC4225 - Mobile IP Version 6 Route Optimization Security Design Background
This document is an account of the rationale behind the Mobile IPv6 (MIPv6) Route Optimization security design. The purpose of this document is to present the thinking and to preserve the reasoning behind the Mobile IPv6 security design in 2001 - 2002.
RFC4224 - RObust Header Compression (ROHC): ROHC over Channels That Can Reorder Packets
RObust Header Compression (ROHC), RFC 3095, defines a framework for header compression, along with a number of compression protocols (profiles). One operating assumption for the profiles defined in RFC 3095 is that the channel between compressor and decompressor is required to maintain packet ordering. This document discusses aspects of using ROHC over channels that can reorder packets. It provides guidelines on how to implement existing profiles over such channels, as well as suggestions for the design of new profiles. This memo provides information for the Internet community.
RFC4223 - Reclassification of RFC 1863 to Historic
This memo reclassifies RFC 1863, A BGP/IDRP Route Server alternative to a full mesh routing, to Historic status. This memo also obsoletes RFC 1863. This memo provides information for the Internet community.
RFC4222 - Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance
This document recommends methods that are intended to improve the scalability and stability of large networks using Open Shortest Path First (OSPF) Version 2 protocol. The methods include processing OSPF Hellos and Link State Advertisement (LSA) Acknowledgments at a higher priority compared to other OSPF packets, and other congestion avoidance procedures. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC4221 - Multiprotocol Label Switching (MPLS) Management Overview
A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects of Multiprotocol Label Switching (MPLS) networks. These MIB modules are defined in separate documents that focus on the specific areas of responsibility of the modules that they describe.
RFC4220 - Traffic Engineering Link Management Information Base
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 for modeling TE links as described in the Link Bundling in MPLS Traffic Engineering (TE) document. [STANDARDS-TRACK]
RFC4219 - Things Multihoming in IPv6 (MULTI6) Developers Should Think About
This document specifies a set of questions that authors should be prepared to answer as part of a solution to multihoming with IPv6. The questions do not assume that multihoming is the only problem of interest, nor do they demand a more general solution. This memo provides information for the Internet community.
RFC4218 - Threats Relating to IPv6 Multihoming Solutions
This document lists security threats related to IPv6 multihoming. Multihoming can introduce new opportunities to redirect packets to different, unintended IP addresses.
RFC4217 - Securing FTP with TLS
This document describes a mechanism that can be used by FTP clients and servers to implement security and authentication using the TLS protocol defined by RFC 2246, "The TLS Protocol Version 1.0.", and the extensions to the FTP protocol defined by RFC 2228, "FTP Security Extensions". It describes the subset of the extensions that are required and the parameters to be used, discusses some of the policy issues that clients and servers will need to take, considers some of the implications of those policies, and discusses some expected behaviours of implementations to allow interoperation. This document is intended to provide TLS support for FTP in a similar way to that provided for SMTP in RFC 2487, "SMTP Service Extension for Secure SMTP over Transport Layer Security", and HTTP in RFC 2817, "Upgrading to TLS Within HTTP/1.1.".
RFC4216 - MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements
This document discusses requirements for the support of inter-AS MPLS Traffic Engineering (MPLS TE). Its main objective is to present a set of requirements and scenarios which would result in general guidelines for the definition, selection, and specification development for any technical solution(s) meeting these requirements and supporting the scenarios. This memo provides information for the Internet community.
RFC4215 - Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks
This document analyzes the transition to IPv6 in Third Generation Partnership Project (3GPP) packet networks. These networks are based on General Packet Radio Service (GPRS) technology, and the radio network architecture is based on Global System for Mobile Communications (GSM) or Universal Mobile Telecommunications System (UMTS)/Wideband Code Division Multiple Access (WCDMA) technology.
RFC4214 - Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connects IPv6 hosts/routers over IPv4 networks. ISATAP views the IPv4 network as a link layer for IPv6 and views other nodes on the network as potential IPv6 hosts/routers. ISATAP supports an automatic tunneling abstraction similar to the Non-Broadcast Multiple Access (NBMA) model. This memo defines an Experimental Protocol for the Internet community.
RFC4213 - Basic Transition Mechanisms for IPv6 Hosts and Routers
This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. Two mechanisms are specified, dual stack and configured tunneling. Dual stack implies providing complete implementations of both versions of the Internet Protocol (IPv4 and IPv6), and configured tunneling provides a means to carry IPv6 packets over unmodified IPv4 routing infrastructures.
RFC4212 - Alternative Certificate Formats for the Public-Key Infrastructure Using X.509 (PKIX) Certificate Management Protocols
The Public-Key Infrastructure using X.509 (PKIX) Working Group of the Internet Engineering Task Force (IETF) has defined a number of certificate management protocols. These protocols are primarily focused on X.509v3 public-key certificates. However, it is sometimes desirable to manage certificates in alternative formats as well. This document specifies how such certificates may be requested using the Certificate Request Message Format (CRMF) syntax that is used by several different protocols. It also explains how alternative certificate formats may be incorporated into such popular protocols as PKIX Certificate Management Protocol (PKIX-CMP) and Certificate Management Messages over CMS (CMC). This memo provides information for the Internet community.
RFC4211 - Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)
This document describes the Certificate Request Message Format (CRMF) syntax and semantics. This syntax is used to convey a request for a certificate to a Certification Authority (CA), possibly via a Registration Authority (RA), for the purposes of X.509 certificate production. The request will typically include a public key and the associated registration information. This document does not define a certificate request protocol. [STANDARDS-TRACK]
RFC4210 - Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)
This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP). Protocol messages are defined for X.509v3 certificate creation and management. CMP provides on-line interactions between PKI components, including an exchange between a Certification Authority (CA) and a client system. [STANDARDS-TRACK]
RFC4209 - Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems
The Link Management Protocol (LMP) is defined to manage traffic engineering (TE) links. In its present form, LMP focuses on peer nodes, i.e., nodes that peer in signaling and/or routing. This document proposes extensions to LMP to allow it to be used between a peer node and an adjacent optical line system (OLS). These extensions are intended to satisfy the "Optical Link Interface Requirements" described in a companion document. [STANDARDS-TRACK]
RFC4208 - Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model
Generalized Multiprotocol Label Switching (GMPLS) defines both routing and signaling protocols for the creation of Label Switched Paths (LSPs) in various switching technologies. These protocols can be used to support a number of deployment scenarios. This memo addresses the application of GMPLS to the overlay model. [STANDARDS-TRACK]
RFC4207 - Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages
This document details the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology-specific information needed when sending Link Management Protocol (LMP) test messages. [STANDARDS-TRACK]
RFC4206 - Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)
To improve scalability of Generalized Multi-Protocol Label Switching (GMPLS) it may be useful to aggregate Label Switched Paths (LSPs) by creating a hierarchy of such LSPs. A way to create such a hierarchy is by (a) a Label Switching Router (LSR) creating a Traffic Engineering Label Switched Path (TE LSP), (b) the LSR forming a forwarding adjacency (FA) out of that LSP (by advertising this LSP as a Traffic Engineering (TE) link into the same instance of ISIS/OSPF as the one that was used to create the LSP), (c) allowing other LSRs to use FAs for their path computation, and (d) nesting of LSPs originated by other LSRs into that LSP (by using the label stack construct).
RFC4205 - Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)
This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). This memo provides information for the Internet community.
RFC4204 - Link Management Protocol (LMP)
For scalability purposes, multiple data links can be combined to form a single traffic engineering (TE) link. Furthermore, the management of TE links is not restricted to in-band messaging, but instead can be done using out-of-band techniques. This document specifies a link management protocol (LMP) that runs between a pair of nodes and is used to manage TE links. Specifically, LMP will be used to maintain control channel connectivity, verify the physical connectivity of the data links, correlate the link property information, suppress downstream alarms, and localize link failures for protection/restoration purposes in multiple kinds of networks. [STANDARDS-TRACK]
RFC4203 - OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)
This document specifies encoding of extensions to the OSPF routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). [STANDARDS-TRACK]
RFC4202 - Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)
This document specifies routing extensions in support of carrying link state information for Generalized Multi-Protocol Label Switching (GMPLS). This document enhances the routing extensions required to support MPLS Traffic Engineering (TE). [STANDARDS-TRACK]
RFC4201 - Link Bundling in MPLS Traffic Engineering (TE)
For the purpose of Generalized Multi-Protocol Label Switching (GMPLS) signaling, in certain cases a combination of <link identifier, label> is not sufficient to unambiguously identify the appropriate resource used by a Label Switched Path (LSP). Such cases are handled by using the link bundling construct, which is described in this document. This document updates the interface identification TLVs, which are defined in the GMPLS Signaling Functional Description. [STANDARDS-TRACK]
RFC4198 - A Uniform Resource Name (URN) Namespace for Federated Content
This document describes a URN (Uniform Resource Name) namespace for identifying content resources within federated content collections. A federated content collection often does not have a strong centralized authority but relies upon shared naming, metadata, and access conventions to provide interoperability among its members. This memo provides information for the Internet community.
RFC4197 - Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks
This document defines the specific requirements for edge-to-edge emulation of circuits carrying Time Division Multiplexed (TDM) digital signals of the Plesiochronous Digital Hierarchy as well as the Synchronous Optical NETwork/Synchronous Digital Hierarchy over packet-switched networks. It is aligned to the common architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3). It makes references to the generic requirements for PWE3 where applicable and complements them by defining requirements originating from specifics of TDM circuits. This memo provides information for the Internet community.
RFC4196 - The SEED Cipher Algorithm and Its Use with IPsec
This document describes the use of the SEED block cipher algorithm in the Cipher Block Chaining Mode, with an explicit IV, as a confidentiality mechanism within the context of the IPsec Encapsulating Security Payload (ESP). [STANDARDS-TRACK]
RFC4195 - A Uniform Resource Name (URN) Namespace for the TV-Anytime Forum
This document describes a Uniform Resource Name (URN) namespace that is engineered by the TV-Anytime Forum for naming persistent resources published by the TV-Anytime Forum including the TV-Anytime Forum Standards, XML (Extensible Markup Language) Document Type Definitions, XML Schemas, Namespaces, and other documents. This memo provides information for the Internet community.
RFC4194 - The S Hexdump Format
This document specifies the S Hexdump Format (SHF), a new, XML-based open format for describing binary data in hexadecimal notation. SHF provides the ability to describe both small and large, simple and complex hexadecimal data dumps in an open, modern, transport- and vendor-neutral format. [STANDARDS-TRACK]
RFC4193 - Unique Local IPv6 Unicast Addresses
This document defines an IPv6 unicast address format that is globally unique and is intended for local communications, usually inside of a site. These addresses are not expected to be routable on the global Internet. [STANDARDS-TRACK]
RFC4192 - Procedures for Renumbering an IPv6 Network without a Flag Day
This document describes a procedure that can be used to renumber a network from one prefix to another. It uses IPv6's intrinsic ability to assign multiple addresses to a network interface to provide continuity of network service through a "make-before-break" transition, as well as addresses naming and configuration management issues. It also uses other IPv6 features to minimize the effort and time required to complete the transition from the old prefix to the new prefix. This memo provides information for the Internet community.
RFC4191 - Default Router Preferences and More-Specific Routes
This document describes an optional extension to Router Advertisement messages for communicating default router preferences and more-specific routes from routers to hosts. This improves the ability of hosts to pick an appropriate router, especially when the host is multi-homed and the routers are on different links. The preference values and specific routes advertised to hosts require administrative configuration; they are not automatically derived from routing tables. [STANDARDS-TRACK]
This memo defines a new Vendor-Specific Information suboption for the Dynamic Host Configuration Protocol's (DHCP) relay agent information option. The suboption allows a DHCP relay agent to include vendor-specific information in the DHCP messages it forwards, as configured by its administrator. [STANDARDS-TRACK]
RFC4242 - Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
This document describes a Dynamic Host Configuration Protocol for IPv6 (DHCPv6) option for specifying an upper bound for how long a client should wait before refreshing information retrieved from DHCPv6. It is used with stateless DHCPv6 as there are no addresses or other entities with lifetimes that can tell the client when to contact the DHCPv6 server to refresh its configuration. [STANDARDS-TRACK]
RFC4241 - A Model of IPv6/IPv4 Dual Stack Internet Access Service
This memo is a digest of the user network interface specification of NTT Communications' dual stack ADSL access service, which provide a IPv6/IPv4 dual stack services to home users. In order to simplify user setup, these services have a mechanism to configure IPv6 specific parameters automatically. The memo focuses on two basic parameters: the prefix assigned to the user and the addresses of IPv6 DNS servers, and it specifies a way to deliver these parameters to Customer Premises Equipment (CPE) automatically. This memo provides information for the Internet community.
RFC4240 - Basic Network Media Services with SIP
In SIP-based networks, there is a need to provide basic network media services. Such services include network announcements, user interaction, and conferencing services. These services are basic building blocks, from which one can construct interesting applications. In order to have interoperability between servers offering these building blocks (also known as Media Servers) and application developers, one needs to be able to locate and invoke such services in a well defined manner.
RFC4239 - Internet Voice Messaging (IVM)
This document describes the carriage of voicemail messages over Internet mail as part of a unified messaging infrastructure.
RFC4238 - Voice Message Routing Service
Voice messaging is traditionally addressed using telephone number addressing. This document describes two techniques for routing voice messages based on a telephone number. The complete service uses the Voice Profile for Internet Mail (VPIM) Directory service to lookup a VPIM email address with a telephone number and confirm that the address is both valid and associated with the intended recipient. However, this service will take time to become widely deployed in the near term. This document also describes a basic send-and-pray service that routes and delivers messages using only the ENUM telephone number resolution service and the existing DNS mail routing facilities. [STANDARDS-TRACK]
RFC4237 - Voice Messaging Directory Service
This document provides details of the Voice Profile for Internet Mail (VPIM) directory service. The service provides the email address of the recipient that is given a telephone number. It optionally provides the spoken name of the recipient and the media capabilities of the recipient.
RFC4236 - HTTP Adaptation with Open Pluggable Edge Services (OPES)
Open Pluggable Edge Services (OPES) framework documents several application-agnostic mechanisms such as OPES tracing, OPES bypass, and OPES callout protocol. This document extends those generic mechanisms for Hypertext Transfer Protocol (HTTP) adaptation. Together, application-agnostic OPES documents and this HTTP profile constitute a complete specification for HTTP adaptation with OPES. [STANDARDS-TRACK]
RFC4235 - An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)
This document defines a dialog event package for the SIP Events architecture, along with a data format used in notifications for this package. The dialog package allows users to subscribe to another user and to receive notification of the changes in state of INVITE-initiated dialog usages in which the subscribed-to user is involved. [STANDARDS-TRACK]
RFC4234 - Augmented BNF for Syntax Specifications: ABNF
Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity, with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]
RFC4233 - Integrated Services Digital Network (ISDN) Q.921-User Adaptation Layer
This document defines a protocol for backhauling of Integrated Services Digital Network (ISDN) Q.921 User messages over IP using the Stream Control Transmission Protocol (SCTP). This protocol would be used between a Signaling Gateway (SG) and Media Gateway Controller (MGC). It is assumed that the SG receives ISDN signaling over a standard ISDN interface.
RFC4231 - Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512
This document provides test vectors for the HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 message authentication schemes. It also provides ASN.1 object identifiers and Uniform Resource Identifiers (URIs) to identify use of these schemes in protocols. The test vectors provided in this document may be used for conformance testing. [STANDARDS-TRACK]
RFC4230 - RSVP Security Properties
This document summarizes the security properties of RSVP. The goal of this analysis is to benefit from previous work done on RSVP and to capture knowledge about past activities. This memo provides information for the Internet community.
RFC4229 - HTTP Header Field Registrations
This document defines the initial contents of a permanent IANA registry for HTTP header fields and a provisional repository for HTTP header fields, per RFC 3864. This memo provides information for the Internet community.
RFC4228 - Requirements for an IETF Draft Submission Toolset
This document specifies requirements for an IETF toolset to facilitate Internet-Draft submission, validation, and posting. This memo provides information for the Internet community.
RFC4227 - Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)
This memo specifies a Simple Object Access Protocol (SOAP) binding to the Blocks Extensible Exchange Protocol (BEEP) core. A SOAP binding describes how SOAP messages are transmitted in the network.
RFC4226 - HOTP: An HMAC-Based One-Time Password Algorithm
This document describes an algorithm to generate one-time password values, based on Hashed Message Authentication Code (HMAC). A security analysis of the algorithm is presented, and important parameters related to the secure deployment of the algorithm are discussed. The proposed algorithm can be used across a wide range of network applications ranging from remote Virtual Private Network (VPN) access, Wi-Fi network logon to transaction-oriented Web applications.
RFC4225 - Mobile IP Version 6 Route Optimization Security Design Background
This document is an account of the rationale behind the Mobile IPv6 (MIPv6) Route Optimization security design. The purpose of this document is to present the thinking and to preserve the reasoning behind the Mobile IPv6 security design in 2001 - 2002.
RFC4224 - RObust Header Compression (ROHC): ROHC over Channels That Can Reorder Packets
RObust Header Compression (ROHC), RFC 3095, defines a framework for header compression, along with a number of compression protocols (profiles). One operating assumption for the profiles defined in RFC 3095 is that the channel between compressor and decompressor is required to maintain packet ordering. This document discusses aspects of using ROHC over channels that can reorder packets. It provides guidelines on how to implement existing profiles over such channels, as well as suggestions for the design of new profiles. This memo provides information for the Internet community.
RFC4223 - Reclassification of RFC 1863 to Historic
This memo reclassifies RFC 1863, A BGP/IDRP Route Server alternative to a full mesh routing, to Historic status. This memo also obsoletes RFC 1863. This memo provides information for the Internet community.
RFC4222 - Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance
This document recommends methods that are intended to improve the scalability and stability of large networks using Open Shortest Path First (OSPF) Version 2 protocol. The methods include processing OSPF Hellos and Link State Advertisement (LSA) Acknowledgments at a higher priority compared to other OSPF packets, and other congestion avoidance procedures. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC4221 - Multiprotocol Label Switching (MPLS) Management Overview
A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects of Multiprotocol Label Switching (MPLS) networks. These MIB modules are defined in separate documents that focus on the specific areas of responsibility of the modules that they describe.
RFC4220 - Traffic Engineering Link Management Information Base
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 for modeling TE links as described in the Link Bundling in MPLS Traffic Engineering (TE) document. [STANDARDS-TRACK]
RFC4219 - Things Multihoming in IPv6 (MULTI6) Developers Should Think About
This document specifies a set of questions that authors should be prepared to answer as part of a solution to multihoming with IPv6. The questions do not assume that multihoming is the only problem of interest, nor do they demand a more general solution. This memo provides information for the Internet community.
RFC4218 - Threats Relating to IPv6 Multihoming Solutions
This document lists security threats related to IPv6 multihoming. Multihoming can introduce new opportunities to redirect packets to different, unintended IP addresses.
RFC4217 - Securing FTP with TLS
This document describes a mechanism that can be used by FTP clients and servers to implement security and authentication using the TLS protocol defined by RFC 2246, "The TLS Protocol Version 1.0.", and the extensions to the FTP protocol defined by RFC 2228, "FTP Security Extensions". It describes the subset of the extensions that are required and the parameters to be used, discusses some of the policy issues that clients and servers will need to take, considers some of the implications of those policies, and discusses some expected behaviours of implementations to allow interoperation. This document is intended to provide TLS support for FTP in a similar way to that provided for SMTP in RFC 2487, "SMTP Service Extension for Secure SMTP over Transport Layer Security", and HTTP in RFC 2817, "Upgrading to TLS Within HTTP/1.1.".
RFC4216 - MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements
This document discusses requirements for the support of inter-AS MPLS Traffic Engineering (MPLS TE). Its main objective is to present a set of requirements and scenarios which would result in general guidelines for the definition, selection, and specification development for any technical solution(s) meeting these requirements and supporting the scenarios. This memo provides information for the Internet community.
RFC4215 - Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks
This document analyzes the transition to IPv6 in Third Generation Partnership Project (3GPP) packet networks. These networks are based on General Packet Radio Service (GPRS) technology, and the radio network architecture is based on Global System for Mobile Communications (GSM) or Universal Mobile Telecommunications System (UMTS)/Wideband Code Division Multiple Access (WCDMA) technology.
RFC4214 - Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connects IPv6 hosts/routers over IPv4 networks. ISATAP views the IPv4 network as a link layer for IPv6 and views other nodes on the network as potential IPv6 hosts/routers. ISATAP supports an automatic tunneling abstraction similar to the Non-Broadcast Multiple Access (NBMA) model. This memo defines an Experimental Protocol for the Internet community.
RFC4213 - Basic Transition Mechanisms for IPv6 Hosts and Routers
This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. Two mechanisms are specified, dual stack and configured tunneling. Dual stack implies providing complete implementations of both versions of the Internet Protocol (IPv4 and IPv6), and configured tunneling provides a means to carry IPv6 packets over unmodified IPv4 routing infrastructures.
RFC4212 - Alternative Certificate Formats for the Public-Key Infrastructure Using X.509 (PKIX) Certificate Management Protocols
The Public-Key Infrastructure using X.509 (PKIX) Working Group of the Internet Engineering Task Force (IETF) has defined a number of certificate management protocols. These protocols are primarily focused on X.509v3 public-key certificates. However, it is sometimes desirable to manage certificates in alternative formats as well. This document specifies how such certificates may be requested using the Certificate Request Message Format (CRMF) syntax that is used by several different protocols. It also explains how alternative certificate formats may be incorporated into such popular protocols as PKIX Certificate Management Protocol (PKIX-CMP) and Certificate Management Messages over CMS (CMC). This memo provides information for the Internet community.
RFC4211 - Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)
This document describes the Certificate Request Message Format (CRMF) syntax and semantics. This syntax is used to convey a request for a certificate to a Certification Authority (CA), possibly via a Registration Authority (RA), for the purposes of X.509 certificate production. The request will typically include a public key and the associated registration information. This document does not define a certificate request protocol. [STANDARDS-TRACK]
RFC4210 - Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)
This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP). Protocol messages are defined for X.509v3 certificate creation and management. CMP provides on-line interactions between PKI components, including an exchange between a Certification Authority (CA) and a client system. [STANDARDS-TRACK]
RFC4209 - Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems
The Link Management Protocol (LMP) is defined to manage traffic engineering (TE) links. In its present form, LMP focuses on peer nodes, i.e., nodes that peer in signaling and/or routing. This document proposes extensions to LMP to allow it to be used between a peer node and an adjacent optical line system (OLS). These extensions are intended to satisfy the "Optical Link Interface Requirements" described in a companion document. [STANDARDS-TRACK]
RFC4208 - Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model
Generalized Multiprotocol Label Switching (GMPLS) defines both routing and signaling protocols for the creation of Label Switched Paths (LSPs) in various switching technologies. These protocols can be used to support a number of deployment scenarios. This memo addresses the application of GMPLS to the overlay model. [STANDARDS-TRACK]
RFC4207 - Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages
This document details the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology-specific information needed when sending Link Management Protocol (LMP) test messages. [STANDARDS-TRACK]
RFC4206 - Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)
To improve scalability of Generalized Multi-Protocol Label Switching (GMPLS) it may be useful to aggregate Label Switched Paths (LSPs) by creating a hierarchy of such LSPs. A way to create such a hierarchy is by (a) a Label Switching Router (LSR) creating a Traffic Engineering Label Switched Path (TE LSP), (b) the LSR forming a forwarding adjacency (FA) out of that LSP (by advertising this LSP as a Traffic Engineering (TE) link into the same instance of ISIS/OSPF as the one that was used to create the LSP), (c) allowing other LSRs to use FAs for their path computation, and (d) nesting of LSPs originated by other LSRs into that LSP (by using the label stack construct).
RFC4205 - Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)
This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). This memo provides information for the Internet community.
RFC4204 - Link Management Protocol (LMP)
For scalability purposes, multiple data links can be combined to form a single traffic engineering (TE) link. Furthermore, the management of TE links is not restricted to in-band messaging, but instead can be done using out-of-band techniques. This document specifies a link management protocol (LMP) that runs between a pair of nodes and is used to manage TE links. Specifically, LMP will be used to maintain control channel connectivity, verify the physical connectivity of the data links, correlate the link property information, suppress downstream alarms, and localize link failures for protection/restoration purposes in multiple kinds of networks. [STANDARDS-TRACK]
RFC4203 - OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)
This document specifies encoding of extensions to the OSPF routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). [STANDARDS-TRACK]
RFC4202 - Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)
This document specifies routing extensions in support of carrying link state information for Generalized Multi-Protocol Label Switching (GMPLS). This document enhances the routing extensions required to support MPLS Traffic Engineering (TE). [STANDARDS-TRACK]
RFC4201 - Link Bundling in MPLS Traffic Engineering (TE)
For the purpose of Generalized Multi-Protocol Label Switching (GMPLS) signaling, in certain cases a combination of <link identifier, label> is not sufficient to unambiguously identify the appropriate resource used by a Label Switched Path (LSP). Such cases are handled by using the link bundling construct, which is described in this document. This document updates the interface identification TLVs, which are defined in the GMPLS Signaling Functional Description. [STANDARDS-TRACK]
RFC4198 - A Uniform Resource Name (URN) Namespace for Federated Content
This document describes a URN (Uniform Resource Name) namespace for identifying content resources within federated content collections. A federated content collection often does not have a strong centralized authority but relies upon shared naming, metadata, and access conventions to provide interoperability among its members. This memo provides information for the Internet community.
RFC4197 - Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks
This document defines the specific requirements for edge-to-edge emulation of circuits carrying Time Division Multiplexed (TDM) digital signals of the Plesiochronous Digital Hierarchy as well as the Synchronous Optical NETwork/Synchronous Digital Hierarchy over packet-switched networks. It is aligned to the common architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3). It makes references to the generic requirements for PWE3 where applicable and complements them by defining requirements originating from specifics of TDM circuits. This memo provides information for the Internet community.
RFC4196 - The SEED Cipher Algorithm and Its Use with IPsec
This document describes the use of the SEED block cipher algorithm in the Cipher Block Chaining Mode, with an explicit IV, as a confidentiality mechanism within the context of the IPsec Encapsulating Security Payload (ESP). [STANDARDS-TRACK]
RFC4195 - A Uniform Resource Name (URN) Namespace for the TV-Anytime Forum
This document describes a Uniform Resource Name (URN) namespace that is engineered by the TV-Anytime Forum for naming persistent resources published by the TV-Anytime Forum including the TV-Anytime Forum Standards, XML (Extensible Markup Language) Document Type Definitions, XML Schemas, Namespaces, and other documents. This memo provides information for the Internet community.
RFC4194 - The S Hexdump Format
This document specifies the S Hexdump Format (SHF), a new, XML-based open format for describing binary data in hexadecimal notation. SHF provides the ability to describe both small and large, simple and complex hexadecimal data dumps in an open, modern, transport- and vendor-neutral format. [STANDARDS-TRACK]
RFC4193 - Unique Local IPv6 Unicast Addresses
This document defines an IPv6 unicast address format that is globally unique and is intended for local communications, usually inside of a site. These addresses are not expected to be routable on the global Internet. [STANDARDS-TRACK]
RFC4192 - Procedures for Renumbering an IPv6 Network without a Flag Day
This document describes a procedure that can be used to renumber a network from one prefix to another. It uses IPv6's intrinsic ability to assign multiple addresses to a network interface to provide continuity of network service through a "make-before-break" transition, as well as addresses naming and configuration management issues. It also uses other IPv6 features to minimize the effort and time required to complete the transition from the old prefix to the new prefix. This memo provides information for the Internet community.
RFC4191 - Default Router Preferences and More-Specific Routes
This document describes an optional extension to Router Advertisement messages for communicating default router preferences and more-specific routes from routers to hosts. This improves the ability of hosts to pick an appropriate router, especially when the host is multi-homed and the routers are on different links. The preference values and specific routes advertised to hosts require administrative configuration; they are not automatically derived from routing tables. [STANDARDS-TRACK]