| |
| 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 9705 | Refresh-Interval Independent RSVP Fast Reroute Facility Protection |
| |
|
|
The RSVP-TE Fast Reroute (FRR) extensions specified in RFC 4090 define two local repair techniques to reroute Label Switched Path(LSP) traffic over pre-established backup tunnels. Facility backup method allows one or more LSPs traversing a connected link or node to be protected using a bypass tunnel. The many-to-one nature of local repair technique is attractive from a scalability point of view.This document enumerates facility backup procedures in RFC 4090 that rely on refresh timeout, hence, making facility backup method refresh-interval dependent. The RSVP-TE extensions defined in this document will enhance the facility backup protection mechanism by making the corresponding procedures refresh-interval independent, and hence, compatible with the Refresh-Interval Independent RSVP (RI-RSVP) capability specified in RFC 8370. Hence, this document updatesRFC 4090 in order to support the RI-RSVP capability specified in RFC8370. |
|
| |
| 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 9719 | YANG Data Model for Routing in Fat Trees (RIFT) |
| |
| Authors: | Z. Zhang, Y. Wei, S. Ma, X. Liu, B. Rijsman. |
| Date: | April 2025 |
| Formats: | txt xml json pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9719 |
|
This document defines a YANG data model for the configuration and management of the Routing in Fat Trees (RIFT) Protocol. The model is based on YANG 1.1, which is defined in RFC 7950 and conforms to theNetwork Management Datastore Architecture (NMDA) as described in RFC8342. |
|
| |
| 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 9724 | State of Affairs for Randomized and Changing Media Access Control (MAC) Addresses |
| |
| Authors: | JC. Zúñiga, CJ. Bernardos, Ed., A. Andersdotter. |
| Date: | March 2025 |
| Formats: | txt json xml pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9724 |
|
Internet users are becoming more aware that their activity over theInternet leaves a vast digital footprint, that communications might not always be properly secured, and that their location and actions can be tracked. One of the main factors that eases tracking ofInternet users is the wide use of long-lasting, and sometimes persistent, identifiers at various protocol layers. This document focuses on Media Access Control (MAC) addresses.
There have been several initiatives within the IETF and the IEEE 802 standards committees to address some of the privacy issues involved.This document provides an overview of these activities to help coordinate standardization activities in these bodies. |
|
| |
| RFC 9725 | WebRTC-HTTP Ingestion Protocol (WHIP) |
| |
|
|
This document describes a simple HTTP-based protocol that will allowWebRTC-based ingestion of content into streaming services and/orContent Delivery Networks (CDNs).
This document updates RFCs 8840 and 8842. |
|
| |
| RFC 9726 | Operational Considerations for Use of DNS in Internet of Things (IoT) Devices |
| |
|
|
This document details considerations about how Internet of Things(IoT) devices use IP addresses and DNS names. These concerns become acute as network operators begin deploying Manufacturer UsageDescriptions (MUD), as specified in RFC 8520, to control device access.
Also, this document makes recommendations on when and how to use DNS names in MUD files. |
|
| |
| 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 9731 | A YANG Data Model for Virtual Network (VN) Operations |
| |
| Authors: | Y. Lee, Ed., D. Dhody, Ed., D. Ceccarelli, I. Bryskin, B. Yoon. |
| Date: | March 2025 |
| Formats: | txt json xml html pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9731 |
|
A Virtual Network (VN) is a network provided by a service provider to a customer for the customer to use in any way it wants as though it were a physical network. This document provides a YANG data model generally applicable to any mode of VN operations. This includes VN operations as per the Abstraction and Control of TE Networks (ACTN) framework (RFC 8453). |
|
| |
| RFC 9732 | A Framework for NRP-Based Enhanced Virtual Private Networks |
| |
| Authors: | J. Dong, S. Bryant, Z. Li, T. Miyasaka, Y. Lee. |
| Date: | March 2025 |
| Formats: | txt html pdf xml json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9732 |
|
This document describes a framework for Enhanced Virtual PrivateNetworks (VPNs) based on Network Resource Partitions (NRPs) in order to support the needs of applications with specific traffic performance requirements (e.g., low latency, bounded jitter). NRP- based enhanced VPNs leverage the VPN and Traffic Engineering (TE) technologies and add characteristics that specific services require beyond those provided by conventional VPNs. Typically, an NRP-based enhanced VPN will be used to underpin network slicing, but it could also be of use in its own right providing enhanced connectivity services between customer sites. This document also provides an overview of relevant technologies in different network layers and identifies some areas for potential new work. |
|
| |
| 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 9744 | EVPN Virtual Private Wire Service (VPWS) Flexible Cross-Connect (FXC) Service |
| |
| Authors: | A. Sajassi, Ed., P. Brissette, J. Uttaro, J. Drake, S. Boutros, J. Rabadan. |
| Date: | March 2025 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9744 |
|
This document describes a new EVPN Virtual Private Wire Service(VPWS) service type specifically for multiplexing multiple attachment circuits across different Ethernet Segments (ESs) and physical interfaces into a single EVPN-VPWS service tunnel and still providingSingle-Active and All-Active multi-homing. This new service is referred to as the EVPN-VPWS Flexible Cross-Connect (FXC) service.This document specifies a solution based on extensions to EVPN-VPWS(RFC 8214), which in turn is based on extensions to EVPN (RFC 7432).Therefore, a thorough understanding of RFCs 7432 and 8214 are prerequisites for this document. |
|
| |
| RFC 9745 | The Deprecation HTTP Response Header Field |
| |
|
|
The Deprecation HTTP response header field is used to signal to consumers of a resource (identified by a URI) that the resource will be or has been deprecated. Additionally, the deprecation link relation can be used to link to a resource that provides further information about planned or existing deprecation. It may also provide ways in which client application developers can best manage deprecation. |
|
| |
| 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 9747 | Unaffiliated Bidirectional Forwarding Detection (BFD) Echo |
| |
| Authors: | W. Cheng, R. Wang, X. Min, Ed., R. Rahman, R. Boddireddy. |
| Date: | March 2025 |
| Formats: | txt json pdf xml html |
| Updates: | RFC 5880 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9747 |
|
This document specifies an extension to the Bidirectional ForwardingDetection (BFD) protocol that enables the use of the BFD Echo function without the need for an associated BFD control session.This "Unaffiliated BFD Echo" mechanism allows rapid detection of forwarding path failures in networks where establishing BFD control sessions is impractical or undesirable. By decoupling the Echo function from the control plane, network devices can utilize BFD's fast failure detection capabilities in a simplified manner, enhancing network resiliency and operational efficiency.
This document updates RFC 5880 by defining a new Unaffiliated BFDEcho mechanism. |
|
| |
| 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. |
|
| |
| RFC 9749 | Use of Voluntary Application Server Identification (VAPID) in JSON Meta Application Protocol (JMAP) Web Push |
| |
|
|
This document defines a method for JSON Meta Application Protocol(JMAP) servers to advertise their capability to authenticate Web Push notifications using the Voluntary Application Server Identification(VAPID) protocol. |
|
| |
| RFC 9751 | Closing the RTP Payload Format Media Types Registry |
| |
|
|
The working group process and the authors of RTP payload formats have sometimes failed to ensure that the media types are registered in theIANA "RTP Payload Format Media Types" registry as recommended by RFC8088. To simplify the process and rely only on the "Media Types" registry, this document closes the RTP payload- specific registry.In addition, it updates the instruction in RFC 8088 to reflect this change. |
|
| |
| RFC 9752 | Conveying Vendor-Specific Information in the Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE |
| |
| Authors: | C. Li, H. Zheng, S. Sivabalan, S. Sidor, Z. Ali. |
| Date: | April 2025 |
| Formats: | txt json pdf xml html |
| Updates: | RFC 7470 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9752 |
|
This document specifies extensions to the Path Computation ElementCommunication Protocol (PCEP) that enable the inclusion of vendor- specific information in stateful Path Computation Element (PCE) operations. These extensions allow vendors to incorporate proprietary data within PCEP messages, facilitating enhanced network optimization and functionality in environments requiring vendor- specific features. The extensions maintain compatibility with existing PCEP implementations and promote interoperability across diverse network deployments. RFC 7470 defines a facility to carry vendor-specific information in stateless PCEP messages. This document extends this capability for the stateful PCEP messages.
This document updates RFC 7470 to specify that Enterprise Numbers are managed through the "Private Enterprise Numbers (PENs)" registry. |
|
| |
| RFC 9754 | Extensions for Opening and Delegating Files in NFSv4.2 |
| |
| Authors: | T. Haynes, T. Myklebust. |
| Date: | March 2025 |
| Formats: | txt html json pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9754 |
|
The Network File System v4 (NFSv4) allows a client to both open a file and be granted a delegation of that file. This delegation provides the client the right to authoritatively cache metadata on the file locally. This document presents several extensions for both opening the file and delegating it to the client. This document extends NFSv4.2 (see RFC 7863). |
|
| |
| RFC 9755 | IMAP Support for UTF-8 |
| |
|
|
This specification extends the Internet Message Access Protocol, specifically IMAP4rev1 (RFC 3501), to support UTF-8 encoded international characters in user names, mail addresses, and message headers. This specification replaces RFC 6855. This specification does not extend IMAP4rev2 (RFC 9051), since that protocol includes everything in this extension. |
|
| |
| RFC 9756 | Update to the IANA Path Communication Element Protocol (PCEP) Numbers Registration Procedures and the Allowance of Experimental Error Codes |
| |
| Authors: | D. Dhody, A. Farrel. |
| Date: | March 2025 |
| Formats: | txt json xml pdf html |
| Updates: | RFC 5440, RFC 8231, RFC 8233, RFC 8281, RFC 8623, RFC 8664, RFC 8685, RFC 8697, RFC 8733, RFC 8745, RFC 8779, RFC 8780, RFC 8800, RFC 8934, RFC 9050, RFC 9059, RFC 9168, RFC 9357, RFC 9504, RFC 9603, RFC 9604 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9756 |
|
This document updates the registration procedure within the IANA"Path Computation Element Protocol (PCEP) Numbers" registry group.This specification changes some of the registries with StandardsAction to IETF Review as defined in RFC 8126 and thus updates RFCs8231, 8233, 8281, 8623, 8664, 8685, 8697, 8733, 8745, 8779, 8780,8800, 8934, 9050, 9059, 9168, 9357, 9504, 9603, and 9604.
Designating "experimental use" sub-ranges within codepoint registries is often beneficial for protocol experimentation in controlled environments. Although the registries for PCEP messages, objects, and TLV types have sub-ranges assigned for Experimental Use, the registry for PCEP Error-Types and Error-values currently does not.This document updates RFC 5440 by designating a specific range ofPCEP Error-Types for Experimental Use. |
|
| |
| RFC 9757 | Path Computation Element Communication Protocol (PCEP) Extensions for Native IP Networks |
| |
| Authors: | A. Wang, B. Khasanov, S. Fang, C. Zhu. |
| Date: | March 2025 |
| Formats: | txt xml pdf json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9757 |
|
This document introduces extensions to the Path Computation ElementCommunication Protocol (PCEP) to support path computation in NativeIP networks through a PCE-based central control mechanism known asCentralized Control Dynamic Routing (CCDR). These extensions empower a PCE to calculate and manage paths specifically for Native IP networks, thereby expanding PCEP's capabilities beyond its past use in MPLS and GMPLS networks. By implementing these extensions, IP network resources can be utilized more efficiently, facilitating the deployment of traffic engineering in Native IP environments. |
|
| |
| RFC 9759 | Unified Time Scaling for Temporal Coordination Frameworks |
| |
|
|
Estimating time requirements for tasks, both critical and mundane, remains a challenge in engineering, business, and everyday communication. Existing models fail due to inherent unpredictability and inconsistencies in human estimation. This document introduces the Two-Week Principle (TWP), a novel, universally adaptable time scale that seeks to standardize all temporal references to a singular, uniform duration. TWP ensures clarity, predictability, and synchronization across all sectors that rely on time-based scheduling. |
|
| |
| RFC 9761 | Manufacturer Usage Description (MUD) for TLS and DTLS Profiles for Internet of Things (IoT) Devices |
| |
| Authors: | T. Reddy.K, D. Wing, B. Anderson. |
| Date: | April 2025 |
| Formats: | txt html pdf json xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9761 |
|
This memo extends the Manufacturer Usage Description (MUD) specification to allow manufacturers to define TLS and DTLS profile parameters. This allows a network security service to identify unexpected (D)TLS usage, which can indicate the presence of unauthorized software, malware, or security policy-violating traffic on an endpoint. |
|
| |
| RFC 9764 | Bidirectional Forwarding Detection (BFD) Encapsulated in Large Packets |
| |
|
|
The Bidirectional Forwarding Detection (BFD) protocol is commonly used to verify connectivity between two systems. BFD packets are typically very small. It is desirable in some circumstances to know not only that the path between two systems is reachable, but also that it is capable of carrying a payload of a particular size. This document specifies how to implement such a mechanism using BFD inAsynchronous mode.
YANG modules for managing this mechanism are also defined in this document. These YANG modules augment the existing BFD YANG modules defined in RFC 9314. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA) (RFC 8342). |
|
| |
| RFC 9775 | IRTF Code of Conduct |
| |
|
|
This document describes the code of conduct for participants in theInternet Research Task Force (IRTF).
The IRTF believes that research is most effective when done in an open and inclusive forum that encourages diversity of ideas and participation. Through this code of conduct, the IRTF continues to strive to create and maintain an environment that encourages broad participation, and one in which people are treated with dignity, decency, and respect.
This document is a product of the Internet Research Steering Group(IRSG). |
|
| |
| RFC 9776 | Internet Group Management Protocol, Version 3 |
| |
|
|
The Internet Group Management Protocol (IGMP) is the protocol used byIPv4 systems to report their IP multicast group memberships to neighboring multicast routers. Version 3 of IGMP (IGMPv3) adds support for source filtering, that is, the ability for a system to report interest in receiving packets only from specific source addresses, or from all but specific source addresses, sent to a particular multicast address. That information may be used by multicast routing protocols to avoid delivering multicast packets from specific sources to networks where there are no interested receivers.
This document specifies IGMPv3. It is a revised version of RFC 3376 that includes clarifications and fixes for errata, and it is backward compatible with RFC 3376.
This document updates RFC 2236 and obsoletes RFC 3376. |
|
| |
| RFC 9777 | Multicast Listener Discovery Version 2 (MLDv2) for IPv6 |
| |
|
|
This document specifies the Multicast Listener Discovery version 2(MLDv2) protocol. MLD is used by an IPv6 router to discover the presence of multicast listeners on directly attached links and to discover which multicast addresses are of interest to those neighboring nodes. MLDv2 is designed to be interoperable with MLDv1.MLDv2 adds the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses or from all sources except for specific source addresses.
This document updates RFC 2710 and obsoletes RFC 3810. |
|
