| |
| RFC 9900 | 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. |
|
| |
| RFC 9901 | Selective Disclosure for JSON Web Tokens |
| |
| Authors: | D. Fett, K. Yasuda, B. Campbell. |
| Date: | November 2025 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9901 |
|
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. |
|
| |
| RFC 9902 | A YANG Data Model for IS-IS Segment Routing over the MPLS Data Plane |
| |
| Authors: | S. Litkowski, Y. Qu, A. Lindem, I. Chen, J. Tantsura. |
| Date: | December 2025 |
| Formats: | txt json html xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9902 |
|
This document defines a YANG data model that can be used to manageIS-IS extensions for Segment Routing (SR) over the MPLS data plane. |
|
| |
| RFC 9903 | A YANG Data Model for OSPF Segment Routing over the MPLS Data Plane |
| |
| Authors: | Y. Qu, A. Lindem, J. Zhang, I. Chen. |
| Date: | December 2025 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9903 |
|
This document defines a YANG data model that can be used to manageOSPF extensions for Segment Routing over the MPLS data plane. |
|
| |
| RFC 9904 | 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.
This document does not change the recommendation status (MUST, MAY,RECOMMENDED, etc.) of the algorithms listed in RFC 8624; that is the work of future documents. |
|
| |
| RFC 9905 | Deprecating the Use of SHA-1 in DNSSEC Signature Algorithms |
| |
|
|
This document deprecates the use of the RSASHA1 andRSASHA1-NSEC3-SHA1 algorithms for the creation of DNS Public Key(DNSKEY) and Resource Record Signature (RRSIG) records.
It updates RFCs 4034 and 5155 as it deprecates the use of these algorithms. |
|
| |
| RFC 9906 | Deprecate Usage of ECC-GOST within DNSSEC |
| |
| Authors: | W. Hardaker, W. Kumari. |
| Date: | November 2025 |
| Formats: | txt pdf json xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9906 |
|
This document retires the use of GOST R 34.10-2001 (mnemonic "ECC-GOST") and GOST R 34.11-94 within DNSSEC.
RFC 5933 (Historic) defined the use of GOST R 34.10-2001 and GOST R34.11-94 algorithms with DNS Security Extensions (DNSSEC). This document updates RFC 5933 by deprecating the use of ECC-GOST. |
|
| |
| RFC 9908 | Clarification and Enhancement of the CSR Attributes Definition in RFC 7030 |
| |
|
|
This document updates RFC 7030, "Enrollment over Secure Transport"(EST), clarifying how the Certificate Signing Request (CSR)Attributes Response can be used by an EST server to specify both CSR attribute Object Identifiers (OIDs) and CSR attribute values, particularly X.509 extension values, that the server expects the client to include in a subsequent CSR request. RFC 9148 is derived from RFC 7030 and is also updated.
RFC 7030 is ambiguous in its specification of the CSR AttributesResponse. This has resulted in implementation challenges and implementor confusion because there was no universal understanding of what was specified. This document clarifies the encoding rules.
This document also provides a new straightforward approach: using a template for CSR contents that may be partially filled in by the server. This also allows an EST server to specify a subjectDistinguished Name (DN). |
|
| |
| RFC 9909 | Internet X.509 Public Key Infrastructure -- Algorithm Identifiers for the Stateless Hash-Based Digital Signature Algorithm (SLH-DSA) |
| |
| Authors: | K. Bashiri, S. Fluhrer, S. Gazdag, D. Van Geest, S. Kousidis. |
| Date: | December 2025 |
| Formats: | txt pdf html xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9909 |
|
Digital signatures are used within the X.509 Public KeyInfrastructure, such as X.509 certificates and Certificate RevocationLists (CRLs), as well as to sign messages. This document specifies the conventions for using the Stateless Hash-Based Digital SignatureAlgorithm (SLH-DSA) in the X.509 Public Key Infrastructure. The conventions for the associated signatures, subject public keys, and private keys are also specified. |
|
| |
| RFC 9910 | Registration Data Access Protocol (RDAP) Regional Internet Registry (RIR) Search |
| |
| Authors: | T. Harrison, J. Singh. |
| Date: | January 2026 |
| Formats: | txt xml pdf html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9910 |
|
The Registration Data Access Protocol (RDAP) is used by RegionalInternet Registries (RIRs) and Domain Name Registries (DNRs) to provide access to their resource registration information. The core specifications for RDAP define basic search functionality, but there are various search options related to IP addresses, IP prefixes, andAutonomous System Numbers (ASNs), which are provided by RIRs via their WHOIS services, but for which there is no corresponding RDAP functionality. This document extends RDAP to support those search options. |
|
| |
| RFC 9911 | 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. |
|
| |
| RFC 9915 | Dynamic Host Configuration Protocol for IPv6 (DHCPv6) |
| |
|
|
This document specifies the Dynamic Host Configuration Protocol forIPv6 (DHCPv6), an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes.Parameters can be provided statelessly or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC).
This document obsoletes RFC 8415. It incorporates verified errata and obsoletes the assignment of temporary addresses (the IA_TA option) and the server unicast capability (the Server Unicast option and UseMulticast status code). |
|
| |
| RFC 9917 | IGP Flexible Algorithms Reverse Affinity Constraint |
| |
|
|
An IGP Flexible Algorithm (Flex-Algorithm) enables the computation of constraint-based paths within an IGP domain, allowing operators to influence path selection according to administrative policies. This document defines an extension to Flex-Algorithm that allows the inclusion or exclusion of links from path computation based onAdministrative Groups (also known as link affinities) associated with the reverse direction of the path under computation.
This document updates RFCs 9350 and 9843 by introducing the new IANA registry that specifies the ordered set of rules that are used to prune links from the topology during the Flex-Algorithm path computation. |
|
| |
| RFC 9920 | RFC Editor Model (Version 3) |
| |
| Authors: | P. Hoffman, A. Rossi. |
| Date: | February 2026 |
| Formats: | txt html json pdf xml |
| Obsoletes: | RFC 9280 |
| Updates: | RFC 7841, RFC 7991, RFC 7992, RFC 7993, RFC 7994, RFC 7995, RFC 7996, RFC 7997, RFC 8729, RFC 8730, RFC 9720 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9920 |
|
This document specifies version 3 of the RFC Editor Model. The model defines two high-level tasks related to the RFC Series. First, policy definition is the joint responsibility of the RFC SeriesWorking Group (RSWG), which produces policy proposals, and the RFCSeries Approval Board (RSAB), which approves such proposals. Second, policy implementation is primarily the responsibility of the RFCProduction Center (RPC) as contractually overseen by the IETFAdministration Limited Liability Company (IETF LLC). In addition, various responsibilities of the RFC Editor function are now performed alone or in combination by the RSWG, RSAB, RPC, RFC Series ConsultingEditor (RSCE), and IETF LLC. Finally, this document specifies theEditorial Stream for publication of future policy definition documents produced through the processes defined herein.
Since the publication of RFC 9280, lessons have been learned about implementing this model. This document lists some of those lessons learned and updates RFC 9280 based on that experience. This document obsoletes RFC 9280.
This document updates RFCs 7841, 7991, 7992, 7993, 7994, 7995, 7996,7997, 8729, 8730, and 9720. |
|
| |
| RFC 9921 | CBOR Object Signing and Encryption (COSE) Header Parameter for Timestamp Tokens as Defined in RFC 3161 |
| |
| Authors: | H. Birkholz, T. Fossati, M. Riechert. |
| Date: | February 2026 |
| Formats: | txt html pdf json xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9921 |
|
This document defines two CBOR Object Signing and Encryption (COSE) header parameters for incorporating timestamping based on RFC 3161 into COSE message structures (COSE_Sign and COSE_Sign1). This enables the use of established timestamping infrastructure per RFC3161 in COSE-based protocols. |
|
| |
| RFC 9922 | A Common YANG Data Model for Scheduling |
| |
| Authors: | Q. Ma, Ed., Q. Wu, M. Boucadair, Ed., D. King. |
| Date: | March 2026 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9922 |
|
This document defines common types and groupings that are meant to be used for scheduling purposes, such as events, policies, services, or resources based on date and time. For the sake of better modularity, the YANG module includes a set of recurrence-related groupings with varying levels of representation (i.e., from basic to advanced) to accommodate a variety of requirements. It also defines groupings for validating requested schedules and reporting scheduling statuses. |
|
| |
| RFC 9923 | The FNV Non-Cryptographic Hash Algorithm |
| |
| Authors: | L. Noll, K. Vo, D. Eastlake 3rd, T. Hansen. |
| Date: | February 2026 |
| Formats: | txt xml pdf json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9923 |
|
FNV (Fowler/Noll/Vo) is a fast, non-cryptographic hash algorithm with good dispersion that has been widely used and is referenced in a number of standards documents. The purpose of this document is to make information on FNV and open-source code performing all specified sizes of FNV conveniently available to the Internet community. |
|
| |
| RFC 9924 | Advanced Professional Video |
| |
| Authors: | Y. Lim, M. Park, M. Budagavi, R. Joshi, K. Choi. |
| Date: | February 2026 |
| Formats: | txt xml html pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9924 |
|
This document describes the bitstream format of Advanced ProfessionalVideo (APV) and its decoding process. APV is a professional video codec providing visually lossless compression mainly for recording and post production. |
|
| |
| RFC 9925 | Unsigned X.509 Certificates |
| |
|
|
This document defines a placeholder X.509 signature algorithm that may be used in contexts where the consumer of the certificate is not expected to verify the signature. As part of this, it updates RFC5280. |
|
| |
| RFC 9926 | Prefix Registration for IPv6 Neighbor Discovery |
| |
|
|
This document updates IPv6 Neighbor Discovery (RFC 4861) and IPv6Subnet Neighbor Discovery (RFC 8505, RFC 8928) to enable a node that owns or is directly connected to a prefix to register that prefix to neighbor routers. The registration indicates that the registered prefix can be reached via the advertising node without a loop. The unicast prefix registration allows the node to request one or more neighbor routers to redistribute the prefix in another routing domain regardless of the routing protocol used in that domain. This document updates the Routing Protocol for Low-Power and LossyNetworks (RPL), as specified in RFCs 6550 and 9010, to enable a6LoWPAN Router (6LR) to inject the registered prefix in RPL. |
|
| |
| RFC 9927 | Fixing the C-Flag in the Extended Address Registration Option (EARO) |
| |
|
|
This document updates "Address-Protected Neighbor Discovery for Low-Power and Lossy Networks" (RFC 8928) by changing the position of theC-flag in the Extended Address Registration Option (EARO) and registering it with IANA. |
|
| |
| RFC 9929 | IGP Unreachable Prefix Announcement |
| |
| Authors: | P. Psenak, Ed., C. Filsfils, D. Voyer, S. Hegde, G. Mishra. |
| Date: | February 2026 |
| Formats: | txt html json pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9929 |
|
Summarization is often used in multi-area or multi-domain networks to improve network efficiency and scalability. With summarization in place, there is a need to signal loss of reachability to an individual prefix covered by the summary. This enables fast convergence by steering traffic, when applicable, away from the node which owns the prefix and is no longer reachable.
This document specifies protocol mechanisms in IS-IS and OSPF, together with two new flags, to advertise such prefix reachability loss.
The term "OSPF" in this document is used to refer to both OSPFv2 andOSPFv3. |
|
| |
| RFC 9930 | Tunnel Extensible Authentication Protocol (TEAP) Version 1 |
| |
|
|
This document defines the Tunnel Extensible Authentication Protocol(TEAP) version 1. TEAP is a tunnel-based EAP method that enables secure communication between a peer and a server by using theTransport Layer Security (TLS) protocol to establish a mutually authenticated tunnel. Within the tunnel, TLV objects are used to convey authentication-related data between the EAP peer and the EAP server. This document obsoletes RFC 7170 and updates RFC 9427 by moving all TEAP specifications from those documents to this one. |
|
| |
| RFC 9931 | Security Considerations for Optimistic Protocol Transitions in HTTP/1.1 |
| |
|
|
In HTTP/1.1, the client can request a change to a new protocol on the existing connection. This document discusses the security considerations that apply to data sent by the client before this request is confirmed and adds new requirements to RFCs 9112 and 9298 to avoid related security issues. |
|
| |
| RFC 9934 | Privacy-Enhanced Mail (PEM) File Format for Encrypted ClientHello (ECH) |
| |
|
|
Encrypted ClientHello (ECH) key pairs need to be configured into TLS servers, which can be built using different TLS libraries. This document specifies a standard file format for this purpose, similar to how RFC 7468 defines other Privacy-Enhanced Mail (PEM) file formats. |
|
| |
| RFC 9935 | Internet X.509 Public Key Infrastructure - Algorithm Identifiers for the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) |
| |
| Authors: | S. Turner, P. Kampanakis, J. Massimo, B. E. Westerbaan. |
| Date: | March 2026 |
| Formats: | txt pdf xml html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9935 |
|
The Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is a quantum-resistant Key Encapsulation Mechanism. This document specifies the conventions for using the ML-KEM in X.509 Public KeyInfrastructure. The conventions for the subject public keys and private keys are also specified. |
|
| |
| RFC 9936 | Use of ML-KEM in the Cryptographic Message Syntax (CMS) |
| |
| Authors: | J. Prat, M. Ounsworth, D. Van Geest. |
| Date: | March 2026 |
| Formats: | txt json xml html pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9936 |
|
Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is a quantum-resistant Key Encapsulation Mechanism (KEM). Three parameter sets for the ML-KEM algorithm are specified by the US NationalInstitute of Standards and Technology (NIST) in FIPS 203. In order of increasing security strength (and decreasing performance), these parameter sets are ML-KEM-512, ML-KEM-768, and ML-KEM-1024. This document specifies the conventions for using ML-KEM with theCryptographic Message Syntax (CMS) using the KEMRecipientInfo structure defined in "Using Key Encapsulation Mechanism (KEM)Algorithms in the Cryptographic Message Syntax (CMS)" (RFC 9629). |
|
| |
| RFC 9937 | Proportional Rate Reduction (PRR) |
| |
| Authors: | M. Mathis, N. Cardwell, Y. Cheng, N. Dukkipati. |
| Date: | December 2025 |
| Formats: | txt json html xml pdf |
| Obsoletes: | RFC 6937 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9937 |
|
This document specifies a Standards Track version of the ProportionalRate 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. |
|
| |
| RFC 9939 | PKCS #8: Private-Key Information Content Types |
| |
| Authors: | J. Mandel, R. Housley, S. Turner. |
| Date: | February 2026 |
| Formats: | txt html xml json pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9939 |
|
This document defines PKCS #8 content types for use withPrivateKeyInfo and EncryptedPrivateKeyInfo as specified in RFC 5958. |
|
