RFC Abstracts
RFC6220 - Defining the Role and Function of IETF Protocol Parameter Registry Operators
Many Internet Engineering Task Force (IETF) protocols make use of commonly defined values that are passed in messages or packets. To ensure consistent interpretation of these values between independent implementations, there is a need to ensure that the values and associated semantic intent are uniquely defined. The IETF uses registry functions to record assigned protocol parameter values and their associated semantic intentions. For each IETF protocol parameter, it is current practice for the IETF to delegate the role of Protocol Parameter Registry Operator to a nominated entity. This document provides a description of, and the requirements for, these delegated functions. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6219 - The China Education and Research Network (CERNET) IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition
This document presents the China Education and Research Network (CERNET)'s IVI translation design and deployment for the IPv4/IPv6 coexistence and transition.
RFC6218 - Cisco Vendor-Specific RADIUS Attributes for the Delivery of Keying Material
This document defines a set of vendor-specific RADIUS Attributes designed to allow both the secure transmission of cryptographic keying material and strong authentication of any RADIUS message. These attributes have been allocated from the Cisco vendor-specific space and have been implemented by multiple vendors. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6217 - Regional Broadcast Using an Atmospheric Link Layer
Broadcasting is a technology that has been largely discarded in favor of technologies like multicast. This document builds on RFC 919 and describes a more efficient routing mechanism for broadcast packets destined for multiple Local Area Networks (LANs) or Metropolitan Area Networks (MANs) using an alternative link layer. It significantly reduces congestion on network equipment and does not require additional physical infrastructure investment. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6216 - Example Call Flows Using Session Initiation Protocol (SIP) Security Mechanisms
This document shows example call flows demonstrating the use of Transport Layer Security (TLS), and Secure/Multipurpose Internet Mail Extensions (S/MIME) in Session Initiation Protocol (SIP). It also provides information that helps implementers build interoperable SIP software. To help facilitate interoperability testing, it includes certificates used in the example call flows and processes to create certificates for testing. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6215 - MPLS Transport Profile User-to-Network and Network-to-Network Interfaces
The framework for MPLS in transport networks (RFC 5921) provides reference models for the MPLS Transport Profile (MPLS-TP) Transport Service Interfaces, which are a User-to-Network Interface (UNI), and a Network-to-Network Interface (NNI). This document updates those reference models to show detailed reference points for these interfaces, along with further clarification of the functional architecture of MPLS-TP at a UNI and NNI.
RFC6214 - Adaptation of RFC 1149 for IPv6
This document specifies a method for transmission of IPv6 datagrams over the same medium as specified for IPv4 datagrams in RFC 1149. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6213 - IS-IS BFD-Enabled TLV
This document describes a type-length-value (TLV) for use in the IS-IS routing protocol that allows for the proper use of the Bidirectional Forwarding Detection (BFD) protocol. There exist certain scenarios in which IS-IS will not react appropriately to a BFD-detected forwarding plane failure without use of either this TLV or some other method. [STANDARDS-TRACK]
RFC6212 - Authentication-Results Registration for Vouch by Reference Results
This memo updates the registry of properties in Authentication- Results: message header fields to allow relaying of the results of a Vouch By Reference query. [STANDARDS-TRACK]
RFC6211 - Cryptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute
The Cryptographic Message Syntax (CMS), unlike X.509/PKIX certificates, is vulnerable to algorithm substitution attacks. In an algorithm substitution attack, the attacker changes either the algorithm being used or the parameters of the algorithm in order to change the result of a signature verification process. In X.509 certificates, the signature algorithm is protected because it is duplicated in the TBSCertificate.signature field with the proviso that the validator is to compare both fields as part of the signature validation process. This document defines a new attribute that contains a copy of the relevant algorithm identifiers so that they are protected by the signature or authentication process. [STANDARDS-TRACK]
RFC6210 - Experiment: Hash Functions with Parameters in the Cryptographic Message Syntax (CMS) and S/MIME
New hash algorithms are being developed that may include parameters. Cryptographic Message Syntax (CMS) has not currently defined any hash algorithms with parameters, but anecdotal evidence suggests that defining one could cause major problems. This document defines just such an algorithm and describes how to use it so that experiments can be run to find out how bad including hash parameters will be. This document defines an Experimental Protocol for the Internet community.
RFC6209 - Addition of the ARIA Cipher Suites to Transport Layer Security (TLS)
This document specifies a set of cipher suites for the Transport Layer Security (TLS) protocol to support the ARIA encryption algorithm as a block cipher. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6208 - Cloud Data Management Interface (CDMI) Media Types
This document describes several Internet media types defined for the Cloud Data Management Interface (CDMI) by the Storage Networking Industry Association (SNIA). The media types are:
RFC6207 - The Media Types application/mods+xml, application/mads+xml, application/mets+xml, application/marcxml+xml, and application/sru+xml
This document specifies media types for the following formats: MODS (Metadata Object Description Schema), MADS (Metadata Authority Description Schema), METS (Metadata Encoding and Transmission Standard), MARCXML (MARC21 XML Schema), and the SRU (Search/Retrieve via URL Response Format) protocol response XML schema. These are all XML schemas providing representations of various forms of information including metadata and search results. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6206 - The Trickle Algorithm
The Trickle algorithm allows nodes in a lossy shared medium (e.g., low-power and lossy networks) to exchange information in a highly robust, energy efficient, simple, and scalable manner. Dynamically adjusting transmission windows allows Trickle to spread new information on the scale of link-layer transmission times while sending only a few messages per hour when information does not change. A simple suppression mechanism and transmission point selection allow Trickle's communication rate to scale logarithmically with density. This document describes the Trickle algorithm and considerations in its use. [STANDARDS-TRACK]
RFC6205 - Generalized Labels for Lambda-Switch-Capable (LSC) Label Switching Routers
Technology in the optical domain is constantly evolving, and, as a consequence, new equipment providing lambda switching capability has been developed and is currently being deployed.
RFC6204 - Basic Requirements for IPv6 Customer Edge Routers
This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6203 - IMAP4 Extension for Fuzzy Search
This document describes an IMAP protocol extension enabling a server to perform searches with inexact matching and assigning relevancy scores for matched messages. [STANDARDS-TRACK]
RFC6202 - Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP
On today's Internet, the Hypertext Transfer Protocol (HTTP) is often used (some would say abused) to enable asynchronous, "server- initiated" communication from a server to a client as well as communication from a client to a server. This document describes known issues and best practices related to such "bidirectional HTTP" applications, focusing on the two most common mechanisms: HTTP long polling and HTTP streaming. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6201 - Device Reset Characterization
An operational forwarding device may need to be restarted (automatically or manually) for a variety of reasons, an event called a "reset" in this document. Since there may be an interruption in the forwarding operation during a reset, it is useful to know how long a device takes to resume the forwarding operation.
RFC6198 - Requirements for the Graceful Shutdown of BGP Sessions
The Border Gateway Protocol (BGP) is heavily used in Service Provider networks for both Internet and BGP/MPLS VPN services. For resiliency purposes, redundant routers and BGP sessions can be deployed to reduce the consequences of an Autonomous System Border Router (ASBR) or BGP session breakdown on customers' or peers' traffic. However, simply taking down or even bringing up a BGP session for maintenance purposes may still induce connectivity losses during the BGP convergence. This is no longer satisfactory for new applications (e.g., voice over IP, online gaming, VPN). Therefore, a solution is required for the graceful shutdown of a (set of) BGP session(s) in order to limit the amount of traffic loss during a planned shutdown. This document expresses requirements for such a solution. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6197 - Location-to-Service Translation (LoST) Service List Boundary Extension
Location-to-Service Translation (LoST) maps service identifiers and location information to service contact URIs. If a LoST client wants to discover available services for a particular location, it will perform a <listServicesByLocation> query to the LoST server. However, the LoST server, in its response, does not provide context information; that is, it does not provide any additional information about the geographical region within which the returned list of services is considered valid. Therefore, this document defines a Service List Boundary that returns a local context along with the list of services returned, in order to assist the client in not missing a change in available services when moving. This document defines an Experimental Protocol for the Internet community.
RFC6196 - Moving mailserver: URI Scheme to Historic
This document registers the mailserver: URI scheme as historic in the IANA URI registry. [STANDARDS-TRACK]
RFC6195 - Domain Name System (DNS) IANA Considerations
This document specifies Internet Assigned Number Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. This memo documents an Internet Best Current Practice.
RFC6194 - Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms
This document includes security considerations for the SHA-0 and SHA-1 message digest algorithm. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6193 - Media Description for the Internet Key Exchange Protocol (IKE) in the Session Description Protocol (SDP)
This document specifies how to establish a media session that represents a virtual private network using the Session Initiation Protocol for the purpose of on-demand media/application sharing between peers. It extends the protocol identifier of the Session Description Protocol (SDP) so that it can negotiate use of the Internet Key Exchange Protocol (IKE) for media sessions in the SDP offer/answer model. It also specifies a method to boot up IKE and generate IPsec security associations using a self-signed certificate. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6192 - Protecting the Router Control Plane
This memo provides a method for protecting a router's control plane from undesired or malicious traffic. In this approach, all legitimate router control plane traffic is identified. Once legitimate traffic has been identified, a filter is deployed in the router's forwarding plane. That filter prevents traffic not specifically identified as legitimate from reaching the router's control plane, or rate-limits such traffic to an acceptable level.
RFC6191 - Reducing the TIME-WAIT State Using TCP Timestamps
This document describes an algorithm for processing incoming SYN segments that allows higher connection-establishment rates between any two TCP endpoints when a TCP Timestamps option is present in the incoming SYN segment. This document only modifies processing of SYN segments received for connections in the TIME-WAIT state; processing in all other states is unchanged. This memo documents an Internet Best Current Practice.
RFC6190 - RTP Payload Format for Scalable Video Coding
This memo describes an RTP payload format for Scalable Video Coding (SVC) as defined in Annex G of ITU-T Recommendation H.264, which is technically identical to Amendment 3 of ISO/IEC International Standard 14496-10. The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit in multiple RTP packets. Furthermore, it supports transmission of an SVC stream over a single as well as multiple RTP sessions. The payload format defines a new media subtype name "H264-SVC", but is still backward compatible to RFC 6184 since the base layer, when encapsulated in its own RTP stream, must use the H.264 media subtype name ("H264") and the packetization method specified in RFC 6184. The payload format has wide applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among others. [STANDARDS-TRACK]
RFC6189 - ZRTP: Media Path Key Agreement for Unicast Secure RTP
This document defines ZRTP, a protocol for media path Diffie-Hellman exchange to agree on a session key and parameters for establishing unicast Secure Real-time Transport Protocol (SRTP) sessions for Voice over IP (VoIP) applications. The ZRTP protocol is media path keying because it is multiplexed on the same port as RTP and does not require support in the signaling protocol. ZRTP does not assume a Public Key Infrastructure (PKI) or require the complexity of certificates in end devices. For the media session, ZRTP provides confidentiality, protection against man-in-the-middle (MiTM) attacks, and, in cases where the signaling protocol provides end-to-end integrity protection, authentication. ZRTP can utilize a Session Description Protocol (SDP) attribute to provide discovery and authentication through the signaling channel. To provide best effort SRTP, ZRTP utilizes normal RTP/AVP (Audio-Visual Profile) profiles. ZRTP secures media sessions that include a voice media stream and can also secure media sessions that do not include voice by using an optional digital signature. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6188 - The Use of AES-192 and AES-256 in Secure RTP
This memo describes the use of the Advanced Encryption Standard (AES) with 192- and 256-bit keys within the Secure RTP (SRTP) protocol. It details counter mode encryption for SRTP and Secure Realtime Transport Control Protocol (SRTCP) and a new SRTP Key Derivation Function (KDF) for AES-192 and AES-256. [STANDARDS-TRACK]
RFC6187 - X.509v3 Certificates for Secure Shell Authentication
X.509 public key certificates use a signature by a trusted certification authority to bind a given public key to a given digital identity. This document specifies how to use X.509 version 3 public key certificates in public key algorithms in the Secure Shell protocol. [STANDARDS-TRACK]
RFC6186 - Use of SRV Records for Locating Email Submission/Access Services
This specification describes how SRV records can be used to locate email services. [STANDARDS-TRACK]
RFC6185 - RTP Payload Format for H.264 Reduced-Complexity Decoding Operation (RCDO) Video
This document describes an RTP payload format for the Reduced- Complexity Decoding Operation (RCDO) for H.264 Baseline profile bitstreams, as specified in ITU-T Recommendation H.241. RCDO reduces the decoding cost and resource consumption of the video processing. The RCDO RTP payload format is based on the H.264 RTP payload format. [STANDARDS-TRACK]
RFC6184 - RTP Payload Format for H.264 Video
This memo describes an RTP Payload format for the ITU-T Recommendation H.264 video codec and the technically identical ISO/IEC International Standard 14496-10 video codec, excluding the Scalable Video Coding (SVC) extension and the Multiview Video Coding extension, for which the RTP payload formats are defined elsewhere. The RTP payload format allows for packetization of one or more Network Abstraction Layer Units (NALUs), produced by an H.264 video encoder, in each RTP payload. The payload format has wide applicability, as it supports applications from simple low bitrate conversational usage, to Internet video streaming with interleaved transmission, to high bitrate video-on-demand.
RFC6183 - IP Flow Information Export (IPFIX) Mediation: Framework
This document describes a framework for IP Flow Information Export (IPFIX) Mediation. This framework extends the IPFIX reference model specified in RFC 5470 by defining the IPFIX Mediator components. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6182 - Architectural Guidelines for Multipath TCP Development
Hosts are often connected by multiple paths, but TCP restricts communications to a single path per transport connection. Resource usage within the network would be more efficient were these multiple paths able to be used concurrently. This should enhance user experience through improved resilience to network failure and higher throughput.
RFC6181 - Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses
Multipath TCP (MPTCP for short) describes the extensions proposed for TCP so that endpoints of a given TCP connection can use multiple paths to exchange data. Such extensions enable the exchange of segments using different source-destination address pairs, resulting in the capability of using multiple paths in a significant number of scenarios. Some level of multihoming and mobility support can be achieved through these extensions. However, the support for multiple IP addresses per endpoint may have implications on the security of the resulting MPTCP. This note includes a threat analysis for MPTCP. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6180 - Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment
The Internet continues to grow beyond the capabilities of IPv4. An expansion in the address space is clearly required. With its increase in the number of available prefixes and addresses in a subnet, and improvements in address management, IPv6 is the only real option on the table. Yet, IPv6 deployment requires some effort, resources, and expertise. The availability of many different deployment models is one reason why expertise is required. This document discusses the IPv6 deployment models and migration tools, and it recommends ones that have been found to work well in operational networks in many common situations. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6179 - The Internet Routing Overlay Network (IRON)
Since the Internet must continue to support escalating growth due to increasing demand, it is clear that current routing architectures and operational practices must be updated. This document proposes an Internet Routing Overlay Network (IRON) that supports sustainable growth while requiring no changes to end systems and no changes to the existing routing system. IRON further addresses other important issues including routing scaling, mobility management, multihoming, traffic engineering and NAT traversal. While business considerations are an important determining factor for widespread adoption, they are out of scope for this document. This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.
RFC6178 - Label Edge Router Forwarding of IPv4 Option Packets
This document specifies how Label Edge Routers (LERs) should behave when determining whether to MPLS encapsulate an IPv4 packet with header options. Lack of a formal standard has resulted in different LER forwarding behaviors for IPv4 packets with header options despite being associated with a prefix-based Forwarding Equivalence Class (FEC). IPv4 option packets that belong to a prefix-based FEC, yet are forwarded into an IPv4/MPLS network without being MPLS- encapsulated, present a security risk against the MPLS infrastructure. Further, LERs that are unable to MPLS encapsulate IPv4 packets with header options cannot operate in certain MPLS environments. While this newly defined LER behavior is mandatory to implement, it is optional to invoke. [STANDARDS-TRACK]
RFC6177 - IPv6 Address Assignment to End Sites
RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks in most cases. The Regional Internet Registries (RIRs) adopted that recommendation in 2002, but began reconsidering the policy in 2005. This document obsoletes the RFC 3177 recommendations on the assignment of IPv6 address space to end sites. The exact choice of how much address space to assign end sites is an issue for the operational community. The IETF's role in this case is limited to providing guidance on IPv6 architectural and operational considerations. This document reviews the architectural and operational considerations of end site assignments as well as the motivations behind the original recommendations in RFC 3177. Moreover, this document clarifies that a one-size-fits-all recommendation of /48 is not nuanced enough for the broad range of end sites and is no longer recommended as a single default.
RFC6176 - Prohibiting Secure Sockets Layer (SSL) Version 2.0
This document requires that when Transport Layer Security (TLS) clients and servers establish connections, they never negotiate the use of Secure Sockets Layer (SSL) version 2.0. This document updates the backward compatibility sections found in the Transport Layer Security (TLS). [STANDARDS-TRACK]
RFC6175 - Requirements to Extend the Datatracker for IETF Working Group Chairs and Authors
This document specifies requirements for new functionality to be added to the IETF Datatracker tool to make it possible for Working Group (WG) Chairs and their Delegates to input and update the status of the Internet-Drafts (I-Ds) associated with their WGs. After these requirements are implemented, WG Chairs will be able to use the Datatracker to provide everyone with more information about the status and progression of WG I-Ds than is currently possible. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6174 - Definition of IETF Working Group Document States
The IETF Datatracker tool needs to be enhanced to make it possible for Working Group (WG) Chairs to provide IETF participants with more information about the status and progression of WG documents than is currently possible.
RFC6173 - Definitions of Managed Objects for the Internet Fibre Channel Protocol (iFCP)
This document defines Management Information Base (MIB) objects to monitor and control the Internet Fibre Channel Protocol (iFCP) gateway instances and their associated sessions, for use with network management protocols.
RFC6172 - Deprecation of the Internet Fibre Channel Protocol (iFCP) Address Translation Mode
Changes to Fibre Channel have caused the specification of the Internet Fibre Channel Protocol (iFCP) address translation mode to become incorrect. Due to the absence of usage of iFCP address translation mode, it is deprecated by this document. iFCP address transparent mode remains correctly specified.
RFC6171 - The Lightweight Directory Access Protocol (LDAP) Don't Use Copy Control
This document defines the Lightweight Directory Access Protocol (LDAP) Don't Use Copy control extension, which allows a client to specify that copied information should not be used in providing service. This control is based upon the X.511 dontUseCopy service control option. [STANDARDS-TRACK]
RFC6170 - Internet X.509 Public Key Infrastructure -- Certificate Image
This document specifies a method to bind a visual representation of a certificate in the form of a certificate image to a public key certificate as defined in RFC 5280, by defining a new "otherLogos" image type according to RFC 3709. [STANDARDS-TRACK]
RFC6169 - Security Concerns with IP Tunneling
A number of security concerns with IP tunnels are documented in this memo. The intended audience of this document includes network administrators and future protocol developers. The primary intent of this document is to raise the awareness level regarding the security issues with IP tunnels as deployed and propose strategies for the mitigation of those issues. [STANDARDS-TRACK]
Many Internet Engineering Task Force (IETF) protocols make use of commonly defined values that are passed in messages or packets. To ensure consistent interpretation of these values between independent implementations, there is a need to ensure that the values and associated semantic intent are uniquely defined. The IETF uses registry functions to record assigned protocol parameter values and their associated semantic intentions. For each IETF protocol parameter, it is current practice for the IETF to delegate the role of Protocol Parameter Registry Operator to a nominated entity. This document provides a description of, and the requirements for, these delegated functions. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6219 - The China Education and Research Network (CERNET) IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition
This document presents the China Education and Research Network (CERNET)'s IVI translation design and deployment for the IPv4/IPv6 coexistence and transition.
RFC6218 - Cisco Vendor-Specific RADIUS Attributes for the Delivery of Keying Material
This document defines a set of vendor-specific RADIUS Attributes designed to allow both the secure transmission of cryptographic keying material and strong authentication of any RADIUS message. These attributes have been allocated from the Cisco vendor-specific space and have been implemented by multiple vendors. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6217 - Regional Broadcast Using an Atmospheric Link Layer
Broadcasting is a technology that has been largely discarded in favor of technologies like multicast. This document builds on RFC 919 and describes a more efficient routing mechanism for broadcast packets destined for multiple Local Area Networks (LANs) or Metropolitan Area Networks (MANs) using an alternative link layer. It significantly reduces congestion on network equipment and does not require additional physical infrastructure investment. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6216 - Example Call Flows Using Session Initiation Protocol (SIP) Security Mechanisms
This document shows example call flows demonstrating the use of Transport Layer Security (TLS), and Secure/Multipurpose Internet Mail Extensions (S/MIME) in Session Initiation Protocol (SIP). It also provides information that helps implementers build interoperable SIP software. To help facilitate interoperability testing, it includes certificates used in the example call flows and processes to create certificates for testing. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6215 - MPLS Transport Profile User-to-Network and Network-to-Network Interfaces
The framework for MPLS in transport networks (RFC 5921) provides reference models for the MPLS Transport Profile (MPLS-TP) Transport Service Interfaces, which are a User-to-Network Interface (UNI), and a Network-to-Network Interface (NNI). This document updates those reference models to show detailed reference points for these interfaces, along with further clarification of the functional architecture of MPLS-TP at a UNI and NNI.
RFC6214 - Adaptation of RFC 1149 for IPv6
This document specifies a method for transmission of IPv6 datagrams over the same medium as specified for IPv4 datagrams in RFC 1149. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6213 - IS-IS BFD-Enabled TLV
This document describes a type-length-value (TLV) for use in the IS-IS routing protocol that allows for the proper use of the Bidirectional Forwarding Detection (BFD) protocol. There exist certain scenarios in which IS-IS will not react appropriately to a BFD-detected forwarding plane failure without use of either this TLV or some other method. [STANDARDS-TRACK]
RFC6212 - Authentication-Results Registration for Vouch by Reference Results
This memo updates the registry of properties in Authentication- Results: message header fields to allow relaying of the results of a Vouch By Reference query. [STANDARDS-TRACK]
RFC6211 - Cryptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute
The Cryptographic Message Syntax (CMS), unlike X.509/PKIX certificates, is vulnerable to algorithm substitution attacks. In an algorithm substitution attack, the attacker changes either the algorithm being used or the parameters of the algorithm in order to change the result of a signature verification process. In X.509 certificates, the signature algorithm is protected because it is duplicated in the TBSCertificate.signature field with the proviso that the validator is to compare both fields as part of the signature validation process. This document defines a new attribute that contains a copy of the relevant algorithm identifiers so that they are protected by the signature or authentication process. [STANDARDS-TRACK]
RFC6210 - Experiment: Hash Functions with Parameters in the Cryptographic Message Syntax (CMS) and S/MIME
New hash algorithms are being developed that may include parameters. Cryptographic Message Syntax (CMS) has not currently defined any hash algorithms with parameters, but anecdotal evidence suggests that defining one could cause major problems. This document defines just such an algorithm and describes how to use it so that experiments can be run to find out how bad including hash parameters will be. This document defines an Experimental Protocol for the Internet community.
RFC6209 - Addition of the ARIA Cipher Suites to Transport Layer Security (TLS)
This document specifies a set of cipher suites for the Transport Layer Security (TLS) protocol to support the ARIA encryption algorithm as a block cipher. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6208 - Cloud Data Management Interface (CDMI) Media Types
This document describes several Internet media types defined for the Cloud Data Management Interface (CDMI) by the Storage Networking Industry Association (SNIA). The media types are:
RFC6207 - The Media Types application/mods+xml, application/mads+xml, application/mets+xml, application/marcxml+xml, and application/sru+xml
This document specifies media types for the following formats: MODS (Metadata Object Description Schema), MADS (Metadata Authority Description Schema), METS (Metadata Encoding and Transmission Standard), MARCXML (MARC21 XML Schema), and the SRU (Search/Retrieve via URL Response Format) protocol response XML schema. These are all XML schemas providing representations of various forms of information including metadata and search results. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6206 - The Trickle Algorithm
The Trickle algorithm allows nodes in a lossy shared medium (e.g., low-power and lossy networks) to exchange information in a highly robust, energy efficient, simple, and scalable manner. Dynamically adjusting transmission windows allows Trickle to spread new information on the scale of link-layer transmission times while sending only a few messages per hour when information does not change. A simple suppression mechanism and transmission point selection allow Trickle's communication rate to scale logarithmically with density. This document describes the Trickle algorithm and considerations in its use. [STANDARDS-TRACK]
RFC6205 - Generalized Labels for Lambda-Switch-Capable (LSC) Label Switching Routers
Technology in the optical domain is constantly evolving, and, as a consequence, new equipment providing lambda switching capability has been developed and is currently being deployed.
RFC6204 - Basic Requirements for IPv6 Customer Edge Routers
This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6203 - IMAP4 Extension for Fuzzy Search
This document describes an IMAP protocol extension enabling a server to perform searches with inexact matching and assigning relevancy scores for matched messages. [STANDARDS-TRACK]
RFC6202 - Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP
On today's Internet, the Hypertext Transfer Protocol (HTTP) is often used (some would say abused) to enable asynchronous, "server- initiated" communication from a server to a client as well as communication from a client to a server. This document describes known issues and best practices related to such "bidirectional HTTP" applications, focusing on the two most common mechanisms: HTTP long polling and HTTP streaming. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6201 - Device Reset Characterization
An operational forwarding device may need to be restarted (automatically or manually) for a variety of reasons, an event called a "reset" in this document. Since there may be an interruption in the forwarding operation during a reset, it is useful to know how long a device takes to resume the forwarding operation.
RFC6198 - Requirements for the Graceful Shutdown of BGP Sessions
The Border Gateway Protocol (BGP) is heavily used in Service Provider networks for both Internet and BGP/MPLS VPN services. For resiliency purposes, redundant routers and BGP sessions can be deployed to reduce the consequences of an Autonomous System Border Router (ASBR) or BGP session breakdown on customers' or peers' traffic. However, simply taking down or even bringing up a BGP session for maintenance purposes may still induce connectivity losses during the BGP convergence. This is no longer satisfactory for new applications (e.g., voice over IP, online gaming, VPN). Therefore, a solution is required for the graceful shutdown of a (set of) BGP session(s) in order to limit the amount of traffic loss during a planned shutdown. This document expresses requirements for such a solution. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6197 - Location-to-Service Translation (LoST) Service List Boundary Extension
Location-to-Service Translation (LoST) maps service identifiers and location information to service contact URIs. If a LoST client wants to discover available services for a particular location, it will perform a <listServicesByLocation> query to the LoST server. However, the LoST server, in its response, does not provide context information; that is, it does not provide any additional information about the geographical region within which the returned list of services is considered valid. Therefore, this document defines a Service List Boundary that returns a local context along with the list of services returned, in order to assist the client in not missing a change in available services when moving. This document defines an Experimental Protocol for the Internet community.
RFC6196 - Moving mailserver: URI Scheme to Historic
This document registers the mailserver: URI scheme as historic in the IANA URI registry. [STANDARDS-TRACK]
RFC6195 - Domain Name System (DNS) IANA Considerations
This document specifies Internet Assigned Number Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. This memo documents an Internet Best Current Practice.
RFC6194 - Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms
This document includes security considerations for the SHA-0 and SHA-1 message digest algorithm. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6193 - Media Description for the Internet Key Exchange Protocol (IKE) in the Session Description Protocol (SDP)
This document specifies how to establish a media session that represents a virtual private network using the Session Initiation Protocol for the purpose of on-demand media/application sharing between peers. It extends the protocol identifier of the Session Description Protocol (SDP) so that it can negotiate use of the Internet Key Exchange Protocol (IKE) for media sessions in the SDP offer/answer model. It also specifies a method to boot up IKE and generate IPsec security associations using a self-signed certificate. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6192 - Protecting the Router Control Plane
This memo provides a method for protecting a router's control plane from undesired or malicious traffic. In this approach, all legitimate router control plane traffic is identified. Once legitimate traffic has been identified, a filter is deployed in the router's forwarding plane. That filter prevents traffic not specifically identified as legitimate from reaching the router's control plane, or rate-limits such traffic to an acceptable level.
RFC6191 - Reducing the TIME-WAIT State Using TCP Timestamps
This document describes an algorithm for processing incoming SYN segments that allows higher connection-establishment rates between any two TCP endpoints when a TCP Timestamps option is present in the incoming SYN segment. This document only modifies processing of SYN segments received for connections in the TIME-WAIT state; processing in all other states is unchanged. This memo documents an Internet Best Current Practice.
RFC6190 - RTP Payload Format for Scalable Video Coding
This memo describes an RTP payload format for Scalable Video Coding (SVC) as defined in Annex G of ITU-T Recommendation H.264, which is technically identical to Amendment 3 of ISO/IEC International Standard 14496-10. The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit in multiple RTP packets. Furthermore, it supports transmission of an SVC stream over a single as well as multiple RTP sessions. The payload format defines a new media subtype name "H264-SVC", but is still backward compatible to RFC 6184 since the base layer, when encapsulated in its own RTP stream, must use the H.264 media subtype name ("H264") and the packetization method specified in RFC 6184. The payload format has wide applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among others. [STANDARDS-TRACK]
RFC6189 - ZRTP: Media Path Key Agreement for Unicast Secure RTP
This document defines ZRTP, a protocol for media path Diffie-Hellman exchange to agree on a session key and parameters for establishing unicast Secure Real-time Transport Protocol (SRTP) sessions for Voice over IP (VoIP) applications. The ZRTP protocol is media path keying because it is multiplexed on the same port as RTP and does not require support in the signaling protocol. ZRTP does not assume a Public Key Infrastructure (PKI) or require the complexity of certificates in end devices. For the media session, ZRTP provides confidentiality, protection against man-in-the-middle (MiTM) attacks, and, in cases where the signaling protocol provides end-to-end integrity protection, authentication. ZRTP can utilize a Session Description Protocol (SDP) attribute to provide discovery and authentication through the signaling channel. To provide best effort SRTP, ZRTP utilizes normal RTP/AVP (Audio-Visual Profile) profiles. ZRTP secures media sessions that include a voice media stream and can also secure media sessions that do not include voice by using an optional digital signature. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6188 - The Use of AES-192 and AES-256 in Secure RTP
This memo describes the use of the Advanced Encryption Standard (AES) with 192- and 256-bit keys within the Secure RTP (SRTP) protocol. It details counter mode encryption for SRTP and Secure Realtime Transport Control Protocol (SRTCP) and a new SRTP Key Derivation Function (KDF) for AES-192 and AES-256. [STANDARDS-TRACK]
RFC6187 - X.509v3 Certificates for Secure Shell Authentication
X.509 public key certificates use a signature by a trusted certification authority to bind a given public key to a given digital identity. This document specifies how to use X.509 version 3 public key certificates in public key algorithms in the Secure Shell protocol. [STANDARDS-TRACK]
RFC6186 - Use of SRV Records for Locating Email Submission/Access Services
This specification describes how SRV records can be used to locate email services. [STANDARDS-TRACK]
RFC6185 - RTP Payload Format for H.264 Reduced-Complexity Decoding Operation (RCDO) Video
This document describes an RTP payload format for the Reduced- Complexity Decoding Operation (RCDO) for H.264 Baseline profile bitstreams, as specified in ITU-T Recommendation H.241. RCDO reduces the decoding cost and resource consumption of the video processing. The RCDO RTP payload format is based on the H.264 RTP payload format. [STANDARDS-TRACK]
RFC6184 - RTP Payload Format for H.264 Video
This memo describes an RTP Payload format for the ITU-T Recommendation H.264 video codec and the technically identical ISO/IEC International Standard 14496-10 video codec, excluding the Scalable Video Coding (SVC) extension and the Multiview Video Coding extension, for which the RTP payload formats are defined elsewhere. The RTP payload format allows for packetization of one or more Network Abstraction Layer Units (NALUs), produced by an H.264 video encoder, in each RTP payload. The payload format has wide applicability, as it supports applications from simple low bitrate conversational usage, to Internet video streaming with interleaved transmission, to high bitrate video-on-demand.
RFC6183 - IP Flow Information Export (IPFIX) Mediation: Framework
This document describes a framework for IP Flow Information Export (IPFIX) Mediation. This framework extends the IPFIX reference model specified in RFC 5470 by defining the IPFIX Mediator components. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6182 - Architectural Guidelines for Multipath TCP Development
Hosts are often connected by multiple paths, but TCP restricts communications to a single path per transport connection. Resource usage within the network would be more efficient were these multiple paths able to be used concurrently. This should enhance user experience through improved resilience to network failure and higher throughput.
RFC6181 - Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses
Multipath TCP (MPTCP for short) describes the extensions proposed for TCP so that endpoints of a given TCP connection can use multiple paths to exchange data. Such extensions enable the exchange of segments using different source-destination address pairs, resulting in the capability of using multiple paths in a significant number of scenarios. Some level of multihoming and mobility support can be achieved through these extensions. However, the support for multiple IP addresses per endpoint may have implications on the security of the resulting MPTCP. This note includes a threat analysis for MPTCP. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6180 - Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment
The Internet continues to grow beyond the capabilities of IPv4. An expansion in the address space is clearly required. With its increase in the number of available prefixes and addresses in a subnet, and improvements in address management, IPv6 is the only real option on the table. Yet, IPv6 deployment requires some effort, resources, and expertise. The availability of many different deployment models is one reason why expertise is required. This document discusses the IPv6 deployment models and migration tools, and it recommends ones that have been found to work well in operational networks in many common situations. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6179 - The Internet Routing Overlay Network (IRON)
Since the Internet must continue to support escalating growth due to increasing demand, it is clear that current routing architectures and operational practices must be updated. This document proposes an Internet Routing Overlay Network (IRON) that supports sustainable growth while requiring no changes to end systems and no changes to the existing routing system. IRON further addresses other important issues including routing scaling, mobility management, multihoming, traffic engineering and NAT traversal. While business considerations are an important determining factor for widespread adoption, they are out of scope for this document. This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.
RFC6178 - Label Edge Router Forwarding of IPv4 Option Packets
This document specifies how Label Edge Routers (LERs) should behave when determining whether to MPLS encapsulate an IPv4 packet with header options. Lack of a formal standard has resulted in different LER forwarding behaviors for IPv4 packets with header options despite being associated with a prefix-based Forwarding Equivalence Class (FEC). IPv4 option packets that belong to a prefix-based FEC, yet are forwarded into an IPv4/MPLS network without being MPLS- encapsulated, present a security risk against the MPLS infrastructure. Further, LERs that are unable to MPLS encapsulate IPv4 packets with header options cannot operate in certain MPLS environments. While this newly defined LER behavior is mandatory to implement, it is optional to invoke. [STANDARDS-TRACK]
RFC6177 - IPv6 Address Assignment to End Sites
RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks in most cases. The Regional Internet Registries (RIRs) adopted that recommendation in 2002, but began reconsidering the policy in 2005. This document obsoletes the RFC 3177 recommendations on the assignment of IPv6 address space to end sites. The exact choice of how much address space to assign end sites is an issue for the operational community. The IETF's role in this case is limited to providing guidance on IPv6 architectural and operational considerations. This document reviews the architectural and operational considerations of end site assignments as well as the motivations behind the original recommendations in RFC 3177. Moreover, this document clarifies that a one-size-fits-all recommendation of /48 is not nuanced enough for the broad range of end sites and is no longer recommended as a single default.
RFC6176 - Prohibiting Secure Sockets Layer (SSL) Version 2.0
This document requires that when Transport Layer Security (TLS) clients and servers establish connections, they never negotiate the use of Secure Sockets Layer (SSL) version 2.0. This document updates the backward compatibility sections found in the Transport Layer Security (TLS). [STANDARDS-TRACK]
RFC6175 - Requirements to Extend the Datatracker for IETF Working Group Chairs and Authors
This document specifies requirements for new functionality to be added to the IETF Datatracker tool to make it possible for Working Group (WG) Chairs and their Delegates to input and update the status of the Internet-Drafts (I-Ds) associated with their WGs. After these requirements are implemented, WG Chairs will be able to use the Datatracker to provide everyone with more information about the status and progression of WG I-Ds than is currently possible. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6174 - Definition of IETF Working Group Document States
The IETF Datatracker tool needs to be enhanced to make it possible for Working Group (WG) Chairs to provide IETF participants with more information about the status and progression of WG documents than is currently possible.
RFC6173 - Definitions of Managed Objects for the Internet Fibre Channel Protocol (iFCP)
This document defines Management Information Base (MIB) objects to monitor and control the Internet Fibre Channel Protocol (iFCP) gateway instances and their associated sessions, for use with network management protocols.
RFC6172 - Deprecation of the Internet Fibre Channel Protocol (iFCP) Address Translation Mode
Changes to Fibre Channel have caused the specification of the Internet Fibre Channel Protocol (iFCP) address translation mode to become incorrect. Due to the absence of usage of iFCP address translation mode, it is deprecated by this document. iFCP address transparent mode remains correctly specified.
RFC6171 - The Lightweight Directory Access Protocol (LDAP) Don't Use Copy Control
This document defines the Lightweight Directory Access Protocol (LDAP) Don't Use Copy control extension, which allows a client to specify that copied information should not be used in providing service. This control is based upon the X.511 dontUseCopy service control option. [STANDARDS-TRACK]
RFC6170 - Internet X.509 Public Key Infrastructure -- Certificate Image
This document specifies a method to bind a visual representation of a certificate in the form of a certificate image to a public key certificate as defined in RFC 5280, by defining a new "otherLogos" image type according to RFC 3709. [STANDARDS-TRACK]
RFC6169 - Security Concerns with IP Tunneling
A number of security concerns with IP tunnels are documented in this memo. The intended audience of this document includes network administrators and future protocol developers. The primary intent of this document is to raise the awareness level regarding the security issues with IP tunnels as deployed and propose strategies for the mitigation of those issues. [STANDARDS-TRACK]