Internet Documents

RFCs 8700 - 8799s

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

 
RFC 8700 Fifty Years of RFCs
 
Authors:H. Flanagan, Ed..
Date:December 2019
Formats:txt json pdf xml html
Updates:RFC 2555, RFC 5540
Status:INFORMATIONAL
DOI:10.17487/RFC 8700
This RFC marks the fiftieth anniversary for the RFC Series. It includes both retrospective material from individuals involved at key inflection points as well as a review of the current state of affairs. It concludes with thoughts on possibilities for the next fifty years for the Series. This document updates the perspectives offered in RFCs 2555 and 5540.
 
RFC 8701 Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility
 
Authors:D. Benjamin.
Date:January 2020
Formats:txt json html pdf xml
Status:INFORMATIONAL
DOI:10.17487/RFC 8701
This document describes GREASE (Generate Random Extensions AndSustain Extensibility), a mechanism to prevent extensibility failures in the TLS ecosystem. It reserves a set of TLS protocol values that may be advertised to ensure peers correctly handle unknown values.
 
RFC 8702 Use of the SHAKE One-Way Hash Functions in the Cryptographic Message Syntax (CMS)
 
Authors:P. Kampanakis, Q. Dang.
Date:January 2020
Formats:txt html xml pdf json
Updates:RFC 3370
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8702
This document updates the "Cryptographic Message Syntax (CMS)Algorithms" (RFC 3370) and describes the conventions for using theSHAKE family of hash functions in the Cryptographic Message Syntax as one-way hash functions with the RSA Probabilistic Signature Scheme(RSASSA-PSS) and Elliptic Curve Digital Signature Algorithm (ECDSA).The conventions for the associated signer public keys in CMS are also described.
 
RFC 8703 Dynamic Link Exchange Protocol (DLEP) Link Identifier Extension
 
Authors:R. Taylor, S. Ratliff.
Date:February 2020
Formats:txt xml html pdf json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8703
The Dynamic Link Exchange Protocol (DLEP) is a protocol for modems to advertise the status of wireless links between reachable destinations to attached routers. The core specification of the protocol (RFC8175) assumes that every modem in the radio network has an attachedDLEP router and requires that the Media Access Control (MAC) address of the DLEP interface on the attached router be used to identify the destination in the network, for purposes of reporting the state and quality of the link to that destination.

This document describes a DLEP extension that allows modems that do not meet the strict requirement above to use DLEP to describe link availability and quality to one or more destinations reachable beyond a device on the Layer 2 domain.

 
RFC 8704 Enhanced Feasible-Path Unicast Reverse Path Forwarding
 
Authors:K. Sriram, D. Montgomery, J. Haas.
Date:February 2020
Formats:txt json xml pdf html
Updates:RFC 3704
Also:BCP 0084
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 8704
This document identifies a need for and proposes improvement of the unicast Reverse Path Forwarding (uRPF) techniques (see RFC 3704) for detection and mitigation of source address spoofing (see BCP 38).Strict uRPF is inflexible about directionality, the loose uRPF is oblivious to directionality, and the current feasible-path uRPF attempts to strike a balance between the two (see RFC 3704).However, as shown in this document, the existing feasible-path uRPF still has shortcomings. This document describes enhanced feasible- path uRPF (EFP-uRPF) techniques that are more flexible (in a meaningful way) about directionality than the feasible-path uRPF (RFC3704). The proposed EFP-uRPF methods aim to significantly reduce false positives regarding invalid detection in source address validation (SAV). Hence, they can potentially alleviate ISPs' concerns about the possibility of disrupting service for their customers and encourage greater deployment of uRPF techniques. This document updates RFC 3704.
 
RFC 8705 OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
 
