RFC Abstracts
RFC9937 - Proportional Rate Reduction (PRR)
This document specifies a Standards Track version of the Proportional Rate Reduction (PRR) algorithm that obsoletes the Experimental version described in RFC 6937. PRR regulates the amount of data sent by TCP or other transport protocols during fast recovery. PRR accurately regulates the actual flight size through recovery such that at the end of recovery it will be as close as possible to the slow start threshold (ssthresh), as determined by the congestion control algorithm.
RFC9911 - Common YANG Data Types
This document defines a collection of common data types to be used with the YANG data modeling language. It includes several new type definitions and obsoletes RFC 6991.
RFC9909 - Internet X.509 Public Key Infrastructure -- Algorithm Identifiers for the Stateless Hash-Based Digital Signature Algorithm (SLH-DSA)
Digital signatures are used within the X.509 Public Key Infrastructure, such as X.509 certificates and Certificate Revocation Lists (CRLs), as well as to sign messages. This document specifies the conventions for using the Stateless Hash-Based Digital Signature Algorithm (SLH-DSA) in the X.509 Public Key Infrastructure. The conventions for the associated signatures, subject public keys, and private keys are also specified.
RFC9906 - Deprecate Usage of ECC-GOST within DNSSEC
This document retires the use of GOST R 34.10-2001 (mnemonic "ECC-GOST") and GOST R 34.11-94 within DNSSEC.
RFC9905 - Deprecating the Use of SHA-1 in DNSSEC Signature Algorithms
This document deprecates the use of the RSASHA1 and RSASHA1-NSEC3-SHA1 algorithms for the creation of DNS Public Key (DNSKEY) and Resource Record Signature (RRSIG) records.
RFC9904 - DNSSEC Cryptographic Algorithm Recommendation Update Process
The DNSSEC protocol makes use of various cryptographic algorithms to provide authentication of DNS data and proof of nonexistence. To ensure interoperability between DNS resolvers and DNS authoritative servers, it is necessary to specify both a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support. This document replaces and obsoletes RFC 8624 and moves the canonical source of algorithm implementation requirements and usage guidance for DNSSEC from RFC 8624 to the IANA DNSSEC algorithm registries. This is done to allow the list of requirements to be more easily updated and referenced. Extensions to these registries can be made in future RFCs. This document also updates RFC 9157 and incorporates the revised IANA DNSSEC considerations from that RFC.
RFC9903 - A YANG Data Model for OSPF Segment Routing over the MPLS Data Plane
This document defines a YANG data model that can be used to manage OSPF extensions for Segment Routing over the MPLS data plane.
RFC9902 - A YANG Data Model for IS-IS Segment Routing over the MPLS Data Plane
This document defines a YANG data model that can be used to manage IS-IS extensions for Segment Routing (SR) over the MPLS data plane.
RFC9901 - Selective Disclosure for JSON Web Tokens
This specification defines a mechanism for the selective disclosure of individual elements of a JSON data structure used as the payload of a JSON Web Signature (JWS). The primary use case is the selective disclosure of JSON Web Token (JWT) claims.
RFC9900 - Updates to NETCONF Transport Port Numbers
This document releases IANA-assigned port numbers for services related to the Network Configuration Protocol (NETCONF) that have not been in use in production networks.
RFC9899 - Extensions to the YANG Data Model for Access Control Lists (ACLs)
RFC 8519 defines a YANG data model for Access Control Lists (ACLs). This document specifies a set of extensions that fix many of the limitations of the ACL model as initially defined in RFC 8519. Specifically, it introduces augmentations to the ACL base model to enhance its functionality and applicability.
RFC9898 - Neighbor Discovery Considerations in IPv6 Deployments
The Neighbor Discovery (ND) protocol is a critical component of the IPv6 architecture. The protocol uses multicast in many messages. It also assumes a security model where all nodes on a link are trusted. Such a design might be inefficient in some scenarios (e.g., use of multicast in wireless networks) or when nodes are not trustworthy (e.g., public access networks). These security and operational issues and the associated mitigation solutions are documented in more than twenty RFCs. There is a need to track these issues and solutions in a single document.
RFC9891 - Automated Certificate Management Environment (ACME) Delay-Tolerant Networking (DTN) Node ID Validation Extension
This document specifies an extension to the Automated Certificate Management Environment (ACME) protocol that allows an ACME server to validate the Delay-Tolerant Networking (DTN) Node ID for an ACME client. A DTN Node ID is an identifier used in the Bundle Protocol (BP) to name a "singleton endpoint": an endpoint that is registered on a single BP Node. The DTN Node ID is encoded both as a certificate Subject Alternative Name (SAN) identity of type otherName with an Other Name form of BundleEID and as an ACME Identifier type "bundleEID".
RFC9890 - An Update to YANG Module Names Registration
This document amends the IANA guidance on the uniqueness of YANG module and submodule names.
RFC9889 - A Realization of Network Slices for 5G Networks Using Current IP/MPLS Technologies
Network slicing is a feature that was introduced by the 3rd Generation Partnership Project (3GPP) in Mobile Networks. Realization of 5G slicing implies requirements for all mobile domains, including the Radio Access Network (RAN), Core Network (CN), and Transport Network (TN).
RFC9887 - Terminal Access Controller Access-Control System Plus (TACACS+) over TLS 1.3
This document specifies the use of Transport Layer Security (TLS) version 1.3 to secure the communication channel between a Terminal Access Controller Access-Control System Plus (TACACS+) client and server. TACACS+ is a protocol used for Authentication, Authorization, and Accounting (AAA) in networked environments. The original TACACS+ protocol does not mandate the use of encryption or secure transport. This specification defines a profile for using TLS 1.3 with TACACS+, including guidance on authentication, connection establishment, and operational considerations. The goal is to enhance the confidentiality, integrity, and authenticity of TACACS+ traffic, aligning the protocol with modern security best practices.
RFC9886 - DRIP Entity Tags (DETs) in the Domain Name System
This document defines the Domain Name System (DNS) functionality of a Drone Remote Identification Protocol (DRIP) Identity Management Entity (DIME). It is built around DRIP Entity Tags (DETs) to standardize a hierarchical registry structure and associated processes to facilitate trustable and scalable registration and lookup of information related to Unmanned Aircraft Systems (UAS). The registry system supports issuance, discovery, and verification of DETs, enabling secure identification and association of UAS and their operators. It also defines the interactions between different classes of registries (root, organizational, and individual) and their respective roles in maintaining the integrity of the registration data. This architecture enables decentralized, federated operation while supporting privacy, traceability, and regulatory compliance requirements in the context of UAS Remote Identification and other services.
RFC9885 - Multi-Part TLVs in IS-IS
New technologies are adding new information into IS-IS while deployment scales are simultaneously increasing. This causes the contents of many critical TLVs to exceed the currently supported limit of 255 octets. This document codifies the common mechanism of extending the TLV content space through multiple TLVs.
RFC9884 - Label Switched Path Ping for Segment Routing Path Segment Identifier with MPLS Data Plane
Segment Routing (SR) leverages source routing to steer packets through an ordered list of instructions called "segments". SR can be instantiated over the MPLS data plane. Path Segment Identifiers (PSIDs) are used to identify and correlate bidirectional or end-to-end paths in SR networks. This document defines procedures (i.e., six new Target Forwarding Equivalence Class (FEC) Stack sub-TLVs) for the use of LSP Ping to support connectivity verification and fault isolation for SR paths that include PSIDs. The mechanisms described enable the validation and tracing of SR paths with Path SIDs in MPLS networks, complementing existing SR-MPLS Operations, Administration, and Maintenance (OAM) capabilities.
RFC9883 - An Attribute for Statement of Possession of a Private Key
This document specifies an attribute for a statement of possession of a private key by a certificate subject. As part of X.509 certificate enrollment, a Certification Authority (CA) typically demands proof that the subject possesses the private key that corresponds to the to-be-certified public key. In some cases, a CA might accept a signed statement from the certificate subject. For example, when a certificate subject needs separate certificates for signature and key establishment, a statement that can be validated with the previously issued signature certificate for the same subject might be adequate for subsequent issuance of the key establishment certificate.
RFC9882 - Use of the ML-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS)
The Module-Lattice-Based Digital Signature Algorithm (ML-DSA), as defined by NIST in FIPS 204, is a post-quantum digital signature scheme that aims to be secure against an adversary in possession of a Cryptographically Relevant Quantum Computer (CRQC). This document specifies the conventions for using the ML-DSA signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier syntax is provided.
RFC9881 - Internet X.509 Public Key Infrastructure -- Algorithm Identifiers for the Module-Lattice-Based Digital Signature Algorithm (ML-DSA)
Digital signatures are used within X.509 certificates and Certificate Revocation Lists (CRLs), and to sign messages. This document specifies the conventions for using FIPS 204, the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in Internet X.509 certificates and CRLs. The conventions for the associated signatures, subject public keys, and private key are also described.
RFC9879 - Use of Password-Based Message Authentication Code 1 (PBMAC1) in PKCS #12 Syntax
This document specifies additions and amendments to RFCs 7292 and 8018. It also obsoletes the RFC 9579. It defines a way to use the Password-Based Message Authentication Code 1 (PBMAC1), defined in RFC 8018, inside the PKCS #12 syntax. The purpose of this specification is to permit the use of more modern Password-Based Key Derivation Functions (PBKDFs) and allow for regulatory compliance.
RFC9878 - Updates to Private Header (P-Header) Extension Usage in Session Initiation Protocol (SIP) Requests and Responses
The Third Generation Partnership Project (3GPP) has identified cases where different SIP private header extensions referred to as "P-" header fields, and defined in RFC 7315, need to be included in SIP requests and responses where they were not allowed according to RFC 7315. This document updates RFC 7315, in order to allow inclusion of the affected "P-" header fields in such requests and responses. This document obsoletes RFC 7976. The changes related to RFC 7976 involve the inclusion of the P-Visited-Network-ID header field in SIP responses.
RFC9877 - Registration Data Access Protocol (RDAP) Extension for Geofeed Data
This document defines a new Registration Data Access Protocol (RDAP) extension, "geofeed1", for indicating that an RDAP server hosts geofeed URLs for its IP network objects. It also defines a new media type and a new link relation type for the associated link objects included in responses.
RFC9876 - Updates to the IANA Registration Procedures for Constrained Application Protocol (CoAP) Content-Formats
This document updates RFC 7252 by modifying the registration procedures for the "CoAP Content-Formats" IANA registry, within the "Constrained RESTful Environments (CoRE) Parameters" registry group. This document also introduces a new column, "Media Type", to the registry. Furthermore, this document reserves Content-Format identifiers 64998 and 64999 for use in documentation.
RFC9875 - HTTP Cache Groups
This specification introduces a means of describing the relationships between stored responses in HTTP caches, grouping them by associating a stored response with one or more strings.
RFC9874 - Best Practices for Deletion of Domain and Host Objects in the Extensible Provisioning Protocol (EPP)
The Extensible Provisioning Protocol (EPP) includes commands for clients to delete domain and host objects, both of which are used to publish information in the Domain Name System (DNS). EPP also includes guidance for deletions that is intended to avoid DNS resolution disruptions and maintain data consistency. However, operational relationships between objects can make that guidance difficult to implement. Some EPP clients have developed operational practices to delete those objects that have unintended impacts on DNS resolution and security. This document describes best current practices and proposes new potential practices to delete domain and host objects that reduce the risk of DNS resolution failure and maintain client-server data consistency.
RFC9873 - Additional Email Address Extension for the Extensible Provisioning Protocol (EPP)
The Extensible Provisioning Protocol (EPP) does not inherently support internationalized email addresses because the specifications for these addresses did not exist when EPP was developed. This document describes a command-response extension that adds support for associating an additional email address with an EPP contact object. That additional email address can be either an internationalized email address or an ASCII-only address.
RFC9872 - Recommendations for Discovering IPv6 Prefix Used for IPv6 Address Synthesis
On networks providing IPv4-IPv6 translation (RFC 7915), hosts and other endpoints need to know the IPv6 prefix(es) used for translation (the NAT64 prefix (RFC 6052)). This document provides guidelines for NAT64 prefix discovery, specifically recommending obtaining the NAT64 prefix from the Router Advertisement option (RFC 8781) when available.
RFC9871 - BGP Color-Aware Routing (CAR)
This document describes a BGP-based routing solution to establish end-to-end intent-aware paths across a multi-domain transport network. The transport network can span multiple service provider and customer network domains. The BGP intent-aware paths can be used to steer traffic flows for service routes that need a specific intent. This solution is called BGP Color-Aware Routing (BGP CAR).
RFC9870 - Export of UDP Options Information in IP Flow Information Export (IPFIX)
This document specifies new IP Flow Information Export (IPFIX) Information Elements for UDP Options.
RFC9869 - Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) for UDP Options
This document specifies how a UDP Options sender implements Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) as a robust method for Path MTU Discovery (PMTUD). This method uses the UDP Options packetization layer. It allows an application to discover the largest size of datagram that can be sent across a network path. It also provides a way to allow the application to periodically verify the current Maximum Packet Size (MPS) supported by a path and to update this when required.
RFC9868 - Transport Options for UDP
Transport protocols are extended through the use of transport header options. This document updates RFC 768 (UDP) by indicating the location, syntax, and semantics for UDP transport layer options within the surplus area after the end of the UDP user data but before the end of the IP datagram.
RFC9867 - Mixing Preshared Keys in the IKE_INTERMEDIATE and CREATE_CHILD_SA Exchanges of the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-Quantum Security
An Internet Key Exchange Protocol Version 2 (IKEv2) extension defined in RFC 8784 allows IPsec traffic to be protected against someone storing VPN communications and decrypting them later, when (and if) a Cryptographically Relevant Quantum Computer (CRQC) is available. The protection is achieved by means of a Post-quantum Preshared Key (PPK) that is mixed into the session keys calculation. However, this protection does not cover an initial IKEv2 Security Association (SA), which might be unacceptable in some scenarios. This specification defines an alternative way to provide protection against quantum computers, which is similar to the solution defined in RFC 8784, but it also protects the initial IKEv2 SA.
RFC9866 - Root Node Failure Detector (RNFD): Fast Detection of Border Router Crashes in the Routing Protocol for Low-Power and Lossy Networks (RPL)
By and large, correct operation of a network running the Routing Protocol for Low-Power and Lossy Networks (RPL) requires border routers to be up. In many applications, it is beneficial for the nodes to detect a failure of a border router as soon as possible to trigger fallback actions. This document specifies the Root Node Failure Detector (RNFD), an extension to RPL that expedites detection of border router crashes by having nodes collaboratively monitor the status of a given border router. The extension introduces an additional state at each node, a new type of RPL Control Message Option for synchronizing this state among different nodes, and the coordination algorithm itself.
RFC9865 - Cursor-Based Pagination of System of Cross-domain Identity Management (SCIM) Resources
This document updates RFCs 7643 and 7644 by defining additional System for Cross-Domain Identity Management (SCIM) query parameters and result attributes to allow use of cursor-based pagination in SCIM service providers that are implemented with existing codebases, databases, or APIs where cursor-based pagination is already well established.
RFC9864 - Fully-Specified Algorithms for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE)
This specification refers to cryptographic algorithm identifiers that fully specify the cryptographic operations to be performed, including any curve, key derivation function (KDF), and hash functions, as being "fully specified". It refers to cryptographic algorithm identifiers that require additional information beyond the algorithm identifier to determine the cryptographic operations to be performed as being "polymorphic". This specification creates fully-specified algorithm identifiers for registered JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) polymorphic algorithm identifiers, enabling applications to use only fully-specified algorithm identifiers. It deprecates those polymorphic algorithm identifiers.
RFC9863 - Path Computation Element Protocol (PCEP) Extension for Color
Color is a 32-bit numerical (unsigned integer) attribute used to associate a Traffic Engineering (TE) tunnel or policy with an intent or objective. For example, a TE Tunnel constructed to deliver low latency services and whose path is optimized for delay can be tagged with a color that represents "low latency." This document specifies extensions to the Path Computation Element Protocol (PCEP) to carry the color attribute.
RFC9862 - Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing (SR) Policy Candidate Paths
A Segment Routing (SR) Policy is an ordered list of instructions called "segments" that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated. An SR Policy is made of one or more Candidate Paths.
RFC9861 - KangarooTwelve and TurboSHAKE
This document defines four eXtendable-Output Functions (XOFs), hash functions with output of arbitrary length, named TurboSHAKE128, TurboSHAKE256, KT128, and KT256.
RFC9860 - Multicast-Only Fast Reroute (MoFRR) Based on Topology Independent Loop-Free Alternate (TI-LFA) Fast Reroute
This document specifies the use of Topology Independent Loop-Free Alternate (TI-LFA) mechanisms with Multicast-only Fast Reroute (MoFRR) for Protocol Independent Multicast (PIM). The TI-LFA provides Fast Reroute (FRR) protection for unicast traffic in IP networks by precomputing backup paths that avoid potential failures. By integrating TI-LFA with MoFRR, this document extends the benefits of FRR mechanisms to multicast traffic, enabling enhanced resilience and minimized packet loss in multicast networks. The document outlines an optional approach to implement TI-LFA in conjunction with MoFRR for PIM, ensuring that multicast traffic is rapidly rerouted in the event of a failure.
RFC9859 - Generalized DNS Notifications
This document generalizes and extends the use of DNS NOTIFY (RFC 1996) beyond conventional zone transfer hints to allow other types of actions that were previously lacking a trigger mechanism to be triggered via the DNS. Notifications merely nudge the receiver to initiate a predefined action promptly (instead of on a schedule); they do not alter the action itself (including any security checks it might employ).
RFC9858 - Additional Parameter Sets for HSS/LMS Hash-Based Signatures
This document extends HSS/LMS (RFC 8554) by defining parameter sets that use alternative hash functions. These include hash functions that result in signatures with significantly smaller sizes than the signatures that use the RFC 8554 parameter sets and should have sufficient security.
RFC9857 - Advertisement of Segment Routing Policies Using BGP - Link State
This document describes a mechanism used to collect Segment Routing (SR) Policy information that is locally available in a node and advertise it into BGP - Link State (BGP-LS) updates. Such information can be used by external components for path computation, reoptimization, service placement, network visualization, etc.
RFC9856 - Multicast Source Redundancy in EVPNs
In Ethernet Virtual Private Networks (EVPNs), IP multicast traffic replication and delivery play a crucial role in enabling efficient and scalable Layer 2 and Layer 3 services. A common deployment scenario involves redundant multicast sources that ensure high availability and resiliency. However, the presence of redundant sources can lead to duplicate IP multicast traffic in the network, causing inefficiencies and increased overhead. This document specifies extensions to the EVPN multicast procedures that allow for the suppression of duplicate IP multicast traffic from redundant sources. The proposed mechanisms enhance the EVPN's capability to deliver multicast traffic efficiently while maintaining high availability. These extensions are applicable to various EVPN deployment scenarios and provide guidelines to ensure consistent and predictable behavior across diverse network topologies.
RFC9855 - Topology Independent Fast Reroute Using Segment Routing
This document presents Topology Independent Loop-Free Alternate (TI-LFA) Fast Reroute (FRR), which is aimed at providing protection of node and Adjacency segments within the Segment Routing (SR) framework. This FRR behavior builds on proven IP FRR concepts being LFAs, Remote LFAs (RLFAs), and Directed Loop-Free Alternates (DLFAs). It extends these concepts to provide guaranteed coverage in any two-connected networks using a link-state IGP. An important aspect of TI-LFA is the FRR path selection approach establishing protection over the expected post-convergence paths from the Point of Local Repair (PLR), reducing the operational need to control the tie-breaks among various FRR options.
RFC9854 - AODV-RPL: The Routing Protocol for Low-Power and Lossy Networks (RPL) Based on Ad Hoc On-Demand Distance Vector (AODV) Routing
Route discovery for symmetric and asymmetric Peer-to-Peer (P2P) traffic flows is a desirable feature in Low-Power and Lossy Networks (LLNs). For that purpose, this document specifies AODV-RPL -- the Routing Protocol for Low-Power and Lossy Networks (RPL) based on Ad hoc On-demand Distance Vector (AODV) routing. AODV-RPL is a reactive P2P route discovery mechanism for both hop-by-hop routes and source routing. Paired instances are used to construct directional paths for cases where there are asymmetric links between source and target nodes.
RFC9847 - IANA Registry Updates for TLS and DTLS
This document updates the changes to the TLS and DTLS IANA registries made in RFC 8447. It adds a new value, "D" for discouraged, to the "Recommended" column of the selected TLS registries and adds a "Comment" column to all active registries that do not already have a "Comment" column. Finally, it updates the registration request instructions.
RFC9845 - Challenges and Opportunities in Management for Green Networking
Reducing humankind's environmental footprint and making technology more environmentally sustainable are among the biggest challenges of our age. Networks play an important part in this challenge. On one hand, they enable applications that help to reduce this footprint. On the other hand, they significantly contribute to this footprint themselves. Therefore, methods to make networking technology itself "greener" and to manage and operate networks in ways that reduce their environmental footprint without impacting their utility need to be explored. This document outlines a corresponding set of opportunities, along with associated research challenges, for networking technology in general and management technology in particular to become greener, i.e., more sustainable, with reduced greenhouse gas emissions and less negative impact on the environment.
This document specifies a Standards Track version of the Proportional Rate Reduction (PRR) algorithm that obsoletes the Experimental version described in RFC 6937. PRR regulates the amount of data sent by TCP or other transport protocols during fast recovery. PRR accurately regulates the actual flight size through recovery such that at the end of recovery it will be as close as possible to the slow start threshold (ssthresh), as determined by the congestion control algorithm.
RFC9911 - Common YANG Data Types
This document defines a collection of common data types to be used with the YANG data modeling language. It includes several new type definitions and obsoletes RFC 6991.
RFC9909 - Internet X.509 Public Key Infrastructure -- Algorithm Identifiers for the Stateless Hash-Based Digital Signature Algorithm (SLH-DSA)
Digital signatures are used within the X.509 Public Key Infrastructure, such as X.509 certificates and Certificate Revocation Lists (CRLs), as well as to sign messages. This document specifies the conventions for using the Stateless Hash-Based Digital Signature Algorithm (SLH-DSA) in the X.509 Public Key Infrastructure. The conventions for the associated signatures, subject public keys, and private keys are also specified.
RFC9906 - Deprecate Usage of ECC-GOST within DNSSEC
This document retires the use of GOST R 34.10-2001 (mnemonic "ECC-GOST") and GOST R 34.11-94 within DNSSEC.
RFC9905 - Deprecating the Use of SHA-1 in DNSSEC Signature Algorithms
This document deprecates the use of the RSASHA1 and RSASHA1-NSEC3-SHA1 algorithms for the creation of DNS Public Key (DNSKEY) and Resource Record Signature (RRSIG) records.
RFC9904 - DNSSEC Cryptographic Algorithm Recommendation Update Process
The DNSSEC protocol makes use of various cryptographic algorithms to provide authentication of DNS data and proof of nonexistence. To ensure interoperability between DNS resolvers and DNS authoritative servers, it is necessary to specify both a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support. This document replaces and obsoletes RFC 8624 and moves the canonical source of algorithm implementation requirements and usage guidance for DNSSEC from RFC 8624 to the IANA DNSSEC algorithm registries. This is done to allow the list of requirements to be more easily updated and referenced. Extensions to these registries can be made in future RFCs. This document also updates RFC 9157 and incorporates the revised IANA DNSSEC considerations from that RFC.
RFC9903 - A YANG Data Model for OSPF Segment Routing over the MPLS Data Plane
This document defines a YANG data model that can be used to manage OSPF extensions for Segment Routing over the MPLS data plane.
RFC9902 - A YANG Data Model for IS-IS Segment Routing over the MPLS Data Plane
This document defines a YANG data model that can be used to manage IS-IS extensions for Segment Routing (SR) over the MPLS data plane.
RFC9901 - Selective Disclosure for JSON Web Tokens
This specification defines a mechanism for the selective disclosure of individual elements of a JSON data structure used as the payload of a JSON Web Signature (JWS). The primary use case is the selective disclosure of JSON Web Token (JWT) claims.
RFC9900 - Updates to NETCONF Transport Port Numbers
This document releases IANA-assigned port numbers for services related to the Network Configuration Protocol (NETCONF) that have not been in use in production networks.
RFC9899 - Extensions to the YANG Data Model for Access Control Lists (ACLs)
RFC 8519 defines a YANG data model for Access Control Lists (ACLs). This document specifies a set of extensions that fix many of the limitations of the ACL model as initially defined in RFC 8519. Specifically, it introduces augmentations to the ACL base model to enhance its functionality and applicability.
RFC9898 - Neighbor Discovery Considerations in IPv6 Deployments
The Neighbor Discovery (ND) protocol is a critical component of the IPv6 architecture. The protocol uses multicast in many messages. It also assumes a security model where all nodes on a link are trusted. Such a design might be inefficient in some scenarios (e.g., use of multicast in wireless networks) or when nodes are not trustworthy (e.g., public access networks). These security and operational issues and the associated mitigation solutions are documented in more than twenty RFCs. There is a need to track these issues and solutions in a single document.
RFC9891 - Automated Certificate Management Environment (ACME) Delay-Tolerant Networking (DTN) Node ID Validation Extension
This document specifies an extension to the Automated Certificate Management Environment (ACME) protocol that allows an ACME server to validate the Delay-Tolerant Networking (DTN) Node ID for an ACME client. A DTN Node ID is an identifier used in the Bundle Protocol (BP) to name a "singleton endpoint": an endpoint that is registered on a single BP Node. The DTN Node ID is encoded both as a certificate Subject Alternative Name (SAN) identity of type otherName with an Other Name form of BundleEID and as an ACME Identifier type "bundleEID".
RFC9890 - An Update to YANG Module Names Registration
This document amends the IANA guidance on the uniqueness of YANG module and submodule names.
RFC9889 - A Realization of Network Slices for 5G Networks Using Current IP/MPLS Technologies
Network slicing is a feature that was introduced by the 3rd Generation Partnership Project (3GPP) in Mobile Networks. Realization of 5G slicing implies requirements for all mobile domains, including the Radio Access Network (RAN), Core Network (CN), and Transport Network (TN).
RFC9887 - Terminal Access Controller Access-Control System Plus (TACACS+) over TLS 1.3
This document specifies the use of Transport Layer Security (TLS) version 1.3 to secure the communication channel between a Terminal Access Controller Access-Control System Plus (TACACS+) client and server. TACACS+ is a protocol used for Authentication, Authorization, and Accounting (AAA) in networked environments. The original TACACS+ protocol does not mandate the use of encryption or secure transport. This specification defines a profile for using TLS 1.3 with TACACS+, including guidance on authentication, connection establishment, and operational considerations. The goal is to enhance the confidentiality, integrity, and authenticity of TACACS+ traffic, aligning the protocol with modern security best practices.
RFC9886 - DRIP Entity Tags (DETs) in the Domain Name System
This document defines the Domain Name System (DNS) functionality of a Drone Remote Identification Protocol (DRIP) Identity Management Entity (DIME). It is built around DRIP Entity Tags (DETs) to standardize a hierarchical registry structure and associated processes to facilitate trustable and scalable registration and lookup of information related to Unmanned Aircraft Systems (UAS). The registry system supports issuance, discovery, and verification of DETs, enabling secure identification and association of UAS and their operators. It also defines the interactions between different classes of registries (root, organizational, and individual) and their respective roles in maintaining the integrity of the registration data. This architecture enables decentralized, federated operation while supporting privacy, traceability, and regulatory compliance requirements in the context of UAS Remote Identification and other services.
RFC9885 - Multi-Part TLVs in IS-IS
New technologies are adding new information into IS-IS while deployment scales are simultaneously increasing. This causes the contents of many critical TLVs to exceed the currently supported limit of 255 octets. This document codifies the common mechanism of extending the TLV content space through multiple TLVs.
RFC9884 - Label Switched Path Ping for Segment Routing Path Segment Identifier with MPLS Data Plane
Segment Routing (SR) leverages source routing to steer packets through an ordered list of instructions called "segments". SR can be instantiated over the MPLS data plane. Path Segment Identifiers (PSIDs) are used to identify and correlate bidirectional or end-to-end paths in SR networks. This document defines procedures (i.e., six new Target Forwarding Equivalence Class (FEC) Stack sub-TLVs) for the use of LSP Ping to support connectivity verification and fault isolation for SR paths that include PSIDs. The mechanisms described enable the validation and tracing of SR paths with Path SIDs in MPLS networks, complementing existing SR-MPLS Operations, Administration, and Maintenance (OAM) capabilities.
RFC9883 - An Attribute for Statement of Possession of a Private Key
This document specifies an attribute for a statement of possession of a private key by a certificate subject. As part of X.509 certificate enrollment, a Certification Authority (CA) typically demands proof that the subject possesses the private key that corresponds to the to-be-certified public key. In some cases, a CA might accept a signed statement from the certificate subject. For example, when a certificate subject needs separate certificates for signature and key establishment, a statement that can be validated with the previously issued signature certificate for the same subject might be adequate for subsequent issuance of the key establishment certificate.
RFC9882 - Use of the ML-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS)
The Module-Lattice-Based Digital Signature Algorithm (ML-DSA), as defined by NIST in FIPS 204, is a post-quantum digital signature scheme that aims to be secure against an adversary in possession of a Cryptographically Relevant Quantum Computer (CRQC). This document specifies the conventions for using the ML-DSA signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier syntax is provided.
RFC9881 - Internet X.509 Public Key Infrastructure -- Algorithm Identifiers for the Module-Lattice-Based Digital Signature Algorithm (ML-DSA)
Digital signatures are used within X.509 certificates and Certificate Revocation Lists (CRLs), and to sign messages. This document specifies the conventions for using FIPS 204, the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in Internet X.509 certificates and CRLs. The conventions for the associated signatures, subject public keys, and private key are also described.
RFC9879 - Use of Password-Based Message Authentication Code 1 (PBMAC1) in PKCS #12 Syntax
This document specifies additions and amendments to RFCs 7292 and 8018. It also obsoletes the RFC 9579. It defines a way to use the Password-Based Message Authentication Code 1 (PBMAC1), defined in RFC 8018, inside the PKCS #12 syntax. The purpose of this specification is to permit the use of more modern Password-Based Key Derivation Functions (PBKDFs) and allow for regulatory compliance.
RFC9878 - Updates to Private Header (P-Header) Extension Usage in Session Initiation Protocol (SIP) Requests and Responses
The Third Generation Partnership Project (3GPP) has identified cases where different SIP private header extensions referred to as "P-" header fields, and defined in RFC 7315, need to be included in SIP requests and responses where they were not allowed according to RFC 7315. This document updates RFC 7315, in order to allow inclusion of the affected "P-" header fields in such requests and responses. This document obsoletes RFC 7976. The changes related to RFC 7976 involve the inclusion of the P-Visited-Network-ID header field in SIP responses.
RFC9877 - Registration Data Access Protocol (RDAP) Extension for Geofeed Data
This document defines a new Registration Data Access Protocol (RDAP) extension, "geofeed1", for indicating that an RDAP server hosts geofeed URLs for its IP network objects. It also defines a new media type and a new link relation type for the associated link objects included in responses.
RFC9876 - Updates to the IANA Registration Procedures for Constrained Application Protocol (CoAP) Content-Formats
This document updates RFC 7252 by modifying the registration procedures for the "CoAP Content-Formats" IANA registry, within the "Constrained RESTful Environments (CoRE) Parameters" registry group. This document also introduces a new column, "Media Type", to the registry. Furthermore, this document reserves Content-Format identifiers 64998 and 64999 for use in documentation.
RFC9875 - HTTP Cache Groups
This specification introduces a means of describing the relationships between stored responses in HTTP caches, grouping them by associating a stored response with one or more strings.
RFC9874 - Best Practices for Deletion of Domain and Host Objects in the Extensible Provisioning Protocol (EPP)
The Extensible Provisioning Protocol (EPP) includes commands for clients to delete domain and host objects, both of which are used to publish information in the Domain Name System (DNS). EPP also includes guidance for deletions that is intended to avoid DNS resolution disruptions and maintain data consistency. However, operational relationships between objects can make that guidance difficult to implement. Some EPP clients have developed operational practices to delete those objects that have unintended impacts on DNS resolution and security. This document describes best current practices and proposes new potential practices to delete domain and host objects that reduce the risk of DNS resolution failure and maintain client-server data consistency.
RFC9873 - Additional Email Address Extension for the Extensible Provisioning Protocol (EPP)
The Extensible Provisioning Protocol (EPP) does not inherently support internationalized email addresses because the specifications for these addresses did not exist when EPP was developed. This document describes a command-response extension that adds support for associating an additional email address with an EPP contact object. That additional email address can be either an internationalized email address or an ASCII-only address.
RFC9872 - Recommendations for Discovering IPv6 Prefix Used for IPv6 Address Synthesis
On networks providing IPv4-IPv6 translation (RFC 7915), hosts and other endpoints need to know the IPv6 prefix(es) used for translation (the NAT64 prefix (RFC 6052)). This document provides guidelines for NAT64 prefix discovery, specifically recommending obtaining the NAT64 prefix from the Router Advertisement option (RFC 8781) when available.
RFC9871 - BGP Color-Aware Routing (CAR)
This document describes a BGP-based routing solution to establish end-to-end intent-aware paths across a multi-domain transport network. The transport network can span multiple service provider and customer network domains. The BGP intent-aware paths can be used to steer traffic flows for service routes that need a specific intent. This solution is called BGP Color-Aware Routing (BGP CAR).
RFC9870 - Export of UDP Options Information in IP Flow Information Export (IPFIX)
This document specifies new IP Flow Information Export (IPFIX) Information Elements for UDP Options.
RFC9869 - Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) for UDP Options
This document specifies how a UDP Options sender implements Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) as a robust method for Path MTU Discovery (PMTUD). This method uses the UDP Options packetization layer. It allows an application to discover the largest size of datagram that can be sent across a network path. It also provides a way to allow the application to periodically verify the current Maximum Packet Size (MPS) supported by a path and to update this when required.
RFC9868 - Transport Options for UDP
Transport protocols are extended through the use of transport header options. This document updates RFC 768 (UDP) by indicating the location, syntax, and semantics for UDP transport layer options within the surplus area after the end of the UDP user data but before the end of the IP datagram.
RFC9867 - Mixing Preshared Keys in the IKE_INTERMEDIATE and CREATE_CHILD_SA Exchanges of the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-Quantum Security
An Internet Key Exchange Protocol Version 2 (IKEv2) extension defined in RFC 8784 allows IPsec traffic to be protected against someone storing VPN communications and decrypting them later, when (and if) a Cryptographically Relevant Quantum Computer (CRQC) is available. The protection is achieved by means of a Post-quantum Preshared Key (PPK) that is mixed into the session keys calculation. However, this protection does not cover an initial IKEv2 Security Association (SA), which might be unacceptable in some scenarios. This specification defines an alternative way to provide protection against quantum computers, which is similar to the solution defined in RFC 8784, but it also protects the initial IKEv2 SA.
RFC9866 - Root Node Failure Detector (RNFD): Fast Detection of Border Router Crashes in the Routing Protocol for Low-Power and Lossy Networks (RPL)
By and large, correct operation of a network running the Routing Protocol for Low-Power and Lossy Networks (RPL) requires border routers to be up. In many applications, it is beneficial for the nodes to detect a failure of a border router as soon as possible to trigger fallback actions. This document specifies the Root Node Failure Detector (RNFD), an extension to RPL that expedites detection of border router crashes by having nodes collaboratively monitor the status of a given border router. The extension introduces an additional state at each node, a new type of RPL Control Message Option for synchronizing this state among different nodes, and the coordination algorithm itself.
RFC9865 - Cursor-Based Pagination of System of Cross-domain Identity Management (SCIM) Resources
This document updates RFCs 7643 and 7644 by defining additional System for Cross-Domain Identity Management (SCIM) query parameters and result attributes to allow use of cursor-based pagination in SCIM service providers that are implemented with existing codebases, databases, or APIs where cursor-based pagination is already well established.
RFC9864 - Fully-Specified Algorithms for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE)
This specification refers to cryptographic algorithm identifiers that fully specify the cryptographic operations to be performed, including any curve, key derivation function (KDF), and hash functions, as being "fully specified". It refers to cryptographic algorithm identifiers that require additional information beyond the algorithm identifier to determine the cryptographic operations to be performed as being "polymorphic". This specification creates fully-specified algorithm identifiers for registered JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) polymorphic algorithm identifiers, enabling applications to use only fully-specified algorithm identifiers. It deprecates those polymorphic algorithm identifiers.
RFC9863 - Path Computation Element Protocol (PCEP) Extension for Color
Color is a 32-bit numerical (unsigned integer) attribute used to associate a Traffic Engineering (TE) tunnel or policy with an intent or objective. For example, a TE Tunnel constructed to deliver low latency services and whose path is optimized for delay can be tagged with a color that represents "low latency." This document specifies extensions to the Path Computation Element Protocol (PCEP) to carry the color attribute.
RFC9862 - Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing (SR) Policy Candidate Paths
A Segment Routing (SR) Policy is an ordered list of instructions called "segments" that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated. An SR Policy is made of one or more Candidate Paths.
RFC9861 - KangarooTwelve and TurboSHAKE
This document defines four eXtendable-Output Functions (XOFs), hash functions with output of arbitrary length, named TurboSHAKE128, TurboSHAKE256, KT128, and KT256.
RFC9860 - Multicast-Only Fast Reroute (MoFRR) Based on Topology Independent Loop-Free Alternate (TI-LFA) Fast Reroute
This document specifies the use of Topology Independent Loop-Free Alternate (TI-LFA) mechanisms with Multicast-only Fast Reroute (MoFRR) for Protocol Independent Multicast (PIM). The TI-LFA provides Fast Reroute (FRR) protection for unicast traffic in IP networks by precomputing backup paths that avoid potential failures. By integrating TI-LFA with MoFRR, this document extends the benefits of FRR mechanisms to multicast traffic, enabling enhanced resilience and minimized packet loss in multicast networks. The document outlines an optional approach to implement TI-LFA in conjunction with MoFRR for PIM, ensuring that multicast traffic is rapidly rerouted in the event of a failure.
RFC9859 - Generalized DNS Notifications
This document generalizes and extends the use of DNS NOTIFY (RFC 1996) beyond conventional zone transfer hints to allow other types of actions that were previously lacking a trigger mechanism to be triggered via the DNS. Notifications merely nudge the receiver to initiate a predefined action promptly (instead of on a schedule); they do not alter the action itself (including any security checks it might employ).
RFC9858 - Additional Parameter Sets for HSS/LMS Hash-Based Signatures
This document extends HSS/LMS (RFC 8554) by defining parameter sets that use alternative hash functions. These include hash functions that result in signatures with significantly smaller sizes than the signatures that use the RFC 8554 parameter sets and should have sufficient security.
RFC9857 - Advertisement of Segment Routing Policies Using BGP - Link State
This document describes a mechanism used to collect Segment Routing (SR) Policy information that is locally available in a node and advertise it into BGP - Link State (BGP-LS) updates. Such information can be used by external components for path computation, reoptimization, service placement, network visualization, etc.
RFC9856 - Multicast Source Redundancy in EVPNs
In Ethernet Virtual Private Networks (EVPNs), IP multicast traffic replication and delivery play a crucial role in enabling efficient and scalable Layer 2 and Layer 3 services. A common deployment scenario involves redundant multicast sources that ensure high availability and resiliency. However, the presence of redundant sources can lead to duplicate IP multicast traffic in the network, causing inefficiencies and increased overhead. This document specifies extensions to the EVPN multicast procedures that allow for the suppression of duplicate IP multicast traffic from redundant sources. The proposed mechanisms enhance the EVPN's capability to deliver multicast traffic efficiently while maintaining high availability. These extensions are applicable to various EVPN deployment scenarios and provide guidelines to ensure consistent and predictable behavior across diverse network topologies.
RFC9855 - Topology Independent Fast Reroute Using Segment Routing
This document presents Topology Independent Loop-Free Alternate (TI-LFA) Fast Reroute (FRR), which is aimed at providing protection of node and Adjacency segments within the Segment Routing (SR) framework. This FRR behavior builds on proven IP FRR concepts being LFAs, Remote LFAs (RLFAs), and Directed Loop-Free Alternates (DLFAs). It extends these concepts to provide guaranteed coverage in any two-connected networks using a link-state IGP. An important aspect of TI-LFA is the FRR path selection approach establishing protection over the expected post-convergence paths from the Point of Local Repair (PLR), reducing the operational need to control the tie-breaks among various FRR options.
RFC9854 - AODV-RPL: The Routing Protocol for Low-Power and Lossy Networks (RPL) Based on Ad Hoc On-Demand Distance Vector (AODV) Routing
Route discovery for symmetric and asymmetric Peer-to-Peer (P2P) traffic flows is a desirable feature in Low-Power and Lossy Networks (LLNs). For that purpose, this document specifies AODV-RPL -- the Routing Protocol for Low-Power and Lossy Networks (RPL) based on Ad hoc On-demand Distance Vector (AODV) routing. AODV-RPL is a reactive P2P route discovery mechanism for both hop-by-hop routes and source routing. Paired instances are used to construct directional paths for cases where there are asymmetric links between source and target nodes.
RFC9847 - IANA Registry Updates for TLS and DTLS
This document updates the changes to the TLS and DTLS IANA registries made in RFC 8447. It adds a new value, "D" for discouraged, to the "Recommended" column of the selected TLS registries and adds a "Comment" column to all active registries that do not already have a "Comment" column. Finally, it updates the registration request instructions.
RFC9845 - Challenges and Opportunities in Management for Green Networking
Reducing humankind's environmental footprint and making technology more environmentally sustainable are among the biggest challenges of our age. Networks play an important part in this challenge. On one hand, they enable applications that help to reduce this footprint. On the other hand, they significantly contribute to this footprint themselves. Therefore, methods to make networking technology itself "greener" and to manage and operate networks in ways that reduce their environmental footprint without impacting their utility need to be explored. This document outlines a corresponding set of opportunities, along with associated research challenges, for networking technology in general and management technology in particular to become greener, i.e., more sustainable, with reduced greenhouse gas emissions and less negative impact on the environment.