| |
| RFC 4201 | 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&rt; 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. |
|
| |
| RFC 4202 | 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). |
|
| |
| RFC 4203 | 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). |
|
| |
| RFC 4204 | 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. |
|
| |
| RFC 4205 | 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). |
|
| |
| RFC 4206 | 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 TrafficEngineering 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).
This document describes the mechanisms to accomplish this. |
|
| |
| RFC 4207 | Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages |
| |
| Authors: | J. Lang, D. Papadimitriou. |
| Date: | October 2005 |
| Formats: | txt json html |
| Updated by: | RFC 6898 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4207 |
|
This document details the Synchronous Optical Network(SONET)/Synchronous Digital Hierarchy (SDH) technology-specific information needed when sending Link Management Protocol (LMP) test messages. |
|
| |
| RFC 4208 | Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model |
| |
| Authors: | G. Swallow, J. Drake, H. Ishimatsu, Y. Rekhter. |
| Date: | October 2005 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4208 |
|
Generalized Multiprotocol Label Switching (GMPLS) defines both routing and signaling protocols for the creation of Label SwitchedPaths (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. |
|
| |
| RFC 4209 | Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems |
| |
| Authors: | A. Fredette, Ed., J. Lang, Ed.. |
| Date: | October 2005 |
| Formats: | txt html json |
| Updated by: | RFC 6898 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4209 |
|
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 InterfaceRequirements" described in a companion document. |
|
| |
| RFC 4210 | 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. |
|
| |
| RFC 4211 | 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 aRegistration 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. |
|
| |
| RFC 4212 | Alternative Certificate Formats for the Public-Key Infrastructure Using X.509 (PKIX) Certificate Management Protocols |
| |
| Authors: | M. Blinov, C. Adams. |
| Date: | October 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4212 |
|
The Public-Key Infrastructure using X.509 (PKIX) Working Group of theInternet 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 CertificateManagement Messages over CMS (CMC). |
|
| |
| RFC 4213 | Basic Transition Mechanisms for IPv6 Hosts and Routers |
| |
| Authors: | E. Nordmark, R. Gilligan. |
| Date: | October 2005 |
| Formats: | txt json html |
| Obsoletes: | RFC 2893 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4213 |
|
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 carryIPv6 packets over unmodified IPv4 routing infrastructures.
This document obsoletes RFC 2893. |
|
| |
| RFC 4214 | Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) |
| |
| Authors: | F. Templin, T. Gleeson, M. Talwar, D. Thaler. |
| Date: | October 2005 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5214 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4214 |
|
The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connectsIPv6 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. |
|
| |
| RFC 4215 | Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks |
| |
| Authors: | J. Wiljakka, Ed.. |
| Date: | October 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4215 |
|
This document analyzes the transition to IPv6 in Third GenerationPartnership 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 MobileCommunications (GSM) or Universal Mobile Telecommunications System(UMTS)/Wideband Code Division Multiple Access (WCDMA) technology.
The focus is on analyzing different transition scenarios and applicable transition mechanisms and finding solutions for those transition scenarios. In these scenarios, the User Equipment (UE) connects to other nodes, e.g., in the Internet, and IPv6/IPv4 transition mechanisms are needed. |
|
| |
| RFC 4216 | MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements |
| |
| Authors: | R. Zhang, Ed., J.-P. Vasseur, Ed.. |
| Date: | November 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4216 |
|
This document discusses requirements for the support of inter-AS MPLSTraffic 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. |
|
| |
| RFC 4217 | 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 SecurityExtensions". 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 SecureSMTP over Transport Layer Security", and HTTP in RFC 2817, "Upgrading to TLS Within HTTP/1.1.".
This specification is in accordance with RFC 959, "File TransferProtocol". It relies on RFC 2246, "The TLS Protocol Version 1.0.", and RFC 2228, "FTP Security Extensions". |
|
| |
| RFC 4218 | Threats Relating to IPv6 Multihoming Solutions |
| |
| Authors: | E. Nordmark, T. Li. |
| Date: | October 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4218 |
|
This document lists security threats related to IPv6 multihoming.Multihoming can introduce new opportunities to redirect packets to different, unintended IP addresses.
The intent is to look at how IPv6 multihoming solutions might make the Internet less secure; we examine threats that are inherent to allIPv6 multihoming solutions rather than study any specific proposed solution. The threats in this document build upon the threats discovered and discussed as part of the Mobile IPv6 work. |
|
| |
| RFC 4219 | Things Multihoming in IPv6 (MULTI6) Developers Should Think About |
| |
| Authors: | E. Lear. |
| Date: | October 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4219 |
|
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. |
|
| |
| RFC 4220 | Traffic Engineering Link Management Information Base |
| |
| Authors: | M. Dubuc, T. Nadeau, J. Lang. |
| Date: | November 2005 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4220 |
|
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. |
|
| |
| RFC 4221 | Multiprotocol Label Switching (MPLS) Management Overview |
| |
| Authors: | T. Nadeau, C. Srinivasan, A. Farrel. |
| Date: | November 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4221 |
|
A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects ofMultiprotocol 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.
This document describes the management architecture for MPLS and indicates the interrelationships between the different MIB modules used for MPLS network management. |
|
| |
| RFC 4222 | 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 PathFirst (OSPF) Version 2 protocol. The methods include processing OSPFHellos and Link State Advertisement (LSA) Acknowledgments at a higher priority compared to other OSPF packets, and other congestion avoidance procedures. |
|
| |
| RFC 4223 | 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 obsoletesRFC 1863. |
|
| |
| RFC 4224 | RObust Header Compression (ROHC): ROHC over Channels That Can Reorder Packets |
| |
| Authors: | G. Pelletier, L-E. Jonsson, K. Sandlund. |
| Date: | January 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4224 |
|
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 RFC3095 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. |
|
| |
| RFC 4225 | Mobile IP Version 6 Route Optimization Security Design Background |
| |
| Authors: | P. Nikander, J. Arkko, T. Aura, G. Montenegro, E. Nordmark. |
| Date: | December 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4225 |
|
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.
The document has two target audiences: (1) helping MIPv6 implementors to better understand the design choices in MIPv6 security procedures, and (2) allowing people dealing with mobility or multi-homing to avoid a number of potential security pitfalls in their designs. |
|
| |
| RFC 4226 | HOTP: An HMAC-Based One-Time Password Algorithm |
| |
| Authors: | D. M'Raihi, M. Bellare, F. Hoornaert, D. Naccache, O. Ranen. |
| Date: | December 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4226 |
|
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.
This work is a joint effort by the OATH (Open AuTHentication) membership to specify an algorithm that can be freely distributed to the technical community. The authors believe that a common and shared algorithm will facilitate adoption of two-factor authentication on the Internet by enabling interoperability across commercial and open-source implementations. |
|
| |
| RFC 4227 | 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.
The SOAP is an XML-based (eXtensible Markup Language) messaging protocol used to implement a wide variety of distributed messaging models. It defines a message format and describes a variety of message patterns, including, but not limited to, Remote ProcedureCalling (RPC), asynchronous event notification, unacknowledged messages, and forwarding via SOAP intermediaries. |
|
| |
| RFC 4228 | Requirements for an IETF Draft Submission Toolset |
| |
| Authors: | A. Rousskov. |
| Date: | December 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4228 |
|
This document specifies requirements for an IETF toolset to facilitate Internet-Draft submission, validation, and posting. |
|
| |
| RFC 4229 | HTTP Header Field Registrations |
| |
| Authors: | M. Nottingham, J. Mogul. |
| Date: | December 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4229 |
|
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. |
|
| |
| RFC 4230 | RSVP Security Properties |
| |
| Authors: | H. Tschofenig, R. Graveman. |
| Date: | December 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4230 |
|
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. |
|
| |
| RFC 4231 | Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 |
| |
| Authors: | M. Nystrom. |
| Date: | December 2005 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4231 |
|
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 UniformResource Identifiers (URIs) to identify use of these schemes in protocols. The test vectors provided in this document may be used for conformance testing. |
|
| |
| RFC 4233 | Integrated Services Digital Network (ISDN) Q.921-User Adaptation Layer |
| |
| Authors: | K. Morneault, S. Rengasami, M. Kalla, G. Sidebottom. |
| Date: | January 2006 |
| Formats: | txt json html |
| Obsoletes: | RFC 3057 |
| Updated by: | RFC 5133 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4233 |
|
This document defines a protocol for backhauling of IntegratedServices Digital Network (ISDN) Q.921 User messages over IP using theStream 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.
This document obsoletes RFC 3057. |
|
| |
| RFC 4234 | 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 manyInternet specifications. The current specification documents ABNF.It balances compactness and simplicity, with reasonable representational power. The differences between standard BNF andABNF 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. |
|
| |
| RFC 4235 | 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. |
|
| |
| RFC 4236 | HTTP Adaptation with Open Pluggable Edge Services (OPES) |
| |
| Authors: | A. Rousskov, M. Stecher. |
| Date: | November 2005 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4236 |
|
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. |
|
| |
| RFC 4237 | Voice Messaging Directory Service |
| |
| Authors: | G. Vaudreuil. |
| Date: | October 2005 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4237 |
|
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.
The VPIM directory Schema provides essential additional attributes to recreate the voice mail user experience using standardized directories. This user experience provides, at the time of addressing, basic assurances that the message will be delivered as intended. This document combines two earlier documents, one fromAnne Brown and one from Greg Vaudreuil, that define a voice messaging schema into a single working group submission. |
|
| |
| RFC 4238 | 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 theVoice Profile for Internet Mail (VPIM) Directory service to lookup aVPIM 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. |
|
| |
| RFC 4239 | Internet Voice Messaging (IVM) |
| |
| Authors: | S. McRae, G. Parsons. |
| Date: | November 2005 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4239 |
|
This document describes the carriage of voicemail messages overInternet mail as part of a unified messaging infrastructure.
The Internet Voice Messaging (IVM) concept described in this document is not a successor format to VPIM v2 (Voice Profile for Internet MailVersion 2), but rather an alternative specification for a different application. |
|
| |
| RFC 4240 | Basic Network Media Services with SIP |
| |
| Authors: | E. Burger, Ed., J. Van Dyke, A. Spitzer. |
| Date: | December 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4240 |
|
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.
This document describes a mechanism for providing an interoperable interface between Application Servers, which provide application services to SIP-based networks, and Media Servers, which provide the basic media processing building blocks. |
|
| |
| RFC 4241 | A Model of IPv6/IPv4 Dual Stack Internet Access Service |
| |
| Authors: | Y. Shirasaki, S. Miyakawa, T. Yamasaki, A. Takenouchi. |
| Date: | December 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4241 |
|
This memo is a digest of the user network interface specification ofNTT Communications' dual stack ADSL access service, which provide aIPv6/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 ofIPv6 DNS servers, and it specifies a way to deliver these parameters to Customer Premises Equipment (CPE) automatically. |
|
| |
| RFC 4242 | Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) |
| |
| Authors: | S. Venaas, T. Chown, B. Volz. |
| Date: | November 2005 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8415 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4242 |
|
This document describes a Dynamic Host Configuration Protocol forIPv6 (DHCPv6) option for specifying an upper bound for how long a client should wait before refreshing information retrieved fromDHCPv6. 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. |
|
| |
| RFC 4243 | Vendor-Specific Information Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option |
| |
| Authors: | M. Stapp, R. Johnson, T. Palaniappan. |
| Date: | December 2005 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4243 |
|
This memo defines a new Vendor-Specific Information suboption for theDynamic 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. |
|
| |
| RFC 4244 | An Extension to the Session Initiation Protocol (SIP) for Request History Information |
| |
|
|
This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. This document defines a new optional SIP header, History-Info, for capturing the history information in requests. |
|
| |
| RFC 4245 | High-Level Requirements for Tightly Coupled SIP Conferencing |
| |
| Authors: | O. Levin, R. Even. |
| Date: | November 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4245 |
|
This document examines a wide range of conferencing requirements for tightly coupled SIP conferences. Separate documents will map the requirements to existing protocol primitives, define new protocol extensions, and introduce new protocols as needed. Together, these documents will provide a guide for building interoperable SIP conferencing applications. |
|
| |
| RFC 4246 | International Standard Audiovisual Number (ISAN) URN Definition |
| |
| Authors: | M. Dolan. |
| Date: | February 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4246 |
|
The International Standard Audiovisual Number (ISAN) is a standard numbering system for the unique and international identification of audiovisual works. This document is the definition of the formalUniform Resource Name (URN) Namespace Identifier (NID) for ISAN. |
|
| |
| RFC 4247 | Requirements for Header Compression over MPLS |
| |
| Authors: | J. Ash, B. Goode, J. Hand, R. Zhang. |
| Date: | November 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4247 |
|
Voice over IP (VoIP) typically uses the encapsulation voice/RTP/UDP/IP. When MPLS labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an MPLS VPN, the packet header is typically 48 bytes, while the voice payload is often no more than 30 bytes, for example. Header compression can significantly reduce the overhead through various compression mechanisms, such as enhanced compressed RTP (ECRTP) and robust header compression (ROHC). We consider using MPLS to route compressed packets over an MPLS LabelSwitched Path (LSP) without compression/decompression cycles at each router. This approach can increase the bandwidth efficiency as well as processing scalability of the maximum number of simultaneous flows that use header compression at each router. In this document, we give a problem statement, goals and requirements, and an example scenario. |
|
| |
| RFC 4248 | The telnet URI Scheme |
| |
|
|
This document specifies the telnet Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track. |
|
| |
| RFC 4249 | Implementer-Friendly Specification of Message and MIME-Part Header Fields and Field Components |
| |
| Authors: | B. Lilly. |
| Date: | January 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4249 |
|
Implementation of generators and parsers of header fields requires certain information about those fields. Interoperability is most likely when all such information is explicitly provided by the technical specification of the fields. Lacking such explicit information, implementers may guess, and interoperability may suffer.This memo identifies information useful to implementers of header field generators and parsers. |
|
| |
| RFC 4250 | The Secure Shell (SSH) Protocol Assigned Numbers |
| |
|
|
This document defines the instructions to the IANA and the initial state of the IANA assigned numbers for the Secure Shell (SSH) protocol. It is intended only for the initialization of the IANA registries referenced in the set of SSH documents. |
|
| |
| RFC 4251 | The Secure Shell (SSH) Protocol Architecture |
| |
|
|
The Secure Shell (SSH) Protocol is a protocol for secure remote login and other secure network services over an insecure network. This document describes the architecture of the SSH protocol, as well as the notation and terminology used in SSH protocol documents. It also discusses the SSH algorithm naming system that allows local extensions. The SSH protocol consists of three major components: TheTransport Layer Protocol provides server authentication, confidentiality, and integrity with perfect forward secrecy. TheUser Authentication Protocol authenticates the client to the server.The Connection Protocol multiplexes the encrypted tunnel into several logical channels. Details of these protocols are described in separate documents. |
|
| |
| RFC 4252 | The Secure Shell (SSH) Authentication Protocol |
| |
|
|
The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods.Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. |
|
| |
| RFC 4253 | The Secure Shell (SSH) Transport Layer Protocol |
| |
|
|
The Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network.
This document describes the SSH transport layer protocol, which typically runs on top of TCP/IP. The protocol can be used as a basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. It may also provide compression.
Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated.
This document also describes the Diffie-Hellman key exchange method and the minimal set of algorithms that are needed to implement theSSH transport layer protocol. |
|
| |
| RFC 4254 | The Secure Shell (SSH) Connection Protocol |
| |
| Authors: | T. Ylonen, C. Lonvick, Ed.. |
| Date: | January 2006 |
| Formats: | txt json html |
| Updated by: | RFC 8308 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4254 |
|
Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network.
This document describes the SSH Connection Protocol. It provides interactive login sessions, remote execution of commands, forwardedTCP/IP connections, and forwarded X11 connections. All of these channels are multiplexed into a single encrypted tunnel.
The SSH Connection Protocol has been designed to run on top of theSSH transport layer and user authentication protocols. |
|
| |
| RFC 4255 | Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints |
| |
| Authors: | J. Schlyter, W. Griffin. |
| Date: | January 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4255 |
|
This document describes a method of verifying Secure Shell (SSH) host keys using Domain Name System Security (DNSSEC). The document defines a new DNS resource record that contains a standard SSH key fingerprint. |
|
| |
| RFC 4256 | Generic Message Exchange Authentication for the Secure Shell Protocol (SSH) |
| |
| Authors: | F. Cusack, M. Forssen. |
| Date: | January 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4256 |
|
The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes a general purpose authentication method for theSSH protocol, suitable for interactive authentications where the authentication data should be entered via a keyboard (or equivalent alphanumeric input device). The major goal of this method is to allow the SSH client to support a whole class of authentication mechanism(s) without knowing the specifics of the actual authentication mechanism(s). |
|
| |
| RFC 4257 | Framework for Generalized Multi-Protocol Label Switching (GMPLS)-based Control of Synchronous Digital Hierarchy/Synchronous Optical Networking (SDH/SONET) Networks |
| |
| Authors: | G. Bernstein, E. Mannie, V. Sharma, E. Gray. |
| Date: | December 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4257 |
|
Generalized Multi-Protocol Label Switching (GMPLS) is a suite of protocol extensions to MPLS to make it generally applicable, to include, for example, control of non packet-based switching, and particularly, optical switching. One consideration is to use GMPLS protocols to upgrade the control plane of optical transport networks.This document illustrates this process by describing those extensions to GMPLS protocols that are aimed at controlling Synchronous DigitalHierarchy (SDH) or Synchronous Optical Networking (SONET) networks.SDH/SONET networks make good examples of this process for a variety of reasons. This document highlights extensions to GMPLS-related routing protocols to disseminate information needed in transport path computation and network operations, together with (G)MPLS protocol extensions required for the provisioning of transport circuits. New capabilities that an GMPLS control plane would bring to SDH/SONET networks, such as new restoration methods and multi-layer circuit establishment, are also discussed. |
|
| |
| RFC 4258 | Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON) |
| |
| Authors: | D. Brungard, Ed.. |
| Date: | November 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4258 |
|
The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting Time Division Multiplexing (TDM) connections including Synchronous Optical Network (SONET)/Synchronous DigitalHierarchy (SDH) and Optical Transport Networks (OTNs).
This document concentrates on the routing requirements placed on theGMPLS suite of protocols in order to support the capabilities and functionalities of an Automatically Switched Optical Network (ASON) as defined by the ITU-T. |
|
| |
| RFC 4259 | A Framework for Transmission of IP Datagrams over MPEG-2 Networks |
| |
| Authors: | M.-J. Montpetit, G. Fairhurst, H. Clausen, B. Collini-Nocker, H. Linder. |
| Date: | November 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4259 |
|
This document describes an architecture for the transport of IPDatagrams over ISO MPEG-2 Transport Streams (TS). The MPEG-2 TS has been widely accepted not only for providing digital TV services but also as a subnetwork technology for building IP networks. Examples of systems using MPEG-2 include the Digital Video Broadcast (DVB) andAdvanced Television Systems Committee (ATSC) Standards for DigitalTelevision.
The document identifies the need for a set of Internet standards defining the interface between the MPEG-2 Transport Stream and an IP subnetwork. It suggests a new encapsulation method for IP datagrams and proposes protocols to perform IPv6/IPv4 address resolution, to associate IP packets with the properties of the Logical Channels provided by an MPEG-2 TS. |
|
| |
| RFC 4260 | Mobile IPv6 Fast Handovers for 802.11 Networks |
| |
| Authors: | P. McCann. |
| Date: | November 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4260 |
|
This document describes how a Mobile IPv6 Fast Handover could be implemented on link layers conforming to the 802.11 suite of specifications. |
|
| |
| RFC 4261 | Common Open Policy Service (COPS) Over Transport Layer Security (TLS) |
| |
|
|
This document describes how to use Transport Layer Security (TLS) to secure Common Open Policy Service (COPS) connections over theInternet.
This document also updates RFC 2748 by modifying the contents of theClient-Accept message. |
|
| |
| RFC 4262 | X.509 Certificate Extension for Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities |
| |
| Authors: | S. Santesson. |
| Date: | December 2005 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4262 |
|
This document defines a certificate extension for inclusion ofSecure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities inX.509 public key certificates, as defined by RFC 3280. This certificate extension provides an optional method to indicate the cryptographic capabilities of an entity as a complement to the S/MIMECapabilities signed attribute in S/MIME messages according to RFC3851. |
|
| |
| RFC 4263 | Media Subtype Registration for Media Type text/troff |
| |
| Authors: | B. Lilly. |
| Date: | January 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4263 |
|
A text media subtype for tagging content consisting of juxtaposed text and formatting directives as used by the troff series of programs and for conveying information about the intended processing steps necessary to produce formatted output is described. |
|
| |
| RFC 4264 | BGP Wedgies |
| |
| Authors: | T. Griffin, G. Huston. |
| Date: | November 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4264 |
|
It has commonly been assumed that the Border Gateway Protocol (BGP) is a tool for distributing reachability information in a manner that creates forwarding paths in a deterministic manner. In this memo we will describe a class of BGP configurations for which there is more than one potential outcome, and where forwarding states other than the intended state are equally stable. Also, the stable state whereBGP converges may be selected by BGP in a non-deterministic manner.These stable, but unintended, BGP states are termed here "BGPWedgies". |
|
| |
| RFC 4265 | Definition of Textual Conventions for Virtual Private Network (VPN) Management |
| |
| Authors: | B. Schliesser, T. Nadeau. |
| Date: | November 2005 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4265 |
|
This document describes Textual Conventions used for managing VirtualPrivate Networks (VPNs). |
|
| |
| RFC 4266 | The gopher URI Scheme |
| |
|
|
This document specifies the gopher Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track. |
|
| |
| RFC 4267 | The W3C Speech Interface Framework Media Types: application/voicexml+xml, application/ssml+xml, application/srgs, application/srgs+xml, application/ccxml+xml, and application/pls+xml |
| |
| Authors: | M. Froumentin. |
| Date: | November 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4267 |
|
This document defines the media types for the languages of the W3CSpeech Interface Framework, as designed by the Voice Browser WorkingGroup in the following specifications: the Voice Extensible MarkupLanguage (VoiceXML), the Speech Synthesis Markup Language (SSML), theSpeech Recognition Grammar Specification (SRGS), the Call Control XML(CCXML), and the Pronunciation Lexicon Specification (PLS). |
|
| |
| RFC 4268 | Entity State MIB |
| |
| Authors: | S. Chisholm, D. Perkins. |
| Date: | November 2005 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4268 |
|
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 extensions to the Entity MIB to provide information about the state of physical entities.
In addition, this memo defines a set of Textual Conventions to represent various states of an entity. The intent is that theseTextual Conventions will be imported and used in MIB modules that would otherwise define their own representations. |
|
| |
| RFC 4269 | The SEED Encryption Algorithm |
| |
| Authors: | H.J. Lee, S.J. Lee, J.H. Yoon, D.H. Cheon, J.I. Lee. |
| Date: | December 2005 |
| Formats: | txt json html |
| Obsoletes: | RFC 4009 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4269 |
|
This document describes the SEED encryption algorithm, which has been adopted by most of the security systems in the Republic of Korea.Included are a description of the encryption and the key scheduling algorithm (Section 2), the S-boxes (Appendix A), and a set of test vectors (Appendix B).
This document obsoletes RFC 4009. |
|
| |
| RFC 4270 | Attacks on Cryptographic Hashes in Internet Protocols |
| |
| Authors: | P. Hoffman, B. Schneier. |
| Date: | November 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4270 |
|
Recent announcements of better-than-expected collision attacks in popular hash algorithms have caused some people to question whether common Internet protocols need to be changed, and if so, how. This document summarizes the use of hashes in many protocols, discusses how the collision attacks affect and do not affect the protocols, shows how to thwart known attacks on digital certificates, and discusses future directions for protocol designers. |
|
| |
| RFC 4271 | A Border Gateway Protocol 4 (BGP-4) |
| |
| Authors: | Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed.. |
| Date: | January 2006 |
| Formats: | txt json html |
| Obsoletes: | RFC 1771 |
| Updated by: | RFC 6286, RFC 6608, RFC 6793, RFC 7606, RFC 7607, RFC 7705, RFC 8212, RFC 8654, RFC 9072 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 4271 |
|
This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.
The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list ofAutonomous Systems (ASes) that reachability information traverses.This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.
BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation ofAS paths.
This document obsoletes RFC 1771. |
|
| |
| RFC 4272 | BGP Security Vulnerabilities Analysis |
| |
| Authors: | S. Murphy. |
| Date: | January 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4272 |
|
Border Gateway Protocol 4 (BGP-4), along with a host of other infrastructure protocols designed before the Internet environment became perilous, was originally designed with little consideration for protection of the information it carries. There are no mechanisms internal to BGP that protect against attacks that modify, delete, forge, or replay data, any of which has the potential to disrupt overall network routing behavior.
This document discusses some of the security issues with BGP routing data dissemination. This document does not discuss security issues with forwarding of packets. |
|
| |
| RFC 4273 | Definitions of Managed Objects for BGP-4 |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet communityIn particular, it describes managed objects used for managing theBorder Gateway Protocol Version 4 or lower.
The origin of this memo is from RFC 1269 "Definitions of ManagedObjects for the Border Gateway Protocol (Version 3)", which was updated to support BGP-4 in RFC 1657. This memo fixes errors introduced when the MIB module was converted to use the SMIv2 language. This memo also updates references to the current SNMP framework documents.
This memo is intended to document deployed implementations of thisMIB module in a historical context, to provide clarifications of some items, and to note errors where the MIB module fails to fully represent the BGP protocol. Work is currently in progress to replace this MIB module with a new one representing the current state of theBGP protocol and its extensions.
This document obsoletes RFC 1269 and RFC 1657. |
|
| |
| RFC 4274 | BGP-4 Protocol Analysis |
| |
| Authors: | D. Meyer, K. Patel. |
| Date: | January 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4274 |
|
The purpose of this report is to document how the requirements for publication of a routing protocol as an Internet Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4).
This report satisfies the requirement for "the second report", as described in Section 6.0 of RFC 1264. In order to fulfill the requirement, this report augments RFC 1774 and summarizes the key features of BGP-4, as well as analyzes the protocol with respect to scaling and performance. |
|
| |
| RFC 4275 | BGP-4 MIB Implementation Survey |
| |
| Authors: | S. Hares, D. Hares. |
| Date: | January 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4275 |
|
This document provides a survey of implementations of BGP-4 that support RFC 1657 MIB agents according to the BGP-4 v1 MIB specification. |
|
| |
| RFC 4276 | BGP-4 Implementation Report |
| |
| Authors: | S. Hares, A. Retana. |
| Date: | January 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4276 |
|
This document reports the results of the BGP-4 implementation survey.The survey had 259 questions about implementations' support of BGP-4 as specified in RFC 4271. After a brief summary of the results, each response is listed. This document contains responses from the four implementers that completed the survey (Alcatel, Cisco, Laurel, andNextHop) and brief information from three that did not (Avici, DataConnection Ltd., and Nokia).
The editors did not use exterior means to verify the accuracy of the information submitted by the respondents. The respondents are experts with the products they reported on. |
|
| |
| RFC 4277 | Experience with the BGP-4 Protocol |
| |
| Authors: | D. McPherson, K. Patel. |
| Date: | January 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4277 |
|
The purpose of this memo is to document how the requirements for publication of a routing protocol as an Internet Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4).
This report satisfies the requirement for "the second report", as described in Section 6.0 of RFC 1264. In order to fulfill the requirement, this report augments RFC 1773 and describes additional knowledge and understanding gained in the time between when the protocol was made a Draft Standard and when it was submitted forStandard. |
|
| |
| RFC 4278 | Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Specification |
| |
| Authors: | S. Bellovin, A. Zinin. |
| Date: | January 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4278 |
|
The IETF Standards Process requires that all normative references for a document be at the same or higher level of standardization. RFC2026 section 9.1 allows the IESG to grant a variance to the standard practices of the IETF. This document explains why the IESG is considering doing so for the revised version of the BGP-4 specification, which refers normatively to RFC 2385, "Protection ofBGP Sessions via the TCP MD5 Signature Option". RFC 2385 will remain at the Proposed Standard level. |
|
| |
| RFC 4279 | Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) |
| |
| Authors: | P. Eronen, Ed., H. Tschofenig, Ed.. |
| Date: | December 2005 |
| Formats: | txt json html |
| Updated by: | RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4279 |
|
This document specifies three sets of new ciphersuites for theTransport Layer Security (TLS) protocol to support authentication based on pre-shared keys (PSKs). These pre-shared keys are symmetric keys, shared in advance among the communicating parties. The first set of ciphersuites uses only symmetric key operations for authentication. The second set uses a Diffie-Hellman exchange authenticated with a pre-shared key, and the third set combines public key authentication of the server with pre-shared key authentication of the client. |
|
| |
| RFC 4280 | Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers |
| |
| Authors: | K. Chowdhury, P. Yegani, L. Madour. |
| Date: | November 2005 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4280 |
|
This document defines new options to discover the Broadcast andMulticast Service (BCMCS) controller in an IP network. BCMCS is being developed for Third generation (3G) cellular telephone networks. Users of the service interact with a controller in the network via the Mobile Node (MN) to derive information required to receive Broadcast and Multicast Service. Dynamic Host ConfigurationProtocol can be used to configure the MN to access a particular controller. This document defines the related options and option codes. |
|
| |
| RFC 4281 | The Codecs Parameter for "Bucket" Media Types |
| |
| Authors: | R. Gellens, D. Singer, P. Frojdh. |
| Date: | November 2005 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6381 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4281 |
|
Several MIME type/subtype combinations exist that can contain different media formats. A receiving agent thus needs to examine the details of such media content to determine if the specific elements can be rendered given an available set of codecs. Especially when the end system has limited resources, or the connection to the end system has limited bandwidth, it would be helpful to know from theContent-Type alone if the content can be rendered.
This document adds a new parameter, "codecs", to various type/subtype combinations to allow for unambiguous specification of the codecs indicated by the media formats contained within.
By labeling content with the specific codecs indicated to render the contained media, receiving systems can determine if the codecs are supported by the end system, and if not, can take appropriate action(such as rejecting the content, sending notification of the situation, transcoding the content to a supported type, fetching and installing the required codecs, further inspection to determine if it will be sufficient to support a subset of the indicated codecs, etc.) |
|
| |
| RFC 4282 | The Network Access Identifier |
| |
| Authors: | B. Aboba, M. Beadles, J. Arkko, P. Eronen. |
| Date: | December 2005 |
| Formats: | txt html json |
| Obsoletes: | RFC 2486 |
| Obsoleted by: | RFC 7542 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4282 |
|
In order to provide roaming services, it is necessary to have a standardized method for identifying users. This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client during network authentication. "Roaming" may be loosely defined as the ability to use any one of multiple InternetService Providers (ISPs), while maintaining a formal, customer-vendor relationship with only one. Examples of where roaming capabilities might be required include ISP "confederations" and ISP-provided corporate network access support. This document is a revised version of RFC 2486, which originally defined NAIs. Enhancements include international character set and privacy support, as well as a number of corrections to the original RFC. |
|
| |
| RFC 4283 | Mobile Node Identifier Option for Mobile IPv6 (MIPv6) |
| |
| Authors: | A. Patel, K. Leung, M. Khalil, H. Akhtar, K. Chowdhury. |
| Date: | November 2005 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4283 |
|
Mobile IPv6 (MIPv6) defines a new Mobility header that is used by mobile nodes, correspondent nodes, and home agents in all messaging related to the creation and management of bindings. Mobile IPv6 nodes need the capability to identify themselves using an identity other than the default home IP address. Some examples of identifiers include Network Access Identifier (NAI), Fully Qualified Domain Name(FQDN), International Mobile Station Identifier (IMSI), and MobileSubscriber Number (MSISDN). This document defines a new mobility option that can be used by Mobile IPv6 entities to identify themselves in messages containing a mobility header. |
|
| |
| RFC 4284 | Identity Selection Hints for the Extensible Authentication Protocol (EAP) |
| |
| Authors: | F. Adrangi, V. Lortz, F. Bari, P. Eronen. |
| Date: | January 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4284 |
|
The Extensible Authentication Protocol (EAP) is defined in RFC 3748.This document defines a mechanism that allows an access network to provide identity selection hints to an EAP peer -- the end of the link that responds to the authenticator. The purpose is to assist the EAP peer in selecting an appropriate Network Access Identifier(NAI). This is useful in situations where the peer does not receive a lower-layer indication of what network it is connecting to, or when there is no direct roaming relationship between the access network and the peer's home network. In the latter case, authentication is typically accomplished via a mediating network such as a roaming consortium or broker.
The mechanism defined in this document is limited in its scalability.It is intended for access networks that have a small to moderate number of direct roaming partners. |
|
| |
| RFC 4285 | Authentication Protocol for Mobile IPv6 |
| |
| Authors: | A. Patel, K. Leung, M. Khalil, H. Akhtar, K. Chowdhury. |
| Date: | January 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4285 |
|
IPsec is specified as the means of securing signaling messages between the Mobile Node and Home Agent for Mobile IPv6 (MIPv6).MIPv6 signaling messages that are secured include the Binding Updates and Acknowledgement messages used for managing the bindings between aMobile Node and its Home Agent. This document proposes an alternate method for securing MIPv6 signaling messages between Mobile Nodes andHome Agents. The alternate method defined here consists of aMIPv6-specific mobility message authentication option that can be added to MIPv6 signaling messages. |
|
| |
| RFC 4286 | Multicast Router Discovery |
| |
| Authors: | B. Haberman, J. Martin. |
| Date: | December 2005 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4286 |
|
The concept of Internet Group Management Protocol (IGMP) andMulticast Listener Discovery (MLD) snooping requires the ability to identify the location of multicast routers. Since snooping is not standardized, there are many mechanisms in use to identify the multicast routers. However, this can lead to interoperability issues between multicast routers and snooping switches from different vendors.
This document introduces a general mechanism that allows for the discovery of multicast routers. This new mechanism, Multicast RouterDiscovery (MRD), introduces a standardized means of identifying multicast routers without a dependency on particular multicast routing protocols. |
|
| |
| RFC 4287 | The Atom Syndication Format |
| |
| Authors: | M. Nottingham, Ed., R. Sayre, Ed.. |
| Date: | December 2005 |
| Formats: | txt html json |
| Updated by: | RFC 5988 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4287 |
|
This document specifies Atom, an XML-based Web content and metadata syndication format. |
|
| |
| RFC 4288 | Media Type Specifications and Registration Procedures |
| |
|
|
This document defines procedures for the specification and registration of media types for use in MIME and other Internet protocols. |
|
| |
| RFC 4289 | Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures |
| |
|
|
This document specifies IANA registration procedures for MIME external body access types and content-transfer-encodings. |
|
| |
| RFC 4290 | Suggested Practices for Registration of Internationalized Domain Names (IDN) |
| |
| Authors: | J. Klensin. |
| Date: | December 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4290 |
|
This document explores the issues in the registration of internationalized domain names (IDNs). The basic IDN definition allows a very large number of possible characters in domain names, and this richness may lead to serious user confusion about similar- looking names. To avoid this confusion, the IDN registration process must impose rules that disallow some otherwise-valid name combinations. This document suggests a set of mechanisms that registries might use to define and implement such rules for a broad range of languages, including adaptation of methods developed forChinese, Japanese, and Korean domain names. |
|
| |
| RFC 4291 | IP Version 6 Addressing Architecture |
| |
|
|
This specification defines the addressing architecture of the IPVersion 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and anIPv6 node's required addresses.
This document obsoletes RFC 3513, "IP Version 6 AddressingArchitecture". |
|
| |
| RFC 4292 | IP Forwarding Table MIB |
| |
|
|
This document 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 related to the forwarding of Internet Protocol (IP) packets in an IP version- independent manner. This document obsoletes RFC 2096. |
|
| |
| RFC 4293 | Management Information Base for the Internet Protocol (IP) |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects used for implementations of the Internet Protocol (IP) in an IP version independent manner.This memo obsoletes RFCs 2011, 2465, and 2466. |
|
| |
| RFC 4294 | IPv6 Node Requirements |
| |
|
|
This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations.Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. |
|
| |
| RFC 4295 | Mobile IPv6 Management Information Base |
| |
| Authors: | G. Keeni, K. Koide, K. Nagami, S. Gundavelli. |
| Date: | April 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4295 |
|
This memo defines a portion of the Management Information Base (MIB), the Mobile-IPv6 MIB, for use with network management protocols in theInternet community. In particular, the Mobile-IPv6 MIB will be used to monitor and control the mobile node, home agent, and correspondent node functions of a Mobile IPv6 (MIPv6) entity. |
|
| |
| RFC 4296 | The Architecture of Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) on Internet Protocols |
| |
| Authors: | S. Bailey, T. Talpey. |
| Date: | December 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4296 |
|
This document defines an abstract architecture for Direct DataPlacement (DDP) and Remote Direct Memory Access (RDMA) protocols to run on Internet Protocol-suite transports. This architecture does not necessarily reflect the proper way to implement such protocols, but is, rather, a descriptive tool for defining and understanding the protocols. DDP allows the efficient placement of data into buffers designated by Upper Layer Protocols (e.g., RDMA). RDMA provides the semantics to enable Remote Direct Memory Access between peers in a way consistent with application requirements. |
|
| |
| RFC 4297 | Remote Direct Memory Access (RDMA) over IP Problem Statement |
| |
| Authors: | A. Romanow, J. Mogul, T. Talpey, S. Bailey. |
| Date: | December 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4297 |
|
Overhead due to the movement of user data in the end-system networkI/O processing path at high speeds is significant, and has limited the use of Internet protocols in interconnection networks, and theInternet itself -- especially where high bandwidth, low latency, and/or low overhead are required by the hosted application.
This document examines this overhead, and addresses an architectural,IP-based "copy avoidance" solution for its elimination, by enablingRemote Direct Memory Access (RDMA). |
|
| |
| RFC 4298 | RTP Payload Format for BroadVoice Speech Codecs |
| |
| Authors: | J.-H. Chen, W. Lee, J. Thyssen. |
| Date: | December 2005 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4298 |
|
This document describes the RTP payload format for the BroadVoice(R) narrowband and wideband speech codecs. The narrowband codec, calledBroadVoice16, or BV16, has been selected by CableLabs as a mandatory codec in PacketCable 1.5 and has a CableLabs specification. The document also provides specifications for the use of BroadVoice withMIME and the Session Description Protocol (SDP). |
|
