Internet Society Frontpage

Search/Site Map Membership
About the Internet Standards
Publications Public Policy
About ISOC Education

Publications 

Become an ISOC Member

Internet Documents

RFCs 4900 - 4999s

RFCs All DocumentsSTDs Internet Standards DocumentsBCPs Best Current Practice DocumentsFYIs Informational Documents
 

 
RFC 4901 Protocol Extensions for Header Compression over MPLS
 
Authors:J. Ash, Ed., J. Hand, Ed., A. Malis, Ed..
Date:June 2007
Formats:txt pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4901
This specification defines how to use Multi-Protocol Label Switching(MPLS) to route Header-Compressed (HC) packets over an MPLS label switched path. HC can significantly reduce packet-header overhead and, in combination with MPLS, can also increases bandwidth efficiency and processing scalability in terms of the maximum number of simultaneous compressed flows that use HC at each router). Here we define how MPLS pseudowires are used to transport the HC context and control messages between the ingress and egress MPLS label switching routers. This is defined for a specific set of existing HC mechanisms that might be used, for example, to support voice over IP.This specification also describes extension mechanisms to allow support for future, as yet to be defined, HC protocols. In this specification, each HC protocol operates independently over a single pseudowire instance, very much as it would over a single point-to- point link.
 
RFC 4902 Integrity, Privacy, and Security in Open Pluggable Edge Services (OPES) for SMTP
 
Authors:M. Stecher.
Date:May 2007
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 4902
The Open Pluggable Edge Services (OPES) framework is application agnostic. Application-specific adaptations extend that framework.Previous work has focused on HTTP and work for SMTP is in progress.These protocols differ fundamentally in the way data flows, and it turns out that existing OPES requirements and IAB considerations forOPES need to be reviewed with regards to how well they fit for SMTP adaptation. This document analyzes aspects about the integrity ofSMTP and mail message adaptation by OPES systems and about privacy and security issues when the OPES framework is adapted to SMTP. It also lists requirements that must be considered when creating the"SMTP adaptation with OPES" document.

The intent of this document is to capture this information before the current OPES working group shuts down. This is to provide input for subsequent working groups or individual contributors that may pick up the OPES/SMTP work at a later date.

 
RFC 4903 Multi-Link Subnet Issues
 
Authors:D. Thaler.
Date:June 2007
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 4903
There have been several proposals around the notion that a subnet may span multiple links connected by routers. This memo documents the issues and potential problems that have been raised with such an approach.
 
RFC 4904 Representing Trunk Groups in tel/sip Uniform Resource Identifiers (URIs)
 
Authors:V. Gurbani, C. Jennings.
Date:June 2007
Formats:txt pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4904
This document describes a standardized mechanism to convey trunk group parameters in sip and tel Uniform Resource Identifiers (URIs).An extension to the tel URI is defined for this purpose.
 
RFC 4905 Encapsulation Methods for Transport of Layer 2 Frames over MPLS Networks
 
Authors:L. Martini, Ed., E. Rosen, Ed., N. El-Aawar, Ed..
Date:June 2007
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 4905
This document describes methods for encapsulating the Protocol DataUnits (PDUs) of layer 2 protocols such as Frame Relay, AsynchronousTransfer Mode (ATM), or Ethernet for transport across an MPLS network. This document describes the so-called "draft-martini" protocol, which has since been superseded by the Pseudowire EmulationEdge to Edge Working Group specifications described in RFC 4447 and related documents.
 
RFC 4906 Transport of Layer 2 Frames Over MPLS
 
Authors:L. Martini, Ed., E. Rosen, Ed., N. El-Aawar, Ed..
Date:June 2007
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 4906
This document describes methods for transporting the Protocol DataUnits (PDUs) of layer 2 protocols such as Frame Relay, AsynchronousTransfer Mode (ATM) Adaption Layer 5 (AAL5), and Ethernet, and for providing a Synchronized Optical Network (SONET) circuit emulation service across an MPLS network. This document describes the so- called "draft-martini" protocol, which has since been superseded by the Pseudowire Emulation Edge to Edge Working Group specifications described in RFC 4447 and related documents.
 
RFC 4907 Architectural Implications of Link Indications
 
Authors:B. Aboba, Ed..
Date:June 2007
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 4907
A link indication represents information provided by the link layer to higher layers regarding the state of the link. This document describes the role of link indications within the Internet architecture. While the judicious use of link indications can provide performance benefits, inappropriate use can degrade both robustness and performance. This document summarizes current proposals, describes the architectural issues, and provides examples of appropriate and inappropriate uses of link indications.
 
RFC 4908 Multi-homing for small scale fixed network Using Mobile IP and NEMO
 
Authors:K. Nagami, S. Uda, N. Ogashiwa, H. Esaki, R. Wakikawa, H. Ohnishi.
Date:June 2007
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4908
Multihoming technology improves the availability of host and network connectivity. Since the behaviors of fixed and mobile networks differ, distinct architectures for each have been discussed and proposed. This document proposes a common architecture for both mobile and fixed networking environments, using mobile IP (RFC 3775) and Network Mobility (NEMO; RFC 3963). The proposed architecture requires a modification of mobile IP and NEMO so that multiple Care- of Addresses (CoAs) can be used. In addition, multiple Home Agents(HAs) that are located in different places are required for redundancy.
 
RFC 4909 Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST LTKM/STKM Transport
 
Authors:L. Dondeti, Ed., D. Castleford, F. Hartung.
Date:June 2007
Formats:txt pdf
Obsoleted by:RFC 5410, RFC 6309
Status:INFORMATIONAL
DOI:10.17487/RFC 4909
This document specifies a new Multimedia Internet KEYing (MIKEY)General Extension payload (RFC 3830) to transport the short-term key message (STKM) and long-term key message (LTKM) payloads defined in the Open Mobile Alliance's (OMA) Browser and Content (BAC) Broadcast(BCAST) group's Service and Content protection specification.
 
RFC 4910 Robust XML Encoding Rules (RXER) for Abstract Syntax Notation One (ASN.1)
 
Authors:S. Legg, D. Prager.
Date:July 2007
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4910
This document defines a set of Abstract Syntax Notation One (ASN.1) encoding rules, called the Robust XML Encoding Rules or RXER, that produce an Extensible Markup Language (XML) representation for values of any given ASN.1 data type. Rules for producing a canonical RXER encoding are also defined.
 
RFC 4911 Encoding Instructions for the Robust XML Encoding Rules (RXER)
 
