RFC Abstracts
RFC6784 - Kerberos Options for DHCPv6
This document defines four new options for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). These options are used to carry configuration information for Kerberos. [STANDARDS-TRACK]
RFC6783 - Mailing Lists and Non-ASCII Addresses
This document describes considerations for mailing lists with the introduction of non-ASCII UTF-8 email addresses. It outlines some possible scenarios for handling lists with mixtures of non-ASCII and traditional addresses but does not specify protocol changes or offer implementation or deployment advice. This document is a product of the Internet Engineering Task Force (IETF).
RFC6782 - Wireline Incremental IPv6
Operators worldwide are in various stages of preparing for or deploying IPv6 in their networks. These operators often face difficult challenges related to IPv6 introduction, along with those related to IPv4 run-out. Operators will need to meet the simultaneous needs of IPv6 connectivity and continue support for IPv4 connectivity for legacy devices with a stagnant supply of IPv4 addresses. The IPv6 transition will take most networks from an IPv4- only environment to an IPv6-dominant environment with long transition periods varying by operator. This document helps provide a framework for wireline providers who are faced with the challenges of introducing IPv6 along with meeting the legacy needs of IPv4 connectivity, utilizing well-defined and commercially available IPv6 transition technologies. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6781 - DNSSEC Operational Practices, Version 2
This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC.
RFC6780 - RSVP ASSOCIATION Object Extensions
The RSVP ASSOCIATION object was 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 object also has broader applicability as a mechanism to associate RSVP state. This document defines how the ASSOCIATION object can be more generally applied. This document also defines Extended ASSOCIATION objects that, in particular, can be used in the context of the MPLS Transport Profile (MPLS-TP). This document updates RFC 2205, RFC 3209, and RFC 3473. It also generalizes the definition of the Association ID field defined in RFC 4872. [STANDARDS-TRACK]
RFC6779 - Definition of Managed Objects for the Neighborhood Discovery Protocol
This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router. The MIB module defined in this document, denoted NHDP-MIB, also reports state, performance information, and notifications about NHDP. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery. [STANDARDS-TRACK]
RFC6778 - Requirements for Archiving IETF Email Lists and for Providing Web-Based Browsing and Searching
The IETF makes heavy use of email lists to conduct its work. Participants frequently need to search and browse the archives of these lists and have asked for improved search capabilities. The current archive mechanism could also be made more efficient. This memo captures the requirements for improved email list archiving and searching systems. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6777 - Label Switched Path (LSP) Data Path Delay Metrics in Generalized MPLS and MPLS Traffic Engineering (MPLS-TE) Networks
When setting up a Label Switched Path (LSP) in Generalized MPLS (GMPLS) and MPLS Traffic Engineering (MPLS-TE) networks, the completion of the signaling process does not necessarily mean that the cross-connection along the LSP has been programmed accordingly and in a timely manner. Meanwhile, the completion of the signaling process may be used by LSP users or applications that control their use as an indication that the data path has become usable. The existence of the inconsistency between the signaling messages and cross-connection programming, and the possible failure of cross- connection programming, if not properly treated, will result in data loss or even application failure. Characterization of this performance can thus help designers to improve the way in which LSPs are used and to make applications or tools that depend on and use LSPs more robust. This document defines a series of performance metrics to evaluate the connectivity of the data path in the signaling process. [STANDARDS-TRACK]
RFC6776 - Measurement Identity and Information Reporting Using a Source Description (SDES) Item and an RTCP Extended Report (XR) Block
This document defines an RTP Control Protocol (RTCP) Source Description (SDES) item and an RTCP Extended Report (XR) block carrying parameters that identify and describe a measurement period to which one or more other RTCP XR blocks may refer. [STANDARDS-TRACK]
RFC6775 - Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)
The IETF work in IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) defines 6LoWPANs such as IEEE 802.15.4. This and other similar link technologies have limited or no usage of multicast signaling due to energy conservation. In addition, the wireless network may not strictly follow the traditional concept of IP subnets and IP links. IPv6 Neighbor Discovery was not designed for non- transitive wireless links, as its reliance on the traditional IPv6 link concept and its heavy use of multicast make it inefficient and sometimes impractical in a low-power and lossy network. This document describes simple optimizations to IPv6 Neighbor Discovery, its addressing mechanisms, and duplicate address detection for Low- power Wireless Personal Area Networks and similar networks. The document thus updates RFC 4944 to specify the use of the optimizations defined here. [STANDARDS-TRACK]
RFC6774 - Distribution of Diverse BGP Paths
The BGP4 protocol specifies the selection and propagation of a single best path for each prefix. As defined and widely deployed today, BGP has no mechanisms to distribute alternate paths that are not considered best path between its speakers. This behavior results in a number of disadvantages for new applications and services.
RFC6773 - DCCP-UDP: A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal
This document specifies an alternative encapsulation of the Datagram Congestion Control Protocol (DCCP), referred to as DCCP-UDP. This encapsulation allows DCCP to be carried through the current generation of Network Address Translation (NAT) middleboxes without modification of those middleboxes. This document also updates the Session Description Protocol (SDP) information for DCCP defined in RFC 5762. [STANDARDS-TRACK]
RFC6772 - Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information
This document defines an authorization policy language for controlling access to location information. It extends the Common Policy authorization framework to provide location-specific access control. More specifically, this document defines condition elements specific to location information in order to restrict access to data based on the current location of the Target.
RFC6771 - Considerations for Having a Successful "Bar BOF" Side Meeting
New work is typically brought to the IETF by a group of interested individuals. IETF meetings are a convenient place for such groups to hold informal get-togethers to discuss and develop their ideas. Such side meetings, which are not reflected in the IETF meeting agenda and have no official status, are often half-jokingly referred to as "bar BOF" sessions to acknowledge that some of them may eventually lead to a proposal for an official IETF BOF ("birds of a feather" session) on a given topic.
RFC6770 - Use Cases for Content Delivery Network Interconnection
Content Delivery Networks (CDNs) are commonly used for improving the End User experience of a content delivery service while keeping cost at a reasonable level. This document focuses on use cases that correspond to identified industry needs and that are expected to be realized once open interfaces and protocols supporting the interconnection of CDNs are specified and implemented. This document can be used to motivate the definition of the requirements to be supported by CDN Interconnection (CDNI) interfaces. It obsoletes RFC 3570. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6769 - Simple Virtual Aggregation (S-VA)
All BGP routers in the Default-Free Zone (DFZ) are required to carry all routes in the Default-Free Routing Table (DFRT). This document describes a technique, Simple Virtual Aggregation (S-VA), that allows some BGP routers not to install all of those routes into the Forwarding Information Base (FIB).
RFC6768 - ATM-Based xDSL Bonded Interfaces MIB
This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. This document proposes an extension to the GBOND-MIB module with a set of objects for managing ATM-based multi-pair bonded xDSL interfaces, as defined in ITU-T Recommendation G.998.1.
RFC6767 - Ethernet-Based xDSL Multi-Pair Bonding (G.Bond/Ethernet) MIB
This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. This document defines an extension to the GBOND-MIB module with a set of objects for managing Ethernet-based multi-pair bonded Digital Subscriber Line (xDSL) interfaces, as defined in ITU-T Recommendation G.998.2.
RFC6766 - xDSL Multi-Pair Bonding Using Time-Division Inverse Multiplexing (G.Bond/TDIM) MIB
This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. This document proposes an extension to the GBOND-MIB module with a set of objects for managing multi-pair bonded xDSL interfaces using Time-Division Inverse Multiplexing (TDIM), as defined in ITU-T Recommendation G.998.3.
RFC6765 - xDSL Multi-Pair Bonding (G.Bond) MIB
This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. This document defines an extension to the Interfaces Group MIB with a set of common objects for managing multi-pair bonded Digital Subscriber Line (xDSL) interfaces, as defined in ITU-T Recommendations G.998.1, G.998.2, and G.998.3. The textual conventions defining the bonding schemes are contained in a separate MIB module maintained by Internet Assigned Numbers Authority (IANA). The MIB modules specific to each bonding technology are defined in G9981-MIB, G9982-MIB, and G9983-MIB, respectively.
RFC6764 - Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV)
This specification describes how DNS SRV records, DNS TXT records, and well-known URIs can be used together or separately to locate CalDAV (Calendaring Extensions to Web Distributed Authoring and Versioning (WebDAV)) or CardDAV (vCard Extensions to WebDAV) services.
RFC6763 - DNS-Based Service Discovery
This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD.
RFC6762 - Multicast DNS
As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful.
RFC6761 - Special-Use Domain Names
This document describes what it means to say that a Domain Name (DNS name) is reserved for special use, when reserving such a name is appropriate, and the procedure for doing so. It establishes an IANA registry for such domain names, and seeds it with entries for some of the already established special domain names.
RFC6760 - Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP)
One of the goals of the authors of Multicast DNS (mDNS) and DNS-Based Service Discovery (DNS-SD) was to retire AppleTalk and the AppleTalk Name Binding Protocol (NBP) and to replace them with an IP-based solution. This document presents a brief overview of the capabilities of AppleTalk NBP and outlines the properties required of an IP-based replacement.
RFC6759 - Cisco Systems Export of Application Information in IP Flow Information Export (IPFIX)
This document specifies a Cisco Systems extension to the IPFIX information model specified in RFC 5102 to export application information. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6758 - Tunneling of SMTP Message Transfer Priorities
This memo defines a mechanism for tunneling of SMTP (Simple Mail Transfer Protocol) Message Transfer Priority values through MTAs (Message Transfer Agents) that don't support the MT-PRIORITY SMTP extension. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6757 - Access Network Identifier (ANI) Option for Proxy Mobile IPv6
The local mobility anchor in a Proxy Mobile IPv6 (PMIPv6) domain is able to provide access-network- and access-operator-specific handling or policing of the mobile node traffic using information about the access network to which the mobile node is attached. This specification defines a mechanism and a related mobility option for carrying the access network identifier and the access operator identification information from the mobile access gateway to the local mobility anchor over Proxy Mobile IPv6. [STANDARDS-TRACK]
RFC6756 - Internet Engineering Task Force and International Telecommunication Union - Telecommunication Standardization Sector Collaboration Guidelines
This document provides guidance to aid in the understanding of collaboration on standards development between the Telecommunication Standardization Sector of the International Telecommunication Union (ITU-T) and the Internet Engineering Task Force (IETF) of the Internet Society (ISOC). It is an update of and obsoletes RFC 3356. The updates reflect changes in the IETF and ITU-T since RFC 3356 was written. The bulk of this document is common text with ITU-T A Series Supplement 3 (07/2012).
RFC6755 - An IETF URN Sub-Namespace for OAuth
This document establishes an IETF URN Sub-namespace for use with OAuth-related specifications. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6754 - Protocol Independent Multicast Equal-Cost Multipath (ECMP) Redirect
A Protocol Independent Multicast (PIM) router uses the Reverse Path Forwarding (RPF) procedure to select an upstream interface and router in order to build forwarding state. When there are equal cost multipaths (ECMPs), existing implementations often use hash algorithms to select a path. Such algorithms do not allow the spread of traffic among the ECMPs according to administrative metrics. This usually leads to inefficient or ineffective use of network resources. This document introduces the ECMP Redirect, a mechanism to improve the RPF procedure over ECMPs. It allows ECMP selection to be based on administratively selected metrics, such as data transmission delays, path preferences, and routing metrics. [STANDARDS-TRACK]
RFC6753 - A Location Dereference Protocol Using HTTP-Enabled Location Delivery (HELD)
This document describes how to use the Hypertext Transfer Protocol (HTTP) over Transport Layer Security (TLS) as a dereference protocol to resolve a reference to a Presence Information Data Format Location Object (PIDF-LO). This document assumes that a Location Recipient possesses a URI that can be used in conjunction with the HTTP-Enabled Location Delivery (HELD) protocol to request the location of the Target. [STANDARDS-TRACK]
RFC6752 - Issues with Private IP Addressing in the Internet
The purpose of this document is to provide a discussion of the potential problems of using private, RFC 1918, or non-globally routable addressing within the core of a Service Provider (SP) network. The discussion focuses on link addresses and, to a small extent, loopback addresses. While many of the issues are well recognised within the ISP community, there appears to be no document that collectively describes the issues. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6751 - Native IPv6 behind IPv4-to-IPv4 NAT Customer Premises Equipment (6a44)
In customer sites having IPv4-only Customer Premises Equipment (CPE), Teredo (RFC 4380, RFC 5991, RFC 6081) provides last-resort IPv6 connectivity. However, because it is designed to work without the involvement of Internet Service Providers, it has significant limitations (connectivity between IPv6 native addresses and Teredo addresses is uncertain; connectivity between Teredo addresses fails for some combinations of NAT types). 6a44 is a complementary solution that, being based on ISP cooperation, avoids these limitations. At the beginning of 6a44 IPv6 addresses, it replaces the Teredo well-known prefix, present at the beginning of Teredo IPv6 addresses, with network-specific /48 prefixes assigned by local ISPs (an evolution similar to that from 6to4 to 6rd (IPv6 Rapid Deployment on IPv4 Infrastructures)). The specification is expected to be complete enough for running code to be independently written and the solution to be incrementally deployed and used. This document defines an Experimental Protocol for the Internet community.
RFC6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage
This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. [STANDARDS-TRACK]
RFC6749 - The OAuth 2.0 Authorization Framework
The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK]
RFC6748 - Optional Advanced Deployment Scenarios for the Identifier-Locator Network Protocol (ILNP)
This document provides an Architectural description and the Concept of Operations of some optional advanced deployment scenarios for the Identifier-Locator Network Protocol (ILNP), which is an evolutionary enhancement to IP. None of the functions described here is required for the use or deployment of ILNP. Instead, it offers descriptions of engineering and deployment options that might provide either enhanced capability or convenience in administration or management of ILNP-based systems. This document defines an Experimental Protocol for the Internet community.
RFC6747 - Address Resolution Protocol (ARP) for the Identifier-Locator Network Protocol for IPv4 (ILNPv4)
This document defines an Address Resolution Protocol (ARP) extension to support the Identifier-Locator Network Protocol for IPv4 (ILNPv4). ILNP is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.
RFC6746 - IPv4 Options for the Identifier-Locator Network Protocol (ILNP)
This document defines two new IPv4 Options that are used only with the Identifier-Locator Network Protocol for IPv4 (ILNPv4). ILNP is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.
RFC6745 - ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv4 (ILNPv4)
This note defines an experimental ICMP message type for IPv4 used with the Identifier-Locator Network Protocol (ILNP). ILNP is an experimental, evolutionary enhancement to IP. The ICMP message defined herein is used to dynamically update Identifier/Locator bindings for an existing ILNP session. This is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.
RFC6744 - IPv6 Nonce Destination Option for the Identifier-Locator Network Protocol for IPv6 (ILNPv6)
The Identifier-Locator Network Protocol (ILNP) is an experimental, evolutionary enhancement to IP. ILNP has multiple instantiations. This document describes an experimental Nonce Destination Option used only with ILNP for IPv6 (ILNPv6). This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.
RFC6743 - ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv6 (ILNPv6)
This note specifies an experimental ICMPv6 message type used with the Identifier-Locator Network Protocol (ILNP). The Identifier-Locator Network Protocol (ILNP) is an experimental, evolutionary enhancement to IP. This message is used to dynamically update Identifier/Locator bindings for an existing ILNP session. This is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.
RFC6742 - DNS Resource Records for the Identifier-Locator Network Protocol (ILNP)
This note describes additional optional resource records for use with the Domain Name System (DNS). These optional resource records are for use with the Identifier-Locator Network Protocol (ILNP). This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.
RFC6741 - Identifier-Locator Network Protocol (ILNP) Engineering Considerations
This document describes common (i.e., version independent) engineering details for the Identifier-Locator Network Protocol (ILNP), which is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.
RFC6740 - Identifier-Locator Network Protocol (ILNP) Architectural Description
This document provides an architectural description and the concept of operations for the Identifier-Locator Network Protocol (ILNP), which is an experimental, evolutionary enhancement to IP. This is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.
RFC6739 - Synchronizing Service Boundaries and <mapping> Elements Based on the Location-to-Service Translation (LoST) Protocol
The Location-to-Service Translation (LoST) protocol is an XML-based protocol for mapping service identifiers and geodetic or civic location information to service URIs and service boundaries. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services.
RFC6738 - Diameter IKEv2 SK: Using Shared Keys to Support Interaction between IKEv2 Servers and Diameter Servers
The Internet Key Exchange Protocol version 2 (IKEv2) is a component of the IPsec architecture and is used to perform mutual authentication as well as to establish and to maintain IPsec Security Associations (SAs) between the respective parties. IKEv2 supports several different authentication mechanisms, such as the Extensible Authentication Protocol (EAP), certificates, and Shared Key (SK).
RFC6737 - The Diameter Capabilities Update Application
This document defines a new Diameter application and associated Command Codes. The Capabilities Update application is intended to allow the dynamic update of certain Diameter peer capabilities while the peer-to-peer connection is in the open state. [STANDARDS-TRACK]
RFC6736 - Diameter Network Address and Port Translation Control Application
This document describes the framework, messages, and procedures for the Diameter Network address and port translation Control Application. This Diameter application allows per-endpoint control of Network Address Translators and Network Address and Port Translators, which are added to networks to cope with IPv4 address space depletion. This Diameter application allows external devices to configure and manage a Network Address Translator device -- expanding the existing Diameter-based Authentication, Authorization, and Accounting (AAA) and policy control capabilities with a Network Address Translator and Network Address and Port Translator control component. These external devices can be network elements in the data plane such as a Network Access Server, or can be more centralized control plane devices such as AAA-servers. This Diameter application establishes a context to commonly identify and manage endpoints on a gateway or server and a Network Address Translator and Network Address and Port Translator device. This includes, for example, the control of the total number of Network Address Translator bindings allowed or the allocation of a specific Network Address Translator binding for a particular endpoint. In addition, it allows Network Address Translator devices to provide information relevant to accounting purposes. [STANDARDS-TRACK]
RFC6735 - Diameter Priority Attribute-Value Pairs
This document defines Attribute-Value Pair (AVP) containers for various priority parameters for use with Diameter and the Authentication, Authorization, and Accounting (AAA) framework. The parameters themselves are defined in several different protocols that operate at either the network or application layer. [STANDARDS-TRACK]
This document defines four new options for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). These options are used to carry configuration information for Kerberos. [STANDARDS-TRACK]
RFC6783 - Mailing Lists and Non-ASCII Addresses
This document describes considerations for mailing lists with the introduction of non-ASCII UTF-8 email addresses. It outlines some possible scenarios for handling lists with mixtures of non-ASCII and traditional addresses but does not specify protocol changes or offer implementation or deployment advice. This document is a product of the Internet Engineering Task Force (IETF).
RFC6782 - Wireline Incremental IPv6
Operators worldwide are in various stages of preparing for or deploying IPv6 in their networks. These operators often face difficult challenges related to IPv6 introduction, along with those related to IPv4 run-out. Operators will need to meet the simultaneous needs of IPv6 connectivity and continue support for IPv4 connectivity for legacy devices with a stagnant supply of IPv4 addresses. The IPv6 transition will take most networks from an IPv4- only environment to an IPv6-dominant environment with long transition periods varying by operator. This document helps provide a framework for wireline providers who are faced with the challenges of introducing IPv6 along with meeting the legacy needs of IPv4 connectivity, utilizing well-defined and commercially available IPv6 transition technologies. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6781 - DNSSEC Operational Practices, Version 2
This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC.
RFC6780 - RSVP ASSOCIATION Object Extensions
The RSVP ASSOCIATION object was 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 object also has broader applicability as a mechanism to associate RSVP state. This document defines how the ASSOCIATION object can be more generally applied. This document also defines Extended ASSOCIATION objects that, in particular, can be used in the context of the MPLS Transport Profile (MPLS-TP). This document updates RFC 2205, RFC 3209, and RFC 3473. It also generalizes the definition of the Association ID field defined in RFC 4872. [STANDARDS-TRACK]
RFC6779 - Definition of Managed Objects for the Neighborhood Discovery Protocol
This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router. The MIB module defined in this document, denoted NHDP-MIB, also reports state, performance information, and notifications about NHDP. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery. [STANDARDS-TRACK]
RFC6778 - Requirements for Archiving IETF Email Lists and for Providing Web-Based Browsing and Searching
The IETF makes heavy use of email lists to conduct its work. Participants frequently need to search and browse the archives of these lists and have asked for improved search capabilities. The current archive mechanism could also be made more efficient. This memo captures the requirements for improved email list archiving and searching systems. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6777 - Label Switched Path (LSP) Data Path Delay Metrics in Generalized MPLS and MPLS Traffic Engineering (MPLS-TE) Networks
When setting up a Label Switched Path (LSP) in Generalized MPLS (GMPLS) and MPLS Traffic Engineering (MPLS-TE) networks, the completion of the signaling process does not necessarily mean that the cross-connection along the LSP has been programmed accordingly and in a timely manner. Meanwhile, the completion of the signaling process may be used by LSP users or applications that control their use as an indication that the data path has become usable. The existence of the inconsistency between the signaling messages and cross-connection programming, and the possible failure of cross- connection programming, if not properly treated, will result in data loss or even application failure. Characterization of this performance can thus help designers to improve the way in which LSPs are used and to make applications or tools that depend on and use LSPs more robust. This document defines a series of performance metrics to evaluate the connectivity of the data path in the signaling process. [STANDARDS-TRACK]
RFC6776 - Measurement Identity and Information Reporting Using a Source Description (SDES) Item and an RTCP Extended Report (XR) Block
This document defines an RTP Control Protocol (RTCP) Source Description (SDES) item and an RTCP Extended Report (XR) block carrying parameters that identify and describe a measurement period to which one or more other RTCP XR blocks may refer. [STANDARDS-TRACK]
RFC6775 - Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)
The IETF work in IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) defines 6LoWPANs such as IEEE 802.15.4. This and other similar link technologies have limited or no usage of multicast signaling due to energy conservation. In addition, the wireless network may not strictly follow the traditional concept of IP subnets and IP links. IPv6 Neighbor Discovery was not designed for non- transitive wireless links, as its reliance on the traditional IPv6 link concept and its heavy use of multicast make it inefficient and sometimes impractical in a low-power and lossy network. This document describes simple optimizations to IPv6 Neighbor Discovery, its addressing mechanisms, and duplicate address detection for Low- power Wireless Personal Area Networks and similar networks. The document thus updates RFC 4944 to specify the use of the optimizations defined here. [STANDARDS-TRACK]
RFC6774 - Distribution of Diverse BGP Paths
The BGP4 protocol specifies the selection and propagation of a single best path for each prefix. As defined and widely deployed today, BGP has no mechanisms to distribute alternate paths that are not considered best path between its speakers. This behavior results in a number of disadvantages for new applications and services.
RFC6773 - DCCP-UDP: A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal
This document specifies an alternative encapsulation of the Datagram Congestion Control Protocol (DCCP), referred to as DCCP-UDP. This encapsulation allows DCCP to be carried through the current generation of Network Address Translation (NAT) middleboxes without modification of those middleboxes. This document also updates the Session Description Protocol (SDP) information for DCCP defined in RFC 5762. [STANDARDS-TRACK]
RFC6772 - Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information
This document defines an authorization policy language for controlling access to location information. It extends the Common Policy authorization framework to provide location-specific access control. More specifically, this document defines condition elements specific to location information in order to restrict access to data based on the current location of the Target.
RFC6771 - Considerations for Having a Successful "Bar BOF" Side Meeting
New work is typically brought to the IETF by a group of interested individuals. IETF meetings are a convenient place for such groups to hold informal get-togethers to discuss and develop their ideas. Such side meetings, which are not reflected in the IETF meeting agenda and have no official status, are often half-jokingly referred to as "bar BOF" sessions to acknowledge that some of them may eventually lead to a proposal for an official IETF BOF ("birds of a feather" session) on a given topic.
RFC6770 - Use Cases for Content Delivery Network Interconnection
Content Delivery Networks (CDNs) are commonly used for improving the End User experience of a content delivery service while keeping cost at a reasonable level. This document focuses on use cases that correspond to identified industry needs and that are expected to be realized once open interfaces and protocols supporting the interconnection of CDNs are specified and implemented. This document can be used to motivate the definition of the requirements to be supported by CDN Interconnection (CDNI) interfaces. It obsoletes RFC 3570. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6769 - Simple Virtual Aggregation (S-VA)
All BGP routers in the Default-Free Zone (DFZ) are required to carry all routes in the Default-Free Routing Table (DFRT). This document describes a technique, Simple Virtual Aggregation (S-VA), that allows some BGP routers not to install all of those routes into the Forwarding Information Base (FIB).
RFC6768 - ATM-Based xDSL Bonded Interfaces MIB
This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. This document proposes an extension to the GBOND-MIB module with a set of objects for managing ATM-based multi-pair bonded xDSL interfaces, as defined in ITU-T Recommendation G.998.1.
RFC6767 - Ethernet-Based xDSL Multi-Pair Bonding (G.Bond/Ethernet) MIB
This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. This document defines an extension to the GBOND-MIB module with a set of objects for managing Ethernet-based multi-pair bonded Digital Subscriber Line (xDSL) interfaces, as defined in ITU-T Recommendation G.998.2.
RFC6766 - xDSL Multi-Pair Bonding Using Time-Division Inverse Multiplexing (G.Bond/TDIM) MIB
This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. This document proposes an extension to the GBOND-MIB module with a set of objects for managing multi-pair bonded xDSL interfaces using Time-Division Inverse Multiplexing (TDIM), as defined in ITU-T Recommendation G.998.3.
RFC6765 - xDSL Multi-Pair Bonding (G.Bond) MIB
This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. This document defines an extension to the Interfaces Group MIB with a set of common objects for managing multi-pair bonded Digital Subscriber Line (xDSL) interfaces, as defined in ITU-T Recommendations G.998.1, G.998.2, and G.998.3. The textual conventions defining the bonding schemes are contained in a separate MIB module maintained by Internet Assigned Numbers Authority (IANA). The MIB modules specific to each bonding technology are defined in G9981-MIB, G9982-MIB, and G9983-MIB, respectively.
RFC6764 - Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV)
This specification describes how DNS SRV records, DNS TXT records, and well-known URIs can be used together or separately to locate CalDAV (Calendaring Extensions to Web Distributed Authoring and Versioning (WebDAV)) or CardDAV (vCard Extensions to WebDAV) services.
RFC6763 - DNS-Based Service Discovery
This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD.
RFC6762 - Multicast DNS
As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful.
RFC6761 - Special-Use Domain Names
This document describes what it means to say that a Domain Name (DNS name) is reserved for special use, when reserving such a name is appropriate, and the procedure for doing so. It establishes an IANA registry for such domain names, and seeds it with entries for some of the already established special domain names.
RFC6760 - Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP)
One of the goals of the authors of Multicast DNS (mDNS) and DNS-Based Service Discovery (DNS-SD) was to retire AppleTalk and the AppleTalk Name Binding Protocol (NBP) and to replace them with an IP-based solution. This document presents a brief overview of the capabilities of AppleTalk NBP and outlines the properties required of an IP-based replacement.
RFC6759 - Cisco Systems Export of Application Information in IP Flow Information Export (IPFIX)
This document specifies a Cisco Systems extension to the IPFIX information model specified in RFC 5102 to export application information. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6758 - Tunneling of SMTP Message Transfer Priorities
This memo defines a mechanism for tunneling of SMTP (Simple Mail Transfer Protocol) Message Transfer Priority values through MTAs (Message Transfer Agents) that don't support the MT-PRIORITY SMTP extension. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6757 - Access Network Identifier (ANI) Option for Proxy Mobile IPv6
The local mobility anchor in a Proxy Mobile IPv6 (PMIPv6) domain is able to provide access-network- and access-operator-specific handling or policing of the mobile node traffic using information about the access network to which the mobile node is attached. This specification defines a mechanism and a related mobility option for carrying the access network identifier and the access operator identification information from the mobile access gateway to the local mobility anchor over Proxy Mobile IPv6. [STANDARDS-TRACK]
RFC6756 - Internet Engineering Task Force and International Telecommunication Union - Telecommunication Standardization Sector Collaboration Guidelines
This document provides guidance to aid in the understanding of collaboration on standards development between the Telecommunication Standardization Sector of the International Telecommunication Union (ITU-T) and the Internet Engineering Task Force (IETF) of the Internet Society (ISOC). It is an update of and obsoletes RFC 3356. The updates reflect changes in the IETF and ITU-T since RFC 3356 was written. The bulk of this document is common text with ITU-T A Series Supplement 3 (07/2012).
RFC6755 - An IETF URN Sub-Namespace for OAuth
This document establishes an IETF URN Sub-namespace for use with OAuth-related specifications. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6754 - Protocol Independent Multicast Equal-Cost Multipath (ECMP) Redirect
A Protocol Independent Multicast (PIM) router uses the Reverse Path Forwarding (RPF) procedure to select an upstream interface and router in order to build forwarding state. When there are equal cost multipaths (ECMPs), existing implementations often use hash algorithms to select a path. Such algorithms do not allow the spread of traffic among the ECMPs according to administrative metrics. This usually leads to inefficient or ineffective use of network resources. This document introduces the ECMP Redirect, a mechanism to improve the RPF procedure over ECMPs. It allows ECMP selection to be based on administratively selected metrics, such as data transmission delays, path preferences, and routing metrics. [STANDARDS-TRACK]
RFC6753 - A Location Dereference Protocol Using HTTP-Enabled Location Delivery (HELD)
This document describes how to use the Hypertext Transfer Protocol (HTTP) over Transport Layer Security (TLS) as a dereference protocol to resolve a reference to a Presence Information Data Format Location Object (PIDF-LO). This document assumes that a Location Recipient possesses a URI that can be used in conjunction with the HTTP-Enabled Location Delivery (HELD) protocol to request the location of the Target. [STANDARDS-TRACK]
RFC6752 - Issues with Private IP Addressing in the Internet
The purpose of this document is to provide a discussion of the potential problems of using private, RFC 1918, or non-globally routable addressing within the core of a Service Provider (SP) network. The discussion focuses on link addresses and, to a small extent, loopback addresses. While many of the issues are well recognised within the ISP community, there appears to be no document that collectively describes the issues. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6751 - Native IPv6 behind IPv4-to-IPv4 NAT Customer Premises Equipment (6a44)
In customer sites having IPv4-only Customer Premises Equipment (CPE), Teredo (RFC 4380, RFC 5991, RFC 6081) provides last-resort IPv6 connectivity. However, because it is designed to work without the involvement of Internet Service Providers, it has significant limitations (connectivity between IPv6 native addresses and Teredo addresses is uncertain; connectivity between Teredo addresses fails for some combinations of NAT types). 6a44 is a complementary solution that, being based on ISP cooperation, avoids these limitations. At the beginning of 6a44 IPv6 addresses, it replaces the Teredo well-known prefix, present at the beginning of Teredo IPv6 addresses, with network-specific /48 prefixes assigned by local ISPs (an evolution similar to that from 6to4 to 6rd (IPv6 Rapid Deployment on IPv4 Infrastructures)). The specification is expected to be complete enough for running code to be independently written and the solution to be incrementally deployed and used. This document defines an Experimental Protocol for the Internet community.
RFC6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage
This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. [STANDARDS-TRACK]
RFC6749 - The OAuth 2.0 Authorization Framework
The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK]
RFC6748 - Optional Advanced Deployment Scenarios for the Identifier-Locator Network Protocol (ILNP)
This document provides an Architectural description and the Concept of Operations of some optional advanced deployment scenarios for the Identifier-Locator Network Protocol (ILNP), which is an evolutionary enhancement to IP. None of the functions described here is required for the use or deployment of ILNP. Instead, it offers descriptions of engineering and deployment options that might provide either enhanced capability or convenience in administration or management of ILNP-based systems. This document defines an Experimental Protocol for the Internet community.
RFC6747 - Address Resolution Protocol (ARP) for the Identifier-Locator Network Protocol for IPv4 (ILNPv4)
This document defines an Address Resolution Protocol (ARP) extension to support the Identifier-Locator Network Protocol for IPv4 (ILNPv4). ILNP is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.
RFC6746 - IPv4 Options for the Identifier-Locator Network Protocol (ILNP)
This document defines two new IPv4 Options that are used only with the Identifier-Locator Network Protocol for IPv4 (ILNPv4). ILNP is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.
RFC6745 - ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv4 (ILNPv4)
This note defines an experimental ICMP message type for IPv4 used with the Identifier-Locator Network Protocol (ILNP). ILNP is an experimental, evolutionary enhancement to IP. The ICMP message defined herein is used to dynamically update Identifier/Locator bindings for an existing ILNP session. This is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.
RFC6744 - IPv6 Nonce Destination Option for the Identifier-Locator Network Protocol for IPv6 (ILNPv6)
The Identifier-Locator Network Protocol (ILNP) is an experimental, evolutionary enhancement to IP. ILNP has multiple instantiations. This document describes an experimental Nonce Destination Option used only with ILNP for IPv6 (ILNPv6). This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.
RFC6743 - ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv6 (ILNPv6)
This note specifies an experimental ICMPv6 message type used with the Identifier-Locator Network Protocol (ILNP). The Identifier-Locator Network Protocol (ILNP) is an experimental, evolutionary enhancement to IP. This message is used to dynamically update Identifier/Locator bindings for an existing ILNP session. This is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.
RFC6742 - DNS Resource Records for the Identifier-Locator Network Protocol (ILNP)
This note describes additional optional resource records for use with the Domain Name System (DNS). These optional resource records are for use with the Identifier-Locator Network Protocol (ILNP). This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.
RFC6741 - Identifier-Locator Network Protocol (ILNP) Engineering Considerations
This document describes common (i.e., version independent) engineering details for the Identifier-Locator Network Protocol (ILNP), which is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.
RFC6740 - Identifier-Locator Network Protocol (ILNP) Architectural Description
This document provides an architectural description and the concept of operations for the Identifier-Locator Network Protocol (ILNP), which is an experimental, evolutionary enhancement to IP. This is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.
RFC6739 - Synchronizing Service Boundaries and <mapping> Elements Based on the Location-to-Service Translation (LoST) Protocol
The Location-to-Service Translation (LoST) protocol is an XML-based protocol for mapping service identifiers and geodetic or civic location information to service URIs and service boundaries. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services.
RFC6738 - Diameter IKEv2 SK: Using Shared Keys to Support Interaction between IKEv2 Servers and Diameter Servers
The Internet Key Exchange Protocol version 2 (IKEv2) is a component of the IPsec architecture and is used to perform mutual authentication as well as to establish and to maintain IPsec Security Associations (SAs) between the respective parties. IKEv2 supports several different authentication mechanisms, such as the Extensible Authentication Protocol (EAP), certificates, and Shared Key (SK).
RFC6737 - The Diameter Capabilities Update Application
This document defines a new Diameter application and associated Command Codes. The Capabilities Update application is intended to allow the dynamic update of certain Diameter peer capabilities while the peer-to-peer connection is in the open state. [STANDARDS-TRACK]
RFC6736 - Diameter Network Address and Port Translation Control Application
This document describes the framework, messages, and procedures for the Diameter Network address and port translation Control Application. This Diameter application allows per-endpoint control of Network Address Translators and Network Address and Port Translators, which are added to networks to cope with IPv4 address space depletion. This Diameter application allows external devices to configure and manage a Network Address Translator device -- expanding the existing Diameter-based Authentication, Authorization, and Accounting (AAA) and policy control capabilities with a Network Address Translator and Network Address and Port Translator control component. These external devices can be network elements in the data plane such as a Network Access Server, or can be more centralized control plane devices such as AAA-servers. This Diameter application establishes a context to commonly identify and manage endpoints on a gateway or server and a Network Address Translator and Network Address and Port Translator device. This includes, for example, the control of the total number of Network Address Translator bindings allowed or the allocation of a specific Network Address Translator binding for a particular endpoint. In addition, it allows Network Address Translator devices to provide information relevant to accounting purposes. [STANDARDS-TRACK]
RFC6735 - Diameter Priority Attribute-Value Pairs
This document defines Attribute-Value Pair (AVP) containers for various priority parameters for use with Diameter and the Authentication, Authorization, and Accounting (AAA) framework. The parameters themselves are defined in several different protocols that operate at either the network or application layer. [STANDARDS-TRACK]