Authors:B. Campbell, J. Bradley, N. Sakimura, T. Lodderstedt.
Date:February 2020
Formats:txt xml pdf json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8705
This document describes OAuth client authentication and certificate- bound access and refresh tokens using mutual Transport Layer Security(TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token.
 
RFC 8706 Restart Signaling for IS-IS
 
Authors:L. Ginsberg, P. Wells.
Date:February 2020
Formats:txt html pdf json xml
Obsoletes:RFC 5306
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8706
This document describes a mechanism for a restarting router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the DOWN state while still correctly initiating database synchronization.

This document additionally describes a mechanism for a router to signal its neighbors that it is preparing to initiate a restart while maintaining forwarding-plane state. This allows the neighbors to maintain their adjacencies until the router has restarted but also allows the neighbors to bring the adjacencies down in the event of other topology changes.

This document additionally describes a mechanism for a restarting router to determine when it has achieved Link State Protocol DataUnit (LSP) database synchronization with its neighbors and a mechanism to optimize LSP database synchronization while minimizing transient routing disruption when a router starts.

This document obsoletes RFC 5306.

 
RFC 8707 Resource Indicators for OAuth 2.0
 
Authors:B. Campbell, J. Bradley, H. Tschofenig.
Date:February 2020
Formats:txt html pdf json xml
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8707
This document specifies an extension to the OAuth 2.0 AuthorizationFramework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access.
 
RFC 8708 Use of the HSS/LMS Hash-Based Signature Algorithm in the Cryptographic Message Syntax (CMS)
 
Authors:R. Housley.
Date:February 2020
Formats:txt json pdf xml html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8708
This document specifies the conventions for using the HierarchicalSignature System (HSS) / Leighton-Micali Signature (LMS) hash-based signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. The HSS/LMS algorithm is one form of hash-based digital signature; it is described in RFC 8554.
 
RFC 8709 Ed25519 and Ed448 Public Key Algorithms for the Secure Shell (SSH) Protocol
 
Authors:B. Harris, L. Velvindron.
Date:February 2020
Formats:txt json html pdf xml
Updates:RFC 4253
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8709
This document describes the use of the Ed25519 and Ed448 digital signature algorithms in the Secure Shell (SSH) protocol.Accordingly, this RFC updates RFC 4253.
 
RFC 8710 Multipart Content-Format for the Constrained Application Protocol (CoAP)
 
Authors:T. Fossati, K. Hartke, C. Bormann.
Date:February 2020
Formats:txt json xml html pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8710
This memo defines application/multipart-core, an application- independent media type that can be used to combine representations of zero or more different media types (each with a ConstrainedApplication Protocol (CoAP) Content-Format identifier) into a single representation, with minimal framing overhead.
 
RFC 8711 Structure of the IETF Administrative Support Activity, Version 2.0
 
Authors:B. Haberman, J. Hall, J. Livingood.
Date:February 2020
Formats:txt json html xml pdf
Obsoletes:RFC 4071, RFC 4333, RFC 7691
Also:BCP 0101
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 8711
The IETF Administrative Support Activity (IASA) was originally established in 2005. In the years since then, the needs of the IETF evolved in ways that required changes to its administrative structure. The purpose of this RFC is to document and describe theIETF Administrative Support Activity, version 2.0 (IASA 2.0). It defines the roles and responsibilities of the IETF Administration LLCBoard (IETF LLC Board), the IETF Executive Director, and the InternetSociety in the fiscal and administrative support of the IETF standards process. It also defines the membership and selection rules for the IETF LLC Board.

This document obsoletes RFC 4071, RFC 4333, and RFC 7691.

 
RFC 8712 The IETF-ISOC Relationship
 
Authors:G. Camarillo, J. Livingood.
Date:February 2020
Formats:txt html pdf xml json
Obsoletes:RFC 2031
Status:INFORMATIONAL
DOI:10.17487/RFC 8712
This document summarizes the Internet Engineering Task Force (IETF) -Internet Society (ISOC) relationship, following a major revision to the structure of the IETF Administrative Support Activity (IASA) in2018. The IASA was revised under a new "IASA 2.0" structure by theIASA2 Working Group, which changed the IETF's administrative, legal, and financial structure. As a result, it also changed the relationship between the IETF and ISOC, which made it necessary to revise RFC 2031.
 
RFC 8713 IAB, IESG, IETF Trust, and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees
 
Authors:M. Kucherawy, Ed., R. Hinden, Ed., J. Livingood, Ed..
Date:February 2020
Formats:txt pdf xml html json
Obsoletes:RFC 7437, RFC 8318
Also:BCP 0010
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 8713
The process by which the members of the IAB and IESG, some Trustees of the IETF Trust, and some Directors of the IETF Administration LLC(IETF LLC) are selected, confirmed, and recalled is specified in this document. This document is based on RFC 7437. Only those updates required to reflect the changes introduced by IETF AdministrativeSupport Activity (IASA) 2.0 have been included. Any other changes will be addressed in future documents.

This document obsoletes RFC 7437 and RFC 8318.

 
RFC 8714 Update to the Process for Selection of Trustees for the IETF Trust
 
Authors:J. Arkko, T. Hardie.
Date:February 2020
Formats:txt pdf json xml html
Obsoletes:RFC 4371
Also:BCP 0101
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 8714
This memo updates the process for selection of Trustees for the IETFTrust. Previously, the IETF Administrative Oversight Committee(IAOC) members also acted as Trustees, but the IAOC has been eliminated as part of an update to the structure of the IETFAdministrative Support Activity (IASA). This memo specifies that theTrustees shall be selected separately.

This memo obsoletes RFC 4371. The changes relate only to the selection of Trustees. All other aspects of the IETF Trust remain as they are today.

 
RFC 8715 IETF Administrative Support Activity 2.0: Update to the Process for Selection of Trustees for the IETF Trust
 
Authors:J. Arkko.
Date:February 2020
Formats:txt pdf json xml html
Status:INFORMATIONAL
DOI:10.17487/RFC 8715
This document captures the rationale for the changes introduced inRFC 8714, "Update to the Process for Selection of Trustees for theIETF Trust".

At the time RFC 8714 was published, the changes to the IETFAdministrative Support Activity, Version 2.0 (IASA 2.0) had an impact on the IETF Trust because members of the IETF AdministrativeOversight Committee (IAOC), which was being phased out, had served asTrustees of the IETF Trust. This document provides background on the past IETF Trust arrangements, explains the effect of the rules in the founding documents during the transition to the new arrangement, and provides a rationale for the update.

 
RFC 8716 Update to the IETF Anti-Harassment Procedures for the Replacement of the IETF Administrative Oversight Committee (IAOC) with the IETF Administration LLC
 
Authors:P. Resnick, A. Farrel.
Date:February 2020
Formats:txt html xml pdf json
Updates:RFC 7776
Also:BCP 0025
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 8716
The IETF Anti-Harassment Procedures are described in RFC 7776.

The IETF Administrative Oversight Committee (IAOC) has been replaced by the IETF Administration LLC, and the IETF Administrative Director has been replaced by the IETF LLC Executive Director. This document updates RFC 7776 to amend these terms.

RFC 7776 contained updates to RFC 7437. RFC 8713 has incorporated those updates, so this document also updates RFC 7776 to remove those updates.

 
RFC 8717 IETF Administrative Support Activity 2.0: Consolidated Updates to IETF Administrative Terminology
 
Authors:J. Klensin, Ed..
Date:February 2020
Formats:txt html json xml pdf
Updates:RFC 2028, RFC 2418, RFC 3005, RFC 3710, RFC 3929, RFC 4633, RFC 6702
Also:BCP 0101
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 8717
In 2018, the IETF began the transition to a new administrative structure and updated its IETF Administrative Support Activity (IASA) to a new "IASA 2.0" structure. In addition to more substantive changes that are described in other documents, the transition to the2018 IETF Administrative Support structure changes several position titles and organizational relationships that are referenced elsewhere. Rather than reissue those referencing documents individually, this specification provides updates to them and deprecates some now-obsolete documents to ensure that there is no confusion due to these changes.
 
RFC 8718 IETF Plenary Meeting Venue Selection Process
 
Authors:E. Lear, Ed..
Date:February 2020
Formats:txt json xml pdf html
Also:BCP 0226
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 8718
The IETF Administration Support Activity (IASA) is responsible for arranging the selection and operation of the IETF plenary meeting venue. This memo specifies IETF community requirements for meeting venues, including hotels and meeting space. It also directs the IASA to make available additional process documents that describe the current meeting selection process.
 
RFC 8719 High-Level Guidance for the Meeting Policy of the IETF
 
Authors:S. Krishnan.
Date:February 2020
Formats:txt json html xml pdf
Also:BCP 0226
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 8719
This document describes a meeting location policy for the IETF and the various stakeholders required to realize this policy.
 
RFC 8720 Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries
 
Authors:R. Housley, Ed., O. Kolkman, Ed..
Date:February 2020
Formats:txt json pdf xml html
Obsoletes:RFC 7500
Status:INFORMATIONAL
DOI:10.17487/RFC 8720
This document provides principles for the operation of InternetAssigned Numbers Authority (IANA) registries.
 
RFC 8721 Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents
 
Authors:J. Halpern, Ed..
Date:February 2020
Formats:txt pdf xml json html
Obsoletes:RFC 5377
Status:INFORMATIONAL
DOI:10.17487/RFC 8721
Contributors grant intellectual property rights to the IETF. TheIETF Trust holds and manages those rights on behalf of the IETF. TheTrustees of the IETF Trust are responsible for that management. This management includes granting the licenses to copy, implement, and otherwise use IETF Contributions, among them Internet-Drafts andRFCs. The Trustees of the IETF Trust accept direction from the IETF regarding the rights to be granted. This document describes the desires of the IETF regarding outbound rights to be granted in IETFContributions. This document obsoletes RFC 5377 solely for the purpose of removing references to the IETF Administrative OversightCommittee (IAOC), which was part of the IETF Administrative SupportActivity (IASA).
 
RFC 8722 Defining the Role and Function of IETF Protocol Parameter Registry Operators
 
Authors:D. McPherson, Ed., O. Kolkman, Ed., J. Klensin, Ed., G. Huston, Ed..
Date:February 2020
Formats:txt html json xml pdf
Obsoletes:RFC 6220
Status:INFORMATIONAL
DOI:10.17487/RFC 8722
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 obsoletes RFC 6220 to replace all references to the IETF Administrative Support Activity (IASA) and related structures with those defined by the IASA 2.0 Model.
 
RFC 8723 Double Encryption Procedures for the Secure Real-Time Transport Protocol (SRTP)
 
Authors:C. Jennings, P. Jones, R. Barnes, A.B. Roach.
Date:April 2020
Formats:txt html xml pdf json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8723
In some conferencing scenarios, it is desirable for an intermediary to be able to manipulate some parameters in Real-time TransportProtocol (RTP) packets, while still providing strong end-to-end security guarantees. This document defines a cryptographic transform for the Secure Real-time Transport Protocol (SRTP) that uses two separate but related cryptographic operations to provide hop-by-hop and end-to-end security guarantees. Both the end-to-end and hop-by- hop cryptographic algorithms can utilize an authenticated encryption with associated data (AEAD) algorithm or take advantage of futureSRTP transforms with different properties.
 
RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation
 
Authors:A. Minaburo, L. Toutain, C. Gomez, D. Barthel, JC. Zúñiga.
Date:April 2020
Formats:txt json xml html pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8724
This document defines the Static Context Header Compression and fragmentation (SCHC) framework, which provides both a header compression mechanism and an optional fragmentation mechanism. SCHC has been designed with Low-Power Wide Area Networks (LPWANs) in mind.

SCHC compression is based on a common static context stored both in the LPWAN device and in the network infrastructure side. This document defines a generic header compression mechanism and its application to compress IPv6/UDP headers.

This document also specifies an optional fragmentation and reassembly mechanism. It can be used to support the IPv6 MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 datagrams that, after SCHC compression or when such compression was not possible, still exceed the Layer 2 maximum payload size.

The SCHC header compression and fragmentation mechanisms are independent of the specific LPWAN technology over which they are used. This document defines generic functionalities and offers flexibility with regard to parameter settings and mechanism choices.This document standardizes the exchange over the LPWAN between twoSCHC entities. Settings and choices specific to a technology or a product are expected to be grouped into profiles, which are specified in other documents. Data models for the context and profiles are out of scope.

 
RFC 8725 JSON Web Token Best Current Practices
 
Authors:Y. Sheffer, D. Hardt, M. Jones.
Date:February 2020
Formats:txt json xml pdf html
Updates:RFC 7519
Also:BCP 0225
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 8725
JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. ThisBest Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs.
 
RFC 8728 RFC Editor Model (Version 2)
 
Authors:O. Kolkman, Ed., J. Halpern, Ed., R. Hinden, Ed..
Date:February 2020
Formats:txt pdf xml json html
Obsoletes:RFC 6635
Status:INFORMATIONAL
DOI:10.17487/RFC 8728
The RFC Editor model described in this document divides the responsibilities for the RFC Series into three functions: the RFCSeries Editor, the RFC Production Center, and the RFC Publisher.Internet Architecture Board (IAB) oversight via the RFC SeriesOversight Committee (RSOC) is described, as is the relationship between the IETF Administration Limited Liability Company and theRSOC. This document reflects the experience gained with "RFC EditorModel (Version 1)", documented in RFC 5620; and obsoletes RFC 6635 to replace all references to the IETF Administrative Support Activity(IASA) and related structures with those defined by the IASA 2.0Model.
 
RFC 8729 The RFC Series and RFC Editor
 
Authors:R. Housley, Ed., L. Daigle, Ed..
Date:February 2020
Formats:txt json pdf xml html
Obsoletes:RFC 4844
Status:INFORMATIONAL
DOI:10.17487/RFC 8729
This document describes the framework for an RFC Series and an RFCEditor function that incorporate the principles of organized community involvement and accountability that has become necessary as the Internet technical community has grown, thereby enabling the RFCSeries to continue to fulfill its mandate. This document obsoletesRFC 4844.
 
RFC 8730 Independent Submission Editor Model
 
Authors:N. Brownlee, Ed., B. Hinden, Ed..
Date:February 2020
Formats:txt xml pdf json html
Obsoletes:RFC 6548
Status:INFORMATIONAL
DOI:10.17487/RFC 8730
This document describes the function and responsibilities of the RFCIndependent Submission Editor (ISE). The Independent Submission stream is one of the stream producers that create draft RFCs, with the ISE as its stream approver. The ISE is overall responsible for activities within the Independent Submission stream, working with draft editors and reviewers, and interacts with the RFC ProductionCenter and Publisher, and the RFC Series Editor (RSE). The ISE is appointed by the IAB, and also interacts with the IETF AdministrationLimited Liability Company (LLC).

This version obsoletes RFC 6548 to replace all references to theInternet Administrative Support Activity (IASA) and related structures with those defined by the IASA 2.0 structure.

 
RFC 8731 Secure Shell (SSH) Key Exchange Method Using Curve25519 and Curve448
 
Authors:A. Adamantiadis, S. Josefsson, M. Baushke.
Date:February 2020
Formats:txt json xml pdf html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8731
This document describes the specification for using Curve25519 andCurve448 key exchange methods in the Secure Shell (SSH) protocol.
 
RFC 8732 Generic Security Service Application Program Interface (GSS-API) Key Exchange with SHA-2
 
Authors:S. Sorce, H. Kario.
Date:February 2020
Formats:txt html pdf xml json
Updates:RFC 4462
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8732
This document specifies additions and amendments to RFC 4462. It defines a new key exchange method that uses SHA-2 for integrity and deprecates weak Diffie-Hellman (DH) groups. The purpose of this specification is to modernize the cryptographic primitives used byGeneric Security Service (GSS) key exchanges.
 
RFC 8733 Path Computation Element Communication Protocol (PCEP) Extensions for MPLS-TE Label Switched Path (LSP) Auto-Bandwidth Adjustment with Stateful PCE
 
Authors:D. Dhody, Ed., R. Gandhi, Ed., U. Palle, R. Singh, L. Fang.
Date:February 2020
Formats:txt html pdf json xml
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8733
The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.Stateful PCE extensions allow stateful control of MPLS-TE LabelSwitched Paths (LSPs) using PCEP.

The auto-bandwidth feature allows automatic and dynamic adjustment of the TE LSP bandwidth reservation based on the volume of traffic flowing through the LSP. This document describes PCEP extensions for auto-bandwidth adjustment when employing an active stateful PCE for both PCE-initiated and PCC-initiated LSPs.

 
RFC 8734 Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS) Version 1.3
 