Authors:S. Legg.
Date:July 2007
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4911
This document defines encoding instructions that may be used in anAbstract Syntax Notation One (ASN.1) specification to alter how ASN.1 values are encoded by the Robust XML Encoding Rules (RXER) andCanonical Robust XML Encoding Rules (CRXER), for example, to encode a component of an ASN.1 value as an Extensible Markup Language (XML) attribute rather than as a child element. Some of these encoding instructions also affect how an ASN.1 specification is translated into an Abstract Syntax Notation X (ASN.X) specification. Encoding instructions that allow an ASN.1 specification to reference definitions in other XML schema languages are also defined.
 
RFC 4912 Abstract Syntax Notation X (ASN.X)
 
Authors:S. Legg.
Date:July 2007
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4912
Abstract Syntax Notation X (ASN.X) is a semantically equivalentExtensible Markup Language (XML) representation for Abstract SyntaxNotation One (ASN.1) specifications. ASN.X completely avoids the numerous ambiguities inherent in the ASN.1 language; therefore, specifications written in ASN.X are much easier to parse and manage than original ASN.1 specifications. ASN.X, together with the RobustXML Encoding Rules (RXER), constitutes a schema language for XML documents that offers, through other ASN.1 encoding rules, alternative compact binary encodings for XML instance documents.
 
RFC 4913 Abstract Syntax Notation X (ASN.X) Representation of Encoding Instructions for the Generic String Encoding Rules (GSER)
 
Authors:S. Legg.
Date:July 2007
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4913
Abstract Syntax Notation X (ASN.X) is an Extensible Markup Language(XML) representation for Abstract Syntax Notation One (ASN.1) specifications. This document specifies the ASN.X representation of encoding instructions for the Generic String Encoding Rules (GSER).
 
RFC 4914 Abstract Syntax Notation X (ASN.X) Representation of Encoding Instructions for the XML Encoding Rules (XER)
 
Authors:S. Legg.
Date:July 2007
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4914
Abstract Syntax Notation X (ASN.X) is an Extensible Markup Language(XML) representation for Abstract Syntax Notation One (ASN.1) specifications. This document specifies the ASN.X representation of encoding instructions for the XML Encoding Rules (XER).
 
RFC 4915 Multi-Topology (MT) Routing in OSPF
 
Authors:P. Psenak, S. Mirtorabi, A. Roy, L. Nguyen, P. Pillay-Esnault.
Date:June 2007
Formats:txt pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4915
This document describes an extension to Open Shortest Path First(OSPF) in order to define independent IP topologies called Multi-Topologies (MTs). The Multi-Topologies extension can be used for computing different paths for unicast traffic, multicast traffic, different classes of service based on flexible criteria, or an in- band network management topology.

An optional extension to exclude selected links from the default topology is also described.

 
RFC 4916 Connected Identity in the Session Initiation Protocol (SIP)
 
Authors:J. Elwell.
Date:June 2007
Formats:txt pdf
Updates:RFC 3261
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4916
This document provides a means for a Session Initiation Protocol(SIP) User Agent (UA) that receives a dialog-forming request to supply its identity to the peer UA by means of a request in the reverse direction, and for that identity to be signed by anAuthentication Service. Because of retargeting of a dialog-forming request (changing the value of the Request-URI), the UA that receives it (the User Agent Server, UAS) can have a different identity from that in the To header field. The same mechanism can be used to indicate a change of identity during a dialog, e.g., because of some action in the Public Switched Telephone Network (PSTN) behind a gateway. This document normatively updates RFC 3261 (SIP).
 
RFC 4917 Mobile IPv4 Message String Extension
 
Authors:V. Sastry, K. Leung, A. Patel.
Date:June 2007
Formats:txt pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4917
This document specifies a new extension for use in Mobile IPv4. This extension can be added by the Home Agent and the Foreign Agent toRegistration Reply messages. This extension carries a text string that is intended for the user of the Mobile Node.
 
RFC 4918 HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)
 
Authors:L. Dusseault, Ed..
Date:June 2007
Formats:txt pdf
Obsoletes:RFC 2518
Updated by:RFC 5689
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4918
Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).

RFC 2518 was published in February 1999, and this specification obsoletes RFC 2518 with minor revisions mostly due to interoperability experience.

 
RFC 4919 IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals
 
Authors:N. Kushalnagar, G. Montenegro, C. Schumacher.
Date:August 2007
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 4919
This document describes the assumptions, problem statement, and goals for transmitting IP over IEEE 802.15.4 networks. The set of goals enumerated in this document form an initial set only.
 
RFC 4920 Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE
 
Authors:A. Farrel, Ed., A. Satyanarayana, A. Iwata, N. Fujita, G. Ash.
Date:July 2007
Formats:txt pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4920
In a distributed, constraint-based routing environment, the information used to compute a path may be out of date. This means that Multiprotocol Label Switching (MPLS) and Generalized MPLS(GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) setup requests may be blocked by links or nodes without sufficient resources. Crankback is a scheme whereby setup failure information is returned from the point of failure to allow new setup attempts to be made avoiding the blocked resources. Crankback can also be applied to LSP recovery to indicate the location of the failed link or node.

This document specifies crankback signaling extensions for use inMPLS signaling using RSVP-TE as defined in "RSVP-TE: Extensions toRSVP for LSP Tunnels", RFC 3209, and GMPLS signaling as defined in"Generalized Multi-Protocol Label Switching (GMPLS) SignalingFunctional Description", RFC 3473. These extensions mean that theLSP setup request can be retried on an alternate path that detours around blocked links or nodes. This offers significant improvements in the successful setup and recovery ratios for LSPs, especially in situations where a large number of setup requests are triggered at the same time.

 
RFC 4923 Quality of Service (QoS) Signaling in a Nested Virtual Private Network
 
Authors:F. Baker, P. Bose.
Date:August 2007
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 4923
Some networks require communication between an interior and exterior portion of a Virtual Private Network (VPN) or through a concatenation of such networks resulting in a nested VPN, but have sensitivities about what information is communicated across the boundary, especially while providing quality of service to communications with different precedence. This note seeks to outline the issues and the nature of the proposed solutions based on the framework forIntegrated Services operation over Diffserv networks as described inRFC 2998.
 
RFC 4924 Reflections on Internet Transparency
 
Authors:B. Aboba, Ed., E. Davies.
Date:July 2007
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 4924
This document provides a review of previous IAB statements onInternet transparency, as well a discussion of new transparency issues. Far from having lessened in relevance, technical implications of intentionally or inadvertently impeding network transparency play a critical role in the Internet's ability to support innovation and global communication. This document provides some specific illustrations of those potential impacts.
 
RFC 4925 Softwire Problem Statement
 
