| |
| RFC 9400 | Guidelines for the Organization of Fully Online Meetings |
| |
|
|
This document provides guidelines for the planning and organization of fully online meetings, regarding the number, length, and composition of sessions on the meeting agenda. These guidelines are based on the experience gained by holding online meetings during theCOVID-19 pandemic in 2020 and 2021. |
|
| |
| RFC 9401 | The Addition of the Death (DTH) Flag to TCP |
| |
|
|
This memo specifies the incorporation of Death (DTH) flag to TCP, including DTH's use of one bit in the TCP header. The flag is designed to make TCP session narratives smooth and attractive. |
|
| |
| RFC 9402 | Concat Notation |
| |
| Authors: | M. Basaglia, J. Bernards, J. Maas. |
| Date: | 1 April 2023 |
| Formats: | txt json pdf html xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9402 |
|
This document defines the Concat notation: a text-based language used to describe pictures and videos whose subject includes cats, containers, and their interactions. |
|
| |
| RFC 9403 | A YANG Data Model for RIB Extensions |
| |
|
|
A Routing Information Base (RIB) is a list of routes and their corresponding administrative data and operational state.
RFC 8349 defines the basic building blocks for the RIB data model, and this model augments it to support multiple next hops (aka paths) for each route as well as additional attributes. |
|
| |
| RFC 9404 | JSON Meta Application Protocol (JMAP) Blob Management Extension |
| |
|
|
The JSON Meta Application Protocol (JMAP) base protocol (RFC 8620) provides the ability to upload and download arbitrary binary data viaHTTP POST and GET on a defined endpoint. This binary data is called a "blob".
This extension adds additional ways to create and access blobs by making inline method calls within a standard JMAP request.
This extension also adds a reverse lookup mechanism to discover where blobs are referenced within other data types. |
|
| |
| RFC 9405 | AI Sarcasm Detection: Insult Your AI without Offending It |
| |
| Authors: | C. GPT, R. L. Barnes, Ed.. |
| Date: | 1 April 2023 |
| Formats: | txt html pdf xml json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9405 |
|
This RFC proposes a framework for detecting sarcasm in AI systems and provides guidelines for using sarcasm without causing offense. By training AI systems to identify linguistic patterns that indicate sarcasm, we can improve their understanding of human communication.The guidelines offer a lighthearted approach to using sarcasm in a way that is both effective and respectful, without crossing the line into offensive language. |
|
| |
| RFC 9406 | HyStart++: Modified Slow Start for TCP |
| |
| Authors: | P. Balasubramanian, Y. Huang, M. Olson. |
| Date: | May 2023 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9406 |
|
This document describes HyStart++, a simple modification to the slow start phase of congestion control algorithms. Slow start can overshoot the ideal send rate in many cases, causing high packet loss and poor performance. HyStart++ uses increase in round-trip delay as a heuristic to find an exit point before possible overshoot. It also adds a mitigation to prevent jitter from causing premature slow start exit. |
|
| |
| RFC 9407 | Tetrys: An On-the-Fly Network Coding Protocol |
| |
| Authors: | J. Detchart, E. Lochin, J. Lacan, V. Roca. |
| Date: | June 2023 |
| Formats: | txt xml pdf json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9407 |
|
This document describes Tetrys, which is an on-the-fly network coding protocol that can be used to transport delay-sensitive and loss- sensitive data over a lossy network. Tetrys may recover from erasures within an RTT-independent delay thanks to the transmission of coded packets. This document is a record of the experience gained by the authors while developing and testing the Tetrys protocol in real conditions.
This document is a product of the Coding for Efficient NetWorkCommunications Research Group (NWCRG). It conforms to the NWCRG taxonomy described in RFC 8406. |
|
| |
| RFC 9408 | A YANG Network Data Model for Service Attachment Points (SAPs) |
| |
| Authors: | M. Boucadair, Ed., O. Gonzalez de Dios, S. Barguil, Q. Wu, V. Lopez. |
| Date: | June 2023 |
| Formats: | txt xml pdf html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9408 |
|
This document defines a YANG data model for representing an abstract view of the provider network topology that contains the points from which its services can be attached (e.g., basic connectivity, VPN, network slices). Also, the model can be used to retrieve the points where the services are actually being delivered to customers(including peer networks).
This document augments the 'ietf-network' data model defined in RFC8345 by adding the concept of Service Attachment Points (SAPs). TheSAPs are the network reference points to which network services, such as Layer 3 Virtual Private Network (L3VPN) or Layer 2 Virtual PrivateNetwork (L2VPN), can be attached. One or multiple services can be bound to the same SAP. Both User-to-Network Interface (UNI) andNetwork-to-Network Interface (NNI) are supported in the SAP data model. |
|
| |
| RFC 9409 | The 'sip-trunking-capability' Link Relation Type |
| |
| Authors: | K. Inamdar, S. Narayanan, D. Engi, G. Salgueiro. |
| Date: | July 2023 |
| Formats: | txt xml html pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9409 |
|
This Informational document defines the 'sip-trunking-capability' link relation type that may be used by an enterprise telephonySession Initiation Protocol (SIP) network to retrieve a SIP trunking capability set document, which contains the capabilities and configuration requirements of an Internet Telephony Service Provider(ITSP). These technical requirements allow for seamless peering between SIP-based enterprise telephony networks and the ITSP. |
|
| |
| RFC 9410 | Handling of Identity Header Errors for Secure Telephone Identity Revisited (STIR) |
| |
|
|
This document extends the current error-handling procedures for mapping of verification failure reasons to 4xx codes for SecureTelephone Identity Revisited (STIR) and the Authenticated IdentityManagement in the Session Initiation Protocol (SIP). It extends the ability to use the Reason header field as an option for conveying an error associated with an Identity header field to the upstream authentication service when local policy dictates that the call should continue in the presence of a verification failure. This document also defines procedures that enable a failure reason to be mapped to a specific Identity header field for scenarios that use multiple Identity header fields, where some may have errors and others may not. The handling of those situations is also defined. |
|
| |
| RFC 9411 | Benchmarking Methodology for Network Security Device Performance |
| |
|
|
This document provides benchmarking terminology and methodology for next-generation network security devices, including next-generation firewalls (NGFWs) and next-generation intrusion prevention systems(NGIPSs). The main areas covered in this document are test terminology, test configuration parameters, and benchmarking methodology for NGFWs and NGIPSs. (It is assumed that readers have a working knowledge of these devices and the security functionality they contain.) This document aims to improve the applicability, reproducibility, and transparency of benchmarks and to align the test methodology with today's increasingly complex layer 7 security- centric network application use cases. As a result, this document makes RFC 3511 obsolete. |
|
| |
| RFC 9412 | The ORIGIN Extension in HTTP/3 |
| |
|
|
The ORIGIN frame for HTTP/2 is equally applicable to HTTP/3, but it needs to be separately registered. This document describes theORIGIN frame for HTTP/3. |
|
| |
| RFC 9413 | Maintaining Robust Protocols |
| |
|
|
The main goal of the networking standards process is to enable the long-term interoperability of protocols. This document describes active protocol maintenance, a means to accomplish that goal. By evolving specifications and implementations, it is possible to reduce ambiguity over time and create a healthy ecosystem.
The robustness principle, often phrased as "be conservative in what you send, and liberal in what you accept", has long guided the design and implementation of Internet protocols. However, it has been interpreted in a variety of ways. While some interpretations help ensure the health of the Internet, others can negatively affect interoperability over time. When a protocol is actively maintained, protocol designers and implementers can avoid these pitfalls. |
|
| |
| RFC 9414 | Unfortunate History of Transient Numeric Identifiers |
| |
|
|
This document analyzes the timeline of the specification and implementation of different types of "transient numeric identifiers" used in IETF protocols and how the security and privacy properties of such protocols have been affected as a result of it. It provides empirical evidence that advice in this area is warranted. This document is a product of the Privacy Enhancements and AssessmentsResearch Group (PEARG) in the IRTF. |
|
| |
| RFC 9415 | On the Generation of Transient Numeric Identifiers |
| |
|
|
This document performs an analysis of the security and privacy implications of different types of "transient numeric identifiers" used in IETF protocols and tries to categorize them based on their interoperability requirements and their associated failure severity when such requirements are not met. Subsequently, it provides advice on possible algorithms that could be employed to satisfy the interoperability requirements of each identifier category while minimizing the negative security and privacy implications, thus providing guidance to protocol designers and protocol implementers.Finally, it describes a number of algorithms that have been employed in real implementations to generate transient numeric identifiers and analyzes their security and privacy properties. This document is a product of the Privacy Enhancements and Assessments Research Group(PEARG) in the IRTF. |
|
| |
| RFC 9416 | Security Considerations for Transient Numeric Identifiers Employed in Network Protocols |
| |
|
|
Poor selection of transient numerical identifiers in protocols such as the TCP/IP suite has historically led to a number of attacks on implementations, ranging from Denial of Service (DoS) or data injection to information leakages that can be exploited by pervasive monitoring. Due diligence in the specification of transient numeric identifiers is required even when cryptographic techniques are employed, since these techniques might not mitigate all the associated issues. This document formally updates RFC 3552, incorporating requirements for transient numeric identifiers, to prevent flaws in future protocols and implementations. |
|
| |
| RFC 9417 | Service Assurance for Intent-Based Networking Architecture |
| |
| Authors: | B. Claise, J. Quilbeuf, D. Lopez, D. Voyer, T. Arumugam. |
| Date: | July 2023 |
| Formats: | txt json pdf xml html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9417 |
|
This document describes an architecture that provides some assurance that service instances are running as expected. As services rely upon multiple subservices provided by a variety of elements, including the underlying network devices and functions, getting the assurance of a healthy service is only possible with a holistic view of all involved elements. This architecture not only helps to correlate the service degradation with symptoms of a specific network component but, it also lists the services impacted by the failure or degradation of a specific network component. |
|
| |
| RFC 9418 | A YANG Data Model for Service Assurance |
| |
| Authors: | B. Claise, J. Quilbeuf, P. Lucente, P. Fasano, T. Arumugam. |
| Date: | July 2023 |
| Formats: | txt pdf xml html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9418 |
|
This document specifies YANG modules for representing assurance graphs. These graphs represent the assurance of a given service by decomposing it into atomic assurance elements called subservices.The companion document, "Service Assurance for Intent-BasedNetworking Architecture" (RFC 9417), presents an architecture for implementing the assurance of such services.
The YANG data models in this document conform to the NetworkManagement Datastore Architecture (NMDA) defined in RFC 8342. |
|
| |
| RFC 9419 | Considerations on Application - Network Collaboration Using Path Signals |
| |
| Authors: | J. Arkko, T. Hardie, T. Pauly, M. Kühlewind. |
| Date: | July 2023 |
| Formats: | txt html pdf xml json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9419 |
|
This document discusses principles for designing mechanisms that use or provide path signals and calls for standards action in specific valuable cases. RFC 8558 describes path signals as messages to or from on-path elements and points out that visible information will be used whether or not it is intended as a signal. The principles in this document are intended as guidance for the design of explicit path signals, which are encouraged to be authenticated and include a minimal set of parties to minimize information sharing. These principles can be achieved through mechanisms like encryption of information and establishing trust relationships between entities on a path. |
|
| |
| RFC 9420 | The Messaging Layer Security (MLS) Protocol |
| |
| Authors: | R. Barnes, B. Beurdouche, R. Robert, J. Millican, E. Omara, K. Cohn-Gordon. |
| Date: | July 2023 |
| Formats: | txt html json xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9420 |
|
Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy (FS) and post-compromise security (PCS) for groups in size ranging from two to thousands. |
|
| |
| RFC 9421 | HTTP Message Signatures |
| |
| Authors: | A. Backman, Ed., J. Richer, Ed., M. Sporny. |
| Date: | February 2024 |
| Formats: | txt html xml json pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9421 |
|
This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange. |
|
| |
| RFC 9422 | The LIMITS SMTP Service Extension |
| |
| Authors: | N. Freed, J. Klensin. |
| Date: | February 2024 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9422 |
|
This document defines a LIMITS extension for the Simple Mail TransferProtocol (SMTP), including submission, as well as the Local MailTransfer Protocol (LMTP). It also defines an associated limit registry. The extension provides the means for an SMTP, submission, or LMTP server to inform the client of limits the server intends to apply to the protocol during the current session. The client is then able to adapt its behavior in order to conform to those limits. |
|
| |
| RFC 9423 | Constrained RESTful Environments (CoRE) Target Attributes Registry |
| |
|
|
The Constrained RESTful Environments (CoRE) specifications apply web technologies to constrained environments. One such important technology is Web Linking (RFC 8288), which CoRE specifications use as the basis for a number of discovery protocols, such as the LinkFormat (RFC 6690) in the Constrained Application Protocol's (CoAP's) resource discovery process (Section 7.2 of RFC 7252) and the ResourceDirectory (RD) (RFC 9176).
Web Links can have target attributes, the names of which are not generally coordinated by the Web Linking specification (Section 2.2 of RFC 8288). This document introduces an IANA registry for coordinating names of target attributes when used in CoRE. It updates the "RD Parameters" IANA registry created by RFC 9176 to coordinate with this registry. |
|
| |
| RFC 9424 | Indicators of Compromise (IoCs) and Their Role in Attack Defence |
| |
| Authors: | K. Paine, O. Whitehouse, J. Sellwood, A. Shaw. |
| Date: | August 2023 |
| Formats: | txt pdf html xml json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9424 |
|
Cyber defenders frequently rely on Indicators of Compromise (IoCs) to identify, trace, and block malicious activity in networks or on endpoints. This document reviews the fundamentals, opportunities, operational limitations, and recommendations for IoC use. It highlights the need for IoCs to be detectable in implementations ofInternet protocols, tools, and technologies -- both for the IoCs' initial discovery and their use in detection -- and provides a foundation for approaches to operational challenges in network security. |
|
| |
| RFC 9425 | JSON Meta Application Protocol (JMAP) for Quotas |
| |
|
|
This document specifies a data model for handling quotas on accounts with a server using the JSON Meta Application Protocol (JMAP). |
|
| |
| RFC 9426 | BATched Sparse (BATS) Coding Scheme for Multi-hop Data Transport |
| |
| Authors: | S. Yang, X. Huang, R. Yeung, J. Zao. |
| Date: | July 2023 |
| Formats: | txt json xml pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9426 |
|
In general, linear network coding can improve the network communication performance in terms of throughput, latency, and reliability. BATched Sparse (BATS) code is a class of efficient linear network coding scheme with a matrix generalization of fountain codes as the outer code and batch-based linear network coding as the inner code. This document describes a baseline BATS coding scheme for communication through multi-hop networks and discusses the related research issues towards a more sophisticated BATS coding scheme. This document is a product of the Coding for EfficientNetwork Communications Research Group (NWCRG). |
|
| |
| RFC 9427 | TLS-Based Extensible Authentication Protocol (EAP) Types for Use with TLS 1.3 |
| |
|
|
The Extensible Authentication Protocol-TLS (EAP-TLS) (RFC 5216) has been updated for TLS 1.3 in RFC 9190. Many other EAP Types also depend on TLS, such as EAP-Flexible Authentication via SecureTunneling (EAP-FAST) (RFC 4851), EAP-Tunneled TLS (EAP-TTLS) (RFC5281), the Tunnel Extensible Authentication Protocol (TEAP) (RFC7170). It is possible that many vendor-specific EAP methods, such as the Protected Extensible Authentication Protocol (PEAP), depend onTLS as well. This document updates those methods in order to use the new key derivation methods available in TLS 1.3. Additional changes necessitated by TLS 1.3 are also discussed. |
|
| |
| RFC 9428 | Transmission of IPv6 Packets over Near Field Communication |
| |
| Authors: | Y. Choi, Ed., Y-G. Hong, J-S. Youn. |
| Date: | July 2023 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9428 |
|
Near Field Communication (NFC) is a set of standards for smartphones and portable devices to establish radio communication with each other by touching them together or bringing them into proximity, usually no more than 10 cm apart. NFC standards cover communication protocols and data exchange formats and are based on existing Radio FrequencyIdentification (RFID) standards, including ISO/IEC 14443 and FeliCa.The standards include ISO/IEC 18092 and those defined by the NFCForum. The NFC technology has been widely implemented and available in mobile phones, laptop computers, and many other devices. This document describes how IPv6 is transmitted over NFC using IPv6 overLow-Power Wireless Personal Area Network (6LoWPAN) techniques. |
|
| |
| RFC 9429 | JavaScript Session Establishment Protocol (JSEP) |
| |
|
|
This document describes the mechanisms for allowing a JavaScript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API and discusses how this relates to existing signaling protocols.
This specification obsoletes RFC 8829. |
|
| |
| RFC 9430 | Extension of the Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) to Transport Layer Security (TLS) |
| |
|
|
This document updates "Datagram Transport Layer Security (DTLS)Profile for Authentication and Authorization for ConstrainedEnvironments (ACE)" (RFC 9202) by specifying that the profile applies to TLS as well as DTLS. |
|
| |
| RFC 9431 | Message Queuing Telemetry Transport (MQTT) and Transport Layer Security (TLS) Profile of Authentication and Authorization for Constrained Environments (ACE) Framework |
| |
|
|
This document specifies a profile for the Authentication andAuthorization for Constrained Environments (ACE) framework to enable authorization in a publish-subscribe messaging system based onMessage Queuing Telemetry Transport (MQTT). Proof-of-Possession keys, bound to OAuth 2.0 access tokens, are used to authenticate and authorize MQTT Clients. The protocol relies on TLS for confidentiality and MQTT server (Broker) authentication. |
|
| |
| RFC 9432 | DNS Catalog Zones |
| |
| Authors: | P. van Dijk, L. Peltan, O. Surý, W. Toorop, C.R. Monshouwer, P. Thomassen, A. Sargsyan. |
| Date: | July 2023 |
| Formats: | txt xml json pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9432 |
|
This document describes a method for automatic DNS zone provisioning among DNS primary and secondary name servers by storing and transferring the catalog of zones to be provisioned as one or more regular DNS zones. |
|
| |
| RFC 9433 | Segment Routing over IPv6 for the Mobile User Plane |
| |
| Authors: | S. Matsushima, Ed., C. Filsfils, M. Kohno, P. Camarillo, Ed., D. Voyer. |
| Date: | July 2023 |
| Formats: | txt json xml pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9433 |
|
This document discusses the applicability of Segment Routing overIPv6 (SRv6) to the user plane of mobile networks. The network programming nature of SRv6 accomplishes mobile user-plane functions in a simple manner. The statelessness of SRv6 and its ability to control both service layer path and underlying transport can be beneficial to the mobile user plane, providing flexibility, end-to- end network slicing, and Service Level Agreement (SLA) control for various applications.
This document discusses how SRv6 could be used as the user plane of mobile networks. This document also specifies the SRv6 EndpointBehaviors required for mobility use cases. |
|
| |
| RFC 9434 | Drone Remote Identification Protocol (DRIP) Architecture |
| |
| Authors: | S. Card, A. Wiethuechter, R. Moskowitz, S. Zhao, Ed., A. Gurtov. |
| Date: | July 2023 |
| Formats: | txt html xml pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9434 |
|
This document describes an architecture for protocols and services to support Unmanned Aircraft System Remote Identification and tracking(UAS RID), plus UAS-RID-related communications. This architecture adheres to the requirements listed in the Drone Remote IdentificationProtocol (DRIP) Requirements document (RFC 9153). |
|
| |
| RFC 9435 | Considerations for Assigning a New Recommended Differentiated Services Code Point (DSCP) |
| |
| Authors: | A. Custura, G. Fairhurst, R. Secchi. |
| Date: | July 2023 |
| Formats: | txt xml pdf html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9435 |
|
This document discusses considerations for assigning a new recommended Differentiated Services Code Point (DSCP) for a standardPer-Hop Behavior (PHB). It considers the common observed re-marking behaviors that the Diffserv field might be subjected to along anInternet path. It also notes some implications of using a specificDSCP. |
|
| |
| RFC 9436 | PIM Message Type Space Extension and Reserved Bits |
| |
|
|
The PIM version 2 messages share a common message header format. The common header definition contains eight reserved bits. This document specifies how these bits may be used by individual message types and extends the PIM type space.
This document updates RFCs 7761 and 3973 by defining the use of theReserved field in the PIM common header. This document further updates RFCs 7761 and 3973, along with RFCs 5015, 5059, 6754, and8364, by specifying the use of the bits for each PIM message.
This document obsoletes RFC 8736. |
|
| |
| RFC 9437 | Publish/Subscribe Functionality for the Locator/ID Separation Protocol (LISP) |
| |
| Authors: | A. Rodriguez-Natal, V. Ermagan, A. Cabellos, S. Barkai, M. Boucadair. |
| Date: | August 2023 |
| Formats: | txt json pdf html xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9437 |
|
This document specifies an extension to the Locator/ID SeparationProtocol (LISP) control plane to enable Publish/Subscribe (PubSub) operation. |
|
| |
| RFC 9438 | CUBIC for Fast and Long-Distance Networks |
| |
|
|
CUBIC is a standard TCP congestion control algorithm that uses a cubic function instead of a linear congestion window increase function to improve scalability and stability over fast and long- distance networks. CUBIC has been adopted as the default TCP congestion control algorithm by the Linux, Windows, and Apple stacks.
This document updates the specification of CUBIC to include algorithmic improvements based on these implementations and recent academic work. Based on the extensive deployment experience withCUBIC, this document also moves the specification to the StandardsTrack and obsoletes RFC 8312. This document also updates RFC 5681, to allow for CUBIC's occasionally more aggressive sending behavior. |
|
| |
| RFC 9439 | Application-Layer Traffic Optimization (ALTO) Performance Cost Metrics |
| |
| Authors: | Q. Wu, Y. Yang, Y. Lee, D. Dhody, S. Randriamasy, L. Contreras. |
| Date: | August 2023 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9439 |
|
The cost metric is a basic concept in Application-Layer TrafficOptimization (ALTO), and different applications may use different types of cost metrics. Since the ALTO base protocol (RFC 7285) defines only a single cost metric (namely, the generic "routingcost" metric), if an application wants to issue a cost map or an endpoint cost request in order to identify a resource provider that offers better performance metrics (e.g., lower delay or loss rate), the base protocol does not define the cost metric to be used.
This document addresses this issue by extending the specification to provide a variety of network performance metrics, including network delay, delay variation (a.k.a. jitter), packet loss rate, hop count, and bandwidth.
There are multiple sources (e.g., estimations based on measurements or a Service Level Agreement) available for deriving a performance metric. This document introduces an additional "cost-context" field to the ALTO "cost-type" field to convey the source of a performance metric. |
|
| |
| RFC 9440 | Client-Cert HTTP Header Field |
| |
|
|
This document describes HTTP extension header fields that allow a TLS terminating reverse proxy (TTRP) to convey the client certificate information of a mutually authenticated TLS connection to the origin server in a common and predictable manner. |
|
| |
| RFC 9441 | Static Context Header Compression (SCHC) Compound Acknowledgement (ACK) |
| |
|
|
This document updates the Static Context Header Compression (SCHC) and fragmentation protocol (RFC 8724) and the corresponding YANG module (RFC 9363). It defines a SCHC Compound Acknowledgement (ACK) message format and procedure, which are intended to reduce the number of response transmissions (i.e., SCHC ACKs) in the ACK-on-Error Mode, by accumulating bitmaps of several windows in a single SCHC message(i.e., the SCHC Compound ACK).
Both the message format and procedure are generic, so they can be used, for instance, by any of the four Low-Power Wide Area Network(LPWAN) technologies defined in RFC 8376, which are Sigfox, LongRange Wide Area Network (LoRaWAN), Narrowband Internet of Things (NB-IoT), and IEEE 802.15.4w. |
|
| |
| RFC 9442 | Static Context Header Compression (SCHC) over Sigfox Low-Power Wide Area Network (LPWAN) |
| |
| Authors: | J. Zúñiga, C. Gomez, S. Aguilar, L. Toutain, S. Céspedes, D. Wistuba, J. Boite. |
| Date: | July 2023 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9442 |
|
The Static Context Header Compression (SCHC) and fragmentation specification (RFC 8724) describes a generic framework for application header compression and fragmentation modes designed forLow-Power Wide Area Network (LPWAN) technologies. This document defines a profile of SCHC over Sigfox LPWAN and provides optimal parameter values and modes of operation. |
|
| |
| RFC 9443 | Multiplexing Scheme Updates for QUIC |
| |
|
|
RFC 7983 defines a scheme for a Real-time Transport Protocol (RTP) receiver to demultiplex Datagram Transport Layer Security (DTLS),Session Traversal Utilities for NAT (STUN), Secure Real-timeTransport Protocol (SRTP) / Secure Real-time Transport ControlProtocol (SRTCP), ZRTP, and Traversal Using Relays around NAT (TURN) channel packets arriving on a single port. This document updates RFC7983 and RFC 5764 to also allow QUIC packets to be multiplexed on a single receiving socket. |
|
| |
| RFC 9444 | Automated Certificate Management Environment (ACME) for Subdomains |
| |
| Authors: | O. Friel, R. Barnes, T. Hollebeek, M. Richardson. |
| Date: | August 2023 |
| Formats: | txt json html pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9444 |
|
This document specifies how Automated Certificate ManagementEnvironment (ACME) can be used by a client to obtain a certificate for a subdomain identifier from a certification authority.Additionally, this document specifies how a client can fulfill a challenge against an ancestor domain but may not need to fulfill a challenge against the explicit subdomain if certification authority policy allows issuance of the subdomain certificate without explicit subdomain ownership proof. |
|
| |
| RFC 9445 | RADIUS Extensions for DHCP-Configured Services |
| |
|
|
This document specifies two new Remote Authentication Dial-In UserService (RADIUS) attributes that carry DHCP options. The specification is generic and can be applicable to any service that relies upon DHCP. Both DHCPv4- and DHCPv6-configured services are covered.
Also, this document updates RFC 4014 by relaxing a constraint on permitted RADIUS attributes in the RADIUS Attributes DHCP suboption. |
|
| |
| RFC 9446 | Reflections on Ten Years Past the Snowden Revelations |
| |
| Authors: | S. Farrell, F. Badii, B. Schneier, S. M. Bellovin. |
| Date: | July 2023 |
| Formats: | txt html xml pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9446 |
|
This memo contains the thoughts and recountings of events that transpired during and after the release of information about theUnited States National Security Agency (NSA) by Edward Snowden in2013. There are four perspectives: that of someone who was involved with sifting through the information to responsibly inform the public, that of a security area director of the IETF, that of a human rights expert, and that of a computer science and affiliate law professor. The purpose of this memo is to provide some historical perspective, while at the same time offering a view as to what security and privacy challenges the technical community should consider. These essays do not represent a consensus view, but that of the individual authors. |
|
| |
| RFC 9447 | Automated Certificate Management Environment (ACME) Challenges Using an Authority Token |
| |
| Authors: | J. Peterson, M. Barnes, D. Hancock, C. Wendt. |
| Date: | September 2023 |
| Formats: | txt xml pdf html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9447 |
|
Some proposed extensions to the Automated Certificate ManagementEnvironment (ACME) rely on proving eligibility for certificates through consulting an external authority that issues a token according to a particular policy. This document specifies a genericAuthority Token Challenge for ACME that supports subtype claims for different identifiers or namespaces that can be defined separately for specific applications. |
|
| |
| RFC 9448 | TNAuthList Profile of Automated Certificate Management Environment (ACME) Authority Token |
| |
| Authors: | C. Wendt, D. Hancock, M. Barnes, J. Peterson. |
| Date: | September 2023 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9448 |
|
This document defines a profile of the Automated CertificateManagement Environment (ACME) Authority Token for the automated and authorized creation of certificates for Voice over IP (VoIP) telephone providers to support Secure Telephone Identity (STI) using the TNAuthList defined by STI certificates. |
|
| |
| RFC 9449 | OAuth 2.0 Demonstrating Proof of Possession (DPoP) |
| |
| Authors: | D. Fett, B. Campbell, J. Bradley, T. Lodderstedt, M. Jones, D. Waite. |
| Date: | September 2023 |
| Formats: | txt xml pdf json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9449 |
|
This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level.This mechanism allows for the detection of replay attacks with access and refresh tokens. |
|
| |
| RFC 9450 | Reliable and Available Wireless (RAW) Use Cases |
| |
| Authors: | CJ. Bernardos, Ed., G. Papadopoulos, P. Thubert, F. Theoleyre. |
| Date: | August 2023 |
| Formats: | txt json pdf xml html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9450 |
|
The wireless medium presents significant specific challenges to achieve properties similar to those of wired deterministic networks.At the same time, a number of use cases cannot be solved with wires and justify the extra effort of going wireless. This document presents wireless use cases (such as aeronautical communications, amusement parks, industrial applications, pro audio and video, gaming, Unmanned Aerial Vehicle (UAV) and vehicle-to-vehicle (V2V) control, edge robotics, and emergency vehicles), demanding reliable and available behavior. |
|
| |
| RFC 9451 | Operations, Administration, and Maintenance (OAM) Packet and Behavior in the Network Service Header (NSH) |
| |
|
|
This document clarifies an ambiguity in the Network Service Header(NSH) specification related to the handling of O bit. In particular, this document clarifies the meaning of "OAM packet".
This document updates RFC 8300. |
|
| |
| RFC 9452 | Network Service Header (NSH) Encapsulation for In Situ OAM (IOAM) Data |
| |
| Authors: | F. Brockners, Ed., S. Bhandari, Ed.. |
| Date: | August 2023 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9452 |
|
In situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information while the packet traverses a path between two points in the network.This document outlines how IOAM-Data-Fields are encapsulated with theNetwork Service Header (NSH). |
|
| |
| RFC 9453 | Applicability and Use Cases for IPv6 over Networks of Resource-constrained Nodes (6lo) |
| |
| Authors: | Y. Hong, C. Gomez, Y. Choi, A. Sangi, S. Chakrabarti. |
| Date: | September 2023 |
| Formats: | txt html json xml pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9453 |
|
This document describes the applicability of IPv6 over constrained- node networks (6lo) and provides practical deployment examples. In addition to IEEE Std 802.15.4, various link-layer technologies are used as examples, such as ITU-T G.9959 (Z-Wave), Bluetooth Low Energy(Bluetooth LE), Digital Enhanced Cordless Telecommunications - UltraLow Energy (DECT-ULE), Master-Slave/Token Passing (MS/TP), Near FieldCommunication (NFC), and Power Line Communication (PLC). This document targets an audience who would like to understand and evaluate running end-to-end IPv6 over the constrained-node networks for local or Internet connectivity. |
|
| |
| RFC 9454 | Update to OSPF Terminology |
| |
|
|
This document updates some OSPF terminology to be in line with inclusive language used in the industry. The IETF has designated"Guidance for NIST Staff on Using Inclusive Language in DocumentaryStandards" by the US National Institute of Standards and Technology(NIST) for its inclusive language guidelines. It is intended that all future OSPF documents use this revised terminology even when they reference the RFCs updated by this document.
This document updates RFCs 2328, 4222, 4811, 5243, 5340, 5614, and5838. |
|
| |
| RFC 9455 | Avoiding Route Origin Authorizations (ROAs) Containing Multiple IP Prefixes |
| |
| Authors: | Z. Yan, R. Bush, G. Geng, T. de Kock, J. Yao. |
| Date: | August 2023 |
| Formats: | txt json html xml pdf |
| Also: | BCP 0238 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 9455 |
|
When using the Resource Public Key Infrastructure (RPKI), address space holders need to issue Route Origin Authorization (ROA) object(s) to authorize one or more Autonomous Systems (ASes) to originate BGP routes to IP address prefix(es). This memo discusses operational problems that may arise from ROAs containing multiple IP prefixes and recommends that each ROA contain a single IP prefix. |
|
| |
| RFC 9456 | Updates to the TLS Transport Model for SNMP |
| |
|
|
This document updates RFC 6353 ("Transport Layer Security (TLS)Transport Model for the Simple Network Management Protocol (SNMP)") to reflect changes necessary to support Transport Layer Security version 1.3 (TLS 1.3) and Datagram Transport Layer Security version1.3 (DTLS 1.3), which are jointly known as "(D)TLS 1.3". This document is compatible with (D)TLS 1.2 and is intended to be compatible with future versions of SNMP and (D)TLS.
This document updates the SNMP-TLS-TM-MIB as defined in RFC 6353. |
|
| |
| RFC 9457 | Problem Details for HTTP APIs |
| |
|
|
This document defines a "problem detail" to carry machine-readable details of errors in HTTP response content to avoid the need to define new error response formats for HTTP APIs.
This document obsoletes RFC 7807. |
|
| |
| RFC 9458 | Oblivious HTTP |
| |
| Authors: | M. Thomson, C. A. Wood. |
| Date: | January 2024 |
| Formats: | txt pdf json xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9458 |
|
This document describes Oblivious HTTP, a protocol for forwarding encrypted HTTP messages. Oblivious HTTP allows a client to make multiple requests to an origin server without that server being able to link those requests to the client or to identify the requests as having come from the same client, while placing only limited trust in the nodes used to forward the messages. |
|
| |
| RFC 9459 | CBOR Object Signing and Encryption (COSE): AES-CTR and AES-CBC |
| |
| Authors: | R. Housley, H. Tschofenig. |
| Date: | September 2023 |
| Formats: | txt pdf json xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9459 |
|
The Concise Binary Object Representation (CBOR) data format is designed for small code size and small message size. CBOR ObjectSigning and Encryption (COSE) is specified in RFC 9052 to provide basic security services using the CBOR data format. This document specifies the conventions for using AES-CTR and AES-CBC as content encryption algorithms with COSE. |
|
| |
| RFC 9460 | Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records) |
| |
| Authors: | B. Schwartz, M. Bishop, E. Nygren. |
| Date: | November 2023 |
| Formats: | txt json html xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9460 |
|
This document specifies the "SVCB" ("Service Binding") and "HTTPS"DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible withCNAME. The HTTPS RR is a variation of SVCB for use with HTTP (seeRFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. |
|
| |
| RFC 9461 | Service Binding Mapping for DNS Servers |
| |
|
|
The SVCB DNS resource record type expresses a bound collection of endpoint metadata, for use when establishing a connection to a named service. DNS itself can be such a service, when the server is identified by a domain name. This document provides the SVCB mapping for named DNS servers, allowing them to indicate support for encrypted transport protocols. |
|
| |
| RFC 9462 | Discovery of Designated Resolvers |
| |
| Authors: | T. Pauly, E. Kinnear, C. A. Wood, P. McManus, T. Jensen. |
| Date: | November 2023 |
| Formats: | txt pdf html xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9462 |
|
This document defines Discovery of Designated Resolvers (DDR), a set of mechanisms for DNS clients to use DNS records to discover a resolver's encrypted DNS configuration. An Encrypted DNS Resolver discovered in this manner is referred to as a "Designated Resolver".These mechanisms can be used to move from unencrypted DNS to encrypted DNS when only the IP address of a resolver is known. These mechanisms are designed to be limited to cases where Unencrypted DNSResolvers and their Designated Resolvers are operated by the same entity or cooperating entities. It can also be used to discover support for encrypted DNS protocols when the name of an Encrypted DNSResolver is known. |
|
| |
| RFC 9463 | DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR) |
| |
| Authors: | M. Boucadair, Ed., T. Reddy.K, Ed., D. Wing, N. Cook, T. Jensen. |
| Date: | November 2023 |
| Formats: | txt pdf html xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9463 |
|
This document specifies new DHCP and IPv6 Router Advertisement options to discover encrypted DNS resolvers (e.g., DNS over HTTPS,DNS over TLS, and DNS over QUIC). Particularly, it allows a host to learn an Authentication Domain Name together with a list of IP addresses and a set of service parameters to reach such encrypted DNS resolvers. |
|
| |
| RFC 9464 | Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for Encrypted DNS |
| |
| Authors: | M. Boucadair, T. Reddy.K, D. Wing, V. Smyslov. |
| Date: | November 2023 |
| Formats: | txt pdf xml json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9464 |
|
This document specifies new Internet Key Exchange Protocol Version 2(IKEv2) Configuration Payload Attribute Types to assign DNS resolvers that support encrypted DNS protocols, such as DNS over HTTPS (DoH),DNS over TLS (DoT), and DNS over QUIC (DoQ). |
|
| |
| RFC 9465 | PIM Null-Register Packing |
| |
| Authors: | V. Kamath, R. Chokkanathapuram Sundaram, R. Banthia, A. Gopal. |
| Date: | September 2023 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9465 |
|
In PIM Sparse Mode (PIM-SM) networks, PIM Null-Register messages are sent by the Designated Router (DR) to the Rendezvous Point (RP) to signal the presence of multicast sources in the network. There are periodic PIM Null-Registers sent from the DR to the RP to keep the state alive at the RP as long as the source is active. The PIM Null-Register message carries information about a single multicast source and group.
This document defines a standard to send information about multiple multicast sources and groups in a single PIM message. This document refers to the new messages as the "PIM Packed Null-Register message" and "PIM Packed Register-Stop message". |
|
| |
| RFC 9466 | PIM Assert Message Packing |
| |
| Authors: | Y. Liu, Ed., T. Eckert, Ed., M. McBride, Z. Zhang. |
| Date: | October 2023 |
| Formats: | txt html xml json pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9466 |
|
When PIM Sparse Mode (PIM-SM), including PIM Source-SpecificMulticast (PIM-SSM), is used in shared LAN networks, there is often more than one upstream router. This can lead to duplicate IP multicast packets being forwarded by these PIM routers. PIM Assert messages are used to elect a single forwarder for each IP multicast traffic flow between these routers.
This document defines a mechanism to send and receive information for multiple IP multicast flows in a single PackedAssert message. This optimization reduces the total number of PIM packets on the LAN and can therefore speed up the election of the single forwarder, reducing the number of duplicate IP multicast packets incurred. |
|
| |
| RFC 9467 | Relaxed Packet Counter Verification for Babel MAC Authentication |
| |
|
|
This document relaxes the packet verification rules defined in "MACAuthentication for the Babel Routing Protocol" (RFC 8967) in order to make the protocol more robust in the presence of packet reordering.This document updates RFC 8967. |
|
| |
| RFC 9468 | Unsolicited Bidirectional Forwarding Detection (BFD) for Sessionless Applications |
| |
| Authors: | E. Chen, N. Shen, R. Raszuk, R. Rahman. |
| Date: | August 2023 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9468 |
|
For operational simplification of "sessionless" applications usingBidirectional Forwarding Detection (BFD), in this document, we present procedures for "unsolicited BFD" that allow a BFD session to be initiated by only one side and established without explicit per- session configuration or registration by the other side (subject to certain per-interface or global policies).
We also introduce a new YANG module to configure and manage"unsolicited BFD". The YANG module in this document is based on YANG1.1, as defined in RFC 7950, and conforms to the Network ManagementDatastore Architecture (NMDA), as described in RFC 8342. This document augments RFC 9314. |
|
| |
| RFC 9469 | Applicability of Ethernet Virtual Private Network (EVPN) to Network Virtualization over Layer 3 (NVO3) Networks |
| |
| Authors: | J. Rabadan, Ed., M. Bocci, S. Boutros, A. Sajassi. |
| Date: | September 2023 |
| Formats: | txt json xml html pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9469 |
|
An Ethernet Virtual Private Network (EVPN) provides a unified control plane that solves the issues of Network Virtualization Edge (NVE) auto-discovery, tenant Media Access Control (MAC) / IP dissemination, and advanced features in a scablable way as required by NetworkVirtualization over Layer 3 (NVO3) networks. EVPN is a scalable solution for NVO3 networks and keeps the independence of the underlayIP Fabric, i.e., there is no need to enable Protocol IndependentMulticast (PIM) in the underlay network and maintain multicast states for tenant Broadcast Domains. This document describes the use ofEVPN for NVO3 networks and discusses its applicability to basic Layer2 and Layer 3 connectivity requirements and to advanced features such as MAC Mobility, MAC Protection and Loop Protection, multihoming,Data Center Interconnect (DCI), and much more. No new EVPN procedures are introduced. |
|
| |
| RFC 9470 | OAuth 2.0 Step Up Authentication Challenge Protocol |
| |
| Authors: | V. Bertocci, B. Campbell. |
| Date: | September 2023 |
| Formats: | txt json pdf html xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9470 |
|
It is not uncommon for resource servers to require different authentication strengths or recentness according to the characteristics of a request. This document introduces a mechanism that resource servers can use to signal to a client that the authentication event associated with the access token of the current request does not meet its authentication requirements and, further, how to meet them. This document also codifies a mechanism for a client to request that an authorization server achieve a specific authentication strength or recentness when processing an authorization request. |
|
| |
| RFC 9471 | DNS Glue Requirements in Referral Responses |
| |
| Authors: | M. Andrews, S. Huque, P. Wouters, D. Wessels. |
| Date: | September 2023 |
| Formats: | txt json pdf html xml |
| Updates: | RFC 1034 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9471 |
|
The DNS uses glue records to allow iterative clients to find the addresses of name servers that are contained within a delegated zone.Authoritative servers are expected to return all available glue records for in-domain name servers in a referral response. If message size constraints prevent the inclusion of all glue records for in-domain name servers, the server must set the TC (Truncated) flag to inform the client that the response is incomplete and that the client should use another transport to retrieve the full response. This document updates RFC 1034 to clarify correct server behavior. |
|
| |
| RFC 9472 | A YANG Data Model for Reporting Software Bills of Materials (SBOMs) and Vulnerability Information |
| |
|
|
To improve cybersecurity posture, automation is necessary to locate the software a device is using, whether that software has known vulnerabilities, and what, if any, recommendations suppliers may have. This memo extends the Manufacturer User Description (MUD) YANG schema to provide the locations of software bills of materials(SBOMs) and vulnerability information by introducing a transparency schema. |
|
| |
| RFC 9473 | A Vocabulary of Path Properties |
| |
| Authors: | R. Enghardt, C. Krähenbühl. |
| Date: | September 2023 |
| Formats: | txt html xml pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9473 |
|
Path properties express information about paths across a network and the services provided via such paths. In a path-aware network, path properties may be fully or partially available to entities such as endpoints. This document defines and categorizes path properties.Furthermore, the document identifies several path properties that might be useful to endpoints or other entities, e.g., for selecting between paths or for invoking some of the provided services. This document is a product of the Path Aware Networking Research Group(PANRG). |
|
| |
| RFC 9474 | RSA Blind Signatures |
| |
| Authors: | F. Denis, F. Jacobs, C. A. Wood. |
| Date: | October 2023 |
| Formats: | txt xml pdf json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9474 |
|
This document specifies an RSA-based blind signature protocol. RSA blind signatures were first introduced by Chaum for untraceable payments. A signature that is output from this protocol can be verified as an RSA-PSS signature.
This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. |
|
| |
| RFC 9475 | Messaging Use Cases and Extensions for Secure Telephone Identity Revisited (STIR) |
| |
| Authors: | J. Peterson, C. Wendt. |
| Date: | December 2023 |
| Formats: | txt xml json pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9475 |
|
Secure Telephone Identity Revisited (STIR) provides a means of attesting the identity of a telephone caller via a signed token in order to prevent impersonation of a calling party number, which is a key enabler for illegal robocalling. Similar impersonation is sometimes leveraged by bad actors in the text and multimedia messaging space. This document explores the applicability of STIR'sPersonal Assertion Token (PASSporT) and certificate issuance framework to text and multimedia messaging use cases, including support for both messages carried as a payload in SIP requests and messages sent in sessions negotiated by SIP. |
|
| |
| RFC 9476 | The .alt Special-Use Top-Level Domain |
| |
| Authors: | W. Kumari, P. Hoffman. |
| Date: | September 2023 |
| Formats: | txt html json pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9476 |
|
This document reserves a Top-Level Domain (TLD) label "alt" to be used in non-DNS contexts. It also provides advice and guidance to developers creating alternative namespaces. |
|
| |
| RFC 9477 | Complaint Feedback Loop Address Header |
| |
|
|
This document describes a method that allows a Message Originator to specify a Complaint Feedback Loop (CFBL) address as a message header field. It also defines the rules for processing and forwarding such a complaint. The motivation for this arises out of the absence of a standardized and automated way to provide Mailbox Providers with an address for a CFBL. Currently, providing and maintaining such an address is a manual and time-consuming process for MessageOriginators and Mailbox Providers.
The mechanism specified in this document is being published as an experiment to gather feedback and gauge the interest of implementers and deployers. This document is produced through the Independent RFCStream and was not subject to the IETF's approval process. |
|
| |
| RFC 9478 | Labeled IPsec Traffic Selector Support for the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
| Authors: | P. Wouters, S. Prasad. |
| Date: | October 2023 |
| Formats: | txt json html pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9478 |
|
This document defines a new Traffic Selector Type (TS Type) for theInternet Key Exchange Protocol version 2 (IKEv2) to add support for negotiating Mandatory Access Control (MAC) security labels as aTraffic Selector of the Security Policy Database (SPD). SecurityLabels for IPsec are also known as "Labeled IPsec". The new TS Type,TS_SECLABEL, consists of a variable length opaque field that specifies the security label. |
|
| |
| RFC 9479 | IS-IS Application-Specific Link Attributes |
| |
| Authors: | L. Ginsberg, P. Psenak, S. Previdi, W. Henderickx, J. Drake. |
| Date: | October 2023 |
| Formats: | txt json pdf xml html |
| Obsoletes: | RFC 8919 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9479 |
|
Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications (e.g.,Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined. In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application- specific values for a given attribute, nor do they support an indication of which applications are using the advertised value for a given link. This document introduces link attribute advertisements that address both of these shortcomings.
This document obsoletes RFC 8919. |
|
| |
| RFC 9480 | Certificate Management Protocol (CMP) Updates |
| |
|
|
This document contains a set of updates to the syntax of CertificateManagement Protocol (CMP) version 2 and its HTTP transfer mechanism.This document updates RFCs 4210, 5912, and 6712.
The aspects of CMP updated in this document are using EnvelopedData instead of EncryptedValue, clarifying the handling of p10cr messages, improving the crypto agility, as well as adding new general message types, extended key usages to identify certificates for use with CMP, and well-known URI path segments.
CMP version 3 is introduced to enable signaling support ofEnvelopedData instead of EncryptedValue and signal the use of an explicit hash AlgorithmIdentifier in certConf messages, as far as needed. |
|
| |
| RFC 9481 | Certificate Management Protocol (CMP) Algorithms |
| |
| Authors: | H. Brockhaus, H. Aschauer, M. Ounsworth, J. Gray. |
| Date: | November 2023 |
| Formats: | txt pdf json xml html |
| Updates: | RFC 4210 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9481 |
|
This document describes the conventions for using several cryptographic algorithms with the Certificate Management Protocol(CMP). CMP is used to enroll and further manage the lifecycle ofX.509 certificates. This document also updates the algorithm use profile from Appendix D.2 of RFC 4210. |
|
| |
| RFC 9482 | Constrained Application Protocol (CoAP) Transfer for the Certificate Management Protocol |
| |
| Authors: | M. Sahni, Ed., S. Tripathi, Ed.. |
| Date: | November 2023 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9482 |
|
This document specifies the use of the Constrained ApplicationProtocol (CoAP) as a transfer mechanism for the CertificateManagement Protocol (CMP). CMP defines the interaction between various PKI entities for the purpose of certificate creation and management. CoAP is an HTTP-like client-server protocol used by various constrained devices in the Internet of Things space. |
|
| |
| RFC 9483 | Lightweight Certificate Management Protocol (CMP) Profile |
| |
| Authors: | H. Brockhaus, D. von Oheimb, S. Fries. |
| Date: | November 2023 |
| Formats: | txt html json xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9483 |
|
This document aims at simple, interoperable, and automated PKI management operations covering typical use cases of industrial andInternet of Things (IoT) scenarios. This is achieved by profiling the Certificate Management Protocol (CMP), the related CertificateRequest Message Format (CRMF), and transfer based on HTTP orConstrained Application Protocol (CoAP) in a succinct but sufficiently detailed and self-contained way. To make secure certificate management for simple scenarios and constrained devices as lightweight as possible, only the most crucial types of operations and options are specified as mandatory. More specialized or complex use cases are supported with optional features. |
|
| |
| RFC 9484 | Proxying IP in HTTP |
| |
| Authors: | T. Pauly, Ed., D. Schinazi, A. Chernyakhovsky, M. Kühlewind, M. Westerlund. |
| Date: | October 2023 |
| Formats: | txt json xml html pdf |
| Updates: | RFC 9298 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9484 |
|
This document describes how to proxy IP packets in HTTP. This protocol is similar to UDP proxying in HTTP but allows transmitting arbitrary IP packets. More specifically, this document defines a protocol that allows an HTTP client to create an IP tunnel through anHTTP server that acts as an IP proxy. This document updates RFC9298. |
|
| |
| RFC 9485 | I-Regexp: An Interoperable Regular Expression Format |
| |
|
|
This document specifies I-Regexp, a flavor of regular expression that is limited in scope with the goal of interoperation across many different regular expression libraries. |
|
| |
| RFC 9486 | IPv6 Options for In Situ Operations, Administration, and Maintenance (IOAM) |
| |
| Authors: | S. Bhandari, Ed., F. Brockners, Ed.. |
| Date: | September 2023 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9486 |
|
In situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document outlines how IOAM Data-Fields are encapsulated in IPv6. |
|
| |
| RFC 9487 | Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPFIX) |
| |
| Authors: | T. Graf, B. Claise, P. Francois. |
| Date: | November 2023 |
| Formats: | txt pdf xml html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9487 |
|
This document introduces new IP Flow Information Export (IPFIX)Information Elements (IEs) to identify a set of information related to Segment Routing over IPv6 (SRv6) such as data contained in aSegment Routing Header (SRH), the SRv6 control plane, and the SRv6Endpoint behavior that traffic is being forwarded with. |
|
| |
| RFC 9488 | Local Protection Enforcement in the Path Computation Element Communication Protocol (PCEP) |
| |
| Authors: | A. Stone, M. Aissaoui, S. Sidor, S. Sivabalan. |
| Date: | October 2023 |
| Formats: | txt json pdf xml html |
| Updates: | RFC 5440 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9488 |
|
This document updates RFC 5440 to clarify usage of the LocalProtection Desired bit signaled in the Path Computation ElementCommunication Protocol (PCEP). This document also introduces a new flag for signaling protection enforcement in PCEP. |
|
| |
| RFC 9489 | Label Switched Path (LSP) Ping Mechanisms for EVPN and Provider Backbone Bridging EVPN (PBB-EVPN) |
| |
| Authors: | P. Jain, A. Sajassi, S. Salam, S. Boutros, G. Mirsky. |
| Date: | November 2023 |
| Formats: | txt pdf xml json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9489 |
|
Label Switched Path (LSP) Ping is a widely deployed Operations,Administration, and Maintenance (OAM) mechanism in MPLS networks.This document describes mechanisms for detecting data plane failures using LSP Ping in MPLS-based Ethernet VPN (EVPN) and ProviderBackbone Bridging EVPN (PBB-EVPN) networks. |
|
| |
| RFC 9490 | Report from the IAB Workshop on Management Techniques in Encrypted Networks (M-TEN) |
| |
| Authors: | M. Knodel, W. Hardaker, T. Pauly. |
| Date: | January 2024 |
| Formats: | txt json xml pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9490 |
|
The "Management Techniques in Encrypted Networks (M-TEN)" workshop was convened by the Internet Architecture Board (IAB) from 17 October2022 to 19 October 2022 as a three-day online meeting. The workshop was organized in three parts to discuss ways to improve network management techniques in support of even broader adoption of encryption on the Internet. 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 expressed during the workshop by participants and do not necessarily reflect IAB views and positions. |
|
| |
| RFC 9491 | Integration of the Network Service Header (NSH) and Segment Routing for Service Function Chaining (SFC) |
| |
| Authors: | J. Guichard, Ed., J. Tantsura, Ed.. |
| Date: | November 2023 |
| Formats: | txt xml pdf json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9491 |
|
This document describes the integration of the Network Service Header(NSH) and Segment Routing (SR), as well as encapsulation details, to efficiently support Service Function Chaining (SFC) while maintaining separation of the service and transport planes as originally intended by the SFC architecture.
Combining these technologies allows SR to be used for steering packets between Service Function Forwarders (SFFs) along a givenService Function Path (SFP), whereas the NSH is responsible for maintaining the integrity of the service plane, the SFC instance context, and any associated metadata.
This integration demonstrates that the NSH and SR can work cooperatively and provide a network operator with the flexibility to use whichever transport technology makes sense in specific areas of their network infrastructure while still maintaining an end-to-end service plane using the NSH. |
|
| |
| RFC 9492 | OSPF Application-Specific Link Attributes |
| |
| Authors: | P. Psenak, Ed., L. Ginsberg, W. Henderickx, J. Tantsura, J. Drake. |
| Date: | October 2023 |
| Formats: | txt html pdf json xml |
| Obsoletes: | RFC 8920 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9492 |
|
Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications such as Segment Routing (SR) Policy and Loop-Free Alternates (LFAs) that also make use of the link attribute advertisements have been defined.In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application- specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link. This document introduces link attribute advertisements inOSPFv2 and OSPFv3 that address both of these shortcomings.
This document obsoletes RFC 8920. |
|
| |
| RFC 9493 | Subject Identifiers for Security Event Tokens |
| |
| Authors: | A. Backman, Ed., M. Scurtescu, P. Jain. |
| Date: | December 2023 |
| Formats: | txt html json pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9493 |
|
Security events communicated within Security Event Tokens may support a variety of identifiers to identify subjects related to the event.This specification formalizes the notion of Subject Identifiers as structured information that describes a subject and named formats that define the syntax and semantics for encoding Subject Identifiers as JSON objects. It also establishes a registry for defining and allocating names for such formats as well as the JSON Web Token (JWT)"sub_id" Claim. |
|
| |
| RFC 9494 | Long-Lived Graceful Restart for BGP |
| |
| Authors: | J. Uttaro, E. Chen, B. Decraene, J. Scudder. |
| Date: | November 2023 |
| Formats: | txt json pdf xml html |
| Updates: | RFC 6368 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9494 |
|
This document introduces a BGP capability called the "Long-LivedGraceful Restart Capability" (or "LLGR Capability"). The benefit of this capability is that stale routes can be retained for a longer time upon session failure than is provided for by BGP GracefulRestart (as described in RFC 4724). A well-known BGP community called "LLGR_STALE" is introduced for marking stale routes retained for a longer time. A second well-known BGP community called"NO_LLGR" is introduced for marking routes for which these procedures should not be applied. We also specify that such long-lived stale routes be treated as the least preferred and that their advertisements be limited to BGP speakers that have advertised the capability. Use of this extension is not advisable in all cases, and we provide guidelines to help determine if it is.
This memo updates RFC 6368 by specifying that the LLGR_STALE community must be propagated into, or out of, the path attributes exchanged between the Provider Edge (PE) and Customer Edge (CE) routers. |
|
| |
| RFC 9495 | Certification Authority Authorization (CAA) Processing for Email Addresses |
| |
|
|
The Certification Authority Authorization (CAA) DNS resource record(RR) provides a mechanism for domains to express the allowed set ofCertification Authorities that are authorized to issue certificates for the domain. RFC 8659 contains the core CAA specification, whereProperty Tags that restrict the issuance of certificates that certify domain names are defined. This specification defines a Property Tag that grants authorization to Certification Authorities to issue certificates that contain the id-kp-emailProtection key purpose in the extendedKeyUsage extension and at least one rfc822Name value or otherName value of type id-on-SmtpUTF8Mailbox that includes the domain name in the subjectAltName extension. |
|
| |
| RFC 9496 | The ristretto255 and decaf448 Groups |
| |
| Authors: | H. de Valence, J. Grigg, M. Hamburg, I. Lovecruft, G. Tankersley, F. Valsorda. |
| Date: | December 2023 |
| Formats: | txt xml html pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9496 |
|
This memo specifies two prime-order groups, ristretto255 and decaf448, suitable for safely implementing higher-level and complex cryptographic protocols. The ristretto255 group can be implemented using Curve25519, allowing existing Curve25519 implementations to be reused and extended to provide a prime-order group. Likewise, the decaf448 group can be implemented using edwards448.
This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. |
|
| |
| RFC 9497 | Oblivious Pseudorandom Functions (OPRFs) Using Prime-Order Groups |
| |
| Authors: | A. Davidson, A. Faz-Hernandez, N. Sullivan, C. A. Wood. |
| Date: | December 2023 |
| Formats: | txt xml html pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9497 |
|
An Oblivious Pseudorandom Function (OPRF) is a two-party protocol between a client and a server for computing the output of aPseudorandom Function (PRF). The server provides the PRF private key, and the client provides the PRF input. At the end of the protocol, the client learns the PRF output without learning anything about the PRF private key, and the server learns neither the PRF input nor output. An OPRF can also satisfy a notion of'verifiability', called a VOPRF. A VOPRF ensures clients can verify that the server used a specific private key during the execution of the protocol. A VOPRF can also be partially oblivious, called aPOPRF. A POPRF allows clients and servers to provide public input to the PRF computation. This document specifies an OPRF, VOPRF, andPOPRF instantiated within standard prime-order groups, including elliptic curves. This document is a product of the Crypto ForumResearch Group (CFRG) in the IRTF. |
|
| |
| RFC 9498 | The GNU Name System |
| |
| Authors: | M. Schanzenbach, C. Grothoff, B. Fix. |
| Date: | November 2023 |
| Formats: | txt json xml pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9498 |
|
This document provides the GNU Name System (GNS) technical specification. GNS is a decentralized and censorship-resistant domain name resolution protocol that provides a privacy-enhancing alternative to the Domain Name System (DNS) protocols.
This document defines the normative wire format of resource records, resolution processes, cryptographic routines, and security and privacy considerations for use by implementers.
This specification was developed outside the IETF and does not haveIETF consensus. It is published here to inform readers about the function of GNS, guide future GNS implementations, and ensure interoperability among implementations (for example, pre-existingGNUnet implementations). |
|
| |
| RFC 9499 | DNS Terminology |
| |
|
|
The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document.
This document updates RFC 2308 by clarifying the definitions of"forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B. |
|
