| |
| 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 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 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 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 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. |
|