Authors:X. Li, Ed., S. Dawkins, Ed., D. Ward, Ed., A. Durand, Ed..
Date:July 2007
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 4925
This document captures the problem statement for the SoftwiresWorking Group, which is developing standards for the discovery, control, and encapsulation methods for connecting IPv4 networks across IPv6-only networks as well as IPv6 networks across IPv4-only networks. The standards will encourage multiple, inter-operable vendor implementations by identifying, and extending where necessary, existing standard protocols to resolve a selected set of "IPv4/IPv6" and "IPv6/IPv4" transition problems. This document describes the specific problems ("Hubs and Spokes" and "Mesh") that will be solved by the standards developed by the Softwires Working Group. Some requirements (and non-requirements) are also identified to better describe the specific problem scope.
 
RFC 4926 A URN Namespace for GEANT
 
Authors:T.Kalin, M.Molina.
Date:July 2007
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 4926
This document describes a proposed URN (Uniform Resource Name) namespace that would be managed by DANTE, representing EuropeanResearch and academic networks, for naming persistent resources defined by GEANT, the Consortium of European Academic and ResearchNetworks, its projects, activities, working groups, and other designated subordinates.
 
RFC 4927 Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering
 
Authors:J.-L. Le Roux, Ed..
Date:June 2007
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 4927
For scalability purposes, a network may comprise multiple InteriorGateway Protocol (IGP) areas. An inter-area Traffic Engineered LabelSwitched Path (TE-LSP) is an LSP that transits through at least twoIGP areas. In a multi-area network, topology visibility remains local to a given area, and a head-end Label Switching Router (LSR) cannot compute an inter-area shortest constrained path. One key application of the Path Computation Element (PCE)-based architecture is the computation of inter-area TE-LSP paths. The PCE CommunicationProtocol (PCECP) is used to communicate computation requests fromPath Computation Clients (PCCs) to PCEs, and to return computed paths in responses. This document lists a detailed set of PCECP-specific requirements for support of inter-area TE-LSP path computation. It complements the generic requirements for a PCE CommunicationProtocol.
 
RFC 4928 Avoiding Equal Cost Multipath Treatment in MPLS Networks
 
Authors:G. Swallow, S. Bryant, L. Andersson.
Date:June 2007
Formats:txt pdf
Updated by:RFC 7274
Also:BCP 0128
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 4928
This document describes the Equal Cost Multipath (ECMP) behavior of currently deployed MPLS networks. This document makes best practice recommendations for anyone defining an application to run over anMPLS network that wishes to avoid the reordering that can result from transmission of different packets from the same flow over multiple different equal cost paths. These recommendations rely on inspection of the IP version number field in packets. Despite the heuristic nature of the recommendations, they provide a relatively safe way to operate MPLS networks, even if future allocations of IP version numbers were made for some purpose.
 
RFC 4929 Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures
 
Authors:L. Andersson, Ed., A. Farrel, Ed..
Date:June 2007
Formats:txt pdf
Also:BCP 0129
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 4929
This document provides guidelines for applying or extending the MPLS or GMPLS ((G)MPLS) protocol suites and clarifies the IETF's (G)MPLS working groups' responsibility for the (G)MPLS protocols. This document is directed to multi-vendor fora and Standards DevelopmentOrganizations (SDOs) to provide an understanding of (G)MPLS work in the IETF and documents the requisite use of IETF review procedures when considering (G)MPLS applications or protocol extensions in their work. This document does not modify IETF processes.
 
RFC 4930 Extensible Provisioning Protocol (EPP)
 
Authors:S. Hollenbeck.
Date:May 2007
Formats:txt pdf
Obsoletes:RFC 3730
Obsoleted by:RFC 5730
Status:DRAFT STANDARD
DOI:10.17487/RFC 4930
This document describes an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. This document obsoletes RFC 3730.
 
RFC 4931 Extensible Provisioning Protocol (EPP) Domain Name Mapping
 
Authors:S. Hollenbeck.
Date:May 2007
Formats:txt pdf
Obsoletes:RFC 3731
Obsoleted by:RFC 5731
Status:DRAFT STANDARD
DOI:10.17487/RFC 4931
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names.This document obsoletes RFC 3731.
 
RFC 4932 Extensible Provisioning Protocol (EPP) Host Mapping
 
Authors:S. Hollenbeck.
Date:May 2007
Formats:txt pdf
Obsoletes:RFC 3732
Obsoleted by:RFC 5732
Status:DRAFT STANDARD
DOI:10.17487/RFC 4932
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names.This document obsoletes RFC 3732.
 
RFC 4933 Extensible Provisioning Protocol (EPP) Contact Mapping
 
Authors:S. Hollenbeck.
Date:May 2007
Formats:txt pdf
Obsoletes:RFC 3733
Obsoleted by:RFC 5733
Status:DRAFT STANDARD
DOI:10.17487/RFC 4933
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as "contacts") stored in a shared central repository. Specified in ExtensibleMarkup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts. This document obsoletes RFC 3733.
 
RFC 4934 Extensible Provisioning Protocol (EPP) Transport Over TCP
 
Authors:S. Hollenbeck.
Date:May 2007
Formats:txt pdf
Obsoletes:RFC 3734
Obsoleted by:RFC 5734
Status:DRAFT STANDARD
DOI:10.17487/RFC 4934
This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport LayerSecurity (TLS) protocol to protect information exchanged between anEPP client and an EPP server. This document obsoletes RFC 3734.
 
RFC 4935 Fibre Channel Fabric Configuration Server MIB
 
Authors:C. DeSanti, H.K. Vivek, K. McCloghrie, S. Gai.
Date:August 2007
Formats:txt pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4935
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 information related to the Fabric Configuration Server function of a Fibre Channel network.
 
RFC 4936 Fibre Channel Zone Server MIB
 
Authors:C. DeSanti, H.K. Vivek, K. McCloghrie, S. Gai.
Date:August 2007
Formats:txt pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4936
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 information related to a Fibre Channel Zone Server.
 
RFC 4937 IANA Considerations for PPP over Ethernet (PPPoE)
 
Authors:P. Arberg, V. Mammoliti.
Date:June 2007
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 4937
This document describes the IANA considerations for the PPP overEthernet (PPPoE) protocol.
 
RFC 4938 PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics
 
Authors:B. Berry, H. Holgate.
Date:June 2007
Formats:txt pdf
Obsoleted by:RFC 5578
Status:INFORMATIONAL
DOI:10.17487/RFC 4938
This document extends the Point-to-Point over Ethernet (PPPoE)Protocol with a credit-based flow control mechanism and Link QualityMetric report. This optional extension should improve the performance of PPPoE over media with variable bandwidth and limited buffering, such as mobile radio links.
 
