| |
| RFC 9700 | Best Current Practice for OAuth 2.0 Security |
| |
|
|
This document describes best current security practice for OAuth 2.0.It updates and extends the threat model and security advice given inRFCs 6749, 6750, and 6819 to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0. Further, it deprecates some modes of operation that are deemed less secure or even insecure. |
|
| |
| RFC 9701 | JSON Web Token (JWT) Response for OAuth Token Introspection |
| |
| Authors: | T. Lodderstedt, Ed., V. Dzhuvinov. |
| Date: | January 2025 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9701 |
|
This specification proposes an additional response secured by JSONWeb Token (JWT) for OAuth 2.0 Token Introspection. |
|
| |
| RFC 9702 | YANG Data Model for Maximum Segment Identifier (SID) Depth (MSD) Types and MPLS MSD |
| |
| Authors: | Y. Qu, A. Lindem, S. Litkowski, J. Tantsura. |
| Date: | January 2025 |
| Formats: | txt html json xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9702 |
|
This document defines two YANG modules. The first module is the initial version of the IANA-maintained YANG module for MaximumSegment Identifier (SID) Depth (MSD) Types, which includes identities for both the MPLS data plane and Segment Routing over IPv6 (SRv6) data plane. The second module augments the IETF MPLS YANG data model to provide support for MPLS MSDs as defined in RFCs 8476 and 8491. |
|
| |
| RFC 9703 | Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) Egress Peer Engineering (EPE) Segment Identifiers (SIDs) with MPLS Data Plane |
| |
| Authors: | S. Hegde, M. Srivastava, K. Arora, S. Ninan, X. Xu. |
| Date: | December 2024 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9703 |
|
Egress Peer Engineering (EPE) is an application of Segment Routing(SR) that solves the problem of egress peer selection. The SR-basedBGP-EPE solution allows a centralized controller, e.g., a Software-Defined Network (SDN) controller, to program any egress peer. TheEPE solution requires the node or the SDN controller to program 1) the PeerNode Segment Identifier (SID) describing a session between two nodes, 2) the PeerAdj SID describing the link or links that are used by the sessions between peer nodes, and 3) the PeerSet SID describing any connected interface to any peer in the related group.This document provides new sub-TLVs for EPE-SIDs that are used in theTarget FEC Stack TLV (Type 1) in MPLS Ping and Traceroute procedures. |
|
| |
| RFC 9704 | Establishing Local DNS Authority in Validated Split-Horizon Environments |
| |
| Authors: | T. Reddy.K, D. Wing, K. Smith, B. Schwartz. |
| Date: | January 2025 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9704 |
|
When split-horizon DNS is deployed by a network, certain domain names can be resolved authoritatively by a network-provided DNS resolver.DNS clients that are not configured to use this resolver by default can use it for these specific domains only. This specification defines a mechanism for domain owners to inform DNS clients about local resolvers that are authorized to answer authoritatively for certain subdomains. |
|
| |
| RFC 9706 | TreeDN: Tree-Based Content Delivery Network (CDN) for Live Streaming to Mass Audiences |
| |
| Authors: | L. Giuliano, C. Lenart, R. Adam. |
| Date: | January 2025 |
| Formats: | txt pdf xml html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9706 |
|
As Internet audience sizes for high-interest live events reach unprecedented levels and bitrates climb to support formats and applications such as 4K, 8K, and Augmented Reality (AR), live streaming can place a unique type of stress upon network resources.TreeDN is a tree-based Content Delivery Network (CDN) architecture designed to address the distinctive scaling challenges of live streaming to mass audiences. TreeDN enables operators to offerReplication-as-a-Service (RaaS) at a fraction of the cost of traditional, unicast-based CDNs -- in some cases, at no additional cost to the infrastructure. In addition to efficiently utilizing network resources to deliver existing multi-destination traffic, this architecture also enables new types of content and use cases that previously were not possible or economically viable using traditionalCDN approaches. Finally, TreeDN is a decentralized architecture and a democratizing technology that makes content distribution more accessible to more people by dramatically reducing the costs of replication. |
|
| |
| RFC 9707 | Report from the IAB Workshop on Barriers to Internet Access of Services (BIAS) |
| |
| Authors: | M. Kühlewind, D. Dhody, M. Knodel. |
| Date: | February 2025 |
| Formats: | txt html pdf xml json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9707 |
|
The "Barriers to Internet Access of Services (BIAS)" workshop was convened by the Internet Architecture Board (IAB) from January 15-17,2024 as a three-day online meeting. Based on the submitted position papers, the workshop covered three areas of interest: the role ofCommunity Networks in Internet access of services, reports and comments on the observed digital divide, and measurements of censorship and censorship circumvention. This report summarizes the workshop's discussions and serves as a reference for reports on the current barriers to Internet access.
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report were expressed during the workshop by participants and do not necessarily reflect the IAB's views and positions. |
|
| |
| RFC 9708 | Use of the HSS/LMS Hash-Based Signature Algorithm in the Cryptographic Message Syntax (CMS) |
| |
|
|
This document specifies the conventions for using the HierarchicalSignature System (HSS) / Leighton-Micali Signature (LMS) hash-based signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. The HSS/LMS algorithm is one form of hash-based digital signature; it is described in RFC 8554. This document obsoletes RFC8708. |
|
| |
| RFC 9709 | Encryption Key Derivation in the Cryptographic Message Syntax (CMS) Using HKDF with SHA-256 |
| |
|
|
This document specifies the derivation of the content-encryption key or the content-authenticated-encryption key in the CryptographicMessage Syntax (CMS) using the HMAC-based Extract-and-Expand KeyDerivation Function (HKDF) with SHA-256. The use of this mechanism provides protection against an attacker that manipulates the content- encryption algorithm identifier or the content-authenticated- encryption algorithm identifier. |
|
| |
| RFC 9710 | Simple Fixes to the IP Flow Information Export (IPFIX) Entities IANA Registry |
| |
| Authors: | M. Boucadair, B. Claise. |
| Date: | February 2025 |
| Formats: | txt xml pdf json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9710 |
|
This document provides simple fixes to the IANA "IP Flow InformationExport (IPFIX) Entities" registry. Specifically, this document provides updates to fix shortcomings in the description of someInformation Elements (IEs), to ensure a consistent structure when citing an existing IANA registry, and to fix broken pointers, orphaned section references, etc. The updates are also meant to bring some consistency among the entries of the registry. |
|
| |
| RFC 9712 | IETF Meeting Venue Requirements Review |
| |
|
|
Following a review of the IETF meeting venue requirements, this document updates RFC 8718 ("IETF Plenary Meeting Venue SelectionProcess"), clarifies how the IETF Administration Support Activity(IASA) should interpret some elements of RFC 8718, and specifies a replacement exploratory meeting process, thereby updating RFC 8719("High-Level Guidance for the Meeting Policy of the IETF"). |
|
| |
| RFC 9713 | Bundle Protocol Version 7 Administrative Record Types Registry |
| |
|
|
This document updates RFC 9171 to clarify that Bundle ProtocolVersion 7 agents are expected to use the IANA "Bundle AdministrativeRecord Types" registry to identify and document administrative record types. This document also designates code points for Private andExperimental Use. |
|
| |
| RFC 9714 | Encapsulation for MPLS Performance Measurement with the Alternate-Marking Method |
| |
| Authors: | W. Cheng, Ed., X. Min, Ed., T. Zhou, J. Dai, Y. Peleg. |
| Date: | February 2025 |
| Formats: | txt json html pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9714 |
|
This document defines the encapsulation for MPLS performance measurement with the Alternate-Marking Method, which performs flow- based packet loss, delay, and jitter measurements on MPLS traffic. |
|
| |
| RFC 9715 | IP Fragmentation Avoidance in DNS over UDP |
| |
|
|
The widely deployed Extension Mechanisms for DNS (EDNS(0)) feature in the DNS enables a DNS receiver to indicate its received UDP message size capacity, which supports the sending of large UDP responses by aDNS server. Large DNS/UDP messages are more likely to be fragmented, and IP fragmentation has exposed weaknesses in application protocols.It is possible to avoid IP fragmentation in DNS by limiting the response size where possible and signaling the need to upgrade fromUDP to TCP transport where necessary. This document describes techniques to avoid IP fragmentation in DNS. |
|
| |
| RFC 9716 | Mechanisms for MPLS Ping and Traceroute Procedures in Inter-Domain Segment Routing Networks |
| |
| Authors: | S. Hegde, K. Arora, M. Srivastava, S. Ninan, N. Kumar. |
| Date: | February 2025 |
| Formats: | txt xml html pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9716 |
|
The Segment Routing (SR) architecture leverages source routing and can be directly applied to the use of an MPLS data plane. A SegmentRouting over MPLS (SR-MPLS) network may consist of multiple IGP domains or multiple Autonomous Systems (ASes) under the control of the same organization. It is useful to have the Label Switched Path(LSP) ping and traceroute procedures when an SR end-to-end path traverses multiple ASes or IGP domains. This document outlines mechanisms to enable efficient LSP ping and traceroute procedures in inter-AS and inter-domain SR-MPLS networks. This is achieved through a straightforward extension to the Operations, Administration, andMaintenance (OAM) protocol, relying solely on data plane forwarding for handling echo replies on transit nodes. |
|
| |
| RFC 9717 | A Routing Architecture for Satellite Networks |
| |
|
|
Satellite networks present some interesting challenges for packet networking. The entire topology is continually in motion, with links far less reliable than what is common in terrestrial networks. Some changes to link connectivity can be anticipated due to orbital dynamics.
This document proposes a scalable routing architecture for satellite networks based on existing routing protocols and mechanisms that is enhanced with scheduled link connectivity change information. This document proposes no protocol changes.
This document presents the author's view and is neither the product of the IETF nor a consensus view of the community. |
|
| |
| RFC 9718 | DNSSEC Trust Anchor Publication for the Root Zone |
| |
|
|
The root zone of the global Domain Name System (DNS) is cryptographically signed using DNS Security Extensions (DNSSEC).
In order to obtain secure answers from the root zone of the DNS usingDNSSEC, a client must configure a suitable trust anchor. This document describes the format and publication mechanisms IANA uses to distribute the DNSSEC trust anchors.
This document obsoletes RFC 7958. |
|
| |
| RFC 9720 | RFC Formats and Versions |
| |
|
|
In order to improve the readability of RFCs while supporting their archivability, the definitive version of the RFC Series transitioned from plain-text ASCII to XML using the RFCXML vocabulary; different publication versions are rendered from that base document. This document describes how RFCs are published.
This document obsoletes RFC 7990. This document also updates the stability policy in RFC 9280. |
|
| |
| RFC 9729 | The Concealed HTTP Authentication Scheme |
| |
| Authors: | D. Schinazi, D. Oliver, J. Hoyland. |
| Date: | February 2025 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9729 |
|
Most HTTP authentication schemes are probeable in the sense that it is possible for an unauthenticated client to probe whether an origin serves resources that require authentication. It is possible for an origin to hide the fact that it requires authentication by not generating Unauthorized status codes; however, that only works with non-cryptographic authentication schemes: cryptographic signatures require a fresh nonce to be signed. Prior to this document, there was no existing way for the origin to share such a nonce without exposing the fact that it serves resources that require authentication. This document defines a new non-probeable cryptographic authentication scheme. |
|
| |
| RFC 9730 | Interworking of GMPLS Control and Centralized Controller Systems |
| |
| Authors: | H. Zheng, Y. Lin, Y. Zhao, Y. Xu, D. Beller. |
| Date: | March 2025 |
| Formats: | txt json html xml pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9730 |
|
Generalized Multiprotocol Label Switching (GMPLS) control allows each network element (NE) to perform local resource discovery, routing, and signaling in a distributed manner.
The advancement of software-defined transport networking technology enables a group of NEs to be managed through centralized controller hierarchies. This helps to tackle challenges arising from multiple domains, vendors, and technologies. An example of such a centralized architecture is the Abstraction and Control of Traffic-EngineeredNetworks (ACTN) controller hierarchy, as described in RFC 8453.
Both the distributed and centralized control planes have their respective advantages and should complement each other in the system, rather than compete. This document outlines how the GMPLS distributed control plane can work together with a centralized controller system in a transport network. |
|
| |
| RFC 9733 | BRSKI with Alternative Enrollment (BRSKI-AE) |
| |
| Authors: | D. von Oheimb, Ed., S. Fries, H. Brockhaus. |
| Date: | March 2025 |
| Formats: | txt pdf xml html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9733 |
|
This document defines enhancements to the Bootstrapping Remote SecureKey Infrastructure (BRSKI) protocol, known as BRSKI with AlternativeEnrollment (BRSKI-AE). BRSKI-AE extends BRSKI to support certificate enrollment mechanisms instead of the originally specified use ofEnrollment over Secure Transport (EST). It supports certificate enrollment protocols such as the Certificate Management Protocol(CMP) that use authenticated self-contained signed objects for certification messages, allowing for flexibility in network device onboarding scenarios. The enhancements address use cases where the existing enrollment mechanism may not be feasible or optimal, providing a framework for integrating suitable alternative enrollment protocols. This document also updates the BRSKI reference architecture to accommodate these alternative methods, ensuring secure and scalable deployment across a range of network environments. |
|
| |
| RFC 9734 | X.509 Certificate Extended Key Usage (EKU) for Instant Messaging URIs |
| |
|
|
RFC 5280 specifies several extended key purpose identifiers(KeyPurposeIds) for X.509 certificates. This document defines anInstant Messaging (IM) identity KeyPurposeId for inclusion in theExtended Key Usage (EKU) extension of X.509 v3 public key certificates |
|
| |
| RFC 9735 | Locator/ID Separation Protocol (LISP) Distinguished Name Encoding |
| |
| Authors: | D. Farinacci, L. Iannone, Ed.. |
| Date: | February 2025 |
| Formats: | txt pdf json xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9735 |
|
This document defines how to use the Address Family Identifier (AFI)17 "Distinguished Name" in the Locator/ID Separation Protocol (LISP).LISP introduces two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). Distinguished Names (DNs) can be used in either EID-Records or RLOC-Records in LISP control messages to convey additional information. |
|
| |
| RFC 9736 | The BGP Monitoring Protocol (BMP) Peer Up Message Namespace |
| |
|
|
RFC 7854, the BGP Monitoring Protocol (BMP), uses different message types for different purposes. Most of these are structured as Type,Length, Value (TLV). One message type, the Peer Up message, lacks a set of TLVs defined for its use, instead sharing a namespace with theInitiation message. Experience has shown that this namespace sharing was a mistake, as it hampers the extension of the protocol.
This document updates RFC 7854 by creating an independent namespace for the Peer Up message. It also updates RFCs 8671 and 9069 by moving defined codepoints into the newly introduced registry.Compliant implementations of RFCs 7854, 8671, and 9069 also comply with this specification. |
|
| |
| RFC 9737 | Reporting Errors in NFSv4.2 via LAYOUTRETURN |
| |
| Authors: | T. Haynes, T. Myklebust. |
| Date: | February 2025 |
| Formats: | txt html json xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9737 |
|
The Parallel Network File System (pNFS) allows for a file's metadata and data to be on different servers (i.e., the metadata server (MDS) and the data server (DS)). When the MDS is restarted, the client can still modify the data file component. During the recovery phase of startup, the MDS and the DSs work together to recover state. If the client has not encountered errors with the data files, then the state can be recovered and the resilvering of the data files can be avoided. With any errors, there is no means by which the client can report errors to the MDS. As such, the MDS has to assume that a file needs resilvering. This document presents an extension to RFC 8435 to allow the client to update the metadata via LAYOUTRETURN and avoid the resilvering. |
|
| |
| RFC 9738 | IMAP MESSAGELIMIT Extension |
| |
| Authors: | A. Melnikov, A. P. Achuthan, V. Nagulakonda, L. Alves. |
| Date: | March 2025 |
| Formats: | txt json xml pdf html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9738 |
|
The MESSAGELIMIT extension of the Internet Message Access Protocol(RFCs 3501 and 9051) allows servers to announce a limit on the number of messages that can be processed in a single FETCH, SEARCH, STORE,COPY, or MOVE command (or their UID variants), or in a single APPEND or UID EXPUNGE command. This helps servers to control resource usage when performing various IMAP operations. This helps clients to know the message limit enforced by the corresponding IMAP server and avoid issuing commands that would exceed such limit. |
|
| |
| RFC 9739 | Protocol Independent Multicast Light (PIM Light) |
| |
| Authors: | H. Bidgoli, Ed., S. Venaas, M. Mishra, Z. Zhang, M. McBride. |
| Date: | March 2025 |
| Formats: | txt json html xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9739 |
|
This document specifies Protocol Independent Multicast Light (PIMLight) and the PIM Light Interface (PLI). A PLI does not need a PIMHello message to accept PIM Join/Prune messages, and it can signal multicast states over networks that cannot support full PIM neighbor discovery, such as Bit Index Explicit Replication (BIER) networks that connect two or more PIM domains. This document outlines the PIMLight protocol and procedures to ensure loop-free multicast traffic between two or more PIM Light routers. |
|
| |
| RFC 9740 | New IPFIX Information Elements for TCP Options and IPv6 Extension Headers |
| |
| Authors: | M. Boucadair, B. Claise. |
| Date: | March 2025 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9740 |
|
This document specifies new IP Flow Information Export (IPFIX)Information Elements (IEs) to solve issues with existing ipv6ExtensionHeaders and tcpOptions IPFIX IEs, especially the ability to export any observed IPv6 extension headers or TCP options. |
|
| |
| RFC 9741 | Concise Data Definition Language (CDDL): Additional Control Operators for the Conversion and Processing of Text |
| |
|
|
The Concise Data Definition Language (CDDL), standardized in RFC8610, provides "control operators" as its main language extension point. RFCs have added to this extension point in both an application-specific and a more general way.
The present document defines a number of additional generally applicable control operators for text conversion (bytes, integers, printf-style formatting, and JSON) and for an operation on text. |
|
| |
| RFC 9743 | Specifying New Congestion Control Algorithms |
| |
|
|
RFC 5033 discusses the principles and guidelines for standardizing new congestion control algorithms. This document obsoletes RFC 5033 to reflect changes in the congestion control landscape by providing a framework for the development and assessment of congestion control mechanisms, promoting stability across diverse network paths. This document seeks to ensure that proposed congestion control algorithms operate efficiently and without harm when used in the globalInternet. It emphasizes the need for comprehensive testing and validation to prevent adverse interactions with existing flows. |
|
| |
| RFC 9746 | BGP EVPN Multihoming Extensions for Split-Horizon Filtering |
| |
|
|
An Ethernet Virtual Private Network (EVPN) is commonly used withNetwork Virtualization Overlay (NVO) tunnels as well as with MPLS andSegment Routing (SR) tunnels. The multihoming procedures in EVPN may vary based on the type of tunnel used within the EVPN BroadcastDomain. Specifically, there are two multihoming split-horizon procedures designed to prevent looped frames on multihomed CustomerEdge (CE) devices: the Ethernet Segment Identifier (ESI) Label-based procedure and the local-bias procedure. The ESI Label-based split- horizon procedure is applied to MPLS-based tunnels such as MPLS overUDP (MPLSoUDP), while the local-bias procedure is used for other tunnels such as Virtual eXtensible Local Area Network (VXLAN) tunnels.
Current specifications do not allow operators to choose which split- horizon procedure to use for tunnel encapsulations that support both methods. Examples of tunnels that may support both procedures include MPLSoUDP, MPLS over GRE (MPLSoGRE), Generic NetworkVirtualization Encapsulation (Geneve), and Segment Routing over IPv6(SRv6) tunnels. This document updates the EVPN multihoming procedures described in RFCs 7432 and 8365, enabling operators to select the split-horizon procedure that meets their specific requirements. |
|
| |
| RFC 9748 | Updating the NTP Registries |
| |
|
|
The Network Time Protocol (NTP) and Network Time Security (NTS) documents define a number of registries, collectively called the NTP registries.
Some registries are correct, but some include incorrect assignments and some don't follow common practice. For the sake of completeness, this document reviews all NTP and NTS registries, and corrects the registries where necessary.
This document updates RFCs 5905, 5906, 7821, 7822, and 8573. |
|
