| |
| RFC 9300 | The Locator/ID Separation Protocol (LISP) |
| |
| Authors: | D. Farinacci, V. Fuller, D. Meyer, D. Lewis, A. Cabellos, Ed.. |
| Date: | October 2022 |
| Formats: | txt json pdf xml html |
| Obsoletes: | RFC 6830 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9300 |
|
This document describes the data plane protocol for the Locator/IDSeparation Protocol (LISP). LISP defines two namespaces: EndpointIdentifiers (EIDs), which identify end hosts; and Routing Locators(RLOCs), which identify network attachment points. With this, LISP effectively separates control from data and allows routers to create overlay networks. LISP-capable routers exchange encapsulated packets according to EID-to-RLOC mappings stored in a local Map-Cache.
LISP requires no change to either host protocol stacks or underlay routers and offers Traffic Engineering (TE), multihoming, and mobility, among other features.
This document obsoletes RFC 6830. |
|
| |
| RFC 9301 | Locator/ID Separation Protocol (LISP) Control Plane |
| |
|
|
This document describes the control plane and Mapping Service for theLocator/ID Separation Protocol (LISP), implemented by two types ofLISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provide a simplified "front end" for one or more Endpoint IDs(EIDs) to Routing Locator mapping databases.
By using this control plane service interface and communicating withMap-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) andEgress Tunnel Routers (ETRs) are not dependent on the details of mapping database systems; this behavior facilitates modularity with different database designs. Since these devices implement the "edge" of the LISP control plane infrastructure, connecting EID addressable nodes of a LISP site, the implementation and operational complexity of the overall cost and effort of deploying LISP is reduced.
This document obsoletes RFCs 6830 and 6833. |
|
| |
| RFC 9302 | Locator/ID Separation Protocol (LISP) Map-Versioning |
| |
|
|
This document describes the Locator/ID Separation Protocol (LISP)Map-Versioning mechanism, which provides in-packet information aboutEndpoint-ID-to-Routing-Locator (EID-to-RLOC) mappings used to encapsulate LISP data packets. This approach is based on associating a version number to EID-to-RLOC mappings and transporting such a version number in the LISP-specific header of LISP-encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers(ETRs) about modifications of the mappings used to encapsulate packets. The mechanism is optional and transparent to implementations not supporting this feature, since in the LISP- specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by ITRs and ETRs that do not support or do not want to use the mechanism.
This document obsoletes RFC 6834, which is the initial experimental specifications of the mechanisms updated by this document. |
|
| |
| RFC 9303 | Locator/ID Separation Protocol Security (LISP-SEC) |
| |
| Authors: | F. Maino, V. Ermagan, A. Cabellos, D. Saucez. |
| Date: | October 2022 |
| Formats: | txt xml pdf html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9303 |
|
This memo specifies Locator/ID Separation Protocol Security (LISP-SEC), a set of security mechanisms that provides origin authentication, integrity, and anti-replay protection to the LISP'sEndpoint-ID-to-Routing-Locator (EID-to-RLOC) mapping data conveyed via the mapping lookup process. LISP-SEC also enables verification of authorization on EID-Prefix claims in Map-Reply messages. |
|
| |
| RFC 9304 | Locator/ID Separation Protocol (LISP): Shared Extension Message and IANA Registry for Packet Type Allocations |
| |
|
|
This document specifies a Locator/ID Separation Protocol (LISP) shared message type for defining future extensions and conducting experiments without consuming a LISP Packet Type codepoint for each extension.
This document obsoletes RFC 8113. |
|
| |
| RFC 9305 | Locator/ID Separation Protocol (LISP) Generic Protocol Extension |
| |
| Authors: | F. Maino, Ed., J. Lemon, P. Agarwal, D. Lewis, M. Smith. |
| Date: | October 2022 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9305 |
|
This document describes extensions to the Locator/ID SeparationProtocol (LISP) data plane, via changes to the LISP header, to support multiprotocol encapsulation and allow the introduction of new protocol capabilities. |
|
| |
| RFC 9306 | Vendor-Specific LISP Canonical Address Format (LCAF) |
| |
| Authors: | A. Rodriguez-Natal, V. Ermagan, A. Smirnov, V. Ashtaputre, D. Farinacci. |
| Date: | October 2022 |
| Formats: | txt html pdf xml json |
| Updates: | RFC 8060 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9306 |
|
This document describes a new Locator/ID Separation Protocol (LISP)Canonical Address Format (LCAF), the Vendor-Specific LCAF. This LCAF enables organizations to have implementation-specific encodings forLCAF addresses. This document updates RFC 8060. |
|
| |
| RFC 9307 | Report from the IAB Workshop on Analyzing IETF Data (AID) 2021 |
| |
| Authors: | N. ten Oever, C. Cath, M. Kühlewind, C. S. Perkins. |
| Date: | September 2022 |
| Formats: | txt html json pdf xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9307 |
|
The "Show me the numbers: Workshop on Analyzing IETF Data (AID)" workshop was convened by the Internet Architecture Board (IAB) fromNovember 29 to December 2, 2021 and hosted by the IN-SIGHT.it project at the University of Amsterdam; however, it was converted to an online-only event. The workshop was organized into two discussion parts with a hackathon activity in between. This report summarizes the workshop's discussion and identifies topics that warrant future work and consideration.
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions. |
|
| |
| RFC 9308 | Applicability of the QUIC Transport Protocol |
| |
| Authors: | M. Kühlewind, B. Trammell. |
| Date: | September 2022 |
| Formats: | txt json pdf xml html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9308 |
|
This document discusses the applicability of the QUIC transport protocol, focusing on caveats impacting application protocol development and deployment over QUIC. Its intended audience is designers of application protocol mappings to QUIC and implementors of these application protocols. |
|
| |
| RFC 9309 | Robots Exclusion Protocol |
| |
| Authors: | M. Koster, G. Illyes, H. Zeller, L. Sassman. |
| Date: | September 2022 |
| Formats: | txt json html pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9309 |
|
This document specifies and extends the "Robots Exclusion Protocol" method originally defined by Martijn Koster in 1994 for service owners to control how content served by their services may be accessed, if at all, by automatic clients known as crawlers.Specifically, it adds definition language for the protocol, instructions for handling errors, and instructions for caching. |
|
| |
| RFC 9310 | X.509 Certificate Extension for 5G Network Function Types |
| |
| Authors: | R. Housley, S. Turner, J. Preuß Mattsson, D. Migault. |
| Date: | January 2023 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9310 |
|
This document specifies the certificate extension for includingNetwork Function Types (NFTypes) for the 5G System in X.509 v3 public key certificates as profiled in RFC 5280. |
|
| |
| RFC 9311 | Running an IETF Hackathon |
| |
|
|
IETF Hackathons encourage the IETF community to collaborate on running code related to existing and evolving Internet standards.This document provides a set of practices that have been used for running IETF Hackathons. These practices apply to Hackathons in which both in-person and remote participation are possible, with adaptations for Hackathons that are online only. |
|
| |
| RFC 9312 | Manageability of the QUIC Transport Protocol |
| |
| Authors: | M. Kühlewind, B. Trammell. |
| Date: | September 2022 |
| Formats: | txt html pdf xml json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9312 |
|
This document discusses manageability of the QUIC transport protocol and focuses on the implications of QUIC's design and wire image on network operations involving QUIC traffic. It is intended as a"user's manual" for the wire image to provide guidance for network operators and equipment vendors who rely on the use of transport- aware network functions. |
|
| |
| RFC 9313 | Pros and Cons of IPv6 Transition Technologies for IPv4-as-a-Service (IPv4aaS) |
| |
| Authors: | G. Lencse, J. Palet Martinez, L. Howard, R. Patterson, I. Farrer. |
| Date: | October 2022 |
| Formats: | txt pdf xml html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9313 |
|
Several IPv6 transition technologies have been developed to provide customers with IPv4-as-a-Service (IPv4aaS) for ISPs with an IPv6-only access and/or core network. These technologies have their advantages and disadvantages. Depending on existing topology, skills, strategy, and other preferences, one of these technologies may be the most appropriate solution for a network operator.
This document examines the five most prominent IPv4aaS technologies and considers a number of different aspects to provide network operators with an easy-to-use reference to assist in selecting the technology that best suits their needs. |
|
| |
| RFC 9314 | YANG Data Model for Bidirectional Forwarding Detection (BFD) |
| |
| Authors: | M. Jethanandani, Ed., R. Rahman, Ed., L. Zheng, Ed., S. Pallagatti, G. Mirsky. |
| Date: | September 2022 |
| Formats: | txt json pdf xml html |
| Updates: | RFC 9127 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9314 |
|
This document defines a YANG data model that can be used to configure and manage Bidirectional Forwarding Detection (BFD).
The YANG modules in this document conform to the Network ManagementDatastore Architecture (NMDA) (RFC 8342). This document updates"YANG Data Model for Bidirectional Forwarding Detection (BFD)" (RFC9127). |
|
| |
| RFC 9315 | Intent-Based Networking - Concepts and Definitions |
| |
| Authors: | A. Clemm, L. Ciavaglia, L. Z. Granville, J. Tantsura. |
| Date: | October 2022 |
| Formats: | txt pdf xml json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9315 |
|
Intent and Intent-Based Networking are taking the industry by storm.At the same time, terms related to Intent-Based Networking are often used loosely and inconsistently, in many cases overlapping and confused with other concepts such as "policy." This document clarifies the concept of "intent" and provides an overview of the functionality that is associated with it. The goal is to contribute towards a common and shared understanding of terms, concepts, and functionality that can be used as the foundation to guide further definition of associated research and engineering problems and their solutions.
This document is a product of the IRTF Network Management ResearchGroup (NMRG). It reflects the consensus of the research group, having received many detailed and positive reviews by research group participants. It is published for informational purposes. |
|
| |
| RFC 9316 | Intent Classification |
| |
| Authors: | C. Li, O. Havel, A. Olariu, P. Martinez-Julia, J. Nobre, D. Lopez. |
| Date: | October 2022 |
| Formats: | txt html json xml pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9316 |
|
Intent is an abstract, high-level policy used to operate a network.An intent-based management system includes an interface for users to input requests and an engine to translate the intents into the network configuration and manage their life cycle.
This document mostly discusses the concept of network intents, but other types of intents are also considered. Specifically, this document highlights stakeholder perspectives of intent, methods to classify and encode intent, and the associated intent taxonomy; it also defines relevant intent terms where necessary, provides a foundation for intent-related research, and facilitates solution development.
This document is a product of the IRTF Network Management ResearchGroup (NMRG). |
|
| |
| RFC 9317 | Operational Considerations for Streaming Media |
| |
| Authors: | J. Holland, A. Begen, S. Dawkins. |
| Date: | October 2022 |
| Formats: | txt html xml json pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9317 |
|
This document provides an overview of operational networking and transport protocol issues that pertain to the quality of experience(QoE) when streaming video and other high-bitrate media over theInternet.
This document explains the characteristics of streaming media delivery that have surprised network designers or transport experts who lack specific media expertise, since streaming media highlights key differences between common assumptions in existing networking practices and observations of media delivery issues encountered when streaming media over those existing networks. |
|
| |
| RFC 9318 | IAB Workshop Report: Measuring Network Quality for End-Users |
| |
|
|
The Measuring Network Quality for End-Users workshop was held virtually by the Internet Architecture Board (IAB) on September14-16, 2021. This report summarizes the workshop, the topics discussed, and some preliminary conclusions drawn at the end of the workshop.
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions. |
|
| |
| RFC 9319 | The Use of maxLength in the Resource Public Key Infrastructure (RPKI) |
| |
| Authors: | Y. Gilad, S. Goldberg, K. Sriram, J. Snijders, B. Maddison. |
| Date: | October 2022 |
| Formats: | txt json html xml pdf |
| Also: | BCP 0185 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 9319 |
|
This document recommends ways to reduce the forged-origin hijack attack surface by prudently limiting the set of IP prefixes that are included in a Route Origin Authorization (ROA). One recommendation is to avoid using the maxLength attribute in ROAs except in some specific cases. The recommendations complement and extend those inRFC 7115. This document also discusses the creation of ROAs for facilitating the use of Distributed Denial of Service (DDoS) mitigation services. Considerations related to ROAs and RPKI-basedRoute Origin Validation (RPKI-ROV) in the context of destination- based Remotely Triggered Discard Route (RTDR) (elsewhere referred to as "Remotely Triggered Black Hole") filtering are also highlighted. |
|
| |
| RFC 9320 | Deterministic Networking (DetNet) Bounded Latency |
| |
| Authors: | N. Finn, J.-Y. Le Boudec, E. Mohammadpour, J. Zhang, B. Varga. |
| Date: | November 2022 |
| Formats: | txt pdf xml json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9320 |
|
This document presents a timing model for sources, destinations, andDeterministic Networking (DetNet) transit nodes. Using the model, it provides a methodology to compute end-to-end latency and backlog bounds for various queuing methods. The methodology can be used by the management and control planes and by resource reservation algorithms to provide bounded latency and zero congestion loss for the DetNet service. |
|
| |
| RFC 9321 | Signature Validation Token |
| |
|
|
Electronic signatures have a limited lifespan with respect to the time period that they can be validated and determined to be authentic. The Signature Validation Token (SVT) defined in this specification provides evidence that asserts the validity of an electronic signature. The SVT is provided by a trusted authority, which asserts that a particular signature was successfully validated according to defined procedures at a certain time. Any future validation of that electronic signature can be satisfied by validating the SVT without any need to also validate the original electronic signature or the associated digital certificates. The SVT supports electronic signatures in Cryptographic Message Syntax (CMS),XML, PDF, and JSON documents. |
|
| |
| RFC 9322 | In Situ Operations, Administration, and Maintenance (IOAM) Loopback and Active Flags |
| |
| Authors: | T. Mizrahi, F. Brockners, S. Bhandari, B. Gafni, M. Spiegel. |
| Date: | November 2022 |
| Formats: | txt html xml json pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9322 |
|
In situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in packets while they traverse a path between two points in the network. This document defines two new flags in the IOAM Trace Option headers, specifically the Loopback and Active flags. |
|
| |
| RFC 9323 | A Profile for RPKI Signed Checklists (RSCs) |
| |
| Authors: | J. Snijders, T. Harrison, B. Maddison. |
| Date: | November 2022 |
| Formats: | txt html xml json pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9323 |
|
This document defines a Cryptographic Message Syntax (CMS) protected content type for use with the Resource Public Key Infrastructure(RPKI) to carry a general-purpose listing of checksums (a'checklist'). The objective is to allow for the creation of an attestation, termed an "RPKI Signed Checklist (RSC)", which contains one or more checksums of arbitrary digital objects (files) that are signed with a specific set of Internet Number Resources. When validated, an RSC confirms that the respective Internet resource holder produced the RSC. |
|
| |
| RFC 9324 | Policy Based on the Resource Public Key Infrastructure (RPKI) without Route Refresh |
| |
|
|
A BGP speaker performing policy based on the Resource Public KeyInfrastructure (RPKI) should not issue route refresh to its neighbors because it has received new RPKI data. This document updates RFC8481 by describing how to avoid doing so by either keeping a fullAdj-RIB-In or saving paths dropped due to ROV (Route OriginValidation) so they may be reevaluated with respect to new RPKI data. |
|
| |
| RFC 9325 | Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) |
| |
|
|
Transport Layer Security (TLS) and Datagram Transport Layer Security(DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases.
RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 in view of recent attacks. |
|
| |
| RFC 9326 | In Situ Operations, Administration, and Maintenance (IOAM) Direct Exporting |
| |
| Authors: | H. Song, B. Gafni, F. Brockners, S. Bhandari, T. Mizrahi. |
| Date: | November 2022 |
| Formats: | txt pdf xml html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9326 |
|
In situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information.Specifically, IOAM allows telemetry data to be pushed into data packets while they traverse the network. This document introduces a new IOAM option type (denoted IOAM-Option-Type) called the "IOAMDirect Export (DEX) Option-Type". This Option-Type is used as a trigger for IOAM data to be directly exported or locally aggregated without being pushed into in-flight data packets. The exporting method and format are outside the scope of this document. |
|
| |
| RFC 9327 | Control Messages Protocol for Use with Network Time Protocol Version 4 |
| |
|
|
This document describes the structure of the control messages that were historically used with the Network Time Protocol (NTP) before the advent of more modern control and management approaches. These control messages have been used to monitor and control the NTP application running on any IP network attached computer. The information in this document was originally described in Appendix B of RFC 1305. The goal of this document is to provide an updated description of the control messages described in RFC 1305 in order to conform with the updated NTP specification documented in RFC 5905.
The publication of this document is not meant to encourage the development and deployment of these control messages. This document is only providing a current reference for these control messages given the current status of RFC 1305. |
|
| |
| RFC 9328 | RTP Payload Format for Versatile Video Coding (VVC) |
| |
| Authors: | S. Zhao, S. Wenger, Y. Sanchez, Y.-K. Wang, M. M Hannuksela. |
| Date: | December 2022 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9328 |
|
This memo describes an RTP payload format for the Versatile VideoCoding (VVC) specification, which was published as both ITU-TRecommendation H.266 and ISO/IEC International Standard 23090-3. VVC was developed by the Joint Video Experts Team (JVET). The RTP payload format allows for packetization of one or more NetworkAbstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit into multiple RTP packets. The payload format has wide applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among other applications. |
|
| |
| RFC 9329 | TCP Encapsulation of Internet Key Exchange Protocol (IKE) and IPsec Packets |
| |
|
|
This document describes a method to transport Internet Key ExchangeProtocol (IKE) and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as "TCP encapsulation", involves sending both IKE packets for Security Association (SA) establishment and EncapsulatingSecurity Payload (ESP) packets over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP.
TCP encapsulation for IKE and IPsec was defined in RFC 8229. This document clarifies the specification for TCP encapsulation by including additional clarifications obtained during implementation and deployment of this method. This documents obsoletes RFC 8229. |
|
| |
| RFC 9330 | Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture |
| |
| Authors: | B. Briscoe, Ed., K. De Schepper, M. Bagnulo, G. White. |
| Date: | January 2023 |
| Formats: | txt xml json pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9330 |
|
This document describes the L4S architecture, which enables Internet applications to achieve low queuing latency, low congestion loss, and scalable throughput control. L4S is based on the insight that the root cause of queuing delay is in the capacity-seeking congestion controllers of senders, not in the queue itself. With the L4S architecture, all Internet applications could (but do not have to) transition away from congestion control algorithms that cause substantial queuing delay and instead adopt a new class of congestion controls that can seek capacity with very little queuing. These are aided by a modified form of Explicit Congestion Notification (ECN) from the network. With this new architecture, applications can have both low latency and high throughput.
The architecture primarily concerns incremental deployment. It defines mechanisms that allow the new class of L4S congestion controls to coexist with 'Classic' congestion controls in a shared network. The aim is for L4S latency and throughput to be usually much better (and rarely worse) while typically not impacting Classic performance. |
|
| |
| RFC 9331 | The Explicit Congestion Notification (ECN) Protocol for Low Latency, Low Loss, and Scalable Throughput (L4S) |
| |
| Authors: | K. De Schepper, B. Briscoe, Ed.. |
| Date: | January 2023 |
| Formats: | txt xml json pdf html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9331 |
|
This specification defines the protocol to be used for a new network service called Low Latency, Low Loss, and Scalable throughput (L4S).L4S uses an Explicit Congestion Notification (ECN) scheme at the IP layer that is similar to the original (or 'Classic') ECN approach, except as specified within. L4S uses 'Scalable' congestion control, which induces much more frequent control signals from the network, and it responds to them with much more fine-grained adjustments so that very low (typically sub-millisecond on average) and consistently low queuing delay becomes possible for L4S traffic without compromising link utilization. Thus, even capacity-seeking (TCP- like) traffic can have high bandwidth and very low delay at the same time, even during periods of high traffic load.
The L4S identifier defined in this document distinguishes L4S from'Classic' (e.g., TCP-Reno-friendly) traffic. Then, network bottlenecks can be incrementally modified to distinguish and isolate existing traffic that still follows the Classic behaviour, to prevent it from degrading the low queuing delay and low loss of L4S traffic.This Experimental specification defines the rules that L4S transports and network elements need to follow, with the intention that L4S flows neither harm each other's performance nor that of Classic traffic. It also suggests open questions to be investigated during experimentation. Examples of new Active Queue Management (AQM) marking algorithms and new transports (whether TCP-like or real time) are specified separately. |
|
| |
| RFC 9332 | Dual-Queue Coupled Active Queue Management (AQM) for Low Latency, Low Loss, and Scalable Throughput (L4S) |
| |
| Authors: | K. De Schepper, B. Briscoe, Ed., G. White. |
| Date: | January 2023 |
| Formats: | txt html json pdf xml |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9332 |
|
This specification defines a framework for coupling the Active QueueManagement (AQM) algorithms in two queues intended for flows with different responses to congestion. This provides a way for theInternet to transition from the scaling problems of standard TCP-Reno-friendly ('Classic') congestion controls to the family of'Scalable' congestion controls. These are designed for consistently very low queuing latency, very low congestion loss, and scaling of per-flow throughput by using Explicit Congestion Notification (ECN) in a modified way. Until the Coupled Dual Queue (DualQ), theseScalable L4S congestion controls could only be deployed where a clean-slate environment could be arranged, such as in private data centres.
This specification first explains how a Coupled DualQ works. It then gives the normative requirements that are necessary for it to work well. All this is independent of which two AQMs are used, but pseudocode examples of specific AQMs are given in appendices. |
|
| |
| RFC 9333 | Minimal IP Encapsulating Security Payload (ESP) |
| |
|
|
This document describes the minimal properties that an IPEncapsulating Security Payload (ESP) implementation needs to meet to remain interoperable with the standard ESP as defined in RFC 4303.Such a minimal version of ESP is not intended to become a replacement of ESP in RFC 4303. Instead, a minimal implementation is expected to be optimized for constrained environments while remaining interoperable with implementations of ESP. In addition, this document provides some considerations for implementing minimal ESP in a constrained environment, such as limiting the number of flash writes, handling frequent wakeup and sleep states, limiting wakeup time, and reducing the use of random generation.
This document does not update or modify RFC 4303. It provides a compact description of how to implement the minimal version of that protocol. RFC 4303 remains the authoritative description. |
|
| |
| RFC 9334 | Remote ATtestation procedureS (RATS) Architecture |
| |
| Authors: | H. Birkholz, D. Thaler, M. Richardson, N. Smith, W. Pan. |
| Date: | January 2023 |
| Formats: | txt json pdf html xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9334 |
|
In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims.It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. |
|
| |
| RFC 9335 | Completely Encrypting RTP Header Extensions and Contributing Sources |
| |
|
|
While the Secure Real-time Transport Protocol (SRTP) provides confidentiality for the contents of a media packet, a significant amount of metadata is left unprotected, including RTP header extensions and contributing sources (CSRCs). However, this data can be moderately sensitive in many applications. While there have been previous attempts to protect this data, they have had limited deployment, due to complexity as well as technical limitations.
This document updates RFC 3711, the SRTP specification, and definesCryptex as a new mechanism that completely encrypts header extensions and CSRCs and uses simpler Session Description Protocol (SDP) signaling with the goal of facilitating deployment. |
|
| |
| RFC 9336 | X.509 Certificate General-Purpose Extended Key Usage (EKU) for Document Signing |
| |
| Authors: | T. Ito, T. Okubo, S. Turner. |
| Date: | December 2022 |
| Formats: | txt xml pdf html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9336 |
|
RFC 5280 specifies several extended key purpose identifiers(KeyPurposeIds) for X.509 certificates. This document defines a general-purpose Document-Signing KeyPurposeId for inclusion in theExtended Key Usage (EKU) extension of X.509 public key certificates.Document-Signing applications may require that the EKU extension be present and that a Document-Signing KeyPurposeId be indicated in order for the certificate to be acceptable to that Document-Signing application. |
|
| |
| RFC 9337 | Generating Password-Based Keys Using the GOST Algorithms |
| |
|
|
This document specifies how to use "PKCS #5: Password-BasedCryptography Specification Version 2.1" (RFC 8018) to generate a symmetric key from a password in conjunction with the Russian national standard GOST algorithms.
PKCS #5 applies a Pseudorandom Function (PRF) -- a cryptographic hash, cipher, or Hash-Based Message Authentication Code (HMAC) -- to the input password along with a salt value and repeats the process many times to produce a derived key.
This specification has been developed outside the IETF. The purpose of publication being to facilitate interoperable implementations that wish to support the GOST algorithms. This document does not implyIETF endorsement of the cryptographic algorithms used here. |
|
| |
| RFC 9338 | CBOR Object Signing and Encryption (COSE): Countersignatures |
| |
|
|
Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. CBOR Object Signing andEncryption (COSE) defines a set of security services for CBOR. This document defines a countersignature algorithm along with the needed header parameters and CBOR tags for COSE. This document updates RFC9052. |
|
| |
| RFC 9339 | OSPF Reverse Metric |
| |
| Authors: | K. Talaulikar, Ed., P. Psenak, H. Johnston. |
| Date: | December 2022 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9339 |
|
This document specifies the extensions to OSPF that enable a router to use Link-Local Signaling (LLS) to signal the metric that receivingOSPF neighbor(s) should use for a link to the signaling router. When used on the link to the signaling router, the signaling of this reverse metric (RM) allows a router to influence the amount of traffic flowing towards itself. In certain use cases, this enables routers to maintain symmetric metrics on both sides of a link between them. |
|
| |
| RFC 9340 | Architectural Principles for a Quantum Internet |
| |
| Authors: | W. Kozlowski, S. Wehner, R. Van Meter, B. Rijsman, A. S. Cacciapuoti, M. Caleffi, S. Nagayama. |
| Date: | March 2023 |
| Formats: | txt html json pdf xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9340 |
|
The vision of a quantum internet is to enhance existing Internet technology by enabling quantum communication between any two points on Earth. To achieve this goal, a quantum network stack should be built from the ground up to account for the fundamentally new properties of quantum entanglement. The first quantum entanglement networks have been realised, but there is no practical proposal for how to organise, utilise, and manage such networks. In this document, we attempt to lay down the framework and introduce some basic architectural principles for a quantum internet. This is intended for general guidance and general interest. It is also intended to provide a foundation for discussion between physicists and network specialists. This document is a product of the QuantumInternet Research Group (QIRG). |
|
| |
| RFC 9341 | Alternate-Marking Method |
| |
| Authors: | G. Fioccola, Ed., M. Cociglio, G. Mirsky, T. Mizrahi, T. Zhou. |
| Date: | December 2022 |
| Formats: | txt html pdf xml json |
| Obsoletes: | RFC 8321 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9341 |
|
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. |
|
| |
| RFC 9342 | Clustered Alternate-Marking Method |
| |
| Authors: | G. Fioccola, Ed., M. Cociglio, A. Sapio, R. Sisto, T. Zhou. |
| Date: | December 2022 |
| Formats: | txt xml pdf json html |
| Obsoletes: | RFC 8889 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9342 |
|
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 RFC8889. |
|
| |
| RFC 9343 | IPv6 Application of the Alternate-Marking Method |
| |
| Authors: | G. Fioccola, T. Zhou, M. Cociglio, F. Qin, R. Pang. |
| Date: | December 2022 |
| Formats: | txt xml json pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9343 |
|
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 DestinationOptions Header. |
|
| |
| RFC 9344 | CCNinfo: Discovering Content and Network Information in Content-Centric Networks |
| |
| Authors: | H. Asaeda, A. Ooka, X. Shao. |
| Date: | February 2023 |
| Formats: | txt xml pdf html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9344 |
|
This document describes a mechanism named "CCNinfo" that discovers information about the network topology and in-network cache inContent-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.
This document is a product of the IRTF Information-Centric NetworkingResearch Group (ICNRG). This document represents the consensus view of ICNRG and has been reviewed extensively by several members of theICN community and the RG. The authors and RG chairs approve of the contents. The document is sponsored under the IRTF, is not issued by the IETF, and is not an IETF standard. This is an experimental protocol and the specification may change in the future. |
|
| |
| RFC 9345 | Delegated Credentials for TLS and DTLS |
| |
| Authors: | R. Barnes, S. Iyengar, N. Sullivan, E. Rescorla. |
| Date: | July 2023 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9345 |
|
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 theCertification 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. |
|
| |
| RFC 9346 | IS-IS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering |
| |
| Authors: | M. Chen, L. Ginsberg, S. Previdi, D. Xiaodong. |
| Date: | February 2023 |
| Formats: | txt json pdf xml html |
| Obsoletes: | RFC 5316 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9346 |
|
This document describes extensions to the Intermediate System toIntermediate System (IS-IS) protocol to support Multiprotocol LabelSwitching (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.
No support for flooding information from within one AS to another AS is proposed or defined in this document.
This document builds on RFC 5316 by adding support for IPv6-only operation.
This document obsoletes RFC 5316. |
|
| |
| RFC 9347 | 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 EncapsulatingSecurity Payload (ESP). This new payload type can be used for various purposes, such as decreasing encapsulation overhead for smallIP packets; however, the focus in this document is to enhance IPTraffic 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. |
|
| |
| RFC 9348 | A YANG Data Model for IP Traffic Flow Security |
| |
|
|
This document describes a YANG module for the management of IPTraffic Flow Security (IP-TFS) additions to Internet Key ExchangeProtocol version 2 (IKEv2) and IPsec. |
|
| |
| RFC 9349 | Definitions of Managed Objects for IP Traffic Flow Security |
| |
|
|
This document describes managed objects for the management of IPTraffic Flow Security additions to Internet Key Exchange ProtocolVersion 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). |
|
| |
| RFC 9350 | IGP Flexible Algorithm |
| |
| Authors: | P. Psenak, Ed., S. Hegde, C. Filsfils, K. Talaulikar, A. Gulko. |
| Date: | February 2023 |
| Formats: | txt html xml json pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9350 |
|
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. |
|
| |
| RFC 9351 | Border Gateway Protocol - Link State (BGP-LS) Extensions for Flexible Algorithm Advertisement |
| |
| Authors: | K. Talaulikar, Ed., P. Psenak, S. Zandi, G. Dawra. |
| Date: | February 2023 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9351 |
|
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.
Border Gateway Protocol - Link State (BGP-LS) enables the collection of various topology information from the network. This document defines extensions to the BGP-LS address family to advertise the FAD as a part of the topology information from the network. |
|
| |
| RFC 9352 | IS-IS Extensions to Support Segment Routing over the IPv6 Data Plane |
| |
| Authors: | P. Psenak, Ed., C. Filsfils, A. Bashandy, B. Decraene, Z. Hu. |
| Date: | February 2023 |
| Formats: | txt pdf xml json html |
| Updates: | RFC 7370 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9352 |
|
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.
This document updates RFC 7370 by modifying an existing registry. |
|
| |
| RFC 9353 | 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 AuthenticationOption (TCP-AO)) support capability.
This document defines capability flag bits for the PCE-CAP-FLAGS sub-TLV that can be announced as an attribute in the IGP advertisement to distribute PCEP security support information. In addition, this document updates RFCs 5088 and 5089 to allow advertisement of a KeyID or KEY-CHAIN-NAME sub-TLV to support TCP-AO security capability.This document also updates RFCs 8231 and 8306. |
|
| |
| RFC 9354 | Transmission of IPv6 Packets over Power Line Communication (PLC) Networks |
| |
| Authors: | J. Hou, B. Liu, Y-G. Hong, X. Tang, C. Perkins. |
| Date: | January 2023 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9354 |
|
Power Line Communication (PLC), namely using electric power lines for indoor and outdoor communications, has been widely applied to supportAdvanced 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. |
|
| |
| RFC 9355 | OSPF Bidirectional Forwarding Detection (BFD) Strict-Mode |
| |
| Authors: | K. Talaulikar, Ed., P. Psenak, A. Fu, M. Rajesh. |
| Date: | February 2023 |
| Formats: | txt pdf xml html json |
| Updates: | RFC 2328 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9355 |
|
This document specifies the extensions to OSPF that enable an OSPF router to signal the requirement for a Bidirectional ForwardingDetection (BFD) session prior to adjacency formation. Link-LocalSignaling (LLS) is used to advertise the requirement for strict-modeBFD 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.
This document updates RFC 2328 by augmenting the OSPF neighbor state machine with a check for BFD session up before progression from Init to 2-Way state when operating in OSPF BFD strict-mode. |
|
| |
| RFC 9356 | 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.
This document defines the protocol extensions for OSPF to advertise the link attributes of L2 bundle members. The document also specifies the advertisement of these OSPF extensions via the BorderGateway Protocol - Link State (BGP-LS) and thereby updates RFC 9085. |
|
| |
| RFC 9357 | Label Switched Path (LSP) Object Flag Extension for Stateful PCE |
| |
|
|
RFC 8231 describes a set of extensions to the Path ComputationElement Communication Protocol (PCEP) to enable stateful control ofMPLS-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.
This document defines a new LSP-EXTENDED-FLAG TLV for the LSP object for an extended Flag field. |
|
| |
| RFC 9358 | Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths and Virtual Networks |
| |
| Authors: | Y. Lee, H. Zheng, D. Ceccarelli. |
| Date: | February 2023 |
| Formats: | txt html json xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9358 |
|
This document describes how to extend the Path Computation ElementCommunication Protocol (PCEP) association mechanism introduced by RFC8697 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. |
|
| |
| RFC 9359 | Echo Request/Reply for Enabled In Situ OAM (IOAM) Capabilities |
| |
| Authors: | X. Min, G. Mirsky, L. Bo. |
| Date: | April 2023 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9359 |
|
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 ExplicitReplication (BIER). |
|
| |
| RFC 9360 | 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. |
|
| |
| RFC 9361 | ICANN Trademark Clearinghouse (TMCH) Functional Specifications |
| |
|
|
This document describes the requirements, the architecture, and the interfaces between the ICANN Trademark Clearinghouse (TMCH) andDomain Name Registries, as well as between the ICANN TMCH and DomainName Registrars for the provisioning and management of domain names during Sunrise and Trademark Claims Periods. |
|
| |
| RFC 9362 | Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Configuration Attributes for Robust Block Transmission |
| |
| Authors: | M. Boucadair, J. Shallow. |
| Date: | February 2023 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9362 |
|
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 ConstrainedApplication 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).
Also, this document defines a YANG data model for representing these new DOTS signal channel configuration parameters. This model augments the DOTS signal YANG module ("ietf-dots-signal-channel") defined in RFC 9132. |
|
| |
| RFC 9363 | A YANG Data Model for Static Context Header Compression (SCHC) |
| |
|
|
This document describes a YANG data model for the Static ContextHeader Compression (SCHC) compression and fragmentation Rules.
This document formalizes the description of the Rules for better interoperability between SCHC instances either to exchange a set ofRules or to modify the parameters of some Rules. |
|
| |
| RFC 9364 | 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 ofDNSSEC. This document does not update any of those RFCs. A second purpose is to state that using DNSSEC for origin authentication ofDNS data is the best current practice. A third purpose is to provide a single reference for other documents that want to refer to DNSSEC. |
|
| |
| RFC 9365 | IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases |
| |
|
|
This document discusses the problem statement and use cases ofIPv6-based vehicular networking for Intelligent TransportationSystems (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, forIPv6-based vehicular networks, it makes a gap analysis of currentIPv6 protocols (e.g., IPv6 Neighbor Discovery, mobility management, as well as security and privacy). |
|
| |
| RFC 9366 | Multiple SIP Reason Header Field Values |
| |
|
|
The SIP Reason header field as defined in RFC 3326 allows only oneReason 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. |
|
| |
| RFC 9367 | GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.3 |
| |
| Authors: | S. Smyshlyaev, Ed., E. Alekseev, E. Griboedova, A. Babueva, L. Nikiforova. |
| Date: | February 2023 |
| Formats: | txt pdf xml json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9367 |
|
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 Version1.3.
This document defines the cipher suites, signature schemes, and key exchange mechanisms for using Russian cryptographic standards, calledGOST algorithms, with TLS Version 1.3. Additionally, this document specifies a profile of TLS 1.3 with GOST algorithms to facilitate interoperable implementations. The IETF has not endorsed the cipher suites, signature schemes, or key exchange mechanisms described in this document. |
|
| |
| RFC 9368 | 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. |
|
| |
| RFC 9369 | 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.
Note that "version 2" is an informal name for this proposal that indicates it is the second version of QUIC to be published as aStandards Track document. The protocol specified here uses a version number other than 2 in the wire image, in order to minimize ossification risks. |
|
| |
| RFC 9370 | Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
| Authors: | CJ. Tjhai, M. Tomlinson, G. Bartlett, S. Fluhrer, D. Van Geest, O. Garcia-Morchon, V. Smyslov. |
| Date: | May 2023 |
| Formats: | txt html xml pdf json |
| Updates: | RFC 7296 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9370 |
|
This document describes how to extend the Internet Key ExchangeProtocol Version 2 (IKEv2) to allow multiple key exchanges to take place while computing a shared secret during a Security Association(SA) setup.
This document utilizes the IKE_INTERMEDIATE exchange, where multiple key exchanges are performed when an IKE SA is being established. It also introduces a new IKEv2 exchange, IKE_FOLLOWUP_KE, which is used for the same purpose when the IKE SA is being rekeyed or is creating additional Child SAs.
This document updates RFC 7296 by renaming a Transform Type 4 from"Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and renaming a field in the Key Exchange Payload from "Diffie-HellmanGroup Num" to "Key Exchange Method". It also renames an IANA registry for this Transform Type from "Transform Type 4 - Diffie-Hellman Group Transform IDs" to "Transform Type 4 - Key ExchangeMethod Transform IDs". These changes generalize key exchange algorithms that can be used in IKEv2. |
|
| |
| RFC 9371 | 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. |
|
| |
| RFC 9372 | L-Band Digital Aeronautical Communications System (LDACS) |
| |
| Authors: | N. Mäurer, Ed., T. Gräupl, Ed., C. Schmitt, Ed.. |
| Date: | March 2023 |
| Formats: | txt json pdf html xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9372 |
|
This document gives an overview of the L-band Digital AeronauticalCommunications 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. |
|
| |
| RFC 9373 | EdDSA Value for IPSECKEY |
| |
| Authors: | R. Moskowitz, T. Kivinen, M. Richardson. |
| Date: | March 2023 |
| Formats: | txt json pdf html xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9373 |
|
This document assigns a value for Edwards-Curve Digital SignatureAlgorithm (EdDSA) Public Keys to the "IPSECKEY Resource RecordParameters" registry. |
|
| |
| RFC 9374 | 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.
Within the context of RID, HHITs will be called DRIP Entity Tags(DETs). HHITs provide claims to the included explicit hierarchy that provides registry (via, for example, DNS, RDAP) discovery for third- party identifier endorsement.
This document updates RFCs 7343 and 7401. |
|
| |
| RFC 9375 | A YANG Data Model for Network and VPN Service Performance Monitoring |
| |
| Authors: | B. Wu, Ed., Q. Wu, Ed., M. Boucadair, Ed., O. Gonzalez de Dios, B. Wen. |
| Date: | April 2023 |
| Formats: | txt html json pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9375 |
|
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. |
|
| |
| RFC 9376 | Applicability of GMPLS for beyond 100 Gbit/s Optical Transport Network |
| |
| Authors: | Q. Wang, Ed., R. Valiveti, Ed., H. Zheng, Ed., H. van Helvoort, S. Belotti. |
| Date: | March 2023 |
| Formats: | txt json xml pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9376 |
|
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. |
|
| |
| RFC 9377 | IS-IS Flood Reflection |
| |
| Authors: | T. Przygienda, Ed., C. Bowers, Y. Lee, A. Sharma, R. White. |
| Date: | April 2023 |
| Formats: | txt xml json pdf html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9377 |
|
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 whichIS-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. |
|
| |
| RFC 9378 | In Situ Operations, Administration, and Maintenance (IOAM) Deployment |
| |
| Authors: | F. Brockners, Ed., S. Bhandari, Ed., D. Bernier, T. Mizrahi, Ed.. |
| Date: | April 2023 |
| Formats: | txt xml html pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9378 |
|
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. |
|
| |
| RFC 9380 | Hashing to Elliptic Curves |
| |
| Authors: | A. Faz-Hernandez, S. Scott, N. Sullivan, R. S. Wahby, C. A. Wood. |
| Date: | August 2023 |
| Formats: | txt html json xml pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9380 |
|
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. |
|
| |
| RFC 9381 | Verifiable Random Functions (VRFs) |
| |
| Authors: | S. Goldberg, L. Reyzin, D. Papadopoulos, J. Včelák. |
| Date: | August 2023 |
| Formats: | txt html xml pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9381 |
|
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.
This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. |
|
| |
| RFC 9382 | 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 InternetResearch Task Force (IRTF). |
|
| |
| RFC 9383 | SPAKE2+, an Augmented Password-Authenticated Key Exchange (PAKE) Protocol |
| |
|
|
This document describes SPAKE2+, a Password-Authenticated KeyExchange (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.
This document was produced outside of the IETF and IRTF and represents the opinions of the authors. Publication of this document as an RFC in the Independent Submissions Stream does not imply endorsement of SPAKE2+ by the IETF or IRTF. |
|
| |
| RFC 9384 | 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.
This document defines a subcode for the BGP Cease NOTIFICATION message (Section 6.7 of RFC 4271) for use when a BGP connection is being closed due to a BFD session going down. |
|
| |
| RFC 9385 | 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.
This specification was developed to facilitate implementations that wish to support the GOST algorithms. This document does not implyIETF endorsement of the cryptographic algorithms used in this document. |
|
| |
| RFC 9386 | IPv6 Deployment Status |
| |
| Authors: | G. Fioccola, P. Volpato, J. Palet Martinez, G. Mishra, C. Xie. |
| Date: | April 2023 |
| Formats: | txt json xml pdf html |
| Obsoletes: | RFC 6036 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9386 |
|
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 RFC6036. |
|
| |
| RFC 9387 | 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. |
|
| |
| RFC 9388 | Content Delivery Network Interconnection (CDNI) Footprint Types: Country Subdivision Code and Footprint Union |
| |
|
|
Open Caching architecture is a use case of Content Delivery NetworkInterconnection (CDNI) in which the commercial Content DeliveryNetwork (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 RFC8006. 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. |
|
| |
| RFC 9389 | Nominating Committee Eligibility |
| |
|
|
The IETF Nominating Committee (NomCom) appoints candidates to severalIETF 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, theIETF 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 obsoletesRFCs 8788 and 8989. |
|
| |
| RFC 9390 | Diameter Group Signaling |
| |
| Authors: | M. Jones, M. Liebsch, L. Morand. |
| Date: | April 2023 |
| Formats: | txt html pdf json xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9390 |
|
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 aDiameter node using a single or a few command exchanges. This document specifies the Diameter protocol extensions to achieve this signaling optimization. |
|
| |
| RFC 9391 | 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).
This document has two parts: one normative part that specifies the use of SCHC over NB-IoT and one informational part that recommends some values if 3GPP wants to use SCHC inside their architectures. |
|
| |
| RFC 9392 | Sending RTP Control Protocol (RTCP) Feedback for Congestion Control in Interactive Multimedia Conferences |
| |
|
|
This memo discusses the rate at which congestion control feedback can be sent using the RTP Control Protocol (RTCP) and the suitability ofRTCP for implementing congestion control for unicast multimedia applications. |
|
| |
| RFC 9393 | Concise Software Identification Tags |
| |
| Authors: | H. Birkholz, J. Fitzgerald-McKay, C. Schmidt, D. Waltermire. |
| Date: | June 2023 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9393 |
|
ISO/IEC 19770-2:2015 Software Identification (SWID) tags provide an extensible XML-based structure to identify and describe individual software components, patches, and installation bundles. SWID tag representations can be too large for devices with network and storage constraints. This document defines a concise representation of SWID tags: Concise SWID (CoSWID) tags. CoSWID supports a set of semantics and features that are similar to those for SWID tags, as well as new semantics that allow CoSWIDs to describe additional types of information, all in a more memory-efficient format. |
|
| |
| RFC 9394 | IMAP PARTIAL Extension for Paged SEARCH and FETCH |
| |
|
|
The PARTIAL extension of the Internet Message Access Protocol (seeRFCs 3501 and 9051) allows clients to limit the number of SEARCH results returned, as well as to perform incremental (paged) searches.This also helps servers to optimize resource usage when performing searches.
This document extends the PARTIAL SEARCH return option originally specified in RFC 5267. It also clarifies some interactions betweenRFC 5267 and RFCs 4731 and 9051.
This document updates RFCs 4731 and 5267. |
|
| |
| RFC 9395 | Deprecation of the Internet Key Exchange Version 1 (IKEv1) Protocol and Obsoleted Algorithms |
| |
|
|
Internet Key Exchange Version 1 (IKEv1) has been deprecated, and RFCs2407, 2408, and 2409 have been moved to Historic status. This document updates RFCs 8221 and 8247 to reflect the usage guidelines of old algorithms that are associated with IKEv1 and are not specified or commonly implemented for IKEv2. This document further updates the IANA registries for IKEv2 "Transform Type Values" by adding a "Status" column where the deprecation status can be listed. |
|
| |
| RFC 9396 | OAuth 2.0 Rich Authorization Requests |
| |
| Authors: | T. Lodderstedt, J. Richer, B. Campbell. |
| Date: | May 2023 |
| Formats: | txt json html pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9396 |
|
This document specifies a new parameter authorization_details that is used to carry fine-grained authorization data in OAuth messages. |
|
| |
| RFC 9397 | Trusted Execution Environment Provisioning (TEEP) Architecture |
| |
| Authors: | M. Pei, H. Tschofenig, D. Thaler, D. Wheeler. |
| Date: | July 2023 |
| Formats: | txt json pdf xml html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9397 |
|
A Trusted Execution Environment (TEE) is an environment that enforces the following: any code within the environment cannot be tampered with, and any data used by such code cannot be read or tampered with by any code outside the environment. This architecture document discusses the motivation for designing and standardizing a protocol for managing the lifecycle of Trusted Applications running inside such a TEE. |
|
| |
| RFC 9398 | A YANG Data Model for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxy Devices |
| |
| Authors: | H. Zhao, X. Liu, Y. Liu, M. Panchanathan, M. Sivakumar. |
| Date: | May 2023 |
| Formats: | txt html json pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9398 |
|
This document defines a YANG data model that can be used to configure and manage Internet Group Management Protocol (IGMP) or MulticastListener Discovery (MLD) Proxy devices. The YANG module in this document conforms to the Network Management Datastore Architecture(NMDA). |
|
| |
| RFC 9399 | Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates |
| |
|
|
This document specifies a certificate extension for including logotypes in public key certificates and attribute certificates.This document obsoletes RFCs 3709 and 6170. |
|
