RFC Abstracts

RFC9256 - Segment Routing Policy Architecture
Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy.
RFC9255 - The 'I' in RPKI Does Not Stand for Identity
There is a false notion that Internet Number Resources (INRs) in the RPKI can be associated with the real-world identity of the 'holder' of an INR. This document specifies that RPKI does not associate to the INR holder.
RFC9254 - Encoding of Data Modeled with YANG in the Concise Binary Object Representation (CBOR)
YANG (RFC 7950) is a data modeling language used to model configuration data, state data, parameters and results of Remote Procedure Call (RPC) operations or actions, and notifications.
RFC9253 - Support for iCalendar Relationships
This specification updates the iCalendar RELATED-TO property defined in RFC 5545 by adding new relation types and introduces new iCalendar properties (LINK, CONCEPT, and REFID) to allow better linking and grouping of iCalendar components and related data.
RFC9252 - BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)
This document defines procedures and messages for SRv6-based BGP services, including Layer 3 Virtual Private Network (L3VPN), Ethernet VPN (EVPN), and Internet services. It builds on "BGP/MPLS IP Virtual Private Networks (VPNs)" (RFC 4364) and "BGP MPLS-Based Ethernet VPN" (RFC 7432).
RFC9251 - Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxies for Ethernet VPN (EVPN)
This document describes how to support endpoints running the Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) efficiently for the multicast services over an Ethernet VPN (EVPN) network by incorporating IGMP/MLD Proxy procedures on EVPN Provider Edges (PEs).
RFC9250 - DNS over Dedicated QUIC Connections
This document describes the use of QUIC to provide transport confidentiality for DNS. The encryption provided by QUIC has similar properties to those provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient packet-loss recovery than UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in RFC 7858, and latency characteristics similar to classic DNS over UDP. This specification describes the use of DoQ as a general-purpose transport for DNS and includes the use of DoQ for stub to recursive, recursive to authoritative, and zone transfer scenarios.
RFC9249 - A YANG Data Model for NTP
This document defines a YANG data model that can be used to configure and manage Network Time Protocol (NTP) version 4. It can also be used to configure and manage version 3. The data model includes configuration data and state data.
RFC9248 - Interoperability Profile for Relay User Equipment
Video Relay Service (VRS) is a term used to describe a method by which a hearing person can communicate with a sign language speaker who is deaf, deafblind, or hard of hearing (HoH) or has a speech disability using an interpreter (i.e., a Communications Assistant (CA)) connected via a videophone to the sign language speaker and an audio telephone call to the hearing user. The CA interprets using sign language on the videophone link and voice on the telephone link. Often the interpreters may be employed by a company or agency, termed a "provider" in this document. The provider also provides a video service that allows users to connect video devices to their service and subsequently to CAs and other sign language speakers. It is desirable that the videophones used by the sign language speaker conform to a standard so that any device may be used with any provider and that direct video calls between sign language speakers work. This document describes the interface between a videophone and a provider.
RFC9247 - BGP - Link State (BGP-LS) Extensions for Seamless Bidirectional Forwarding Detection (S-BFD)
Seamless Bidirectional Forwarding Detection (S-BFD) defines a simplified mechanism to use Bidirectional Forwarding Detection (BFD) with large portions of negotiation aspects eliminated, thus providing benefits such as quick provisioning as well as improved control and flexibility to network nodes initiating the path monitoring. The link-state routing protocols (IS-IS and OSPF) have been extended to advertise the S-BFD Discriminators.
RFC9246 - URI Signing for Content Delivery Network Interconnection (CDNI)
This document describes how the concept of URI Signing supports the content access control requirements of Content Delivery Network Interconnection (CDNI) and proposes a URI Signing method as a JSON Web Token (JWT) profile.
RFC9245 - IETF Discussion List Charter
The Internet Engineering Task Force (IETF) discussion mailing list furthers the development and specification of Internet technology through the general discussion of technical, procedural, operational, and other topics for which no dedicated mailing lists exist. As this is the most general IETF mailing list, considerable latitude in terms of topics is allowed, but there are posts and topics that are unsuitable for this mailing list. This document defines the charter for the IETF discussion list and explains its scope.
RFC9244 - Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry
This document aims to enrich the Distributed Denial-of-Service Open Threat Signaling (DOTS) signal channel protocol with various telemetry attributes, allowing for optimal Distributed Denial-of-Service (DDoS) attack mitigation. It specifies the normal traffic baseline and attack traffic telemetry attributes a DOTS client can convey to its DOTS server in the mitigation request, the mitigation status telemetry attributes a DOTS server can communicate to a DOTS client, and the mitigation efficacy telemetry attributes a DOTS client can communicate to a DOTS server. The telemetry attributes can assist the mitigator in choosing the DDoS mitigation techniques and performing optimal DDoS attack mitigation.
RFC9243 - A YANG Data Model for DHCPv6 Configuration
This document describes YANG data models for the configuration and management of Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (RFC 8415) servers, relays, and clients.
RFC9242 - Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2)
This document defines a new exchange, called "Intermediate Exchange", for the Internet Key Exchange Protocol Version 2 (IKEv2). This exchange can be used for transferring large amounts of data in the process of IKEv2 Security Association (SA) establishment. An example of the need to do this is using key exchange methods resistant to Quantum Computers (QCs) for IKE SA establishment. The Intermediate Exchange makes it possible to use the existing IKE fragmentation mechanism (which cannot be used in the initial IKEv2 exchange), helping to avoid IP fragmentation of large IKE messages if they need to be sent before IKEv2 SA is established.
RFC9241 - Content Delivery Network Interconnection (CDNI) Footprint and Capabilities Advertisement Using Application-Layer Traffic Optimization (ALTO)
The Content Delivery Networks Interconnection (CDNI) framework in RFC 6707 defines a set of protocols to interconnect CDNs to achieve multiple goals, including extending the reach of a given CDN. A CDNI Request Routing Footprint & Capabilities Advertisement interface (FCI) is needed to achieve the goals of a CDNI. RFC 8008 defines the FCI semantics and provides guidelines on the FCI protocol, but the exact protocol is not specified. This document defines a new Application-Layer Traffic Optimization (ALTO) service, called "CDNI Advertisement Service", that provides an implementation of the FCI, following the guidelines defined in RFC 8008.
RFC9240 - An Extension for Application-Layer Traffic Optimization (ALTO): Entity Property Maps
This document specifies an extension to the base Application-Layer Traffic Optimization (ALTO) Protocol that generalizes the concept of "endpoint properties", which have been tied to IP addresses so far, to entities defined by a wide set of objects. Further, these properties are presented as maps, similar to the network and cost maps in the base ALTO Protocol. While supporting the endpoints and related Endpoint Property Service defined in RFC 7285, the ALTO Protocol is extended in two major directions. First, from endpoints restricted to IP addresses to entities covering a wider and extensible set of objects; second, from properties for specific endpoints to entire entity property maps. These extensions introduce additional features that allow entities and property values to be specific to a given information resource. This is made possible by a generic and flexible design of entity and property types.
RFC9239 - Updates to ECMAScript Media Types
This document describes the registration of media types for the ECMAScript and JavaScript programming languages and conformance requirements for implementations of these types. This document obsoletes RFC 4329 ("Scripting Media Types)", replacing the previous registrations with information and requirements aligned with common usage and implementation experiences.
RFC9238 - Loading Manufacturer Usage Description (MUD) URLs from QR Codes
This informational document details a protocol to load Manufacturer Usage Description (MUD) definitions from RFC 8520 for devices that do not have them integrated.
RFC9237 - An Authorization Information Format (AIF) for Authentication and Authorization for Constrained Environments (ACE)
Information about which entities are authorized to perform what operations on which constituents of other entities is a crucial component of producing an overall system that is secure. Conveying precise authorization information is especially critical in highly automated systems with large numbers of entities, such as the Internet of Things.
RFC9236 - Architectural Considerations of Information-Centric Networking (ICN) Using a Name Resolution Service
This document describes architectural considerations and implications related to the use of a Name Resolution Service (NRS) in Information-Centric Networking (ICN). It explains how the ICN architecture can change when an NRS is utilized and how its use influences the ICN routing system. This document is a product of the Information-Centric Networking Research Group (ICNRG).
RFC9235 - TCP Authentication Option (TCP-AO) Test Vectors
This document provides test vectors to validate implementations of the two mandatory authentication algorithms specified for the TCP Authentication Option over both IPv4 and IPv6. This includes validation of the key derivation function (KDF) based on a set of test connection parameters as well as validation of the message authentication code (MAC). Vectors are provided for both currently required pairs of KDF and MAC algorithms: KDF_HMAC_SHA1 and HMAC- SHA-1-96, and KDF_AES_128_CMAC and AES-128-CMAC-96. The vectors also validate both whole TCP segments as well as segments whose options are excluded for middlebox traversal.
RFC9234 - Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages
Route leaks are the propagation of BGP prefixes that violate assumptions of BGP topology relationships, e.g., announcing a route learned from one transit provider to another transit provider or a lateral (i.e., non-transit) peer or announcing a route learned from one lateral peer to another lateral peer or a transit provider. These are usually the result of misconfigured or absent BGP route filtering or lack of coordination between autonomous systems (ASes). Existing approaches to leak prevention rely on marking routes by operator configuration, with no check that the configuration corresponds to that of the External BGP (eBGP) neighbor, or enforcement of the two eBGP speakers agreeing on the peering relationship. This document enhances the BGP OPEN message to establish an agreement of the peering relationship on each eBGP session between autonomous systems in order to enforce appropriate configuration on both sides. Propagated routes are then marked according to the agreed relationship, allowing both prevention and detection of route leaks.
RFC9233 - Internationalized Domain Names for Applications 2008 (IDNA2008) and Unicode 12.0.0
This document describes the changes between Unicode 6.0.0 and Unicode 12.0.0 in the context of the current version of Internationalized Domain Names for Applications 2008 (IDNA2008). Some additions and changes have been made in the Unicode Standard that affect the values produced by the algorithm IDNA2008 specifies. IDNA2008 allows adding exceptions to the algorithm for backward compatibility; however, this document does not add any such exceptions. This document provides the necessary tables to IANA to make its database consistent with Unicode 12.0.0.
RFC9232 - Network Telemetry Framework
Network telemetry is a technology for gaining network insight and facilitating efficient and automated network management. It encompasses various techniques for remote data generation, collection, correlation, and consumption. This document describes an architectural framework for network telemetry, motivated by challenges that are encountered as part of the operation of networks and by the requirements that ensue. This document clarifies the terminology and classifies the modules and components of a network telemetry system from different perspectives. The framework and taxonomy help to set a common ground for the collection of related work and provide guidance for related technique and standard developments.
RFC9231 - Additional XML Security Uniform Resource Identifiers (URIs)
This document updates and corrects the IANA "XML Security URIs" registry that lists URIs intended for use with XML digital signatures, encryption, canonicalization, and key management. These URIs identify algorithms and types of information. This document also obsoletes and corrects three errata against RFC 6931.
RFC9230 - Oblivious DNS over HTTPS
This document describes a protocol that allows clients to hide their IP addresses from DNS resolvers via proxying encrypted DNS over HTTPS (DoH) messages. This improves privacy of DNS operations by not allowing any one server entity to be aware of both the client IP address and the content of DNS queries and answers.
RFC9229 - IPv4 Routes with an IPv6 Next Hop in the Babel Routing Protocol
This document defines an extension to the Babel routing protocol that allows announcing routes to an IPv4 prefix with an IPv6 next hop, which makes it possible for IPv4 traffic to flow through interfaces that have not been assigned an IPv4 address.
RFC9228 - Delivered-To Email Header Field
The address to which email is delivered might be different than any of the addresses shown in any of the content header fields that were created by the email's author. For example, the address used by the email transport service is provided separately, such as through SMTP's "RCPT TO" command, and might not match any address in the To: or cc: fields. In addition, before final delivery, handling can entail a sequence of submission/delivery events, using a sequence of different destination addresses that (eventually) lead to the recipient. As well, a receiving system's delivery process can produce local address transformations.
RFC9227 - Using GOST Ciphers in the Encapsulating Security Payload (ESP) and Internet Key Exchange Version 2 (IKEv2) Protocols
This document defines a set of encryption transforms for use in the Encapsulating Security Payload (ESP) and in the Internet Key Exchange version 2 (IKEv2) protocols, which are parts of the IP Security (IPsec) protocol suite. The transforms are based on the GOST R 34.12-2015 block ciphers (which are named "Magma" and "Kuznyechik") in Multilinear Galois Mode (MGM) and the external rekeying approach.
RFC9226 - Bioctal: Hexadecimal 2.0
The prevailing hexadecimal system was chosen for congruence with groups of four binary digits, but its design exhibits an indifference to cognitive factors. An alternative is introduced that is designed to reduce brain cycles in cases where a hexadecimal number should be readily convertible to binary by a human being.
RFC9225 - Software Defects Considered Harmful
This document discourages the practice of introducing software defects in general and in network protocol implementations specifically. Software defects are one of the largest cost drivers for the networking industry. This document is intended to clarify the best current practice in this regard.
RFC9224 - Finding the Authoritative Registration Data Access Protocol (RDAP) Service
This document specifies a method to find which Registration Data Access Protocol (RDAP) server is authoritative to answer queries for a requested scope, such as domain names, IP addresses, or Autonomous System numbers. This document obsoletes RFC 7484.
RFC9223 - Real-Time Transport Object Delivery over Unidirectional Transport (ROUTE)
The Real-time Transport Object delivery over Unidirectional Transport (ROUTE) protocol is specified for robust delivery of Application Objects, including Application Objects with real-time delivery constraints, to receivers over a unidirectional transport. Application Objects consist of data that has meaning to applications that use the ROUTE protocol for delivery of data to receivers; for example, it can be a file, a Dynamic Adaptive Streaming over HTTP (DASH) or HTTP Live Streaming (HLS) segment, a WAV audio clip, etc. The ROUTE protocol also supports low-latency streaming applications.
RFC9222 - Guidelines for Autonomic Service Agents
This document proposes guidelines for the design of Autonomic Service Agents for autonomic networks. Autonomic Service Agents, together with the Autonomic Network Infrastructure, the Autonomic Control Plane, and the GeneRic Autonomic Signaling Protocol, constitute base elements of an autonomic networking ecosystem.
RFC9221 - An Unreliable Datagram Extension to QUIC
This document defines an extension to the QUIC transport protocol to add support for sending and receiving unreliable datagrams over a QUIC connection.
RFC9220 - Bootstrapping WebSockets with HTTP/3
The mechanism for running the WebSocket Protocol over a single stream of an HTTP/2 connection is equally applicable to HTTP/3, but the HTTP-version-specific details need to be specified. This document describes how the mechanism is adapted for HTTP/3.
RFC9219 - S/MIME Signature Verification Extension to the JSON Meta Application Protocol (JMAP)
This document specifies an extension to "The JSON Meta Application Protocol (JMAP) for Mail" (RFC 8621) for returning the S/MIME signature verification status.
RFC9218 - Extensible Prioritization Scheme for HTTP
This document describes a scheme that allows an HTTP client to communicate its preferences for how the upstream server prioritizes responses to its requests, and also allows a server to hint to a downstream intermediary how its responses should be prioritized when they are forwarded. This document defines the Priority header field for communicating the initial priority in an HTTP version-independent manner, as well as HTTP/2 and HTTP/3 frames for reprioritizing responses. These share a common format structure that is designed to provide future extensibility.
RFC9217 - Current Open Questions in Path-Aware Networking
In contrast to the present Internet architecture, a path-aware internetworking architecture has two important properties: it exposes the properties of available Internet paths to endpoints, and it provides for endpoints and applications to use these properties to select paths through the Internet for their traffic. While this property of "path awareness" already exists in many Internet-connected networks within single domains and via administrative interfaces to the network layer, a fully path-aware internetwork expands these concepts across layers and across the Internet.
RFC9216 - S/MIME Example Keys and Certificates
The S/MIME development community benefits from sharing samples of signed or encrypted data. This document facilitates such collaboration by defining a small set of X.509v3 certificates and keys for use when generating such samples.
RFC9215 - Using GOST R 34.10-2012 and GOST R 34.11-2012 Algorithms with the Internet X.509 Public Key Infrastructure
This document describes encoding formats, identifiers, and parameter formats for the GOST R 34.10-2012 and GOST R 34.11-2012 algorithms for use in the Internet X.509 Public Key Infrastructure (PKI).
RFC9214 - OSPFv3 Code Point for MPLS LSP Ping
IANA has created "Protocol in the Segment ID Sub-TLV" and "Protocol in Label Stack Sub-TLV of Downstream Detailed Mapping TLV" registries under the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry. RFC 8287 defines the code points for Open Shortest Path First (OSPF) and Intermediate System to Intermediate System (IS-IS) protocols.
RFC9213 - Targeted HTTP Cache Control
This specification defines a convention for HTTP response header fields that allow cache directives to be targeted at specific caches or classes of caches. It also defines one such header field, the CDN-Cache-Control response header field, which is targeted at content delivery network (CDN) caches.
RFC9212 - Commercial National Security Algorithm (CNSA) Suite Cryptography for Secure Shell (SSH)
The United States Government has published the National Security Agency (NSA) Commercial National Security Algorithm (CNSA) Suite, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using the United States National Security Agency's CNSA Suite algorithms with the Secure Shell Transport Layer Protocol and the Secure Shell Authentication Protocol. It applies to the capabilities, configuration, and operation of all components of US National Security Systems (described in NIST Special Publication 800-59) that employ Secure Shell (SSH). This document is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments.
RFC9211 - The Cache-Status HTTP Response Header Field
To aid debugging, HTTP caches often append header fields to a response, explaining how they handled the request in an ad hoc manner. This specification defines a standard mechanism to do so that is aligned with HTTP's caching model.
RFC9210 - DNS Transport over TCP - Operational Requirements
This document updates RFCs 1123 and 1536. This document requires the operational practice of permitting DNS messages to be carried over TCP on the Internet as a Best Current Practice. This operational requirement is aligned with the implementation requirements in RFC 7766. The use of TCP includes both DNS over unencrypted TCP as well as over an encrypted TLS session. The document also considers the consequences of this form of DNS communication and the potential operational issues that can arise when this Best Current Practice is not upheld.
RFC9209 - The Proxy-Status HTTP Response Header Field
This document defines the Proxy-Status HTTP response field to convey the details of an intermediary's response handling, including generated errors.
RFC9208 - IMAP QUOTA Extension
This document defines a QUOTA extension of the Internet Message Access Protocol (IMAP) (see RFCs 3501 and 9051) that permits administrative limits on resource usage (quotas) to be manipulated through the IMAP protocol.
RFC9207 - OAuth 2.0 Authorization Server Issuer Identification
This document specifies a new parameter called iss. This parameter is used to explicitly include the issuer identifier of the authorization server in the authorization response of an OAuth authorization flow. The iss parameter serves as an effective countermeasure to "mix-up attacks".