Authors:L. Bruckert, J. Merkle, M. Lochter.
Date:February 2020
Formats:txt json html pdf xml
Status:INFORMATIONAL
DOI:10.17487/RFC 8734
Elliptic Curve Cryptography (ECC) Brainpool curves were an option for authentication and key exchange in the Transport Layer Security (TLS) protocol version 1.2 but were deprecated by the IETF for use with TLS version 1.3 because they had little usage. However, these curves have not been shown to have significant cryptographical weaknesses, and there is some interest in using several of these curves in TLS1.3.

This document provides the necessary protocol mechanisms for usingECC Brainpool curves in TLS 1.3. This approach is not endorsed by the IETF.

 
RFC 8735 Scenarios and Simulation Results of PCE in a Native IP Network
 
Authors:A. Wang, X. Huang, C. Kou, Z. Li, P. Mi.
Date:February 2020
Formats:txt json pdf xml html
Status:INFORMATIONAL
DOI:10.17487/RFC 8735
Requirements for providing the End-to-End (E2E) performance assurance are emerging within the service provider networks. While there are various technology solutions, there is no single solution that can fulfill these requirements for a native IP network. In particular, there is a need for a universal E2E solution that can cover both intra- and inter-domain scenarios.

One feasible E2E traffic-engineering solution is the addition of central control in a native IP network. This document describes various complex scenarios and simulation results when applying thePath Computation Element (PCE) in a native IP network. This solution, referred to as Centralized Control Dynamic Routing (CCDR), integrates the advantage of using distributed protocols and the power of a centralized control technology, providing traffic engineering for native IP networks in a manner that applies equally to intra- and inter-domain scenarios.

 
RFC 8736 PIM Message Type Space Extension and Reserved Bits
 
