RFC Abstracts

RFC8765 - DNS Push Notifications
The Domain Name System (DNS) was designed to return matching records efficiently for queries for data that are relatively static. When those records change frequently, DNS is still efficient at returning the updated results when polled, as long as the polling rate is not too high. But, there exists no mechanism for a client to be asynchronously notified when these changes occur. This document defines a mechanism for a client to be notified of such changes to DNS records, called DNS Push Notifications.
RFC8764 - Apple's DNS Long-Lived Queries Protocol
Apple's DNS Long-Lived Queries (LLQ) is a mechanism for extending the DNS protocol to support change notification, thus allowing clients to learn about changes to DNS data without polling the server. From 2005 onwards, LLQ was implemented in Apple products including Mac OS X, Bonjour for Windows, and AirPort wireless base stations. In 2020, the LLQ protocol was superseded by the IETF Standards Track RFC 8765, "DNS Push Notifications", which builds on experience gained with the LLQ protocol to create a superior replacement.
RFC8763 - Deployment Considerations for Information-Centric Networking (ICN)
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-Centric Networking Research Group (ICNRG).
RFC8762 - Simple Two-Way Active Measurement Protocol
This document describes the Simple Two-way Active Measurement Protocol (STAMP), which enables the measurement of both one-way and round-trip performance metrics, like delay, delay variation, and packet loss.
RFC8761 - Video Codec Requirements and Evaluation Methodology
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.
RFC8760 - The Session Initiation Protocol (SIP) Digest Access Authentication Scheme
This document updates RFC 3261 by modifying the Digest Access Authentication scheme used by the Session Initiation Protocol (SIP) to add support for more secure digest algorithms, e.g., SHA-256 and SHA-512/256, to replace the obsolete MD5 algorithm.
RFC8759 - RTP Payload for Timed Text Markup Language (TTML)
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.
RFC8758 - Deprecating RC4 in Secure Shell (SSH)
This document deprecates RC4 in Secure Shell (SSH). Therefore, this document formally moves RFC 4345 to Historic status.
RFC8757 - Dynamic Link Exchange Protocol (DLEP) Latency Range Extension
This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) to provide the range of latency that can be experienced on a link.
RFC8756 - Commercial National Security Algorithm (CNSA) Suite Profile of Certificate Management over CMS
This document specifies a profile of the Certificate Management over CMS (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.
RFC8755 - Using Commercial National Security Algorithm Suite Algorithms in Secure/Multipurpose Internet Mail Extensions
The United States Government has published the National Security Agency (NSA) Commercial National Security Algorithm (CNSA) Suite, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using the United States National Security Agency's CNSA Suite algorithms in Secure/Multipurpose Internet Mail Extensions (S/MIME) as specified in RFC 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.
RFC8754 - IPv6 Segment Routing Header (SRH)
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.
RFC8753 - Internationalized Domain Names for Applications (IDNA) Review for New Unicode Versions
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 with Unicode 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.
RFC8752 - Report from the IAB Workshop on Exploring Synergy between Content Aggregation and the Publisher Ecosystem (ESCAPE)
The Exploring Synergy between Content Aggregation and the Publisher Ecosystem (ESCAPE) Workshop was convened by the Internet Architecture Board (IAB) in July 2019. This report summarizes its significant points of discussion and identifies topics that may warrant further consideration.
RFC8751 - Hierarchical Stateful Path Computation Element (PCE)
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.
RFC8750 - Implicit Initialization Vector (IV) for Counter-Based Ciphers in Encapsulating Security Payload (ESP)
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 the IV 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 Sequence Number (SN) can be used instead to generate the nonce. This avoids sending the IV itself and saves 8 octets per packet in the case of AES-GCM, AES-CCM, and ChaCha20-Poly1305. This document describes how to do this.
RFC8749 - Moving DNSSEC Lookaside Validation (DLV) to Historic Status
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.
RFC8748 - Registry Fee Extension for the Extensible Provisioning Protocol (EPP)
Given the expansion of the DNS namespace and the proliferation of novel business models, it is desirable to provide a method for Extensible 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.
RFC8747 - Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)
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)" (RFC 7800) but using Concise Binary Object Representation (CBOR) and CWTs rather than JavaScript Object Notation (JSON) and JSON Web Tokens (JWTs).
RFC8746 - Concise Binary Object Representation (CBOR) Tags for Typed Arrays
The Concise Binary Object Representation (CBOR), as defined in RFC 7049, 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.
RFC8745 - Path Computation Element Communication Protocol (PCEP) Extensions for Associating Working and Protection Label Switched Paths (LSPs) with Stateful PCE
An active stateful Path Computation Element (PCE) is capable of computing as well as controlling via Path Computation Element Communication Protocol (PCEP) Multiprotocol Label Switching Traffic Engineering (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.
RFC8744 - Issues and Requirements for Server Name Identification (SNI) Encryption in TLS
This document describes the general problem of encrypting the Server Name Identification (SNI) TLS parameter. The proposed solutions hide a hidden service behind a fronting service, only disclosing the SNI of the fronting service to external observers. This document lists known attacks against SNI encryption, discusses the current "HTTP co-tenancy" solution, and presents requirements for future TLS-layer solutions.
RFC8743 - Multiple Access Management Services Multi-Access Management Services (MAMS)
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.
RFC8742 - Concise Binary Object Representation (CBOR) Sequences
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.
RFC8741 - Ability for a Stateful Path Computation Element (PCE) to Request and Obtain Control of a Label Switched Path (LSP)
A stateful Path Computation Element (PCE) retains information about the placement of Multiprotocol Label Switching (MPLS) Traffic Engineering 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 Path Computation Client (PCC) that has set up LSPs under local configuration may delegate control of those LSPs to a stateful PCE.
RFC8740 - Using TLS 1.3 with HTTP/2
This document updates RFC 7540 by forbidding TLS 1.3 post-handshake authentication, as an analog to the existing TLS 1.2 renegotiation restriction.
RFC8739 - Support for Short-Term, Automatically Renewed (STAR) Certificates in the Automated Certificate Management Environment (ACME)
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 Automated Certificate Management Environment (ACME) extension to enable the issuance of Short-Term, Automatically Renewed (STAR) X.509 certificates.
RFC8738 - Automated Certificate Management Environment (ACME) IP Identifier Validation Extension
This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for IP addresses.
RFC8737 - Automated Certificate Management Environment (ACME) TLS Application-Layer Protocol Negotiation (ALPN) Challenge Extension
This document specifies a new challenge for the Automated Certificate Management Environment (ACME) protocol that allows for domain control validation using TLS.
RFC8736 - PIM Message Type Space Extension and Reserved Bits
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.
RFC8735 - Scenarios and Simulation Results of PCE in a Native IP Network
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.
RFC8734 - Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS) Version 1.3
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 TLS 1.3.
RFC8733 - Path Computation Element Communication Protocol (PCEP) Extensions for MPLS-TE Label Switched Path (LSP) Auto-Bandwidth Adjustment with Stateful PCE
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 Label Switched Paths (LSPs) using PCEP.
RFC8732 - Generic Security Service Application Program Interface (GSS-API) Key Exchange with SHA-2
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 by Generic Security Service (GSS) key exchanges.
RFC8731 - Secure Shell (SSH) Key Exchange Method Using Curve25519 and Curve448
This document describes the specification for using Curve25519 and Curve448 key exchange methods in the Secure Shell (SSH) protocol.
RFC8730 - Independent Submission Editor Model
This document describes the function and responsibilities of the RFC Independent 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 Production Center and Publisher, and the RFC Series Editor (RSE). The ISE is appointed by the IAB, and also interacts with the IETF Administration Limited Liability Company (LLC).
RFC8729 - The RFC Series and RFC Editor
This document describes the framework for an RFC Series and an RFC Editor 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 RFC Series to continue to fulfill its mandate. This document obsoletes RFC 4844.
RFC8728 - RFC Editor Model (Version 2)
The RFC Editor model described in this document divides the responsibilities for the RFC Series into three functions: the RFC Series Editor, the RFC Production Center, and the RFC Publisher. Internet Architecture Board (IAB) oversight via the RFC Series Oversight Committee (RSOC) is described, as is the relationship between the IETF Administration Limited Liability Company and the RSOC. This document reflects the experience gained with "RFC Editor Model (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.0 Model.
RFC8727 - JSON Binding of the Incident Object Description Exchange Format
The Incident Object Description Exchange Format (IODEF) defined in RFC 7970 provides an information model and a corresponding XML data model for exchanging incident and indicator information. This document gives implementers and operators an alternative format to exchange the same information by defining an alternative data model implementation in JSON and its encoding in Concise Binary Object Representation (CBOR).
RFC8726 - How Requests for IANA Action Will Be Handled on the Independent Stream
The Internet Assigned Numbers Authority (IANA) maintains registries to track code points used by protocols such as those defined by the IETF and documented in RFCs developed on the IETF Stream.
RFC8725 - JSON Web Token Best Current Practices
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. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs.
RFC8724 - SCHC: Generic Framework for Static Context Header Compression and Fragmentation
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.
RFC8723 - Double Encryption Procedures for the Secure Real-Time Transport Protocol (SRTP)
In some conferencing scenarios, it is desirable for an intermediary to be able to manipulate some parameters in Real-time Transport Protocol (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 future SRTP transforms with different properties.
RFC8722 - Defining the Role and Function of IETF Protocol Parameter Registry Operators
Many Internet Engineering Task Force (IETF) protocols make use of commonly defined values that are passed in messages or packets. To ensure consistent interpretation of these values between independent implementations, there is a need to ensure that the values and associated semantic intent are uniquely defined. The IETF uses registry functions to record assigned protocol parameter values and their associated semantic intentions. For each IETF protocol parameter, it is current practice for the IETF to delegate the role of Protocol Parameter Registry Operator to a nominated entity. This document provides a description of, and the requirements for, these delegated functions. This document 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.
RFC8721 - Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents
Contributors grant intellectual property rights to the IETF. The IETF Trust holds and manages those rights on behalf of the IETF. The Trustees 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 and RFCs. 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 IETF Contributions. This document obsoletes RFC 5377 solely for the purpose of removing references to the IETF Administrative Oversight Committee (IAOC), which was part of the IETF Administrative Support Activity (IASA).
RFC8720 - Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries
This document provides principles for the operation of Internet Assigned Numbers Authority (IANA) registries.
RFC8719 - High-Level Guidance for the Meeting Policy of the IETF
This document describes a meeting location policy for the IETF and the various stakeholders required to realize this policy.
RFC8718 - IETF Plenary Meeting Venue Selection Process
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.
RFC8717 - IETF Administrative Support Activity 2.0: Consolidated Updates to IETF Administrative Terminology
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 the 2018 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.
RFC8716 - Update to the IETF Anti-Harassment Procedures for the Replacement of the IETF Administrative Oversight Committee (IAOC) with the IETF Administration LLC
The IETF Anti-Harassment Procedures are described in RFC 7776.