RFC Abstracts
RFC6074 - Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)
Provider Provisioned Layer 2 Virtual Private Networks (L2VPNs) may have different "provisioning models", i.e., models for what information needs to be configured in what entities. Once configured, the provisioning information is distributed by a "discovery process". When the discovery process is complete, a signaling protocol is automatically invoked to set up the mesh of pseudowires (PWs) that form the (virtual) backbone of the L2VPN. This document specifies a number of L2VPN provisioning models, and further specifies the semantic structure of the endpoint identifiers required by each model. It discusses the distribution of these identifiers by the discovery process, especially when discovery is based on the Border Gateway Protocol (BGP). It then specifies how the endpoint identifiers are carried in the two signaling protocols that are used to set up PWs, the Label Distribution Protocol (LDP), and the Layer 2 Tunneling Protocol version 3 (L2TPv3). [STANDARDS- TRACK]
RFC6073 - Segmented Pseudowire
This document describes how to connect pseudowires (PWs) between different Packet Switched Network (PSN) domains or between two or more distinct PW control plane domains, where a control plane domain uses a common control plane protocol or instance of that protocol for a given PW. The different PW control plane domains may belong to independent autonomous systems, or the PSN technology is heterogeneous, or a PW might need to be aggregated at a specific PSN point. The PW packet data units are simply switched from one PW to another without changing the PW payload. [STANDARDS-TRACK]
RFC6072 - Certificate Management Service for the Session Initiation Protocol (SIP)
This document defines a credential service that allows Session Initiation Protocol (SIP) User Agents (UAs) to use a SIP event package to discover the certificates of other users. This mechanism allows User Agents that want to contact a given Address-of-Record (AOR) to retrieve that AOR's certificate by subscribing to the credential service, which returns an authenticated response containing that certificate. The credential service also allows users to store and retrieve their own certificates and private keys. [STANDARDS-TRACK]
RFC6071 - IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap
Over the past few years, the number of RFCs that define and use IPsec and Internet Key Exchange (IKE) has greatly proliferated. This is complicated by the fact that these RFCs originate from numerous IETF working groups: the original IPsec WG, its various spin-offs, and other WGs that use IPsec and/or IKE to protect their protocols' traffic.
RFC6070 - PKCS #5: Password-Based Key Derivation Function 2 (PBKDF2) Test Vectors
This document contains test vectors for the Public-Key Cryptography Standards (PKCS) #5 Password-Based Key Derivation Function 2 (PBKDF2) with the Hash-based Message Authentication Code (HMAC) Secure Hash Algorithm (SHA-1) pseudorandom function. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6069 - Making TCP More Robust to Long Connectivity Disruptions (TCP-LCD)
Disruptions in end-to-end path connectivity, which last longer than one retransmission timeout, cause suboptimal TCP performance. The reason for this performance degradation is that TCP interprets segment loss induced by long connectivity disruptions as a sign of congestion, resulting in repeated retransmission timer backoffs. This, in turn, leads to a delayed detection of the re-establishment of the connection since TCP waits for the next retransmission timeout before it attempts a retransmission.
RFC6068 - The 'mailto' URI Scheme
This document defines the format of Uniform Resource Identifiers (URIs) to identify resources that are reached using Internet mail. It adds better internationalization and compatibility with Internationalized Resource Identifiers (IRIs; RFC 3987) to the previous syntax of 'mailto' URIs (RFC 2368). [STANDARDS-TRACK]
RFC6067 - BCP 47 Extension U
This document specifies an Extension to BCP 47 that provides subtags that specify language and/or locale-based behavior or refinements to language tags, according to work done by the Unicode Consortium. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6066 - Transport Layer Security (TLS) Extensions: Extension Definitions
This document provides specifications for existing TLS extensions. It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. [STANDARDS-TRACK]
RFC6065 - Using Authentication, Authorization, and Accounting Services to Dynamically Provision View-Based Access Control Model User-to-Group Mappings
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. It describes the use of information provided by Authentication, Authorization, and Accounting (AAA) services, such as the Remote Authentication Dial-In User Service (RADIUS), to dynamically update user-to-group mappings in the View-based Access Control Model (VACM). [STANDARDS-TRACK]
RFC6064 - SDP and RTSP Extensions Defined for 3GPP Packet-Switched Streaming Service and Multimedia Broadcast/Multicast Service
The Packet-switched Streaming Service (PSS) and the Multimedia Broadcast/Multicast Service (MBMS) defined by 3GPP use the Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) with some extensions. This document provides information about these extensions and registers the RTSP and SDP extensions with IANA. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6063 - Dynamic Symmetric Key Provisioning Protocol (DSKPP)
The Dynamic Symmetric Key Provisioning Protocol (DSKPP) is a client-server protocol for initialization (and configuration) of symmetric keys to locally and remotely accessible cryptographic modules. The protocol can be run with or without private key capabilities in the cryptographic modules and with or without an established public key infrastructure.
RFC6062 - Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations
This specification defines an extension of Traversal Using Relays around NAT (TURN), a relay protocol for Network Address Translator (NAT) traversal. This extension allows a TURN client to request TCP allocations, and defines new requests and indications for the TURN server to open and accept TCP connections with the client\'s peers. TURN and this extension both purposefully restrict the ways in which the relayed address can be used. In particular, it prevents users from running general-purpose servers from ports obtained from the TURN server. [STANDARDS-TRACK]
RFC6061 - Uniform Resource Name (URN) Namespace for the National Emergency Number Association (NENA)
This document describes the Namespace Identifier (NID) "nena" for Uniform Resource Name (URN) resources published by the National Emergency Number Association (NENA). NENA defines and manages resources that utilize this URN model. Management activities for these and other resource types are provided by the NENA Registry System (NRS). This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6060 - Generalized Multiprotocol Label Switching (GMPLS) Control of Ethernet Provider Backbone Traffic Engineering (PBB-TE)
This specification is complementary to the GMPLS Ethernet Label Switching Architecture and Framework and describes the technology-specific aspects of GMPLS control for Provider Backbone Bridge Traffic Engineering (PBB-TE). The necessary GMPLS extensions and mechanisms are described to establish Ethernet PBB-TE point-to-point (P2P) and point-to-multipoint (P2MP) connections. This document supports, but does not modify, the standard IEEE data plane. [STANDARDS-TRACK]
RFC6059 - Simple Procedures for Detecting Network Attachment in IPv6
Detecting Network Attachment allows hosts to assess if its existing addressing or routing configuration is valid for a newly connected network. This document provides simple procedures for Detecting Network Attachment in IPv6 hosts, and procedures for routers to support such services. [STANDARDS-TRACK]
RFC6058 - Transient Binding for Proxy Mobile IPv6
This document specifies a mechanism that enhances Proxy Mobile IPv6 protocol signaling to support the creation of a transient binding cache entry that is used to optimize the performance of dual radio handover, as well as single radio handover. This mechanism is applicable to the mobile node's inter-MAG (Mobility Access Gateway) handover while using a single interface or different interfaces. The handover problem space using the Proxy Mobile IPv6 base protocol is analyzed and the use of transient binding cache entries at the local mobility anchor is described. The specified extension to the Proxy Mobile IPv6 protocol ensures optimized forwarding of downlink as well as uplink packets between mobile nodes and the network infrastructure and avoids superfluous packet forwarding delay or even packet loss. This document defines an Experimental Protocol for the Internet community.
RFC6057 - Comcast's Protocol-Agnostic Congestion Management System
This document describes the congestion management system of Comcast Cable, a large cable broadband Internet Service Provider (ISP) in the U.S. Comcast completed deployment of this congestion management system on December 31, 2008. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6056 - Recommendations for Transport-Protocol Port Randomization
During the last few years, awareness has been raised about a number of "blind" attacks that can be performed against the Transmission Control Protocol (TCP) and similar protocols. The consequences of these attacks range from throughput reduction to broken connections or data corruption. These attacks rely on the attacker's ability to guess or know the five-tuple (Protocol, Source Address, Destination Address, Source Port, Destination Port) that identifies the transport protocol instance to be attacked. This document describes a number of simple and efficient methods for the selection of the client port number, such that the possibility of an attacker guessing the exact value is reduced. While this is not a replacement for cryptographic methods for protecting the transport-protocol instance, the aforementioned port selection algorithms provide improved security with very little effort and without any key management overhead. The algorithms described in this document are local policies that may be incrementally deployed and that do not violate the specifications of any of the transport protocols that may benefit from them, such as TCP, UDP, UDP-lite, Stream Control Transmission Protocol (SCTP), Datagram Congestion Control Protocol (DCCP), and RTP (provided that the RTP application explicitly signals the RTP and RTCP port numbers). This memo documents an Internet Best Current Practice.
RFC6055 - IAB Thoughts on Encodings for Internationalized Domain Names
This document explores issues with Internationalized Domain Names (IDNs) that result from the use of various encoding schemes such as UTF-8 and the ASCII-Compatible Encoding produced by the Punycode algorithm. It focuses on the importance of agreeing on a single encoding and how complicated the state of affairs ends up being as a result of using different encodings today.
RFC6054 - Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic
Counter modes have been defined for block ciphers such as the Advanced Encryption Standard (AES). Counter modes use a counter, which is typically assumed to be incremented by a single sender. This memo describes the use of counter modes when applied to the Encapsulating Security Payload (ESP) and Authentication Header (AH) in multiple-sender group applications. [STANDARDS-TRACK]
RFC6053 - Implementation Report for Forwarding and Control Element Separation (ForCES)
Forwarding and Control Element Separation (ForCES) defines an architectural framework and associated protocols to standardize information exchange between the control plane and the forwarding plane in a ForCES network element (ForCES NE). RFC 3654 has defined the ForCES requirements, and RFC 3746 has defined the ForCES framework.
RFC6052 - IPv6 Addressing of IPv4/IPv6 Translators
This document discusses the algorithmic translation of an IPv6 address to a corresponding IPv4 address, and vice versa, using only statically configured information. It defines a well-known prefix for use in algorithmic translations, while allowing organizations to also use network-specific prefixes when appropriate. Algorithmic translation is used in IPv4/IPv6 translators, as well as other types of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. [STANDARDS-TRACK]
RFC6051 - Rapid Synchronisation of RTP Flows
This memo outlines how RTP sessions are synchronised, and discusses how rapidly such synchronisation can occur. We show that most RTP sessions can be synchronised immediately, but that the use of video switching multipoint conference units (MCUs) or large source-specific multicast (SSM) groups can greatly increase the synchronisation delay. This increase in delay can be unacceptable to some applications that use layered and/or multi-description codecs.
RFC6050 - A Session Initiation Protocol (SIP) Extension for the Identification of Services
This document describes private extensions to the Session Initiation Protocol (SIP) that enable a network of trusted SIP servers to assert the service of authenticated users. The use of these extensions is only applicable inside an administrative domain with previously agreed-upon policies for generation, transport, and usage of such information. This document does NOT offer a general service identification model suitable for use between different trust domains or for use in the Internet at large.
RFC6049 - Spatial Composition of Metrics
This memo utilizes IP performance metrics that are applicable to both complete paths and sub-paths, and it defines relationships to compose a complete path metric from the sub-path metrics with some accuracy with regard to the actual metrics. This is called "spatial composition" in RFC 2330. The memo refers to the framework for metric composition, and provides background and motivation for combining metrics to derive others. The descriptions of several composed metrics and statistics follow. [STANDARDS-TRACK]
RFC6048 - Network News Transfer Protocol (NNTP) Additions to LIST Command
This document defines a set of enhancements to the Network News Transfer Protocol (NNTP) that allow a client to request extended information from NNTP servers regarding server status, policy, and other aspects of local configuration. These enhancements are made as new keywords to the existing LIST capability described in RFC 3977.
RFC6047 - iCalendar Message-Based Interoperability Protocol (iMIP)
This document, "iCalendar Message-Based Interoperability Protocol (iMIP)", specifies a binding from the iCalendar Transport-independent Interoperability Protocol (iTIP) to Internet email-based transports. Calendaring entries defined by the iCalendar Object Model (iCalendar) are wrapped using constructs from RFC 5322 and MIME (RFC 2045, RFC 2046, RFC 2047, and RFC 2049), and then transported over SMTP. [STANDARDS-TRACK]
RFC6046 - Transport of Real-time Inter-network Defense (RID) Messages
The Incident Object Description Exchange Format (IODEF) defines a common XML format for document exchange, and Real-time Inter-network Defense (RID) defines extensions to IODEF intended for the cooperative handling of security incidents within consortia of network operators and enterprises. This document specifies a transport protocol for RID based upon the passing of RID messages over HTTP/TLS (Transport Layer Security). This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6045 - Real-time Inter-network Defense (RID)
Network security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system. Network providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations.
RFC6044 - Mapping and Interworking of Diversion Information between Diversion and History-Info Headers in the Session Initiation Protocol (SIP)
Although the SIP History-Info header is the solution adopted in IETF, the non-standard Diversion header is nevertheless widely implemented and used for conveying call-diversion-related information in SIP signaling.
RFC6043 - MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY)
The Multimedia Internet KEYing (MIKEY) specification describes a key management scheme for real-time applications. In this document, we note that the currently defined MIKEY modes are insufficient to address deployment scenarios built around a centralized key management service. Interest in such deployments is increasing. Therefore, a set of new MIKEY modes that work well in such scenarios are defined. The new modes use a trusted key management service and a ticket concept, similar to that in Kerberos. The new modes also support features used by many existing applications, where the exact identity of the other endpoint may not be known at the start of the communication session. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6042 - Transport Layer Security (TLS) Authorization Using KeyNote
This document specifies the use of the KeyNote trust-management system as an authorization extension in the Transport Layer Security (TLS) Handshake Protocol, according to guidelines in RFC 5878. Extensions carried in the client and server hello messages confirm that both parties support the desired authorization data types. Then, if supported by both the client and the server, KeyNote credentials are exchanged in the supplemental data handshake message. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6041 - Forwarding and Control Element Separation (ForCES) Applicability Statement
The Forwarding and Control Element Separation (ForCES) protocol defines a standard framework and mechanism for the interconnection between control elements and forwarding elements in IP routers and similar devices. In this document we describe the applicability of the ForCES model and protocol. We provide example deployment scenarios and functionality, as well as document applications that would be inappropriate for ForCES. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6040 - Tunnelling of Explicit Congestion Notification
This document redefines how the explicit congestion notification (ECN) field of the IP header should be constructed on entry to and exit from any IP-in-IP tunnel. On encapsulation, it updates RFC 3168 to bring all IP-in-IP tunnels (v4 or v6) into line with RFC 4301 IPsec ECN processing. On decapsulation, it updates both RFC 3168 and RFC 4301 to add new behaviours for previously unused combinations of inner and outer headers. The new rules ensure the ECN field is correctly propagated across a tunnel whether it is used to signal one or two severity levels of congestion; whereas before, only one severity level was supported. Tunnel endpoints can be updated in any order without affecting pre-existing uses of the ECN field, thus ensuring backward compatibility. Nonetheless, operators wanting to support two severity levels (e.g., for pre-congestion notification -- PCN) can require compliance with this new specification. A thorough analysis of the reasoning for these changes and the implications is included. In the unlikely event that the new rules do not meet a specific need, RFC 4774 gives guidance on designing alternate ECN semantics, and this document extends that to include tunnelling issues. [STANDARDS-TRACK]
RFC6039 - Issues with Existing Cryptographic Protection Methods for Routing Protocols
Routing protocols have been extended over time to use cryptographic mechanisms to ensure that data received from a neighboring router has not been modified in transit and actually originated from an authorized neighboring router.
RFC6038 - Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features
This memo describes two closely related features for the core specification of the Two-Way Active Measurement Protocol (TWAMP): an optional capability where the responding host returns some of the command octets or padding octets to the sender, and an optional sender packet format that ensures equal test packet sizes are used in both directions. [STANDARDS-TRACK]
RFC6037 - Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs
This document describes the MVPN (Multicast in BGP/MPLS IP VPNs) solution designed and deployed by Cisco Systems. The procedures specified in this document are largely a subset of the generalized MVPN framework recently standardized by the IETF. However, as the deployment of the procedures specified herein predates the publication of IETF standards (in some cases by over five years), an implementation based on these procedures differs in some respects from a fully standards-compliant implementation. These differences are pointed out in the document. This document defines a Historic Document for the Internet community.
RFC6036 - Emerging Service Provider Scenarios for IPv6 Deployment
This document describes practices and plans that are emerging among Internet Service Providers for the deployment of IPv6 services. They are based on practical experience so far, as well as current plans and requirements, reported in a survey of a number of ISPs carried out in early 2010. This document identifies a number of technology gaps, but it does not make recommendations. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6035 - Session Initiation Protocol Event Package for Voice Quality Reporting
This document defines a Session Initiation Protocol (SIP) event package that enables the collection and reporting of metrics that measure the quality for Voice over Internet Protocol (VoIP) sessions. Voice call quality information derived from RTP Control Protocol Extended Reports (RTCP-XR) and call information from SIP is conveyed from a User Agent (UA) in a session, known as a reporter, to a third party, known as a collector. A registration for the application/ vq-rtcpxr media type is also included. [STANDARDS-TRACK]
RFC6034 - Unicast-Prefix-Based IPv4 Multicast Addresses
This specification defines an extension to the multicast addressing architecture of the IP Version 4 protocol. The extension presented in this document allows for unicast-prefix-based assignment of multicast addresses. By delegating multicast addresses at the same time as unicast prefixes, network operators will be able to identify their multicast addresses without needing to run an inter-domain allocation protocol. [STANDARDS-TRACK]
RFC6033 - Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type
This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) encrypted key package content type. Specifically, it includes conventions necessary to implement EnvelopedData, EncryptedData, and AuthEnvelopedData. [STANDARDS-TRACK]
RFC6032 - Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type
This document defines the Cryptographic Message Syntax (CMS) encrypted key package content type, which can be used to encrypt a content that includes a key package, such as a symmetric key package or an asymmetric key package. It is transport independent. CMS can be used to digitally sign, digest, authenticate, or further encrypt this content type. It is designed to be used with the CMS Content Constraints (CCC) extension, which does not constrain the EncryptedData, EnvelopedData, and AuthEnvelopedData. [STANDARDS-TRACK]
RFC6031 - Cryptographic Message Syntax (CMS) Symmetric Key Package Content Type
This document defines the symmetric key format content type. It is transport independent. The Cryptographic Message Syntax (CMS) can be used to digitally sign, digest, authenticate, or encrypt this content type. [STANDARDS-TRACK]
RFC6030 - Portable Symmetric Key Container (PSKC)
This document specifies a symmetric key format for the transport and provisioning of symmetric keys to different types of crypto modules. For example, One-Time Password (OTP) shared secrets or symmetric cryptographic keys to strong authentication devices. A standard key transport format enables enterprises to deploy best-of-breed solutions combining components from different vendors into the same infrastructure. [STANDARDS-TRACK]
RFC6029 - A Survey on Research on the Application-Layer Traffic Optimization (ALTO) Problem
A significant part of the Internet traffic today is generated by peer-to-peer (P2P) applications used originally for file sharing, and more recently for real-time communications and live media streaming. Such applications discover a route to each other through an overlay network with little knowledge of the underlying network topology. As a result, they may choose peers based on information deduced from empirical measurements, which can lead to suboptimal choices. This document, a product of the P2P Research Group, presents a survey of existing literature on discovering and using network topology information for Application-Layer Traffic Optimization. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6028 - Host Identity Protocol (HIP) Multi-Hop Routing Extension
This document specifies two extensions to the Host Identity Protocol (HIP) to implement multi-hop routing. The first extension allows implementing source routing in HIP. That is, a node sending a HIP packet can define a set of nodes that the HIP packet should traverse. The second extension allows a HIP packet to carry and record the list of nodes that forwarded it. This document defines an Experimental Protocol for the Internet community.
RFC6027 - IPsec Cluster Problem Statement
This document defines the terminology, problem statement, and requirements for implementing Internet Key Exchange (IKE) and IPsec on clusters. It also describes gaps in existing standards and their implementation that need to be filled in order to allow peers to interoperate with clusters from different vendors. Agreed upon terminology, problem statement, and requirements will allow IETF working groups to consider development of IPsec/IKEv2 mechanisms to simplify cluster implementations. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6026 - Correct Transaction Handling for 2xx Responses to Session Initiation Protocol (SIP) INVITE Requests
This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address an error in the specified handling of success (2xx class) responses to INVITE requests. Elements following RFC 3261 exactly will misidentify retransmissions of the request as a new, unassociated request. The correction involves modifying the INVITE transaction state machines. The correction also changes the way responses that cannot be matched to an existing transaction are handled to address a security risk. [STANDARDS-TRACK]
RFC6025 - ASN.1 Translation
Abstract Syntax Notation One (ASN.1) is widely used throughout the IETF Security Area and has been for many years. Some specifications were written using a now deprecated version of ASN.1 and some were written using the current version of ASN.1. Not all ASN.1 compilers support both older and current syntax. This document is intended to provide guidance to specification authors and to implementers converting ASN.1 modules from one version of ASN.1 to another version without causing changes to the "bits on the wire". This document does not provide a comprehensive tutorial of any version of ASN.1. Instead, it addresses ASN.1 features that are used in IETF Security Area specifications with a focus on items that vary with the ASN.1 version. This document is not an Internet Standards Track specification; it is published for informational purposes.
Provider Provisioned Layer 2 Virtual Private Networks (L2VPNs) may have different "provisioning models", i.e., models for what information needs to be configured in what entities. Once configured, the provisioning information is distributed by a "discovery process". When the discovery process is complete, a signaling protocol is automatically invoked to set up the mesh of pseudowires (PWs) that form the (virtual) backbone of the L2VPN. This document specifies a number of L2VPN provisioning models, and further specifies the semantic structure of the endpoint identifiers required by each model. It discusses the distribution of these identifiers by the discovery process, especially when discovery is based on the Border Gateway Protocol (BGP). It then specifies how the endpoint identifiers are carried in the two signaling protocols that are used to set up PWs, the Label Distribution Protocol (LDP), and the Layer 2 Tunneling Protocol version 3 (L2TPv3). [STANDARDS- TRACK]
RFC6073 - Segmented Pseudowire
This document describes how to connect pseudowires (PWs) between different Packet Switched Network (PSN) domains or between two or more distinct PW control plane domains, where a control plane domain uses a common control plane protocol or instance of that protocol for a given PW. The different PW control plane domains may belong to independent autonomous systems, or the PSN technology is heterogeneous, or a PW might need to be aggregated at a specific PSN point. The PW packet data units are simply switched from one PW to another without changing the PW payload. [STANDARDS-TRACK]
RFC6072 - Certificate Management Service for the Session Initiation Protocol (SIP)
This document defines a credential service that allows Session Initiation Protocol (SIP) User Agents (UAs) to use a SIP event package to discover the certificates of other users. This mechanism allows User Agents that want to contact a given Address-of-Record (AOR) to retrieve that AOR's certificate by subscribing to the credential service, which returns an authenticated response containing that certificate. The credential service also allows users to store and retrieve their own certificates and private keys. [STANDARDS-TRACK]
RFC6071 - IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap
Over the past few years, the number of RFCs that define and use IPsec and Internet Key Exchange (IKE) has greatly proliferated. This is complicated by the fact that these RFCs originate from numerous IETF working groups: the original IPsec WG, its various spin-offs, and other WGs that use IPsec and/or IKE to protect their protocols' traffic.
RFC6070 - PKCS #5: Password-Based Key Derivation Function 2 (PBKDF2) Test Vectors
This document contains test vectors for the Public-Key Cryptography Standards (PKCS) #5 Password-Based Key Derivation Function 2 (PBKDF2) with the Hash-based Message Authentication Code (HMAC) Secure Hash Algorithm (SHA-1) pseudorandom function. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6069 - Making TCP More Robust to Long Connectivity Disruptions (TCP-LCD)
Disruptions in end-to-end path connectivity, which last longer than one retransmission timeout, cause suboptimal TCP performance. The reason for this performance degradation is that TCP interprets segment loss induced by long connectivity disruptions as a sign of congestion, resulting in repeated retransmission timer backoffs. This, in turn, leads to a delayed detection of the re-establishment of the connection since TCP waits for the next retransmission timeout before it attempts a retransmission.
RFC6068 - The 'mailto' URI Scheme
This document defines the format of Uniform Resource Identifiers (URIs) to identify resources that are reached using Internet mail. It adds better internationalization and compatibility with Internationalized Resource Identifiers (IRIs; RFC 3987) to the previous syntax of 'mailto' URIs (RFC 2368). [STANDARDS-TRACK]
RFC6067 - BCP 47 Extension U
This document specifies an Extension to BCP 47 that provides subtags that specify language and/or locale-based behavior or refinements to language tags, according to work done by the Unicode Consortium. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6066 - Transport Layer Security (TLS) Extensions: Extension Definitions
This document provides specifications for existing TLS extensions. It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. [STANDARDS-TRACK]
RFC6065 - Using Authentication, Authorization, and Accounting Services to Dynamically Provision View-Based Access Control Model User-to-Group Mappings
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. It describes the use of information provided by Authentication, Authorization, and Accounting (AAA) services, such as the Remote Authentication Dial-In User Service (RADIUS), to dynamically update user-to-group mappings in the View-based Access Control Model (VACM). [STANDARDS-TRACK]
RFC6064 - SDP and RTSP Extensions Defined for 3GPP Packet-Switched Streaming Service and Multimedia Broadcast/Multicast Service
The Packet-switched Streaming Service (PSS) and the Multimedia Broadcast/Multicast Service (MBMS) defined by 3GPP use the Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) with some extensions. This document provides information about these extensions and registers the RTSP and SDP extensions with IANA. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6063 - Dynamic Symmetric Key Provisioning Protocol (DSKPP)
The Dynamic Symmetric Key Provisioning Protocol (DSKPP) is a client-server protocol for initialization (and configuration) of symmetric keys to locally and remotely accessible cryptographic modules. The protocol can be run with or without private key capabilities in the cryptographic modules and with or without an established public key infrastructure.
RFC6062 - Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations
This specification defines an extension of Traversal Using Relays around NAT (TURN), a relay protocol for Network Address Translator (NAT) traversal. This extension allows a TURN client to request TCP allocations, and defines new requests and indications for the TURN server to open and accept TCP connections with the client\'s peers. TURN and this extension both purposefully restrict the ways in which the relayed address can be used. In particular, it prevents users from running general-purpose servers from ports obtained from the TURN server. [STANDARDS-TRACK]
RFC6061 - Uniform Resource Name (URN) Namespace for the National Emergency Number Association (NENA)
This document describes the Namespace Identifier (NID) "nena" for Uniform Resource Name (URN) resources published by the National Emergency Number Association (NENA). NENA defines and manages resources that utilize this URN model. Management activities for these and other resource types are provided by the NENA Registry System (NRS). This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6060 - Generalized Multiprotocol Label Switching (GMPLS) Control of Ethernet Provider Backbone Traffic Engineering (PBB-TE)
This specification is complementary to the GMPLS Ethernet Label Switching Architecture and Framework and describes the technology-specific aspects of GMPLS control for Provider Backbone Bridge Traffic Engineering (PBB-TE). The necessary GMPLS extensions and mechanisms are described to establish Ethernet PBB-TE point-to-point (P2P) and point-to-multipoint (P2MP) connections. This document supports, but does not modify, the standard IEEE data plane. [STANDARDS-TRACK]
RFC6059 - Simple Procedures for Detecting Network Attachment in IPv6
Detecting Network Attachment allows hosts to assess if its existing addressing or routing configuration is valid for a newly connected network. This document provides simple procedures for Detecting Network Attachment in IPv6 hosts, and procedures for routers to support such services. [STANDARDS-TRACK]
RFC6058 - Transient Binding for Proxy Mobile IPv6
This document specifies a mechanism that enhances Proxy Mobile IPv6 protocol signaling to support the creation of a transient binding cache entry that is used to optimize the performance of dual radio handover, as well as single radio handover. This mechanism is applicable to the mobile node's inter-MAG (Mobility Access Gateway) handover while using a single interface or different interfaces. The handover problem space using the Proxy Mobile IPv6 base protocol is analyzed and the use of transient binding cache entries at the local mobility anchor is described. The specified extension to the Proxy Mobile IPv6 protocol ensures optimized forwarding of downlink as well as uplink packets between mobile nodes and the network infrastructure and avoids superfluous packet forwarding delay or even packet loss. This document defines an Experimental Protocol for the Internet community.
RFC6057 - Comcast's Protocol-Agnostic Congestion Management System
This document describes the congestion management system of Comcast Cable, a large cable broadband Internet Service Provider (ISP) in the U.S. Comcast completed deployment of this congestion management system on December 31, 2008. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6056 - Recommendations for Transport-Protocol Port Randomization
During the last few years, awareness has been raised about a number of "blind" attacks that can be performed against the Transmission Control Protocol (TCP) and similar protocols. The consequences of these attacks range from throughput reduction to broken connections or data corruption. These attacks rely on the attacker's ability to guess or know the five-tuple (Protocol, Source Address, Destination Address, Source Port, Destination Port) that identifies the transport protocol instance to be attacked. This document describes a number of simple and efficient methods for the selection of the client port number, such that the possibility of an attacker guessing the exact value is reduced. While this is not a replacement for cryptographic methods for protecting the transport-protocol instance, the aforementioned port selection algorithms provide improved security with very little effort and without any key management overhead. The algorithms described in this document are local policies that may be incrementally deployed and that do not violate the specifications of any of the transport protocols that may benefit from them, such as TCP, UDP, UDP-lite, Stream Control Transmission Protocol (SCTP), Datagram Congestion Control Protocol (DCCP), and RTP (provided that the RTP application explicitly signals the RTP and RTCP port numbers). This memo documents an Internet Best Current Practice.
RFC6055 - IAB Thoughts on Encodings for Internationalized Domain Names
This document explores issues with Internationalized Domain Names (IDNs) that result from the use of various encoding schemes such as UTF-8 and the ASCII-Compatible Encoding produced by the Punycode algorithm. It focuses on the importance of agreeing on a single encoding and how complicated the state of affairs ends up being as a result of using different encodings today.
RFC6054 - Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic
Counter modes have been defined for block ciphers such as the Advanced Encryption Standard (AES). Counter modes use a counter, which is typically assumed to be incremented by a single sender. This memo describes the use of counter modes when applied to the Encapsulating Security Payload (ESP) and Authentication Header (AH) in multiple-sender group applications. [STANDARDS-TRACK]
RFC6053 - Implementation Report for Forwarding and Control Element Separation (ForCES)
Forwarding and Control Element Separation (ForCES) defines an architectural framework and associated protocols to standardize information exchange between the control plane and the forwarding plane in a ForCES network element (ForCES NE). RFC 3654 has defined the ForCES requirements, and RFC 3746 has defined the ForCES framework.
RFC6052 - IPv6 Addressing of IPv4/IPv6 Translators
This document discusses the algorithmic translation of an IPv6 address to a corresponding IPv4 address, and vice versa, using only statically configured information. It defines a well-known prefix for use in algorithmic translations, while allowing organizations to also use network-specific prefixes when appropriate. Algorithmic translation is used in IPv4/IPv6 translators, as well as other types of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. [STANDARDS-TRACK]
RFC6051 - Rapid Synchronisation of RTP Flows
This memo outlines how RTP sessions are synchronised, and discusses how rapidly such synchronisation can occur. We show that most RTP sessions can be synchronised immediately, but that the use of video switching multipoint conference units (MCUs) or large source-specific multicast (SSM) groups can greatly increase the synchronisation delay. This increase in delay can be unacceptable to some applications that use layered and/or multi-description codecs.
RFC6050 - A Session Initiation Protocol (SIP) Extension for the Identification of Services
This document describes private extensions to the Session Initiation Protocol (SIP) that enable a network of trusted SIP servers to assert the service of authenticated users. The use of these extensions is only applicable inside an administrative domain with previously agreed-upon policies for generation, transport, and usage of such information. This document does NOT offer a general service identification model suitable for use between different trust domains or for use in the Internet at large.
RFC6049 - Spatial Composition of Metrics
This memo utilizes IP performance metrics that are applicable to both complete paths and sub-paths, and it defines relationships to compose a complete path metric from the sub-path metrics with some accuracy with regard to the actual metrics. This is called "spatial composition" in RFC 2330. The memo refers to the framework for metric composition, and provides background and motivation for combining metrics to derive others. The descriptions of several composed metrics and statistics follow. [STANDARDS-TRACK]
RFC6048 - Network News Transfer Protocol (NNTP) Additions to LIST Command
This document defines a set of enhancements to the Network News Transfer Protocol (NNTP) that allow a client to request extended information from NNTP servers regarding server status, policy, and other aspects of local configuration. These enhancements are made as new keywords to the existing LIST capability described in RFC 3977.
RFC6047 - iCalendar Message-Based Interoperability Protocol (iMIP)
This document, "iCalendar Message-Based Interoperability Protocol (iMIP)", specifies a binding from the iCalendar Transport-independent Interoperability Protocol (iTIP) to Internet email-based transports. Calendaring entries defined by the iCalendar Object Model (iCalendar) are wrapped using constructs from RFC 5322 and MIME (RFC 2045, RFC 2046, RFC 2047, and RFC 2049), and then transported over SMTP. [STANDARDS-TRACK]
RFC6046 - Transport of Real-time Inter-network Defense (RID) Messages
The Incident Object Description Exchange Format (IODEF) defines a common XML format for document exchange, and Real-time Inter-network Defense (RID) defines extensions to IODEF intended for the cooperative handling of security incidents within consortia of network operators and enterprises. This document specifies a transport protocol for RID based upon the passing of RID messages over HTTP/TLS (Transport Layer Security). This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6045 - Real-time Inter-network Defense (RID)
Network security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system. Network providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations.
RFC6044 - Mapping and Interworking of Diversion Information between Diversion and History-Info Headers in the Session Initiation Protocol (SIP)
Although the SIP History-Info header is the solution adopted in IETF, the non-standard Diversion header is nevertheless widely implemented and used for conveying call-diversion-related information in SIP signaling.
RFC6043 - MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY)
The Multimedia Internet KEYing (MIKEY) specification describes a key management scheme for real-time applications. In this document, we note that the currently defined MIKEY modes are insufficient to address deployment scenarios built around a centralized key management service. Interest in such deployments is increasing. Therefore, a set of new MIKEY modes that work well in such scenarios are defined. The new modes use a trusted key management service and a ticket concept, similar to that in Kerberos. The new modes also support features used by many existing applications, where the exact identity of the other endpoint may not be known at the start of the communication session. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6042 - Transport Layer Security (TLS) Authorization Using KeyNote
This document specifies the use of the KeyNote trust-management system as an authorization extension in the Transport Layer Security (TLS) Handshake Protocol, according to guidelines in RFC 5878. Extensions carried in the client and server hello messages confirm that both parties support the desired authorization data types. Then, if supported by both the client and the server, KeyNote credentials are exchanged in the supplemental data handshake message. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6041 - Forwarding and Control Element Separation (ForCES) Applicability Statement
The Forwarding and Control Element Separation (ForCES) protocol defines a standard framework and mechanism for the interconnection between control elements and forwarding elements in IP routers and similar devices. In this document we describe the applicability of the ForCES model and protocol. We provide example deployment scenarios and functionality, as well as document applications that would be inappropriate for ForCES. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6040 - Tunnelling of Explicit Congestion Notification
This document redefines how the explicit congestion notification (ECN) field of the IP header should be constructed on entry to and exit from any IP-in-IP tunnel. On encapsulation, it updates RFC 3168 to bring all IP-in-IP tunnels (v4 or v6) into line with RFC 4301 IPsec ECN processing. On decapsulation, it updates both RFC 3168 and RFC 4301 to add new behaviours for previously unused combinations of inner and outer headers. The new rules ensure the ECN field is correctly propagated across a tunnel whether it is used to signal one or two severity levels of congestion; whereas before, only one severity level was supported. Tunnel endpoints can be updated in any order without affecting pre-existing uses of the ECN field, thus ensuring backward compatibility. Nonetheless, operators wanting to support two severity levels (e.g., for pre-congestion notification -- PCN) can require compliance with this new specification. A thorough analysis of the reasoning for these changes and the implications is included. In the unlikely event that the new rules do not meet a specific need, RFC 4774 gives guidance on designing alternate ECN semantics, and this document extends that to include tunnelling issues. [STANDARDS-TRACK]
RFC6039 - Issues with Existing Cryptographic Protection Methods for Routing Protocols
Routing protocols have been extended over time to use cryptographic mechanisms to ensure that data received from a neighboring router has not been modified in transit and actually originated from an authorized neighboring router.
RFC6038 - Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features
This memo describes two closely related features for the core specification of the Two-Way Active Measurement Protocol (TWAMP): an optional capability where the responding host returns some of the command octets or padding octets to the sender, and an optional sender packet format that ensures equal test packet sizes are used in both directions. [STANDARDS-TRACK]
RFC6037 - Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs
This document describes the MVPN (Multicast in BGP/MPLS IP VPNs) solution designed and deployed by Cisco Systems. The procedures specified in this document are largely a subset of the generalized MVPN framework recently standardized by the IETF. However, as the deployment of the procedures specified herein predates the publication of IETF standards (in some cases by over five years), an implementation based on these procedures differs in some respects from a fully standards-compliant implementation. These differences are pointed out in the document. This document defines a Historic Document for the Internet community.
RFC6036 - Emerging Service Provider Scenarios for IPv6 Deployment
This document describes practices and plans that are emerging among Internet Service Providers for the deployment of IPv6 services. They are based on practical experience so far, as well as current plans and requirements, reported in a survey of a number of ISPs carried out in early 2010. This document identifies a number of technology gaps, but it does not make recommendations. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6035 - Session Initiation Protocol Event Package for Voice Quality Reporting
This document defines a Session Initiation Protocol (SIP) event package that enables the collection and reporting of metrics that measure the quality for Voice over Internet Protocol (VoIP) sessions. Voice call quality information derived from RTP Control Protocol Extended Reports (RTCP-XR) and call information from SIP is conveyed from a User Agent (UA) in a session, known as a reporter, to a third party, known as a collector. A registration for the application/ vq-rtcpxr media type is also included. [STANDARDS-TRACK]
RFC6034 - Unicast-Prefix-Based IPv4 Multicast Addresses
This specification defines an extension to the multicast addressing architecture of the IP Version 4 protocol. The extension presented in this document allows for unicast-prefix-based assignment of multicast addresses. By delegating multicast addresses at the same time as unicast prefixes, network operators will be able to identify their multicast addresses without needing to run an inter-domain allocation protocol. [STANDARDS-TRACK]
RFC6033 - Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type
This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) encrypted key package content type. Specifically, it includes conventions necessary to implement EnvelopedData, EncryptedData, and AuthEnvelopedData. [STANDARDS-TRACK]
RFC6032 - Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type
This document defines the Cryptographic Message Syntax (CMS) encrypted key package content type, which can be used to encrypt a content that includes a key package, such as a symmetric key package or an asymmetric key package. It is transport independent. CMS can be used to digitally sign, digest, authenticate, or further encrypt this content type. It is designed to be used with the CMS Content Constraints (CCC) extension, which does not constrain the EncryptedData, EnvelopedData, and AuthEnvelopedData. [STANDARDS-TRACK]
RFC6031 - Cryptographic Message Syntax (CMS) Symmetric Key Package Content Type
This document defines the symmetric key format content type. It is transport independent. The Cryptographic Message Syntax (CMS) can be used to digitally sign, digest, authenticate, or encrypt this content type. [STANDARDS-TRACK]
RFC6030 - Portable Symmetric Key Container (PSKC)
This document specifies a symmetric key format for the transport and provisioning of symmetric keys to different types of crypto modules. For example, One-Time Password (OTP) shared secrets or symmetric cryptographic keys to strong authentication devices. A standard key transport format enables enterprises to deploy best-of-breed solutions combining components from different vendors into the same infrastructure. [STANDARDS-TRACK]
RFC6029 - A Survey on Research on the Application-Layer Traffic Optimization (ALTO) Problem
A significant part of the Internet traffic today is generated by peer-to-peer (P2P) applications used originally for file sharing, and more recently for real-time communications and live media streaming. Such applications discover a route to each other through an overlay network with little knowledge of the underlying network topology. As a result, they may choose peers based on information deduced from empirical measurements, which can lead to suboptimal choices. This document, a product of the P2P Research Group, presents a survey of existing literature on discovering and using network topology information for Application-Layer Traffic Optimization. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6028 - Host Identity Protocol (HIP) Multi-Hop Routing Extension
This document specifies two extensions to the Host Identity Protocol (HIP) to implement multi-hop routing. The first extension allows implementing source routing in HIP. That is, a node sending a HIP packet can define a set of nodes that the HIP packet should traverse. The second extension allows a HIP packet to carry and record the list of nodes that forwarded it. This document defines an Experimental Protocol for the Internet community.
RFC6027 - IPsec Cluster Problem Statement
This document defines the terminology, problem statement, and requirements for implementing Internet Key Exchange (IKE) and IPsec on clusters. It also describes gaps in existing standards and their implementation that need to be filled in order to allow peers to interoperate with clusters from different vendors. Agreed upon terminology, problem statement, and requirements will allow IETF working groups to consider development of IPsec/IKEv2 mechanisms to simplify cluster implementations. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6026 - Correct Transaction Handling for 2xx Responses to Session Initiation Protocol (SIP) INVITE Requests
This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address an error in the specified handling of success (2xx class) responses to INVITE requests. Elements following RFC 3261 exactly will misidentify retransmissions of the request as a new, unassociated request. The correction involves modifying the INVITE transaction state machines. The correction also changes the way responses that cannot be matched to an existing transaction are handled to address a security risk. [STANDARDS-TRACK]
RFC6025 - ASN.1 Translation
Abstract Syntax Notation One (ASN.1) is widely used throughout the IETF Security Area and has been for many years. Some specifications were written using a now deprecated version of ASN.1 and some were written using the current version of ASN.1. Not all ASN.1 compilers support both older and current syntax. This document is intended to provide guidance to specification authors and to implementers converting ASN.1 modules from one version of ASN.1 to another version without causing changes to the "bits on the wire". This document does not provide a comprehensive tutorial of any version of ASN.1. Instead, it addresses ASN.1 features that are used in IETF Security Area specifications with a focus on items that vary with the ASN.1 version. This document is not an Internet Standards Track specification; it is published for informational purposes.