| |
| RFC 4901 | Protocol Extensions for Header Compression over MPLS |
| |
| Authors: | J. Ash, Ed., J. Hand, Ed., A. Malis, Ed.. |
| Date: | June 2007 |
| Formats: | txt html json |
| 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 json html |
| 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 json html |
| 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 html json |
| 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 html json |
| 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 json html |
| 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 json html |
| 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 html json |
| 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 |
| |
|
|
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 html json |
| 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 html json |
| 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 json html |
| 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 json html |
| 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 html json |
| 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 html json |
| 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) |
| |
|
|
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 json html |
| 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) |
| |
|
|
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 html json |
| 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 html json |
| 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 json html |
| 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 html json |
| 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 html json |
| 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 json html |
| 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 json html |
| 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 |
| |
|
|
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 html json |
| 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) |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 html json |
| 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 json html |
| 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 json html |
| 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 |
| |
|
|
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 html json |
| 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 |
| |
|
|
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 |
| |
|
|
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 html json |
| 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 html json |
| 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 |
| |
|
|
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 json html |
| 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 html json |
| 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 html json |
| 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 json html |
| 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 |
| |
|
|
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 json html |
| 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 json html |
| 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 |
| |
|
|
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 html json |
| 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 |
| |
|
|
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 json html |
| 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 html json |
| 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 html json |
| 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 json html |
| 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 json html |
| 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 |
| |
|
|
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) |
| |
|
|
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 |
| |
|
|
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 html json |
| 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 json html |
| Updated by: | RFC 8996 |
| 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 json html |
| 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 |
| |
|
|
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 html json |
| 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 json html |
| 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 |
| |
|
|
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 json html |
| 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 json html |
| 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 html json |
| 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 html json |
| 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 |
| |
|
|
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) |
| |
|
|
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) |
| |
|
|
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 html json |
| 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 json html |
| 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' |
| |
|
|
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 json html |
| 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 json html |
| 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) |
| |
|
|
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 html json |
| 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 json html |
| 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 json html |
| 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 html json |
| 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 html json |
| 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 json html |
| 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 json html |
| 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 json html |
| 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 |
| |
|
|
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 html json |
| 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 json html |
| 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 json html |
| 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 html json |
| 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 html json |
| 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 json html |
| 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. |
|