Authors:S. Venaas, A. Retana.
Date:February 2020
Formats:txt xml pdf html json
Obsoletes:RFC 6166
Updates:RFC 3973, RFC 5015, RFC 5059, RFC 6754, RFC 7761, RFC 8364
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8736
The PIM version 2 messages share a common message header format. The common header definition contains eight reserved bits. This document specifies how these bits may be used by individual message types and creates a registry containing the per-message-type usage. This document also extends the PIM type space by defining three new message types. For each of the new types, four of the previously reserved bits are used to form an extended type range.

This document updates RFCs 7761 and 3973 by defining the use of the currently Reserved field in the PIM common header. This document further updates RFCs 7761 and 3973, along with RFCs 5015, 5059, 6754, and 8364, by specifying the use of the currently reserved bits for each PIM message.

This document obsoletes RFC 6166.

 
RFC 8737 Automated Certificate Management Environment (ACME) TLS Application-Layer Protocol Negotiation (ALPN) Challenge Extension
 
Authors:R.B. Shoemaker.
Date:February 2020
Formats:txt html xml pdf json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8737
This document specifies a new challenge for the Automated CertificateManagement Environment (ACME) protocol that allows for domain control validation using TLS.
 
RFC 8738 Automated Certificate Management Environment (ACME) IP Identifier Validation Extension
 
Authors:R.B. Shoemaker.
Date:February 2020
Formats:txt xml json pdf html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8738
This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for IP addresses.
 
RFC 8739 Support for Short-Term, Automatically Renewed (STAR) Certificates in the Automated Certificate Management Environment (ACME)
 
Authors:Y. Sheffer, D. Lopez, O. Gonzalez de Dios, A. Pastor Perales, T. Fossati.
Date:March 2020
Formats:txt xml json pdf html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8739
Public key certificates need to be revoked when they are compromised, that is, when the associated private key is exposed to an unauthorized entity. However, the revocation process is often unreliable. An alternative to revocation is issuing a sequence of certificates, each with a short validity period, and terminating the sequence upon compromise. This memo proposes an AutomatedCertificate Management Environment (ACME) extension to enable the issuance of Short-Term, Automatically Renewed (STAR) X.509 certificates.
 