RFC 4939 Definitions of Managed Objects for iSNS (Internet Storage Name Service)
 
Authors:K. Gibbons, G. Ramkumar, S. Kipp.
Date:July 2007
Formats:txt pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4939
The iSNS (Internet Storage Name Service) protocol provides storage name service functionality on an IP network that is being used for iSCSI (Internet Small Computer System Interface) or iFCP (InternetFibre Channel Protocol) storage. This document provides a mechanism to monitor multiple iSNS Servers, including information about registered objects in an iSNS Server.
 
RFC 4940 IANA Considerations for OSPF
 
Authors:K. Kompella, B. Fenner.
Date:July 2007
Formats:txt pdf
Also:BCP 0130
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 4940
This memo creates a number of OSPF registries and provides guidance to IANA for assignment of code points within these registries.
 
RFC 4941 Privacy Extensions for Stateless Address Autoconfiguration in IPv6
 
Authors:T. Narten, R. Draves, S. Krishnan.
Date:September 2007
Formats:txt pdf
Obsoletes:RFC 3041
Status:DRAFT STANDARD
DOI:10.17487/RFC 4941
Nodes use IPv6 stateless address autoconfiguration to generate addresses using a combination of locally available information and information advertised by routers. Addresses are formed by combining network prefixes with an interface identifier. On an interface that contains an embedded IEEE Identifier, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation. This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node.
 
RFC 4942 IPv6 Transition/Co-existence Security Considerations
 
Authors:E. Davies, S. Krishnan, P. Savola.
Date:September 2007
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 4942
The transition from a pure IPv4 network to a network where IPv4 andIPv6 coexist brings a number of extra security considerations that need to be taken into account when deploying IPv6 and operating the dual-protocol network and the associated transition mechanisms. This document attempts to give an overview of the various issues grouped into three categories: o issues due to the IPv6 protocol itself, o issues due to transition mechanisms, and o issues due to IPv6 deployment.
 
RFC 4943 IPv6 Neighbor Discovery On-Link Assumption Considered Harmful
 
Authors:S. Roy, A. Durand, J. Paugh.
Date:September 2007
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 4943
This document describes the historical and background information behind the removal of the "on-link assumption" from the conceptual host sending algorithm defined in Neighbor Discovery for IP Version 6(IPv6). According to the algorithm as originally described, when a host's default router list is empty, the host assumes that all destinations are on-link. This is particularly problematic withIPv6-capable nodes that do not have off-link IPv6 connectivity (e.g., no default router). This document describes how making this assumption causes problems and how these problems outweigh the benefits of this part of the conceptual sending algorithm.
 
RFC 4944 Transmission of IPv6 Packets over IEEE 802.15.4 Networks
 
Authors:G. Montenegro, N. Kushalnagar, J. Hui, D. Culler.
Date:September 2007
Formats:txt pdf
Updated by:RFC 6282, RFC 6775, RFC 8025, RFC 8066
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4944
This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks.Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE802.15.4 meshes.
 
RFC 4945 The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX
 
Authors:B. Korver.
Date:August 2007
Formats:txt pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4945
The Internet Key Exchange (IKE) and Public Key Infrastructure forX.509 (PKIX) certificate profile both provide frameworks that must be profiled for use in a given application. This document provides a profile of IKE and PKIX that defines the requirements for using PKI technology in the context of IKE/IPsec. The document complements protocol specifications such as IKEv1 and IKEv2, which assume the existence of public key certificates and related keying materials, but which do not address PKI issues explicitly. This document addresses those issues. The intended audience is implementers of PKI for IPsec.
 
RFC 4946 Atom License Extension
 
Authors:J. Snell.
Date:July 2007
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4946
This memo defines an extension to the Atom Syndication Format for describing licenses associated with Atom feeds and entries.
 
RFC 4947 Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks
 
Authors:G. Fairhurst, M. Montpetit.
Date:July 2007
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 4947
This document describes the process of binding/associating IPv4/IPv6 addresses with MPEG-2 Transport Streams (TS). This procedure is known as Address Resolution (AR) or Neighbor Discovery (ND). Such address resolution complements the higher-layer resource discovery tools that are used to advertise IP sessions.

In MPEG-2 Networks, an IP address must be associated with a Packet ID(PID) value and a specific Transmission Multiplex. This document reviews current methods appropriate to a range of technologies (such as DVB (Digital Video Broadcasting), ATSC (Advanced TelevisionSystems Committee), DOCSIS (Data-Over-Cable Service InterfaceSpecifications), and variants). It also describes the interaction with well-known protocols for address management including DHCP, ARP, and the ND protocol.

 
RFC 4948 Report from the IAB workshop on Unwanted Traffic March 9-10, 2006
 
Authors:L. Andersson, E. Davies, L. Zhang.
Date:August 2007
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 4948
This document reports the outcome of a workshop held by the InternetArchitecture Board (IAB) on Unwanted Internet Traffic. The workshop was held on March 9-10, 2006 at USC/ISI in Marina del Rey, CA, USA.The primary goal of the workshop was to foster interchange between the operator, standards, and research communities on the topic of unwanted traffic, as manifested in, for example, Distributed Denial of Service (DDoS) attacks, spam, and phishing, to gain understandings on the ultimate sources of these unwanted traffic, and to assess their impact and the effectiveness of existing solutions. It was also a goal of the workshop to identify engineering and research topics that could be undertaken by the IAB, the IETF, the IRTF, and the network research and development community at large to develop effective countermeasures against the unwanted traffic.
 
RFC 4949 Internet Security Glossary, Version 2
 
