| |
| RFC 9200 | Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth) |
| |
| Authors: | L. Seitz, G. Selander, E. Wahlstroem, S. Erdtman, H. Tschofenig. |
| Date: | August 2022 |
| Formats: | txt html xml json pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9200 |
|
This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments calledACE-OAuth. The framework is based on a set of building blocks including OAuth 2.0 and the Constrained Application Protocol (CoAP), thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined to better serve the IoT use cases. |
|
| |
| RFC 9201 | Additional OAuth Parameters for Authentication and Authorization for Constrained Environments (ACE) |
| |
|
|
This specification defines new parameters and encodings for the OAuth2.0 token and introspection endpoints when used with the framework for Authentication and Authorization for Constrained Environments(ACE). These are used to express the proof-of-possession (PoP) key the client wishes to use, the PoP key that the authorization server has selected, and the PoP key the resource server uses to authenticate to the client. |
|
| |
| RFC 9202 | Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) |
| |
| Authors: | S. Gerdes, O. Bergmann, C. Bormann, G. Selander, L. Seitz. |
| Date: | August 2022 |
| Formats: | txt json pdf xml html |
| Updated by: | RFC 9430 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9202 |
|
This specification defines a profile of the Authentication andAuthorization for Constrained Environments (ACE) framework that allows constrained servers to delegate client authentication and authorization. The protocol relies on DTLS version 1.2 or later for communication security between entities in a constrained network using either raw public keys or pre-shared keys. A resource- constrained server can use this protocol to delegate management of authorization information to a trusted host with less-severe limitations regarding processing power and memory. |
|
| |
| RFC 9203 | The Object Security for Constrained RESTful Environments (OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework |
| |
| Authors: | F. Palombini, L. Seitz, G. Selander, M. Gunnarsson. |
| Date: | August 2022 |
| Formats: | txt pdf xml json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9203 |
|
This document specifies a profile for the Authentication andAuthorization for Constrained Environments (ACE) framework. It utilizes Object Security for Constrained RESTful Environments(OSCORE) to provide communication security and proof-of-possession for a key owned by the client and bound to an OAuth 2.0 access token. |
|
| |
| RFC 9204 | QPACK: Field Compression for HTTP/3 |
| |
| Authors: | C. Krasic, M. Bishop, A. Frindell, Ed.. |
| Date: | June 2022 |
| Formats: | txt pdf xml html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9204 |
|
This specification defines QPACK: a compression format for efficiently representing HTTP fields that is to be used in HTTP/3.This is a variation of HPACK compression that seeks to reduce head- of-line blocking. |
|
| |
| RFC 9205 | Building Protocols with HTTP |
| |
|
|
Applications often use HTTP as a substrate to create HTTP-based APIs.This document specifies best practices for writing specifications that use HTTP to define new application protocols. It is written primarily to guide IETF efforts to define application protocols usingHTTP for deployment on the Internet but might be applicable in other situations.This document obsoletes RFC 3205. |
|
| |
| RFC 9206 | Commercial National Security Algorithm (CNSA) Suite Cryptography for Internet Protocol Security (IPsec) |
| |
|
|
The United States Government has published the National SecurityAgency's Commercial National Security Algorithm (CNSA) Suite, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using theUnited States National Security Agency's CNSA Suite algorithms inInternet Protocol Security (IPsec). It applies to the capabilities, configuration, and operation of all components of US NationalSecurity Systems (described in NIST Special Publication 800-59) that employ IPsec. This document is also appropriate for all other USGovernment systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments. |
|
| |
| RFC 9207 | OAuth 2.0 Authorization Server Issuer Identification |
| |
| Authors: | K. Meyer zu Selhausen, D. Fett. |
| Date: | March 2022 |
| Formats: | txt json html xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9207 |
|
This document specifies a new parameter called iss. This parameter is used to explicitly include the issuer identifier of the authorization server in the authorization response of an OAuth authorization flow. The iss parameter serves as an effective countermeasure to "mix-up attacks". |
|
| |
| RFC 9208 | IMAP QUOTA Extension |
| |
|
|
This document defines a QUOTA extension of the Internet MessageAccess Protocol (IMAP) (see RFCs 3501 and 9051) that permits administrative limits on resource usage (quotas) to be manipulated through the IMAP protocol.
This document obsoletes RFC 2087 but attempts to remain backwards compatible whenever possible. |
|
| |
| RFC 9209 | The Proxy-Status HTTP Response Header Field |
| |
| Authors: | M. Nottingham, P. Sikora. |
| Date: | June 2022 |
| Formats: | txt html json xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9209 |
|
This document defines the Proxy-Status HTTP response field to convey the details of an intermediary's response handling, including generated errors. |
|
| |
| RFC 9210 | DNS Transport over TCP - Operational Requirements |
| |
|
|
This document updates RFCs 1123 and 1536. This document requires the operational practice of permitting DNS messages to be carried overTCP on the Internet as a Best Current Practice. This operational requirement is aligned with the implementation requirements in RFC7766. The use of TCP includes both DNS over unencrypted TCP as well as over an encrypted TLS session. The document also considers the consequences of this form of DNS communication and the potential operational issues that can arise when this Best Current Practice is not upheld. |
|
| |
| RFC 9211 | The Cache-Status HTTP Response Header Field |
| |
|
|
To aid debugging, HTTP caches often append header fields to a response, explaining how they handled the request in an ad hoc manner. This specification defines a standard mechanism to do so that is aligned with HTTP's caching model. |
|
| |
| RFC 9212 | Commercial National Security Algorithm (CNSA) Suite Cryptography for Secure Shell (SSH) |
| |
|
|
The United States Government has published the National SecurityAgency (NSA) Commercial National Security Algorithm (CNSA) Suite, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using theUnited States National Security Agency's CNSA Suite algorithms with the Secure Shell Transport Layer Protocol and the Secure ShellAuthentication Protocol. It applies to the capabilities, configuration, and operation of all components of US NationalSecurity Systems (described in NIST Special Publication 800-59) that employ Secure Shell (SSH). This document is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments. |
|
| |
| RFC 9213 | Targeted HTTP Cache Control |
| |
| Authors: | S. Ludin, M. Nottingham, Y. Wu. |
| Date: | June 2022 |
| Formats: | txt xml pdf json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9213 |
|
This specification defines a convention for HTTP response header fields that allow cache directives to be targeted at specific caches or classes of caches. It also defines one such header field, theCDN-Cache-Control response header field, which is targeted at content delivery network (CDN) caches. |
|
| |
| RFC 9214 | OSPFv3 Code Point for MPLS LSP Ping |
| |
|
|
IANA has created "Protocol in the Segment ID Sub-TLV" and "Protocol in Label Stack Sub-TLV of Downstream Detailed Mapping TLV" registries under the "Multiprotocol Label Switching (MPLS) Label Switched Paths(LSPs) Ping Parameters" registry. RFC 8287 defines the code points for Open Shortest Path First (OSPF) and Intermediate System toIntermediate System (IS-IS) protocols.
This document specifies the code point to be used in the Segment ID sub-TLV and Downstream Detailed Mapping (DDMAP) TLV when the InteriorGateway Protocol (IGP) is OSPFv3. This document also updatesRFC 8287 by clarifying that the existing "OSPF" code point is to be used only to indicate OSPFv2 and by defining the behavior when theSegment ID sub-TLV indicates the use of IPv6. |
|
| |
| RFC 9215 | Using GOST R 34.10-2012 and GOST R 34.11-2012 Algorithms with the Internet X.509 Public Key Infrastructure |
| |
| Authors: | D. Baryshkov, Ed., V. Nikolaev, A. Chelpanov. |
| Date: | March 2022 |
| Formats: | txt xml pdf html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9215 |
|
This document describes encoding formats, identifiers, and parameter formats for the GOST R 34.10-2012 and GOST R 34.11-2012 algorithms for use in the Internet X.509 Public Key Infrastructure (PKI).
This specification is 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 9216 | S/MIME Example Keys and Certificates |
| |
|
|
The S/MIME development community benefits from sharing samples of signed or encrypted data. This document facilitates such collaboration by defining a small set of X.509v3 certificates and keys for use when generating such samples. |
|
| |
| RFC 9217 | Current Open Questions in Path-Aware Networking |
| |
|
|
In contrast to the present Internet architecture, a path-aware internetworking architecture has two important properties: it exposes the properties of available Internet paths to endpoints, and it provides for endpoints and applications to use these properties to select paths through the Internet for their traffic. While this property of "path awareness" already exists in many Internet- connected networks within single domains and via administrative interfaces to the network layer, a fully path-aware internetwork expands these concepts across layers and across the Internet.
This document poses questions in path-aware networking, open as of2021, that must be answered in the design, development, and deployment of path-aware internetworks. It was originally written to frame discussions in the Path Aware Networking Research Group(PANRG), and has been published to snapshot current thinking in this space. |
|
| |
| RFC 9218 | Extensible Prioritization Scheme for HTTP |
| |
|
|
This document describes a scheme that allows an HTTP client to communicate its preferences for how the upstream server prioritizes responses to its requests, and also allows a server to hint to a downstream intermediary how its responses should be prioritized when they are forwarded. This document defines the Priority header field for communicating the initial priority in an HTTP version-independent manner, as well as HTTP/2 and HTTP/3 frames for reprioritizing responses. These share a common format structure that is designed to provide future extensibility. |
|
| |
| RFC 9219 | S/MIME Signature Verification Extension to the JSON Meta Application Protocol (JMAP) |
| |
|
|
This document specifies an extension to "The JSON Meta ApplicationProtocol (JMAP) for Mail" (RFC 8621) for returning the S/MIME signature verification status. |
|
| |
| RFC 9220 | Bootstrapping WebSockets with HTTP/3 |
| |
|
|
The mechanism for running the WebSocket Protocol over a single stream of an HTTP/2 connection is equally applicable to HTTP/3, but theHTTP-version-specific details need to be specified. This document describes how the mechanism is adapted for HTTP/3. |
|
| |
| RFC 9221 | An Unreliable Datagram Extension to QUIC |
| |
| Authors: | T. Pauly, E. Kinnear, D. Schinazi. |
| Date: | March 2022 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9221 |
|
This document defines an extension to the QUIC transport protocol to add support for sending and receiving unreliable datagrams over aQUIC connection. |
|
| |
| RFC 9222 | Guidelines for Autonomic Service Agents |
| |
| Authors: | B. E. Carpenter, L. Ciavaglia, S. Jiang, P. Peloso. |
| Date: | March 2022 |
| Formats: | txt json pdf html xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9222 |
|
This document proposes guidelines for the design of Autonomic ServiceAgents for autonomic networks. Autonomic Service Agents, together with the Autonomic Network Infrastructure, the Autonomic ControlPlane, and the GeneRic Autonomic Signaling Protocol, constitute base elements of an autonomic networking ecosystem. |
|
| |
| RFC 9223 | Real-Time Transport Object Delivery over Unidirectional Transport (ROUTE) |
| |
| Authors: | W. Zia, T. Stockhammer, L. Chaponniere, G. Mandyam, M. Luby. |
| Date: | April 2022 |
| Formats: | txt json pdf html xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9223 |
|
The Real-time Transport Object delivery over Unidirectional Transport(ROUTE) protocol is specified for robust delivery of ApplicationObjects, including Application Objects with real-time delivery constraints, to receivers over a unidirectional transport.Application Objects consist of data that has meaning to applications that use the ROUTE protocol for delivery of data to receivers; for example, it can be a file, a Dynamic Adaptive Streaming over HTTP(DASH) or HTTP Live Streaming (HLS) segment, a WAV audio clip, etc.The ROUTE protocol also supports low-latency streaming applications.
The ROUTE protocol is suitable for unicast, broadcast, and multicast transport. Therefore, it can be run over UDP/IP, including multicastIP. The ROUTE protocol can leverage the features of the underlying protocol layer, e.g., to provide security, it can leverage IP security protocols such as IPsec.
This document specifies the ROUTE protocol such that it could be used by a variety of services for delivery of Application Objects by specifying their own profiles of this protocol (e.g., by adding or constraining some features).
This is not an IETF specification and does not have IETF consensus. |
|
| |
| RFC 9224 | Finding the Authoritative Registration Data Access Protocol (RDAP) Service |
| |
|
|
This document specifies a method to find which Registration DataAccess Protocol (RDAP) server is authoritative to answer queries for a requested scope, such as domain names, IP addresses, or AutonomousSystem numbers. This document obsoletes RFC 7484. |
|
| |
| RFC 9225 | Software Defects Considered Harmful |
| |
| Authors: | J. Snijders, C. Morrow, R. van Mook. |
| Date: | 1 April 2022 |
| Formats: | txt html pdf xml json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9225 |
|
This document discourages the practice of introducing software defects in general and in network protocol implementations specifically. Software defects are one of the largest cost drivers for the networking industry. This document is intended to clarify the best current practice in this regard. |
|
| |
| RFC 9226 | Bioctal: Hexadecimal 2.0 |
| |
|
|
The prevailing hexadecimal system was chosen for congruence with groups of four binary digits, but its design exhibits an indifference to cognitive factors. An alternative is introduced that is designed to reduce brain cycles in cases where a hexadecimal number should be readily convertible to binary by a human being. |
|
| |
| RFC 9227 | Using GOST Ciphers in the Encapsulating Security Payload (ESP) and Internet Key Exchange Version 2 (IKEv2) Protocols |
| |
|
|
This document defines a set of encryption transforms for use in theEncapsulating Security Payload (ESP) and in the Internet Key Exchange version 2 (IKEv2) protocols, which are parts of the IP Security(IPsec) protocol suite. The transforms are based on the GOST R34.12-2015 block ciphers (which are named "Magma" and "Kuznyechik") in Multilinear Galois Mode (MGM) and the external rekeying approach.
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 9228 | Delivered-To Email Header Field |
| |
|
|
The address to which email is delivered might be different than any of the addresses shown in any of the content header fields that were created by the email's author. For example, the address used by the email transport service is provided separately, such as throughSMTP's "RCPT TO" command, and might not match any address in the To: or cc: fields. In addition, before final delivery, handling can entail a sequence of submission/delivery events, using a sequence of different destination addresses that (eventually) lead to the recipient. As well, a receiving system's delivery process can produce local address transformations.
It can be helpful for a message to have a common way to record each delivery in such a sequence, noting each address used in the sequence to that recipient, such as for (1) analyzing the path a message has taken, (2) loop detection, or (3) formulating the author's address in a reply message. This document defines a header field for this information.
Email handling information discloses details about the email infrastructure, as well as about a particular recipient; this can raise privacy concerns.
A header field such as this is not automatically assured of widespread use. Therefore, this document is being published as anExperimental RFC, looking for constituency and for operational utility. This document was produced through the IndependentSubmission Stream and was not subject to the IETF's approval process. |
|
| |
| RFC 9229 | IPv4 Routes with an IPv6 Next Hop in the Babel Routing Protocol |
| |
|
|
This document defines an extension to the Babel routing protocol that allows announcing routes to an IPv4 prefix with an IPv6 next hop, which makes it possible for IPv4 traffic to flow through interfaces that have not been assigned an IPv4 address. |
|
| |
| RFC 9230 | Oblivious DNS over HTTPS |
| |
| Authors: | E. Kinnear, P. McManus, T. Pauly, T. Verma, C.A. Wood. |
| Date: | June 2022 |
| Formats: | txt pdf html xml json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9230 |
|
This document describes a protocol that allows clients to hide theirIP addresses from DNS resolvers via proxying encrypted DNS over HTTPS(DoH) messages. This improves privacy of DNS operations by not allowing any one server entity to be aware of both the client IP address and the content of DNS queries and answers.
This experimental protocol has been developed outside the IETF and is published here to guide implementation, ensure interoperability among implementations, and enable wide-scale experimentation. |
|
| |
| RFC 9231 | Additional XML Security Uniform Resource Identifiers (URIs) |
| |
|
|
This document updates and corrects the IANA "XML Security URIs" registry that lists URIs intended for use with XML digital signatures, encryption, canonicalization, and key management. TheseURIs identify algorithms and types of information. This document also obsoletes and corrects three errata against RFC 6931. |
|
| |
| RFC 9232 | Network Telemetry Framework |
| |
| Authors: | H. Song, F. Qin, P. Martinez-Julia, L. Ciavaglia, A. Wang. |
| Date: | May 2022 |
| Formats: | txt json html xml pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9232 |
|
Network telemetry is a technology for gaining network insight and facilitating efficient and automated network management. It encompasses various techniques for remote data generation, collection, correlation, and consumption. This document describes an architectural framework for network telemetry, motivated by challenges that are encountered as part of the operation of networks and by the requirements that ensue. This document clarifies the terminology and classifies the modules and components of a network telemetry system from different perspectives. The framework and taxonomy help to set a common ground for the collection of related work and provide guidance for related technique and standard developments. |
|
| |
| RFC 9233 | Internationalized Domain Names for Applications 2008 (IDNA2008) and Unicode 12.0.0 |
| |
|
|
This document describes the changes between Unicode 6.0.0 and Unicode12.0.0 in the context of the current version of InternationalizedDomain Names for Applications 2008 (IDNA2008). Some additions and changes have been made in the Unicode Standard that affect the values produced by the algorithm IDNA2008 specifies. IDNA2008 allows adding exceptions to the algorithm for backward compatibility; however, this document does not add any such exceptions. This document provides the necessary tables to IANA to make its database consistent withUnicode 12.0.0.
To improve understanding, this document describes systems that are being used as alternatives to those that conform to IDNA2008. |
|
| |
| RFC 9234 | Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages |
| |
| Authors: | A. Azimov, E. Bogomazov, R. Bush, K. Patel, K. Sriram. |
| Date: | May 2022 |
| Formats: | txt html xml json pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9234 |
|
Route leaks are the propagation of BGP prefixes that violate assumptions of BGP topology relationships, e.g., announcing a route learned from one transit provider to another transit provider or a lateral (i.e., non-transit) peer or announcing a route learned from one lateral peer to another lateral peer or a transit provider.These are usually the result of misconfigured or absent BGP route filtering or lack of coordination between autonomous systems (ASes).Existing approaches to leak prevention rely on marking routes by operator configuration, with no check that the configuration corresponds to that of the External BGP (eBGP) neighbor, or enforcement of the two eBGP speakers agreeing on the peering relationship. This document enhances the BGP OPEN message to establish an agreement of the peering relationship on each eBGP session between autonomous systems in order to enforce appropriate configuration on both sides. Propagated routes are then marked according to the agreed relationship, allowing both prevention and detection of route leaks. |
|
| |
| RFC 9235 | TCP Authentication Option (TCP-AO) Test Vectors |
| |
|
|
This document provides test vectors to validate implementations of the two mandatory authentication algorithms specified for the TCPAuthentication Option over both IPv4 and IPv6. This includes validation of the key derivation function (KDF) based on a set of test connection parameters as well as validation of the message authentication code (MAC). Vectors are provided for both currently required pairs of KDF and MAC algorithms: KDF_HMAC_SHA1 and HMAC-SHA-1-96, and KDF_AES_128_CMAC and AES-128-CMAC-96. The vectors also validate both whole TCP segments as well as segments whose options are excluded for middlebox traversal. |
|
| |
| RFC 9236 | Architectural Considerations of Information-Centric Networking (ICN) Using a Name Resolution Service |
| |
|
|
This document describes architectural considerations and implications related to the use of a Name Resolution Service (NRS) in Information-Centric Networking (ICN). It explains how the ICN architecture can change when an NRS is utilized and how its use influences the ICN routing system. This document is a product of the Information-Centric Networking Research Group (ICNRG). |
|
| |
| RFC 9237 | An Authorization Information Format (AIF) for Authentication and Authorization for Constrained Environments (ACE) |
| |
|
|
Information about which entities are authorized to perform what operations on which constituents of other entities is a crucial component of producing an overall system that is secure. Conveying precise authorization information is especially critical in highly automated systems with large numbers of entities, such as theInternet of Things.
This specification provides a generic information model and format for representing such authorization information, as well as two variants of a specific instantiation of that format for use withRepresentational State Transfer (REST) resources identified by URI path. |
|
| |
| RFC 9238 | Loading Manufacturer Usage Description (MUD) URLs from QR Codes |
| |
| Authors: | M. Richardson, J. Latour, H. Habibi Gharakheili. |
| Date: | May 2022 |
| Formats: | txt pdf xml html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9238 |
|
This informational document details a protocol to load ManufacturerUsage Description (MUD) definitions from RFC 8520 for devices that do not have them integrated.
This document is published to inform the Internet community of this mechanism to allow interoperability and to serve as a basis of other standards work if there is interest. |
|
| |
| RFC 9239 | Updates to ECMAScript Media Types |
| |
|
|
This document describes the registration of media types for theECMAScript and JavaScript programming languages and conformance requirements for implementations of these types. This document obsoletes RFC 4329 ("Scripting Media Types)", replacing the previous registrations with information and requirements aligned with common usage and implementation experiences. |
|
| |
| RFC 9240 | An Extension for Application-Layer Traffic Optimization (ALTO): Entity Property Maps |
| |
| Authors: | W. Roome, S. Randriamasy, Y. Yang, J. Zhang, K. Gao. |
| Date: | July 2022 |
| Formats: | txt json html xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9240 |
|
This document specifies an extension to the base Application-LayerTraffic Optimization (ALTO) Protocol that generalizes the concept of"endpoint properties", which have been tied to IP addresses so far, to entities defined by a wide set of objects. Further, these properties are presented as maps, similar to the network and cost maps in the base ALTO Protocol. While supporting the endpoints and related Endpoint Property Service defined in RFC 7285, the ALTOProtocol is extended in two major directions. First, from endpoints restricted to IP addresses to entities covering a wider and extensible set of objects; second, from properties for specific endpoints to entire entity property maps. These extensions introduce additional features that allow entities and property values to be specific to a given information resource. This is made possible by a generic and flexible design of entity and property types. |
|
| |
| RFC 9241 | Content Delivery Network Interconnection (CDNI) Footprint and Capabilities Advertisement Using Application-Layer Traffic Optimization (ALTO) |
| |
| Authors: | J. Seedorf, Y. Yang, K. Ma, J. Peterson, J. Zhang. |
| Date: | July 2022 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9241 |
|
The Content Delivery Networks Interconnection (CDNI) framework in RFC6707 defines a set of protocols to interconnect CDNs to achieve multiple goals, including extending the reach of a given CDN. A CDNIRequest Routing Footprint & Capabilities Advertisement interface(FCI) is needed to achieve the goals of a CDNI. RFC 8008 defines theFCI semantics and provides guidelines on the FCI protocol, but the exact protocol is not specified. This document defines a newApplication-Layer Traffic Optimization (ALTO) service, called "CDNIAdvertisement Service", that provides an implementation of the FCI, following the guidelines defined in RFC 8008. |
|
| |
| RFC 9242 | Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
|
This document defines a new exchange, called "Intermediate Exchange", for the Internet Key Exchange Protocol Version 2 (IKEv2). This exchange can be used for transferring large amounts of data in the process of IKEv2 Security Association (SA) establishment. An example of the need to do this is using key exchange methods resistant toQuantum Computers (QCs) for IKE SA establishment. The IntermediateExchange makes it possible to use the existing IKE fragmentation mechanism (which cannot be used in the initial IKEv2 exchange), helping to avoid IP fragmentation of large IKE messages if they need to be sent before IKEv2 SA is established. |
|
| |
| RFC 9243 | A YANG Data Model for DHCPv6 Configuration |
| |
|
|
This document describes YANG data models for the configuration and management of Dynamic Host Configuration Protocol for IPv6 (DHCPv6)(RFC 8415) servers, relays, and clients. |
|
| |
| RFC 9244 | Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry |
| |
| Authors: | M. Boucadair, Ed., T. Reddy.K, Ed., E. Doron, M. Chen, J. Shallow. |
| Date: | June 2022 |
| Formats: | txt pdf xml json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9244 |
|
This document aims to enrich the Distributed Denial-of-Service OpenThreat Signaling (DOTS) signal channel protocol with various telemetry attributes, allowing for optimal Distributed Denial-of-Service (DDoS) attack mitigation. It specifies the normal traffic baseline and attack traffic telemetry attributes a DOTS client can convey to its DOTS server in the mitigation request, the mitigation status telemetry attributes a DOTS server can communicate to a DOTS client, and the mitigation efficacy telemetry attributes a DOTS client can communicate to a DOTS server. The telemetry attributes can assist the mitigator in choosing the DDoS mitigation techniques and performing optimal DDoS attack mitigation.
This document specifies two YANG modules: one for representing DOTS telemetry message types and one for sharing the attack mapping details over the DOTS data channel. |
|
| |
| RFC 9245 | IETF Discussion List Charter |
| |
|
|
The Internet Engineering Task Force (IETF) discussion mailing list furthers the development and specification of Internet technology through the general discussion of technical, procedural, operational, and other topics for which no dedicated mailing lists exist. As this is the most general IETF mailing list, considerable latitude in terms of topics is allowed, but there are posts and topics that are unsuitable for this mailing list. This document defines the charter for the IETF discussion list and explains its scope.
This document obsoletes RFC 3005 and updates RFC 3683. |
|
| |
| RFC 9246 | URI Signing for Content Delivery Network Interconnection (CDNI) |
| |
| Authors: | R. van Brandenburg, K. Leung, P. Sorber. |
| Date: | June 2022 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9246 |
|
This document describes how the concept of URI Signing supports the content access control requirements of Content Delivery NetworkInterconnection (CDNI) and proposes a URI Signing method as a JSONWeb Token (JWT) profile.
The proposed URI Signing method specifies the information needed to be included in the URI to transmit the signed JWT, as well as the claims needed by the signed JWT to authorize a User Agent (UA). The mechanism described can be used both in CDNI and single ContentDelivery Network (CDN) scenarios. |
|
| |
| RFC 9247 | BGP - Link State (BGP-LS) Extensions for Seamless Bidirectional Forwarding Detection (S-BFD) |
| |
| Authors: | Z. Li, S. Zhuang, K. Talaulikar, Ed., S. Aldrin, J. Tantsura, G. Mirsky. |
| Date: | June 2022 |
| Formats: | txt html json xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9247 |
|
Seamless Bidirectional Forwarding Detection (S-BFD) defines a simplified mechanism to use Bidirectional Forwarding Detection (BFD) with large portions of negotiation aspects eliminated, thus providing benefits such as quick provisioning as well as improved control and flexibility to network nodes initiating the path monitoring. The link-state routing protocols (IS-IS and OSPF) have been extended to advertise the S-BFD Discriminators.
This document defines extensions to the BGP - Link State (BGP-LS) address family to carry the S-BFD Discriminators' information viaBGP. |
|
| |
| RFC 9248 | Interoperability Profile for Relay User Equipment |
| |
|
|
Video Relay Service (VRS) is a term used to describe a method by which a hearing person can communicate with a sign language speaker who is deaf, deafblind, or hard of hearing (HoH) or has a speech disability using an interpreter (i.e., a Communications Assistant(CA)) connected via a videophone to the sign language speaker and an audio telephone call to the hearing user. The CA interprets using sign language on the videophone link and voice on the telephone link.Often the interpreters may be employed by a company or agency, termed a "provider" in this document. The provider also provides a video service that allows users to connect video devices to their service and subsequently to CAs and other sign language speakers. It is desirable that the videophones used by the sign language speaker conform to a standard so that any device may be used with any provider and that direct video calls between sign language speakers work. This document describes the interface between a videophone and a provider. |
|
| |
| RFC 9249 | A YANG Data Model for NTP |
| |
| Authors: | N. Wu, D. Dhody, Ed., A. Sinha, Ed., A. Kumar S N, Y. Zhao. |
| Date: | July 2022 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9249 |
|
This document defines a YANG data model that can be used to configure and manage Network Time Protocol (NTP) version 4. It can also be used to configure and manage version 3. The data model includes configuration data and state data. |
|
| |
| RFC 9250 | DNS over Dedicated QUIC Connections |
| |
| Authors: | C. Huitema, S. Dickinson, A. Mankin. |
| Date: | May 2022 |
| Formats: | txt json pdf html xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9250 |
|
This document describes the use of QUIC to provide transport confidentiality for DNS. The encryption provided by QUIC has similar properties to those provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient packet-loss recovery than UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in RFC7858, and latency characteristics similar to classic DNS over UDP.This specification describes the use of DoQ as a general-purpose transport for DNS and includes the use of DoQ for stub to recursive, recursive to authoritative, and zone transfer scenarios. |
|
| |
| RFC 9251 | Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxies for Ethernet VPN (EVPN) |
| |
| Authors: | A. Sajassi, S. Thoria, M. Mishra, K. Patel, J. Drake, W. Lin. |
| Date: | June 2022 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9251 |
|
This document describes how to support endpoints running the InternetGroup Management Protocol (IGMP) or Multicast Listener Discovery(MLD) efficiently for the multicast services over an Ethernet VPN(EVPN) network by incorporating IGMP/MLD Proxy procedures on EVPNProvider Edges (PEs). |
|
| |
| RFC 9252 | BGP Overlay Services Based on Segment Routing over IPv6 (SRv6) |
| |
| Authors: | G. Dawra, Ed., K. Talaulikar, Ed., R. Raszuk, B. Decraene, S. Zhuang, J. Rabadan. |
| Date: | July 2022 |
| Formats: | txt xml pdf html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9252 |
|
This document defines procedures and messages for SRv6-based BGP services, including Layer 3 Virtual Private Network (L3VPN), EthernetVPN (EVPN), and Internet services. It builds on "BGP/MPLS IP VirtualPrivate Networks (VPNs)" (RFC 4364) and "BGP MPLS-Based Ethernet VPN"(RFC 7432). |
|
| |
| RFC 9253 | Support for iCalendar Relationships |
| |
|
|
This specification updates the iCalendar RELATED-TO property defined in RFC 5545 by adding new relation types and introduces new iCalendar properties (LINK, CONCEPT, and REFID) to allow better linking and grouping of iCalendar components and related data. |
|
| |
| RFC 9254 | Encoding of Data Modeled with YANG in the Concise Binary Object Representation (CBOR) |
| |
| Authors: | M. Veillette, Ed., I. Petrov, Ed., A. Pelov, C. Bormann, M. Richardson. |
| Date: | July 2022 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9254 |
|
YANG (RFC 7950) is a data modeling language used to model configuration data, state data, parameters and results of RemoteProcedure Call (RPC) operations or actions, and notifications.
This document defines encoding rules for YANG in the Concise BinaryObject Representation (CBOR) (RFC 8949). |
|
| |
| RFC 9255 | The 'I' in RPKI Does Not Stand for Identity |
| |
|
|
There is a false notion that Internet Number Resources (INRs) in theRPKI can be associated with the real-world identity of the 'holder' of an INR. This document specifies that RPKI does not associate to the INR holder. |
|
| |
| RFC 9256 | Segment Routing Policy Architecture |
| |
| Authors: | C. Filsfils, K. Talaulikar, Ed., D. Voyer, A. Bogdanov, P. Mattes. |
| Date: | July 2022 |
| Formats: | txt html json pdf xml |
| Updates: | RFC 8402 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9256 |
|
Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy.
This document updates RFC 8402 as it details the concepts of SRPolicy and steering into an SR Policy. |
|
| |
| RFC 9257 | Guidance for External Pre-Shared Key (PSK) Usage in TLS |
| |
| Authors: | R. Housley, J. Hoyland, M. Sethi, C. A. Wood. |
| Date: | July 2022 |
| Formats: | txt html pdf xml json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9257 |
|
This document provides usage guidance for external Pre-Shared Keys(PSKs) in Transport Layer Security (TLS) 1.3 as defined in RFC 8446.It lists TLS security properties provided by PSKs under certain assumptions, then it demonstrates how violations of these assumptions lead to attacks. Advice for applications to help meet these assumptions is provided. This document also discusses PSK use cases and provisioning processes. Finally, it lists the privacy and security properties that are not provided by TLS 1.3 when externalPSKs are used. |
|
| |
| RFC 9258 | Importing External Pre-Shared Keys (PSKs) for TLS 1.3 |
| |
|
|
This document describes an interface for importing external Pre-Shared Keys (PSKs) into TLS 1.3. |
|
| |
| RFC 9259 | Operations, Administration, and Maintenance (OAM) in Segment Routing over IPv6 (SRv6) |
| |
| Authors: | Z. Ali, C. Filsfils, S. Matsushima, D. Voyer, M. Chen. |
| Date: | June 2022 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9259 |
|
This document describes how the existing IPv6 mechanisms for ping and traceroute can be used in a Segment Routing over IPv6 (SRv6) network.The document also specifies the OAM flag (O-flag) in the SegmentRouting Header (SRH) for performing controllable and predictable flow sampling from segment endpoints. In addition, the document describes how a centralized monitoring system performs a path continuity check between any nodes within an SRv6 domain. |
|
| |
| RFC 9260 | Stream Control Transmission Protocol |
| |
|
|
This document describes the Stream Control Transmission Protocol(SCTP) and obsoletes RFC 4960. It incorporates the specification of the chunk flags registry from RFC 6096 and the specification of the I bit of DATA chunks from RFC 7053. Therefore, RFCs 6096 and 7053 are also obsoleted by this document. In addition, RFCs 4460 and 8540, which describe errata for SCTP, are obsoleted by this document.
SCTP was originally designed to transport Public Switched TelephoneNetwork (PSTN) signaling messages over IP networks. It is also suited to be used for other applications, for example, WebRTC.
SCTP is a reliable transport protocol operating on top of a connectionless packet network, such as IP. It offers the following services to its users:
* acknowledged error-free, non-duplicated transfer of user data,
* data fragmentation to conform to discovered Path MaximumTransmission Unit (PMTU) size,
* sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages,
* optional bundling of multiple user messages into a single SCTP packet, and
* network-level fault tolerance through supporting of multi-homing at either or both ends of an association.
The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. |
|
| |
| RFC 9261 | Exported Authenticators in TLS |
| |
|
|
This document describes a mechanism that builds on Transport LayerSecurity (TLS) or Datagram Transport Layer Security (DTLS) and enables peers to provide proof of ownership of an identity, such as an X.509 certificate. This proof can be exported by one peer, transmitted out of band to the other peer, and verified by the receiving peer. |
|
| |
| RFC 9262 | Tree Engineering for Bit Index Explicit Replication (BIER-TE) |
| |
| Authors: | T. Eckert, Ed., M. Menth, G. Cauchie. |
| Date: | October 2022 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9262 |
|
This memo describes per-packet stateless strict and loose path steered replication and forwarding for "Bit Index ExplicitReplication" (BIER) packets (RFC 8279); it is called "TreeEngineering for Bit Index Explicit Replication" (BIER-TE) and is intended to be used as the path steering mechanism for TrafficEngineering with BIER.
BIER-TE introduces a new semantic for "bit positions" (BPs). TheseBPs indicate adjacencies of the network topology, as opposed to (non-TE) BIER in which BPs indicate "Bit-Forwarding Egress Routers"(BFERs). A BIER-TE "packets BitString" therefore indicates the edges of the (loop-free) tree across which the packets are forwarded byBIER-TE. BIER-TE can leverage BIER forwarding engines with little changes. Co-existence of BIER and BIER-TE forwarding in the same domain is possible -- for example, by using separate BIER"subdomains" (SDs). Except for the optional routed adjacencies,BIER-TE does not require a BIER routing underlay and can therefore operate without depending on a routing protocol such as the "InteriorGateway Protocol" (IGP). |
|
| |
| RFC 9263 | Network Service Header (NSH) Metadata Type 2 Variable-Length Context Headers |
| |
| Authors: | Y. Wei, Ed., U. Elzur, S. Majee, C. Pignataro, D. Eastlake 3rd. |
| Date: | August 2022 |
| Formats: | txt html json pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9263 |
|
Service Function Chaining (SFC) uses the Network Service Header (NSH)(RFC 8300) to steer and provide context metadata (MD) with each packet. Such metadata can be of various types, including MD Type 2, consisting of Variable-Length Context Headers. This document specifies several such Context Headers that can be used within aService Function Path (SFP). |
|
| |
| RFC 9264 | Linkset: Media Types and a Link Relation Type for Link Sets |
| |
| Authors: | E. Wilde, H. Van de Sompel. |
| Date: | July 2022 |
| Formats: | txt json pdf html xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9264 |
|
This specification defines two formats and associated media types for representing sets of links as standalone documents. One format is based on JSON, and the other is aligned with the format for representing links in the HTTP "Link" header field. This specification also introduces a link relation type to support the discovery of sets of links. |
|
| |
| RFC 9265 | Forward Erasure Correction (FEC) Coding and Congestion Control in Transport |
| |
| Authors: | N. Kuhn, E. Lochin, F. Michel, M. Welzl. |
| Date: | July 2022 |
| Formats: | txt json pdf html xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9265 |
|
Forward Erasure Correction (FEC) is a reliability mechanism that is distinct and separate from the retransmission logic in reliable transfer protocols such as TCP. FEC coding can help deal with losses at the end of transfers or with networks having non-congestion losses. However, FEC coding mechanisms should not hide congestion signals. This memo offers a discussion of how FEC coding and congestion control can coexist. Another objective is to encourage the research community to also consider congestion control aspects when proposing and comparing FEC coding solutions in communication systems.
This document is the product of the Coding for Efficient NetworkCommunications Research Group (NWCRG). The scope of the document is end-to-end communications; FEC coding for tunnels is out of the scope of the document. |
|
| |
| RFC 9266 | Channel Bindings for TLS 1.3 |
| |
|
|
This document defines a channel binding type, tls-exporter, that is compatible with TLS 1.3 in accordance with RFC 5056, "On the Use ofChannel Bindings to Secure Channels". Furthermore, it updates the default channel binding to the new binding for versions of TLS greater than 1.2. This document updates RFCs 5801, 5802, 5929, and7677. |
|
| |
| RFC 9267 | Common Implementation Anti-Patterns Related to Domain Name System (DNS) Resource Record (RR) Processing |
| |
| Authors: | S. Dashevskyi, D. dos Santos, J. Wetzels, A. Amri. |
| Date: | July 2022 |
| Formats: | txt xml pdf html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9267 |
|
This memo describes common vulnerabilities related to Domain NameSystem (DNS) resource record (RR) processing as seen in several DNS client implementations. These vulnerabilities may lead to successfulDenial-of-Service and Remote Code Execution attacks against the affected software. Where applicable, violations of RFC 1035 are mentioned. |
|
| |
| RFC 9268 | IPv6 Minimum Path MTU Hop-by-Hop Option |
| |
|
|
This document specifies a new IPv6 Hop-by-Hop Option that is used to record the Minimum Path MTU (PMTU) along the forward path between a source host to a destination host. The recorded value can then be communicated back to the source using the return Path MTU field in the Option. |
|
| |
| RFC 9269 | Experimental Scenarios of Information-Centric Networking (ICN) Integration in 4G Mobile Networks |
| |
| Authors: | P. Suthar, M. Stolic, A. Jangam, Ed., D. Trossen, R. Ravindran. |
| Date: | August 2022 |
| Formats: | txt xml pdf json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9269 |
|
A 4G mobile network uses IP-based transport for the control plane to establish the data session at the user plane for the actual data delivery. In the existing architecture, IP-based unicast is used for the delivery of multimedia content to a mobile terminal, where each user is receiving a separate stream from the server. From a bandwidth and routing perspective, this approach is inefficient.Evolved multimedia broadcast and multicast service (eMBMS) provides capabilities for delivering contents to multiple users simultaneously, but its deployment is very limited or at an experimental stage due to numerous challenges. The focus of this document is to list the options for using Information-CentricNetworking (ICN) in 4G mobile networks and elaborate the experimental setups for its further evaluation. The experimental setups discussed provide guidance for using ICN either natively or with an existing mobility protocol stack. With further investigations based on the listed experiments, ICN with its inherent capabilities such as network-layer multicast, anchorless mobility, security, and optimized data delivery using local caching at the edge may provide a viable alternative to IP transport in 4G mobile networks. |
|
| |
| RFC 9270 | GMPLS Signaling Extensions for Shared Mesh Protection |
| |
|
|
ITU-T Recommendation G.808.3 defines the generic aspects of a SharedMesh Protection (SMP) mechanism, where the difference between SMP andShared Mesh Restoration (SMR) is also identified. ITU-TRecommendation G.873.3 defines the protection switching operation and associated protocol for SMP at the Optical Data Unit (ODU) layer.RFC 7412 provides requirements for any mechanism that would be used to implement SMP in a Multi-Protocol Label Switching - TransportProfile (MPLS-TP) network.
This document updates RFCs 4872 and 4873 to provide extensions forGeneralized Multi-Protocol Label Switching (GMPLS) signaling to support the control of the SMP mechanism. |
|
| |
| RFC 9271 | Uninterruptible Power Supply (UPS) Management Protocol -- Commands and Responses |
| |
|
|
This document describes the command/response protocol currently used in the management of Uninterruptible Power Supply (UPS) units and other power devices often deployed in small offices and in IT installations subject to an erratic public power supply. The UPS units typically interface to an Attachment Daemon in the system they protect. This daemon is in turn polled by a Management Daemon that notifies users and system administrators of power supply incidents and automates system shutdown decisions. The commands and responses described by this document are exchanged between the UPS AttachmentDaemon and the Management Daemon. The practice current when this protocol was first developed risks weak security, and this is addressed in the Security Considerations sections of this document. |
|
| |
| RFC 9272 | Underlay Path Calculation Algorithm and Constraints for Bit Index Explicit Replication (BIER) |
| |
| Authors: | Z. Zhang, T. Przygienda, A. Dolganow, H. Bidgoli, IJ. Wijnands, A. Gulko. |
| Date: | September 2022 |
| Formats: | txt html json xml pdf |
| Updates: | RFC 8401, RFC 8444 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9272 |
|
This document specifies general rules for the interaction between theBIER Algorithm (BAR) and the IGP Algorithm (IPA) used for underlay path calculation within the Bit Index Explicit Replication (BIER) architecture. The semantics defined in this document update RFC 8401 and RFC 8444. This document also updates the "BIER Algorithm" registry established in RFC 8401. |
|
| |
| RFC 9273 | Network Coding for Content-Centric Networking / Named Data Networking: Considerations and Challenges |
| |
| Authors: | K. Matsuzono, H. Asaeda, C. Westphal. |
| Date: | August 2022 |
| Formats: | txt html xml json pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9273 |
|
This document describes the current research outcomes in NetworkCoding (NC) for Content-Centric Networking (CCNx) / Named DataNetworking (NDN) and clarifies the technical considerations and potential challenges for applying NC in CCNx/NDN. This document is the product of the Coding for Efficient Network CommunicationsResearch Group (NWCRG) and the Information-Centric NetworkingResearch Group (ICNRG). |
|
| |
| RFC 9274 | A Cost Mode Registry for the Application-Layer Traffic Optimization (ALTO) Protocol |
| |
|
|
This document creates a new IANA registry for tracking cost modes supported by the Application-Layer Traffic Optimization (ALTO)Protocol. Also, this document relaxes a constraint that was imposed by the ALTO specification on allowed cost mode values.
This document updates RFC 7285. |
|
| |
| RFC 9275 | An Extension for Application-Layer Traffic Optimization (ALTO): Path Vector |
| |
| Authors: | K. Gao, Y. Lee, S. Randriamasy, Y. Yang, J. Zhang. |
| Date: | September 2022 |
| Formats: | txt json html xml pdf |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9275 |
|
This document is an extension to the base Application-Layer TrafficOptimization (ALTO) protocol. It extends the ALTO cost map and ALTO property map services so that an application can decide to which endpoint(s) to connect based not only on numerical/ordinal cost values but also on fine-grained abstract information regarding the paths. This is useful for applications whose performance is impacted by specific components of a network on the end-to-end paths, e.g., they may infer that several paths share common links and prevent traffic bottlenecks by avoiding such paths. This extension introduces a new abstraction called the "Abstract Network Element"(ANE) to represent these components and encodes a network path as a vector of ANEs. Thus, it provides a more complete but still abstract graph representation of the underlying network(s) for informed traffic optimization among endpoints. |
|
| |
| RFC 9276 | Guidance for NSEC3 Parameter Settings |
| |
|
|
NSEC3 is a DNSSEC mechanism providing proof of nonexistence by asserting that there are no names that exist between two domain names within a zone. Unlike its counterpart NSEC, NSEC3 avoids directly disclosing the bounding domain name pairs. This document provides guidance on setting NSEC3 parameters based on recent operational deployment experience. This document updates RFC 5155 with guidance about selecting NSEC3 iteration and salt parameters. |
|
| |
| RFC 9277 | On Stable Storage for Items in Concise Binary Object Representation (CBOR) |
| |
| Authors: | M. Richardson, C. Bormann. |
| Date: | August 2022 |
| Formats: | txt pdf html xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9277 |
|
This document defines a stored ("file") format for Concise BinaryObject Representation (CBOR) data items that is friendly to common systems that recognize file types, such as the Unix file(1) command. |
|
| |
| RFC 9278 | JWK Thumbprint URI |
| |
|
|
This specification registers a kind of URI that represents a JSON WebKey (JWK) Thumbprint value. JWK Thumbprints are defined in RFC 7638.This enables JWK Thumbprints to be used, for instance, as key identifiers in contexts requiring URIs. |
|
| |
| RFC 9279 | Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Message Extension |
| |
| Authors: | M. Sivakumar, S. Venaas, Z. Zhang, H. Asaeda. |
| Date: | August 2022 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9279 |
|
This document specifies a generic mechanism to extend IGMPv3 andMulticast Listener Discovery Version 2 (MLDv2) by using a list ofTLVs (Type, Length, and Value). |
|
| |
| RFC 9280 | RFC Editor Model (Version 3) |
| |
|
|
This document specifies version 3 of the RFC Editor Model. The model defines two high-level tasks related to the RFC Series. First, policy definition is the joint responsibility of the RFC SeriesWorking Group (RSWG), which produces policy proposals, and the RFCSeries Approval Board (RSAB), which approves such proposals. Second, policy implementation is primarily the responsibility of the RFCProduction Center (RPC) as contractually overseen by the IETFAdministration Limited Liability Company (IETF LLC). In addition, various responsibilities of the RFC Editor function are now performed alone or in combination by the RSWG, RSAB, RPC, RFC Series ConsultingEditor (RSCE), and IETF LLC. Finally, this document establishes theEditorial Stream for publication of future policy definition documents produced through the processes defined herein.
This document obsoletes RFC 8728. This document updates RFCs 7841,8729, and 8730. |
|
| |
| RFC 9281 | Entities Involved in the IETF Standards Process |
| |
|
|
This document describes the individuals and organizations involved in the IETF standards process, as described in BCP 9. It includes brief descriptions of the entities involved and the role they play in the standards process.
The IETF and its structure have undergone many changes since RFC 2028 was published in 1996. This document reflects the changed organizational structure of the IETF and obsoletes RFC 2028. |
|
| |
| RFC 9282 | Responsibility Change for the RFC Series |
| |
|
|
In RFC 9280, responsibility for the RFC Series moved to the RFCSeries Working Group and the RFC Series Approval Board. It is no longer the responsibility of the RFC Editor, and the role of the IAB in the RFC Series is altered. Accordingly, in Section 2.1 of RFC2026, the sentence "RFC publication is the direct responsibility of the RFC Editor, under the general direction of the IAB" is deleted. |
|
| |
| RFC 9283 | IAB Charter Update for RFC Editor Model |
| |
|
|
This document updates the IAB Charter (RFC 2850) to be consistent with version 3 of the RFC Editor Model (RFC 9280). |
|
| |
| RFC 9284 | Multihoming Deployment Considerations for DDoS Open Threat Signaling (DOTS) |
| |
| Authors: | M. Boucadair, T. Reddy.K, W. Pan. |
| Date: | August 2022 |
| Formats: | txt xml pdf json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9284 |
|
This document discusses multihoming considerations for DDoS OpenThreat Signaling (DOTS). The goal is to provide some guidance forDOTS clients and client-domain DOTS gateways when multihomed. |
|
| |
| RFC 9285 | The Base45 Data Encoding |
| |
| Authors: | P. Fältström, F. Ljunggren, D.W. van Gulik. |
| Date: | August 2022 |
| Formats: | txt json xml pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9285 |
|
This document describes the Base45 encoding scheme, which is built upon the Base64, Base32, and Base16 encoding schemes. |
|
| |
| RFC 9286 | Manifests for the Resource Public Key Infrastructure (RPKI) |
| |
|
|
This document defines a "manifest" for use in the Resource Public KeyInfrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate,Certificate Revocation List (CRL), or other type of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object and a hash of the file content. Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository. Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect replay attacks, and unauthorized in-flight modification or deletion of signed objects. This document obsoletes RFC 6486. |
|
| |
| RFC 9287 | Greasing the QUIC Bit |
| |
|
|
This document describes a method for negotiating the ability to send an arbitrary value for the second-most significant bit in QUIC packets. |
|
| |
| RFC 9288 | Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers |
| |
|
|
This document analyzes the security implications of IPv6 ExtensionHeaders and associated IPv6 options. Additionally, it discusses the operational and interoperability implications of discarding packets based on the IPv6 Extension Headers and IPv6 options they contain.Finally, it provides advice on the filtering of such IPv6 packets at transit routers for traffic not directed to them, for those cases where such filtering is deemed as necessary. |
|
| |
| RFC 9289 | Towards Remote Procedure Call Encryption by Default |
| |
|
|
This document describes a mechanism that, through the use of opportunistic Transport Layer Security (TLS), enables encryption ofRemote Procedure Call (RPC) transactions while they are in transit.The proposed mechanism interoperates with Open Network Computing(ONC) RPC implementations that do not support it. This document updates RFC 5531. |
|
| |
| RFC 9290 | Concise Problem Details for Constrained Application Protocol (CoAP) APIs |
| |
| Authors: | T. Fossati, C. Bormann. |
| Date: | October 2022 |
| Formats: | txt json xml html pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9290 |
|
This document defines a concise "problem detail" as a way to carry machine-readable details of errors in a Representational StateTransfer (REST) response to avoid the need to define new error response formats for REST APIs for constrained environments. The format is inspired by, but intended to be more concise than, the problem details for HTTP APIs defined in RFC 7807. |
|
| |
| RFC 9291 | A YANG Network Data Model for Layer 2 VPNs |
| |
| Authors: | M. Boucadair, Ed., O. Gonzalez de Dios, Ed., S. Barguil, L. Munoz. |
| Date: | September 2022 |
| Formats: | txt json xml html pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9291 |
|
This document defines an L2VPN Network Model (L2NM) that can be used to manage the provisioning of Layer 2 Virtual Private Network (L2VPN) services within a network (e.g., a service provider network). TheL2NM complements the L2VPN Service Model (L2SM) by providing a network-centric view of the service that is internal to a service provider. The L2NM is particularly meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices.
Also, this document defines a YANG module to manage Ethernet segments and the initial versions of two IANA-maintained modules that include a set of identities of BGP Layer 2 encapsulation types and pseudowire types. |
|
| |
| RFC 9292 | Binary Representation of HTTP Messages |
| |
| Authors: | M. Thomson, C. A. Wood. |
| Date: | August 2022 |
| Formats: | txt pdf xml html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9292 |
|
This document defines a binary format for representing HTTP messages. |
|
| |
| RFC 9293 | Transmission Control Protocol (TCP) |
| |
|
|
This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793.This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093,6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits fromRFC 793 have also been updated based on RFC 3168. |
|
| |
| RFC 9294 | Application-Specific Link Attributes Advertisement Using the Border Gateway Protocol - Link State (BGP-LS) |
| |
| Authors: | K. Talaulikar, Ed., P. Psenak, J. Tantsura. |
| Date: | August 2022 |
| Formats: | txt pdf json xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9294 |
|
Extensions have been defined for link-state routing protocols that enable distribution of application-specific link attributes for existing as well as newer applications such as Segment Routing (SR).This document defines extensions to the Border Gateway Protocol -Link State (BGP-LS) to enable the advertisement of these application- specific attributes as a part of the topology information from the network. |
|
| |
| RFC 9295 | Clarifications for Ed25519, Ed448, X25519, and X448 Algorithm Identifiers |
| |
| Authors: | S. Turner, S. Josefsson, D. McCarney, T. Ito. |
| Date: | September 2022 |
| Formats: | txt pdf xml json html |
| Updates: | RFC 8410 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9295 |
|
This document updates RFC 8410 to clarify existing semantics, and specify missing semantics, for key usage bits when used in certificates that support the Ed25519, Ed448, X25519, and X448Elliptic Curve Cryptography algorithms. |
|
| |
| RFC 9296 | ifStackTable for the Point-to-Point (P2P) Interface over a LAN Type: Definition and Examples |
| |
| Authors: | D. Liu, J. Halpern, C. Zhang. |
| Date: | August 2022 |
| Formats: | txt html json xml pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9296 |
|
RFC 5309 defines the Point-to-Point (P2P) circuit type, one of the two circuit types used in the link-state routing protocols, and highlights that it is important to identify the correct circuit type when forming adjacencies, flooding link-state database packets, and monitoring the link state.
This document provides advice about the ifStack for the P2P interface over a LAN Type to facilitate operational control, maintenance, and statistics. |
|
| |
| RFC 9297 | HTTP Datagrams and the Capsule Protocol |
| |
| Authors: | D. Schinazi, L. Pardue. |
| Date: | August 2022 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9297 |
|
This document describes HTTP Datagrams, a convention for conveying multiplexed, potentially unreliable datagrams inside an HTTP connection.
In HTTP/3, HTTP Datagrams can be sent unreliably using the QUICDATAGRAM extension. When the QUIC DATAGRAM frame is unavailable or undesirable, HTTP Datagrams can be sent using the Capsule Protocol, which is a more general convention for conveying data in HTTP connections.
HTTP Datagrams and the Capsule Protocol are intended for use by HTTP extensions, not applications. |
|
| |
| RFC 9298 | Proxying UDP in HTTP |
| |
|
|
This document describes how to proxy UDP in HTTP, similar to how theHTTP CONNECT method allows proxying TCP in HTTP. More specifically, this document defines a protocol that allows an HTTP client to create a tunnel for UDP communications through an HTTP server that acts as a proxy. |
|
| |
| RFC 9299 | An Architectural Introduction to the Locator/ID Separation Protocol (LISP) |
| |
| Authors: | A. Cabellos, D. Saucez, Ed.. |
| Date: | October 2022 |
| Formats: | txt json xml pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9299 |
|
This document describes the architecture of the Locator/ID SeparationProtocol (LISP), making it easier to read the rest of the LISP specifications and providing a basis for discussion about the details of the LISP protocols. This document is used for introductory purposes; more details can be found in the protocol specifications,RFCs 9300 and 9301. |
|
