| |
| RFC 9800 | Compressed SRv6 Segment List Encoding |
| |
| Authors: | W. Cheng, Ed., C. Filsfils, Z. Li, B. Decraene, F. Clad, Ed.. |
| Date: | June 2025 |
| Formats: | txt xml pdf json html |
| Updates: | RFC 8754 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9800 |
|
Segment Routing over IPv6 (SRv6) is the instantiation of SegmentRouting (SR) on the IPv6 data plane. This document specifies new flavors for the SRv6 endpoint behaviors defined in RFC 8986, which enable the compression of an SRv6 segment list. Such compression significantly reduces the size of the SRv6 encapsulation needed to steer packets over long segment lists.
This document updates RFC 8754 by allowing a Segment List entry in the Segment Routing Header (SRH) to be either an IPv6 address, as specified in RFC 8754, or a REPLACE-CSID container in packed format, as specified in this document. |
|
| |
| RFC 9801 | Private Line Emulation over Packet Switched Networks |
| |
| Authors: | S. Gringeri, J. Whittaker, N. Leymann, C. Schmutzer, Ed., C. Brown. |
| Date: | July 2025 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9801 |
|
This document expands the applicability of Virtual Private WireService (VPWS) bit-stream payloads beyond Time Division Multiplexing(TDM) signals and provides pseudowire transport with complete signal transparency over Packet Switched Networks (PSNs). |
|
| |
| RFC 9802 | Use of the HSS and XMSS Hash-Based Signature Algorithms in Internet X.509 Public Key Infrastructure |
| |
| Authors: | D. Van Geest, K. Bashiri, S. Fluhrer, S. Gazdag, S. Kousidis. |
| Date: | June 2025 |
| Formats: | txt html pdf json xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9802 |
|
This document specifies algorithm identifiers and ASN.1 encoding formats for the following stateful Hash-Based Signature (HBS) schemes: Hierarchical Signature System (HSS), eXtended MerkleSignature Scheme (XMSS), and XMSS^MT (a multi-tree variant of XMSS).This specification applies to the Internet X.509 Public KeyInfrastructure (PKI) when digital signatures are used to sign certificates and certificate revocation lists (CRLs). |
|
| |
| RFC 9803 | Extensible Provisioning Protocol (EPP) Mapping for DNS Time-to-Live (TTL) Values |
| |
|
|
This document describes an extension to the Extensible ProvisioningProtocol (EPP) that allows EPP clients to manage the Time-to-Live(TTL) value for domain name delegation records. |
|
| |
| RFC 9804 | Simple Public Key Infrastructure (SPKI) S-Expressions |
| |
|
|
This memo specifies the data structure representation that was devised to support Simple Public Key Infrastructure (SPKI) certificates, as detailed in RFC 2692, with the intent that it be more widely applicable. It has been and is being used elsewhere.There are multiple implementations in a variety of programming languages. Uses of this representation are referred to in this document as "S-expressions". This memo makes precise the encodings of these SPKI S-expressions: It gives a "canonical form" for them, describes two "transport" representations, and also describes an"advanced" format for display to people. |
|
| |
| RFC 9805 | Deprecation of the IPv6 Router Alert Option for New Protocols |
| |
|
|
This document deprecates the IPv6 Router Alert option. Protocols that use the IPv6 Router Alert option may continue to do so, even in future versions. However, new protocols that are standardized in the future must not use the IPv6 Router Alert option.
This document updates RFC 2711. |
|
| |
| RFC 9806 | Updates to SIP-Based Media Recording (SIPREC) to Correct Metadata Media Type |
| |
|
|
The SIP-based Media Recording (SIPREC) protocol is defined by both"Session Initiation Protocol (SIP) Recording Metadata" (RFC 7865) and"Session Recording Protocol" (RFC 7866). Unfortunately, both RFCs contradict each other regarding how recording metadata is to be labeled. In addition, neither RFC registered the new media type.This document updates RFC 7866 to align with RFC 7865 when labeling recording metadata and also registers the media type. |
|
| |
| RFC 9807 | The OPAQUE Augmented Password-Authenticated Key Exchange (aPAKE) Protocol |
| |
| Authors: | D. Bourdrez, H. Krawczyk, K. Lewi, C. A. Wood. |
| Date: | July 2025 |
| Formats: | txt xml pdf html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9807 |
|
This document describes the OPAQUE protocol, an Augmented (orAsymmetric) Password-Authenticated Key Exchange (aPAKE) protocol that supports mutual authentication in a client-server setting without reliance on PKI and with security against pre-computation attacks upon server compromise. In addition, the protocol provides forward secrecy and the ability to hide the password from the server, even during password registration. This document specifies the coreOPAQUE protocol and one instantiation based on 3DH. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. |
|
| |
| RFC 9808 | Content Delivery Network Interconnection (CDNI) Capacity Capability Advertisement Extensions |
| |
| Authors: | A. Ryan, B. Rosenblum, N. Sopher. |
| Date: | July 2025 |
| Formats: | txt xml pdf json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9808 |
|
This specification defines a set of additional Capability Objects that provide information about current downstream CDN (dCDN) utilization and specified usage limits to the delegating upstream CDN(uCDN) in order to inform traffic delegation decisions.
This document supplements the CDNI Capability Objects, defined in RFC8008 as part of the Footprint & Capabilities Advertisement Interface(FCI), with two additional Capability Objects: FCI.CapacityLimits andFCI.Telemetry. |
|
| |
| RFC 9809 | X.509 Certificate Extended Key Usage (EKU) for Configuration, Updates, and Safety-Critical Communication |
| |
| Authors: | H. Brockhaus, D. Goltzsche. |
| Date: | July 2025 |
| Formats: | txt xml json pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9809 |
|
RFC 5280 defines the Extended Key Usage (EKU) extension and specifies several extended key purpose identifiers (KeyPurposeIds) for use with that extension in X.509 certificates. This document definesKeyPurposeIds for general-purpose and trust anchor configuration files, for software and firmware update packages, and for safety- critical communication to be included in the EKU extension of X.509 v3 public key certificates. |
|
| |
| RFC 9810 | Internet X.509 Public Key Infrastructure -- Certificate Management Protocol (CMP) |
| |
|
|
This document describes the Internet X.509 Public Key Infrastructure(PKI) Certificate Management Protocol (CMP). Protocol messages are defined for X.509v3 certificate creation and management. CMP provides interactions between client systems and PKI components such as a Registration Authority (RA) and a Certification Authority (CA).
This document adds support for management of certificates containing a Key Encapsulation Mechanism (KEM) public key and uses EnvelopedData instead of EncryptedValue. This document also includes the updates specified in Section 2 and Appendix A.2 of RFC 9480.
This document obsoletes RFC 4210, and together with RFC 9811, it also obsoletes RFC 9480. Appendix F of this document updates Section 9 ofRFC 5912. |
|
| |
| RFC 9811 | Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP) |
| |
|
|
This document describes how to layer the Certificate ManagementProtocol (CMP) over HTTP.
It includes the updates to RFC 6712 specified in Section 3 of RFC9480; these updates introduce CMP URIs using a well-known prefix. It obsoletes RFC 6712; and, together with RFC 9810, it also obsoletesRFC 9480. |
|
| |
| RFC 9813 | Operational Considerations for Using TLS Pre-Shared Keys (TLS-PSKs) with RADIUS |
| |
|
|
This document provides implementation and operational considerations for using TLS Pre-Shared Keys (TLS-PSKs) with RADIUS/TLS (RFC 6614) and RADIUS/DTLS (RFC 7360). The purpose of the document is to help smooth the operational transition from the use of RADIUS/UDP toRADIUS/TLS. |
|
| |
| RFC 9814 | Use of the SLH-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS) |
| |
| Authors: | R. Housley, S. Fluhrer, P. Kampanakis, B. Westerbaan. |
| Date: | July 2025 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9814 |
|
SLH-DSA is a stateless hash-based signature algorithm. This document specifies the conventions for using the SLH-DSA signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. |
|
| |
| RFC 9815 | BGP Link State (BGP-LS) Shortest Path First (SPF) Routing |
| |
| Authors: | K. Patel, A. Lindem, S. Zandi, W. Henderickx. |
| Date: | July 2025 |
| Formats: | txt json html xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9815 |
|
Many Massively Scaled Data Centers (MSDCs) have converged on simplified Layer 3 (L3) routing. Furthermore, requirements for operational simplicity have led many of these MSDCs to converge onBGP as their single routing protocol for both fabric routing and DataCenter Interconnect (DCI) routing. This document describes extensions to BGP for use with BGP Link State (BGP-LS) distribution and the Shortest Path First (SPF) algorithm. In doing this, it allows BGP to be efficiently used as both the underlay protocol and the overlay protocol in MSDCs. |
|
| |
| RFC 9816 | Usage and Applicability of BGP Link State (BGP-LS) Shortest Path First (SPF) Routing in Data Centers |
| |
| Authors: | K. Patel, A. Lindem, S. Zandi, G. Dawra, J. Dong. |
| Date: | July 2025 |
| Formats: | txt pdf xml html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9816 |
|
This document discusses the usage and applicability of BGP Link State(BGP-LS) Shortest Path First (SPF) extensions in data center networks utilizing Clos or Fat Tree topologies. The document is intended to provide simplified guidance for the deployment of BGP-LS SPF extensions. |
|
| |
| RFC 9817 | Use Cases for In-Network Computing |
| |
| Authors: | I. Kunze, K. Wehrle, D. Trossen, M-J. Montpetit, X. de Foy, D. Griffin, M. Rio. |
| Date: | August 2025 |
| Formats: | txt html pdf xml json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9817 |
|
Computing in the Network (COIN) comes with the prospect of deploying processing functionality on networking devices such as switches and network interface cards. While such functionality can be beneficial, it has to be carefully placed into the context of the generalInternet communication, and it needs to be clearly identified where and how those benefits apply.
This document presents some use cases to demonstrate how a number of salient COIN-related applications can benefit from COIN.Furthermore, to guide research on COIN, it identifies essential research questions and outlines desirable capabilities that COIN systems addressing these use cases may need to support. Finally, the document provides a preliminary categorization of the described research questions to source future work in this domain. This document is a product of the Computing in the Network Research Group(COINRG). It is not an IETF product and it is not a standard. |
|
| |
| RFC 9818 | DHCPv6 Prefix Delegation on IPv6 Customer Edge (CE) Routers in LANs |
| |
|
|
This document defines requirements for IPv6 Customer Edge (CE) routers to support DHCPv6 Prefix Delegation for distributing available prefixes to LAN devices that were delegated to an IPv6 CE router. This document updates RFC 7084. |
|
| |
| RFC 9819 | Argument Signaling for BGP Services in Segment Routing over IPv6 (SRv6) |
| |
|
|
RFC 9252 defines procedures and messages for BGP overlay services forSegment Routing over IPv6 (SRv6), including Layer 3 Virtual PrivateNetwork (L3VPN), Ethernet VPN (EVPN), and global Internet routing.This document updates RFC 9252 and provides more detailed specifications for the signaling and processing of SRv6 SegmentIdentifier advertisements for BGP overlay service routes associated with SRv6 Endpoint Behaviors that support arguments. |
|
| |
| RFC 9820 | Authentication Service Based on the Extensible Authentication Protocol (EAP) for Use with the Constrained Application Protocol (CoAP) |
| |
| Authors: | R. Marin-Lopez, D. Garcia-Carrillo. |
| Date: | September 2025 |
| Formats: | txt json xml html pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9820 |
|
This document specifies an authentication service that uses theConstrained Application Protocol (CoAP) as a transport method to carry the Extensible Authentication Protocol (EAP). As such, it defines an EAP lower layer based on CoAP called "CoAP-EAP". One of the main goals is to authenticate a CoAP-enabled Internet of Things(IoT) device (EAP peer) that intends to join a security domain managed by a Controller (EAP authenticator). Secondly, it allows deriving key material to protect CoAP messages exchanged between them based on Object Security for Constrained RESTful Environments(OSCORE), enabling the establishment of a security association between them. |
|
| |
| RFC 9824 | Compact Denial of Existence in DNSSEC |
| |
|
|
This document describes a technique to generate a signed DNS response on demand for a nonexistent name by claiming that the name exists but doesn't have any data for the queried record type. Such responses require only one minimally covering NSEC or NSEC3 record, allow online signing servers to minimize signing operations and response sizes, and prevent zone content disclosure.
This document updates RFCs 4034 and 4035. |
|
| |
| RFC 9825 | Extensions to OSPF for Advertising Prefix Administrative Tags |
| |
| Authors: | A. Lindem, Ed., P. Psenak, Y. Qu. |
| Date: | July 2025 |
| Formats: | txt pdf json xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9825 |
|
It is useful for routers in OSPFv2 and OSPFv3 routing domains to be able to associate tags with prefixes. Previously, OSPFv2 and OSPFv3 were relegated to a single tag and only for Autonomous System (AS)External and Not-So-Stubby-Area (NSSA) prefixes. With the flexible encodings provided by OSPFv2 Prefix/Link Attribute Advertisement andOSPFv3 Extended Link State Advertisements (LSAs), multiple administrative tags may be advertised for all types of prefixes.These administrative tags can be used for many applications including route redistribution policy, selective prefix prioritization, selective IP Fast Reroute (IPFRR) prefix protection, and many others. |
|
| |
| RFC 9826 | A YANG Data Model for the Path Computation Element Communication Protocol (PCEP) |
| |
| Authors: | D. Dhody, Ed., V. Beeram, J. Hardwick, J. Tantsura. |
| Date: | September 2025 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9826 |
|
This document defines a YANG data model for the management of thePath Computation Element Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PathComputation Element (PCE), or between two PCEs. |
|
| |
| RFC 9828 | RTP Payload Format for JPEG 2000 Streaming with Sub-Codestream Latency |
| |
| Authors: | P.-A. Lemieux, Ed., D. Taubman. |
| Date: | August 2025 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9828 |
|
This document defines the RTP payload format for the streaming of a video signal encoded as a sequence of JPEG 2000 codestreams. The format allows sub-codestream latency, such that the first RTP packet for a given image can be emitted before the entire image is available to or encoded by the sender. |
|
| |
| RFC 9829 | Handling of Resource Public Key Infrastructure (RPKI) Certificate Revocation List (CRL) Number Extensions |
| |
|
|
This document revises how the Resource Public Key Infrastructure(RPKI) handles Certificate Revocation List (CRL) Number extensions.This document updates RFC 6487. |
|
| |
| RFC 9830 | Advertising Segment Routing Policies in BGP |
| |
| Authors: | S. Previdi, C. Filsfils, K. Talaulikar, Ed., P. Mattes, D. Jain. |
| Date: | September 2025 |
| Formats: | txt json pdf xml html |
| Updates: | RFC 9012 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9830 |
|
A Segment Routing (SR) Policy is an ordered list of segments (also referred to as "instructions") that define a source-routed policy.An SR Policy consists of one or more Candidate Paths (CPs), each comprising one or more segment lists. A headend can be provisioned with these CPs using various mechanisms such as Command-LineInterface (CLI), Network Configuration Protocol (NETCONF), PathComputation Element Communication Protocol (PCEP), or BGP.
This document specifies how BGP can be used to distribute SR PolicyCPs. It introduces a BGP SAFI for advertising a CP of an SR Policy and defines sub-TLVs for the Tunnel Encapsulation Attribute to signal information related to these CPs.
Furthermore, this document updates RFC 9012 by extending the ColorExtended Community to support additional steering modes over SRPolicy. |
|
| |
| RFC 9831 | Segment Type Extensions for BGP Segment Routing (SR) Policy |
| |
| Authors: | K. Talaulikar, Ed., C. Filsfils, S. Previdi, P. Mattes, D. Jain. |
| Date: | September 2025 |
| Formats: | txt json html pdf xml |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9831 |
|
This document specifies the signaling of additional Segment Routing(SR) Segment Types for SR Policies in BGP using the SR PolicySubsequent Address Family Identifier (SAFI). |
|
| |
| RFC 9832 | BGP Classful Transport Planes |
| |
| Authors: | K. Vairavakkalai, Ed., N. Venkataraman, Ed.. |
| Date: | September 2025 |
| Formats: | txt xml html pdf json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9832 |
|
This document specifies a mechanism referred to as "Intent-DrivenService Mapping". The mechanism uses BGP to express Intent-based association of overlay routes with underlay routes having specificTraffic Engineering (TE) characteristics satisfying a certain ServiceLevel Agreement (SLA). This is achieved by defining new constructs to group underlay routes with sufficiently similar TE characteristics into identifiable classes (called "Transport Classes" or "TCs"), that overlay routes use as an ordered set to resolve reachability(Resolution Schemes) towards service endpoints. These constructs can be used, for example, to realize the "IETF Network Slice" defined in the TEAS Network Slices framework (RFC 9543).
Additionally, this document specifies protocol procedures for BGP that enable dissemination of service mapping information in a network that may span multiple cooperating administrative domains. These domains may be administered either by the same provider or by closely coordinating providers. A new BGP address family that leverages the procedures described in RFC 4364 ("BGP/MPLS IP Virtual PrivateNetworks (VPNs)") and follows the NLRI encoding described in RFC 8277("Using BGP to Bind MPLS Labels to Address Prefixes") is defined to enable each advertised underlay route to be identified by its class.This new address family is called "BGP Classful Transport" (or "BGPCT"). |
|
| |
| RFC 9833 | A Common YANG Data Model for Attachment Circuits |
| |
| Authors: | M. Boucadair, Ed., R. Roberts, Ed., O. Gonzalez de Dios, S. Barguil, B. Wu. |
| Date: | September 2025 |
| Formats: | txt xml html pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9833 |
|
The document specifies a common attachment circuits (ACs) YANG data model, which is designed to be reusable by other models. This design is meant to ensure consistent AC structures among models that manipulate ACs. For example, this common model can be reused by service models to expose ACs as a service, service models that require binding a service to a set of ACs, network and device models to provision ACs, etc. |
|
| |
| RFC 9834 | YANG Data Models for Bearers and Attachment Circuits as a Service (ACaaS) |
| |
| Authors: | M. Boucadair, Ed., R. Roberts, Ed., O. Gonzalez de Dios, S. Barguil, B. Wu. |
| Date: | September 2025 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9834 |
|
Delivery of network services assumes that appropriate setup is provisioned over the links that connect customer termination points and a provider network. The required setup to allow successful data exchange over these links is referred to as an attachment circuit(AC), while the underlying link is referred to as a "bearer".
This document specifies a YANG service data model for ACs. This model can be used for the provisioning of ACs before or during service provisioning (e.g., RFC 9543 Network Slice Service).
The document also specifies a YANG service data model for managing bearers over which ACs are established. |
|
| |
| RFC 9835 | A Network YANG Data Model for Attachment Circuits |
| |
| Authors: | M. Boucadair, Ed., R. Roberts, O. Gonzalez de Dios, S. Barguil, B. Wu. |
| Date: | September 2025 |
| Formats: | txt xml pdf json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9835 |
|
This document specifies a network model for attachment circuits(ACs). The model can be used for the provisioning of ACs prior to or during service provisioning (e.g., VPN, RFC 9543 Network SliceService). A companion service model is specified in "YANG DataModels for Bearers and Attachment Circuits as a Service (ACaaS)"(RFC9834).
The module augments the base network ('ietf-network') and the ServiceAttachment Point (SAP) models with the detailed information for the provisioning of ACs in Provider Edges (PEs). |
|
| |
| RFC 9836 | A YANG Data Model for Augmenting VPN Service and Network Models with Attachment Circuits |
| |
| Authors: | M. Boucadair, Ed., R. Roberts, S. Barguil, O. Gonzalez de Dios. |
| Date: | September 2025 |
| Formats: | txt html pdf json xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9836 |
|
This document defines a YANG data model, referred to as the "AC Glue" model, to augment the LxVPN Service Model (LxSM) and LxVPN NetworkModel (LxNM) with references to attachment circuits (ACs). The ACGlue model enables a provider to associate Layer 2/3 VPN (LxVPN) services with the underlying AC infrastructure, thereby facilitating consistent provisioning and management of new or existing ACs in conjunction with LxVPN services. Specifically, by introducing an integrated approach to AC and LxVPN management, this model supportsAttachment Circuit as a Service (ACaaS) and provides a standardized mechanism for aligning AC/VPN requests with the network configurations required to deliver them. |
|
| |
| RFC 9837 | The IPv6 VPN Service Destination Option |
| |
| Authors: | R. Bonica, X. Li, A. Farrel, Y. Kamite, L. Jalil. |
| Date: | August 2025 |
| Formats: | txt html json pdf xml |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9837 |
|
This document describes an experiment in which VPN service information is encoded in an experimental IPv6 Destination Option.The experimental IPv6 Destination Option is called the VPN ServiceOption.
One purpose of this experiment is to demonstrate that the VPN ServiceOption can be deployed in a production network. Another purpose is to demonstrate that the security measures described in this document are sufficient to protect a VPN. Finally, this document encourages replication of the experiment. |
|
| |
| RFC 9839 | Unicode Character Repertoire Subsets |
| |
|
|
This document discusses subsets of the Unicode character repertoire for use in protocols and data formats and specifies three subsets recommended for use in IETF specifications. |
|
| |
| RFC 9840 | rLEDBAT: Receiver-Driven Low Extra Delay Background Transport for TCP |
| |
| Authors: | M. Bagnulo, A. García-Martínez, G. Montenegro, P. Balasubramanian. |
| Date: | September 2025 |
| Formats: | txt html xml pdf json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9840 |
|
This document specifies receiver-driven Low Extra Delay BackgroundTransport (rLEDBAT) -- a set of mechanisms that enable the execution of a less-than-best-effort congestion control algorithm for TCP at the receiver end. This document is a product of the InternetCongestion Control Research Group (ICCRG) of the Internet ResearchTask Force (IRTF). |
|
| |
| RFC 9841 | Shared Brotli Compressed Data Format |
| |
| Authors: | J. Alakuijala, T. Duong, E. Kliuchnikov, Z. Szabadka, L. Vandevenne, Ed.. |
| Date: | September 2025 |
| Formats: | txt xml html pdf json |
| Updates: | RFC 7932 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9841 |
|
This specification defines a data format for shared brotli compression, which adds support for shared dictionaries, large window, and a container format to brotli (RFC 7932). Shared dictionaries and large window support allow significant compression gains compared to regular brotli. This document specifies an extension to the method defined in RFC 7932. |
|
| |
| RFC 9842 | Compression Dictionary Transport |
| |
| Authors: | P. Meenan, Ed., Y. Weiss, Ed.. |
| Date: | September 2025 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9842 |
|
This document specifies a mechanism for dictionary-based compression in the Hypertext Transfer Protocol (HTTP). By utilizing this technique, clients and servers can reduce the size of transmitted data, leading to improved performance and reduced bandwidth consumption. This document extends existing HTTP compression methods and provides guidelines for the delivery and use of compression dictionaries within the HTTP protocol. |
|
| |
| RFC 9843 | IGP Flexible Algorithms: Bandwidth, Delay, Metrics, and Constraints |
| |
| Authors: | S. Hegde, W. Britto, R. Shetty, B. Decraene, P. Psenak, T. Li. |
| Date: | September 2025 |
| Formats: | txt json html pdf xml |
| Updates: | RFC 9350 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9843 |
|
Many networks configure the IGP link metric relative to the link capacity, and high bandwidth traffic gets routed per the link capacity. Flexible Algorithms provide mechanisms to create constraint-based paths in an IGP. This specification documents a generic metric-type and a set of bandwidth-related constraints to be used in Flexible Algorithms.
This document updates RFC 9350. |
|
| |
| RFC 9844 | Entering IPv6 Zone Identifiers in User Interfaces |
| |
|
|
This document describes how the zone identifier of an IPv6 scoped address, defined in the IPv6 Scoped Address Architecture specification (RFC 4007), should be entered into a user interface.This document obsoletes RFC 6874 and updates RFCs 4007, 7622, and8089. |
|
| |
| RFC 9845 | Challenges and Opportunities in Management for Green Networking |
| |
| Authors: | A. Clemm, Ed., C. Pignataro, Ed., C. Westphal, L. Ciavaglia, J. Tantsura, M-P. Odini. |
| Date: | October 2025 |
| Formats: | txt html pdf xml json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9845 |
|
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 is a product of the Network Management Research Group(NMRG) of the Internet Research Task Force (IRTF). This document reflects the consensus of the research group. It is not a candidate for any level of Internet Standard and is published for informational purposes. |
|
| |
| RFC 9856 | Multicast Source Redundancy in EVPNs |
| |
| Authors: | J. Rabadan, Ed., J. Kotalwar, S. Sathappan, Z. Zhang, W. Lin. |
| Date: | September 2025 |
| Formats: | txt pdf json xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9856 |
|
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. |
|
| |
| RFC 9858 | 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.
This document is a product of the Internet Research Task Force(IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Crypto ForumResearch Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not candidates for any level of Internet Standard; see Section 2 of RFC 7841. |
|
| |
| RFC 9859 | Generalized DNS Notifications |
| |
| Authors: | J. Stenstam, P. Thomassen, J. Levine. |
| Date: | September 2025 |
| Formats: | txt pdf html xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9859 |
|
This document generalizes and extends the use of DNS NOTIFY (RFC1996) 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).
To enable this functionality, a method for discovering the receiver endpoint for such notification messages is introduced, via the newDSYNC record type. Notification types are recorded in a new registry, with initial support for parental NS and DS record updates including DNSSEC bootstrapping. |
|
| |
| RFC 9861 | KangarooTwelve and TurboSHAKE |
| |
| Authors: | B. Viguier, D. Wong, Ed., G. Van Assche, Ed., Q. Dang, Ed., J. Daemen, Ed.. |
| Date: | October 2025 |
| Formats: | txt html xml pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9861 |
|
This document defines four eXtendable-Output Functions (XOFs), hash functions with output of arbitrary length, named TurboSHAKE128,TurboSHAKE256, KT128, and KT256.
All four functions provide efficient and secure hashing primitives, and the last two are able to exploit the parallelism of the implementation in a scalable way.
This document is a product of the Crypto Forum Research Group. It builds up on the definitions of the permutations and of the sponge construction in NIST FIPS 202 and is meant to serve as a stable reference and an implementation guide. |
|
| |
| RFC 9865 | Cursor-Based Pagination of System of Cross-domain Identity Management (SCIM) Resources |
| |
|
|
This document updates RFCs 7643 and 7644 by defining additionalSystem 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. |
|
| |
| RFC 9866 | 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 RoutingProtocol 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 NodeFailure 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 MessageOption for synchronizing this state among different nodes, and the coordination algorithm itself. |
|
| |
| RFC 9868 | 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. |
|
| |
| RFC 9869 | Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) for UDP Options |
| |
| Authors: | G. Fairhurst, T. Jones. |
| Date: | October 2025 |
| Formats: | txt html json xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9869 |
|
This document specifies how a UDP Options sender implements DatagramPacketization 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. |
|
| |
| RFC 9870 | Export of UDP Options Information in IP Flow Information Export (IPFIX) |
| |
| Authors: | M. Boucadair, T. Reddy.K. |
| Date: | October 2025 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9870 |
|
This document specifies new IP Flow Information Export (IPFIX)Information Elements for UDP Options. |
|
| |
| RFC 9872 | Recommendations for Discovering IPv6 Prefix Used for IPv6 Address Synthesis |
| |
| Authors: | N. Buraglio, T. Jensen, J. Linkova. |
| Date: | September 2025 |
| Formats: | txt xml pdf json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9872 |
|
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 forNAT64 prefix discovery, specifically recommending obtaining the NAT64 prefix from the Router Advertisement option (RFC 8781) when available. |
|
| |
| RFC 9873 | Additional Email Address Extension for the Extensible Provisioning Protocol (EPP) |
| |
| Authors: | D. Belyavsky, J. Gould, S. Hollenbeck. |
| Date: | October 2025 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9873 |
|
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. |
|
| |
| RFC 9874 | 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. |
|
| |
| RFC 9877 | Registration Data Access Protocol (RDAP) Extension for Geofeed Data |
| |
| Authors: | J. Singh, T. Harrison. |
| Date: | October 2025 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9877 |
|
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. |
|
