RFC Abstracts
RFC6909 - IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6
This specification defines a new mobility option, the IPv4 Traffic Offload Selector option, for Proxy Mobile IPv6. This option can be used by the local mobility anchor and the mobile access gateway for negotiating IPv4 traffic offload policy for a mobility session. Based on the negotiated IPv4 traffic offload policy, a mobile access gateway can selectively offload some of the IPv4 traffic flows in the access network instead of tunneling back to the local mobility anchor in the home network.
RFC6908 - Deployment Considerations for Dual-Stack Lite
This document discusses the deployment issues of and the requirements for the deployment and operation of Dual-Stack Lite (DS-Lite). This document describes the various deployment considerations and applicability of the DS-Lite architecture.
RFC6907 - Use Cases and Interpretations of Resource Public Key Infrastructure (RPKI) Objects for Issuers and Relying Parties
This document describes a number of use cases together with directions and interpretations for organizations and relying parties when creating or encountering Resource Public Key Infrastructure (RPKI) object scenarios in the public RPKI. All of these items are discussed here in relation to the Internet routing system.
RFC6906 - The 'profile' Link Relation Type
This specification defines the 'profile' link relation type that allows resource representations to indicate that they are following one or more profiles. A profile is defined not to alter the semantics of the resource representation itself, but to allow clients to learn about additional semantics (constraints, conventions, extensions) that are associated with the resource representation, in addition to those defined by the media type and possibly other mechanisms.
RFC6905 - Requirements for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL)
Operations, Administration, and Maintenance (OAM) is a general term used to identify functions and toolsets to troubleshoot and monitor networks. This document presents OAM requirements applicable to the Transparent Interconnection of Lots of Links (TRILL).
RFC6904 - Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)
The Secure Real-time Transport Protocol (SRTP) provides authentication, but not encryption, of the headers of Real-time Transport Protocol (RTP) packets. However, RTP header extensions may carry sensitive information for which participants in multimedia sessions want confidentiality. This document provides a mechanism, extending the mechanisms of SRTP, to selectively encrypt RTP header extensions in SRTP.
RFC6903 - Additional Link Relation Types
This specification defines a number of additional link relation types that can used for a range of purposes in a variety of applications types.
RFC6902 - JavaScript Object Notation (JSON) Patch
JSON Patch defines a JSON document structure for expressing a sequence of operations to apply to a JavaScript Object Notation (JSON) document; it is suitable for use with the HTTP PATCH method. The "application/json-patch+json" media type is used to identify such patch documents.
RFC6901 - JavaScript Object Notation (JSON) Pointer
JSON Pointer defines a string syntax for identifying a specific value within a JavaScript Object Notation (JSON) document.
RFC6898 - Link Management Protocol Behavior Negotiation and Configuration Modifications
The Link Management Protocol (LMP) is used to coordinate the properties, use, and faults of data links in networks controlled by Generalized Multiprotocol Label Switching (GMPLS). This document defines an extension to LMP to negotiate capabilities and indicate support for LMP extensions. The defined extension is compatible with non-supporting implementations.
RFC6897 - Multipath TCP (MPTCP) Application Interface Considerations
Multipath TCP (MPTCP) adds the capability of using multiple paths to a regular TCP session. Even though it is designed to be totally backward compatible to applications, the data transport differs compared to regular TCP, and there are several additional degrees of freedom that applications may wish to exploit. This document summarizes the impact that MPTCP may have on applications, such as changes in performance. Furthermore, it discusses compatibility issues of MPTCP in combination with non-MPTCP-aware applications. Finally, the document describes a basic application interface that is a simple extension of TCP's interface for MPTCP-aware applications.
RFC6896 - SCS: KoanLogic's Secure Cookie Sessions for HTTP
This memo defines a generic URI and HTTP-header-friendly envelope for carrying symmetrically encrypted, authenticated, and origin-timestamped tokens. It also describes one possible usage of such tokens via a simple protocol based on HTTP cookies.
RFC6895 - Domain Name System (DNS) IANA Considerations
This document specifies Internet Assigned Numbers Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. It obsoletes RFC 6195 and updates RFCs 1183, 2845, 2930, and 3597.
RFC6894 - Methodology for Benchmarking MPLS Traffic Engineered (MPLS-TE) Fast Reroute Protection
This document describes the methodology for benchmarking MPLS Fast Reroute (FRR) protection mechanisms for link and node protection. This document provides test methodologies and testbed setup for measuring failover times of Fast Reroute techniques while considering factors (such as underlying links) that might impact recovery times for real-time applications bound to MPLS Traffic Engineered (MPLS-TE) tunnels.
RFC6893 - A Uniform Resource Name (URN) Namespace for the Open IPTV Forum (OIPF)
This document describes a Uniform Resource Name (URN) namespace for the Open IPTV Forum (OIPF) for naming persistent resources defined within OIPF specifications. Example resources include technical documents and specifications, eXtensible Markup Language (XML) schemas, classification schemes, XML Document Type Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by the OIPF.
RFC6892 - The 'describes' Link Relation Type
This specification defines the 'describes' link relation type that allows resource representations to indicate that they are describing another resource. In contexts where applications want to associate described resources and description resources, and want to build services based on these associations, the 'describes' link relation type provides the opposite direction of the 'describedby' link relation type, which already is a registered link relation type.
RFC6891 - Extension Mechanisms for DNS (EDNS(0))
The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow.
RFC6890 - Special-Purpose IP Address Registries
This memo reiterates the assignment of an IPv4 address block (192.0.0.0/24) to IANA. It also instructs IANA to restructure its IPv4 and IPv6 Special-Purpose Address Registries. Upon restructuring, the aforementioned registries will record all special-purpose address blocks, maintaining a common set of information regarding each address block.
RFC6889 - Analysis of Stateful 64 Translation
Due to specific problems, Network Address Translation - Protocol Translation (NAT-PT) was deprecated by the IETF as a mechanism to perform IPv6-IPv4 translation. Since then, new efforts have been undertaken within IETF to standardize alternative mechanisms to perform IPv6-IPv4 translation. This document analyzes to what extent the new stateful translation mechanisms avoid the problems that caused the IETF to deprecate NAT-PT.
RFC6888 - Common Requirements for Carrier-Grade NATs (CGNs)
This document defines common requirements for Carrier-Grade NATs (CGNs). It updates RFC 4787.
RFC6887 - Port Control Protocol (PCP)
The Port Control Protocol allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a Network Address Translator (NAT) or simple firewall, and also allows a host to optimize its outgoing NAT keepalive messages.
RFC6886 - NAT Port Mapping Protocol (NAT-PMP)
This document describes a protocol for automating the process of creating Network Address Translation (NAT) port mappings. Included in the protocol is a method for retrieving the external IPv4 address of a NAT gateway, thus allowing a client to make its external IPv4 address and port known to peers that may wish to communicate with it. From 2005 onwards, this protocol was implemented in Apple products including Mac OS X, Bonjour for Windows, and AirPort wireless base stations. In 2013, NAT Port Mapping Protocol (NAT-PMP) was superseded by the IETF Standards Track RFC "Port Control Protocol (PCP)", which builds on NAT-PMP and uses a compatible packet format, but adds a number of significant enhancements.
RFC6885 - Stringprep Revision and Problem Statement for the Preparation and Comparison of Internationalized Strings (PRECIS)
If a protocol expects to compare two strings and is prepared only for those strings to be ASCII, then using Unicode code points in those strings requires they be prepared somehow. Internationalizing Domain Names in Applications (here called IDNA2003) defined and used Stringprep and Nameprep. Other protocols subsequently defined Stringprep profiles. A new approach different from Stringprep and Nameprep is used for a revision of IDNA2003 (called IDNA2008). Other Stringprep profiles need to be similarly updated, or a replacement of Stringprep needs to be designed. This document outlines the issues to be faced by those designing a Stringprep replacement.
RFC6884 - RTP Payload Format for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW)
This document specifies Real-time Transport Protocol (RTP) payload formats to be used for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW). Three media type registrations are included for EVRC-NW RTP payload formats. In addition, a file format is specified for transport of EVRC-NW speech data in storage mode applications such as email.
RFC6883 - IPv6 Guidance for Internet Content Providers and Application Service Providers
This document provides guidance and suggestions for Internet Content Providers and Application Service Providers who wish to offer their service to both IPv6 and IPv4 customers. Many of the points will also apply to hosting providers or to any enterprise network preparing for IPv6 users.
RFC6882 - Support for Resource Reservation Protocol Traffic Engineering (RSVP-TE) in Layer 3 Virtual Private Networks (L3VPNs)
IP Virtual Private Networks (VPNs) provide connectivity between sites across an IP/MPLS backbone. These VPNs can be operated using BGP/MPLS, and a single Provider Edge (PE) node may provide access to multiple customer sites belonging to different VPNs.
RFC6881 - Best Current Practice for Communications Services in Support of Emergency Calling
The IETF and other standards organizations have efforts targeted at standardizing various aspects of placing emergency calls on IP networks. This memo describes best current practice on how devices, networks, and services using IETF protocols should use such standards to make emergency calls.
RFC6880 - An Information Model for Kerberos Version 5
This document describes an information model for Kerberos version 5 from the point of view of an administrative service. There is no standard for administrating a Kerberos 5 Key Distribution Center (KDC). This document describes the services exposed by an administrative interface to a KDC.
RFC6879 - IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods
This document analyzes events that cause renumbering and describes the current renumbering methods. These are described in three categories: those applicable during network design, those applicable during preparation for renumbering, and those applicable during the renumbering operation.
RFC6878 - IANA Registry for the Session Initiation Protocol (SIP) "Priority" Header Field
This document defines a new IANA registry to keep track of the values defined for the Session Initiation Protocol (SIP) "Priority" header field. It updates RFC 3261.
RFC6877 - 464XLAT: Combination of Stateful and Stateless Translation
This document describes an architecture (464XLAT) for providing limited IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation (as described in RFC 6146) in the core and stateless protocol translation (as described in RFC 6145) at the edge. 464XLAT is a simple and scalable technique to quickly deploy limited IPv4 access service to IPv6-only edge networks without encapsulation.
RFC6876 - A Posture Transport Protocol over TLS (PT-TLS)
This document specifies PT-TLS, a TLS-based Posture Transport (PT) protocol. The PT-TLS protocol carries the Network Endpoint Assessment (NEA) message exchange under the protection of a Transport Layer Security (TLS) secured tunnel.
RFC6875 - The P2P Network Experiment Council's Activities and Experiments with Application-Layer Traffic Optimization (ALTO) in Japan
This document describes experiments that clarify how an approach similar to Application-Layer Traffic Optimization (ALTO) was effective in reducing network traffic. These experiments were performed in Japan by the P2P Network Experiment Council in an attempt to harmonize peer-to-peer (P2P) technology with network infrastructure. Based on what was learned from these experiments, this document provides some suggestions that might be useful for the ALTO architecture and especially for application-independent ALTO- like server operation.
RFC6874 - Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers
This document describes how the zone identifier of an IPv6 scoped address, defined as <zone_id> in the IPv6 Scoped Address Architecture (RFC 4007), can be represented in a literal IPv6 address and in a Uniform Resource Identifier that includes such a literal address. It updates the URI Generic Syntax specification (RFC 3986) accordingly.
RFC6873 - Format for the Session Initiation Protocol (SIP) Common Log Format (CLF)
The SIPCLF working group has defined a Common Log Format (CLF) framework for Session Initiation Protocol (SIP) servers. This CLF mimics the successful event logging format found in well-known web servers like Apache and web proxies like Squid. This document proposes an indexed text encoding format for the SIP CLF that retains the key advantages of a text-based format while significantly increasing processing performance over a purely text-based implementation. This file format adheres to the SIP CLF information model and provides an effective encoding scheme for all mandatory and optional fields that appear in a SIP CLF record.
RFC6872 - The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Information Model
Well-known web servers such as Apache and web proxies like Squid support event logging using a common log format. The logs produced using these de facto standard formats are invaluable to system administrators for troubleshooting a server and tool writers to craft tools that mine the log files and produce reports and trends. Furthermore, these log files can also be used to train anomaly detection systems and feed events into a security event management system. The Session Initiation Protocol (SIP) does not have a common log format, and, as a result, each server supports a distinct log format that makes it unnecessarily complex to produce tools to do trend analysis and security detection. This document describes a framework, including requirements and analysis of existing approaches, and specifies an information model for development of a SIP common log file format that can be used uniformly by user agents, proxies, registrars, and redirect servers as well as back-to-back user agents.
RFC6871 - Session Description Protocol (SDP) Media Capabilities Negotiation
Session Description Protocol (SDP) capability negotiation provides a general framework for indicating and negotiating capabilities in SDP. The base framework defines only capabilities for negotiating transport protocols and attributes. This documents extends the framework by defining media capabilities that can be used to negotiate media types and their associated parameters.
RFC6870 - Pseudowire Preferential Forwarding Status Bit
This document describes a mechanism for signaling the active and standby status of redundant Pseudowires (PWs) between their termination points. A set of Redundant PWs is configured between Provider Edge (PE) nodes in single-segment pseudowire (SS-PW) applications or between Terminating Provider Edge (T-PE) nodes in Multi-Segment Pseudowire (MS-PW) applications.
RFC6869 - vCard KIND:device
This document defines a value of "device" for the vCard KIND property so that the vCard format can be used to represent computing devices such as appliances, computers, or network elements (e.g., a server, router, switch, printer, sensor, or phone). [STANDARDS-TRACK]
RFC6868 - Parameter Value Encoding in iCalendar and vCard
This specification updates the data formats for iCalendar (RFC 5545) and vCard (RFC 6350) to allow parameter values to include certain characters forbidden by the existing specifications.
RFC6867 - An Internet Key Exchange Protocol Version 2 (IKEv2) Extension to Support EAP Re-authentication Protocol (ERP)
This document updates the Internet Key Exchange Protocol version 2 (IKEv2) described in RFC 5996. This extension allows an IKE Security Association (SA) to be created and authenticated using the Extensible Authentication Protocol (EAP) Re-authentication Protocol extension, as described in RFC 6696. This document defines an Experimental Protocol for the Internet community.
RFC6866 - Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Networks
This document analyses the problems of updating the IPv6 addresses of hosts in enterprise networks that, for operational reasons, require static addresses.
RFC6865 - Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME
This document describes a fully-specified simple Forward Error Correction (FEC) scheme for Reed-Solomon codes over the finite field (also known as the Galois Field) GF(2^^m), with 2 <= m <= 16, that can be used to protect arbitrary media streams along the lines defined by FECFRAME. The Reed-Solomon codes considered have attractive properties, since they offer optimal protection against packet erasures and the source symbols are part of the encoding symbols, which can greatly simplify decoding. However, the price to pay is a limit on the maximum source block size, on the maximum number of encoding symbols, and a computational complexity higher than that of the Low-Density Parity Check (LDPC) codes, for instance.
RFC6864 - Updated Specification of the IPv4 ID Field
The IPv4 Identification (ID) field enables fragmentation and reassembly and, as currently specified, is required to be unique within the maximum lifetime for all datagrams with a given source address/destination address/protocol tuple. If enforced, this uniqueness requirement would limit all connections to 6.4 Mbps for typical datagram sizes. Because individual connections commonly exceed this speed, it is clear that existing systems violate the current specification. This document updates the specification of the IPv4 ID field in RFCs 791, 1122, and 2003 to more closely reflect current practice and to more closely match IPv6 so that the field's value is defined only when a datagram is actually fragmented. It also discusses the impact of these changes on how datagrams are used. [STANDARDS-TRACK]
RFC6863 - Analysis of OSPF Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guide
This document analyzes OSPFv2 and OSPFv3 according to the guidelines set forth in Section 4.2 of the "Keying and Authentication for Routing Protocols (KARP) Design Guidelines" (RFC 6518). Key components of solutions to gaps identified in this document are already underway.
RFC6862 - Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements
Different routing protocols employ different mechanisms for securing protocol packets on the wire. While most already have some method for accomplishing cryptographic message authentication, in many cases the existing methods are dated, vulnerable to attack, and employ cryptographic algorithms that have been deprecated. The "Keying and Authentication for Routing Protocols" (KARP) effort aims to overhaul and improve these mechanisms. This document does not contain protocol specifications. Instead, it defines the areas where protocol specification work is needed. This document is a companion document to RFC 6518, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines"; together they form the guidance and instruction KARP design teams will use to review and overhaul routing protocol transport security.
RFC6861 - The "create-form" and "edit-form" Link Relations
RFC 5988 standardized a means of indicating the relationships between resources on the Web. This specification defines link relation types that may be used to express the relationships between a resource and an input form for constructing data submissions. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6860 - Hiding Transit-Only Networks in OSPF
A transit-only network is defined as a network connecting routers only. In OSPF, transit-only networks are usually configured with routable IP addresses, which are advertised in Link State Advertisements (LSAs) but are not needed for data traffic. In addition, remote attacks can be launched against routers by sending packets to these transit-only networks. This document presents a mechanism to hide transit-only networks to speed up network convergence and reduce vulnerability to remote attacks.
RFC6859 - Update to RFC 3777 to Clarify Nominating Committee Eligibility of IETF Leadership
RFC 3777 specifies that "sitting members" of the IAB and IESG "may not volunteer to serve on the nominating committee". Since the time that document was written, the IETF Administrative Oversight Committee (IAOC) was formed; that body is not covered by RFC 3777. There is also ambiguity in RFC 3777 about whether ex officio members and liaisons are included as "sitting members". This document updates RFC 3777 to clarify the rules as they apply to members of the IAB, the IESG, and the IAOC. This memo documents an Internet Best Current Practice.
RFC6858 - Simplified POP and IMAP Downgrading for Internationalized Email
This document specifies a method for IMAP and POP servers to serve internationalized messages to conventional clients. The specification is simple, easy to implement, and provides only rudimentary results.
This specification defines a new mobility option, the IPv4 Traffic Offload Selector option, for Proxy Mobile IPv6. This option can be used by the local mobility anchor and the mobile access gateway for negotiating IPv4 traffic offload policy for a mobility session. Based on the negotiated IPv4 traffic offload policy, a mobile access gateway can selectively offload some of the IPv4 traffic flows in the access network instead of tunneling back to the local mobility anchor in the home network.
RFC6908 - Deployment Considerations for Dual-Stack Lite
This document discusses the deployment issues of and the requirements for the deployment and operation of Dual-Stack Lite (DS-Lite). This document describes the various deployment considerations and applicability of the DS-Lite architecture.
RFC6907 - Use Cases and Interpretations of Resource Public Key Infrastructure (RPKI) Objects for Issuers and Relying Parties
This document describes a number of use cases together with directions and interpretations for organizations and relying parties when creating or encountering Resource Public Key Infrastructure (RPKI) object scenarios in the public RPKI. All of these items are discussed here in relation to the Internet routing system.
RFC6906 - The 'profile' Link Relation Type
This specification defines the 'profile' link relation type that allows resource representations to indicate that they are following one or more profiles. A profile is defined not to alter the semantics of the resource representation itself, but to allow clients to learn about additional semantics (constraints, conventions, extensions) that are associated with the resource representation, in addition to those defined by the media type and possibly other mechanisms.
RFC6905 - Requirements for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL)
Operations, Administration, and Maintenance (OAM) is a general term used to identify functions and toolsets to troubleshoot and monitor networks. This document presents OAM requirements applicable to the Transparent Interconnection of Lots of Links (TRILL).
RFC6904 - Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)
The Secure Real-time Transport Protocol (SRTP) provides authentication, but not encryption, of the headers of Real-time Transport Protocol (RTP) packets. However, RTP header extensions may carry sensitive information for which participants in multimedia sessions want confidentiality. This document provides a mechanism, extending the mechanisms of SRTP, to selectively encrypt RTP header extensions in SRTP.
RFC6903 - Additional Link Relation Types
This specification defines a number of additional link relation types that can used for a range of purposes in a variety of applications types.
RFC6902 - JavaScript Object Notation (JSON) Patch
JSON Patch defines a JSON document structure for expressing a sequence of operations to apply to a JavaScript Object Notation (JSON) document; it is suitable for use with the HTTP PATCH method. The "application/json-patch+json" media type is used to identify such patch documents.
RFC6901 - JavaScript Object Notation (JSON) Pointer
JSON Pointer defines a string syntax for identifying a specific value within a JavaScript Object Notation (JSON) document.
RFC6898 - Link Management Protocol Behavior Negotiation and Configuration Modifications
The Link Management Protocol (LMP) is used to coordinate the properties, use, and faults of data links in networks controlled by Generalized Multiprotocol Label Switching (GMPLS). This document defines an extension to LMP to negotiate capabilities and indicate support for LMP extensions. The defined extension is compatible with non-supporting implementations.
RFC6897 - Multipath TCP (MPTCP) Application Interface Considerations
Multipath TCP (MPTCP) adds the capability of using multiple paths to a regular TCP session. Even though it is designed to be totally backward compatible to applications, the data transport differs compared to regular TCP, and there are several additional degrees of freedom that applications may wish to exploit. This document summarizes the impact that MPTCP may have on applications, such as changes in performance. Furthermore, it discusses compatibility issues of MPTCP in combination with non-MPTCP-aware applications. Finally, the document describes a basic application interface that is a simple extension of TCP's interface for MPTCP-aware applications.
RFC6896 - SCS: KoanLogic's Secure Cookie Sessions for HTTP
This memo defines a generic URI and HTTP-header-friendly envelope for carrying symmetrically encrypted, authenticated, and origin-timestamped tokens. It also describes one possible usage of such tokens via a simple protocol based on HTTP cookies.
RFC6895 - Domain Name System (DNS) IANA Considerations
This document specifies Internet Assigned Numbers Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. It obsoletes RFC 6195 and updates RFCs 1183, 2845, 2930, and 3597.
RFC6894 - Methodology for Benchmarking MPLS Traffic Engineered (MPLS-TE) Fast Reroute Protection
This document describes the methodology for benchmarking MPLS Fast Reroute (FRR) protection mechanisms for link and node protection. This document provides test methodologies and testbed setup for measuring failover times of Fast Reroute techniques while considering factors (such as underlying links) that might impact recovery times for real-time applications bound to MPLS Traffic Engineered (MPLS-TE) tunnels.
RFC6893 - A Uniform Resource Name (URN) Namespace for the Open IPTV Forum (OIPF)
This document describes a Uniform Resource Name (URN) namespace for the Open IPTV Forum (OIPF) for naming persistent resources defined within OIPF specifications. Example resources include technical documents and specifications, eXtensible Markup Language (XML) schemas, classification schemes, XML Document Type Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by the OIPF.
RFC6892 - The 'describes' Link Relation Type
This specification defines the 'describes' link relation type that allows resource representations to indicate that they are describing another resource. In contexts where applications want to associate described resources and description resources, and want to build services based on these associations, the 'describes' link relation type provides the opposite direction of the 'describedby' link relation type, which already is a registered link relation type.
RFC6891 - Extension Mechanisms for DNS (EDNS(0))
The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow.
RFC6890 - Special-Purpose IP Address Registries
This memo reiterates the assignment of an IPv4 address block (192.0.0.0/24) to IANA. It also instructs IANA to restructure its IPv4 and IPv6 Special-Purpose Address Registries. Upon restructuring, the aforementioned registries will record all special-purpose address blocks, maintaining a common set of information regarding each address block.
RFC6889 - Analysis of Stateful 64 Translation
Due to specific problems, Network Address Translation - Protocol Translation (NAT-PT) was deprecated by the IETF as a mechanism to perform IPv6-IPv4 translation. Since then, new efforts have been undertaken within IETF to standardize alternative mechanisms to perform IPv6-IPv4 translation. This document analyzes to what extent the new stateful translation mechanisms avoid the problems that caused the IETF to deprecate NAT-PT.
RFC6888 - Common Requirements for Carrier-Grade NATs (CGNs)
This document defines common requirements for Carrier-Grade NATs (CGNs). It updates RFC 4787.
RFC6887 - Port Control Protocol (PCP)
The Port Control Protocol allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a Network Address Translator (NAT) or simple firewall, and also allows a host to optimize its outgoing NAT keepalive messages.
RFC6886 - NAT Port Mapping Protocol (NAT-PMP)
This document describes a protocol for automating the process of creating Network Address Translation (NAT) port mappings. Included in the protocol is a method for retrieving the external IPv4 address of a NAT gateway, thus allowing a client to make its external IPv4 address and port known to peers that may wish to communicate with it. From 2005 onwards, this protocol was implemented in Apple products including Mac OS X, Bonjour for Windows, and AirPort wireless base stations. In 2013, NAT Port Mapping Protocol (NAT-PMP) was superseded by the IETF Standards Track RFC "Port Control Protocol (PCP)", which builds on NAT-PMP and uses a compatible packet format, but adds a number of significant enhancements.
RFC6885 - Stringprep Revision and Problem Statement for the Preparation and Comparison of Internationalized Strings (PRECIS)
If a protocol expects to compare two strings and is prepared only for those strings to be ASCII, then using Unicode code points in those strings requires they be prepared somehow. Internationalizing Domain Names in Applications (here called IDNA2003) defined and used Stringprep and Nameprep. Other protocols subsequently defined Stringprep profiles. A new approach different from Stringprep and Nameprep is used for a revision of IDNA2003 (called IDNA2008). Other Stringprep profiles need to be similarly updated, or a replacement of Stringprep needs to be designed. This document outlines the issues to be faced by those designing a Stringprep replacement.
RFC6884 - RTP Payload Format for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW)
This document specifies Real-time Transport Protocol (RTP) payload formats to be used for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW). Three media type registrations are included for EVRC-NW RTP payload formats. In addition, a file format is specified for transport of EVRC-NW speech data in storage mode applications such as email.
RFC6883 - IPv6 Guidance for Internet Content Providers and Application Service Providers
This document provides guidance and suggestions for Internet Content Providers and Application Service Providers who wish to offer their service to both IPv6 and IPv4 customers. Many of the points will also apply to hosting providers or to any enterprise network preparing for IPv6 users.
RFC6882 - Support for Resource Reservation Protocol Traffic Engineering (RSVP-TE) in Layer 3 Virtual Private Networks (L3VPNs)
IP Virtual Private Networks (VPNs) provide connectivity between sites across an IP/MPLS backbone. These VPNs can be operated using BGP/MPLS, and a single Provider Edge (PE) node may provide access to multiple customer sites belonging to different VPNs.
RFC6881 - Best Current Practice for Communications Services in Support of Emergency Calling
The IETF and other standards organizations have efforts targeted at standardizing various aspects of placing emergency calls on IP networks. This memo describes best current practice on how devices, networks, and services using IETF protocols should use such standards to make emergency calls.
RFC6880 - An Information Model for Kerberos Version 5
This document describes an information model for Kerberos version 5 from the point of view of an administrative service. There is no standard for administrating a Kerberos 5 Key Distribution Center (KDC). This document describes the services exposed by an administrative interface to a KDC.
RFC6879 - IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods
This document analyzes events that cause renumbering and describes the current renumbering methods. These are described in three categories: those applicable during network design, those applicable during preparation for renumbering, and those applicable during the renumbering operation.
RFC6878 - IANA Registry for the Session Initiation Protocol (SIP) "Priority" Header Field
This document defines a new IANA registry to keep track of the values defined for the Session Initiation Protocol (SIP) "Priority" header field. It updates RFC 3261.
RFC6877 - 464XLAT: Combination of Stateful and Stateless Translation
This document describes an architecture (464XLAT) for providing limited IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation (as described in RFC 6146) in the core and stateless protocol translation (as described in RFC 6145) at the edge. 464XLAT is a simple and scalable technique to quickly deploy limited IPv4 access service to IPv6-only edge networks without encapsulation.
RFC6876 - A Posture Transport Protocol over TLS (PT-TLS)
This document specifies PT-TLS, a TLS-based Posture Transport (PT) protocol. The PT-TLS protocol carries the Network Endpoint Assessment (NEA) message exchange under the protection of a Transport Layer Security (TLS) secured tunnel.
RFC6875 - The P2P Network Experiment Council's Activities and Experiments with Application-Layer Traffic Optimization (ALTO) in Japan
This document describes experiments that clarify how an approach similar to Application-Layer Traffic Optimization (ALTO) was effective in reducing network traffic. These experiments were performed in Japan by the P2P Network Experiment Council in an attempt to harmonize peer-to-peer (P2P) technology with network infrastructure. Based on what was learned from these experiments, this document provides some suggestions that might be useful for the ALTO architecture and especially for application-independent ALTO- like server operation.
RFC6874 - Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers
This document describes how the zone identifier of an IPv6 scoped address, defined as <zone_id> in the IPv6 Scoped Address Architecture (RFC 4007), can be represented in a literal IPv6 address and in a Uniform Resource Identifier that includes such a literal address. It updates the URI Generic Syntax specification (RFC 3986) accordingly.
RFC6873 - Format for the Session Initiation Protocol (SIP) Common Log Format (CLF)
The SIPCLF working group has defined a Common Log Format (CLF) framework for Session Initiation Protocol (SIP) servers. This CLF mimics the successful event logging format found in well-known web servers like Apache and web proxies like Squid. This document proposes an indexed text encoding format for the SIP CLF that retains the key advantages of a text-based format while significantly increasing processing performance over a purely text-based implementation. This file format adheres to the SIP CLF information model and provides an effective encoding scheme for all mandatory and optional fields that appear in a SIP CLF record.
RFC6872 - The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Information Model
Well-known web servers such as Apache and web proxies like Squid support event logging using a common log format. The logs produced using these de facto standard formats are invaluable to system administrators for troubleshooting a server and tool writers to craft tools that mine the log files and produce reports and trends. Furthermore, these log files can also be used to train anomaly detection systems and feed events into a security event management system. The Session Initiation Protocol (SIP) does not have a common log format, and, as a result, each server supports a distinct log format that makes it unnecessarily complex to produce tools to do trend analysis and security detection. This document describes a framework, including requirements and analysis of existing approaches, and specifies an information model for development of a SIP common log file format that can be used uniformly by user agents, proxies, registrars, and redirect servers as well as back-to-back user agents.
RFC6871 - Session Description Protocol (SDP) Media Capabilities Negotiation
Session Description Protocol (SDP) capability negotiation provides a general framework for indicating and negotiating capabilities in SDP. The base framework defines only capabilities for negotiating transport protocols and attributes. This documents extends the framework by defining media capabilities that can be used to negotiate media types and their associated parameters.
RFC6870 - Pseudowire Preferential Forwarding Status Bit
This document describes a mechanism for signaling the active and standby status of redundant Pseudowires (PWs) between their termination points. A set of Redundant PWs is configured between Provider Edge (PE) nodes in single-segment pseudowire (SS-PW) applications or between Terminating Provider Edge (T-PE) nodes in Multi-Segment Pseudowire (MS-PW) applications.
RFC6869 - vCard KIND:device
This document defines a value of "device" for the vCard KIND property so that the vCard format can be used to represent computing devices such as appliances, computers, or network elements (e.g., a server, router, switch, printer, sensor, or phone). [STANDARDS-TRACK]
RFC6868 - Parameter Value Encoding in iCalendar and vCard
This specification updates the data formats for iCalendar (RFC 5545) and vCard (RFC 6350) to allow parameter values to include certain characters forbidden by the existing specifications.
RFC6867 - An Internet Key Exchange Protocol Version 2 (IKEv2) Extension to Support EAP Re-authentication Protocol (ERP)
This document updates the Internet Key Exchange Protocol version 2 (IKEv2) described in RFC 5996. This extension allows an IKE Security Association (SA) to be created and authenticated using the Extensible Authentication Protocol (EAP) Re-authentication Protocol extension, as described in RFC 6696. This document defines an Experimental Protocol for the Internet community.
RFC6866 - Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Networks
This document analyses the problems of updating the IPv6 addresses of hosts in enterprise networks that, for operational reasons, require static addresses.
RFC6865 - Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME
This document describes a fully-specified simple Forward Error Correction (FEC) scheme for Reed-Solomon codes over the finite field (also known as the Galois Field) GF(2^^m), with 2 <= m <= 16, that can be used to protect arbitrary media streams along the lines defined by FECFRAME. The Reed-Solomon codes considered have attractive properties, since they offer optimal protection against packet erasures and the source symbols are part of the encoding symbols, which can greatly simplify decoding. However, the price to pay is a limit on the maximum source block size, on the maximum number of encoding symbols, and a computational complexity higher than that of the Low-Density Parity Check (LDPC) codes, for instance.
RFC6864 - Updated Specification of the IPv4 ID Field
The IPv4 Identification (ID) field enables fragmentation and reassembly and, as currently specified, is required to be unique within the maximum lifetime for all datagrams with a given source address/destination address/protocol tuple. If enforced, this uniqueness requirement would limit all connections to 6.4 Mbps for typical datagram sizes. Because individual connections commonly exceed this speed, it is clear that existing systems violate the current specification. This document updates the specification of the IPv4 ID field in RFCs 791, 1122, and 2003 to more closely reflect current practice and to more closely match IPv6 so that the field's value is defined only when a datagram is actually fragmented. It also discusses the impact of these changes on how datagrams are used. [STANDARDS-TRACK]
RFC6863 - Analysis of OSPF Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guide
This document analyzes OSPFv2 and OSPFv3 according to the guidelines set forth in Section 4.2 of the "Keying and Authentication for Routing Protocols (KARP) Design Guidelines" (RFC 6518). Key components of solutions to gaps identified in this document are already underway.
RFC6862 - Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements
Different routing protocols employ different mechanisms for securing protocol packets on the wire. While most already have some method for accomplishing cryptographic message authentication, in many cases the existing methods are dated, vulnerable to attack, and employ cryptographic algorithms that have been deprecated. The "Keying and Authentication for Routing Protocols" (KARP) effort aims to overhaul and improve these mechanisms. This document does not contain protocol specifications. Instead, it defines the areas where protocol specification work is needed. This document is a companion document to RFC 6518, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines"; together they form the guidance and instruction KARP design teams will use to review and overhaul routing protocol transport security.
RFC6861 - The "create-form" and "edit-form" Link Relations
RFC 5988 standardized a means of indicating the relationships between resources on the Web. This specification defines link relation types that may be used to express the relationships between a resource and an input form for constructing data submissions. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6860 - Hiding Transit-Only Networks in OSPF
A transit-only network is defined as a network connecting routers only. In OSPF, transit-only networks are usually configured with routable IP addresses, which are advertised in Link State Advertisements (LSAs) but are not needed for data traffic. In addition, remote attacks can be launched against routers by sending packets to these transit-only networks. This document presents a mechanism to hide transit-only networks to speed up network convergence and reduce vulnerability to remote attacks.
RFC6859 - Update to RFC 3777 to Clarify Nominating Committee Eligibility of IETF Leadership
RFC 3777 specifies that "sitting members" of the IAB and IESG "may not volunteer to serve on the nominating committee". Since the time that document was written, the IETF Administrative Oversight Committee (IAOC) was formed; that body is not covered by RFC 3777. There is also ambiguity in RFC 3777 about whether ex officio members and liaisons are included as "sitting members". This document updates RFC 3777 to clarify the rules as they apply to members of the IAB, the IESG, and the IAOC. This memo documents an Internet Best Current Practice.
RFC6858 - Simplified POP and IMAP Downgrading for Internationalized Email
This document specifies a method for IMAP and POP servers to serve internationalized messages to conventional clients. The specification is simple, easy to implement, and provides only rudimentary results.