RFC Abstracts
RFC5762 - RTP and the Datagram Congestion Control Protocol (DCCP)
The Real-time Transport Protocol (RTP) is a widely used transport for real-time multimedia on IP networks. The Datagram Congestion Control Protocol (DCCP) is a transport protocol that provides desirable services for real-time applications. This memo specifies a mapping of RTP onto DCCP, along with associated signalling, such that real- time applications can make use of the services provided by DCCP. [STANDARDS-TRACK]
RFC5761 - Multiplexing RTP Data and Control Packets on a Single Port
This memo discusses issues that arise when multiplexing RTP data packets and RTP Control Protocol (RTCP) packets on a single UDP port. It updates RFC 3550 and RFC 3551 to describe when such multiplexing is and is not appropriate, and it explains how the Session Description Protocol (SDP) can be used to signal multiplexed sessions. [STANDARDS-TRACK]
RFC5760 - RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback
This document specifies an extension to the Real-time Transport Control Protocol (RTCP) to use unicast feedback to a multicast sender. The proposed extension is useful for single-source multicast sessions such as Source-Specific Multicast (SSM) communication where the traditional model of many-to-many group communication is either not available or not desired. In addition, it can be applied to any group that might benefit from a sender-controlled summarized reporting mechanism. [STANDARDS-TRACK]
RFC5759 - Suite B Certificate and Certificate Revocation List (CRL) Profile
This document specifies a base profile for X.509 v3 Certificates and X.509 v2 Certificate Revocation Lists (CRLs) for use with the United States National Security Agency's Suite B Cryptography. The reader is assumed to have familiarity with RFC 5280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile". This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5758 - Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA
This document updates RFC 3279 to specify algorithm identifiers and ASN.1 encoding rules for the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures when using SHA-224, SHA-256, SHA-384, or SHA-512 as the hashing algorithm. This specification applies to the Internet X.509 Public Key infrastructure (PKI) when digital signatures are used to sign certificates and certificate revocation lists (CRLs). This document also identifies all four SHA2 hash algorithms for use in the Internet X.509 PKI. [STANDARDS-TRACK]
RFC5757 - Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey
This document discusses current mobility extensions to IP-layer multicast. It describes problems arising from mobile group communication in general, the case of multicast listener mobility, and problems for mobile senders using Any Source Multicast and Source-Specific Multicast. Characteristic aspects of multicast routing and deployment issues for fixed IPv6 networks are summarized. Specific properties and interplays with the underlying network access are surveyed with respect to the relevant technologies in the wireless domain. It outlines the principal approaches to multicast mobility, together with a comprehensive exploration of the mobile multicast problem and solution space. This document concludes with a conceptual road map for initial steps in standardization for use by future mobile multicast protocol designers. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5756 - Updates for RSAES-OAEP and RSASSA-PSS Algorithm Parameters
This document updates RFC 4055. It updates the conventions for using the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm in the Internet X.509 Public Key Infrastructure (PKI). Specifically, it updates the conventions for algorithm parameters in an X.509 certificate's subjectPublicKeyInfo field. [STANDARDS-TRACK]
RFC5755 - An Internet Attribute Certificate Profile for Authorization
This specification defines a profile for the use of X.509 Attribute Certificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPsec, and WWW security applications. This document obsoletes RFC 3281. [STANDARDS-TRACK]
RFC5754 - Using SHA2 Algorithms with Cryptographic Message Syntax
This document describes the conventions for using the Secure Hash Algorithm (SHA) message digest algorithms (SHA-224, SHA-256, SHA-384, SHA-512) with the Cryptographic Message Syntax (CMS). It also describes the conventions for using these algorithms with the CMS and the Digital Signature Algorithm (DSA), Rivest Shamir Adleman (RSA), and Elliptic Curve DSA (ECDSA) signature algorithms. Further, it provides SMIMECapabilities attribute values for each algorithm. [STANDARDS-TRACK]
RFC5753 - Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)
This document describes how to use Elliptic Curve Cryptography (ECC) public key algorithms in the Cryptographic Message Syntax (CMS). The ECC algorithms support the creation of digital signatures and the exchange of keys to encrypt or authenticate content. The definition of the algorithm processing is based on the NIST FIPS 186-3 for digital signature, NIST SP800-56A and SEC1 for key agreement, RFC 3370 and RFC 3565 for key wrap and content encryption, NIST FIPS 180-3 for message digest, SEC1 for key derivation, and RFC 2104 and RFC 4231 for message authentication code standards. This document obsoletes RFC 3278. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5752 - Multiple Signatures in Cryptographic Message Syntax (CMS)
Cryptographic Message Syntax (CMS) SignedData includes the SignerInfo structure to convey per-signer information. SignedData supports multiple signers and multiple signature algorithms per signer with multiple SignerInfo structures. If a signer attaches more than one SignerInfo, there are concerns that an attacker could perform a downgrade attack by removing the SignerInfo(s) with the \'strong' algorithm(s). This document defines the multiple-signatures attribute, its generation rules, and its processing rules to allow signers to convey multiple SignerInfo objects while protecting against downgrade attacks. Additionally, this attribute may assist during periods of algorithm migration. [STANDARDS-TRACK]
RFC5751 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification
This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.2. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 3851. [STANDARDS-TRACK]
RFC5750 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling
This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) v3.2 agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 5280, the Internet X.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME agents must meet the certificate processing requirements in this document as well as those in RFC 5280. This document obsoletes RFC 3850. [STANDARDS-TRACK]
RFC5749 - Distribution of EAP-Based Keys for Handover and Re-Authentication
This document describes an abstract mechanism for delivering root keys from an Extensible Authentication Protocol (EAP) server to another network server that requires the keys for offering security protected services, such as re-authentication, to an EAP peer. The distributed root key can be either a usage-specific root key (USRK), a domain-specific root key (DSRK), or a domain-specific usage- specific root key (DSUSRK) that has been derived from an Extended Master Session Key (EMSK) hierarchy previously established between the EAP server and an EAP peer. This document defines a template for a key distribution exchange (KDE) protocol that can distribute these different types of root keys using a AAA (Authentication, Authorization, and Accounting) protocol and discusses its security requirements. The described protocol template does not specify message formats, data encoding, or other implementation details. It thus needs to be instantiated with a specific protocol (e.g., RADIUS or Diameter) before it can be used. [STANDARDS-TRACK]
RFC5748 - IANA Registry Update for Support of the SEED Cipher Algorithm in Multimedia Internet KEYing (MIKEY)
This document updates IANA registries to support the SEED block cipher algorithm for the Secure Real-time Transport Protocol (SRTP) and the secure Real-time Transport Control Protocol (SRTCP) in Multimedia Internet KEYing (MIKEY). This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5747 - 4over6 Transit Solution Using IP Encapsulation and MP-BGP Extensions
The emerging and growing deployment of IPv6 networks will introduce cases where connectivity with IPv4 networks crossing IPv6 transit backbones is desired. This document describes a mechanism for automatic discovery and creation of IPv4-over-IPv6 tunnels via extensions to multiprotocol BGP. It is targeted at connecting islands of IPv4 networks across an IPv6-only backbone without the need for a manually configured overlay of tunnels. The mechanisms described in this document have been implemented, tested, and deployed on the large research IPv6 network in China. This document defines an Experimental Protocol for the Internet community.
RFC5746 - Transport Layer Security (TLS) Renegotiation Indication Extension
Secure Socket Layer (SSL) and Transport Layer Security (TLS) renegotiation are vulnerable to an attack in which the attacker forms a TLS connection with the target server, injects content of his choice, and then splices in a new TLS connection from a client. The server treats the client's initial TLS handshake as a renegotiation and thus believes that the initial data transmitted by the attacker is from the same entity as the subsequent client data. This specification defines a TLS extension to cryptographically tie renegotiations to the TLS connections they are being performed over, thus preventing this attack. [STANDARDS-TRACK]
RFC5745 - Procedures for Rights Handling in the RFC IAB Stream
This document specifies the procedures by which authors of RFC IAB stream documents grant the community "incoming" rights for copying and using the text. It also specifies the "outgoing" rights the community grants to readers and users of those documents, and it requests that the IETF Trust manage the outgoing rights to effect this result. This memo provides information for the Internet community.
RFC5744 - Procedures for Rights Handling in the RFC Independent Submission Stream
This document specifies the procedures by which authors of RFC Independent Submission documents grant the community "incoming" rights for copying and using the text. It also specifies the "outgoing" rights the community grants to readers and users of those documents, and it requests that the IETF Trust manage the outgoing rights to effect this result. This memo provides information for the Internet community.
RFC5743 - Definition of an Internet Research Task Force (IRTF) Document Stream
This memo defines the publication stream for RFCs from the Internet Research Task Force. Most documents undergoing this process will come from IRTF Research Groups, and it is expected that they will be published as Informational or Experimental RFCs by the RFC Editor. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5742 - IESG Procedures for Handling of Independent and IRTF Stream Submissions
This document describes the procedures used by the IESG for handling documents submitted for RFC publication from the Independent Submission and IRTF streams.
RFC5741 - RFC Streams, Headers, and Boilerplates
RFC documents contain a number of fixed elements such as the title page header, standard boilerplates, and copyright/IPR statements. This document describes them and introduces some updates to reflect current usage and requirements of RFC publication. In particular, this updated structure is intended to communicate clearly the source of RFC creation and review. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5740 - NACK-Oriented Reliable Multicast (NORM) Transport Protocol
This document describes the messages and procedures of the Negative- ACKnowledgment (NACK) Oriented Reliable Multicast (NORM) protocol. This protocol can provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services. NORM uses a selective, negative acknowledgment mechanism for transport reliability and offers additional protocol mechanisms to allow for operation with minimal a priori coordination among senders and receivers. A congestion control scheme is specified to allow the NORM protocol to fairly share available network bandwidth with other transport protocols such as Transmission Control Protocol (TCP). It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity (possibly a unicast return path) between the senders and receivers. The protocol offers a number of features to allow different types of applications or possibly other higher-level transport protocols to utilize its service in different ways. The protocol leverages the use of FEC-based (forward error correction) repair and other IETF Reliable Multicast Transport (RMT) building blocks in its design. This document obsoletes RFC 3940. [STANDARDS-TRACK]
RFC5739 - IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2)
When Internet Key Exchange Protocol version 2 (IKEv2) is used for remote VPN access (client to VPN gateway), the gateway assigns the client an IP address from the internal network using IKEv2 configuration payloads. The configuration payloads specified in RFC 4306 work well for IPv4 but make it difficult to use certain features of IPv6. This document specifies new configuration attributes for IKEv2 that allows the VPN gateway to assign IPv6 prefixes to clients, enabling all features of IPv6 to be used with the client-gateway "virtual link". This document defines an Experimental Protocol for the Internet community.
RFC5738 - IMAP Support for UTF-8
This specification extends the Internet Message Access Protocol version 4rev1 (IMAP4rev1) to support UTF-8 encoded international characters in user names, mail addresses, and message headers. This document defines an Experimental Protocol for the Internet community.
RFC5737 - IPv4 Address Blocks Reserved for Documentation
Three IPv4 unicast address blocks are reserved for use in examples in specifications and other documents. This document describes the use of these blocks. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5736 - IANA IPv4 Special Purpose Address Registry
This is a direction to IANA concerning the creation and management of the IANA IPv4 Special Purpose Address Registry. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5735 - Special Use IPv4 Addresses
This document obsoletes RFC 3330. It describes the global and other specialized IPv4 address blocks that have been assigned by the Internet Assigned Numbers Authority (IANA). It does not address IPv4 address space assigned to operators and users through the Regional Internet Registries, nor does it address IPv4 address space assigned directly by IANA prior to the creation of the Regional Internet Registries. It also does not address allocations or assignments of IPv6 addresses or autonomous system numbers. This memo documents an Internet Best Current Practice.
RFC5734 - Extensible Provisioning Protocol (EPP) Transport over TCP
This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server. This document obsoletes RFC 4934. [STANDARDS-TRACK]
RFC5733 - Extensible Provisioning Protocol (EPP) Contact Mapping
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as "contacts") stored in a shared central repository. Specified in Extensible Markup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts. This document obsoletes RFC 4933. [STANDARDS-TRACK]
RFC5732 - Extensible Provisioning Protocol (EPP) Host Mapping
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names. This document obsoletes RFC 4932. [STANDARDS-TRACK]
RFC5731 - Extensible Provisioning Protocol (EPP) Domain Name Mapping
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names. This document obsoletes RFC 4931. [STANDARDS-TRACK]
RFC5730 - Extensible Provisioning Protocol (EPP)
This document describes an application-layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. This document obsoletes RFC 4930. [STANDARDS-TRACK]
RFC5729 - Clarifications on the Routing of Diameter Requests Based on the Username and the Realm
This specification defines the behavior required of Diameter agents to route requests when the User-Name Attribute Value Pair contains a Network Access Identifier formatted with multiple realms. These multi-realm, or "Decorated", Network Access Identifiers are used in order to force the routing of request messages through a predefined list of mediating realms. [STANDARDS-TRACK]
RFC5728 - The SatLabs Group DVB-RCS MIB
This document describes the MIB module for the Digital Video Broadcasting Return Channel via Satellite system (DVB-RCS), as defined by the SatLabs Group. It defines a set of MIB objects to characterize the behavior and performance of network-layer entities deploying DVB-RCS. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5727 - Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area
This memo documents a process intended to organize the future development of the Session Initiation Protocol (SIP) and related work in the Real-time Applications and Infrastructure (RAI) Area. As the environments in which SIP is deployed grow more numerous and diverse, modifying or extending SIP in certain ways may threaten the interoperability and security of the protocol; however, the IETF process must also cater to the realities of existing deployments and serve the needs of the implementers working with SIP. This document therefore defines the functions of two long-lived working groups in the RAI Area that are, respectively, responsible for the maintenance of the core SIP specifications and the development of new efforts to extend and apply work in this space. This document obsoletes RFC 3427. This memo documents an Internet Best Current Practice.
RFC5726 - Mobile IPv6 Location Privacy Solutions
Mobile IPv6 (RFC 3775) enables a mobile node to remain reachable while it roams on the Internet. However, the location and movement of the mobile node can be revealed by the IP addresses used in signaling or data packets. In this document, we consider the Mobile IPv6 location privacy problem described in RFC 4882, and propose efficient and secure techniques to protect location privacy of the mobile node. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group. This document defines an Experimental Protocol for the Internet community.
RFC5725 - Post-Repair Loss RLE Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)
This document defines a new report block type within the framework of RTP Control Protocol (RTCP) Extended Reports (XRs). One of the initial XR report block types is the Loss Run Length Encoding (RLE) Report Block. This report conveys information regarding the individual Real-time Transport Protocol (RTP) packet receipt and loss events experienced during the RTCP interval preceding the transmission of the report. The new report, which is referred to as the Post-repair Loss RLE report, carries information regarding the packets that remain lost after all loss-repair methods are applied. By comparing the RTP packet receipts/losses before and after the loss repair is completed, one can determine the effectiveness of the loss- repair methods in an aggregated fashion. This document also defines the signaling of the Post-repair Loss RLE report in the Session Description Protocol (SDP). [STANDARDS-TRACK]
RFC5724 - URI Scheme for Global System for Mobile Communications (GSM) Short Message Service (SMS)
This memo specifies the Uniform Resource Identifier (URI) scheme "sms" for specifying one or more recipients for an SMS message. SMS messages are two-way paging messages that can be sent from and received by a mobile phone or a suitably equipped networked device. [STANDARDS-TRACK]
RFC5723 - Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption
The Internet Key Exchange version 2 (IKEv2) protocol has a certain computational and communication overhead with respect to the number of round trips required and the cryptographic operations involved. In remote access situations, the Extensible Authentication Protocol (EAP) is used for authentication, which adds several more round trips and consequently latency.
RFC5722 - Handling of Overlapping IPv6 Fragments
The fragmentation and reassembly algorithm specified in the base IPv6 specification allows fragments to overlap. This document demonstrates the security issues associated with allowing overlapping fragments and updates the IPv6 specification to explicitly forbid overlapping fragments. [STANDARDS-TRACK]
RFC5721 - POP3 Support for UTF-8
This specification extends the Post Office Protocol version 3 (POP3) to support un-encoded international characters in user names, passwords, mail addresses, message headers, and protocol-level textual error strings. This document defines an Experimental Protocol for the Internet community.
RFC5720 - Routing and Addressing in Networks with Global Enterprise Recursion (RANGER)
RANGER is an architectural framework for scalable routing and addressing in networks with global enterprise recursion. The term "enterprise network" within this context extends to a wide variety of use cases and deployment scenarios, where an "enterprise" can be as small as a Small Office, Home Office (SOHO) network, as dynamic as a Mobile Ad Hoc Network, as complex as a multi-organizational corporation, or as large as the global Internet itself. Such networks will require an architected solution for the coordination of routing and addressing plans with accommodations for scalability, provider-independence, mobility, multihoming, and security. These considerations are particularly true for existing deployments, but the same principles apply even for clean-slate approaches. The RANGER architecture addresses these requirements and provides a comprehensive framework for IPv6/IPv4 coexistence. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5719 - Updated IANA Considerations for Diameter Command Code Allocations
The Diameter base specification, described in RFC 3588, provides a number of ways to extend Diameter, with new Diameter commands (i.e., messages used by Diameter applications) and applications as the most extensive enhancements. RFC 3588 illustrates the conditions that lead to the need to define a new Diameter application or a new command code. Depending on the scope of the Diameter extension, IETF actions are necessary. Although defining new Diameter applications does not require IETF consensus, defining new Diameter commands requires IETF consensus per RFC 3588. This has led to questionable design decisions by other Standards Development Organizations, which chose to define new applications on existing commands -- rather than asking for assignment of new command codes -- for the pure purpose of avoiding bringing their specifications to the IETF. In some cases, interoperability problems were an effect of the poor design caused by overloading existing commands.
RFC5718 - An In-Band Data Communication Network For the MPLS Transport Profile
The Generic Associated Channel (G-ACh) has been defined as a generalization of the pseudowire (PW) associated control channel to enable the realization of a control/communication channel that is associated with Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs), MPLS PWs, MPLS LSP segments, and MPLS sections between adjacent MPLS-capable devices.
RFC5717 - Partial Lock Remote Procedure Call (RPC) for NETCONF
The Network Configuration protocol (NETCONF) defines the lock and unlock Remote Procedure Calls (RPCs), used to lock entire configuration datastores. In some situations, a way to lock only parts of a configuration datastore is required. This document defines a capability-based extension to the NETCONF protocol for locking portions of a configuration datastore. [STANDARDS-TRACK]
RFC5716 - Requirements for Federated File Systems
This document describes and lists the functional requirements of a federated file system and defines related terms. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5715 - A Framework for Loop-Free Convergence
A micro-loop is a packet forwarding loop that may occur transiently among two or more routers in a hop-by-hop packet forwarding paradigm.
RFC5714 - IP Fast Reroute Framework
This document provides a framework for the development of IP fast- reroute mechanisms that provide protection against link or router failure by invoking locally determined repair paths. Unlike MPLS fast-reroute, the mechanisms are applicable to a network employing conventional IP routing and forwarding. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5713 - Security Threats and Security Requirements for the Access Node Control Protocol (ANCP)
The Access Node Control Protocol (ANCP) aims to communicate Quality of Service (QoS)-related, service-related, and subscriber-related configurations and operations between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)). The main goal of this protocol is to allow the NAS to configure, manage, and control access equipment, including the ability for the Access Nodes to report information to the NAS.
The Real-time Transport Protocol (RTP) is a widely used transport for real-time multimedia on IP networks. The Datagram Congestion Control Protocol (DCCP) is a transport protocol that provides desirable services for real-time applications. This memo specifies a mapping of RTP onto DCCP, along with associated signalling, such that real- time applications can make use of the services provided by DCCP. [STANDARDS-TRACK]
RFC5761 - Multiplexing RTP Data and Control Packets on a Single Port
This memo discusses issues that arise when multiplexing RTP data packets and RTP Control Protocol (RTCP) packets on a single UDP port. It updates RFC 3550 and RFC 3551 to describe when such multiplexing is and is not appropriate, and it explains how the Session Description Protocol (SDP) can be used to signal multiplexed sessions. [STANDARDS-TRACK]
RFC5760 - RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback
This document specifies an extension to the Real-time Transport Control Protocol (RTCP) to use unicast feedback to a multicast sender. The proposed extension is useful for single-source multicast sessions such as Source-Specific Multicast (SSM) communication where the traditional model of many-to-many group communication is either not available or not desired. In addition, it can be applied to any group that might benefit from a sender-controlled summarized reporting mechanism. [STANDARDS-TRACK]
RFC5759 - Suite B Certificate and Certificate Revocation List (CRL) Profile
This document specifies a base profile for X.509 v3 Certificates and X.509 v2 Certificate Revocation Lists (CRLs) for use with the United States National Security Agency's Suite B Cryptography. The reader is assumed to have familiarity with RFC 5280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile". This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5758 - Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA
This document updates RFC 3279 to specify algorithm identifiers and ASN.1 encoding rules for the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures when using SHA-224, SHA-256, SHA-384, or SHA-512 as the hashing algorithm. This specification applies to the Internet X.509 Public Key infrastructure (PKI) when digital signatures are used to sign certificates and certificate revocation lists (CRLs). This document also identifies all four SHA2 hash algorithms for use in the Internet X.509 PKI. [STANDARDS-TRACK]
RFC5757 - Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey
This document discusses current mobility extensions to IP-layer multicast. It describes problems arising from mobile group communication in general, the case of multicast listener mobility, and problems for mobile senders using Any Source Multicast and Source-Specific Multicast. Characteristic aspects of multicast routing and deployment issues for fixed IPv6 networks are summarized. Specific properties and interplays with the underlying network access are surveyed with respect to the relevant technologies in the wireless domain. It outlines the principal approaches to multicast mobility, together with a comprehensive exploration of the mobile multicast problem and solution space. This document concludes with a conceptual road map for initial steps in standardization for use by future mobile multicast protocol designers. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5756 - Updates for RSAES-OAEP and RSASSA-PSS Algorithm Parameters
This document updates RFC 4055. It updates the conventions for using the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm in the Internet X.509 Public Key Infrastructure (PKI). Specifically, it updates the conventions for algorithm parameters in an X.509 certificate's subjectPublicKeyInfo field. [STANDARDS-TRACK]
RFC5755 - An Internet Attribute Certificate Profile for Authorization
This specification defines a profile for the use of X.509 Attribute Certificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPsec, and WWW security applications. This document obsoletes RFC 3281. [STANDARDS-TRACK]
RFC5754 - Using SHA2 Algorithms with Cryptographic Message Syntax
This document describes the conventions for using the Secure Hash Algorithm (SHA) message digest algorithms (SHA-224, SHA-256, SHA-384, SHA-512) with the Cryptographic Message Syntax (CMS). It also describes the conventions for using these algorithms with the CMS and the Digital Signature Algorithm (DSA), Rivest Shamir Adleman (RSA), and Elliptic Curve DSA (ECDSA) signature algorithms. Further, it provides SMIMECapabilities attribute values for each algorithm. [STANDARDS-TRACK]
RFC5753 - Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)
This document describes how to use Elliptic Curve Cryptography (ECC) public key algorithms in the Cryptographic Message Syntax (CMS). The ECC algorithms support the creation of digital signatures and the exchange of keys to encrypt or authenticate content. The definition of the algorithm processing is based on the NIST FIPS 186-3 for digital signature, NIST SP800-56A and SEC1 for key agreement, RFC 3370 and RFC 3565 for key wrap and content encryption, NIST FIPS 180-3 for message digest, SEC1 for key derivation, and RFC 2104 and RFC 4231 for message authentication code standards. This document obsoletes RFC 3278. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5752 - Multiple Signatures in Cryptographic Message Syntax (CMS)
Cryptographic Message Syntax (CMS) SignedData includes the SignerInfo structure to convey per-signer information. SignedData supports multiple signers and multiple signature algorithms per signer with multiple SignerInfo structures. If a signer attaches more than one SignerInfo, there are concerns that an attacker could perform a downgrade attack by removing the SignerInfo(s) with the \'strong' algorithm(s). This document defines the multiple-signatures attribute, its generation rules, and its processing rules to allow signers to convey multiple SignerInfo objects while protecting against downgrade attacks. Additionally, this attribute may assist during periods of algorithm migration. [STANDARDS-TRACK]
RFC5751 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification
This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.2. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 3851. [STANDARDS-TRACK]
RFC5750 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling
This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) v3.2 agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 5280, the Internet X.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME agents must meet the certificate processing requirements in this document as well as those in RFC 5280. This document obsoletes RFC 3850. [STANDARDS-TRACK]
RFC5749 - Distribution of EAP-Based Keys for Handover and Re-Authentication
This document describes an abstract mechanism for delivering root keys from an Extensible Authentication Protocol (EAP) server to another network server that requires the keys for offering security protected services, such as re-authentication, to an EAP peer. The distributed root key can be either a usage-specific root key (USRK), a domain-specific root key (DSRK), or a domain-specific usage- specific root key (DSUSRK) that has been derived from an Extended Master Session Key (EMSK) hierarchy previously established between the EAP server and an EAP peer. This document defines a template for a key distribution exchange (KDE) protocol that can distribute these different types of root keys using a AAA (Authentication, Authorization, and Accounting) protocol and discusses its security requirements. The described protocol template does not specify message formats, data encoding, or other implementation details. It thus needs to be instantiated with a specific protocol (e.g., RADIUS or Diameter) before it can be used. [STANDARDS-TRACK]
RFC5748 - IANA Registry Update for Support of the SEED Cipher Algorithm in Multimedia Internet KEYing (MIKEY)
This document updates IANA registries to support the SEED block cipher algorithm for the Secure Real-time Transport Protocol (SRTP) and the secure Real-time Transport Control Protocol (SRTCP) in Multimedia Internet KEYing (MIKEY). This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5747 - 4over6 Transit Solution Using IP Encapsulation and MP-BGP Extensions
The emerging and growing deployment of IPv6 networks will introduce cases where connectivity with IPv4 networks crossing IPv6 transit backbones is desired. This document describes a mechanism for automatic discovery and creation of IPv4-over-IPv6 tunnels via extensions to multiprotocol BGP. It is targeted at connecting islands of IPv4 networks across an IPv6-only backbone without the need for a manually configured overlay of tunnels. The mechanisms described in this document have been implemented, tested, and deployed on the large research IPv6 network in China. This document defines an Experimental Protocol for the Internet community.
RFC5746 - Transport Layer Security (TLS) Renegotiation Indication Extension
Secure Socket Layer (SSL) and Transport Layer Security (TLS) renegotiation are vulnerable to an attack in which the attacker forms a TLS connection with the target server, injects content of his choice, and then splices in a new TLS connection from a client. The server treats the client's initial TLS handshake as a renegotiation and thus believes that the initial data transmitted by the attacker is from the same entity as the subsequent client data. This specification defines a TLS extension to cryptographically tie renegotiations to the TLS connections they are being performed over, thus preventing this attack. [STANDARDS-TRACK]
RFC5745 - Procedures for Rights Handling in the RFC IAB Stream
This document specifies the procedures by which authors of RFC IAB stream documents grant the community "incoming" rights for copying and using the text. It also specifies the "outgoing" rights the community grants to readers and users of those documents, and it requests that the IETF Trust manage the outgoing rights to effect this result. This memo provides information for the Internet community.
RFC5744 - Procedures for Rights Handling in the RFC Independent Submission Stream
This document specifies the procedures by which authors of RFC Independent Submission documents grant the community "incoming" rights for copying and using the text. It also specifies the "outgoing" rights the community grants to readers and users of those documents, and it requests that the IETF Trust manage the outgoing rights to effect this result. This memo provides information for the Internet community.
RFC5743 - Definition of an Internet Research Task Force (IRTF) Document Stream
This memo defines the publication stream for RFCs from the Internet Research Task Force. Most documents undergoing this process will come from IRTF Research Groups, and it is expected that they will be published as Informational or Experimental RFCs by the RFC Editor. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5742 - IESG Procedures for Handling of Independent and IRTF Stream Submissions
This document describes the procedures used by the IESG for handling documents submitted for RFC publication from the Independent Submission and IRTF streams.
RFC5741 - RFC Streams, Headers, and Boilerplates
RFC documents contain a number of fixed elements such as the title page header, standard boilerplates, and copyright/IPR statements. This document describes them and introduces some updates to reflect current usage and requirements of RFC publication. In particular, this updated structure is intended to communicate clearly the source of RFC creation and review. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5740 - NACK-Oriented Reliable Multicast (NORM) Transport Protocol
This document describes the messages and procedures of the Negative- ACKnowledgment (NACK) Oriented Reliable Multicast (NORM) protocol. This protocol can provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services. NORM uses a selective, negative acknowledgment mechanism for transport reliability and offers additional protocol mechanisms to allow for operation with minimal a priori coordination among senders and receivers. A congestion control scheme is specified to allow the NORM protocol to fairly share available network bandwidth with other transport protocols such as Transmission Control Protocol (TCP). It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity (possibly a unicast return path) between the senders and receivers. The protocol offers a number of features to allow different types of applications or possibly other higher-level transport protocols to utilize its service in different ways. The protocol leverages the use of FEC-based (forward error correction) repair and other IETF Reliable Multicast Transport (RMT) building blocks in its design. This document obsoletes RFC 3940. [STANDARDS-TRACK]
RFC5739 - IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2)
When Internet Key Exchange Protocol version 2 (IKEv2) is used for remote VPN access (client to VPN gateway), the gateway assigns the client an IP address from the internal network using IKEv2 configuration payloads. The configuration payloads specified in RFC 4306 work well for IPv4 but make it difficult to use certain features of IPv6. This document specifies new configuration attributes for IKEv2 that allows the VPN gateway to assign IPv6 prefixes to clients, enabling all features of IPv6 to be used with the client-gateway "virtual link". This document defines an Experimental Protocol for the Internet community.
RFC5738 - IMAP Support for UTF-8
This specification extends the Internet Message Access Protocol version 4rev1 (IMAP4rev1) to support UTF-8 encoded international characters in user names, mail addresses, and message headers. This document defines an Experimental Protocol for the Internet community.
RFC5737 - IPv4 Address Blocks Reserved for Documentation
Three IPv4 unicast address blocks are reserved for use in examples in specifications and other documents. This document describes the use of these blocks. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5736 - IANA IPv4 Special Purpose Address Registry
This is a direction to IANA concerning the creation and management of the IANA IPv4 Special Purpose Address Registry. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5735 - Special Use IPv4 Addresses
This document obsoletes RFC 3330. It describes the global and other specialized IPv4 address blocks that have been assigned by the Internet Assigned Numbers Authority (IANA). It does not address IPv4 address space assigned to operators and users through the Regional Internet Registries, nor does it address IPv4 address space assigned directly by IANA prior to the creation of the Regional Internet Registries. It also does not address allocations or assignments of IPv6 addresses or autonomous system numbers. This memo documents an Internet Best Current Practice.
RFC5734 - Extensible Provisioning Protocol (EPP) Transport over TCP
This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server. This document obsoletes RFC 4934. [STANDARDS-TRACK]
RFC5733 - Extensible Provisioning Protocol (EPP) Contact Mapping
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as "contacts") stored in a shared central repository. Specified in Extensible Markup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts. This document obsoletes RFC 4933. [STANDARDS-TRACK]
RFC5732 - Extensible Provisioning Protocol (EPP) Host Mapping
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names. This document obsoletes RFC 4932. [STANDARDS-TRACK]
RFC5731 - Extensible Provisioning Protocol (EPP) Domain Name Mapping
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names. This document obsoletes RFC 4931. [STANDARDS-TRACK]
RFC5730 - Extensible Provisioning Protocol (EPP)
This document describes an application-layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. This document obsoletes RFC 4930. [STANDARDS-TRACK]
RFC5729 - Clarifications on the Routing of Diameter Requests Based on the Username and the Realm
This specification defines the behavior required of Diameter agents to route requests when the User-Name Attribute Value Pair contains a Network Access Identifier formatted with multiple realms. These multi-realm, or "Decorated", Network Access Identifiers are used in order to force the routing of request messages through a predefined list of mediating realms. [STANDARDS-TRACK]
RFC5728 - The SatLabs Group DVB-RCS MIB
This document describes the MIB module for the Digital Video Broadcasting Return Channel via Satellite system (DVB-RCS), as defined by the SatLabs Group. It defines a set of MIB objects to characterize the behavior and performance of network-layer entities deploying DVB-RCS. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5727 - Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area
This memo documents a process intended to organize the future development of the Session Initiation Protocol (SIP) and related work in the Real-time Applications and Infrastructure (RAI) Area. As the environments in which SIP is deployed grow more numerous and diverse, modifying or extending SIP in certain ways may threaten the interoperability and security of the protocol; however, the IETF process must also cater to the realities of existing deployments and serve the needs of the implementers working with SIP. This document therefore defines the functions of two long-lived working groups in the RAI Area that are, respectively, responsible for the maintenance of the core SIP specifications and the development of new efforts to extend and apply work in this space. This document obsoletes RFC 3427. This memo documents an Internet Best Current Practice.
RFC5726 - Mobile IPv6 Location Privacy Solutions
Mobile IPv6 (RFC 3775) enables a mobile node to remain reachable while it roams on the Internet. However, the location and movement of the mobile node can be revealed by the IP addresses used in signaling or data packets. In this document, we consider the Mobile IPv6 location privacy problem described in RFC 4882, and propose efficient and secure techniques to protect location privacy of the mobile node. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group. This document defines an Experimental Protocol for the Internet community.
RFC5725 - Post-Repair Loss RLE Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)
This document defines a new report block type within the framework of RTP Control Protocol (RTCP) Extended Reports (XRs). One of the initial XR report block types is the Loss Run Length Encoding (RLE) Report Block. This report conveys information regarding the individual Real-time Transport Protocol (RTP) packet receipt and loss events experienced during the RTCP interval preceding the transmission of the report. The new report, which is referred to as the Post-repair Loss RLE report, carries information regarding the packets that remain lost after all loss-repair methods are applied. By comparing the RTP packet receipts/losses before and after the loss repair is completed, one can determine the effectiveness of the loss- repair methods in an aggregated fashion. This document also defines the signaling of the Post-repair Loss RLE report in the Session Description Protocol (SDP). [STANDARDS-TRACK]
RFC5724 - URI Scheme for Global System for Mobile Communications (GSM) Short Message Service (SMS)
This memo specifies the Uniform Resource Identifier (URI) scheme "sms" for specifying one or more recipients for an SMS message. SMS messages are two-way paging messages that can be sent from and received by a mobile phone or a suitably equipped networked device. [STANDARDS-TRACK]
RFC5723 - Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption
The Internet Key Exchange version 2 (IKEv2) protocol has a certain computational and communication overhead with respect to the number of round trips required and the cryptographic operations involved. In remote access situations, the Extensible Authentication Protocol (EAP) is used for authentication, which adds several more round trips and consequently latency.
RFC5722 - Handling of Overlapping IPv6 Fragments
The fragmentation and reassembly algorithm specified in the base IPv6 specification allows fragments to overlap. This document demonstrates the security issues associated with allowing overlapping fragments and updates the IPv6 specification to explicitly forbid overlapping fragments. [STANDARDS-TRACK]
RFC5721 - POP3 Support for UTF-8
This specification extends the Post Office Protocol version 3 (POP3) to support un-encoded international characters in user names, passwords, mail addresses, message headers, and protocol-level textual error strings. This document defines an Experimental Protocol for the Internet community.
RFC5720 - Routing and Addressing in Networks with Global Enterprise Recursion (RANGER)
RANGER is an architectural framework for scalable routing and addressing in networks with global enterprise recursion. The term "enterprise network" within this context extends to a wide variety of use cases and deployment scenarios, where an "enterprise" can be as small as a Small Office, Home Office (SOHO) network, as dynamic as a Mobile Ad Hoc Network, as complex as a multi-organizational corporation, or as large as the global Internet itself. Such networks will require an architected solution for the coordination of routing and addressing plans with accommodations for scalability, provider-independence, mobility, multihoming, and security. These considerations are particularly true for existing deployments, but the same principles apply even for clean-slate approaches. The RANGER architecture addresses these requirements and provides a comprehensive framework for IPv6/IPv4 coexistence. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5719 - Updated IANA Considerations for Diameter Command Code Allocations
The Diameter base specification, described in RFC 3588, provides a number of ways to extend Diameter, with new Diameter commands (i.e., messages used by Diameter applications) and applications as the most extensive enhancements. RFC 3588 illustrates the conditions that lead to the need to define a new Diameter application or a new command code. Depending on the scope of the Diameter extension, IETF actions are necessary. Although defining new Diameter applications does not require IETF consensus, defining new Diameter commands requires IETF consensus per RFC 3588. This has led to questionable design decisions by other Standards Development Organizations, which chose to define new applications on existing commands -- rather than asking for assignment of new command codes -- for the pure purpose of avoiding bringing their specifications to the IETF. In some cases, interoperability problems were an effect of the poor design caused by overloading existing commands.
RFC5718 - An In-Band Data Communication Network For the MPLS Transport Profile
The Generic Associated Channel (G-ACh) has been defined as a generalization of the pseudowire (PW) associated control channel to enable the realization of a control/communication channel that is associated with Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs), MPLS PWs, MPLS LSP segments, and MPLS sections between adjacent MPLS-capable devices.
RFC5717 - Partial Lock Remote Procedure Call (RPC) for NETCONF
The Network Configuration protocol (NETCONF) defines the lock and unlock Remote Procedure Calls (RPCs), used to lock entire configuration datastores. In some situations, a way to lock only parts of a configuration datastore is required. This document defines a capability-based extension to the NETCONF protocol for locking portions of a configuration datastore. [STANDARDS-TRACK]
RFC5716 - Requirements for Federated File Systems
This document describes and lists the functional requirements of a federated file system and defines related terms. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5715 - A Framework for Loop-Free Convergence
A micro-loop is a packet forwarding loop that may occur transiently among two or more routers in a hop-by-hop packet forwarding paradigm.
RFC5714 - IP Fast Reroute Framework
This document provides a framework for the development of IP fast- reroute mechanisms that provide protection against link or router failure by invoking locally determined repair paths. Unlike MPLS fast-reroute, the mechanisms are applicable to a network employing conventional IP routing and forwarding. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5713 - Security Threats and Security Requirements for the Access Node Control Protocol (ANCP)
The Access Node Control Protocol (ANCP) aims to communicate Quality of Service (QoS)-related, service-related, and subscriber-related configurations and operations between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)). The main goal of this protocol is to allow the NAS to configure, manage, and control access equipment, including the ability for the Access Nodes to report information to the NAS.