RFC 8740 Using TLS 1.3 with HTTP/2
 
Authors:D. Benjamin.
Date:February 2020
Formats:txt html pdf json xml
Updates:RFC 7540
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8740
This document updates RFC 7540 by forbidding TLS 1.3 post-handshake authentication, as an analog to the existing TLS 1.2 renegotiation restriction.
 
RFC 8741 Ability for a Stateful Path Computation Element (PCE) to Request and Obtain Control of a Label Switched Path (LSP)
 
Authors:A. Raghuram, A. Goddard, J. Karthik, S. Sivabalan, M. Negi.
Date:March 2020
Formats:txt html pdf json xml
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8741
A stateful Path Computation Element (PCE) retains information about the placement of Multiprotocol Label Switching (MPLS) TrafficEngineering Label Switched Paths (TE LSPs). When a PCE has stateful control over LSPs, it may send indications to LSP head-ends to modify the attributes (especially the paths) of the LSPs. A PathComputation Client (PCC) that has set up LSPs under local configuration may delegate control of those LSPs to a stateful PCE.

There are use cases in which a stateful PCE may wish to obtain control of locally configured LSPs that it is aware of but have not been delegated to the PCE.

This document describes an extension to the Path Computation ElementCommunication Protocol (PCEP) to enable a PCE to make requests for such control.

 
RFC 8742 Concise Binary Object Representation (CBOR) Sequences
 
Authors:C. Bormann.
Date:February 2020
Formats:txt xml pdf json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8742
This document describes the Concise Binary Object Representation(CBOR) Sequence format and associated media type "application/cbor- seq". A CBOR Sequence consists of any number of encoded CBOR data items, simply concatenated in sequence.

Structured syntax suffixes for media types allow other media types to build on them and make it explicit that they are built on an existing media type as their foundation. This specification defines and registers "+cbor-seq" as a structured syntax suffix for CBORSequences.

 
RFC 8743 Multiple Access Management Services Multi-Access Management Services (MAMS)
 
Authors:S. Kanugovi, F. Baboescu, J. Zhu, S. Seo.
Date:March 2020
Formats:txt json xml pdf html
Status:INFORMATIONAL
DOI:10.17487/RFC 8743
In multiconnectivity scenarios, the clients can simultaneously connect to multiple networks based on different access technologies and network architectures like Wi-Fi, LTE, and DSL. Both the quality of experience of the users and the overall network utilization and efficiency may be improved through the smart selection and combination of access and core network paths that can dynamically adapt to changing network conditions.

This document presents a unified problem statement and introduces a solution for managing multiconnectivity. The solution has been developed by the authors based on their experiences in multiple standards bodies, including the IETF and the 3GPP. However, this document is not an Internet Standards Track specification, and it does not represent the consensus opinion of the IETF.

This document describes requirements, solution principles, and the architecture of the Multi-Access Management Services (MAMS) framework. The MAMS framework aims to provide best performance while being easy to implement in a wide variety of multiconnectivity deployments. It specifies the protocol for (1) flexibly selecting the best combination of access and core network paths for the uplink and downlink, and (2) determining the user-plane treatment (e.g., tunneling, encryption) and traffic distribution over the selected links, to ensure network efficiency and the best possible application performance.

 
RFC 8745 Path Computation Element Communication Protocol (PCEP) Extensions for Associating Working and Protection Label Switched Paths (LSPs) with Stateful PCE
 
Authors:H. Ananthakrishnan, S. Sivabalan, C. Barth, I. Minei, M. Negi.
Date:March 2020
Formats:txt xml pdf html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8745
An active stateful Path Computation Element (PCE) is capable of computing as well as controlling via Path Computation ElementCommunication Protocol (PCEP) Multiprotocol Label Switching TrafficEngineering (MPLS-TE) Label Switched Paths (LSPs). Furthermore, it is also possible for an active stateful PCE to create, maintain, and delete LSPs. This document defines the PCEP extension to associate two or more LSPs to provide end-to-end path protection.
 
RFC 8746 Concise Binary Object Representation (CBOR) Tags for Typed Arrays
 
Authors:C. Bormann, Ed..
Date:February 2020
Formats:txt json html pdf xml
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8746
The Concise Binary Object Representation (CBOR), as defined in RFC7049, is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation.

This document makes use of this extensibility to define a number ofCBOR tags for typed arrays of numeric data, as well as additional tags for multi-dimensional and homogeneous arrays. It is intended as the reference document for the IANA registration of the CBOR tags defined.

 
RFC 8747 Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)
 
Authors:M. Jones, L. Seitz, G. Selander, S. Erdtman, H. Tschofenig.
Date:March 2020
Formats:txt json pdf xml html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8747
This specification describes how to declare in a CBOR Web Token (CWT)(which is defined by RFC 8392) that the presenter of the CWT possesses a particular proof-of-possession key. Being able to prove possession of a key is also sometimes described as being the holder- of-key. This specification provides equivalent functionality to"Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC7800) but using Concise Binary Object Representation (CBOR) and CWTs rather than JavaScript Object Notation (JSON) and JSON Web Tokens(JWTs).
 
RFC 8748 Registry Fee Extension for the Extensible Provisioning Protocol (EPP)
 
Authors:R. Carney, G. Brown, J. Frakes.
Date:March 2020
Formats:txt html json pdf xml
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8748
Given the expansion of the DNS namespace and the proliferation of novel business models, it is desirable to provide a method forExtensible Provisioning Protocol (EPP) clients to query EPP servers for the fees and credits associated with various billable transactions and provide expected fees and credits for certain commands and objects. This document describes an EPP extension mapping for registry fees.
 
RFC 8749 Moving DNSSEC Lookaside Validation (DLV) to Historic Status
 
Authors:W. Mekking, D. Mahoney.
Date:March 2020
Formats:txt html pdf xml json
Updates:RFC 6698, RFC 6840
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8749
This document retires DNSSEC Lookaside Validation (DLV) and reclassifies RFCs 4431 and 5074 as Historic. Furthermore, this document updates RFC 6698 by excluding the DLV resource record from certificates and updates RFC 6840 by excluding the DLV registries from the trust anchor selection.
 
