| |
| RFC 9500 | Standard Public Key Cryptography (PKC) Test Keys |
| |
|
|
This document provides a set of standard Public Key Cryptography(PKC) test keys that may be used wherever pre-generated keys and associated operations like digital signatures are required. Like theEuropean Institute for Computer Antivirus Research (EICAR) virus test and the Generic Test for Unsolicited Bulk Email (GTUBE) spam test files, these publicly known test keys can be detected and recognised by applications consuming them as being purely for testing purposes without assigning any security properties to them. |
|
| |
| RFC 9501 | Open Participation Principle regarding Remote Registration Fee |
| |
|
|
This document outlines a principle for open participation that extends the open process principle defined in RFC 3935 by stating that there must be a free option for online participation to IETF meetings and, if possible, related IETF-hosted events. |
|
| |
| RFC 9502 | IGP Flexible Algorithm in IP Networks |
| |
| Authors: | W. Britto, S. Hegde, P. Kaneriya, R. Shetty, R. Bonica, P. Psenak. |
| Date: | November 2023 |
| Formats: | txt html xml json pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9502 |
|
This document extends IGP Flexible Algorithm so that it can be used with regular IPv4 and IPv6 forwarding. |
|
| |
| RFC 9503 | Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Segment Routing Networks |
| |
| Authors: | R. Gandhi, Ed., C. Filsfils, M. Chen, B. Janssens, R. Foote. |
| Date: | October 2023 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9503 |
|
Segment Routing (SR) leverages the source routing paradigm. SR is applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6(SRv6) forwarding planes. This document specifies Simple Two-WayActive Measurement Protocol (STAMP) extensions (as described in RFC8762) for SR networks, for both the SR-MPLS and SRv6 forwarding planes, by augmenting the optional extensions defined in RFC 8972. |
|
| |
| RFC 9504 | Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE Usage in GMPLS-Controlled Networks |
| |
| Authors: | Y. Lee, H. Zheng, O. Gonzalez de Dios, V. Lopez, Z. Ali. |
| Date: | December 2023 |
| Formats: | txt json html xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9504 |
|
The Path Computation Element Communication Protocol (PCEP) has been extended to support stateful PCE functions where the stateful PCE maintains information about paths and resource usage within a network; however, these extensions do not cover all requirements forGMPLS networks.
This document provides the extensions required for PCEP so as to enable the usage of a stateful PCE capability in GMPLS-controlled networks. |
|
| |
| RFC 9505 | A Survey of Worldwide Censorship Techniques |
| |
| Authors: | J. L. Hall, M. D. Aaron, A. Andersdotter, B. Jones, N. Feamster, M. Knodel. |
| Date: | November 2023 |
| Formats: | txt json xml pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9505 |
|
This document describes technical mechanisms employed in network censorship that regimes around the world use for blocking or impairing Internet traffic. It aims to make designers, implementers, and users of Internet protocols aware of the properties exploited and mechanisms used for censoring end-user access to information. This document makes no suggestions on individual protocol considerations, and is purely informational, intended as a reference. This document is a product of the Privacy Enhancement and Assessment Research Group(PEARG) in the IRTF. |
|
| |
| RFC 9506 | Explicit Host-to-Network Flow Measurements Techniques |
| |
| Authors: | M. Cociglio, A. Ferrieux, G. Fioccola, I. Lubashev, F. Bulgarella, M. Nilo, I. Hamchaoui, R. Sisto. |
| Date: | October 2023 |
| Formats: | txt html pdf xml json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9506 |
|
This document describes protocol-independent methods called ExplicitHost-to-Network Flow Measurement Techniques that can be applicable to transport-layer protocols between the client and server. These methods employ just a few marking bits inside the header of each packet for performance measurements and require the client and server to collaborate. Both endpoints cooperate by marking packets and, possibly, mirroring the markings on the round-trip connection. The techniques are especially valuable when applied to protocols that encrypt transport headers since they enable loss and delay measurements by passive, on-path network devices. This document describes several methods that can be used separately or jointly depending of the availability of marking bits, desired measurements, and properties of the protocol to which the methods are applied. |
|
| |
| RFC 9507 | Information-Centric Networking (ICN) Traceroute Protocol Specification |
| |
| Authors: | S. Mastorakis, D. Oran, I. Moiseenko, J. Gibson, R. Droms. |
| Date: | March 2024 |
| Formats: | txt pdf xml html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9507 |
|
This document presents the design of an Information-CentricNetworking (ICN) Traceroute protocol. This includes the operation of both the client and the forwarder.
This document is a product of the Information-Centric NetworkingResearch Group (ICNRG) of the IRTF. |
|
| |
| RFC 9508 | Information-Centric Networking (ICN) Ping Protocol Specification |
| |
| Authors: | S. Mastorakis, D. Oran, J. Gibson, I. Moiseenko, R. Droms. |
| Date: | March 2024 |
| Formats: | txt pdf json xml html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9508 |
|
This document presents the design of an Information-CentricNetworking (ICN) Ping protocol. It includes the operations of both the client and the forwarder.
This document is a product of the Information-Centric NetworkingResearch Group (ICNRG) of the IRTF. |
|
| |
| RFC 9509 | X.509 Certificate Extended Key Usage (EKU) for 5G Network Functions |
| |
| Authors: | T. Reddy.K, J. Ekman, D. Migault. |
| Date: | March 2024 |
| Formats: | txt pdf json xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9509 |
|
RFC 5280 specifies several extended key purpose identifiers(KeyPurposeIds) for X.509 certificates. This document defines encrypting JSON objects in HTTP messages, using JSON Web Tokens(JWTs), and signing the OAuth 2.0 access tokens KeyPurposeIds for inclusion in the Extended Key Usage (EKU) extension of X.509 v3 public key certificates used by Network Functions (NFs) for the 5GSystem. |
|
| |
| RFC 9510 | Alternative Delta Time Encoding for Content-Centric Networking (CCNx) Using Compact Floating-Point Arithmetic |
| |
|
|
Content-Centric Networking (CCNx) utilizes delta time for a number of functions. When using CCNx in environments with constrained nodes or bandwidth-constrained networks, it is valuable to have a compressed representation of delta time. In order to do so, either accuracy or dynamic range has to be sacrificed. Since the current uses of delta time do not require both simultaneously, one can consider a logarithmic encoding. This document updates RFC 8609 ("CCNx messages in TLV Format") to specify this alternative encoding.
This document is a product of the IRTF Information-Centric NetworkingResearch Group (ICNRG). |
|
| |
| RFC 9511 | Attribution of Internet Probes |
| |
| Authors: | É. Vyncke, B. Donnet, J. Iurman. |
| Date: | November 2023 |
| Formats: | txt xml json pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9511 |
|
Active measurements over the public Internet can target either collaborating parties or non-collaborating ones. Sometimes these measurements, also called "probes", are viewed as unwelcome or aggressive.
This document suggests some simple techniques for a source to identify its probes. This allows any party or organization to understand what an unsolicited probe packet is, what its purpose is, and, most importantly, who to contact. The technique relies on offline analysis of the probe; therefore, it does not require any change in the data or control plane. It has been designed mainly for layer 3 measurements. |
|
| |
| RFC 9512 | YAML Media Type |
| |
| Authors: | R. Polli, E. Wilde, E. Aro. |
| Date: | February 2024 |
| Formats: | txt html json pdf xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9512 |
|
This document registers the application/yaml media type and the +yaml structured syntax suffix with IANA. Both identify document components that are serialized according to the YAML specification. |
|
| |
| RFC 9513 | OSPFv3 Extensions for Segment Routing over IPv6 (SRv6) |
| |
| Authors: | Z. Li, Z. Hu, K. Talaulikar, Ed., P. Psenak. |
| Date: | December 2023 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9513 |
|
The Segment Routing (SR) architecture allows a flexible definition of the end-to-end path by encoding it as a sequence of topological elements called segments. It can be implemented over an MPLS or IPv6 data plane. This document describes the OSPFv3 extensions required to support SR over the IPv6 data plane. |
|
| |
| RFC 9514 | Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing over IPv6 (SRv6) |
| |
| Authors: | G. Dawra, C. Filsfils, K. Talaulikar, Ed., M. Chen, D. Bernier, B. Decraene. |
| Date: | December 2023 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9514 |
|
Segment Routing over IPv6 (SRv6) allows for a flexible definition of end-to-end paths within various topologies by encoding paths as sequences of topological or functional sub-paths called "segments".These segments are advertised by various protocols such as BGP, IS-IS, and OSPFv3.
This document defines extensions to BGP - Link State (BGP-LS) to advertise SRv6 segments along with their behaviors and other attributes via BGP. The BGP-LS address-family solution for SRv6 described in this document is similar to BGP-LS for SR for the MPLS data plane, which is defined in RFC 9085. |
|
| |
| RFC 9515 | Revision to Registration Procedures for Multiple BMP Registries |
| |
|
|
This document updates RFC 7854, "BGP Monitoring Protocol (BMP)", by changing the registration procedures for several registries.Specifically, any BMP registry with a range of 32768-65530 designated"Specification Required" has that range redesignated as "First ComeFirst Served". |
|
| |
| RFC 9516 | Active Operations, Administration, and Maintenance (OAM) for Service Function Chaining (SFC) |
| |
| Authors: | G. Mirsky, W. Meng, T. Ao, B. Khasnabish, K. Leung, G. Mishra. |
| Date: | November 2023 |
| Formats: | txt xml pdf html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9516 |
|
A set of requirements for active Operations, Administration, andMaintenance (OAM) for Service Function Chaining (SFC) in a network is presented in this document. Based on these requirements, an encapsulation of active OAM messages in SFC and a mechanism to detect and localize defects are described. |
|
| |
| RFC 9517 | A URN Namespace for the Data Documentation Initiative (DDI) |
| |
|
|
This document describes the Namespace Identifier (NID) "ddi" forUniform Resource Names (URNs) used to identify resources that conform to the standards published by the Data Documentation Initiative (DDI)Alliance.
The DDI Alliance is not affiliated with the Internet Engineering TaskForce (IETF) or Internet Society (ISOC). This Independent Submission is not a standard nor does it have IETF community consensus. |
|
| |
| RFC 9518 | Centralization, Decentralization, and Internet Standards |
| |
|
|
This document discusses aspects of centralization that relate toInternet standards efforts. It argues that, while standards bodies have a limited ability to prevent many forms of centralization, they can still make contributions that assist in the decentralization of the Internet. |
|
| |
| RFC 9519 | Update to the IANA SSH Protocol Parameters Registry Requirements |
| |
|
|
This specification updates the registration policies for adding new entries to registries within the IANA "Secure Shell (SSH) ProtocolParameters" group of registries. Previously, the registration policy was generally IETF Review, as defined in RFC 8126, although a few registries require Standards Action. This specification changes it from IETF Review to Expert Review. This document updates RFCs 4250,4716, 4819, and 8308. |
|
| |
| RFC 9520 | Negative Caching of DNS Resolution Failures |
| |
|
|
In the DNS, resolvers employ caching to reduce both latency for end users and load on authoritative name servers. The process of resolution may result in one of three types of responses: (1) a response containing the requested data, (2) a response indicating the requested data does not exist, or (3) a non-response due to a resolution failure in which the resolver does not receive any useful information regarding the data's existence. This document concerns itself only with the third type.
RFC 2308 specifies requirements for DNS negative caching. There, caching of TYPE 2 responses is mandatory and caching of TYPE 3 responses is optional. This document updates RFC 2308 to require negative caching for DNS resolution failures.
RFC 4035 allows DNSSEC validation failure caching. This document updates RFC 4035 to require caching for DNSSEC validation failures.
RFC 4697 prohibits aggressive requerying for NS records at a failed zone's parent zone. This document updates RFC 4697 to expand this requirement to all query types and to all ancestor zones. |
|
| |
| RFC 9521 | Bidirectional Forwarding Detection (BFD) for Generic Network Virtualization Encapsulation (Geneve) |
| |
| Authors: | X. Min, G. Mirsky, S. Pallagatti, J. Tantsura, S. Aldrin. |
| Date: | January 2024 |
| Formats: | txt json pdf html xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9521 |
|
This document describes the use of the Bidirectional ForwardingDetection (BFD) protocol in point-to-point Generic NetworkVirtualization Encapsulation (Geneve) unicast tunnels used to make up an overlay network. |
|
| |
| RFC 9522 | Overview and Principles of Internet Traffic Engineering |
| |
|
|
This document describes the principles of traffic engineering (TE) in the Internet. The document is intended to promote better understanding of the issues surrounding traffic engineering in IP networks and the networks that support IP networking and to provide a common basis for the development of traffic-engineering capabilities for the Internet. The principles, architectures, and methodologies for performance evaluation and performance optimization of operational networks are also discussed.
This work was first published as RFC 3272 in May 2002. This document obsoletes RFC 3272 by making a complete update to bring the text in line with best current practices for Internet traffic engineering and to include references to the latest relevant work in the IETF. |
|
| |
| RFC 9523 | A Secure Selection and Filtering Mechanism for the Network Time Protocol with Khronos |
| |
| Authors: | N. Rozen-Schiff, D. Dolev, T. Mizrahi, M. Schapira. |
| Date: | February 2024 |
| Formats: | txt xml pdf html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9523 |
|
The Network Time Protocol version 4 (NTPv4), as defined in RFC 5905, is the mechanism used by NTP clients to synchronize with NTP servers across the Internet. This document describes a companion application to the NTPv4 client, named "Khronos", that is used as a "watchdog" alongside NTPv4 and that provides improved security against time- shifting attacks. Khronos involves changes to the NTP client's system process only. Since it does not affect the wire protocol, theKhronos mechanism is applicable to current and future time protocols. |
|
| |
| RFC 9524 | Segment Routing Replication for Multipoint Service Delivery |
| |
| Authors: | D. Voyer, Ed., C. Filsfils, R. Parekh, H. Bidgoli, Z. Zhang. |
| Date: | February 2024 |
| Formats: | txt xml json pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9524 |
|
This document describes the Segment Routing Replication segment for multipoint service delivery. A Replication segment allows a packet to be replicated from a replication node to downstream nodes. |
|
| |
| RFC 9525 | Service Identity in TLS |
| |
|
|
Many application technologies enable secure communication between two entities by means of Transport Layer Security (TLS) with InternetPublic Key Infrastructure using X.509 (PKIX) certificates. This document specifies procedures for representing and verifying the identity of application services in such interactions.
This document obsoletes RFC 6125. |
|
| |
| RFC 9526 | Simple Provisioning of Public Names for Residential Networks |
| |
| Authors: | D. Migault, R. Weber, M. Richardson, R. Hunter. |
| Date: | January 2024 |
| Formats: | txt html pdf xml json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9526 |
|
Home network owners may have devices or services hosted on their home network that they wish to access from the Internet (i.e., from a network outside of the home network). Home networks are increasingly numbered using IPv6 addresses, which in principle makes this access simpler, but accessing home networks from the Internet requires the names and IP addresses of these devices and services to be made available in the public DNS.
This document describes how a Home Naming Authority (NHA) instructs the outsourced infrastructure to publish these pieces of information in the public DNS. The names and IP addresses of the home network are set in the Public Homenet Zone by the Homenet Naming Authority(HNA), which in turn instructs an outsourced infrastructure to publish the zone on behalf of the home network owner. |
|
| |
| RFC 9527 | DHCPv6 Options for the Homenet Naming Authority |
| |
| Authors: | D. Migault, R. Weber, T. Mrugalski. |
| Date: | January 2024 |
| Formats: | txt html json pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9527 |
|
This document defines DHCPv6 options so that a Homenet NamingAuthority (HNA) can automatically set the appropriate configuration and outsource the authoritative naming service for the home network.In most cases, the outsourcing mechanism is transparent for the end user. |
|
| |
| RFC 9528 | Ephemeral Diffie-Hellman Over COSE (EDHOC) |
| |
| Authors: | G. Selander, J. Preuß Mattsson, F. Palombini. |
| Date: | March 2024 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9528 |
|
This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys. EDHOC provides mutual authentication, forward secrecy, and identity protection. EDHOC is intended for usage in constrained scenarios, and a main use case is to establish an Object Security for Constrained RESTful Environments (OSCORE) security context. By reusing CBOR Object Signing and Encryption(COSE) for cryptography, Concise Binary Object Representation (CBOR) for encoding, and Constrained Application Protocol (CoAP) for transport, the additional code size can be kept very low. |
|
| |
| RFC 9529 | Traces of Ephemeral Diffie-Hellman Over COSE (EDHOC) |
| |
| Authors: | G. Selander, J. Preuß Mattsson, M. Serafin, M. Tiloca, M. Vučinić. |
| Date: | March 2024 |
| Formats: | txt json html pdf xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9529 |
|
This document contains example traces of Ephemeral Diffie-HellmanOver COSE (EDHOC). |
|
| |
| RFC 9530 | Digest Fields |
| |
|
|
This document defines HTTP fields that support integrity digests.The Content-Digest field can be used for the integrity of HTTP message content. The Repr-Digest field can be used for the integrity of HTTP representations. Want-Content-Digest and Want-Repr-Digest can be used to indicate a sender's interest and preferences for receiving the respective Integrity fields.
This document obsoletes RFC 3230 and the Digest and Want-Digest HTTP fields. |
|
| |
| RFC 9531 | Path Steering in Content-Centric Networking (CCNx) and Named Data Networking (NDN) |
| |
|
|
Path steering is a mechanism to discover paths to the producers ofInformation-Centric Networking (ICN) Content Objects and steer subsequent Interest messages along a previously discovered path. It has various uses, including the operation of state-of-the-art multi- path congestion control algorithms and for network measurement and management. This specification derives directly from the design published in "Path Switching in Content Centric and Named DataNetworks" (4th ACM Conference on Information-Centric Networking) and, therefore, does not recapitulate the design motivations, implementation details, or evaluation of the scheme. However, some technical details are different, and where there are differences, the design documented here is to be considered definitive.
This document is a product of the IRTF Information-Centric NetworkingResearch Group (ICNRG). It is not an IETF product and is not anInternet Standard. |
|
| |
| RFC 9532 | HTTP Proxy-Status Parameter for Next-Hop Aliases |
| |
|
|
This document defines the next-hop-aliases HTTP Proxy-StatusParameter. This parameter carries the list of aliases and canonical names an intermediary received during DNS resolution as part of establishing a connection to the next hop. |
|
| |
| RFC 9533 | One-Way and Two-Way Active Measurement Protocol Extensions for Performance Measurement on a Link Aggregation Group |
| |
| Authors: | Z. Li, T. Zhou, J. Guo, G. Mirsky, R. Gandhi. |
| Date: | January 2024 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9533 |
|
This document defines extensions to the One-Way Active MeasurementProtocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) to implement performance measurement on every member link of a LinkAggregation Group (LAG). Knowing the measured metrics of each member link of a LAG enables operators to enforce the performance-based traffic steering policy across the member links. |
|
| |
| RFC 9534 | Simple Two-Way Active Measurement Protocol Extensions for Performance Measurement on a Link Aggregation Group |
| |
| Authors: | Z. Li, T. Zhou, J. Guo, G. Mirsky, R. Gandhi. |
| Date: | January 2024 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9534 |
|
This document extends Simple Two-way Active Measurement Protocol(STAMP) to implement performance measurement on every member link of a Link Aggregation Group (LAG). Knowing the measured metrics of each member link of a LAG enables operators to enforce a performance-based traffic steering policy across the member links. |
|
| |
| RFC 9535 | JSONPath: Query Expressions for JSON |
| |
| Authors: | S. Gössner, Ed., G. Normington, Ed., C. Bormann, Ed.. |
| Date: | February 2024 |
| Formats: | txt pdf xml json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9535 |
|
JSONPath defines a string syntax for selecting and extracting JSON(RFC 8259) values from within a given JSON value. |
|
| |
| RFC 9536 | Registration Data Access Protocol (RDAP) Reverse Search |
| |
| Authors: | M. Loffredo, M. Martinelli. |
| Date: | April 2024 |
| Formats: | txt html xml json pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9536 |
|
The Registration Data Access Protocol (RDAP) does not include query capabilities for finding the list of domains related to a set of entities matching a given search pattern. Considering that an RDAP entity can be associated with any defined object class and other relationships between RDAP object classes exist, a reverse search can be applied to other use cases besides the classic domain-entity scenario. This document describes an RDAP extension that allows servers to provide a reverse search feature based on the relationship defined in RDAP between an object class for search and any related object class. The reverse search based on the domain-entity relationship is treated as a particular case. |
|
| |
| RFC 9537 | Redacted Fields in the Registration Data Access Protocol (RDAP) Response |
| |
| Authors: | J. Gould, D. Smith, J. Kolker, R. Carney. |
| Date: | March 2024 |
| Formats: | txt html xml json pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9537 |
|
This document describes a Registration Data Access Protocol (RDAP) extension for specifying methods of redaction of RDAP responses and explicitly identifying redacted RDAP response fields, using JSONPath as the default expression language. |
|
| |
| RFC 9538 | Content Delivery Network Interconnection (CDNI) Delegation Using the Automated Certificate Management Environment |
| |
| Authors: | F. Fieau, Ed., E. Stephan, S. Mishra. |
| Date: | February 2024 |
| Formats: | txt json html xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9538 |
|
This document defines metadata to support delegating the delivery ofHTTPS content between two or more interconnected Content DeliveryNetworks (CDNs). Specifically, this document defines a ContentDelivery Network Interconnection (CDNI) Metadata interface object to enable delegation of X.509 certificates leveraging delegation schemes defined in RFC 9115. Per RFC 9115, delegating entities can remain in full control of the delegation and can revoke it at any time. This avoids the need to share private cryptographic key material between the involved entities. |
|
| |
| RFC 9539 | Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS |
| |
| Authors: | D. K. Gillmor, Ed., J. Salazar, Ed., P. Hoffman, Ed.. |
| Date: | February 2024 |
| Formats: | txt json xml pdf html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9539 |
|
This document sets out steps that DNS servers (recursive resolvers and authoritative servers) can take unilaterally (without any coordination with other peers) to defend DNS query privacy against a passive network monitor. The protections provided by the guidance in this document can be defeated by an active attacker, but they should be simpler and less risky to deploy than more powerful defenses.
The goal of this document is to simplify and speed up deployment of opportunistic encrypted transport in the recursive-to-authoritative hop of the DNS ecosystem. Wider easy deployment of the underlying encrypted transport on an opportunistic basis may facilitate the future specification of stronger cryptographic protections against more-powerful attacks. |
|
| |
| RFC 9540 | Discovery of Oblivious Services via Service Binding Records |
| |
| Authors: | T. Pauly, T. Reddy.K. |
| Date: | February 2024 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9540 |
|
This document defines a parameter that can be included in ServiceBinding (SVCB) and HTTPS DNS resource records to denote that a service is accessible using Oblivious HTTP, by offering an ObliviousGateway Resource through which to access the target. This document also defines a mechanism for learning the key configuration of the discovered Oblivious Gateway Resource. |
|
| |
| RFC 9541 | Flush Mechanism for Customer MAC Addresses Based on Service Instance Identifier (I-SID) in Provider Backbone Bridging EVPN (PBB-EVPN) |
| |
| Authors: | J. Rabadan, Ed., S. Sathappan, K. Nagaraj, M. Miyake, T. Matsuda. |
| Date: | March 2024 |
| Formats: | txt pdf xml html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9541 |
|
Provider Backbone Bridging (PBB) can be combined with EthernetVirtual Private Networks (EVPNs) to deploy Ethernet Local AreaNetwork (E-LAN) services in large Multiprotocol Label Switching(MPLS) networks. That combination is what we refer to as "PBB-EVPN."Single-Active multihoming and per Service Instance Identifier (I-SID) load-balancing can be provided to access devices and aggregation networks. In order to speed up the network convergence in case of failures on Single-Active multihomed Ethernet Segments (ESs), PBB-EVPN defines a flush mechanism for Customer MACs (C-MACs) called"C-MAC flush" that works for different Ethernet Segment Backbone MAC(B-MAC) address allocation models. This document complements thoseC-MAC flush procedures for cases in which no PBB-EVPN ESs are defined(i.e., the attachment circuit is associated with a zero EthernetSegment Identifier (ESI)) and the C-MAC flush requires I-SID-level granularity. |
|
| |
| RFC 9542 | IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters |
| |
|
|
Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses several aspects of such parameters and their use in IETF protocols, specifies IANA considerations for assignment of points under the IANAOrganizationally Unique Identifier (OUI), and provides some values for use in documentation. This document obsoletes RFC 7042. |
|
| |
| RFC 9543 | A Framework for Network Slices in Networks Built from IETF Technologies |
| |
| Authors: | A. Farrel, Ed., J. Drake, Ed., R. Rokui, S. Homma, K. Makhijani, L. Contreras, J. Tantsura. |
| Date: | March 2024 |
| Formats: | txt json html xml pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9543 |
|
This document describes network slicing in the context of networks built from IETF technologies. It defines the term "IETF NetworkSlice" to describe this type of network slice and establishes the general principles of network slicing in the IETF context.
The document discusses the general framework for requesting and operating IETF Network Slices, the characteristics of an IETF NetworkSlice, the necessary system components and interfaces, and the mapping of abstract requests to more specific technologies. The document also discusses related considerations with monitoring and security.
This document also provides definitions of related terms to enable consistent usage in other IETF documents that describe or use aspects of IETF Network Slices. |
|
| |
| RFC 9544 | Precision Availability Metrics (PAMs) for Services Governed by Service Level Objectives (SLOs) |
| |
| Authors: | G. Mirsky, J. Halpern, X. Min, A. Clemm, J. Strassner, J. François. |
| Date: | March 2024 |
| Formats: | txt html json xml pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9544 |
|
This document defines a set of metrics for networking services with performance requirements expressed as Service Level Objectives(SLOs). These metrics, referred to as "Precision AvailabilityMetrics (PAMs)", are useful for defining and monitoring SLOs. For example, PAMs can be used by providers and/or customers of an RFC9543 Network Slice Service to assess whether the service is provided in compliance with its defined SLOs. |
|
| |
| RFC 9545 | Path Segment Identifier in MPLS-Based Segment Routing Networks |
| |
| Authors: | W. Cheng, Ed., H. Li, C. Li, Ed., R. Gandhi, R. Zigler. |
| Date: | February 2024 |
| Formats: | txt html xml json pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9545 |
|
A Segment Routing (SR) path is identified by an SR segment list. A subset of segments from the segment list cannot be leveraged to distinguish one SR path from another as they may be partially congruent. SR path identification is a prerequisite for various use cases such as performance measurement and end-to-end 1+1 path protection.
In an SR over MPLS (SR-MPLS) data plane, an egress node cannot determine on which SR path a packet traversed the network from the label stack because the segment identifiers are removed from the label stack as the packet transits the network.
This document defines a Path Segment Identifier (PSID) to identify anSR path on the egress node of the path. |
|
| |
| RFC 9546 | Operations, Administration, and Maintenance (OAM) for Deterministic Networking (DetNet) with the MPLS Data Plane |
| |
| Authors: | G. Mirsky, M. Chen, B. Varga. |
| Date: | February 2024 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9546 |
|
This document defines format and usage principles of theDeterministic Networking (DetNet) service Associated Channel over aDetNet network with the MPLS data plane. The DetNet serviceAssociated Channel can be used to carry test packets of activeOperations, Administration, and Maintenance (OAM) protocols that are used to detect DetNet failures and measure performance metrics. |
|
| |
| RFC 9547 | Report from the IAB Workshop on Environmental Impact of Internet Applications and Systems, 2022 |
| |
| Authors: | J. Arkko, C. S. Perkins, S. Krishnan. |
| Date: | February 2024 |
| Formats: | txt pdf xml json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9547 |
|
Internet communications and applications have both environmental costs and benefits. The IAB ran an online workshop in December 2022 to explore and understand these impacts.
The role of the workshop was to discuss the impacts and the evolving industry needs, and to identify areas for improvements and future work. A key goal of the workshop was to call further attention to the topic and bring together a diverse stakeholder community to discuss these issues.
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions. |
|
| |
| RFC 9548 | Generating Transport Key Containers (PFX) Using the GOST Algorithms |
| |
|
|
This document specifies how to use "PKCS #12: Personal InformationExchange Syntax v1.1" (RFC 7292) to transport key containers (PFX) for storing keys and certificates in conjunction with the Russian national standard GOST algorithms.
This specification has been developed outside the IETF. The purpose of publication is to facilitate interoperable implementations that wish to support the GOST algorithms. This document does not implyIETF endorsement of the cryptographic algorithms used here. |
|
| |
| RFC 9549 | Internationalization Updates to RFC 5280 |
| |
|
|
The updates to RFC 5280 described in this document provide alignment with the 2008 specification for Internationalized Domain Names (IDNs) and includes support for internationalized email addresses in X.509 certificates. The updates ensure that name constraints for email addresses that contain only ASCII characters and internationalized email addresses are handled in the same manner. This document obsoletes RFC 8399. |
|
| |
| RFC 9550 | Deterministic Networking (DetNet): Packet Ordering Function |
| |
| Authors: | B. Varga, Ed., J. Farkas, S. Kehrer, T. Heer. |
| Date: | March 2024 |
| Formats: | txt html xml pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9550 |
|
The replication and elimination functions of the DeterministicNetworking (DetNet) architecture can result in out-of-order packets, which is not acceptable for some time-sensitive applications. ThePacket Ordering Function (POF) algorithms described in this document enable restoration of the correct packet order when the replication and elimination functions are used in DetNet networks. The POF only provides ordering within the latency bound of a DetNet flow; it does not provide any additional reliability. |
|
| |
| RFC 9551 | Framework of Operations, Administration, and Maintenance (OAM) for Deterministic Networking (DetNet) |
| |
| Authors: | G. Mirsky, F. Theoleyre, G. Papadopoulos, CJ. Bernardos, B. Varga, J. Farkas. |
| Date: | March 2024 |
| Formats: | txt xml pdf html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9551 |
|
Deterministic Networking (DetNet), as defined in RFC 8655, aims to provide bounded end-to-end latency on top of the network infrastructure, comprising both Layer 2 bridged and Layer 3 routed segments. This document's primary purpose is to detail the specific requirements of the Operations, Administration, and Maintenance (OAM) recommended to maintain a deterministic network. The document will be used in future work that defines the applicability of and extension of OAM protocols for a deterministic network. With the implementation of the OAM framework in DetNet, an operator will have a real-time view of the network infrastructure regarding the network's ability to respect the Service Level Objective (SLO), such as packet delay, delay variation, and packet-loss ratio, assigned to each DetNet flow. |
|
| |
| RFC 9552 | Distribution of Link-State and Traffic Engineering Information Using BGP |
| |
|
|
In many environments, a component external to a network is called upon to perform computations based on the network topology and the current state of the connections within the network, includingTraffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network.
This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using aBGP Network Layer Reachability Information (NLRI) encoding format.The mechanism applies to physical and virtual (e.g., tunnel) IGP links. The mechanism described is subject to policy control.
Applications of this technique include Application-Layer TrafficOptimization (ALTO) servers and Path Computation Elements (PCEs).
This document obsoletes RFC 7752 by completely replacing that document. It makes some small changes and clarifications to the previous specification. This document also obsoletes RFC 9029 by incorporating the updates that it made to RFC 7752. |
|
| |
| RFC 9553 | JSContact: A JSON Representation of Contact Data |
| |
|
|
This specification defines a data model and JavaScript ObjectNotation (JSON) representation of contact card information that can be used for data storage and exchange in address book or directory applications. It aims to be an alternative to the vCard data format and to be unambiguous, extendable, and simple to process. In contrast to the JSON-based jCard format, it is not a direct mapping from the vCard data model and expands semantics where appropriate.Two additional specifications define new vCard elements and how to convert between JSContact and vCard. |
|
| |
| RFC 9554 | vCard Format Extensions for JSContact |
| |
|
|
This document defines a set of new properties for vCard and extends the use of existing ones. Their primary purpose is to align the same set of features between the JSContact and vCard formats, but the new definitions also aim to be useful within just the vCard format. This document updates RFC 6350 ("vCard Format Specification"). |
|
| |
| RFC 9555 | JSContact: Converting from and to vCard |
| |
|
|
This document defines how to convert contact information between theJSContact and vCard data formats. It defines conversion rules for every JSContact and vCard element registered at IANA at the time of publication. It also defines new JSContact properties as well as vCard properties and parameters, to support converting arbitrary or unknown JSContact and vCard elements. |
|
| |
| RFC 9556 | Internet of Things (IoT) Edge Challenges and Functions |
| |
| Authors: | J. Hong, Y-G. Hong, X. de Foy, M. Kovatsch, E. Schooler, D. Kutscher. |
| Date: | April 2024 |
| Formats: | txt xml json pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9556 |
|
Many Internet of Things (IoT) applications have requirements that cannot be satisfied by centralized cloud-based systems (i.e., cloud computing). These include time sensitivity, data volume, connectivity cost, operation in the face of intermittent services, privacy, and security. As a result, IoT is driving the Internet toward edge computing. This document outlines the requirements of the emerging IoT edge and its challenges. It presents a general model and major components of the IoT edge to provide a common basis for future discussions in the Thing-to-Thing Research Group (T2TRG) and other IRTF and IETF groups. This document is a product of theIRTF T2TRG. |
|
| |
| RFC 9557 | Date and Time on the Internet: Timestamps with Additional Information |
| |
|
|
This document defines an extension to the timestamp format defined inRFC 3339 for representing additional information, including a time zone.
It updates RFC 3339 in the specific interpretation of the local offset Z, which is no longer understood to "imply that UTC is the preferred reference point for the specified time". |
|
| |
| RFC 9558 | Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC |
| |
| Authors: | B. Makarenko, V. Dolmatov, Ed.. |
| Date: | April 2024 |
| Formats: | txt html xml pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9558 |
|
This document describes how to produce digital signatures and hash functions using the GOST R 34.10-2012 and GOST R 34.11-2012 algorithms for DNSKEY, RRSIG, and DS resource records, for use in theDomain Name System Security Extensions (DNSSEC). |
|
| |
| RFC 9559 | Matroska Media Container Format Specification |
| |
|
|
This document defines the Matroska audiovisual data container structure, including definitions of its structural elements, terminology, vocabulary, and application.
This document updates RFC 8794 to permit the use of a previously reserved Extensible Binary Meta Language (EBML) Element ID. |
|
| |
| RFC 9560 | Federated Authentication for the Registration Data Access Protocol (RDAP) Using OpenID Connect |
| |
|
|
The Registration Data Access Protocol (RDAP) providesRepresentational State Transfer (RESTful) web services to retrieve registration metadata from domain name and regional internet registries. RDAP allows a server to make access control decisions based on client identity, and as such, it includes support for client identification features provided by the Hypertext Transfer Protocol(HTTP). Identification methods that require clients to obtain and manage credentials from every RDAP server operator present management challenges for both clients and servers, whereas a federated authentication system would make it easier to operate and use RDAP without the need to maintain server-specific client credentials.This document describes a federated authentication system for RDAP based on OpenID Connect. |
|
| |
| RFC 9561 | Using the Parallel NFS (pNFS) SCSI Layout to Access Non-Volatile Memory Express (NVMe) Storage Devices |
| |
| Authors: | C. Hellwig, Ed., C. Lever, S. Faibish, D. Black. |
| Date: | April 2024 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9561 |
|
This document specifies how to use the Parallel Network File System(pNFS) Small Computer System Interface (SCSI) Layout Type to access storage devices using the Non-Volatile Memory Express (NVMe) protocol family. |
|
| |
| RFC 9562 | Universally Unique IDentifiers (UUIDs) |
| |
|
|
This specification defines UUIDs (Universally Unique IDentifiers) -- also known as GUIDs (Globally Unique IDentifiers) -- and a UniformResource Name namespace for UUIDs. A UUID is 128 bits long and is intended to guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System (NCS), later in the Open Software Foundation's (OSF's) Distributed ComputingEnvironment (DCE), and then in Microsoft Windows platforms.
This specification is derived from the OSF DCE specification with the kind permission of the OSF (now known as "The Open Group").Information from earlier versions of the OSF DCE specification have been incorporated into this document. This document obsoletes RFC4122. |
|
| |
| RFC 9563 | SM2 Digital Signature Algorithm for DNSSEC |
| |
| Authors: | C. Zhang, Y. Liu, F. Leng, Q. Zhao, Z. He. |
| Date: | December 2024 |
| Formats: | txt xml pdf json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9563 |
|
This document specifies the use of the SM2 digital signature algorithm and SM3 hash algorithm for DNS Security (DNSSEC).
This document is an Independent Submission to the RFC series and does not have consensus of the IETF community. |
|
| |
| RFC 9564 | Faster Than Light Speed Protocol (FLIP) |
| |
|
|
The recent advances in artificial intelligence (AI) such as large language models enable the design of the Faster than LIght speedProtocol (FLIP) for Internet. FLIP provides a way to avoid congestion, enhance security, and deliver faster packets on theInternet by using AI to predict future packets at the receiving peer before they arrive. This document describes the protocol, its various encapsulations, and some operational considerations. |
|
| |
| RFC 9565 | An Update to the tcpControlBits IP Flow Information Export (IPFIX) Information Element |
| |
|
|
RFC 7125 revised the tcpControlBits IP Flow Information Export(IPFIX) Information Element that was originally defined in RFC 5102 to reflect changes to the TCP header control bits since RFC 793.However, that update is still problematic for interoperability because some flag values have subsequently been deprecated.
This document removes stale information from the IANA "IPFIXInformation Elements" registry and avoids future conflicts with the authoritative IANA "TCP Header Flags" registry.
This document obsoletes RFC 7125. |
|
| |
| RFC 9566 | Deterministic Networking (DetNet) Packet Replication, Elimination, and Ordering Functions (PREOF) via MPLS over UDP/IP |
| |
| Authors: | B. Varga, J. Farkas, A. Malis. |
| Date: | April 2024 |
| Formats: | txt json pdf html xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9566 |
|
This document describes how the DetNet IP data plane can support thePacket Replication, Elimination, and Ordering Functions (PREOF) built on the existing MPLS PREOF solution defined for the DetNet MPLS data plane and the mechanisms defined by MPLS-over-UDP technology. |
|
| |
| RFC 9567 | DNS Error Reporting |
| |
|
|
DNS error reporting is a lightweight reporting mechanism that provides the operator of an authoritative server with reports on DNS resource records that fail to resolve or validate. A domain owner orDNS hosting organization can use these reports to improve domain hosting. The reports are based on extended DNS errors as described in RFC 8914.
When a domain name fails to resolve or validate due to a misconfiguration or an attack, the operator of the authoritative server may be unaware of this. To mitigate this lack of feedback, this document describes a method for a validating resolver to automatically signal an error to a monitoring agent specified by the authoritative server. The error is encoded in the QNAME; thus, the very act of sending the query is to report the error. |
|
| |
| RFC 9568 | Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6 |
| |
|
|
This document defines version 3 of the Virtual Router RedundancyProtocol (VRRP) for IPv4 and IPv6. It obsoletes RFC 5798, which previously specified VRRP (version 3). RFC 5798 obsoleted RFC 3768, which specified VRRP (version 2) for IPv4. VRRP specifies an election protocol that dynamically assigns responsibility for aVirtual Router to one of the VRRP Routers on a LAN. The VRRP Router controlling the IPv4 or IPv6 address(es) associated with a VirtualRouter is called the Active Router, and it forwards packets routed to these IPv4 or IPv6 addresses. Active Routers are configured with virtual IPv4 or IPv6 addresses, and Backup Routers infer the address family of the virtual addresses being advertised based on the IP protocol version. Within a VRRP Router, the Virtual Routers in each of the IPv4 and IPv6 address families are independent of one another and always treated as separate Virtual Router instances. The election process provides dynamic failover in the forwarding responsibility should the Active Router become unavailable. ForIPv4, the advantage gained from using VRRP is a higher-availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. For IPv6, the advantage gained from using VRRP for IPv6 is a quicker switchover toBackup Routers than can be obtained with standard IPv6 NeighborDiscovery mechanisms. |
|
| |
| RFC 9569 | The Application-Layer Traffic Optimization (ALTO) Transport Information Publication Service (TIPS) |
| |
| Authors: | K. Gao, R. Schott, Y. R. Yang, L. Delwiche, L. Keller. |
| Date: | September 2024 |
| Formats: | txt html json pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9569 |
|
"Application-Layer Traffic Optimization (ALTO) Protocol" (RFC 7285) leverages HTTP/1.1 and is designed for the simple, sequential request-reply use case, in which an ALTO client requests a sequence of information resources and the server responds with the complete content of each resource, one at a time.
RFC 8895, which describes ALTO incremental updates using Server-SentEvents (SSE), defines a multiplexing protocol on top of HTTP/1.x, so that an ALTO server can incrementally push resource updates to clients whenever monitored network information resources change, allowing the clients to monitor multiple resources at the same time.However, HTTP/2 and later versions already support concurrent, non- blocking transport of multiple streams in the same HTTP connection.
To take advantage of newer HTTP features, this document introduces the ALTO Transport Information Publication Service (TIPS). TIPS uses an incremental RESTful design to give an ALTO client the new capability to explicitly and concurrently (in a non-blocking manner) request (or pull) specific incremental updates using HTTP/2 orHTTP/3, while still functioning for HTTP/1.1. |
|
| |
| RFC 9570 | Deprecating the Use of Router Alert in LSP Ping |
| |
|
|
The MPLS echo request and MPLS echo response messages, defined in RFC8029, "Detecting Multiprotocol Label Switched (MPLS) Data-PlaneFailures" (usually referred to as LSP ping), are encapsulated in IP packets with headers that include a Router Alert Option (RAO). In actual deployments, the RAO was neither required nor used.Furthermore, RFC 6398 identifies security vulnerabilities associated with the RAO in non-controlled environments, e.g., the case of using the MPLS echo request/reply as inter-area Operations, Administration, and Maintenance (OAM), and recommends against its use outside of controlled environments.
Therefore, this document retires the RAO for MPLS OAM and updates RFC8029 to remove the RAO from LSP ping message encapsulations.Furthermore, this document explains why RFC 7506 has been reclassified as Historic.
Also, this document recommends the use of an IPv6 loopback address(::1/128) as the IPv6 destination address for an MPLS echo request message. |
|
| |
| RFC 9571 | Extension of RFC 6374-Based Performance Measurement Using Synonymous Flow Labels |
| |
| Authors: | S. Bryant, Ed., G. Swallow, M. Chen, G. Fioccola, G. Mirsky. |
| Date: | May 2024 |
| Formats: | txt html xml json pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9571 |
|
RFC 6374 describes methods of making loss and delay measurements onLabel Switched Paths (LSPs) primarily as they are used in MPLSTransport Profile (MPLS-TP) networks. This document describes a method of extending the performance measurements (specified in RFC6374) from flows carried over MPLS-TP to flows carried over genericMPLS LSPs. In particular, it extends the technique to allow loss and delay measurements to be made on multipoint-to-point LSPs and introduces some additional techniques to allow more sophisticated measurements to be made in both MPLS-TP and generic MPLS networks. |
|
| |
| RFC 9572 | Updates to EVPN Broadcast, Unknown Unicast, or Multicast (BUM) Procedures |
| |
| Authors: | Z. Zhang, W. Lin, J. Rabadan, K. Patel, A. Sajassi. |
| Date: | May 2024 |
| Formats: | txt pdf xml json html |
| Updates: | RFC 7432 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9572 |
|
This document specifies updated procedures for handling Broadcast,Unknown Unicast, or Multicast (BUM) traffic in Ethernet VPNs (EVPNs), including selective multicast and segmentation of provider tunnels.This document updates RFC 7432. |
|
| |
| RFC 9573 | MVPN/EVPN Tunnel Aggregation with Common Labels |
| |
|
|
The Multicast VPN (MVPN) specifications allow a single Point-to-Multipoint (P2MP) tunnel to carry traffic of multiple IP VPNs(referred to as VPNs in this document). The EVPN specifications allow a single P2MP tunnel to carry traffic of multiple BroadcastDomains (BDs). These features require the ingress router of the P2MP tunnel to allocate an upstream-assigned MPLS label for each VPN or for each BD. A packet sent on a P2MP tunnel then carries the label that is mapped to its VPN or BD (in some cases, a distinct upstream- assigned label is needed for each flow.) Since each ingress router allocates labels independently, with no coordination among the ingress routers, the egress routers may need to keep track of a large number of labels. The number of labels may need to be as large as, or larger than, the product of the number of ingress routers times the number of VPNs or BDs. However, the number of labels can be greatly reduced if the association between a label and a VPN or BD is made by provisioning, so that all ingress routers assign the same label to a particular VPN or BD. New procedures are needed in order to take advantage of such provisioned labels. These new procedures also apply to Multipoint-to-Multipoint (MP2MP) tunnels. This document updates RFCs 6514, 7432, and 7582 by specifying the necessary procedures. |
|
| |
| RFC 9574 | Optimized Ingress Replication Solution for Ethernet VPNs (EVPNs) |
| |
| Authors: | J. Rabadan, Ed., S. Sathappan, W. Lin, M. Katiyar, A. Sajassi. |
| Date: | May 2024 |
| Formats: | txt pdf xml html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9574 |
|
Network Virtualization Overlay (NVO) networks using Ethernet VPNs(EVPNs) as their control plane may use trees based on ingress replication or Protocol Independent Multicast (PIM) to convey the overlay Broadcast, Unknown Unicast, or Multicast (BUM) traffic. PIM provides an efficient solution that prevents sending multiple copies of the same packet over the same physical link; however, it may not always be deployed in the NVO network core. Ingress replication avoids the dependency on PIM in the NVO network core. While ingress replication provides a simple multicast transport, some NVO networks with demanding multicast applications require a more efficient solution without PIM in the core. This document describes a solution to optimize the efficiency of ingress replication trees. |
|
| |
| RFC 9575 | DRIP Entity Tag (DET) Authentication Formats and Protocols for Broadcast Remote Identification (RID) |
| |
| Authors: | A. Wiethuechter, Ed., S. Card, R. Moskowitz. |
| Date: | June 2024 |
| Formats: | txt pdf html xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9575 |
|
The Drone Remote Identification Protocol (DRIP), plus trust policies and periodic access to registries, augments Unmanned Aircraft System(UAS) Remote Identification (RID), enabling local real-time assessment of trustworthiness of received RID messages and observedUAS, even by Observers lacking Internet access. This document defines DRIP message types and formats to be sent in Broadcast RIDAuthentication Messages to verify that attached and recently detached messages were signed by the registered owner of the DRIP Entity Tag(DET) claimed. |
|
| |
| RFC 9576 | The Privacy Pass Architecture |
| |
| Authors: | A. Davidson, J. Iyengar, C. A. Wood. |
| Date: | June 2024 |
| Formats: | txt json html xml pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9576 |
|
This document specifies the Privacy Pass architecture and requirements for its constituent protocols used for authorization based on privacy-preserving authentication mechanisms. It describes the conceptual model of Privacy Pass and its protocols, its security and privacy goals, practical deployment models, and recommendations for each deployment model, to help ensure that the desired security and privacy goals are fulfilled. |
|
| |
| RFC 9577 | The Privacy Pass HTTP Authentication Scheme |
| |
| Authors: | T. Pauly, S. Valdez, C. A. Wood. |
| Date: | June 2024 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9577 |
|
This document defines an HTTP authentication scheme for Privacy Pass, a privacy-preserving authentication mechanism used for authorization.The authentication scheme specified in this document can be used byClients to redeem Privacy Pass tokens with an Origin. It can also be used by Origins to challenge Clients to present Privacy Pass tokens. |
|
| |
| RFC 9578 | Privacy Pass Issuance Protocols |
| |
| Authors: | S. Celi, A. Davidson, S. Valdez, C. A. Wood. |
| Date: | June 2024 |
| Formats: | txt html json xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9578 |
|
This document specifies two variants of the two-message issuance protocol for Privacy Pass tokens: one that produces tokens that are privately verifiable using the Issuer Private Key and one that produces tokens that are publicly verifiable using the Issuer PublicKey. Instances of "issuance protocol" and "issuance protocols" in the text of this document are used interchangeably to refer to the two variants of the Privacy Pass issuance protocol. |
|
| |
| RFC 9579 | Use of Password-Based Message Authentication Code 1 (PBMAC1) in PKCS #12 Syntax |
| |
|
|
This document specifies additions and amendments to RFCs 7292 and8018. It defines a way to use the Password-Based MessageAuthentication Code 1 (PBMAC1), defined in RFC 8018, inside the PKCS#12 syntax. The purpose of this specification is to permit the use of more modern Password-Based Key Derivation Functions (PBKDFs) and allow for regulatory compliance. |
|
| |
| RFC 9580 | OpenPGP |
| |
|
|
This document specifies the message formats used in OpenPGP. OpenPGP provides encryption with public key or symmetric cryptographic algorithms, digital signatures, compression, and key management.
This document is maintained in order to publish all necessary information needed to develop interoperable applications based on theOpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions.It does, however, discuss implementation issues necessary to avoid security flaws.
This document obsoletes RFCs 4880 ("OpenPGP Message Format"), 5581("The Camellia Cipher in OpenPGP"), and 6637 ("Elliptic CurveCryptography (ECC) in OpenPGP"). |
|
| |
| RFC 9581 | Concise Binary Object Representation (CBOR) Tags for Time, Duration, and Period |
| |
| Authors: | C. Bormann, B. Gamari, H. Birkholz. |
| Date: | August 2024 |
| Formats: | txt xml html pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9581 |
|
The Concise Binary Object Representation (CBOR, RFC 8949) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation.
In CBOR, one point of extensibility is the definition of CBOR tags.RFC 8949 defines two tags for time: CBOR tag 0 (RFC 3339 time as a string) and tag 1 (POSIX time as int or float). Since then, additional requirements have become known. The present document defines a CBOR tag for time that allows a more elaborate representation of time, as well as related CBOR tags for duration and time period. This document is intended as the reference document for the IANA registration of the CBOR tags defined. |
|
| |
| RFC 9582 | A Profile for Route Origin Authorizations (ROAs) |
| |
| Authors: | J. Snijders, B. Maddison, M. Lepinski, D. Kong, S. Kent. |
| Date: | May 2024 |
| Formats: | txt json pdf xml html |
| Obsoletes: | RFC 6482 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9582 |
|
This document defines a standard profile for Route OriginAuthorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to one or more prefixes within the address block. This document obsoletes RFC6482. |
|
| |
| RFC 9583 | Application Scenarios for the Quantum Internet |
| |
| Authors: | C. Wang, A. Rahman, R. Li, M. Aelmans, K. Chakraborty. |
| Date: | June 2024 |
| Formats: | txt json html pdf xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9583 |
|
The Quantum Internet has the potential to improve application functionality by incorporating quantum information technology into the infrastructure of the overall Internet. This document provides an overview of some applications expected to be used on the QuantumInternet and categorizes them. Some general requirements for theQuantum Internet are also discussed. The intent of this document is to describe a framework for applications and to describe a few selected application scenarios for the Quantum Internet. This document is a product of the Quantum Internet Research Group (QIRG). |
|
| |
| RFC 9584 | RTP Payload Format for Essential Video Coding (EVC) |
| |
| Authors: | S. Zhao, S. Wenger, Y. Lim. |
| Date: | June 2024 |
| Formats: | txt html pdf json xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9584 |
|
This document describes an RTP payload format for the Essential VideoCoding (EVC) standard, published as ISO/IEC International Standard23094-1. EVC was developed by the MPEG. The RTP payload format allows for the packetization of one or more Network Abstraction Layer(NAL) units in each RTP packet payload and the fragmentation of a NAL unit into multiple RTP packets. The payload format has broad applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among other applications. |
|
| |
| RFC 9585 | IMAP Response Code for Command Progress Notifications |
| |
|
|
This document defines a new IMAP untagged response code,"INPROGRESS", that provides progress notifications regarding the status of long-running commands. |
|
| |
| RFC 9586 | IMAP Extension for Using and Returning Unique Identifiers (UIDs) Only |
| |
| Authors: | A. Melnikov, A. P. Achuthan, V. Nagulakonda, A. Singh, L. Alves. |
| Date: | May 2024 |
| Formats: | txt json xml pdf html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9586 |
|
The UIDONLY extension to the Internet Message Access Protocol (RFCs3501 and 9051) allows clients to enable a mode in which information about mailbox changes is returned using only Unique Identifiers(UIDs). Message numbers are not returned in responses and cannot be used in requests once this extension is enabled. This helps both clients and servers to reduce resource usage required to maintain a map between message numbers and UIDs.
This document defines an experimental IMAP extension. |
|
| |
| RFC 9587 | YANG Data Model for OSPFv3 Extended Link State Advertisements (LSAs) |
| |
| Authors: | A. Lindem, S. Palani, Y. Qu. |
| Date: | June 2024 |
| Formats: | txt xml pdf json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9587 |
|
This document defines a YANG data model augmenting the IETF OSPF YANG data model (RFC 9129) to provide support for OSPFv3 Link StateAdvertisement (LSA) Extensibility as defined in RFC 8362. OSPFv3Extended LSAs provide extensible TLV-based LSAs for the base LSA types defined in RFC 5340. |
|
| |
| RFC 9588 | Kerberos Simple Password-Authenticated Key Exchange (SPAKE) Pre-authentication |
| |
| Authors: | N. McCallum, S. Sorce, R. Harwood, G. Hudson. |
| Date: | August 2024 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9588 |
|
This document defines a new pre-authentication mechanism for theKerberos protocol. The mechanism uses a password-authenticated key exchange (PAKE) to prevent brute-force password attacks, and it may incorporate a second factor. |
|
| |
| RFC 9589 | On the Use of the Cryptographic Message Syntax (CMS) Signing-Time Attribute in Resource Public Key Infrastructure (RPKI) Signed Objects |
| |
|
|
In the Resource Public Key Infrastructure (RPKI), Signed Objects are defined as Cryptographic Message Syntax (CMS) protected content types. A Signed Object contains a signing-time attribute, representing the purported time at which the object was signed by its issuer. RPKI repositories are accessible using the rsync and RPKIRepository Delta protocols, allowing Relying Parties (RPs) to synchronize a local copy of the RPKI repository used for validation with the remote repositories. This document describes how the CMS signing-time attribute can be used to avoid needless retransfers of data when switching between different synchronization protocols.This document updates RFC 6488 by mandating the presence of the CMS signing-time attribute and disallowing the use of the binary-signing- time attribute. |
|
| |
| RFC 9590 | IMAP Extension for Returning Mailbox METADATA in Extended LIS |
| |
| Authors: | K. Murchison, B. Gondwana. |
| Date: | May 2024 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9590 |
|
This document defines an extension to the Internet Message AccessProtocol (IMAP) LIST command that allows the client to request mailbox annotations (metadata), along with other information typically returned by the LIST command. |
|
| |
| RFC 9591 | The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for Two-Round Schnorr Signatures |
| |
| Authors: | D. Connolly, C. Komlo, I. Goldberg, C. A. Wood. |
| Date: | June 2024 |
| Formats: | txt pdf xml html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9591 |
|
This document specifies the Flexible Round-Optimized SchnorrThreshold (FROST) signing protocol. FROST signatures can be issued after a threshold number of entities cooperate to compute a signature, allowing for improved distribution of trust and redundancy with respect to a secret key. FROST depends only on a prime-order group and cryptographic hash function. This document specifies a number of ciphersuites to instantiate FROST using different prime- order groups and hash functions. This document is a product of theCrypto Forum Research Group (CFRG) in the IRTF. |
|
| |
| RFC 9592 | Retiring the Tao of the IETF |
| |
|
|
This document retires and obsoletes the Tao of the IETF as an IETF- maintained document. This document also obsoletes RFC 6722, which describes the publication process of the Tao. Furthermore, this document describes the rationale for the retirement of the Tao. For archival purposes, the last version of the Tao is included in the appendix. Information that new participants need to engage in the work of the IETF will continue to be provided through the IETF website in a more timely and accessible manner. This is the way. |
|
| |
| RFC 9593 | Announcing Supported Authentication Methods in the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
|
This specification defines a mechanism that allows implementations of the Internet Key Exchange Protocol Version 2 (IKEv2) to indicate the list of supported authentication methods to their peers while establishing IKEv2 Security Associations (SAs). This mechanism improves interoperability when IKEv2 partners are configured with multiple credentials of different types for authenticating each other. |
|
| |
| RFC 9594 | Key Provisioning for Group Communication Using Authentication and Authorization for Constrained Environments (ACE) |
| |
| Authors: | F. Palombini, M. Tiloca. |
| Date: | September 2024 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9594 |
|
This document defines how to use the Authentication and Authorization for Constrained Environments (ACE) framework to distribute keying material and configuration parameters for secure group communication.Candidate group members that act as Clients and are authorized to join a group can do so by interacting with a Key Distribution Center(KDC) acting as the Resource Server, from which they obtain the keying material to communicate with other group members. While defining general message formats as well as the interface and operations available at the KDC, this document supports different approaches and protocols for secure group communication. Therefore, details are delegated to separate application profiles of this document as specialized instances that target a particular group communication approach and define how communications in the group are protected. Compliance requirements for such application profiles are also specified. |
|
| |
| RFC 9595 | YANG Schema Item iDentifier (YANG SID) |
| |
| Authors: | M. Veillette, Ed., A. Pelov, Ed., I. Petrov, Ed., C. Bormann, M. Richardson. |
| Date: | July 2024 |
| Formats: | txt html json xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9595 |
|
YANG Schema Item iDentifiers (YANG SIDs) are globally unique 63-bit unsigned integers used to identify YANG items. SIDs provide a more compact method for identifying those YANG items that can be used efficiently, notably in constrained environments (RFC 7228). This document defines the semantics, registration processes, and assignment processes for YANG SIDs for IETF-managed YANG modules. To enable the implementation of these processes, this document also defines a file format used to persist and publish assigned YANG SIDs. |
|
| |
| RFC 9596 | CBOR Object Signing and Encryption (COSE) "typ" (type) Header Parameter |
| |
|
|
This specification adds the equivalent of the JSON Object Signing andEncryption (JOSE) "typ" (type) header parameter to CBOR ObjectSigning and Encryption (COSE). This enables the benefits of explicit typing (as defined in RFC 8725, "JSON Web Token Best CurrentPractices") to be brought to COSE objects. The syntax of the COSE type header parameter value is the same as the existing COSE content type header parameter. |
|
| |
| RFC 9597 | CBOR Web Token (CWT) Claims in COSE Headers |
| |
|
|
This document describes how to include CBOR Web Token (CWT) claims in the header parameters of any CBOR Object Signing and Encryption(COSE) structure. This functionality helps to facilitate applications that wish to make use of CWT claims in encrypted COSE structures and/or COSE structures featuring detached signatures, while having some of those claims be available before decryption and/ or without inspecting the detached payload. Another use case is using CWT claims with payloads that are not CWT Claims Sets, including payloads that are not CBOR at all. |
|
| |
| RFC 9598 | Internationalized Email Addresses in X.509 Certificates |
| |
|
|
This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name and Issuer AlternativeName extension that allows a certificate subject to be associated with an internationalized email address.
This document updates RFC 5280 and obsoletes RFC 8398. |
|
| |
| RFC 9599 | Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP |
| |
|
|
The purpose of this document is to guide the design of congestion notification in any lower-layer or tunnelling protocol that encapsulates IP. The aim is for explicit congestion signals to propagate consistently from lower-layer protocols into IP. Then, theIP internetwork layer can act as a portability layer to carry congestion notification from non-IP-aware congested nodes up to the transport layer (L4). Specifications that follow these guidelines, whether produced by the IETF or other standards bodies, should assure interworking among IP-layer and lower-layer congestion notification mechanisms. This document is included in BCP 89 and updates the single paragraph of advice to subnetwork designers about ExplicitCongestion Notification (ECN) in Section 13 of RFC 3819 by replacing it with a reference to this document. |
|