Authors:R. Shirey.
Date:August 2007
Formats:txt pdf
Obsoletes:RFC 2828
Also:FYI 0036
Status:INFORMATIONAL
DOI:10.17487/RFC 4949
This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process(RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed.
 
RFC 4950 ICMP Extensions for Multiprotocol Label Switching
 
Authors:R. Bonica, D. Gan, D. Tappan, C. Pignataro.
Date:August 2007
Formats:txt pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4950
This memo defines an extension object that can be appended to selected multi-part ICMP messages. This extension permits LabelSwitching Routers to append MPLS information to ICMP messages, and has already been widely deployed.
 
RFC 4951 Fail Over Extensions for Layer 2 Tunneling Protocol (L2TP) "failover"
 
Authors:V. Jain, Ed..
Date:August 2007
Formats:txt pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4951
Layer 2 Tunneling Protocol (L2TP) is a connection-oriented protocol that has a shared state between active endpoints. Some of this shared state is vital for operation, but may be volatile in nature, such as packet sequence numbers used on the L2TP Control Connection.When failure of one side of a control connection occurs, a new control connection is created and associated with the old connection by exchanging information about the old connection. Such a mechanism is not intended as a replacement for an active fail over with some mirrored connection states, but as an aid for those parameters that are particularly difficult to have immediately available. Protocol extensions to L2TP defined in this document are intended to facilitate state recovery, providing additional resiliency in an L2TP network, and improving a remote system's layer 2 connectivity.
 
RFC 4952 Overview and Framework for Internationalized Email
 
Authors:J. Klensin, Y. Ko.
Date:July 2007
Formats:txt pdf
Obsoleted by:RFC 6530
Updated by:RFC 5336
Status:INFORMATIONAL
DOI:10.17487/RFC 4952
Full use of electronic mail throughout the world requires that people be able to use their own names, written correctly in their own languages and scripts, as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email.
 
RFC 4953 Defending TCP Against Spoofing Attacks
 
Authors:J. Touch.
Date:July 2007
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 4953
Recent analysis of potential attacks on core Internet infrastructure indicates an increased vulnerability of TCP connections to spurious resets (RSTs), sent with forged IP source addresses (spoofing). TCP has always been susceptible to such RST spoofing attacks, which were indirectly protected by checking that the RST sequence number was inside the current receive window, as well as via the obfuscation ofTCP endpoint and port numbers. For pairs of well-known endpoints often over predictable port pairs, such as BGP or between web servers and well-known large-scale caches, increases in the path bandwidth- delay product of a connection have sufficiently increased the receive window space that off-path third parties can brute-force generate a viable RST sequence number. The susceptibility to attack increases with the square of the bandwidth, and thus presents a significant vulnerability for recent high-speed networks. This document addresses this vulnerability, discussing proposed solutions at the transport level and their inherent challenges, as well as existing network level solutions and the feasibility of their deployment.This document focuses on vulnerabilities due to spoofed TCP segments, and includes a discussion of related ICMP spoofing attacks on TCP connections.
 
RFC 4954 SMTP Service Extension for Authentication
 
Authors:R. Siemborski, Ed., A. Melnikov, Ed..
Date:July 2007
Formats:txt pdf
Obsoletes:RFC 2554
Updates:RFC 3463
Updated by:RFC 5248
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4954
This document defines a Simple Mail Transport Protocol (SMTP) extension whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions during this session. This extension includes a profile of the Simple Authentication and Security Layer (SASL) for SMTP.

This document obsoletes RFC 2554.

 
RFC 4955 DNS Security (DNSSEC) Experiments
 
Authors:D. Blacka.
Date:July 2007
Formats:txt pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4955
This document describes a methodology for deploying alternate, non- backwards-compatible, DNS Security (DNSSEC) methodologies in an experimental fashion without disrupting the deployment of standardDNSSEC.
 
RFC 4956 DNS Security (DNSSEC) Opt-In
 
Authors:R. Arends, M. Kosters, D. Blacka.
Date:July 2007
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4956
In the DNS security (DNSSEC) extensions, delegations to unsigned subzones are cryptographically secured. Maintaining this cryptography is not always practical or necessary. This document describes an experimental "Opt-In" model that allows administrators to omit this cryptography and manage the cost of adopting DNSSEC with large zones.
 
RFC 4957 Link-Layer Event Notifications for Detecting Network Attachments
 
Authors:S. Krishnan, Ed., N. Montavont, E. Njedjou, S. Veerepalli, A. Yegin, Ed..
Date:August 2007
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 4957
Certain network access technologies are capable of providing various types of link-layer status information to IP. Link-layer event notifications can help IP expeditiously detect configuration changes.This document provides a non-exhaustive catalogue of information available from well-known access technologies.
 
RFC 4958 A Framework for Supporting Emergency Telecommunications Services (ETS) within a Single Administrative Domain
 
Authors:K. Carlberg.
Date:July 2007
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 4958
This document presents a framework discussing the role of various protocols and mechanisms that could be considered candidates for supporting Emergency Telecommunication Services (ETS) within a single administrative domain. Comments about their potential usage as well as their current deployment are provided to the reader. Specific solutions are not presented.
 
RFC 4959 IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response
 
Authors:R. Siemborski, A. Gulbrandsen.
Date:September 2007
Formats:txt pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4959
To date, the Internet Message Access Protocol (IMAP) has used aSimple Authentication and Security Layer (SASL) profile which always required at least one complete round trip for an authentication, as it did not support an initial client response argument. This additional round trip at the beginning of the session is undesirable, especially when round-trip costs are high.

This document defines an extension to IMAP which allows clients and servers to avoid this round trip by allowing an initial client response argument to the IMAP AUTHENTICATE command.

 
RFC 4960 Stream Control Transmission Protocol
 
Authors:R. Stewart, Ed..
Date:September 2007
Formats:txt pdf
Obsoletes:RFC 2960, RFC 3309
Updated by:RFC 6096, RFC 6335, RFC 7053
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4960
This document obsoletes RFC 2960 and RFC 3309. It describes theStream Control Transmission Protocol (SCTP). SCTP is designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks, but is capable of broader applications.

SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers the following services to its users:

-- acknowledged error-free non-duplicated transfer of user data,

-- data fragmentation to conform to discovered path MTU size,

-- sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages,

-- optional bundling of multiple user messages into a single SCTP packet, and

-- network-level fault tolerance through supporting of multi-homing at either or both ends of an association.

The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks.

 
RFC 4961 Symmetric RTP / RTP Control Protocol (RTCP)
 
Authors:D. Wing.
Date:July 2007
Formats:txt pdf
Also:BCP 0131
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 4961
This document recommends using one UDP port pair for both communication directions of bidirectional RTP and RTP ControlProtocol (RTCP) sessions, commonly called "symmetric RTP" and"symmetric RTCP".
 
RFC 4962 Guidance for Authentication, Authorization, and Accounting (AAA) Key Management
 
Authors:R. Housley, B. Aboba.
Date:July 2007
Formats:txt pdf
Also:BCP 0132
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 4962
This document provides guidance to designers of Authentication,Authorization, and Accounting (AAA) key management protocols. The guidance is also useful to designers of systems and solutions that include AAA key management protocols. Given the complexity and difficulty in designing secure, long-lasting key management algorithms and protocols by experts in the field, it is almost certainly inappropriate for IETF working groups without deep expertise in the area to be designing their own key management algorithms and protocols based on Authentication, Authorization, andAccounting (AAA) protocols. The guidelines in this document apply to documents requesting publication as IETF RFCs. Further, these guidelines will be useful to other standards development organizations (SDOs) that specify AAA key management.
 
RFC 4963 IPv4 Reassembly Errors at High Data Rates
 
Authors:J. Heffner, M. Mathis, B. Chandler.
Date:July 2007
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 4963
IPv4 fragmentation is not sufficiently robust for use under some conditions in today's Internet. At high data rates, the 16-bit IP identification field is not large enough to prevent frequent incorrectly assembled IP fragments, and the TCP and UDP checksums are insufficient to prevent the resulting corrupted datagrams from being delivered to higher protocol layers. This note describes some easily reproduced experiments demonstrating the problem, and discusses some of the operational implications of these observations.
 
RFC 4964 The P-Answer-State Header Extension to the Session Initiation Protocol for the Open Mobile Alliance Push to Talk over Cellular
 
Authors:A. Allen, Ed., J. Holm, T. Hallin.
Date:September 2007
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 4964
This document describes a private Session Initiation Protocol (SIP) header (P-header) used by the Open Mobile Alliance (OMA) for Push to talk over Cellular (PoC) along with its applicability, which is limited to the OMA PoC application. The P-Answer-State header is used for indicating the answering mode of the handset, which is particular to the PoC application.
 
RFC 4965 CableLabs - IETF Standardization Collaboration
 
Authors:J-F. Mule, W. Townsley.
Date:September 2007
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 4965
This document describes the collaboration and liaison relationship between the Internet Engineering Task Force (IETF) and the CableTelevision Laboratories, Inc. (CableLabs).
 
RFC 4966 Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status
 
Authors:C. Aoun, E. Davies.
Date:July 2007
Formats:txt pdf
Obsoletes:RFC 2766
Status:INFORMATIONAL
DOI:10.17487/RFC 4966
This document discusses issues with the specific form of IPv6-IPv4 protocol translation mechanism implemented by the Network AddressTranslator - Protocol Translator (NAT-PT) defined in RFC 2766. These issues are sufficiently serious that recommending RFC 2766 as a general purpose transition mechanism is no longer desirable, and this document recommends that the IETF should reclassify RFC 2766 fromProposed Standard to Historic status.
 
RFC 4967 Dial String Parameter for the Session Initiation Protocol Uniform Resource Identifier
 
Authors:B. Rosen.
Date:July 2007
Formats:txt pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4967
RFC 3966 explicitly states that 'tel' URIs may not represent a dial string. That leaves no way specify a dial string in a standardized way. Great confusion exists with the SIP URI parameter "user=phone", and specifically, if it can represent a dial string. This memo creates a new value for the user parameter "dialstring", so that one may specify "user=dialstring" to encode a dial string as a 'sip:' or'sips:' URI.
 
RFC 4968 Analysis of IPv6 Link Models for 802.16 Based Networks
 
Authors:S. Madanapalli, Ed..
Date:August 2007
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 4968
This document provides different IPv6 link models that are suitable for IEEE 802.16 based networks and provides analysis of various considerations for each link model and the applicability of each link model under different deployment scenarios. This document is the result of a design team (DT) that was formed to analyze the IPv6 link models for IEEE 802.16 based networks.
 
RFC 4969 IANA Registration for vCard Enumservice
 
Authors:A. Mayrhofer.
Date:August 2007
Formats:txt pdf
Updated by:RFC 6118
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4969
This memo registers the Enumservice "vCard" using the URI schemes"http" and "https". This Enumservice is to be used to refer from anENUM domain name to a vCard instance describing the user of the respective E.164 number.

Information gathered from those vCards could be used before, during, or after inbound or outbound communication takes place. For example, a callee might be presented with the name and association of the caller before picking up the call.

 
RFC 4970 Extensions to OSPF for Advertising Optional Router Capabilities
 
Authors:A. Lindem, Ed., N. Shen, JP. Vasseur, R. Aggarwal, S. Shaffer.
Date:July 2007
Formats:txt pdf
Obsoleted by:RFC 7770
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4970
It is useful for routers in an OSPFv2 or OSPFv3 routing domain to know the capabilities of their neighbors and other routers in the routing domain. This document proposes extensions to OSPFv2 andOSPFv3 for advertising optional router capabilities. A new RouterInformation (RI) Link State Advertisement (LSA) is proposed for this purpose. In OSPFv2, the RI LSA will be implemented with a new opaqueLSA type ID. In OSPFv3, the RI LSA will be implemented with a newLSA type function code. In both protocols, the RI LSA can be advertised at any of the defined flooding scopes (link, area, or autonomous system (AS)).
 
RFC 4971 Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information
 
Authors:JP. Vasseur, Ed., N. Shen, Ed., R. Aggarwal, Ed..
Date:July 2007
Formats:txt pdf
Obsoleted by:RFC 7981
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4971
This document defines a new optional Intermediate System toIntermediate System (IS-IS) TLV named CAPABILITY, formed of multiple sub-TLVs, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain.
 
RFC 4972 Routing Extensions for Discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership
 
Authors:JP. Vasseur, Ed., JL. Leroux, Ed., S. Yasukawa, S. Previdi, P. Psenak, P. Mabbey.
Date:July 2007
Formats:txt pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4972
The setup of a full mesh of Multi-Protocol Label Switching (MPLS)Traffic Engineering (TE) Label Switched Paths (LSP) among a set ofLabel Switch Routers (LSR) is a common deployment scenario of MPLSTraffic Engineering either for bandwidth optimization, bandwidth guarantees or fast rerouting with MPLS Fast Reroute. Such deployment may require the configuration of a potentially large number of TELSPs (on the order of the square of the number of LSRs). This document specifies Interior Gateway Protocol (IGP) routing extensions for Intermediate System-to-Intermediate System (IS-IS) and OpenShortest Path First (OSPF) so as to provide an automatic discovery of the set of LSRs members of a mesh in order to automate the creation of such mesh of TE LSPs.
 
RFC 4973 OSPF-xTE: Experimental Extension to OSPF for Traffic Engineering
 
Authors:P. Srisuresh, P. Joseph.
Date:July 2007
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4973
This document defines OSPF-xTE, an experimental traffic engineering(TE) extension to the link-state routing protocol OSPF. OSPF-xTE defines new TE Link State Advertisements (LSAs) to disseminate TE metrics within an autonomous System (AS), which may consist of multiple areas. When an AS consists of TE and non-TE nodes, OSPF-xTE ensures that non-TE nodes in the AS are unaffected by the TE LSAs.OSPF-xTE generates a stand-alone TE Link State Database (TE-LSDB), distinct from the native OSPF LSDB, for computation of TE circuit paths. OSPF-xTE is versatile and extendible to non-packet networks such as Synchronous Optical Network (SONET) / Time DivisionMultiplexing (TDM) and optical networks.
 
RFC 4974 Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls
 
Authors:D. Papadimitriou, A. Farrel.
Date:August 2007
Formats:txt pdf
Updates:RFC 3473
Updated by:RFC 6001
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4974
In certain networking topologies, it may be advantageous to maintain associations between endpoints and key transit points to support an instance of a service. Such associations are known as Calls.

A Call does not provide the actual connectivity for transmitting user traffic, but only builds a relationship by which subsequentConnections may be made. In Generalized MPLS (GMPLS) suchConnections are known as Label Switched Paths (LSPs).

This document specifies how GMPLS Resource Reservation Protocol -Traffic Engineering (RSVP-TE) signaling may be used and extended to support Calls. These mechanisms provide full and logicalCall/Connection separation.

The mechanisms proposed in this document are applicable to any environment (including multi-area), and for any type of interface: packet, layer-2, time-division multiplexed, lambda, or fiber switching.

 
RFC 4975 The Message Session Relay Protocol (MSRP)
 
Authors:B. Campbell, Ed., R. Mahy, Ed., C. Jennings, Ed..
Date:September 2007
Formats:txt pdf
Updated by:RFC 7977
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4975
This document describes the Message Session Relay Protocol, a protocol for transmitting a series of related instant messages in the context of a session. Message sessions are treated like any other media stream when set up via a rendezvous or session creation protocol such as the Session Initiation Protocol.
 
RFC 4976 Relay Extensions for the Message Sessions Relay Protocol (MSRP)
 
Authors:C. Jennings, R. Mahy, A. B. Roach.
Date:September 2007
Formats:txt pdf
Updated by:RFC 7977
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4976
Two separate models for conveying instant messages have been defined.Page-mode messages stand alone and are not part of a SessionInitiation Protocol (SIP) session, whereas session-mode messages are set up as part of a session using SIP. The Message Session RelayProtocol (MSRP) is a protocol for near real-time, peer-to-peer exchanges of binary content without intermediaries, which is designed to be signaled using a separate rendezvous protocol such as SIP.This document introduces the notion of message relay intermediaries to MSRP and describes the extensions necessary to use them.
 
RFC 4977 Problem Statement: Dual Stack Mobility
 
Authors:G. Tsirtsis, H. Soliman.
Date:August 2007
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 4977
This document discusses the issues associated with mobility management for dual stack mobile nodes. Currently, two mobility management protocols are defined for IPv4 and IPv6. Deploying both in a dual stack mobile node introduces a number of problems.Deployment and operational issues motivate the use of a single mobility management protocol. This document discusses such motivations. The document also discusses requirements for the MobileIPv4 (MIPv4) and Mobile IPv6 (MIPv6) protocol so that they can support mobility management for a dual stack node.
 
RFC 4978 The IMAP COMPRESS Extension
 
Authors:A. Gulbrandsen.
Date:August 2007
Formats:txt pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4978
The COMPRESS extension allows an IMAP connection to be effectively and efficiently compressed.
 
RFC 4979 IANA Registration for Enumservice 'XMPP'
 
Authors:A. Mayrhofer.
Date:August 2007
Formats:txt pdf
Updated by:RFC 6118
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4979
This document requests IANA registration of an Enumservice for XMPP, the Extensible Messaging and Presence Protocol. This Enumservice specifically allows the use of 'xmpp' Uniform Resource Identifiers(URIs) in the context of E.164 Number Mapping (ENUM).
 
RFC 4980 Analysis of Multihoming in Network Mobility Support
 
Authors:C. Ng, T. Ernst, E. Paik, M. Bagnulo.
Date:October 2007
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 4980
This document is an analysis of multihoming in the context of network mobility (NEMO) in IPv6. As there are many situations in which mobile networks may be multihomed, a taxonomy is proposed to classify the possible configurations. The possible deployment scenarios of multihomed mobile networks are described together with the associated issues when network mobility is supported by RFC 3963 (NEMO BasicSupport). Recommendations are offered on how to address these issues.
 
RFC 4981 Survey of Research towards Robust Peer-to-Peer Networks: Search Methods
 
Authors:J. Risson, T. Moors.
Date:September 2007
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 4981
The pace of research on peer-to-peer (P2P) networking in the last five years warrants a critical survey. P2P has the makings of a disruptive technology -- it can aggregate enormous storage and processing resources while minimizing entry and scaling costs.

Failures are common amongst massive numbers of distributed peers, though the impact of individual failures may be less than in conventional architectures. Thus, the key to realizing P2P's potential in applications other than casual file sharing is robustness.

P2P search methods are first couched within an overall P2P taxonomy.P2P indexes for simple key lookup are assessed, including those based on Plaxton trees, rings, tori, butterflies, de Bruijn graphs, and skip graphs. Similarly, P2P indexes for keyword lookup, information retrieval and data management are explored. Finally, early efforts to optimize range, multi-attribute, join, and aggregation queries over P2P indexes are reviewed. Insofar as they are available in the primary literature, robustness mechanisms and metrics are highlighted throughout. However, the low-level mechanisms that most affect robustness are not well isolated in the literature. Recommendations are given for future research.

 
RFC 4982 Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs)
 
