| |
| RFC 10001 | Operational Guidelines for DNS Transport in Mixed IPv4/IPv6 Environments |
| |
|
|
This document provides guidelines and documents best current practice for operating authoritative DNS servers, recursive resolvers, and stub resolvers in a mixed IPv4/IPv6 environment. This document recommends that both authoritative DNS servers and recursive resolvers support IPv4 and IPv6. It also provides guidance on how recursive DNS resolvers should select upstream DNS servers, including when IPv4-embedded IPv6 addresses are available.This document obsoletes RFC 3901. |
|
| |
| RFC 10002 | Certificate Management over CMS (CMC) |
| |
|
|
This document defines the base syntax for CMC, a CertificateManagement protocol using the Cryptographic Message Syntax (CMS).This protocol addresses two immediate needs within the InternetPublic Key Infrastructure (PKI) community:
1. The need for an interface to public key certification products and services based on CMS and PKCS #10 (Public Key CryptographyStandard), and
2. The need for a PKI enrollment protocol for encryption-only keys due to algorithm or hardware design.
CMC also requires the use of the transport document (RFC 10003) and the requirements usage document (RFC 10004) along with this document for a full definition.
This document obsoletes RFCs 5272 and 6402. |
|
| |
| RFC 10003 | Certificate Management over CMS (CMC): Transport Protocols |
| |
|
|
This document defines a number of transport mechanisms that are used to move Certificate Management over CMS (CMC) messages. The transport mechanisms described in this document are HTTP, file, mail, and TCP.
This document obsoletes RFCs 5273 and 6402. |
|
| |
| RFC 10004 | Certificate Management over CMS (CMC): Compliance Requirements |
| |
|
|
This document provides a set of compliance statements about theCertificate Management over CMS (CMC) enrollment protocol. The ASN.1 structures and the transport mechanisms for the CMC enrollment protocol are covered in other documents (RFCs 10002 and 10003). This document provides the information needed to make a compliant version of CMC.
This document obsoletes RFCs 5274 and 6402. |
|
| |
| RFC 10005 | BGP Link Bandwidth Extended Community |
| |
| Authors: | P. Mohapatra, R. Das, Ed., S. Mohanty, Ed., S. Krier, R.J. Szarecki, A. Gattani. |
| Date: | June 2026 |
| Formats: | txt pdf html xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 10005 |
|
This document defines a BGP extended community, the Link BandwidthExtended Community, which carries bandwidth information to enable weighted load-balancing in multipath scenarios. It specifies the format and processing rules for this extended community type. |
|
| |
| RFC 10006 | Automatic SIP Trunking and Peering |
| |
| Authors: | K. Inamdar, S. Narayanan, C. Jennings. |
| Date: | August 2026 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 10006 |
|
This document specifies a framework that enables enterprise telephonySession Initiation Protocol (SIP) networks to solicit and obtain a capability set document from a SIP service provider. The capability set document encodes a set of characteristics that enable easy peering between enterprise and service provider SIP networks. |
|
| |
| RFC 10007 | Clarification to Processing Key Usage Values During Certificate Revocation List (CRL) Validation |
| |
|
|
RFC 5280 defines the profile of X.509 certificates and CertificateRevocation Lists (CRLs) for use in the Internet. Section 4.2.1.3 ofRFC 5280 requires CRL issuer certificates to contain the keyUsage extension with the cRLSign bit asserted. However, the CRL validation algorithm specified in Section 6.3 of RFC 5280 does not explicitly include a corresponding check for the presence of the keyUsage certificate extension. This document updates RFC 5280 to require that check. |
|
| |
| RFC 10008 | The HTTP QUERY Method |
| |
| Authors: | J. Reschke, J.M. Snell, M. Bishop. |
| Date: | June 2026 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 10008 |
|
This specification defines the QUERY method for HTTP. A QUERY requests that the request target process the enclosed content in a safe and idempotent manner and then respond with the result of that processing. This is similar to POST requests, but QUERY requests can be automatically repeated or restarted without concern for partial state changes. |
|
| |
| RFC 10013 | Entity Attestation Token (EAT) Measured Component |
| |
| Authors: | S. Frost, T. Fossati, H. Tschofenig, H. Birkholz. |
| Date: | July 2026 |
| Formats: | txt xml json pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 10013 |
|
The term "measured component" refers to an object within the attester's target environment whose state can be sampled and typically digested using a cryptographic hash function. Examples of measured components include firmware stored in flash memory, software loaded into memory at start time, data stored in a file system, or values in a CPU register. This document provides the information model for the measured component and two associated data models.This separation is intentional: The JSON and Concise Binary ObjectRepresentation (CBOR) serializations, coupled with the media types and associated Constrained Application Protocol (CoAP) Content-Formats, enable the immediate use of the semantics within the EntityAttestation Token (EAT) framework. Meanwhile, the information model can be reused in future specifications to provide additional serializations, for example, using ASN.1. |
|
| |
| RFC 10014 | Guidelines for Characterizing the Term "OAM" |
| |
| Authors: | C. Pignataro, A. Farrel, T. Mizrahi. |
| Date: | June 2026 |
| Formats: | txt html xml pdf json |
| Updates: | RFC 6291 |
| Also: | BCP161 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 10014 |
|
As the IETF continues to produce and standardize differentOperations, Administration, and Maintenance (OAM) protocols and technologies, various qualifiers and modifiers are prepended to theOAM abbreviation. While, at first glance, the most used qualifiers appear to be well understood, the same qualifier may be interpreted differently in different contexts. A case in point is the qualifiers"in-band" and "out-of-band", which have their origins in the radio lexicon, and which have been extrapolated into other communication networks. This document recommends not to use these two terms when referring to OAM.
This document considers some common qualifiers and modifiers that are prepended, within the context of packet networks, to the OAM abbreviation and lays out guidelines for their use in IETF documents.
This document extends RFC 6291 by adding to the guidelines for the use of the term "OAM" with qualifiers. It does not modify any part of RFC 6291. |
|
| |
| RFC 10015 | Deprecating Obsolete Key Exchange Methods in TLS 1.2 and DTLS 1.2 |
| |
| Authors: | N. Aviram. |
| Date: | July 2026 |
| Formats: | txt xml pdf html json |
| Updates: | RFC 4162, RFC 4279, RFC 4346, RFC 4785, RFC 5246, RFC 5288, RFC 5289, RFC 5469, RFC 5487, RFC 5932, RFC 6209, RFC 6347, RFC 6367, RFC 6655, RFC 7905, RFC 8422, RFC 9325 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 10015 |
|
For (D)TLS 1.2, this document deprecates the use of two key exchanges, namely Diffie-Hellman (DH) over a finite field and RSA.It also discourages the use of static Elliptic Curve Diffie-Hellman(ECDH) cipher suites.
These prescriptions apply only to (D)TLS 1.2, since (D)TLS 1.0 andTLS 1.1 are deprecated by RFC 8996 and (D)TLS 1.3 either does not use the affected algorithms or does not share the relevant configuration options. (There is no DTLS version 1.1.)
This document updates RFCs 4162, 4279, 4346, 4785, 5246, 5288, 5289,5469, 5487, 5932, 6209, 6347, 6367, 6655, 7905, 8422, and 9325 to either deprecate or discourage the use of cipher suites using the above key exchange methods in (D)TLS 1.2 connections. |
|
| |
| RFC 10016 | System-Defined Configuration |
| |
|
|
The Network Management Datastore Architecture (NMDA) in RFC 8342 defines several configuration datastores holding configuration. The contents of these configuration datastores are controlled by clients.This document introduces the concept of a system configuration datastore holding configuration controlled by the system on which a server is running. The system configuration can be referenced (e.g., leafref) by configuration explicitly created by clients.
This document updates RFC 8342. |
|
| |
| RFC 10017 | OAuth 2.0 for Browser-Based Applications |
| |
| Authors: | A. Parecki, P. De Ryck, D. Waite. |
| Date: | August 2026 |
| Formats: | txt json html pdf xml |
| Also: | BCP212 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 10017 |
|
This specification details the threats, attack consequences, security considerations, and best practices that must be taken into account when developing browser-based applications that use OAuth 2.0. |
|
| |
| RFC 10018 | Multicast and Ethernet VPN with Segment Routing Point-to-Multipoint (P2MP) and Ingress Replication |
| |
|
|
A Point-to-Multipoint (P2MP) tree in a Segment Routing (SR) domain carries traffic from a Root to a set of Leaves. This document specifies extensions to BGP encodings and procedures for P2MP trees and Ingress Replication used in BGP/MPLS IP VPNs and Ethernet VPNs(EVPNs) in an SR domain. This document updates RFCs 6514 and 7988. |
|
| |
| RFC 10019 | Zeroconf Multicast Address Allocation Problem Statement and Requirements |
| |
| Authors: | N. Karstens, D. Farinacci, M. McBride. |
| Date: | July 2026 |
| Formats: | txt html pdf json xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 10019 |
|
This document surveys current problems with existing protocols for automatically assigning multicast IP addresses in zero-configuration(zeroconf) networking environments. It addresses key challenges, such as link-layer address collisions, hardware limitations, multicast snooping inefficiencies, and the need to avoid manual configuration. Based on these challenges, it derives requirements for a lightweight, decentralized solution for dynamically allocating unique multicast group addresses without central coordination.
The document presents explicit requirements covering discovery, allocation, conflict detection and resolution, and lease management.It also evaluates considerations specific to IPv6 and IPv4 multicast address ranges, and identifies approaches that are unsuited for zeroconf deployment. This foundation serves as a reference for developing future solutions for multicast address allocation that operate autonomously within local networks. |
|
| |
| RFC 10022 | IMAP UIDBATCHES Extension |
| |
|
|
The UIDBATCHES extension of the Internet Message Access Protocol(IMAP) allows clients to retrieve Unique Identifier (UID) ranges that partition a mailbox's messages into equally sized batches. This enables clients to perform operations such as FETCH, SEARCH, andSTORE on specific message batches, providing better control over resource usage and response sizes. The extension is particularly useful with the UIDONLY mode where sequence numbers are unavailable. |
|
| |
| RFC 10023 | The "_for-sale" Underscored and Globally Scoped DNS Node Name |
| |
|
|
This document defines an operational convention that uses the reserved underscored DNS leaf node name "_for-sale" to indicate the parent domain name is available for purchase.
The convention can be deployed without disrupting existing operations, and it may be applied even when the domain name is still actively in use. |
|
| |
| RFC 10024 | Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3 |
| |
| Authors: | K. Kwiatkowski, P. Kampanakis, B. E. Westerbaan, D. Stebila. |
| Date: | August 2026 |
| Formats: | txt html json pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 10024 |
|
This document defines three hybrid key agreement mechanisms for TLS1.3 -- X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 -- that combine the post-quantum ML-KEM (Module-Lattice-Based KeyEncapsulation Mechanism) with an ECDHE (Ephemeral Elliptic CurveDiffie-Hellman) exchange. |
|
| |
| RFC 10026 | Operational Recommendations for DNSSEC Delegation Signer (DS) Automation |
| |
| Authors: | S. Sheng, P. Thomassen. |
| Date: | July 2026 |
| Formats: | txt xml json pdf html |
| Also: | BCP246 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 10026 |
|
Enabling support for automatic acceptance of DNSSEC Delegation Signer(DS) parameters from the Child DNS operator (via RFCs 7344, 8078, and9615) requires the Parental Agent, often a registry or registrar, to make a number of technical decisions around acceptance checks, error and success reporting, and multi-party issues such as concurrent updates. This document describes recommendations about how these points are best addressed in practice. |
|
| |
| RFC 10027 | Best Current Practice for Security of Cross-Device Flows |
| |
| Authors: | P. Kasselman, D. Fett, F. Skokan. |
| Date: | August 2026 |
| Formats: | txt xml pdf json html |
| Also: | BCP247 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 10027 |
|
This document describes threats against cross-device flows along with practical mitigations, protocol selection guidance, and a summary of formal analysis results identified as relevant to the security of cross-device flows. It serves as a security guide to system designers, architects, product managers, security specialists, fraud analysts, and engineers implementing cross-device flows. |
|
| |
| RFC 10028 | Updates to Dynamic IPv6 Multicast Address Group IDs |
| |
|
|
This document describes limitations of the existing range of dynamicIPv6 multicast addresses specified in "Allocation Guidelines for IPv6Multicast Addresses" (RFC 3307). It updates RFC 3307 by replacing these allocations with a new IANA registry in the "IPv6 MulticastAddress Space" registry group. The document also defines initial contents of the new registry: a reduced allocation for the MulticastAddress Dynamic Client Allocation Protocol (MADCAP) (RFC 2730), a range for Source-Specific Multicast (SSM), a Private Use range, a range for Experimental Use, and Solicited-Node multicast addresses(which were not previously noted in RFC 3307). |
|
| |
| RFC 10029 | DNS Multiple QTYPEs |
| |
|
|
This document specifies a method for a DNS client to request additional DNS record types to be delivered alongside the primary record type specified in the Question section of a DNS QUERY(OpCode=0). |
|
| |
| RFC 10030 | Network Time Protocol (NTP) over the Precision Time Protocol (PTP) |
| |
|
|
This document specifies a transport for the client-server and symmetric modes of the Network Time Protocol (NTP) that encapsulatesNTP messages in messages of the Precision Time Protocol (PTP). This transport enables hardware timestamping in network interface controllers (NICs) that can timestamp only PTP messages and delay corrections in PTP transparent clocks. |
|
| |
| RFC 10031 | Media Access Control (MAC) Addresses in X.509 Certificates |
| |
| Authors: | R. Housley, C. Bonnell, J. Mandel, T. Okubo, M. StJohns. |
| Date: | August 2026 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 10031 |
|
This document defines a new GeneralName.otherName for inclusion in the X.509 Subject Alternative Name (SAN) and Issuer Alternative Name(IAN) extensions to carry an IEEE Media Access Control (MAC) address.The new name form makes it possible to bind a Layer 2 interface identifier to a public key certificate. Additionally, this document defines how constraints on this name form can be encoded and processed in the X.509 Name Constraints extension (NCE). |
|
| |
| RFC 10033 | Hash-Based Signatures: State and Backup Management |
| |
| Authors: | T. Wiggers, K. Bashiri, S. Kölbl, J. Goodman, S. Kousidis. |
| Date: | September 2026 |
| Formats: | txt json xml pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 10033 |
|
Stateful Hash-Based Signature Schemes (Stateful HBS) such asLeighton-Micali Signature (LMS), Hierarchical Signature System (HSS), eXtended Merkle Signature Scheme (XMSS), and XMSS^MT combine Merkle trees with One-Time Signatures (OTSs) to provide signatures that are resistant against attacks using large-scale quantum computers.Unlike conventional stateless digital signature schemes, Stateful HBS have a state to keep track of which OTS keys have been used, as double-signing with the same OTS key allows forgeries.
This document provides guidance and catalogs security considerations for the operational and technical aspects of deploying systems that rely on Stateful HBS. Management of the state of the Stateful HBS, including any handling of redundant key material, is a sensitive topic. This document describes some approaches to handle the associated challenges. It also describes the challenges that need to be resolved before certain approaches should be considered. |
|
| |
| RFC 10034 | RTP Payload Format for Visual Volumetric Video-Based Coding (V3C) |
| |
|
|
A visual volumetric video-based coding (V3C) ISO/IEC 23090-5 bitstream is composed of V3C units that contain V3C atlas sub- bitstreams, V3C video sub-bitstreams, and a V3C parameter set. This document describes an RTP payload format for V3C atlas sub- bitstreams. The RTP payload format for V3C video sub-bitstreams is defined by relevant IETF RFCs for the applicable video codec. TheV3C RTP payload format allows for the packetization of one or moreV3C atlas Network Abstraction Layer (NAL) units in an RTP packet payload as well as the fragmentation of a V3C atlas NAL unit into multiple RTP packets. The document also describes the mechanisms for grouping RTP streams of V3C component sub-bitstreams, providing a complete solution for streaming V3C-encoded content. |
|
| |
| RFC 10035 | YANG Library: Addition of the augmented-by List |
| |
|
|
"YANG Library" (RFC 8525) specifies the "ietf-yang-library" YANG module that provides information about the YANG modules, datastores, and datastore schemas used by a network management server.
This document augments the "ietf-yang-library" module to provide the augmented-by list. It facilitates the process of obtaining all dependencies between YANG modules by querying the network management server's YANG library. This document updates RFC 8525 to also include the augmented-by list. |
|
| |
| RFC 10036 | Incremental Forwarding of HTTP Messages |
| |
| Authors: | K. Oku, T. Pauly, M. Thomson. |
| Date: | August 2026 |
| Formats: | txt pdf xml json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 10036 |
|
This document specifies the "Incremental" HTTP header field, which instructs HTTP intermediaries to forward the HTTP message incrementally. |
|
| |
| RFC 10037 | Registration Data Access Protocol (RDAP) Extension for DNS Time-to- Live (TTL) Values |
| |
|
|
This document specifies an extension to the Registration Data AccessProtocol (RDAP), which allows the Time-to-Live (TTL) values for relevant DNS record types to be included in RDAP responses. |
|
| |
| RFC 10038 | Distributing the Segment Routing over IPv6 (SRv6) Locator Using DHCPv6 |
| |
| Authors: | W. Cheng, Ed., R. Han, C. Lin, Ed., D. Voyer, G. Zhang. |
| Date: | August 2026 |
| Formats: | txt pdf xml html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 10038 |
|
In an SRv6 network, each SRv6 Segment Endpoint Node must be assigned an SRv6 Locator, and segment identifiers (SIDs) are generated within the address space of this SRv6 Locator. This document describes a method for assigning SRv6 Locators to SRv6 Segment Endpoint Nodes through the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). |
|
| |
| RFC 10039 | Interconnecting EVPN and IPVPN Domains |
| |
| Authors: | J. Rabadan, Ed., A. Sajassi, Ed., J. Drake, W. Lin, J. Uttaro, A. Simpson. |
| Date: | September 2026 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 10039 |
|
Ethernet Virtual Private Network (EVPN) provides a unified BGP control plane for both intra- and inter-subnet forwarding within tenant networks. When a tenant network spans multiple domains, including any combination of EVPN and IPVPN domains, it becomes necessary to define the interworking mechanisms among these BGP domains (EVPN and IPVPN) to ensure seamless end-to-end tenant connectivity. This document defines these interworking procedures.
In addition, this document defines a new BGP Path Attribute, referred to as Domain Path (D-PATH), which provides loop prevention for gateway nodes by protecting against control plane loops. The introduction of D-PATH modifies the BGP best-path selection process for Multiprotocol BGP inter-subnet forwarding (ISF) routes ofSubsequent Address Family Identifiers (SAFIs) 128 (IPVPN) and 70(EVPN). |
|
| |
| RFC 10040 | Locator/ID Separation Protocol (LISP) Geo-Coordinates |
| |
|
|
This document describes how Geo-Coordinates can be used in theLocator/ID Separation Protocol (LISP) and defines a new LISPCanonical Address Format (LCAF) encoding for such Geo-Coordinates.
This document updates RFC 8060. |
|
| |
| RFC 10042 | Post-Quantum/Traditional Hybrid Key Exchange with the Module- Lattice-Based Key-Encapsulation Mechanism for Use in SSH |
| |
| Authors: | P. Kampanakis, D. Stebila, T. Hansen. |
| Date: | August 2026 |
| Formats: | txt pdf html xml json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 10042 |
|
This document defines Post-Quantum Traditional (PQ/T) Hybrid key exchange methods based on the quantum-resistant Module-Lattice-BasedKey-Encapsulation Mechanism (ML-KEM) standard and traditionalElliptic-Curve Diffie-Hellman (ECDH) key exchange schemes. These methods are defined for use in the Secure Shell (SSH) transport layer protocol. |
|
