Internet Society Frontpage

Search/Site Map Membership
About the Internet Standards
Publications Public Policy
About ISOC Education

Publications 

Become an ISOC Member

Internet Documents

RFCs 8100 - 8199s

RFCs All DocumentsSTDs Internet Standards DocumentsBCPs Best Current Practice DocumentsFYIs Informational Documents
 

 
RFC 8100 Diffserv-Interconnection Classes and Practice
 
Authors:R. Geib, Ed., D. Black.
Date:March 2017
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 8100
This document defines a limited common set of Diffserv Per-HopBehaviors (PHBs) and Diffserv Codepoints (DSCPs) to be applied at(inter)connections of two separately administered and operated networks, and it explains how this approach can simplify network configuration and operation. Many network providers operateMultiprotocol Label Switching (MPLS) using Treatment Aggregates for traffic marked with different Diffserv Per-Hop Behaviors and use MPLS for interconnection with other networks. This document offers a simple interconnection approach that may simplify operation ofDiffserv for network interconnection among providers that use MPLS and apply the Short Pipe Model. While motivated by the requirements of MPLS network operators that use Short Pipe Model tunnels, this document is applicable to other networks, both MPLS and non-MPLS.
 
RFC 8101 IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Namespace for Mission Critical Push To Talk Service
 
Authors:C. Holmberg, J. Axell.
Date:March 2017
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 8101
This document creates additional Session Initiation Protocol (SIP)Resource-Priority namespaces to meet the requirements of the3GPP-defined Mission Critical Push To Talk (MCPTT) and places these namespaces in the corresponding IANA registry.
 
RFC 8102 Remote-LFA Node Protection and Manageability
 
Authors:P. Sarkar, Ed., S. Hegde, C. Bowers, H. Gredler, S. Litkowski.
Date:March 2017
Formats:txt pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8102
The loop-free alternates (LFAs) computed following the current remote-LFA specification guarantees only link protection. The resulting remote-LFA next hops (also called "PQ-nodes") may not guarantee node protection for all destinations being protected by it.

This document describes an extension to the remote-loop-free-based IP fast reroute mechanisms that specifies procedures for determining whether or not a given PQ-node provides node protection for a specific destination. The document also shows how the same procedure can be utilized for the collection of complete characteristics for alternate paths. Knowledge about the characteristics of all alternate paths is a precursor to applying the operator-defined policy for eliminating paths not fitting the constraints.

 
RFC 8103 Using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS)
 
Authors:R. Housley.
Date:February 2017
Formats:txt pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8103
This document describes the conventions for using ChaCha20-Poly1305Authenticated Encryption in the Cryptographic Message Syntax (CMS).ChaCha20-Poly1305 is an authenticated encryption algorithm constructed of the ChaCha stream cipher and Poly1305 authenticator.
 
RFC 8104 Pseudowire (PW) Endpoint Fast Failure Protection
 
Authors:Y. Shen, R. Aggarwal, W. Henderickx, Y. Jiang.
Date:March 2017
Formats:txt pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8104
This document specifies a fast mechanism for protecting pseudowires(PWs) transported by IP/MPLS tunnels against egress endpoint failures, including egress attachment circuit (AC) failure, egress provider edge (PE) failure, multi-segment PW terminating PE failure, and multi-segment PW switching PE failure. Operating on the basis of multihomed customer edge (CE), redundant PWs, upstream label assignment, and context-specific label switching, the mechanism enables local repair to be performed by the router upstream adjacent to a failure. The router can restore a PW in the order of tens of milliseconds, by rerouting traffic around the failure to a protector through a pre-established bypass tunnel. Therefore, the mechanism can be used to reduce traffic loss before global repair reacts to the failure and the network converges on the topology changes due to the failure.
 
RFC 8106 IPv6 Router Advertisement Options for DNS Configuration
 
Authors:J. Jeong, S. Park, L. Beloeil, S. Madanapalli.
Date:March 2017
Formats:txt pdf
Obsoletes:RFC 6106
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8106
This document specifies IPv6 Router Advertisement (RA) options(called "DNS RA options") to allow IPv6 routers to advertise a list of DNS Recursive Server Addresses and a DNS Search List to IPv6 hosts.

This document, which obsoletes RFC 6106, defines a higher default value of the lifetime of the DNS RA options to reduce the likelihood of expiry of the options on links with a relatively high rate of packet loss.

 
RFC 8107 Advertising Digital Identifier (Ad-ID) URN Namespace Definition
 
Authors:J. Wold.
Date:March 2017
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 8107
Advertising Digital Identifiers (Ad-IDs) are used to identify advertising assets across all media platforms. This document defines the formal Uniform Resource Name (URN) Namespace Identifier (NID)"adid" for Ad-IDs.
 
RFC 8108 Sending Multiple RTP Streams in a Single RTP Session
 
Authors:J. Lennox, M. Westerlund, Q. Wu, C. Perkins.
Date:March 2017
Formats:txt pdf
Updates:RFC 3550, RFC 4585
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8108
This memo expands and clarifies the behavior of Real-time TransportProtocol (RTP) endpoints that use multiple synchronization sources(SSRCs). This occurs, for example, when an endpoint sends multipleRTP streams in a single RTP session. This memo updates RFC 3550 with regard to handling multiple SSRCs per endpoint in RTP sessions, with a particular focus on RTP Control Protocol (RTCP) behavior. It also updates RFC 4585 to change and clarify the calculation of the timeout of SSRCs and the inclusion of feedback messages.
 
RFC 8109 Initializing a DNS Resolver with Priming Queries
 