Authors:M. Bagnulo, J. Arkko.
Date:July 2007
Formats:txt pdf
Updates:RFC 3972
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4982
This document analyzes the implications of recent attacks on commonly used hash functions on Cryptographically Generated Addresses (CGAs) and updates the CGA specification to support multiple hash algorithms.
 
RFC 4983 Fibre Channel Registered State Change Notification (RSCN) MIB
 
Authors:C. DeSanti, H.K. Vivek, K. McCloghrie, S. Gai.
Date:August 2007
Formats:txt pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4983
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 information related to the management of Fibre Channel's Registered State ChangeNotifications (RSCNs).
 
RFC 4984 Report from the IAB Workshop on Routing and Addressing
 
Authors:D. Meyer, Ed., L. Zhang, Ed., K. Fall, Ed..
Date:September 2007
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 4984
This document reports the outcome of the Routing and AddressingWorkshop that was held by the Internet Architecture Board (IAB) onOctober 18-19, 2006, in Amsterdam, Netherlands. The primary goal of the workshop was to develop a shared understanding of the problems that the large backbone operators are facing regarding the scalability of today's Internet routing system. The key workshop findings include an analysis of the major factors that are driving routing table growth, constraints in router technology, and the limitations of today's Internet addressing architecture. It is hoped that these findings will serve as input to the IETF community and help identify next steps towards effective solutions.

Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and not of the IAB. Furthermore, note that work on issues related to this workshop report is continuing, and this document does not intend to reflect the increased understanding of issues nor to discuss the range of potential solutions that may be the outcome of this ongoing work.

 
RFC 4985 Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name
 
