RFC Abstracts

RFC9740 - New IPFIX Information Elements for TCP Options and IPv6 Extension Headers
This document specifies new IP Flow Information Export (IPFIX) Information Elements (IEs) to solve issues with existing ipv6ExtensionHeaders and tcpOptions IPFIX IEs, especially the ability to export any observed IPv6 extension headers or TCP options.
RFC9739 - Protocol Independent Multicast Light (PIM Light)
This document specifies Protocol Independent Multicast Light (PIM Light) and the PIM Light Interface (PLI). A PLI does not need a PIM Hello message to accept PIM Join/Prune messages, and it can signal multicast states over networks that cannot support full PIM neighbor discovery, such as Bit Index Explicit Replication (BIER) networks that connect two or more PIM domains. This document outlines the PIM Light protocol and procedures to ensure loop-free multicast traffic between two or more PIM Light routers.
RFC9738 - IMAP MESSAGELIMIT Extension
The MESSAGELIMIT extension of the Internet Message Access Protocol (RFCs 3501 and 9051) allows servers to announce a limit on the number of messages that can be processed in a single FETCH, SEARCH, STORE, COPY, or MOVE command (or their UID variants), or in a single APPEND or UID EXPUNGE command. This helps servers to control resource usage when performing various IMAP operations. This helps clients to know the message limit enforced by the corresponding IMAP server and avoid issuing commands that would exceed such limit.
RFC9737 - Reporting Errors in NFSv4.2 via LAYOUTRETURN
The Parallel Network File System (pNFS) allows for a file's metadata and data to be on different servers (i.e., the metadata server (MDS) and the data server (DS)). When the MDS is restarted, the client can still modify the data file component. During the recovery phase of startup, the MDS and the DSs work together to recover state. If the client has not encountered errors with the data files, then the state can be recovered and the resilvering of the data files can be avoided. With any errors, there is no means by which the client can report errors to the MDS. As such, the MDS has to assume that a file needs resilvering. This document presents an extension to RFC 8435 to allow the client to update the metadata via LAYOUTRETURN and avoid the resilvering.
RFC9736 - The BGP Monitoring Protocol (BMP) Peer Up Message Namespace
RFC 7854, the BGP Monitoring Protocol (BMP), uses different message types for different purposes. Most of these are structured as Type, Length, Value (TLV). One message type, the Peer Up message, lacks a set of TLVs defined for its use, instead sharing a namespace with the Initiation message. Experience has shown that this namespace sharing was a mistake, as it hampers the extension of the protocol.
RFC9735 - Locator/ID Separation Protocol (LISP) Distinguished Name Encoding
This document defines how to use the Address Family Identifier (AFI) 17 "Distinguished Name" in the Locator/ID Separation Protocol (LISP). LISP introduces two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). Distinguished Names (DNs) can be used in either EID-Records or RLOC-Records in LISP control messages to convey additional information.
RFC9734 - X.509 Certificate Extended Key Usage (EKU) for Instant Messaging URIs
RFC 5280 specifies several extended key purpose identifiers (KeyPurposeIds) for X.509 certificates. This document defines an Instant Messaging (IM) identity KeyPurposeId for inclusion in the Extended Key Usage (EKU) extension of X.509 v3 public key certificates
RFC9733 - BRSKI with Alternative Enrollment (BRSKI-AE)
This document defines enhancements to the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol, known as BRSKI with Alternative Enrollment (BRSKI-AE). BRSKI-AE extends BRSKI to support certificate enrollment mechanisms instead of the originally specified use of Enrollment over Secure Transport (EST). It supports certificate enrollment protocols such as the Certificate Management Protocol (CMP) that use authenticated self-contained signed objects for certification messages, allowing for flexibility in network device onboarding scenarios. The enhancements address use cases where the existing enrollment mechanism may not be feasible or optimal, providing a framework for integrating suitable alternative enrollment protocols. This document also updates the BRSKI reference architecture to accommodate these alternative methods, ensuring secure and scalable deployment across a range of network environments.
RFC9732 - A Framework for NRP-Based Enhanced Virtual Private Networks
This document describes a framework for Enhanced Virtual Private Networks (VPNs) based on Network Resource Partitions (NRPs) in order to support the needs of applications with specific traffic performance requirements (e.g., low latency, bounded jitter). NRP-based enhanced VPNs leverage the VPN and Traffic Engineering (TE) technologies and add characteristics that specific services require beyond those provided by conventional VPNs. Typically, an NRP-based enhanced VPN will be used to underpin network slicing, but it could also be of use in its own right providing enhanced connectivity services between customer sites. This document also provides an overview of relevant technologies in different network layers and identifies some areas for potential new work.
RFC9731 - A YANG Data Model for Virtual Network (VN) Operations
A Virtual Network (VN) is a network provided by a service provider to a customer for the customer to use in any way it wants as though it were a physical network. This document provides a YANG data model generally applicable to any mode of VN operations. This includes VN operations as per the Abstraction and Control of TE Networks (ACTN) framework (RFC 8453).
RFC9730 - Interworking of GMPLS Control and Centralized Controller Systems
Generalized Multiprotocol Label Switching (GMPLS) control allows each network element (NE) to perform local resource discovery, routing, and signaling in a distributed manner.
RFC9729 - The Concealed HTTP Authentication Scheme
Most HTTP authentication schemes are probeable in the sense that it is possible for an unauthenticated client to probe whether an origin serves resources that require authentication. It is possible for an origin to hide the fact that it requires authentication by not generating Unauthorized status codes; however, that only works with non-cryptographic authentication schemes: cryptographic signatures require a fresh nonce to be signed. Prior to this document, there was no existing way for the origin to share such a nonce without exposing the fact that it serves resources that require authentication. This document defines a new non-probeable cryptographic authentication scheme.
RFC9728 - OAuth 2.0 Protected Resource Metadata
This specification defines a metadata format that an OAuth 2.0 client or authorization server can use to obtain the information needed to interact with an OAuth 2.0 protected resource.
RFC9727 - api-catalog: A Well-Known URI and Link Relation to Help Discovery of APIs
This document defines the "api-catalog" well-known URI and link relation. It is intended to facilitate automated discovery and usage of published Application Programming Interfaces (APIs). A request to the api-catalog resource will return a document providing information about, and links to, the Publisher's APIs.
RFC9726 - Operational Considerations for Use of DNS in Internet of Things (IoT) Devices
This document details considerations about how Internet of Things (IoT) devices use IP addresses and DNS names. These concerns become acute as network operators begin deploying Manufacturer Usage Descriptions (MUD), as specified in RFC 8520, to control device access.
RFC9725 - WebRTC-HTTP Ingestion Protocol (WHIP)
This document describes a simple HTTP-based protocol that will allow WebRTC-based ingestion of content into streaming services and/or Content Delivery Networks (CDNs).
RFC9724 - State of Affairs for Randomized and Changing Media Access Control (MAC) Addresses
Internet users are becoming more aware that their activity over the Internet leaves a vast digital footprint, that communications might not always be properly secured, and that their location and actions can be tracked. One of the main factors that eases tracking of Internet users is the wide use of long-lasting, and sometimes persistent, identifiers at various protocol layers. This document focuses on Media Access Control (MAC) addresses.
RFC9723 - BGP Colored Prefix Routing (CPR) for Services Based on Segment Routing over IPv6 (SRv6)
This document describes a mechanism to advertise IPv6 prefixes in BGP that are associated with Color Extended Communities to establish end-to-end intent-aware paths for Segment Routing over IPv6 (SRv6) services. Such IPv6 prefixes are called "Colored Prefixes", and this mechanism is called "Colored Prefix Routing" (CPR). In SRv6 networks, the Colored Prefixes are the SRv6 locators associated with different intents. SRv6 services (e.g., SRv6 VPN services) with a specific intent could be assigned with SRv6 Segment Identifiers (SIDs) under the corresponding SRv6 locators, which are advertised as Colored Prefixes.
RFC9722 - Fast Recovery for EVPN Designated Forwarder Election
The Ethernet Virtual Private Network (EVPN) solution in RFC 7432 provides Designated Forwarder (DF) election procedures for multihomed Ethernet Segments. These procedures have been enhanced further by applying the Highest Random Weight (HRW) algorithm for DF election to avoid unnecessary DF status changes upon a failure. This document improves these procedures by providing a fast DF election upon recovery of the failed link or node associated with the multihomed Ethernet Segment. This document updates RFC 8584 by optionally introducing delays between some of the events therein.
RFC9721 - Extended Mobility Procedures for Ethernet VPN Integrated Routing and Bridging (EVPN-IRB)
This document specifies extensions to the Ethernet VPN Integrated Routing and Bridging (EVPN-IRB) procedures specified in RFCs 7432 and 9135 to enhance the mobility mechanisms for networks based on EVPN-IRB. The proposed extensions improve the handling of host mobility and duplicate address detection in EVPN-IRB networks to cover a broader set of scenarios where a host's unicast IP address to Media Access Control (MAC) address bindings may change across moves. These enhancements address limitations in the existing EVPN-IRB mobility procedures by providing more efficient and scalable solutions. The extensions are backward compatible with existing EVPN-IRB implementations and aim to optimize network performance in scenarios involving frequent IP address mobility.
RFC9720 - RFC Formats and Versions
In order to improve the readability of RFCs while supporting their archivability, the definitive version of the RFC Series transitioned from plain-text ASCII to XML using the RFCXML vocabulary; different publication versions are rendered from that base document. This document describes how RFCs are published.
RFC9719 - YANG Data Model for Routing in Fat Trees (RIFT)
This document defines a YANG data model for the configuration and management of the Routing in Fat Trees (RIFT) Protocol. The model is based on YANG 1.1, which is defined in RFC 7950 and conforms to the Network Management Datastore Architecture (NMDA) as described in RFC 8342.
RFC9718 - DNSSEC Trust Anchor Publication for the Root Zone
The root zone of the global Domain Name System (DNS) is cryptographically signed using DNS Security Extensions (DNSSEC).
RFC9717 - A Routing Architecture for Satellite Networks
Satellite networks present some interesting challenges for packet networking. The entire topology is continually in motion, with links far less reliable than what is common in terrestrial networks. Some changes to link connectivity can be anticipated due to orbital dynamics.
RFC9716 - Mechanisms for MPLS Ping and Traceroute Procedures in Inter-Domain Segment Routing Networks
The Segment Routing (SR) architecture leverages source routing and can be directly applied to the use of an MPLS data plane. A Segment Routing over MPLS (SR-MPLS) network may consist of multiple IGP domains or multiple Autonomous Systems (ASes) under the control of the same organization. It is useful to have the Label Switched Path (LSP) ping and traceroute procedures when an SR end-to-end path traverses multiple ASes or IGP domains. This document outlines mechanisms to enable efficient LSP ping and traceroute procedures in inter-AS and inter-domain SR-MPLS networks. This is achieved through a straightforward extension to the Operations, Administration, and Maintenance (OAM) protocol, relying solely on data plane forwarding for handling echo replies on transit nodes.
RFC9715 - IP Fragmentation Avoidance in DNS over UDP
The widely deployed Extension Mechanisms for DNS (EDNS(0)) feature in the DNS enables a DNS receiver to indicate its received UDP message size capacity, which supports the sending of large UDP responses by a DNS server. Large DNS/UDP messages are more likely to be fragmented, and IP fragmentation has exposed weaknesses in application protocols. It is possible to avoid IP fragmentation in DNS by limiting the response size where possible and signaling the need to upgrade from UDP to TCP transport where necessary. This document describes techniques to avoid IP fragmentation in DNS.
RFC9714 - Encapsulation for MPLS Performance Measurement with the Alternate-Marking Method
This document defines the encapsulation for MPLS performance measurement with the Alternate-Marking Method, which performs flow-based packet loss, delay, and jitter measurements on MPLS traffic.
RFC9713 - Bundle Protocol Version 7 Administrative Record Types Registry
This document updates RFC 9171 to clarify that Bundle Protocol Version 7 agents are expected to use the IANA "Bundle Administrative Record Types" registry to identify and document administrative record types. This document also designates code points for Private and Experimental Use.
RFC9712 - IETF Meeting Venue Requirements Review
Following a review of the IETF meeting venue requirements, this document updates RFC 8718 ("IETF Plenary Meeting Venue Selection Process"), clarifies how the IETF Administration Support Activity (IASA) should interpret some elements of RFC 8718, and specifies a replacement exploratory meeting process, thereby updating RFC 8719 ("High-Level Guidance for the Meeting Policy of the IETF").
RFC9711 - The Entity Attestation Token (EAT)
An Entity Attestation Token (EAT) provides an attested claims set that describes the state and characteristics of an entity, a device such as a smartphone, an Internet of Things (IoT) device, network equipment, or such. This claims set is used by a relying party, server, or service to determine the type and degree of trust placed in the entity.
RFC9710 - Simple Fixes to the IP Flow Information Export (IPFIX) Entities IANA Registry
This document provides simple fixes to the IANA "IP Flow Information Export (IPFIX) Entities" registry. Specifically, this document provides updates to fix shortcomings in the description of some Information Elements (IEs), to ensure a consistent structure when citing an existing IANA registry, and to fix broken pointers, orphaned section references, etc. The updates are also meant to bring some consistency among the entries of the registry.
RFC9709 - Encryption Key Derivation in the Cryptographic Message Syntax (CMS) Using HKDF with SHA-256
This document specifies the derivation of the content-encryption key or the content-authenticated-encryption key in the Cryptographic Message Syntax (CMS) using the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) with SHA-256. The use of this mechanism provides protection against an attacker that manipulates the content-encryption algorithm identifier or the content-authenticated-encryption algorithm identifier.
RFC9708 - Use of the HSS/LMS Hash-Based Signature Algorithm in the Cryptographic Message Syntax (CMS)
This document specifies the conventions for using the Hierarchical Signature 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. This document obsoletes RFC 8708.
RFC9707 - Report from the IAB Workshop on Barriers to Internet Access of Services (BIAS)
The "Barriers to Internet Access of Services (BIAS)" workshop was convened by the Internet Architecture Board (IAB) from January 15-17, 2024 as a three-day online meeting. Based on the submitted position papers, the workshop covered three areas of interest: the role of Community Networks in Internet access of services, reports and comments on the observed digital divide, and measurements of censorship and censorship circumvention. This report summarizes the workshop's discussions and serves as a reference for reports on the current barriers to Internet access.
RFC9706 - TreeDN: Tree-Based Content Delivery Network (CDN) for Live Streaming to Mass Audiences
As Internet audience sizes for high-interest live events reach unprecedented levels and bitrates climb to support formats and applications such as 4K, 8K, and Augmented Reality (AR), live streaming can place a unique type of stress upon network resources. TreeDN is a tree-based Content Delivery Network (CDN) architecture designed to address the distinctive scaling challenges of live streaming to mass audiences. TreeDN enables operators to offer Replication-as-a-Service (RaaS) at a fraction of the cost of traditional, unicast-based CDNs -- in some cases, at no additional cost to the infrastructure. In addition to efficiently utilizing network resources to deliver existing multi-destination traffic, this architecture also enables new types of content and use cases that previously were not possible or economically viable using traditional CDN approaches. Finally, TreeDN is a decentralized architecture and a democratizing technology that makes content distribution more accessible to more people by dramatically reducing the costs of replication.
RFC9705 - Refresh-Interval Independent RSVP Fast Reroute Facility Protection
The RSVP-TE Fast Reroute (FRR) extensions specified in RFC 4090 define two local repair techniques to reroute Label Switched Path (LSP) traffic over pre-established backup tunnels. Facility backup method allows one or more LSPs traversing a connected link or node to be protected using a bypass tunnel. The many-to-one nature of local repair technique is attractive from a scalability point of view. This document enumerates facility backup procedures in RFC 4090 that rely on refresh timeout, hence, making facility backup method refresh-interval dependent. The RSVP-TE extensions defined in this document will enhance the facility backup protection mechanism by making the corresponding procedures refresh-interval independent, and hence, compatible with the Refresh-Interval Independent RSVP (RI-RSVP) capability specified in RFC 8370. Hence, this document updates RFC 4090 in order to support the RI-RSVP capability specified in RFC 8370.
RFC9704 - Establishing Local DNS Authority in Validated Split-Horizon Environments
When split-horizon DNS is deployed by a network, certain domain names can be resolved authoritatively by a network-provided DNS resolver. DNS clients that are not configured to use this resolver by default can use it for these specific domains only. This specification defines a mechanism for domain owners to inform DNS clients about local resolvers that are authorized to answer authoritatively for certain subdomains.
RFC9703 - Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) Egress Peer Engineering (EPE) Segment Identifiers (SIDs) with MPLS Data Plane
Egress Peer Engineering (EPE) is an application of Segment Routing (SR) that solves the problem of egress peer selection. The SR-based BGP-EPE solution allows a centralized controller, e.g., a Software-Defined Network (SDN) controller, to program any egress peer. The EPE solution requires the node or the SDN controller to program 1) the PeerNode Segment Identifier (SID) describing a session between two nodes, 2) the PeerAdj SID describing the link or links that are used by the sessions between peer nodes, and 3) the PeerSet SID describing any connected interface to any peer in the related group. This document provides new sub-TLVs for EPE-SIDs that are used in the Target FEC Stack TLV (Type 1) in MPLS Ping and Traceroute procedures.
RFC9702 - YANG Data Model for Maximum Segment Identifier (SID) Depth (MSD) Types and MPLS MSD
This document defines two YANG modules. The first module is the initial version of the IANA-maintained YANG module for Maximum Segment Identifier (SID) Depth (MSD) Types, which includes identities for both the MPLS data plane and Segment Routing over IPv6 (SRv6) data plane. The second module augments the IETF MPLS YANG data model to provide support for MPLS MSDs as defined in RFCs 8476 and 8491.
RFC9701 - JSON Web Token (JWT) Response for OAuth Token Introspection
This specification proposes an additional response secured by JSON Web Token (JWT) for OAuth 2.0 Token Introspection.
RFC9700 - Best Current Practice for OAuth 2.0 Security
This document describes best current security practice for OAuth 2.0. It updates and extends the threat model and security advice given in RFCs 6749, 6750, and 6819 to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0. Further, it deprecates some modes of operation that are deemed less secure or even insecure.
RFC9699 - Use Case for an Extended Reality Application on Edge Computing Infrastructure
This document explores the issues involved in the use of edge computing resources to operationalize a media use case that involves an Extended Reality (XR) application. In particular, this document discusses an XR application that can run on devices having different form factors (such as different physical sizes and shapes) and needs edge computing resources to mitigate the effect of problems such as the need to support interactive communication requiring low latency, limited battery power, and heat dissipation from those devices. This document also discusses the expected behavior of XR applications, which can be used to manage traffic, and the service requirements for XR applications to be able to run on the network. Network operators who are interested in providing edge computing resources to operationalize the requirements of such applications are the intended audience for this document.
RFC9698 - The JMAPACCESS Extension for IMAP
This document defines an IMAP extension to let clients know that the messages in this IMAP server are also available via the JSON Meta Application Protocol (JMAP), and how. It is intended for clients that want to migrate gradually to JMAP or use JMAP extensions within an IMAP client.
RFC9697 - Detecting RPKI Repository Delta Protocol (RRDP) Session Desynchronization
This document describes an approach for Resource Public Key Infrastructure (RPKI) Relying Parties to detect a particular form of RPKI Repository Delta Protocol (RRDP) session desynchronization and how to recover. This document updates RFC 8182.
RFC9696 - Routing in Fat Trees (RIFT) Applicability and Operational Considerations
This document discusses the properties, applicability, and operational considerations of Routing in Fat Trees (RIFT) in different network scenarios with the intention of providing a rough guide on how RIFT can be deployed to simplify routing operations in Clos topologies and their variations.
RFC9695 - The 'haptics' Top-Level Media Type
This memo registers and documents the 'haptics' top-level media type, under which subtypes for representation formats for haptics may be registered. This document also serves as a registration for a set of subtypes, which are representative of some existing subtypes already in use.
RFC9694 - Guidelines for the Definition of New Top-Level Media Types
This document defines best practices for defining new top-level media types. It also introduces a registry for top-level media types, and contains a short history of top-level media types. It updates RFC 6838.
RFC9693 - Benchmarking Methodology for Stateful NATxy Gateways
RFC 2544 defines a benchmarking methodology for network interconnect devices. RFC 5180 addresses IPv6 specificities, and it also provides a technology update but excludes IPv6 transition technologies. RFC 8219 addresses IPv6 transition technologies, including stateful NAT64. However, none of them discuss how to apply pseudorandom port numbers from RFC 4814 to any stateful NATxy (such as NAT44, NAT64, and NAT66) technologies. This document discusses why using pseudorandom port numbers with stateful NATxy gateways is a difficult problem. It recommends a solution that limits the port number ranges and uses two test phases (phase 1 and phase 2). This document shows how the classic performance measurement procedures (e.g., throughput, frame loss rate, latency, etc.) can be carried out. New performance metrics and measurement procedures are also defined for measuring the maximum connection establishment rate, connection tear-down rate, and connection tracking table capacity.
RFC9692 - RIFT: Routing in Fat Trees
This document defines a specialized, dynamic routing protocol for Clos, fat tree, and variants thereof. These topologies were initially used within crossbar interconnects and consequently router and switch backplanes, but their characteristics make them ideal for constructing IP fabrics as well. The protocol specified by this document is optimized towards the minimization of control plane state to support very large substrates as well as the minimization of configuration and operational complexity to allow for a simplified deployment of said topologies.
RFC9691 - A Profile for Resource Public Key Infrastructure (RPKI) Trust Anchor Keys (TAKs)
A Trust Anchor Locator (TAL) is used by Relying Parties (RPs) in the Resource Public Key Infrastructure (RPKI) to locate and validate a Trust Anchor (TA) Certification Authority (CA) certificate used in RPKI validation. This document defines an RPKI signed object for a Trust Anchor Key (TAK). A TAK object can be used by a TA to signal to RPs the location(s) of the accompanying CA certificate for the current public key, as well as the successor public key and the location(s) of its CA certificate. This object helps to support planned key rollovers without impacting RPKI validation.