Authors:P. Koch, M. Larson, P. Hoffman.
Date:March 2017
Formats:txt pdf
Also:BCP 0209
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 8109
This document describes the queries that a DNS resolver should emit to initialize its cache. The result is that the resolver gets both a current NS Resource Record Set (RRset) for the root zone and the necessary address information for reaching the root servers.
 
RFC 8113 Locator/ID Separation Protocol (LISP): Shared Extension Message & IANA Registry for Packet Type Allocations
 
Authors:M. Boucadair, C. Jacquenet.
Date:March 2017
Formats:txt pdf
Updates:RFC 6830
Status:EXPERIMENTAL
DOI:10.17487/RFC 8113
This document specifies a Locator/ID Separation Protocol (LISP) shared message type for defining future extensions and conducting experiments without consuming a LISP packet type codepoint for each extension. It also defines a registry for LISP Packet Type allocations, thus updating RFC 6830.
 
RFC 8114 Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Multicast Network
 
Authors:M. Boucadair, C. Qin, C. Jacquenet, Y. Lee, Q. Wang.
Date:March 2017
Formats:txt pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8114
This document specifies a solution for the delivery of IPv4 multicast services to IPv4 clients over an IPv6 multicast network. The solution relies upon a stateless IPv4-in-IPv6 encapsulation scheme and uses an IPv6 multicast distribution tree to deliver IPv4 multicast traffic. The solution is particularly useful for the delivery of multicast service offerings to customers serviced byDual-Stack Lite (DS-Lite).
 
RFC 8115 DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 Prefixes
 
Authors:M. Boucadair, J. Qin, T. Tsou, X. Deng.
Date:March 2017
Formats:txt pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8115
This document defines a Dynamic Host Configuration Protocol version 6(DHCPv6) Option for multicast IPv4 service continuity solutions, which is used to carry the IPv6 prefixes to be used to build unicast and multicast IPv4-embedded IPv6 addresses.
 
RFC 8117 Current Hostname Practice Considered Harmful
 
Authors:C. Huitema, D. Thaler, R. Winter.
Date:March 2017
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 8117
Giving a hostname to your computer and publishing it as you roam from one network to another is the Internet's equivalent of walking around with a name tag affixed to your lapel. This current practice can significantly compromise your privacy, and something should change in order to mitigate these privacy threats.

There are several possible remedies, such as fixing a variety of protocols or avoiding disclosing a hostname at all. This document describes some of the protocols that reveal hostnames today and sketches another possible remedy, which is to replace static hostnames by frequently changing randomized values.

 
RFC 8118 The application/pdf Media Type
 
Authors:M. Hardy, L. Masinter, D. Markovic, D. Johnson, M. Bailey.
Date:March 2017
Formats:txt pdf
Obsoletes:RFC 3778
Status:INFORMATIONAL
DOI:10.17487/RFC 8118
The Portable Document Format (PDF) is an ISO standard (ISO32000-1:2008) defining a final-form document representation language in use for document exchange, including on the Internet, since 1993.This document provides an overview of the PDF format and updates the media type registration of "application/pdf". It obsoletes RFC 3778.
 
RFC 8119 SIP "cause" URI Parameter for Service Number Translation
 
Authors:M. Mohali, M. Barnes.
Date:March 2017
Formats:txt pdf
Updates:RFC 4458
Status:INFORMATIONAL
DOI:10.17487/RFC 8119
RFC 4458 (regarding SIP URIs for applications) defines a "cause" URI parameter, which may appear in the Request-URI of a SIP request, that is used to indicate a reason why the request arrived to the UserAgent Server (UAS) receiving the message. This document updates RFC4458 by creating a new predefined value for the "cause" URI parameter to cover service number translation for cases of retargeting due to specific service action leading to the translation of a called service access number. This document also provides guidance, which was missing in RFC 4458, for using the "cause" URI parameter within the History-Info header field, since this use is mandatory in some IP networks' implementations.
 
RFC 8122 Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)
 
Authors:J. Lennox, C. Holmberg.
Date:March 2017
Formats:txt pdf
Obsoletes:RFC 4572
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8122
This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines the SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured.

This document obsoletes RFC 4572 by clarifying the usage of multiple fingerprints.

 
RFC 8123 Requirements for Marking SIP Messages to be Logged
 
Authors:P. Dawes, C. Arunachalam.
Date:March 2017
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 8123
SIP networks use signaling monitoring tools to debug customer- reported problems and for regression testing if network or client software is upgraded. As networks grow and become interconnected, including connection via transit networks, it becomes impractical to predict the path that SIP signaling will take between clients and, therefore, impractical to monitor SIP signaling end-to-end.

This document describes the requirements for adding an indicator to the SIP Protocol Data Unit (PDU) or a SIP message that marks the PDU as a candidate for logging. Such a marking will typically be applied as part of network testing controlled by the network operator and not used in regular client signaling. However, such a marking can be carried end-to-end, including the SIP terminals, even if a session originates and terminates in different networks.

 
RFC 8128 IETF Appointment Procedures for the ICANN Root Zone Evolution Review Committee
 
Authors:C. Morgan.
Date:March 2017
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 8128
This memo outlines the process by which the IETF makes an appointment to the ICANN Root Zone Evolution Review Committee (RZERC).
 
RFC 8129 Authentication Indicator in Kerberos Tickets
 
Authors:A. Jain, N. Kinder, N. McCallum.
Date:March 2017
Formats:txt pdf
Updates:RFC 4120
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8129
This document updates RFC 4120, as it specifies an extension in theKerberos protocol. It defines a new authorization data type,AD-AUTHENTICATION-INDICATOR. The purpose of introducing this data type is to include an indicator of the strength of a client's authentication in service tickets so that application services can use it as an input into policy decisions.