RFC Abstracts
RFC6959 - Source Address Validation Improvement (SAVI) Threat Scope
The Source Address Validation Improvement (SAVI) effort aims to complement ingress filtering with finer-grained, standardized IP source address validation. This document describes threats enabled by IP source address spoofing both in the global and finer-grained context, describes currently available solutions and challenges, and provides a starting point analysis for finer-grained (host granularity) anti-spoofing work.
RFC6958 - RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Loss Metric Reporting
This document defines an RTP Control Protocol (RTCP) Extended Report (XR) Block that allows the reporting of burst and gap loss metrics for use in a range of RTP applications.
RFC6957 - Duplicate Address Detection Proxy
The document describes a proxy-based mechanism allowing the use of Duplicate Address Detection (DAD) by IPv6 nodes in a point-to-multipoint architecture with a "split-horizon" forwarding scheme, primarily deployed for Digital Subscriber Line (DSL) and Fiber access architectures. Based on the DAD signaling, the first-hop router stores in a Binding Table all known IPv6 addresses used on a point-to-multipoint domain (e.g., VLAN). When a node performs DAD for an address already used by another node, the first-hop router defends the address rather than the device using the address.
RFC6956 - Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library
This document defines basic classes of Logical Function Blocks (LFBs) used in Forwarding and Control Element Separation (ForCES). The basic LFB classes are defined according to the ForCES Forwarding Element (FE) model and ForCES protocol specifications; they are scoped to meet requirements of typical router functions and are considered the basic LFB library for ForCES. The library includes the descriptions of the LFBs and the XML definitions.
RFC6955 - Diffie-Hellman Proof-of-Possession Algorithms
This document describes two methods for producing an integrity check value from a Diffie-Hellman key pair and one method for producing an integrity check value from an Elliptic Curve key pair. This behavior is needed for such operations as creating the signature of a Public-Key Cryptography Standards (PKCS) #10 Certification Request. These algorithms are designed to provide a Proof-of-Possession of the private key and not to be a general purpose signing algorithm.
RFC6954 - Using the Elliptic Curve Cryptography (ECC) Brainpool Curves for the Internet Key Exchange Protocol Version 2 (IKEv2)
This document specifies use of the Elliptic Curve Cryptography (ECC) Brainpool elliptic curve groups for key exchange in the Internet Key Exchange Protocol version 2 (IKEv2).
RFC6953 - Protocol to Access White-Space (PAWS) Databases: Use Cases and Requirements
Portions of the radio spectrum that are assigned to a particular use but are unused or unoccupied at specific locations and times are defined as "white space". The concept of allowing additional transmissions (which may or may not be licensed) in white space is a technique to "unlock" existing spectrum for new use. This document includes the problem statement for the development of a protocol to access a database of white-space information followed by use cases and requirements for that protocol. Finally, requirements associated with the protocol are presented.
RFC6952 - Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide
This document analyzes TCP-based routing protocols, the Border Gateway Protocol (BGP), the Label Distribution Protocol (LDP), the Path Computation Element Communication Protocol (PCEP), and the Multicast Source Distribution Protocol (MSDP), according to guidelines set forth in Section 4.2 of "Keying and Authentication for Routing Protocols Design Guidelines", RFC 6518.
RFC6951 - UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication
This document describes a simple method of encapsulating Stream Control Transmission Protocol (SCTP) packets into UDP packets and its limitations. This allows the usage of SCTP in networks with legacy NATs that do not support SCTP. It can also be used to implement SCTP on hosts without directly accessing the IP layer, for example, implementing it as part of the application without requiring special privileges.
RFC6950 - Architectural Considerations on Application Features in the DNS
A number of Internet applications rely on the Domain Name System (DNS) to support their operations. Many applications use the DNS to locate services for a domain; some, for example, transform identifiers other than domain names into formats that the DNS can process, and then fetch application data or service location data from the DNS. Proposals incorporating sophisticated application behavior using DNS as a substrate have raised questions about the role of the DNS as an application platform. This document explores the architectural consequences of using the DNS to implement certain application features, and it provides guidance to future application designers as to the limitations of the DNS as a substrate and the situations in which alternative designs should be considered.
RFC6949 - RFC Series Format Requirements and Future Development
This document describes the current requirements and requests for enhancements for the format of the canonical version of RFCs. Terms are defined to help clarify exactly which stages of document production are under discussion for format changes. The requirements described in this document will determine what changes will be made to RFC format. This document updates RFC 2223.
RFC6948 - Some Measurements on World IPv6 Day from an End-User Perspective
During World IPv6 Day on June 8, 2011, several key content providers enabled their networks to offer both IPv4 and IPv6 services. Hundreds of organizations participated in this effort, and in the months and weeks leading up to the event worked hard on preparing their networks to support this event. The event was largely unnoticed by the general public, which is a good thing since it means that no major problems were detected. For the Internet, however, there was a major change on a short timescale. This memo discusses measurements that the authors made from the perspective of an end user with good IPv4 and IPv6 connectivity. Our measurements include the number of most popular networks providing AAAA records for their service, as well as delay and connection failure statistics.
RFC6947 - The Session Description Protocol (SDP) Alternate Connectivity (ALTC) Attribute
This document proposes a mechanism that allows the same SDP offer to carry multiple IP addresses of different address families (e.g., IPv4 and IPv6). The proposed attribute, the "altc" attribute, solves the backward-compatibility problem that plagued Alternative Network Address Types (ANAT) due to their syntax.
RFC6946 - Processing of IPv6 "Atomic" Fragments
The IPv6 specification allows packets to contain a Fragment Header without the packet being actually fragmented into multiple pieces (we refer to these packets as "atomic fragments"). Such packets are typically sent by hosts that have received an ICMPv6 "Packet Too Big" error message that advertises a Next-Hop MTU smaller than 1280 bytes, and are currently processed by some implementations as normal "fragmented traffic" (i.e., they are "reassembled" with any other queued fragments that supposedly correspond to the same original packet). Thus, an attacker can cause hosts to employ atomic fragments by forging ICMPv6 "Packet Too Big" error messages, and then launch any fragmentation-based attacks against such traffic. This document discusses the generation of the aforementioned atomic fragments and the corresponding security implications. Additionally, this document formally updates RFC 2460 and RFC 5722, such that IPv6 atomic fragments are processed independently of any other fragments, thus completely eliminating the aforementioned attack vector.
RFC6945 - Definitions of Managed Objects for the Resource Public Key Infrastructure (RPKI) to Router 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 used for monitoring the Resource Public Key Infrastructure (RPKI) to Router Protocol.
RFC6944 - Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status
The DNS Security Extensions (DNSSEC) requires the use of cryptographic algorithm suites for generating digital signatures over DNS data. There is currently an IANA registry for these algorithms, but there is no record of the recommended implementation status of each algorithm. This document provides an applicability statement on algorithm implementation status for DNSSEC component software. This document lists each algorithm's status based on the current reference. In the case that an algorithm is specified without an implementation status, this document assigns one. This document updates RFCs 2536, 2539, 3110, 4034, 4398, 5155, 5702, and 5933.
RFC6943 - Issues in Identifier Comparison for Security Purposes
Identifiers such as hostnames, URIs, IP addresses, and email addresses are often used in security contexts to identify security principals and resources. In such contexts, an identifier presented via some protocol is often compared using some policy to make security decisions such as whether the security principal may access the resource, what level of authentication or encryption is required, etc. If the parties involved in a security decision use different algorithms to compare identifiers, then failure scenarios ranging from denial of service to elevation of privilege can result. This document provides a discussion of these issues that designers should consider when defining identifiers and protocols, and when constructing architectures that use multiple protocols.
RFC6942 - Diameter Support for the EAP Re-authentication Protocol (ERP)
The EAP Re-authentication Protocol (ERP) defines extensions to the Extensible Authentication Protocol (EAP) to support efficient re-authentication between the peer and an EAP Re-authentication (ER) server through a compatible authenticator. This document specifies Diameter support for ERP. It defines a new Diameter ERP application to transport ERP messages between an ER authenticator and the ER server, and a set of new Attribute-Value Pairs (AVPs) that can be used to transport the cryptographic material needed by the re-authentication server.
RFC6941 - MPLS Transport Profile (MPLS-TP) Security Framework
This document provides a security framework for the MPLS Transport Profile (MPLS-TP). MPLS-TP extends MPLS technologies and introduces new Operations, Administration, and Maintenance (OAM) capabilities, a transport-oriented path protection mechanism, and strong emphasis on static provisioning supported by network management systems. This document addresses the security aspects relevant in the context of MPLS-TP specifically. It describes potential security threats as well as mitigation procedures related to MPLS-TP networks and to MPLS-TP interconnection to other MPLS and GMPLS networks. This document is built on RFC 5920 ("Security Framework for MPLS and GMPLS Networks") by providing additional security considerations that are applicable to the MPLS-TP extensions. All the security considerations from RFC 5920 are assumed to apply.
RFC6940 - REsource LOcation And Discovery (RELOAD) Base Protocol
This specification defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet. A P2P signaling protocol provides its clients with an abstract storage and messaging service between a set of cooperating peers that form the overlay network. RELOAD is designed to support a P2P Session Initiation Protocol (P2PSIP) network, but can be utilized by other applications with similar requirements by defining new usages that specify the Kinds of data that need to be stored for a particular application. RELOAD defines a security model based on a certificate enrollment service that provides unique identities. NAT traversal is a fundamental service of the protocol. RELOAD also allows access from "client" nodes that do not need to route traffic or store data for others.
RFC6939 - Client Link-Layer Address Option in DHCPv6
This document specifies the format and mechanism that is to be used for encoding the client link-layer address in DHCPv6 Relay-Forward messages by defining a new DHCPv6 Client Link-Layer Address option.
RFC6938 - Deprecation of BGP Path Attributes: DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID
This document requests IANA to deprecate the following BGP path attributes: DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID, associated with an abandoned Internet-Draft and a Historic RFC.
RFC6937 - Proportional Rate Reduction for TCP
This document describes an experimental Proportional Rate Reduction (PRR) algorithm as an alternative to the widely deployed Fast Recovery and Rate-Halving algorithms. These algorithms determine the amount of data sent by TCP during loss recovery. PRR minimizes excess window adjustments, and the actual window size at the end of recovery will be as close as possible to the ssthresh, as determined by the congestion control algorithm.
RFC6936 - Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums
This document provides an applicability statement for the use of UDP transport checksums with IPv6. It defines recommendations and requirements for the use of IPv6 UDP datagrams with a zero UDP checksum. It describes the issues and design principles that need to be considered when UDP is used with IPv6 to support tunnel encapsulations, and it examines the role of the IPv6 UDP transport checksum. The document also identifies issues and constraints for deployment on network paths that include middleboxes. An appendix presents a summary of the trade-offs that were considered in evaluating the safety of the update to RFC 2460 that changes the use of the UDP checksum with IPv6.
RFC6935 - IPv6 and UDP Checksums for Tunneled Packets
This document updates the IPv6 specification (RFC 2460) to improve performance when a tunnel protocol uses UDP with IPv6 to tunnel packets. The performance improvement is obtained by relaxing the IPv6 UDP checksum requirement for tunnel protocols whose header information is protected on the "inner" packet being carried. Relaxing this requirement removes the overhead associated with the computation of UDP checksums on IPv6 packets that carry the tunnel protocol packets. This specification describes how the IPv6 UDP checksum requirement can be relaxed when the encapsulated packet itself contains a checksum. It also describes the limitations and risks of this approach and discusses the restrictions on the use of this method.
RFC6934 - Applicability of the Access Node Control Mechanism to Broadband Networks Based on Passive Optical Networks (PONs)
The purpose of this document is to provide applicability of the Access Node Control Mechanism to broadband access based on Passive Optical Networks (PONs). The need for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node Complex, composed of a combination of Optical Line Termination (OLT) and Optical Network Termination (ONT) elements, is described in a multi-service reference architecture in order to perform QoS-related, service-related, and subscriber-related operations. The Access Node Control Mechanism is also extended for interaction between components of the Access Node Complex (OLT and ONT). The Access Node Control Mechanism will ensure that the transmission of information between the NAS and Access Node Complex (ANX) and between the OLT and ONT within an ANX does not need to go through distinct element managers but rather uses direct device-to-device communication and stays on net. This allows for performing access-link-related operations within those network elements to meet performance objectives.
RFC6933 - Entity MIB (Version 4)
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single Simple Network Management Protocol (SNMP) agent. This document specifies version 4 of the Entity MIB. This memo obsoletes version 3 of the Entity MIB module published as RFC 4133.
RFC6932 - Brainpool Elliptic Curves for the Internet Key Exchange (IKE) Group Description Registry
This memo allocates code points for four new elliptic curve domain parameter sets over finite prime fields into a registry that was established by the Internet Key Exchange (IKE) but is used by other protocols.
RFC6931 - Additional XML Security Uniform Resource Identifiers (URIs)
This document expands, updates, and establishes an IANA registry for the list of URIs intended for use with XML digital signatures, encryption, canonicalization, and key management. These URIs identify algorithms and types of information. This document obsoletes RFC 4051.
RFC6930 - RADIUS Attribute for IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)
The IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) provides both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 coexistence period. The Dynamic Host Configuration Protocol (DHCP) 6rd option has been defined to configure the 6rd Customer Edge (CE). However, in many networks, the configuration information may be stored in the Authentication Authorization and Accounting (AAA) servers, while user configuration is mainly acquired from a Broadband Network Gateway (BNG) through the DHCP protocol. This document defines a Remote Authentication Dial-In User Service (RADIUS) attribute that carries 6rd configuration information from the AAA server to BNGs.
RFC6929 - Remote Authentication Dial In User Service (RADIUS) Protocol Extensions
The Remote Authentication Dial-In User Service (RADIUS) protocol is nearing exhaustion of its current 8-bit Attribute Type space. In addition, experience shows a growing need for complex grouping, along with attributes that can carry more than 253 octets of data. This document defines changes to RADIUS that address all of the above problems.
RFC6928 - Increasing TCP's Initial Window
This document proposes an experiment to increase the permitted TCP initial window (IW) from between 2 and 4 segments, as specified in RFC 3390, to 10 segments with a fallback to the existing recommendation when performance issues are detected. It discusses the motivation behind the increase, the advantages and disadvantages of the higher initial window, and presents results from several large-scale experiments showing that the higher initial window improves the overall performance of many web services without resulting in a congestion collapse. The document closes with a discussion of usage and deployment for further experimental purposes recommended by the IETF TCP Maintenance and Minor Extensions (TCPM) working group.
RFC6927 - Variants in Second-Level Names Registered in Top-Level Domains
Internationalized Domain Names for Applications (IDNA) provides a method to map a subset of names written in Unicode into the DNS. Because of Unicode decisions, appearance, language and writing system conventions, and historical reasons, it often has been asserted that there is more than one way to write what competent readers and writers think of as the same host name; these different ways of writing are often called "variants". (The authors note that there are many conflicting definitions for the term "variant" in the IDNA community.) This document surveys the approaches that top-level domains have taken to the registration and provisioning of domain names that have variants. This document is not a product of the IETF, does not propose any method to make variants work "correctly", and is not an introduction to internationalization or IDNA.
RFC6926 - DHCPv4 Bulk Leasequery
The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Leasequery protocol allows a requestor to request information about DHCPv4 bindings. This protocol is limited to queries for individual bindings. In some situations, individual binding queries may not be efficient or even possible. This document extends the DHCPv4 Leasequery protocol to allow for bulk transfer of DHCPv4 address binding data via TCP.
RFC6925 - The DHCPv4 Relay Agent Identifier Sub-Option
This document defines a new Relay Agent Identifier sub-option for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information option. The sub-option carries a value that uniquely identifies the relay agent device within the administrative domain. The value is normally administratively configured in the relay agent. The sub-option allows a DHCP relay agent to include the identifier in the DHCP messages it sends.
RFC6924 - Registration of Second-Level URN Namespaces under "ietf"
RFC 2648 defines the "ietf" URN namespace and a number of sub- namespaces. RFC 3553 defines an additional sub-namespace, "params", and creates a registry to document allocations under that. But there is no registry that lists, in one place, all sub-namespaces of "ietf". This document creates and populates such a registry, thereby changing the mechanism defined in RFC 2648 for adding new sub- namespaces of "ietf".
RFC6923 - MPLS Transport Profile (MPLS-TP) Identifiers Following ITU-T Conventions
This document specifies an extension to the identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP). Identifiers that follow IP/MPLS conventions have already been defined. This memo augments that set of identifiers for MPLS-TP management and Operations, Administration, and Maintenance (OAM) functions to include identifier information in a format typically used by the International Telecommunication Union Telecommunication Standardization Sector (ITU-T).
RFC6922 - The application/sql Media Type
This document registers the application/sql media type to be used for the Structured Query Language (SQL).
RFC6921 - Design Considerations for Faster-Than-Light (FTL) Communication
We are approaching the time when we will be able to communicate faster than the speed of light. It is well known that as we approach the speed of light, time slows down. Logically, it is reasonable to assume that as we go faster than the speed of light, time will reverse. The major consequence of this for Internet protocols is that packets will arrive before they are sent. This will have a major impact on the way we design Internet protocols. This paper outlines some of the issues and suggests some directions for additional analysis of these issues.
RFC6920 - Naming Things with Hashes
This document defines a set of ways to identify a thing (a digital object in this case) using the output from a hash function. It specifies a new URI scheme for this purpose, a way to map these to HTTP URLs, and binary and human-speakable formats for these names. The various formats are designed to support, but not require, a strong link to the referenced object, such that the referenced object may be authenticated to the same degree as the reference to it. The reason for this work is to standardise current uses of hash outputs in URLs and to support new information-centric applications and other uses of hash outputs in protocols.
RFC6919 - Further Key Words for Use in RFCs to Indicate Requirement Levels
RFC 2119 defines a standard set of key words for describing requirements of a specification. Many IETF documents have found that these words cannot accurately capture the nuanced requirements of their specification. This document defines additional key words that can be used to address alternative requirements scenarios. Authors who follow these guidelines should incorporate this phrase near the beginning of their document:
RFC6918 - Formally Deprecating Some ICMPv4 Message Types
A number of ICMPv4 message types have become obsolete in practice, but have never been formally deprecated. This document deprecates such ICMPv4 message types, thus cleaning up the corresponding IANA registry. Additionally, it updates RFC 792 and RFC 950, obsoletes RFC 1788, and requests the RFC Editor to change the status of RFC 1788 to Historic.
RFC6917 - Media Resource Brokering
The MediaCtrl working group in the IETF has proposed an architecture for controlling media services. The Session Initiation Protocol (SIP) is used as the signaling protocol that provides many inherent capabilities for message routing. In addition to such signaling properties, a need exists for intelligent, application-level media service selection based on non-static signaling properties. This is especially true when considered in conjunction with deployment architectures that include 1:M and M:N combinations of Application Servers and Media Servers. This document introduces a Media Resource Broker (MRB) entity, which manages the availability of Media Servers and the media resource demands of Application Servers. The document includes potential deployment options for an MRB and appropriate interfaces to Application Servers and Media Servers.
RFC6916 - Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)
This document specifies the process that Certification Authorities (CAs) and Relying Parties (RPs) participating in the Resource Public Key Infrastructure (RPKI) will need to follow to transition to a new (and probably cryptographically stronger) algorithm set. The process is expected to be completed over a timescale of several years. Consequently, no emergency transition is specified. The transition procedure defined in this document supports only a top-down migration (parent migrates before children).
RFC6915 - Flow Identity Extension for HTTP-Enabled Location Delivery (HELD)
RFC 6155 specifies an extension for the HTTP-Enabled Location Delivery (HELD) protocol, allowing the use of an IP address and port number to request a Device location based on an individual packet flow.
RFC6914 - SIMPLE Made Simple: An Overview of the IETF Specifications for Instant Messaging and Presence Using the Session Initiation Protocol (SIP)
The IETF has produced many specifications related to Presence and Instant Messaging with the Session Initiation Protocol (SIP). Collectively, these specifications are known as SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE). This document serves as a guide to the SIMPLE suite of specifications. It categorizes the specifications, explains what each is for, and how they relate to each other.
RFC6913 - Indicating Fax over IP Capability in the Session Initiation Protocol (SIP)
This document defines and registers with IANA the new "fax" media feature tag for use with the Session Initiation Protocol (SIP). Currently, fax calls are indistinguishable from voice calls at call initiation. Consequently, fax calls can be routed to SIP user agents that are not fax capable. A "fax" media feature tag implemented in conjunction with caller preferences allows for more accurate fax call routing.
RFC6912 - Principles for Unicode Code Point Inclusion in Labels in the DNS
Internationalized Domain Names in Applications (IDNA) makes available to DNS zone administrators a very wide range of Unicode code points. Most operators of zones should probably not permit registration of U-labels using the entire range. This is especially true of zones that accept registrations across organizational boundaries, such as top-level domains and, most importantly, the root. It is unfortunately not possible to generate algorithms to determine whether permitting a code point presents a low risk. This memo presents a set of principles that can be used to guide the decision of whether a Unicode code point may be wisely included in the repertoire of permissible code points in a U-label in a zone.
RFC6911 - RADIUS Attributes for IPv6 Access Networks
This document specifies additional IPv6 RADIUS Attributes useful in residential broadband network deployments. The Attributes, which are used for authorization and accounting, enable assignment of a host IPv6 address and an IPv6 DNS server address via DHCPv6, assignment of an IPv6 route announced via router advertisement, assignment of a named IPv6 delegated prefix pool, and assignment of a named IPv6 pool for host DHCPv6 addressing.
RFC6910 - Completion of Calls for the Session Initiation Protocol (SIP)
The "completion of calls" feature defined in this specification allows the caller of a failed call to be notified when the callee becomes available to receive a call.
The Source Address Validation Improvement (SAVI) effort aims to complement ingress filtering with finer-grained, standardized IP source address validation. This document describes threats enabled by IP source address spoofing both in the global and finer-grained context, describes currently available solutions and challenges, and provides a starting point analysis for finer-grained (host granularity) anti-spoofing work.
RFC6958 - RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Loss Metric Reporting
This document defines an RTP Control Protocol (RTCP) Extended Report (XR) Block that allows the reporting of burst and gap loss metrics for use in a range of RTP applications.
RFC6957 - Duplicate Address Detection Proxy
The document describes a proxy-based mechanism allowing the use of Duplicate Address Detection (DAD) by IPv6 nodes in a point-to-multipoint architecture with a "split-horizon" forwarding scheme, primarily deployed for Digital Subscriber Line (DSL) and Fiber access architectures. Based on the DAD signaling, the first-hop router stores in a Binding Table all known IPv6 addresses used on a point-to-multipoint domain (e.g., VLAN). When a node performs DAD for an address already used by another node, the first-hop router defends the address rather than the device using the address.
RFC6956 - Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library
This document defines basic classes of Logical Function Blocks (LFBs) used in Forwarding and Control Element Separation (ForCES). The basic LFB classes are defined according to the ForCES Forwarding Element (FE) model and ForCES protocol specifications; they are scoped to meet requirements of typical router functions and are considered the basic LFB library for ForCES. The library includes the descriptions of the LFBs and the XML definitions.
RFC6955 - Diffie-Hellman Proof-of-Possession Algorithms
This document describes two methods for producing an integrity check value from a Diffie-Hellman key pair and one method for producing an integrity check value from an Elliptic Curve key pair. This behavior is needed for such operations as creating the signature of a Public-Key Cryptography Standards (PKCS) #10 Certification Request. These algorithms are designed to provide a Proof-of-Possession of the private key and not to be a general purpose signing algorithm.
RFC6954 - Using the Elliptic Curve Cryptography (ECC) Brainpool Curves for the Internet Key Exchange Protocol Version 2 (IKEv2)
This document specifies use of the Elliptic Curve Cryptography (ECC) Brainpool elliptic curve groups for key exchange in the Internet Key Exchange Protocol version 2 (IKEv2).
RFC6953 - Protocol to Access White-Space (PAWS) Databases: Use Cases and Requirements
Portions of the radio spectrum that are assigned to a particular use but are unused or unoccupied at specific locations and times are defined as "white space". The concept of allowing additional transmissions (which may or may not be licensed) in white space is a technique to "unlock" existing spectrum for new use. This document includes the problem statement for the development of a protocol to access a database of white-space information followed by use cases and requirements for that protocol. Finally, requirements associated with the protocol are presented.
RFC6952 - Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide
This document analyzes TCP-based routing protocols, the Border Gateway Protocol (BGP), the Label Distribution Protocol (LDP), the Path Computation Element Communication Protocol (PCEP), and the Multicast Source Distribution Protocol (MSDP), according to guidelines set forth in Section 4.2 of "Keying and Authentication for Routing Protocols Design Guidelines", RFC 6518.
RFC6951 - UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication
This document describes a simple method of encapsulating Stream Control Transmission Protocol (SCTP) packets into UDP packets and its limitations. This allows the usage of SCTP in networks with legacy NATs that do not support SCTP. It can also be used to implement SCTP on hosts without directly accessing the IP layer, for example, implementing it as part of the application without requiring special privileges.
RFC6950 - Architectural Considerations on Application Features in the DNS
A number of Internet applications rely on the Domain Name System (DNS) to support their operations. Many applications use the DNS to locate services for a domain; some, for example, transform identifiers other than domain names into formats that the DNS can process, and then fetch application data or service location data from the DNS. Proposals incorporating sophisticated application behavior using DNS as a substrate have raised questions about the role of the DNS as an application platform. This document explores the architectural consequences of using the DNS to implement certain application features, and it provides guidance to future application designers as to the limitations of the DNS as a substrate and the situations in which alternative designs should be considered.
RFC6949 - RFC Series Format Requirements and Future Development
This document describes the current requirements and requests for enhancements for the format of the canonical version of RFCs. Terms are defined to help clarify exactly which stages of document production are under discussion for format changes. The requirements described in this document will determine what changes will be made to RFC format. This document updates RFC 2223.
RFC6948 - Some Measurements on World IPv6 Day from an End-User Perspective
During World IPv6 Day on June 8, 2011, several key content providers enabled their networks to offer both IPv4 and IPv6 services. Hundreds of organizations participated in this effort, and in the months and weeks leading up to the event worked hard on preparing their networks to support this event. The event was largely unnoticed by the general public, which is a good thing since it means that no major problems were detected. For the Internet, however, there was a major change on a short timescale. This memo discusses measurements that the authors made from the perspective of an end user with good IPv4 and IPv6 connectivity. Our measurements include the number of most popular networks providing AAAA records for their service, as well as delay and connection failure statistics.
RFC6947 - The Session Description Protocol (SDP) Alternate Connectivity (ALTC) Attribute
This document proposes a mechanism that allows the same SDP offer to carry multiple IP addresses of different address families (e.g., IPv4 and IPv6). The proposed attribute, the "altc" attribute, solves the backward-compatibility problem that plagued Alternative Network Address Types (ANAT) due to their syntax.
RFC6946 - Processing of IPv6 "Atomic" Fragments
The IPv6 specification allows packets to contain a Fragment Header without the packet being actually fragmented into multiple pieces (we refer to these packets as "atomic fragments"). Such packets are typically sent by hosts that have received an ICMPv6 "Packet Too Big" error message that advertises a Next-Hop MTU smaller than 1280 bytes, and are currently processed by some implementations as normal "fragmented traffic" (i.e., they are "reassembled" with any other queued fragments that supposedly correspond to the same original packet). Thus, an attacker can cause hosts to employ atomic fragments by forging ICMPv6 "Packet Too Big" error messages, and then launch any fragmentation-based attacks against such traffic. This document discusses the generation of the aforementioned atomic fragments and the corresponding security implications. Additionally, this document formally updates RFC 2460 and RFC 5722, such that IPv6 atomic fragments are processed independently of any other fragments, thus completely eliminating the aforementioned attack vector.
RFC6945 - Definitions of Managed Objects for the Resource Public Key Infrastructure (RPKI) to Router 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 used for monitoring the Resource Public Key Infrastructure (RPKI) to Router Protocol.
RFC6944 - Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status
The DNS Security Extensions (DNSSEC) requires the use of cryptographic algorithm suites for generating digital signatures over DNS data. There is currently an IANA registry for these algorithms, but there is no record of the recommended implementation status of each algorithm. This document provides an applicability statement on algorithm implementation status for DNSSEC component software. This document lists each algorithm's status based on the current reference. In the case that an algorithm is specified without an implementation status, this document assigns one. This document updates RFCs 2536, 2539, 3110, 4034, 4398, 5155, 5702, and 5933.
RFC6943 - Issues in Identifier Comparison for Security Purposes
Identifiers such as hostnames, URIs, IP addresses, and email addresses are often used in security contexts to identify security principals and resources. In such contexts, an identifier presented via some protocol is often compared using some policy to make security decisions such as whether the security principal may access the resource, what level of authentication or encryption is required, etc. If the parties involved in a security decision use different algorithms to compare identifiers, then failure scenarios ranging from denial of service to elevation of privilege can result. This document provides a discussion of these issues that designers should consider when defining identifiers and protocols, and when constructing architectures that use multiple protocols.
RFC6942 - Diameter Support for the EAP Re-authentication Protocol (ERP)
The EAP Re-authentication Protocol (ERP) defines extensions to the Extensible Authentication Protocol (EAP) to support efficient re-authentication between the peer and an EAP Re-authentication (ER) server through a compatible authenticator. This document specifies Diameter support for ERP. It defines a new Diameter ERP application to transport ERP messages between an ER authenticator and the ER server, and a set of new Attribute-Value Pairs (AVPs) that can be used to transport the cryptographic material needed by the re-authentication server.
RFC6941 - MPLS Transport Profile (MPLS-TP) Security Framework
This document provides a security framework for the MPLS Transport Profile (MPLS-TP). MPLS-TP extends MPLS technologies and introduces new Operations, Administration, and Maintenance (OAM) capabilities, a transport-oriented path protection mechanism, and strong emphasis on static provisioning supported by network management systems. This document addresses the security aspects relevant in the context of MPLS-TP specifically. It describes potential security threats as well as mitigation procedures related to MPLS-TP networks and to MPLS-TP interconnection to other MPLS and GMPLS networks. This document is built on RFC 5920 ("Security Framework for MPLS and GMPLS Networks") by providing additional security considerations that are applicable to the MPLS-TP extensions. All the security considerations from RFC 5920 are assumed to apply.
RFC6940 - REsource LOcation And Discovery (RELOAD) Base Protocol
This specification defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet. A P2P signaling protocol provides its clients with an abstract storage and messaging service between a set of cooperating peers that form the overlay network. RELOAD is designed to support a P2P Session Initiation Protocol (P2PSIP) network, but can be utilized by other applications with similar requirements by defining new usages that specify the Kinds of data that need to be stored for a particular application. RELOAD defines a security model based on a certificate enrollment service that provides unique identities. NAT traversal is a fundamental service of the protocol. RELOAD also allows access from "client" nodes that do not need to route traffic or store data for others.
RFC6939 - Client Link-Layer Address Option in DHCPv6
This document specifies the format and mechanism that is to be used for encoding the client link-layer address in DHCPv6 Relay-Forward messages by defining a new DHCPv6 Client Link-Layer Address option.
RFC6938 - Deprecation of BGP Path Attributes: DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID
This document requests IANA to deprecate the following BGP path attributes: DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID, associated with an abandoned Internet-Draft and a Historic RFC.
RFC6937 - Proportional Rate Reduction for TCP
This document describes an experimental Proportional Rate Reduction (PRR) algorithm as an alternative to the widely deployed Fast Recovery and Rate-Halving algorithms. These algorithms determine the amount of data sent by TCP during loss recovery. PRR minimizes excess window adjustments, and the actual window size at the end of recovery will be as close as possible to the ssthresh, as determined by the congestion control algorithm.
RFC6936 - Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums
This document provides an applicability statement for the use of UDP transport checksums with IPv6. It defines recommendations and requirements for the use of IPv6 UDP datagrams with a zero UDP checksum. It describes the issues and design principles that need to be considered when UDP is used with IPv6 to support tunnel encapsulations, and it examines the role of the IPv6 UDP transport checksum. The document also identifies issues and constraints for deployment on network paths that include middleboxes. An appendix presents a summary of the trade-offs that were considered in evaluating the safety of the update to RFC 2460 that changes the use of the UDP checksum with IPv6.
RFC6935 - IPv6 and UDP Checksums for Tunneled Packets
This document updates the IPv6 specification (RFC 2460) to improve performance when a tunnel protocol uses UDP with IPv6 to tunnel packets. The performance improvement is obtained by relaxing the IPv6 UDP checksum requirement for tunnel protocols whose header information is protected on the "inner" packet being carried. Relaxing this requirement removes the overhead associated with the computation of UDP checksums on IPv6 packets that carry the tunnel protocol packets. This specification describes how the IPv6 UDP checksum requirement can be relaxed when the encapsulated packet itself contains a checksum. It also describes the limitations and risks of this approach and discusses the restrictions on the use of this method.
RFC6934 - Applicability of the Access Node Control Mechanism to Broadband Networks Based on Passive Optical Networks (PONs)
The purpose of this document is to provide applicability of the Access Node Control Mechanism to broadband access based on Passive Optical Networks (PONs). The need for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node Complex, composed of a combination of Optical Line Termination (OLT) and Optical Network Termination (ONT) elements, is described in a multi-service reference architecture in order to perform QoS-related, service-related, and subscriber-related operations. The Access Node Control Mechanism is also extended for interaction between components of the Access Node Complex (OLT and ONT). The Access Node Control Mechanism will ensure that the transmission of information between the NAS and Access Node Complex (ANX) and between the OLT and ONT within an ANX does not need to go through distinct element managers but rather uses direct device-to-device communication and stays on net. This allows for performing access-link-related operations within those network elements to meet performance objectives.
RFC6933 - Entity MIB (Version 4)
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single Simple Network Management Protocol (SNMP) agent. This document specifies version 4 of the Entity MIB. This memo obsoletes version 3 of the Entity MIB module published as RFC 4133.
RFC6932 - Brainpool Elliptic Curves for the Internet Key Exchange (IKE) Group Description Registry
This memo allocates code points for four new elliptic curve domain parameter sets over finite prime fields into a registry that was established by the Internet Key Exchange (IKE) but is used by other protocols.
RFC6931 - Additional XML Security Uniform Resource Identifiers (URIs)
This document expands, updates, and establishes an IANA registry for the list of URIs intended for use with XML digital signatures, encryption, canonicalization, and key management. These URIs identify algorithms and types of information. This document obsoletes RFC 4051.
RFC6930 - RADIUS Attribute for IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)
The IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) provides both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 coexistence period. The Dynamic Host Configuration Protocol (DHCP) 6rd option has been defined to configure the 6rd Customer Edge (CE). However, in many networks, the configuration information may be stored in the Authentication Authorization and Accounting (AAA) servers, while user configuration is mainly acquired from a Broadband Network Gateway (BNG) through the DHCP protocol. This document defines a Remote Authentication Dial-In User Service (RADIUS) attribute that carries 6rd configuration information from the AAA server to BNGs.
RFC6929 - Remote Authentication Dial In User Service (RADIUS) Protocol Extensions
The Remote Authentication Dial-In User Service (RADIUS) protocol is nearing exhaustion of its current 8-bit Attribute Type space. In addition, experience shows a growing need for complex grouping, along with attributes that can carry more than 253 octets of data. This document defines changes to RADIUS that address all of the above problems.
RFC6928 - Increasing TCP's Initial Window
This document proposes an experiment to increase the permitted TCP initial window (IW) from between 2 and 4 segments, as specified in RFC 3390, to 10 segments with a fallback to the existing recommendation when performance issues are detected. It discusses the motivation behind the increase, the advantages and disadvantages of the higher initial window, and presents results from several large-scale experiments showing that the higher initial window improves the overall performance of many web services without resulting in a congestion collapse. The document closes with a discussion of usage and deployment for further experimental purposes recommended by the IETF TCP Maintenance and Minor Extensions (TCPM) working group.
RFC6927 - Variants in Second-Level Names Registered in Top-Level Domains
Internationalized Domain Names for Applications (IDNA) provides a method to map a subset of names written in Unicode into the DNS. Because of Unicode decisions, appearance, language and writing system conventions, and historical reasons, it often has been asserted that there is more than one way to write what competent readers and writers think of as the same host name; these different ways of writing are often called "variants". (The authors note that there are many conflicting definitions for the term "variant" in the IDNA community.) This document surveys the approaches that top-level domains have taken to the registration and provisioning of domain names that have variants. This document is not a product of the IETF, does not propose any method to make variants work "correctly", and is not an introduction to internationalization or IDNA.
RFC6926 - DHCPv4 Bulk Leasequery
The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Leasequery protocol allows a requestor to request information about DHCPv4 bindings. This protocol is limited to queries for individual bindings. In some situations, individual binding queries may not be efficient or even possible. This document extends the DHCPv4 Leasequery protocol to allow for bulk transfer of DHCPv4 address binding data via TCP.
RFC6925 - The DHCPv4 Relay Agent Identifier Sub-Option
This document defines a new Relay Agent Identifier sub-option for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information option. The sub-option carries a value that uniquely identifies the relay agent device within the administrative domain. The value is normally administratively configured in the relay agent. The sub-option allows a DHCP relay agent to include the identifier in the DHCP messages it sends.
RFC6924 - Registration of Second-Level URN Namespaces under "ietf"
RFC 2648 defines the "ietf" URN namespace and a number of sub- namespaces. RFC 3553 defines an additional sub-namespace, "params", and creates a registry to document allocations under that. But there is no registry that lists, in one place, all sub-namespaces of "ietf". This document creates and populates such a registry, thereby changing the mechanism defined in RFC 2648 for adding new sub- namespaces of "ietf".
RFC6923 - MPLS Transport Profile (MPLS-TP) Identifiers Following ITU-T Conventions
This document specifies an extension to the identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP). Identifiers that follow IP/MPLS conventions have already been defined. This memo augments that set of identifiers for MPLS-TP management and Operations, Administration, and Maintenance (OAM) functions to include identifier information in a format typically used by the International Telecommunication Union Telecommunication Standardization Sector (ITU-T).
RFC6922 - The application/sql Media Type
This document registers the application/sql media type to be used for the Structured Query Language (SQL).
RFC6921 - Design Considerations for Faster-Than-Light (FTL) Communication
We are approaching the time when we will be able to communicate faster than the speed of light. It is well known that as we approach the speed of light, time slows down. Logically, it is reasonable to assume that as we go faster than the speed of light, time will reverse. The major consequence of this for Internet protocols is that packets will arrive before they are sent. This will have a major impact on the way we design Internet protocols. This paper outlines some of the issues and suggests some directions for additional analysis of these issues.
RFC6920 - Naming Things with Hashes
This document defines a set of ways to identify a thing (a digital object in this case) using the output from a hash function. It specifies a new URI scheme for this purpose, a way to map these to HTTP URLs, and binary and human-speakable formats for these names. The various formats are designed to support, but not require, a strong link to the referenced object, such that the referenced object may be authenticated to the same degree as the reference to it. The reason for this work is to standardise current uses of hash outputs in URLs and to support new information-centric applications and other uses of hash outputs in protocols.
RFC6919 - Further Key Words for Use in RFCs to Indicate Requirement Levels
RFC 2119 defines a standard set of key words for describing requirements of a specification. Many IETF documents have found that these words cannot accurately capture the nuanced requirements of their specification. This document defines additional key words that can be used to address alternative requirements scenarios. Authors who follow these guidelines should incorporate this phrase near the beginning of their document:
RFC6918 - Formally Deprecating Some ICMPv4 Message Types
A number of ICMPv4 message types have become obsolete in practice, but have never been formally deprecated. This document deprecates such ICMPv4 message types, thus cleaning up the corresponding IANA registry. Additionally, it updates RFC 792 and RFC 950, obsoletes RFC 1788, and requests the RFC Editor to change the status of RFC 1788 to Historic.
RFC6917 - Media Resource Brokering
The MediaCtrl working group in the IETF has proposed an architecture for controlling media services. The Session Initiation Protocol (SIP) is used as the signaling protocol that provides many inherent capabilities for message routing. In addition to such signaling properties, a need exists for intelligent, application-level media service selection based on non-static signaling properties. This is especially true when considered in conjunction with deployment architectures that include 1:M and M:N combinations of Application Servers and Media Servers. This document introduces a Media Resource Broker (MRB) entity, which manages the availability of Media Servers and the media resource demands of Application Servers. The document includes potential deployment options for an MRB and appropriate interfaces to Application Servers and Media Servers.
RFC6916 - Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)
This document specifies the process that Certification Authorities (CAs) and Relying Parties (RPs) participating in the Resource Public Key Infrastructure (RPKI) will need to follow to transition to a new (and probably cryptographically stronger) algorithm set. The process is expected to be completed over a timescale of several years. Consequently, no emergency transition is specified. The transition procedure defined in this document supports only a top-down migration (parent migrates before children).
RFC6915 - Flow Identity Extension for HTTP-Enabled Location Delivery (HELD)
RFC 6155 specifies an extension for the HTTP-Enabled Location Delivery (HELD) protocol, allowing the use of an IP address and port number to request a Device location based on an individual packet flow.
RFC6914 - SIMPLE Made Simple: An Overview of the IETF Specifications for Instant Messaging and Presence Using the Session Initiation Protocol (SIP)
The IETF has produced many specifications related to Presence and Instant Messaging with the Session Initiation Protocol (SIP). Collectively, these specifications are known as SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE). This document serves as a guide to the SIMPLE suite of specifications. It categorizes the specifications, explains what each is for, and how they relate to each other.
RFC6913 - Indicating Fax over IP Capability in the Session Initiation Protocol (SIP)
This document defines and registers with IANA the new "fax" media feature tag for use with the Session Initiation Protocol (SIP). Currently, fax calls are indistinguishable from voice calls at call initiation. Consequently, fax calls can be routed to SIP user agents that are not fax capable. A "fax" media feature tag implemented in conjunction with caller preferences allows for more accurate fax call routing.
RFC6912 - Principles for Unicode Code Point Inclusion in Labels in the DNS
Internationalized Domain Names in Applications (IDNA) makes available to DNS zone administrators a very wide range of Unicode code points. Most operators of zones should probably not permit registration of U-labels using the entire range. This is especially true of zones that accept registrations across organizational boundaries, such as top-level domains and, most importantly, the root. It is unfortunately not possible to generate algorithms to determine whether permitting a code point presents a low risk. This memo presents a set of principles that can be used to guide the decision of whether a Unicode code point may be wisely included in the repertoire of permissible code points in a U-label in a zone.
RFC6911 - RADIUS Attributes for IPv6 Access Networks
This document specifies additional IPv6 RADIUS Attributes useful in residential broadband network deployments. The Attributes, which are used for authorization and accounting, enable assignment of a host IPv6 address and an IPv6 DNS server address via DHCPv6, assignment of an IPv6 route announced via router advertisement, assignment of a named IPv6 delegated prefix pool, and assignment of a named IPv6 pool for host DHCPv6 addressing.
RFC6910 - Completion of Calls for the Session Initiation Protocol (SIP)
The "completion of calls" feature defined in this specification allows the caller of a failed call to be notified when the callee becomes available to receive a call.