Authors:S. Santesson.
Date:August 2007
Formats:txt pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4985
This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name extension that allows a certificate subject to be associated with the service name and domain name components of a DNS Service Resource Record.
 
RFC 4986 Requirements Related to DNS Security (DNSSEC) Trust Anchor Rollover
 
Authors:H. Eland, R. Mundy, S. Crocker, S. Krishnaswamy.
Date:August 2007
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 4986
Every DNS security-aware resolver must have at least one Trust Anchor to use as the basis for validating responses from DNS signed zones.For various reasons, most DNS security-aware resolvers are expected to have several Trust Anchors. For some operations, manual monitoring and updating of Trust Anchors may be feasible, but many operations will require automated methods for updating Trust Anchors in their security-aware resolvers. This document identifies the requirements that must be met by an automated DNS Trust Anchor rollover solution for security-aware DNS resolvers.
 
RFC 4987 TCP SYN Flooding Attacks and Common Mitigations
 
Authors:W. Eddy.
Date:August 2007
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 4987
This document describes TCP SYN flooding attacks, which have been well-known to the community for several years. Various countermeasures against these attacks, and the trade-offs of each, are described. This document archives explanations of the attack and common defense techniques for the benefit of TCP implementers and administrators of TCP servers or networks, but does not make any standards-level recommendations.
 