RFC 8750 Implicit Initialization Vector (IV) for Counter-Based Ciphers in Encapsulating Security Payload (ESP)
 
Authors:D. Migault, T. Guggemos, Y. Nir.
Date:March 2020
Formats:txt html json xml pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8750
Encapsulating Security Payload (ESP) sends an initialization vector(IV) in each packet. The size of the IV depends on the applied transform and is usually 8 or 16 octets for the transforms defined at the time this document was written. When used with IPsec, some algorithms, such as AES-GCM, AES-CCM, and ChaCha20-Poly1305, take theIV to generate a nonce that is used as an input parameter for encrypting and decrypting. This IV must be unique but can be predictable. As a result, the value provided in the ESP SequenceNumber (SN) can be used instead to generate the nonce. This avoids sending the IV itself and saves 8 octets per packet in the case ofAES-GCM, AES-CCM, and ChaCha20-Poly1305. This document describes how to do this.
 
RFC 8751 Hierarchical Stateful Path Computation Element (PCE)
 
Authors:D. Dhody, Y. Lee, D. Ceccarelli, J. Shin, D. King.
Date:March 2020
Formats:txt html xml pdf json
Status:INFORMATIONAL
DOI:10.17487/RFC 8751
A stateful Path Computation Element (PCE) maintains information on the current network state received from the Path Computation Clients(PCCs), including computed Label Switched Paths (LSPs), reserved resources within the network, and pending path computation requests.This information may then be considered when computing the path for a new traffic-engineered LSP or for any associated/dependent LSPs. The path-computation response from a PCE helps the PCC to gracefully establish the computed LSP.

The Hierarchical Path Computation Element (H-PCE) architecture allows the optimum sequence of interconnected domains to be selected and network policy to be applied if applicable, via the use of a hierarchical relationship between PCEs.

Combining the capabilities of stateful PCE and the hierarchical PCE would be advantageous. This document describes general considerations and use cases for the deployment of stateful, but not stateless, PCEs using the hierarchical PCE architecture.

 
RFC 8752 Report from the IAB Workshop on Exploring Synergy between Content Aggregation and the Publisher Ecosystem (ESCAPE)
 
Authors:M. Thomson, M. Nottingham.
Date:March 2020
Formats:txt pdf json xml html
Status:INFORMATIONAL
DOI:10.17487/RFC 8752
The Exploring Synergy between Content Aggregation and the PublisherEcosystem (ESCAPE) Workshop was convened by the Internet ArchitectureBoard (IAB) in July 2019. This report summarizes its significant points of discussion and identifies topics that may warrant further consideration.

Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.

 
RFC 8753 Internationalized Domain Names for Applications (IDNA) Review for New Unicode Versions
 
Authors:J. Klensin, P. Fältström.
Date:April 2020
Formats:txt pdf json xml html
Updates:RFC 5892
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8753
The standards for Internationalized Domain Names in Applications(IDNA) require a review of each new version of Unicode to determine whether incompatibilities with prior versions or other issues exist and, where appropriate, to allow the IETF to decide on the trade-offs between compatibility with prior IDNA versions and compatibility withUnicode going forward. That requirement, and its relationship to tables maintained by IANA, has caused significant confusion in the past. This document makes adjustments to the review procedure based on experience and updates IDNA, specifically RFC 5892, to reflect those changes and to clarify the various relationships involved. It also makes other minor adjustments to align that document with experience.
 
RFC 8754 IPv6 Segment Routing Header (SRH)
 
