RFC Abstracts
RFC9391 - Static Context Header Compression over Narrowband Internet of Things
This document describes Static Context Header Compression and fragmentation (SCHC) specifications, RFCs 8724 and 8824, in combination with the 3rd Generation Partnership Project (3GPP) and the Narrowband Internet of Things (NB-IoT).
RFC9390 - Diameter Group Signaling
In large network deployments, a single Diameter node can support over a million concurrent Diameter sessions. In some use cases, Diameter nodes need to apply the same operation to a large group of Diameter sessions concurrently. The Diameter base protocol commands operate on a single session so these use cases can result in many thousands of command exchanges enforcing the same operation on each session in the group. In order to reduce signaling, it is desirable to enable bulk operations on all (or part of) the sessions managed by a Diameter node using a single or a few command exchanges. This document specifies the Diameter protocol extensions to achieve this signaling optimization.
RFC9389 - Nominating Committee Eligibility
The IETF Nominating Committee (NomCom) appoints candidates to several IETF leadership committees. RFC 8713 provides criteria for NomCom membership that attempt to ensure NomCom volunteers are members of the loosely defined IETF community, by requiring in-person attendance in three of the past five in-person meetings. In 2020 and 2021, the IETF had six consecutive fully online plenary meetings that drove rapid advancement in remote meeting technologies and procedures, including an experiment that included remote attendance for NomCom eligibility. This document updates RFC 8713 by defining a new set of eligibility criteria from first principles, with consideration to the increased salience of remote attendance. This document obsoletes RFCs 8788 and 8989.
RFC9388 - Content Delivery Network Interconnection (CDNI) Footprint Types: Country Subdivision Code and Footprint Union
Open Caching architecture is a use case of Content Delivery Network Interconnection (CDNI) in which the commercial Content Delivery Network (CDN) is the upstream CDN (uCDN) and the ISP caching layer serves as the downstream CDN (dCDN). RFC 8006 defines footprint types that are used for footprint objects as part of the Metadata interface (MI). The footprint types are also used for the Footprint & Capabilities Advertisement interface (FCI) as defined in RFC 8008. This document defines two new footprint types. The first footprint type defined is an ISO 3166-2 country subdivision code. Defining this country subdivision code improves granularity for delegation as compared to the ISO 3166-1 country code footprint type defined in RFC 8006. The ISO 3166-2 country subdivision code is also added as a new entity domain type in the "ALTO Entity Domain Types" registry defined in Section 7.4 of RFC 9241. The second footprint type defines a footprint union to aggregate footprint objects. This allows for additive semantics over the narrowing semantics defined in Appendix B of RFC 8008 and therefore updates RFC 8008. The two new footprint types are based on the requirements raised by Open Caching but are also applicable to CDNI use cases in general.
RFC9387 - Use Cases for DDoS Open Threat Signaling (DOTS) Telemetry
DDoS Open Threat Signaling (DOTS) telemetry enriches the base DOTS protocols to assist the mitigator in using efficient DDoS attack mitigation techniques in a network. This document presents sample use cases for DOTS telemetry. It discusses what components are deployed in the network, how they cooperate, and what information is exchanged to effectively use these techniques.
RFC9386 - IPv6 Deployment Status
This document provides an overview of the status of IPv6 deployment in 2022. Specifically, it looks at the degree of adoption of IPv6 in the industry, analyzes the remaining challenges, and proposes further investigations in areas where the industry has not yet taken a clear and unified approach in the transition to IPv6. It obsoletes RFC 6036.
RFC9385 - Using GOST Cryptographic Algorithms in the Internet Key Exchange Protocol Version 2 (IKEv2)
This document defines a set of cryptographic transforms for use in the Internet Key Exchange Protocol version 2 (IKEv2). The transforms are based on Russian cryptographic standard algorithms (called "GOST" algorithms). Use of GOST ciphers in IKEv2 is defined in RFC 9227. This document aims to define the use of GOST algorithms for the rest of the cryptographic transforms used in IKEv2.
RFC9384 - A BGP Cease NOTIFICATION Subcode for Bidirectional Forwarding Detection (BFD)
The Bidirectional Forwarding Detection (BFD) protocol (RFC 5880) is used to detect loss of connectivity between two forwarding engines, typically with low latency. BFD is leveraged by routing protocols, including the Border Gateway Protocol (BGP), to bring down routing protocol connections more quickly than the original protocol timers.
RFC9383 - SPAKE2+, an Augmented Password-Authenticated Key Exchange (PAKE) Protocol
This document describes SPAKE2+, a Password-Authenticated Key Exchange (PAKE) protocol run between two parties for deriving a strong shared key with no risk of disclosing the password. SPAKE2+ is an augmented PAKE protocol, as only one party has knowledge of the password. This method is simple to implement, compatible with any prime-order group, and computationally efficient.
RFC9382 - SPAKE2, a Password-Authenticated Key Exchange
This document describes SPAKE2, which is a protocol for two parties that share a password to derive a strong shared key without disclosing the password. This method is compatible with any group, is computationally efficient, and has a security proof. This document predated the Crypto Forum Research Group (CFRG) password-authenticated key exchange (PAKE) competition, and it was not selected; however, given existing use of variants in Kerberos and other applications, it was felt that publication was beneficial. Applications that need a symmetric PAKE, but are unable to hash onto an elliptic curve at execution time, can use SPAKE2. This document is a product of the Crypto Forum Research Group in the Internet Research Task Force (IRTF).
RFC9381 - Verifiable Random Functions (VRFs)
A Verifiable Random Function (VRF) is the public key version of a keyed cryptographic hash. Only the holder of the secret key can compute the hash, but anyone with the public key can verify the correctness of the hash. VRFs are useful for preventing enumeration of hash-based data structures. This document specifies VRF constructions based on RSA and elliptic curves that are secure in the cryptographic random oracle model.
RFC9380 - Hashing to Elliptic Curves
This document specifies a number of algorithms for encoding or hashing an arbitrary string to a point on an elliptic curve. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.
RFC9378 - In Situ Operations, Administration, and Maintenance (IOAM) Deployment
In situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document provides a framework for IOAM deployment and provides IOAM deployment considerations and guidance.
RFC9377 - IS-IS Flood Reflection
This document describes a backward-compatible, optional IS-IS extension that allows the creation of IS-IS flood reflection topologies. Flood reflection permits topologies in which IS-IS Level 1 (L1) areas provide transit-forwarding for IS-IS Level 2 (L2) areas using all available L1 nodes internally. It accomplishes this by creating L2 flood reflection adjacencies within each L1 area. Those adjacencies are used to flood L2 Link State Protocol Data Units (LSPs) and are used in the L2 Shortest Path First (SPF) computation. However, they are not ordinarily utilized for forwarding within the flood reflection cluster. This arrangement gives the L2 topology significantly better scaling properties than prevalently used flat designs. As an additional benefit, only those routers directly participating in flood reflection are required to support the feature. This allows for incremental deployment of scalable L1 transit areas in an existing, previously flat network design, without the necessity of upgrading all routers in the network.
RFC9376 - Applicability of GMPLS for beyond 100 Gbit/s Optical Transport Network
This document examines the applicability of using existing GMPLS routing and signaling mechanisms to set up Optical Data Unit-k (ODUk) Label Switched Paths (LSPs) over Optical Data Unit-Cn (ODUCn) links as defined in the 2020 version of ITU-T Recommendation G.709.
RFC9375 - A YANG Data Model for Network and VPN Service Performance Monitoring
The data model for network topologies defined in RFC 8345 introduces vertical layering relationships between networks that can be augmented to cover network and service topologies. This document defines a YANG module for performance monitoring (PM) of both underlay networks and overlay VPN services that can be used to monitor and manage network performance on the topology of both layers.
RFC9374 - DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID (UAS RID)
This document describes the use of Hierarchical Host Identity Tags (HHITs) as self-asserting IPv6 addresses, which makes them trustable identifiers for use in Unmanned Aircraft System Remote Identification (UAS RID) and tracking.
RFC9373 - EdDSA Value for IPSECKEY
This document assigns a value for Edwards-Curve Digital Signature Algorithm (EdDSA) Public Keys to the "IPSECKEY Resource Record Parameters" registry.
RFC9372 - L-Band Digital Aeronautical Communications System (LDACS)
This document gives an overview of the L-band Digital Aeronautical Communications System (LDACS) architecture, which provides a secure, scalable, and spectrum-efficient terrestrial data link for civil aviation. LDACS is a scheduled and reliable multi-application cellular broadband system with support for IPv6. It is part of a larger shift of flight guidance communication moving to IP-based communication. High reliability and availability of IP connectivity over LDACS, as well as security, are therefore essential. The intent of this document is to introduce LDACS to the IETF community, raise awareness on related activities inside and outside of the IETF, and to seek expertise in shaping the shift of aeronautics to IP.
RFC9371 - Registration Procedures for Private Enterprise Numbers (PENs)
This document describes how Private Enterprise Numbers (PENs) are registered by IANA. It shows how to request a new PEN and how to modify a current PEN. It also gives a brief overview of PEN uses.
RFC9370 - Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2)
This document describes how to extend the Internet Key Exchange Protocol Version 2 (IKEv2) to allow multiple key exchanges to take place while computing a shared secret during a Security Association (SA) setup.
RFC9369 - QUIC Version 2
This document specifies QUIC version 2, which is identical to QUIC version 1 except for some trivial details. Its purpose is to combat various ossification vectors and exercise the version negotiation framework. It also serves as a template for the minimum changes in any future version of QUIC.
RFC9368 - Compatible Version Negotiation for QUIC
QUIC does not provide a complete version negotiation mechanism but instead only provides a way for the server to indicate that the version the client chose is unacceptable. This document describes a version negotiation mechanism that allows a client and server to select a mutually supported version. Optionally, if the client's chosen version and the negotiated version share a compatible first flight format, the negotiation can take place without incurring an extra round trip. This document updates RFC 8999.
RFC9367 - GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.3
The purpose of this document is to make the Russian cryptographic standards available to the Internet community for their implementation in the Transport Layer Security (TLS) Protocol Version 1.3.
RFC9366 - Multiple SIP Reason Header Field Values
The SIP Reason header field as defined in RFC 3326 allows only one Reason value per protocol value. Experience with more recently defined protocols shows it is useful to allow multiple values with the same protocol value. This document updates RFC 3326 to allow multiple values for an indicated registered protocol when that protocol defines what the presence of multiple values means.
RFC9365 - IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases
This document discusses the problem statement and use cases of IPv6-based vehicular networking for Intelligent Transportation Systems (ITS). The main scenarios of vehicular communications are vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-everything (V2X) communications. First, this document explains use cases using V2V, V2I, and V2X networking. Next, for IPv6-based vehicular networks, it makes a gap analysis of current IPv6 protocols (e.g., IPv6 Neighbor Discovery, mobility management, as well as security and privacy).
RFC9364 - DNS Security Extensions (DNSSEC)
This document describes the DNS Security Extensions (commonly called "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. A second purpose is to state that using DNSSEC for origin authentication of DNS data is the best current practice. A third purpose is to provide a single reference for other documents that want to refer to DNSSEC.
RFC9363 - A YANG Data Model for Static Context Header Compression (SCHC)
This document describes a YANG data model for the Static Context Header Compression (SCHC) compression and fragmentation Rules.
RFC9362 - Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Configuration Attributes for Robust Block Transmission
This document specifies new DDoS Open Threat Signaling (DOTS) signal channel configuration parameters that can be negotiated between DOTS peers to enable the use of Q-Block1 and Q-Block2 Constrained Application Protocol (CoAP) options. These options enable robust and faster transmission rates for large amounts of data with less packet interchanges as well as support for faster recovery should any of the blocks get lost in transmission (especially during DDoS attacks).
RFC9361 - ICANN Trademark Clearinghouse (TMCH) Functional Specifications
This document describes the requirements, the architecture, and the interfaces between the ICANN Trademark Clearinghouse (TMCH) and Domain Name Registries, as well as between the ICANN TMCH and Domain Name Registrars for the provisioning and management of domain names during Sunrise and Trademark Claims Periods.
RFC9360 - CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing X.509 Certificates
The CBOR Object Signing and Encryption (COSE) message structure uses references to keys in general. For some algorithms, additional properties are defined that carry parameters relating to keys as needed. The COSE Key structure is used for transporting keys outside of COSE messages. This document extends the way that keys can be identified and transported by providing attributes that refer to or contain X.509 certificates.
RFC9359 - Echo Request/Reply for Enabled In Situ OAM (IOAM) Capabilities
This document describes a generic format for use in echo request/reply mechanisms, which can be used within an IOAM-Domain, allowing the IOAM encapsulating node to discover the enabled IOAM capabilities of each IOAM transit and IOAM decapsulating node. The generic format is intended to be used with a variety of data planes such as IPv6, MPLS, Service Function Chain (SFC), and Bit Index Explicit Replication (BIER).
RFC9358 - Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths and Virtual Networks
This document describes how to extend the Path Computation Element Communication Protocol (PCEP) association mechanism introduced by RFC 8697 to further associate sets of Label Switched Paths (LSPs) with a higher-level structure such as a Virtual Network (VN) requested by a customer or application. This extended association mechanism can be used to facilitate control of a VN using the PCE architecture.
RFC9357 - Label Switched Path (LSP) Object Flag Extension for Stateful PCE
RFC 8231 describes a set of extensions to the Path Computation Element Communication Protocol (PCEP) to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP. One of the extensions is the LSP object, which includes a Flag field with a length of 12 bits. However, all bits of the Flag field have already been assigned.
RFC9356 - Advertising Layer 2 Bundle Member Link Attributes in OSPF
There are deployments where the Layer 3 (L3) interface on which OSPF operates is a Layer 2 (L2) interface bundle. Existing OSPF advertisements only support advertising link attributes of the L3 interface. If entities external to OSPF wish to control traffic flows on the individual physical links that comprise the L2 interface bundle, link attribute information for the bundle members is required.
RFC9355 - OSPF Bidirectional Forwarding Detection (BFD) Strict-Mode
This document specifies the extensions to OSPF that enable an OSPF router to signal the requirement for a Bidirectional Forwarding Detection (BFD) session prior to adjacency formation. Link-Local Signaling (LLS) is used to advertise the requirement for strict-mode BFD session establishment for an OSPF adjacency. If both OSPF neighbors advertise BFD strict-mode, adjacency formation will be blocked until a BFD session has been successfully established.
RFC9354 - Transmission of IPv6 Packets over Power Line Communication (PLC) Networks
Power Line Communication (PLC), namely using electric power lines for indoor and outdoor communications, has been widely applied to support Advanced Metering Infrastructure (AMI), especially smart meters for electricity. The existing electricity infrastructure facilitates the expansion of PLC deployments due to its potential advantages in terms of cost and convenience. Moreover, a wide variety of accessible devices raises the potential demand of IPv6 for future applications. This document describes how IPv6 packets are transported over constrained PLC networks, such as those described in ITU-T G.9903, IEEE 1901.1, and IEEE 1901.2.
RFC9353 - IGP Extension for Path Computation Element Communication Protocol (PCEP) Security Capability Support in PCE Discovery (PCED)
When a Path Computation Element (PCE) is a Label Switching Router (LSR) or a server participating in the Interior Gateway Protocol (IGP), its presence and path computation capabilities can be advertised using IGP flooding. The IGP extensions for PCE Discovery (PCED) (RFCs 5088 and 5089) define a method to advertise path computation capabilities using IGP flooding for OSPF and IS-IS, respectively. However, these specifications lack a method to advertise Path Computation Element Communication Protocol (PCEP) security (e.g., Transport Layer Security (TLS) and TCP Authentication Option (TCP-AO)) support capability.
RFC9352 - IS-IS Extensions to Support Segment Routing over the IPv6 Data Plane
The Segment Routing (SR) architecture allows a flexible definition of the end-to-end path by encoding it as a sequence of topological elements called "segments". It can be implemented over the MPLS or the IPv6 data plane. This document describes the IS-IS extensions required to support SR over the IPv6 data plane.
RFC9351 - Border Gateway Protocol - Link State (BGP-LS) Extensions for Flexible Algorithm Advertisement
Flexible Algorithm is a solution that allows some routing protocols (e.g., OSPF and IS-IS) to compute paths over a network based on user-defined (and hence, flexible) constraints and metrics. The computation is performed by routers participating in the specific network in a distributed manner using a Flexible Algorithm Definition (FAD). This definition is provisioned on one or more routers and propagated through the network by OSPF and IS-IS flooding.
RFC9350 - IGP Flexible Algorithm
IGP protocols historically compute the best paths over the network based on the IGP metric assigned to the links. Many network deployments use RSVP-TE or Segment Routing - Traffic Engineering (SR-TE) to steer traffic over a path that is computed using different metrics or constraints than the shortest IGP path. This document specifies a solution that allows IGPs themselves to compute constraint-based paths over the network. This document also specifies a way of using Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets along the constraint-based paths.
RFC9349 - Definitions of Managed Objects for IP Traffic Flow Security
This document describes managed objects for the management of IP Traffic Flow Security additions to Internet Key Exchange Protocol Version 2 (IKEv2) and IPsec. This document provides a read-only version of the objects defined in the YANG module for the same purpose, which is in "A YANG Data Model for IP Traffic Flow Security" (RFC 9348).
RFC9348 - A YANG Data Model for IP Traffic Flow Security
This document describes a YANG module for the management of IP Traffic Flow Security (IP-TFS) additions to Internet Key Exchange Protocol version 2 (IKEv2) and IPsec.
RFC9347 - Aggregation and Fragmentation Mode for Encapsulating Security Payload (ESP) and Its Use for IP Traffic Flow Security (IP-TFS)
This document describes a mechanism for aggregation and fragmentation of IP packets when they are being encapsulated in Encapsulating Security Payload (ESP). This new payload type can be used for various purposes, such as decreasing encapsulation overhead for small IP packets; however, the focus in this document is to enhance IP Traffic Flow Security (IP-TFS) by adding Traffic Flow Confidentiality (TFC) to encrypted IP-encapsulated traffic. TFC is provided by obscuring the size and frequency of IP traffic using a fixed-size, constant-send-rate IPsec tunnel. The solution allows for congestion control, as well as nonconstant send-rate usage.
RFC9346 - IS-IS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering
This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). It defines IS-IS extensions for the flooding of TE information about inter-AS links, which can be used to perform inter-AS TE path computation.
RFC9345 - Delegated Credentials for TLS and DTLS
The organizational separation between operators of TLS and DTLS endpoints and the certification authority can create limitations. For example, the lifetime of certificates, how they may be used, and the algorithms they support are ultimately determined by the Certification Authority (CA). This document describes a mechanism to overcome some of these limitations by enabling operators to delegate their own credentials for use in TLS and DTLS without breaking compatibility with peers that do not support this specification.
RFC9344 - CCNinfo: Discovering Content and Network Information in Content-Centric Networks
This document describes a mechanism named "CCNinfo" that discovers information about the network topology and in-network cache in Content-Centric Networks (CCNs). CCNinfo investigates 1) the CCN routing path information per name prefix, 2) the Round-Trip Time (RTT) between the content forwarder and the consumer, and 3) the states of in-network cache per name prefix. CCNinfo is useful to understand and debug the behavior of testbed networks and other experimental deployments of CCN systems.
RFC9343 - IPv6 Application of the Alternate-Marking Method
This document describes how the Alternate-Marking Method can be used as a passive performance measurement tool in an IPv6 domain. It defines an Extension Header Option to encode Alternate-Marking information in both the Hop-by-Hop Options Header and Destination Options Header.
RFC9342 - Clustered Alternate-Marking Method
This document generalizes and expands the Alternate-Marking methodology to measure any kind of unicast flow whose packets can follow several different paths in the network; this can result in a multipoint-to-multipoint network. The network clustering approach is presented and, for this reason, the technique described here is called "Clustered Alternate Marking". This document obsoletes RFC 8889.
RFC9341 - Alternate-Marking Method
This document describes the Alternate-Marking technique to perform packet loss, delay, and jitter measurements on live traffic. This technology can be applied in various situations and for different protocols. According to the classification defined in RFC 7799, it could be considered Passive or Hybrid depending on the application. This document obsoletes RFC 8321.
This document describes Static Context Header Compression and fragmentation (SCHC) specifications, RFCs 8724 and 8824, in combination with the 3rd Generation Partnership Project (3GPP) and the Narrowband Internet of Things (NB-IoT).
RFC9390 - Diameter Group Signaling
In large network deployments, a single Diameter node can support over a million concurrent Diameter sessions. In some use cases, Diameter nodes need to apply the same operation to a large group of Diameter sessions concurrently. The Diameter base protocol commands operate on a single session so these use cases can result in many thousands of command exchanges enforcing the same operation on each session in the group. In order to reduce signaling, it is desirable to enable bulk operations on all (or part of) the sessions managed by a Diameter node using a single or a few command exchanges. This document specifies the Diameter protocol extensions to achieve this signaling optimization.
RFC9389 - Nominating Committee Eligibility
The IETF Nominating Committee (NomCom) appoints candidates to several IETF leadership committees. RFC 8713 provides criteria for NomCom membership that attempt to ensure NomCom volunteers are members of the loosely defined IETF community, by requiring in-person attendance in three of the past five in-person meetings. In 2020 and 2021, the IETF had six consecutive fully online plenary meetings that drove rapid advancement in remote meeting technologies and procedures, including an experiment that included remote attendance for NomCom eligibility. This document updates RFC 8713 by defining a new set of eligibility criteria from first principles, with consideration to the increased salience of remote attendance. This document obsoletes RFCs 8788 and 8989.
RFC9388 - Content Delivery Network Interconnection (CDNI) Footprint Types: Country Subdivision Code and Footprint Union
Open Caching architecture is a use case of Content Delivery Network Interconnection (CDNI) in which the commercial Content Delivery Network (CDN) is the upstream CDN (uCDN) and the ISP caching layer serves as the downstream CDN (dCDN). RFC 8006 defines footprint types that are used for footprint objects as part of the Metadata interface (MI). The footprint types are also used for the Footprint & Capabilities Advertisement interface (FCI) as defined in RFC 8008. This document defines two new footprint types. The first footprint type defined is an ISO 3166-2 country subdivision code. Defining this country subdivision code improves granularity for delegation as compared to the ISO 3166-1 country code footprint type defined in RFC 8006. The ISO 3166-2 country subdivision code is also added as a new entity domain type in the "ALTO Entity Domain Types" registry defined in Section 7.4 of RFC 9241. The second footprint type defines a footprint union to aggregate footprint objects. This allows for additive semantics over the narrowing semantics defined in Appendix B of RFC 8008 and therefore updates RFC 8008. The two new footprint types are based on the requirements raised by Open Caching but are also applicable to CDNI use cases in general.
RFC9387 - Use Cases for DDoS Open Threat Signaling (DOTS) Telemetry
DDoS Open Threat Signaling (DOTS) telemetry enriches the base DOTS protocols to assist the mitigator in using efficient DDoS attack mitigation techniques in a network. This document presents sample use cases for DOTS telemetry. It discusses what components are deployed in the network, how they cooperate, and what information is exchanged to effectively use these techniques.
RFC9386 - IPv6 Deployment Status
This document provides an overview of the status of IPv6 deployment in 2022. Specifically, it looks at the degree of adoption of IPv6 in the industry, analyzes the remaining challenges, and proposes further investigations in areas where the industry has not yet taken a clear and unified approach in the transition to IPv6. It obsoletes RFC 6036.
RFC9385 - Using GOST Cryptographic Algorithms in the Internet Key Exchange Protocol Version 2 (IKEv2)
This document defines a set of cryptographic transforms for use in the Internet Key Exchange Protocol version 2 (IKEv2). The transforms are based on Russian cryptographic standard algorithms (called "GOST" algorithms). Use of GOST ciphers in IKEv2 is defined in RFC 9227. This document aims to define the use of GOST algorithms for the rest of the cryptographic transforms used in IKEv2.
RFC9384 - A BGP Cease NOTIFICATION Subcode for Bidirectional Forwarding Detection (BFD)
The Bidirectional Forwarding Detection (BFD) protocol (RFC 5880) is used to detect loss of connectivity between two forwarding engines, typically with low latency. BFD is leveraged by routing protocols, including the Border Gateway Protocol (BGP), to bring down routing protocol connections more quickly than the original protocol timers.
RFC9383 - SPAKE2+, an Augmented Password-Authenticated Key Exchange (PAKE) Protocol
This document describes SPAKE2+, a Password-Authenticated Key Exchange (PAKE) protocol run between two parties for deriving a strong shared key with no risk of disclosing the password. SPAKE2+ is an augmented PAKE protocol, as only one party has knowledge of the password. This method is simple to implement, compatible with any prime-order group, and computationally efficient.
RFC9382 - SPAKE2, a Password-Authenticated Key Exchange
This document describes SPAKE2, which is a protocol for two parties that share a password to derive a strong shared key without disclosing the password. This method is compatible with any group, is computationally efficient, and has a security proof. This document predated the Crypto Forum Research Group (CFRG) password-authenticated key exchange (PAKE) competition, and it was not selected; however, given existing use of variants in Kerberos and other applications, it was felt that publication was beneficial. Applications that need a symmetric PAKE, but are unable to hash onto an elliptic curve at execution time, can use SPAKE2. This document is a product of the Crypto Forum Research Group in the Internet Research Task Force (IRTF).
RFC9381 - Verifiable Random Functions (VRFs)
A Verifiable Random Function (VRF) is the public key version of a keyed cryptographic hash. Only the holder of the secret key can compute the hash, but anyone with the public key can verify the correctness of the hash. VRFs are useful for preventing enumeration of hash-based data structures. This document specifies VRF constructions based on RSA and elliptic curves that are secure in the cryptographic random oracle model.
RFC9380 - Hashing to Elliptic Curves
This document specifies a number of algorithms for encoding or hashing an arbitrary string to a point on an elliptic curve. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.
RFC9378 - In Situ Operations, Administration, and Maintenance (IOAM) Deployment
In situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document provides a framework for IOAM deployment and provides IOAM deployment considerations and guidance.
RFC9377 - IS-IS Flood Reflection
This document describes a backward-compatible, optional IS-IS extension that allows the creation of IS-IS flood reflection topologies. Flood reflection permits topologies in which IS-IS Level 1 (L1) areas provide transit-forwarding for IS-IS Level 2 (L2) areas using all available L1 nodes internally. It accomplishes this by creating L2 flood reflection adjacencies within each L1 area. Those adjacencies are used to flood L2 Link State Protocol Data Units (LSPs) and are used in the L2 Shortest Path First (SPF) computation. However, they are not ordinarily utilized for forwarding within the flood reflection cluster. This arrangement gives the L2 topology significantly better scaling properties than prevalently used flat designs. As an additional benefit, only those routers directly participating in flood reflection are required to support the feature. This allows for incremental deployment of scalable L1 transit areas in an existing, previously flat network design, without the necessity of upgrading all routers in the network.
RFC9376 - Applicability of GMPLS for beyond 100 Gbit/s Optical Transport Network
This document examines the applicability of using existing GMPLS routing and signaling mechanisms to set up Optical Data Unit-k (ODUk) Label Switched Paths (LSPs) over Optical Data Unit-Cn (ODUCn) links as defined in the 2020 version of ITU-T Recommendation G.709.
RFC9375 - A YANG Data Model for Network and VPN Service Performance Monitoring
The data model for network topologies defined in RFC 8345 introduces vertical layering relationships between networks that can be augmented to cover network and service topologies. This document defines a YANG module for performance monitoring (PM) of both underlay networks and overlay VPN services that can be used to monitor and manage network performance on the topology of both layers.
RFC9374 - DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID (UAS RID)
This document describes the use of Hierarchical Host Identity Tags (HHITs) as self-asserting IPv6 addresses, which makes them trustable identifiers for use in Unmanned Aircraft System Remote Identification (UAS RID) and tracking.
RFC9373 - EdDSA Value for IPSECKEY
This document assigns a value for Edwards-Curve Digital Signature Algorithm (EdDSA) Public Keys to the "IPSECKEY Resource Record Parameters" registry.
RFC9372 - L-Band Digital Aeronautical Communications System (LDACS)
This document gives an overview of the L-band Digital Aeronautical Communications System (LDACS) architecture, which provides a secure, scalable, and spectrum-efficient terrestrial data link for civil aviation. LDACS is a scheduled and reliable multi-application cellular broadband system with support for IPv6. It is part of a larger shift of flight guidance communication moving to IP-based communication. High reliability and availability of IP connectivity over LDACS, as well as security, are therefore essential. The intent of this document is to introduce LDACS to the IETF community, raise awareness on related activities inside and outside of the IETF, and to seek expertise in shaping the shift of aeronautics to IP.
RFC9371 - Registration Procedures for Private Enterprise Numbers (PENs)
This document describes how Private Enterprise Numbers (PENs) are registered by IANA. It shows how to request a new PEN and how to modify a current PEN. It also gives a brief overview of PEN uses.
RFC9370 - Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2)
This document describes how to extend the Internet Key Exchange Protocol Version 2 (IKEv2) to allow multiple key exchanges to take place while computing a shared secret during a Security Association (SA) setup.
RFC9369 - QUIC Version 2
This document specifies QUIC version 2, which is identical to QUIC version 1 except for some trivial details. Its purpose is to combat various ossification vectors and exercise the version negotiation framework. It also serves as a template for the minimum changes in any future version of QUIC.
RFC9368 - Compatible Version Negotiation for QUIC
QUIC does not provide a complete version negotiation mechanism but instead only provides a way for the server to indicate that the version the client chose is unacceptable. This document describes a version negotiation mechanism that allows a client and server to select a mutually supported version. Optionally, if the client's chosen version and the negotiated version share a compatible first flight format, the negotiation can take place without incurring an extra round trip. This document updates RFC 8999.
RFC9367 - GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.3
The purpose of this document is to make the Russian cryptographic standards available to the Internet community for their implementation in the Transport Layer Security (TLS) Protocol Version 1.3.
RFC9366 - Multiple SIP Reason Header Field Values
The SIP Reason header field as defined in RFC 3326 allows only one Reason value per protocol value. Experience with more recently defined protocols shows it is useful to allow multiple values with the same protocol value. This document updates RFC 3326 to allow multiple values for an indicated registered protocol when that protocol defines what the presence of multiple values means.
RFC9365 - IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases
This document discusses the problem statement and use cases of IPv6-based vehicular networking for Intelligent Transportation Systems (ITS). The main scenarios of vehicular communications are vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-everything (V2X) communications. First, this document explains use cases using V2V, V2I, and V2X networking. Next, for IPv6-based vehicular networks, it makes a gap analysis of current IPv6 protocols (e.g., IPv6 Neighbor Discovery, mobility management, as well as security and privacy).
RFC9364 - DNS Security Extensions (DNSSEC)
This document describes the DNS Security Extensions (commonly called "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. A second purpose is to state that using DNSSEC for origin authentication of DNS data is the best current practice. A third purpose is to provide a single reference for other documents that want to refer to DNSSEC.
RFC9363 - A YANG Data Model for Static Context Header Compression (SCHC)
This document describes a YANG data model for the Static Context Header Compression (SCHC) compression and fragmentation Rules.
RFC9362 - Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Configuration Attributes for Robust Block Transmission
This document specifies new DDoS Open Threat Signaling (DOTS) signal channel configuration parameters that can be negotiated between DOTS peers to enable the use of Q-Block1 and Q-Block2 Constrained Application Protocol (CoAP) options. These options enable robust and faster transmission rates for large amounts of data with less packet interchanges as well as support for faster recovery should any of the blocks get lost in transmission (especially during DDoS attacks).
RFC9361 - ICANN Trademark Clearinghouse (TMCH) Functional Specifications
This document describes the requirements, the architecture, and the interfaces between the ICANN Trademark Clearinghouse (TMCH) and Domain Name Registries, as well as between the ICANN TMCH and Domain Name Registrars for the provisioning and management of domain names during Sunrise and Trademark Claims Periods.
RFC9360 - CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing X.509 Certificates
The CBOR Object Signing and Encryption (COSE) message structure uses references to keys in general. For some algorithms, additional properties are defined that carry parameters relating to keys as needed. The COSE Key structure is used for transporting keys outside of COSE messages. This document extends the way that keys can be identified and transported by providing attributes that refer to or contain X.509 certificates.
RFC9359 - Echo Request/Reply for Enabled In Situ OAM (IOAM) Capabilities
This document describes a generic format for use in echo request/reply mechanisms, which can be used within an IOAM-Domain, allowing the IOAM encapsulating node to discover the enabled IOAM capabilities of each IOAM transit and IOAM decapsulating node. The generic format is intended to be used with a variety of data planes such as IPv6, MPLS, Service Function Chain (SFC), and Bit Index Explicit Replication (BIER).
RFC9358 - Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths and Virtual Networks
This document describes how to extend the Path Computation Element Communication Protocol (PCEP) association mechanism introduced by RFC 8697 to further associate sets of Label Switched Paths (LSPs) with a higher-level structure such as a Virtual Network (VN) requested by a customer or application. This extended association mechanism can be used to facilitate control of a VN using the PCE architecture.
RFC9357 - Label Switched Path (LSP) Object Flag Extension for Stateful PCE
RFC 8231 describes a set of extensions to the Path Computation Element Communication Protocol (PCEP) to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP. One of the extensions is the LSP object, which includes a Flag field with a length of 12 bits. However, all bits of the Flag field have already been assigned.
RFC9356 - Advertising Layer 2 Bundle Member Link Attributes in OSPF
There are deployments where the Layer 3 (L3) interface on which OSPF operates is a Layer 2 (L2) interface bundle. Existing OSPF advertisements only support advertising link attributes of the L3 interface. If entities external to OSPF wish to control traffic flows on the individual physical links that comprise the L2 interface bundle, link attribute information for the bundle members is required.
RFC9355 - OSPF Bidirectional Forwarding Detection (BFD) Strict-Mode
This document specifies the extensions to OSPF that enable an OSPF router to signal the requirement for a Bidirectional Forwarding Detection (BFD) session prior to adjacency formation. Link-Local Signaling (LLS) is used to advertise the requirement for strict-mode BFD session establishment for an OSPF adjacency. If both OSPF neighbors advertise BFD strict-mode, adjacency formation will be blocked until a BFD session has been successfully established.
RFC9354 - Transmission of IPv6 Packets over Power Line Communication (PLC) Networks
Power Line Communication (PLC), namely using electric power lines for indoor and outdoor communications, has been widely applied to support Advanced Metering Infrastructure (AMI), especially smart meters for electricity. The existing electricity infrastructure facilitates the expansion of PLC deployments due to its potential advantages in terms of cost and convenience. Moreover, a wide variety of accessible devices raises the potential demand of IPv6 for future applications. This document describes how IPv6 packets are transported over constrained PLC networks, such as those described in ITU-T G.9903, IEEE 1901.1, and IEEE 1901.2.
RFC9353 - IGP Extension for Path Computation Element Communication Protocol (PCEP) Security Capability Support in PCE Discovery (PCED)
When a Path Computation Element (PCE) is a Label Switching Router (LSR) or a server participating in the Interior Gateway Protocol (IGP), its presence and path computation capabilities can be advertised using IGP flooding. The IGP extensions for PCE Discovery (PCED) (RFCs 5088 and 5089) define a method to advertise path computation capabilities using IGP flooding for OSPF and IS-IS, respectively. However, these specifications lack a method to advertise Path Computation Element Communication Protocol (PCEP) security (e.g., Transport Layer Security (TLS) and TCP Authentication Option (TCP-AO)) support capability.
RFC9352 - IS-IS Extensions to Support Segment Routing over the IPv6 Data Plane
The Segment Routing (SR) architecture allows a flexible definition of the end-to-end path by encoding it as a sequence of topological elements called "segments". It can be implemented over the MPLS or the IPv6 data plane. This document describes the IS-IS extensions required to support SR over the IPv6 data plane.
RFC9351 - Border Gateway Protocol - Link State (BGP-LS) Extensions for Flexible Algorithm Advertisement
Flexible Algorithm is a solution that allows some routing protocols (e.g., OSPF and IS-IS) to compute paths over a network based on user-defined (and hence, flexible) constraints and metrics. The computation is performed by routers participating in the specific network in a distributed manner using a Flexible Algorithm Definition (FAD). This definition is provisioned on one or more routers and propagated through the network by OSPF and IS-IS flooding.
RFC9350 - IGP Flexible Algorithm
IGP protocols historically compute the best paths over the network based on the IGP metric assigned to the links. Many network deployments use RSVP-TE or Segment Routing - Traffic Engineering (SR-TE) to steer traffic over a path that is computed using different metrics or constraints than the shortest IGP path. This document specifies a solution that allows IGPs themselves to compute constraint-based paths over the network. This document also specifies a way of using Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets along the constraint-based paths.
RFC9349 - Definitions of Managed Objects for IP Traffic Flow Security
This document describes managed objects for the management of IP Traffic Flow Security additions to Internet Key Exchange Protocol Version 2 (IKEv2) and IPsec. This document provides a read-only version of the objects defined in the YANG module for the same purpose, which is in "A YANG Data Model for IP Traffic Flow Security" (RFC 9348).
RFC9348 - A YANG Data Model for IP Traffic Flow Security
This document describes a YANG module for the management of IP Traffic Flow Security (IP-TFS) additions to Internet Key Exchange Protocol version 2 (IKEv2) and IPsec.
RFC9347 - Aggregation and Fragmentation Mode for Encapsulating Security Payload (ESP) and Its Use for IP Traffic Flow Security (IP-TFS)
This document describes a mechanism for aggregation and fragmentation of IP packets when they are being encapsulated in Encapsulating Security Payload (ESP). This new payload type can be used for various purposes, such as decreasing encapsulation overhead for small IP packets; however, the focus in this document is to enhance IP Traffic Flow Security (IP-TFS) by adding Traffic Flow Confidentiality (TFC) to encrypted IP-encapsulated traffic. TFC is provided by obscuring the size and frequency of IP traffic using a fixed-size, constant-send-rate IPsec tunnel. The solution allows for congestion control, as well as nonconstant send-rate usage.
RFC9346 - IS-IS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering
This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). It defines IS-IS extensions for the flooding of TE information about inter-AS links, which can be used to perform inter-AS TE path computation.
RFC9345 - Delegated Credentials for TLS and DTLS
The organizational separation between operators of TLS and DTLS endpoints and the certification authority can create limitations. For example, the lifetime of certificates, how they may be used, and the algorithms they support are ultimately determined by the Certification Authority (CA). This document describes a mechanism to overcome some of these limitations by enabling operators to delegate their own credentials for use in TLS and DTLS without breaking compatibility with peers that do not support this specification.
RFC9344 - CCNinfo: Discovering Content and Network Information in Content-Centric Networks
This document describes a mechanism named "CCNinfo" that discovers information about the network topology and in-network cache in Content-Centric Networks (CCNs). CCNinfo investigates 1) the CCN routing path information per name prefix, 2) the Round-Trip Time (RTT) between the content forwarder and the consumer, and 3) the states of in-network cache per name prefix. CCNinfo is useful to understand and debug the behavior of testbed networks and other experimental deployments of CCN systems.
RFC9343 - IPv6 Application of the Alternate-Marking Method
This document describes how the Alternate-Marking Method can be used as a passive performance measurement tool in an IPv6 domain. It defines an Extension Header Option to encode Alternate-Marking information in both the Hop-by-Hop Options Header and Destination Options Header.
RFC9342 - Clustered Alternate-Marking Method
This document generalizes and expands the Alternate-Marking methodology to measure any kind of unicast flow whose packets can follow several different paths in the network; this can result in a multipoint-to-multipoint network. The network clustering approach is presented and, for this reason, the technique described here is called "Clustered Alternate Marking". This document obsoletes RFC 8889.
RFC9341 - Alternate-Marking Method
This document describes the Alternate-Marking technique to perform packet loss, delay, and jitter measurements on live traffic. This technology can be applied in various situations and for different protocols. According to the classification defined in RFC 7799, it could be considered Passive or Hybrid depending on the application. This document obsoletes RFC 8321.