RFC 4988 Mobile IPv4 Fast Handovers
 
Authors:R. Koodli, C. Perkins.
Date:October 2007
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4988
This document adapts the Mobile IPv6 Fast Handovers to improve delay and packet loss resulting from Mobile IPv4 handover operations.Specifically, this document addresses movement detection, IP address configuration, and location update latencies during a handover. For reducing the IP address configuration latency, the document proposes that the new Care-of Address is always made to be the new access router's IP address.
 
RFC 4990 Use of Addresses in Generalized Multiprotocol Label Switching (GMPLS) Networks
 
Authors:K. Shiomoto, R. Papneja, R. Rabbat.
Date:September 2007
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 4990
This document clarifies the use of addresses in GeneralizedMultiprotocol Label Switching (GMPLS) networks. The aim is to facilitate interworking of GMPLS-capable Label Switching Routers(LSRs). The document is based on experience gained in implementation, interoperability testing, and deployment.

The document describes how to interpret address and identifier fields within GMPLS protocols, and how to choose which addresses to set in those fields for specific control plane usage models. It also discusses how to handle IPv6 sources and destinations in the MPLS andGMPLS Traffic Engineering (TE) Management Information Base (MIB) modules.

This document does not define new procedures or processes. Whenever this document makes requirements statements or recommendations, these are taken from normative text in the referenced RFCs.

 
RFC 4991 A Common Schema for Internet Registry Information Service Transfer Protocols
 
Authors:A. Newton.
Date:August 2007
Formats:txt pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4991
This document describes an XML Schema for use by Internet RegistryInformation Service (IRIS) application transfer protocols that share common characteristics. It describes common information about the transfer protocol, such as version, supported extensions, and supported security mechanisms.
 
RFC 4992 XML Pipelining with Chunks for the Internet Registry Information Service
 
Authors:A. Newton.
Date:August 2007
Formats:txt pdf
Updates:RFC 3981
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4992
This document describes a simple TCP transfer protocol for theInternet Registry Information Service (IRIS). Data is transferred between clients and servers using chunks to achieve pipelining.
 
RFC 4993 A Lightweight UDP Transfer Protocol for the Internet Registry Information Service
 
Authors:A. Newton.
Date:August 2007
Formats:txt pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4993
This document describes a lightweight UDP transfer protocol for theInternet Registry Information Service (IRIS). This transfer protocol uses a single packet for every request and response, and optionally employs compression over the contents of the packet.
 
RFC 4994 DHCPv6 Relay Agent Echo Request Option
 
Authors:S. Zeng, B. Volz, K. Kinnear, J. Brzozowski.
Date:September 2007
Formats:txt pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4994
This memo defines a Relay Agent Echo Request option for the DynamicHost Configuration Protocol for IPv6 (DHCPv6). The option allows aDHCPv6 relay agent to request a list of relay agent options that the server echoes back to the relay agent.
 
RFC 4995 The RObust Header Compression (ROHC) Framework
 
Authors:L-E. Jonsson, G. Pelletier, K. Sandlund.
Date:July 2007
Formats:txt pdf
Obsoleted by:RFC 5795
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4995
The Robust Header Compression (ROHC) protocol provides an efficient, flexible, and future-proof header compression concept. It is designed to operate efficiently and robustly over various link technologies with different characteristics.

The ROHC framework, along with a set of compression profiles, was initially defined in RFC 3095. To improve and simplify the ROHC specifications, this document explicitly defines the ROHC framework and the profile for uncompressed separately. More specifically, the definition of the framework does not modify or update the definition of the framework specified by RFC 3095.

 
RFC 4996 RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)
 
Authors:G. Pelletier, K. Sandlund, L-E. Jonsson, M. West.
Date:July 2007
Formats:txt pdf
Obsoleted by:RFC 6846
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4996
This document specifies a ROHC (Robust Header Compression) profile for compression of TCP/IP packets. The profile, called ROHC-TCP, provides efficient and robust compression of TCP headers, including frequently used TCP options such as SACK (Selective Acknowledgments) and Timestamps.

ROHC-TCP works well when used over links with significant error rates and long round-trip times. For many bandwidth-limited links where header compression is essential, such characteristics are common.

 
RFC 4997 Formal Notation for RObust Header Compression (ROHC-FN)
 
Authors:R. Finking, G. Pelletier.
Date:July 2007
Formats:txt pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4997
This document defines Robust Header Compression - Formal Notation(ROHC-FN), a formal notation to specify field encodings for compressed formats when defining new profiles within the ROHC framework. ROHC-FN offers a library of encoding methods that are often used in ROHC profiles and can thereby help to simplify future profile development work.
 
RFC 4998 Evidence Record Syntax (ERS)
 
Authors:T. Gondrom, R. Brandner, U. Pordesch.
Date:August 2007
Formats:txt pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 4998
In many scenarios, users must be able prove the existence and integrity of data, including digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time. This document specifies the syntax and processing of anEvidence Record, a structure designed to support long-term non- repudiation of existence of data.