Authors:C. Filsfils, Ed., D. Dukes, Ed., S. Previdi, J. Leddy, S. Matsushima, D. Voyer.
Date:March 2020
Formats:txt pdf xml html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8754
Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header(SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable.
 
RFC 8755 Using Commercial National Security Algorithm Suite Algorithms in Secure/Multipurpose Internet Mail Extensions
 
Authors:M. Jenkins.
Date:March 2020
Formats:txt html pdf xml json
Status:INFORMATIONAL
DOI:10.17487/RFC 8755
The United States Government has published the National SecurityAgency (NSA) Commercial National Security Algorithm (CNSA) Suite, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using theUnited States National Security Agency's CNSA Suite algorithms inSecure/Multipurpose Internet Mail Extensions (S/MIME) as specified inRFC 8551. It applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ S/MIME messaging. US National Security Systems are described in NIST Special Publication 800-59. It is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments.
 
RFC 8756 Commercial National Security Algorithm (CNSA) Suite Profile of Certificate Management over CMS
 
Authors:M. Jenkins, L. Zieglar.
Date:March 2020
Formats:txt json xml pdf html
Status:INFORMATIONAL
DOI:10.17487/RFC 8756
This document specifies a profile of the Certificate Management overCMS (CMC) protocol for managing X.509 public key certificates in applications that use the Commercial National Security Algorithm(CNSA) Suite published by the United States Government.

The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that manage X.509 public key certificates over CMS. It is also appropriate for all other US Government systems that process high-value information.

The profile is made publicly available here for use by developers and operators of these and any other system deployments.

 
RFC 8757 Dynamic Link Exchange Protocol (DLEP) Latency Range Extension
 
Authors:B. Cheng, L. Berger, Ed..
Date:March 2020
Formats:txt json xml html pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8757
This document defines an extension to the Dynamic Link ExchangeProtocol (DLEP) to provide the range of latency that can be experienced on a link.
 
RFC 8758 Deprecating RC4 in Secure Shell (SSH)
 
Authors:L. Velvindron.
Date:April 2020
Formats:txt html xml json pdf
Updates:RFC 4253
Also:BCP 0227
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 8758
This document deprecates RC4 in Secure Shell (SSH). Therefore, this document formally moves RFC 4345 to Historic status.
 
RFC 8759 RTP Payload for Timed Text Markup Language (TTML)
 
Authors:J. Sandford.
Date:March 2020
Formats:txt html xml pdf json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8759
This memo describes a Real-time Transport Protocol (RTP) payload format for Timed Text Markup Language (TTML), an XML-based timed text format from W3C. This payload format is specifically targeted at streaming workflows using TTML.
 
RFC 8760 The Session Initiation Protocol (SIP) Digest Access Authentication Scheme
 
Authors:R. Shekh-Yusef.
Date:March 2020
Formats:txt html pdf xml json
Updates:RFC 3261
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8760
This document updates RFC 3261 by modifying the Digest AccessAuthentication scheme used by the Session Initiation Protocol (SIP) to add support for more secure digest algorithms, e.g., SHA-256 andSHA-512/256, to replace the obsolete MD5 algorithm.
 
RFC 8761 Video Codec Requirements and Evaluation Methodology
 
Authors:A. Filippov, A. Norkin, J.R. Alvarez.
Date:April 2020
Formats:txt pdf xml html json
Status:INFORMATIONAL
DOI:10.17487/RFC 8761
This document provides requirements for a video codec designed mainly for use over the Internet. In addition, this document describes an evaluation methodology for measuring the compression efficiency to determine whether or not the stated requirements have been fulfilled.
 
RFC 8762 Simple Two-Way Active Measurement Protocol
 
Authors:G. Mirsky, G. Jun, H. Nydell, R. Foote.
Date:March 2020
Formats:txt json html xml pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8762
This document describes the Simple Two-way Active MeasurementProtocol (STAMP), which enables the measurement of both one-way and round-trip performance metrics, like delay, delay variation, and packet loss.
 
RFC 8763 Deployment Considerations for Information-Centric Networking (ICN)
 
Authors:A. Rahman, D. Trossen, D. Kutscher, R. Ravindran.
Date:April 2020
Formats:txt json xml html pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 8763
Information-Centric Networking (ICN) is now reaching technological maturity after many years of fundamental research and experimentation. This document provides a number of deployment considerations in the interest of helping the ICN community move forward to the next step of live deployments. First, the major deployment configurations for ICN are described, including the key overlay and underlay approaches. Then, proposed deployment migration paths are outlined to address major practical issues, such as network and application migration. Next, selected ICN trial experiences are summarized. Finally, protocol areas that require further standardization are identified to facilitate future interoperable ICN deployments. This document is a product of the Information-CentricNetworking Research Group (ICNRG).
 
RFC 8767 Serving Stale Data to Improve DNS Resiliency
 
Authors:D. Lawrence, W. Kumari, P. Sood.
Date:March 2020
Formats:txt pdf xml json html
Updates:RFC 1034, RFC 1035, RFC 2181
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8767
This document defines a method (serve-stale) for recursive resolvers to use stale DNS data to avoid outages when authoritative nameservers cannot be reached to refresh expired data. One of the motivations for serve-stale is to make the DNS more resilient to DoS attacks and thereby make them less attractive as an attack vector. This document updates the definitions of TTL from RFCs 1034 and 1035 so that data can be kept in the cache beyond the TTL expiry; it also updates RFC2181 by interpreting values with the high-order bit set as being positive, rather than 0, and suggests a cap of 7 days.
 
RFC 8768 Constrained Application Protocol (CoAP) Hop-Limit Option
 
Authors:M. Boucadair, T. Reddy.K, J. Shallow.
Date:March 2020
Formats:txt pdf html xml json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8768
The presence of Constrained Application Protocol (CoAP) proxies may lead to infinite forwarding loops, which is undesirable. To prevent and detect such loops, this document specifies the Hop-Limit CoAP option.
 
RFC 8769 Cryptographic Message Syntax (CMS) Content Types for Concise Binary Object Representation (CBOR)
 
Authors:J. Schaad.
Date:March 2020
Formats:txt html pdf xml json
Status:INFORMATIONAL
DOI:10.17487/RFC 8769
Concise Binary Object Representation (CBOR) is becoming a widely used method of doing content encoding. The Cryptographic Message Syntax(CMS) is still a widely used method of doing message-based security.This document defines a set of content types for CMS that hold CBOR content.
 
RFC 8770 Host Router Support for OSPFv2
 
Authors:K. Patel, P. Pillay-Esnault, M. Bhardwaj, S. Bayraktar.
Date:April 2020
Formats:txt xml pdf html json
Updates:RFC 6987
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8770
The Open Shortest Path First Version 2 (OSPFv2) protocol does not have a mechanism for a node to repel transit traffic if it is on the shortest path. This document defines a bit called the Host-bit(H-bit). This bit enables a router to advertise that it is a non- transit router. This document also describes the changes needed to support the H-bit in the domain. In addition, this document updatesRFC 6987 to advertise Type 2 External and Not-So-Stubby Area (NSSA)Link State Advertisements (LSAs) (RFC 3101) with a high cost in order to repel traffic effectively.
 
RFC 8771 The Internationalized Deliberately Unreadable Network NOtation (I-DUNNO)
 
Authors:A. Mayrhofer, J. Hague.
Date:1 April 2020
Formats:txt html xml pdf json
Status:EXPERIMENTAL
DOI:10.17487/RFC 8771
Domain Names were designed for humans, IP addresses were not. But more than 30 years after the introduction of the DNS, a minority of mankind persists in invading the realm of machine-to-machine communication by reading, writing, misspelling, memorizing, permuting, and confusing IP addresses. This memo describes theInternationalized Deliberately Unreadable Network NOtation("I-DUNNO"), a notation designed to replace current textual representations of IP addresses with something that is not only more concise but will also discourage this small, but obviously important, subset of human activity.
 
RFC 8772 The China Mobile, Huawei, and ZTE Broadband Network Gateway (BNG) Simple Control and User Plane Separation Protocol (S-CUSP)
 
Authors:S. Hu, D. Eastlake, F. Qin, T. Chua, D. Huang.
Date:May 2020
Formats:txt json pdf xml html
Status:INFORMATIONAL
DOI:10.17487/RFC 8772
A Broadband Network Gateway (BNG) in a fixed wireline access network is an Ethernet-centric IP edge router and the aggregation point for subscriber traffic. Control and User Plane Separation (CUPS) for such a BNG improves flexibility and scalability but requires various communication between the User Plane (UP) and the Control Plane (CP).China Mobile, Huawei Technologies, and ZTE have developed a simpleCUPS control channel protocol to support such communication: theSimple Control and User Plane Separation Protocol (S-CUSP). S-CUSP is defined in this document.

This document is not an IETF standard and does not have IETF consensus. S-CUSP is presented here to make its specification conveniently available to the Internet community to enable diagnosis and interoperability.

 
RFC 8773 TLS 1.3 Extension for Certificate-Based Authentication with an External Pre-Shared Key
 
Authors:R. Housley.
Date:March 2020
Formats:txt json html pdf xml
Status:EXPERIMENTAL
DOI:10.17487/RFC 8773
This document specifies a TLS 1.3 extension that allows a server to authenticate with a combination of a certificate and an external pre- shared key (PSK).
 
RFC 8774 The Quantum Bug
 
Authors:M. Welzl.
Date:1 April 2020
Formats:txt html pdf json xml
Status:INFORMATIONAL
DOI:10.17487/RFC 8774
The age of quantum networking is upon us, and with it comes"entanglement": a procedure in which a state (i.e., a bit) can be transferred instantly, with no measurable delay between peers. This will lead to a perceived round-trip time of zero seconds on someInternet paths, a capability which was not predicted and so not included as a possibility in many protocol specifications. Worse than the millennium bug, this unexpected value is bound to cause serious Internet failures unless the specifications are fixed in time.
 
RFC 8775 PIM Designated Router Load Balancing
 
Authors:Y. Cai, H. Ou, S. Vallepalli, M. Mishra, S. Venaas, A. Green.
Date:April 2020
Formats:txt html json pdf xml
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8775
On a multi-access network, one of the PIM-SM (PIM Sparse Mode) routers is elected as a Designated Router. One of the responsibilities of the Designated Router is to track local multicast listeners and forward data to these listeners if the group is operating in PIM-SM. This document specifies a modification to thePIM-SM protocol that allows more than one of the PIM-SM routers to take on this responsibility so that the forwarding load can be distributed among multiple routers.
 
RFC 8777 DNS Reverse IP Automatic Multicast Tunneling (AMT) Discovery
 
Authors:J. Holland.
Date:April 2020
Formats:txt xml pdf json html
Updates:RFC 7450
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8777
This document updates RFC 7450, "Automatic Multicast Tunneling" (orAMT), by modifying the relay discovery process. A new DNS resource record named AMTRELAY is defined for publishing AMT relays for source-specific multicast channels. The reverse IP DNS zone for a multicast sender's IP address is configured to use AMTRELAY resource records to advertise a set of AMT relays that can receive and forward multicast traffic from that sender over an AMT tunnel. Other extensions and clarifications to the relay discovery process are also defined.
 
RFC 8778 Use of the HSS/LMS Hash-Based Signature Algorithm with CBOR Object Signing and Encryption (COSE)
 
Authors:R. Housley.
Date:April 2020
Formats:txt html xml pdf json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8778
This document specifies the conventions for using the HierarchicalSignature System (HSS) / Leighton-Micali Signature (LMS) hash-based signature algorithm with the CBOR Object Signing and Encryption(COSE) syntax. The HSS/LMS algorithm is one form of hash-based digital signature; it is described in RFC 8554.
 
RFC 8781 Discovering PREF64 in Router Advertisements
 
Authors:L. Colitti, J. Linkova.
Date:April 2020
Formats:txt html xml pdf json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8781
This document specifies a Neighbor Discovery option to be used inRouter Advertisements (RAs) to communicate prefixes of NetworkAddress and Protocol Translation from IPv6 clients to IPv4 servers(NAT64) to hosts.
 
RFC 8782 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification
 
Authors:T. Reddy.K, Ed., M. Boucadair, Ed., P. Patil, A. Mortensen, N. Teague.
Date:May 2020
Formats:txt pdf xml json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8782
This document specifies the Distributed Denial-of-Service Open ThreatSignaling (DOTS) signal channel, a protocol for signaling the need for protection against Distributed Denial-of-Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client.

A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration purposes.

 
RFC 8783 Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification
 
Authors:M. Boucadair, Ed., T. Reddy.K, Ed..
Date:May 2020
Formats:txt json pdf xml html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8783
The document specifies a Distributed Denial-of-Service Open ThreatSignaling (DOTS) data channel used for bulk exchange of data that cannot easily or appropriately communicated through the DOTS signal channel under attack conditions.

This is a companion document to "Distributed Denial-of-Service OpenThreat Signaling (DOTS) Signal Channel Specification" (RFC 8782).

 
RFC 8786 Updated Rules for Processing Stateful PCE Request Parameters Flags
 
Authors:A. Farrel.
Date:May 2020
Formats:txt json html xml pdf
Updates:RFC 8231
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8786
Extensions to the Path Computation Element Communication Protocol(PCEP) to support stateful Path Computation Elements (PCEs) are defined in RFC 8231. One of the extensions is the Stateful PCERequest Parameters (SRP) object. That object includes a Flags field that is a set of 32 bit flags, and RFC 8281 defines an IANA registry for tracking assigned flags. However, RFC 8231 does not explain how an implementation should set unassigned flags in transmitted messages, nor how an implementation should process unassigned, unknown, or unsupported flags in received messages.

This document updates RFC 8231 by defining the correct behaviors.

 
RFC 8787 Location Source Parameter for the SIP Geolocation Header Field
 
Authors:J. Winterbottom, R. Jesske, B. Chatras, A. Hutton.
Date:May 2020
Formats:txt json xml pdf html
Updates:RFC 6442
Status:PROPOSED STANDARD
DOI:10.17487/RFC 8787
There are some circumstances where a Geolocation header field may contain more than one locationValue. Knowing the identity of the node adding the locationValue allows the recipient more freedom in selecting the value to look at first rather than relying solely on the order of the locationValues. This document defines the "loc-src" parameter so that the entity adding the locationValue to theGeolocation header field can identify itself using its hostname.This document updates RFC 6442.