RFC Abstracts

RFC6724 - Default Address Selection for Internet Protocol Version 6 (IPv6)
This document describes two algorithms, one for source address selection and one for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual-stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses -- depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice versa.
RFC6723 - Update of the Pseudowire Control-Word Negotiation Mechanism
The control-word negotiation mechanism specified in RFC 4447 has a problem when a PE (Provider Edge) changes the preference for the use of the control word from NOT PREFERRED to PREFERRED. This document updates RFC 4447 and RFC 6073 by adding the Label Request message to resolve this control-word negotiation issue for single-segment and multi-segment pseudowires. [STANDARDS-TRACK]
RFC6722 - Publishing the "Tao of the IETF" as a Web Page
This document describes how the "Tao of the IETF", which has been published as a series of RFCs in the past, is instead being published as a web page. It also contains the procedure for publishing and editing that web page. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6721 - The Atom "deleted-entry" Element
This specification adds mechanisms to the Atom Syndication Format that publishers of Atom Feed and Entry documents can use to explicitly identify Atom entries that have been removed. [STANDARDS-TRACK]
RFC6720 - The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol (LDP)
The Generalized TTL Security Mechanism (GTSM) describes a generalized use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify that the packet was sourced by a node on a connected link, thereby protecting the router\'s IP control plane from CPU utilization-based attacks. This technique improves security and is used by many protocols. This document defines the GTSM use for the Label Distribution Protocol (LDP).
RFC6719 - The Minimum Rank with Hysteresis Objective Function
The Routing Protocol for Low-Power and Lossy Networks (RPL) constructs routes by using Objective Functions that optimize or constrain the routes it selects and uses. This specification describes the Minimum Rank with Hysteresis Objective Function (MRHOF), an Objective Function that selects routes that minimize a metric, while using hysteresis to reduce churn in response to small metric changes. MRHOF works with additive metrics along a route, and the metrics it uses are determined by the metrics that the RPL Destination Information Object (DIO) messages advertise. [STANDARDS-TRACK]
RFC6718 - Pseudowire Redundancy
This document describes a framework comprised of a number of scenarios and associated requirements for pseudowire (PW) redundancy. A set of redundant PWs is configured between provider edge (PE) nodes in single-segment PW applications or between terminating PE (T-PE) nodes in multi-segment PW applications. In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new PW status is required to indicate the preferential forwarding status of active or standby for each PW in the redundant set. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6717 - kx509 Kerberized Certificate Issuance Protocol in Use in 2012
This document describes a protocol, called kx509, for using Kerberos tickets to acquire X.509 certificates. These certificates may be used for many of the same purposes as X.509 certificates acquired by other means, but if a Kerberos infrastructure already exists, then the overhead of using kx509 may be much less.
RFC6716 - Definition of the Opus Audio Codec
This document defines the Opus interactive speech and audio codec. Opus is designed to handle a wide range of interactive audio applications, including Voice over IP, videoconferencing, in-game chat, and even live, distributed music performances. It scales from low bitrate narrowband speech at 6 kbit/s to very high quality stereo music at 510 kbit/s. Opus uses both Linear Prediction (LP) and the Modified Discrete Cosine Transform (MDCT) to achieve good compression of both speech and music. [STANDARDS-TRACK]
RFC6715 - vCard Format Extensions: Representing vCard Extensions Defined by the Open Mobile Alliance (OMA) Converged Address Book (CAB) Group
This document defines extensions to the vCard data format for representing and exchanging certain contact information. The properties covered here have been defined by the Open Mobile Alliance (OMA) Converged Address Book group, in order to synchronize, using OMA Data Synchronization, contact fields that were not already defined in the base vCard 4.0 specification. [STANDARDS-TRACK]
RFC6714 - Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP)
This document defines a Message Session Relay Protocol (MSRP) extension, Connection Establishment for Media Anchoring (CEMA). Support of this extension is OPTIONAL. The extension allows middleboxes to anchor the MSRP connection, without the need for middleboxes to modify the MSRP messages; thus, it also enables secure end-to-end MSRP communication in networks where such middleboxes are deployed. This document also defines a Session Description Protocol (SDP) attribute, 'msrp-cema', that MSRP endpoints use to indicate support of the CEMA extension. [STANDARDS-TRACK]
RFC6713 - The 'application/zlib' and 'application/gzip' Media Types
This document defines the 'application/gzip' and 'application/zlib' media types for compressed data using the gzip and zlib compression formats. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6712 - Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP)
This document describes how to layer the Certificate Management Protocol (CMP) over HTTP. It is the "CMPtrans" document referenced in RFC 4210; therefore, this document updates the reference given therein. [STANDARDS-TRACK]
RFC6711 - An IANA Registry for Level of Assurance (LoA) Profiles
This document establishes an IANA registry for Level of Assurance (LoA) Profiles. The registry is intended to be used as an aid to discovering such LoA definitions in protocols that use an LoA concept, including Security Assertion Markup Language (SAML) 2.0 and OpenID Connect. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6710 - Simple Mail Transfer Protocol Extension for Message Transfer Priorities
This memo defines an extension to the SMTP (Simple Mail Transfer Protocol) service whereby messages are given a label to indicate preferential handling, to enable mail handling nodes to take this information into account for onward processing. [STANDARDS-TRACK]
RFC6709 - Design Considerations for Protocol Extensions
This document discusses architectural issues related to the extensibility of Internet protocols, with a focus on design considerations. It is intended to assist designers of both base protocols and extensions. Case studies are included. A companion document, RFC 4775 (BCP 125), discusses procedures relating to the extensibility of IETF protocols. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6708 - Application-Layer Traffic Optimization (ALTO) Requirements
Many Internet applications are used to access resources, such as pieces of information or server processes that are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer file sharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. This guidance shall be based on parameters that affect performance and efficiency of the data transmission between the hosts, e.g., the topological distance. The ultimate goal is to improve performance or Quality of Experience in the application while reducing the utilization of the underlying network infrastructure.
RFC6707 - Content Distribution Network Interconnection (CDNI) Problem Statement
Content Delivery Networks (CDNs) provide numerous benefits for cacheable content: reduced delivery cost, improved quality of experience for End Users, and increased robustness of delivery. For these reasons, they are frequently used for large-scale content delivery. As a result, existing CDN Providers are scaling up their infrastructure, and many Network Service Providers (NSPs) are deploying their own CDNs. It is generally desirable that a given content item can be delivered to an End User regardless of that End User's location or attachment network. This is the motivation for interconnecting standalone CDNs so they can interoperate as an open content delivery infrastructure for the end-to-end delivery of content from Content Service Providers (CSPs) to End Users. However, no standards or open specifications currently exist to facilitate such CDN Interconnection.
RFC6706 - Asymmetric Extended Route Optimization (AERO)
Nodes attached to common multi-access link types (e.g., multicast- capable, shared media, non-broadcast multiple access (NBMA), etc.) can exchange packets as neighbors on the link, but they may not always be provisioned with sufficient routing information for optimal neighbor selection. Such nodes should therefore be able to discover a trusted intermediate router on the link that provides both forwarding services to reach off-link destinations and redirection services to inform the node of an on-link neighbor that is closer to the final destination. This redirection can provide a useful route optimization, since the triangular path from the ingress link neighbor, to the intermediate router, and finally to the egress link neighbor may be considerably longer than the direct path from ingress to egress. However, ordinary redirection may lead to operational issues on certain link types and/or in certain deployment scenarios. This document therefore introduces an Asymmetric Extended Route Optimization (AERO) capability that addresses the issues. This document defines an Experimental Protocol for the Internet community.
RFC6705 - Localized Routing for Proxy Mobile IPv6
Proxy Mobile IPv6 (PMIPv6) is a network based mobility management protocol that enables IP mobility for a host without requiring its participation in any mobility-related signaling. PMIPv6 requires all communications to go through the local mobility anchor. As this can be suboptimal, Localized Routing (LR) allows Mobile Nodes (MNs) attached to the same or different Mobile Access Gateways (MAGs) to route traffic by using localized forwarding or a direct tunnel between the gateways. This document proposes initiation, utilization, and termination mechanisms for localized routing between mobile access gateways within a proxy mobile IPv6 domain. It defines two new signaling messages, Localized Routing Initiation (LRI) and Local Routing Acknowledgment (LRA), that are used to realize this mechanism. [STANDARDS-TRACK]
RFC6704 - Forcerenew Nonce Authentication
Dynamic Host Configuration Protocol (DHCP) FORCERENEW allows for the reconfiguration of a single host by forcing the DHCP client into a Renew state on a trigger from the DHCP server. In the Forcerenew Nonce Authentication protocol, the server sends a nonce to the client in the initial DHCP ACK that is used for subsequent validation of a FORCERENEW message. This document updates RFC 3203. [STANDARDS-TRACK]
RFC6703 - Reporting IP Network Performance Metrics: Different Points of View
Consumers of IP network performance metrics have many different uses in mind. This memo provides "long-term" reporting considerations (e.g., hours, days, weeks, or months, as opposed to 10 seconds), based on analysis of the points of view of two key audiences. It describes how these audience categories affect the selection of metric parameters and options when seeking information that serves their needs. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6702 - Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules
The disclosure process for intellectual property rights (IPR) in documents produced within the IETF stream is essential to the accurate development of community consensus. However, this process is not always followed by IETF participants. Regardless of the cause or motivation, noncompliance with IPR disclosure rules can delay or even derail completion of IETF specifications. This document describes some strategies for promoting compliance with the IPR disclosure rules. These strategies are primarily intended for use by area directors, working group chairs, and working group secretaries. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6701 - Sanctions Available for Application to Violators of IETF IPR Policy
The IETF has developed and documented policies that govern the behavior of all IETF participants with respect to Intellectual Property Rights (IPR) about which they might reasonably be aware.
RFC6698 - The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA
Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. [STANDARDS-TRACK]
RFC6697 - Handover Keying (HOKEY) Architecture Design
The Handover Keying (HOKEY) Working Group seeks to minimize handover delay due to authentication when a peer moves from one point of attachment to another. Work has progressed on two different approaches to reduce handover delay: early authentication (so that authentication does not need to be performed during handover), and reuse of cryptographic material generated during an initial authentication to save time during re-authentication. A basic assumption is that the mobile host or "peer" is initially authenticated using the Extensible Authentication Protocol (EAP), executed between the peer and an EAP server as defined in RFC 3748.
RFC6696 - EAP Extensions for the EAP Re-authentication Protocol (ERP)
The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods. In systems where EAP is used for authentication, it is desirable to avoid repeating the entire EAP exchange with another authenticator. This document specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re- authentication between the peer and an EAP re-authentication server through any authenticator. The re-authentication server may be in the home network or in the local network to which the peer is connecting. [STANDARDS-TRACK]
RFC6695 - Methods to Convey Forward Error Correction (FEC) Framework Configuration Information
The Forward Error Correction (FEC) Framework document (RFC 6363) defines the FEC Framework Configuration Information necessary for the FEC Framework operation. This document describes how to use signaling protocols such as the Session Announcement Protocol (SAP), the Session Initiation Protocol (SIP), the Real Time Streaming Protocol (RTSP), etc. for determining and communicating the configuration information between sender(s) and receiver(s).
RFC6694 - The "about" URI Scheme
This document describes the "about" URI scheme, which is widely used by Web browsers and some other applications to designate access to their internal resources, such as settings, application information, hidden built-in functionality, and so on. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6693 - Probabilistic Routing Protocol for Intermittently Connected Networks
This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised.
RFC6692 - Source Ports in Abuse Reporting Format (ARF) Reports
This document defines an additional header field for use in Abuse Reporting Format (ARF) reports to permit the identification of the source port of the connection involved in an abuse incident.
RFC6691 - TCP Options and Maximum Segment Size (MSS)
This memo discusses what value to use with the TCP Maximum Segment Size (MSS) option, and updates RFC 879 and RFC 2385. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6690 - Constrained RESTful Environments (CoRE) Link Format
This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links. Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. "RESTful" refers to the Representational State Transfer (REST) architecture. A well-known URI is defined as a default entry point for requesting the links hosted by a server. [STANDARDS-TRACK]
RFC6689 - Usage of the RSVP ASSOCIATION Object
The Resource Reservation Protocol (RSVP) ASSOCIATION object is defined in the context of GMPLS-controlled label switched paths (LSPs). In this context, the object is used to associate recovery LSPs with the LSP they are protecting. This document reviews how the association is to be provided in the context of GMPLS recovery. No new procedures or mechanisms are defined by this document, and it is strictly informative in nature. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6688 - Parallel NFS (pNFS) Block Disk Protection
Parallel NFS (pNFS) extends the Network File System version 4 (NFSv4) to enable direct client access to file data on storage devices and bypass the NFSv4 server. This can increase both performance and parallelism, but it requires additional client functionality, some of which depends upon the type of storage used. The pNFS specification for block storage (RFC 5663) describes how clients can identify the volumes used for pNFS, but this mechanism requires communication with the NFSv4 server. This document updates RFC 5663 to add a mechanism that enables identification of block storage devices used by pNFS file systems without communicating with the server. This enables clients to control access to pNFS block devices when the client initially boots, as opposed to waiting until the client can communicate with the NFSv4 server. [STANDARDS-TRACK]
RFC6687 - Performance Evaluation of the Routing Protocol for Low-Power and Lossy Networks (RPL)
This document presents a performance evaluation of the Routing Protocol for Low-Power and Lossy Networks (RPL) for a small outdoor deployment of sensor nodes and for a large-scale smart meter network. Detailed simulations are carried out to produce several routing performance metrics using these real-life deployment scenarios. Please refer to the PDF version of this document, which includes several plots for the performance metrics not shown in the plain-text version. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6686 - Resolution of the Sender Policy Framework (SPF) and Sender ID Experiments
In 2006, the IETF published a suite of protocol documents comprising the Sender Policy Framework (SPF) and Sender ID: two proposed email authentication protocols. Both of these protocols enable one to publish, via the Domain Name System, a policy declaring which mail servers were authorized to send email on behalf of the domain name being queried. There was concern that the two would conflict in some significant operational situations, interfering with message delivery.
RFC6685 - Expert Review for Incident Object Description Exchange Format (IODEF) Extensions in IANA XML Registry
This document specifies restrictions on additions to the subset of the IANA XML Namespace and Schema registries, to require Expert Review for extensions to Incident Object Description Exchange Format (IODEF). [STANDARDS-TRACK]
RFC6684 - Guidelines and Template for Defining Extensions to the Incident Object Description Exchange Format (IODEF)
This document provides guidelines for extensions to the Incident Object Description Exchange Format (IODEF) described in RFC 5070 for exchange of incident management data, and it contains a template for Internet-Drafts describing those extensions, in order to ease the work and improve the quality of extension descriptions. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6683 - Guidelines for Implementing Digital Video Broadcasting - IPTV (DVB-IPTV) Application-Layer Hybrid Forward Error Correction (FEC) Protection
Annex E of the Digital Video Broadcasting - IPTV (DVB-IPTV) technical specification defines an optional Application-Layer Forward Error Correction (AL-FEC) protocol to protect the streaming media transported using RTP. The DVB-IPTV AL-FEC protocol uses two layers for FEC protection. The first (base) layer is based on the 1-D interleaved parity code. The second (enhancement) layer is based on the Raptor code. By offering a layered approach, the DVB-IPTV AL-FEC protocol offers good protection against both bursty and random packet losses at a cost of decent complexity. This document describes how one can implement the DVB-IPTV AL-FEC protocol by using the 1-D interleaved parity code and Raptor code that have already been specified in separate documents. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6682 - RTP Payload Format for Raptor Forward Error Correction (FEC)
This document specifies an RTP payload format for the Forward Error Correction (FEC) repair data produced by the Raptor FEC Schemes. Raptor FEC Schemes are specified for use with the IETF FEC Framework that supports the transport of repair data over both UDP and RTP. This document specifies the payload format that is required for the use of RTP to carry Raptor repair flows. [STANDARDS-TRACK]
RFC6681 - Raptor Forward Error Correction (FEC) Schemes for FECFRAME
This document describes Fully-Specified Forward Error Correction (FEC) Schemes for the Raptor and RaptorQ codes and their application to reliable delivery of media streams in the context of the FEC Framework. The Raptor and RaptorQ codes are systematic codes, where a number of repair symbols are generated from a set of source symbols and sent in one or more repair flows in addition to the source symbols that are sent to the receiver(s) within a source flow. The Raptor and RaptorQ codes offer close to optimal protection against arbitrary packet losses at a low computational complexity. Six FEC Schemes are defined: two for the protection of arbitrary packet flows, two that are optimized for small source blocks, and two for the protection of a single flow that already contains a sequence number. Repair data may be sent over arbitrary datagram transport (e.g., UDP) or using RTP. [STANDARDS-TRACK]
RFC6680 - Generic Security Service Application Programming Interface (GSS-API) Naming Extensions
The Generic Security Service Application Programming Interface (GSS-API) provides a simple naming architecture that supports name-based authorization. This document introduces new APIs that extend the GSS-API naming model to support name attribute transfer between GSS-API peers.
RFC6679 - Explicit Congestion Notification (ECN) for RTP over UDP
This memo specifies how Explicit Congestion Notification (ECN) can be used with the Real-time Transport Protocol (RTP) running over UDP, using the RTP Control Protocol (RTCP) as a feedback mechanism. It defines a new RTCP Extended Report (XR) block for periodic ECN feedback, a new RTCP transport feedback message for timely reporting of congestion events, and a Session Traversal Utilities for NAT (STUN) extension used in the optional initialisation method using Interactive Connectivity Establishment (ICE). Signalling and procedures for negotiation of capabilities and initialisation methods are also defined. [STANDARDS-TRACK]
RFC6678 - Requirements for a Tunnel-Based Extensible Authentication Protocol (EAP) Method
This memo defines the requirements for a tunnel-based Extensible Authentication Protocol (EAP) Method. This tunnel method will use Transport Layer Security (TLS) to establish a secure tunnel. The tunnel will provide support for password authentication, EAP authentication, and the transport of additional data for other purposes. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6677 - Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods
This document defines how to implement channel bindings for Extensible Authentication Protocol (EAP) methods to address the "lying Network Access Service (NAS)" problem as well as the "lying provider" problem. [STANDARDS-TRACK]
RFC6676 - Multicast Addresses for Documentation
This document discusses which multicast addresses should be used for documentation purposes and reserves multicast addresses for such use. Some multicast addresses are derived from AS numbers or unicast addresses. This document also explains how these can be used for documentation purposes. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6675 - A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP
This document presents a conservative loss recovery algorithm for TCP that is based on the use of the selective acknowledgment (SACK) TCP option. The algorithm presented in this document conforms to the spirit of the current congestion control specification (RFC 5681), but allows TCP senders to recover more effectively when multiple segments are lost from a single flight of data. This document obsoletes RFC 3517 and describes changes from it. [STANDARDS-TRACK]
RFC6674 - Gateway-Initiated Dual-Stack Lite Deployment
Gateway-Initiated Dual-Stack Lite (GI-DS-Lite) is a variant of Dual- Stack Lite (DS-Lite) applicable to certain tunnel-based access architectures. GI-DS-Lite extends existing access tunnels beyond the access gateway to an IPv4-IPv4 NAT using softwires with an embedded Context Identifier that uniquely identifies the end-system to which the tunneled packets belong. The access gateway determines which portion of the traffic requires NAT using local policies and sends/ receives this portion to/from this softwire. [STANDARDS-TRACK]
RFC6673 - Round-Trip Packet Loss Metrics
Many user applications (and the transport protocols that make them possible) require two-way communications. To assess this capability, and to achieve test system simplicity, round-trip loss measurements are frequently conducted in practice. The Two-Way Active Measurement Protocol specified in RFC 5357 establishes a round-trip loss measurement capability for the Internet. However, there is currently no round-trip packet loss metric specified according to the RFC 2330 framework.