| |
| RFC 9600 | TRansparent Interconnection of Lots of Links (TRILL): Explicit Congestion Notification (ECN) Support |
| |
| Authors: | D. Eastlake 3rd, B. Briscoe. |
| Date: | August 2024 |
| Formats: | txt xml pdf html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9600 |
|
Explicit Congestion Notification (ECN) allows a forwarding element to notify downstream devices, including the destination, of the onset of congestion without having to drop packets. This can improve network efficiency through better congestion control without packet drops.This document extends ECN to TRansparent Interconnection of Lots ofLinks (TRILL) switches, including integration with IP ECN, and provides for ECN marking in the TRILL header extension flags word(RFC 7179). |
|
| |
| RFC 9601 | Propagating Explicit Congestion Notification across IP Tunnel Headers Separated by a Shim |
| |
|
|
RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the rules for propagation of Explicit Congestion Notification (ECN) consistent for all forms of IP-in-IP tunnel. This specification updates RFC 6040 to clarify that its scope includes tunnels where twoIP headers are separated by at least one shim header that is not sufficient on its own for wide-area packet forwarding. It surveys widely deployed IP tunnelling protocols that use such shim headers and updates the specifications of those that do not mention ECN propagation (including RFCs 2661, 3931, 2784, 4380 and 7450, which specify L2TPv2, L2TPv3, Generic Routing Encapsulation (GRE), Teredo, and Automatic Multicast Tunneling (AMT), respectively). This specification also updates RFC 6040 with configuration requirements needed to make any legacy tunnel ingress safe. |
|
| |
| RFC 9602 | Segment Routing over IPv6 (SRv6) Segment Identifiers in the IPv6 Addressing Architecture |
| |
|
|
Segment Routing over IPv6 (SRv6) uses IPv6 as the underlying data plane. Thus, Segment Identifiers (SIDs) used by SRv6 can resembleIPv6 addresses and behave like them while exhibiting slightly different behaviors in some situations. This document explores the characteristics of SRv6 SIDs and focuses on the relationship of SRv6SIDs to the IPv6 Addressing Architecture. This document allocates and makes a dedicated prefix available for SRv6 SIDs. |
|
| |
| RFC 9603 | Path Computation Element Communication Protocol (PCEP) Extensions for IPv6 Segment Routing |
| |
| Authors: | C. Li, Ed., P. Kaladharan, S. Sivabalan, M. Koldychev, Y. Zhu. |
| Date: | July 2024 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9603 |
|
Segment Routing (SR) can be used to steer packets through a network using the IPv6 or MPLS data plane, employing the source routing paradigm.An SR Path can be derived from a variety of mechanisms, including anIGP Shortest Path Tree (SPT), explicit configuration, or a PathComputation Element (PCE).
Since SR can be applied to both MPLS and IPv6 data planes, a PCE should be able to compute an SR Path for both MPLS and IPv6 data planes. The Path Computation Element Communication Protocol (PCEP) extension and mechanisms to support SR-MPLS have been defined. This document outlines the necessary extensions to support SR for the IPv6 data plane within PCEP. |
|
| |
| RFC 9604 | Carrying Binding Label/SID in PCE-Based Networks |
| |
| Authors: | S. Sivabalan, C. Filsfils, J. Tantsura, S. Previdi, C. Li, Ed.. |
| Date: | August 2024 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9604 |
|
In order to provide greater scalability, network confidentiality, and service independence, Segment Routing (SR) utilizes a Binding SegmentIdentifier (BSID), as described in RFC 8402. It is possible to associate a BSID to an RSVP-TE-signaled Traffic Engineering (TE)Label Switched Path (LSP) or an SR TE path. The BSID can be used by an upstream node for steering traffic into the appropriate TE path to enforce SR policies. This document specifies the concept of binding value, which can be either an MPLS label or a Segment Identifier(SID). It further specifies an extension to Path Computation ElementCommunication Protocol (PCEP) for reporting the binding value by aPath Computation Client (PCC) to the Path Computation Element (PCE) to support PCE-based TE policies. |
|
| |
| RFC 9605 | Secure Frame (SFrame): Lightweight Authenticated Encryption for Real-Time Media |
| |
| Authors: | E. Omara, J. Uberti, S. G. Murillo, R. Barnes, Ed., Y. Fablet. |
| Date: | August 2024 |
| Formats: | txt html json pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9605 |
|
This document describes the Secure Frame (SFrame) end-to-end encryption and authentication mechanism for media frames in a multiparty conference call, in which central media servers (SelectiveForwarding Units or SFUs) can access the media metadata needed to make forwarding decisions without having access to the actual media.
This mechanism differs from the Secure Real-Time Protocol (SRTP) in that it is independent of RTP (thus compatible with non-RTP media transport) and can be applied to whole media frames in order to be more bandwidth efficient. |
|
| |
| RFC 9606 | DNS Resolver Information |
| |
| Authors: | T. Reddy.K, M. Boucadair. |
| Date: | June 2024 |
| Formats: | txt xml pdf json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9606 |
|
This document specifies a method for DNS resolvers to publish information about themselves. DNS clients can use the resolver information to identify the capabilities of DNS resolvers. How DNS clients use such information is beyond the scope of this document. |
|
| |
| RFC 9607 | RTP Payload Format for the Secure Communication Interoperability Protocol (SCIP) Codec |
| |
| Authors: | D. Hanson, M. Faller, K. Maver. |
| Date: | July 2024 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9607 |
|
This document describes the RTP payload format of the SecureCommunication Interoperability Protocol (SCIP). SCIP is an application-layer protocol that provides end-to-end session establishment, payload encryption, packetization and de-packetization of media, and reliable transport. This document provides a globally available reference that can be used for the development of network equipment and procurement of services that support SCIP traffic. The intended audience is network security policymakers; network administrators, architects, and original equipment manufacturers(OEMs); procurement personnel; and government agency and commercial industry representatives. |
|
| |
| RFC 9608 | No Revocation Available for X.509 Public Key Certificates |
| |
|
|
X.509v3 public key certificates are profiled in RFC 5280. Short- lived certificates are seeing greater use in the Internet. TheCertification Authority (CA) that issues these short-lived certificates do not publish revocation information because the certificate lifespan that is shorter than the time needed to detect, report, and distribute revocation information. Some long-livedX.509v3 public key certificates never expire, and they are never revoked. This specification defines the noRevAvail certificate extension so that a relying party can readily determine that the CA does not publish revocation information for the certificate, and it updates the certification path validation algorithm defined in RFC5280 so that revocation checking is skipped when the noRevAvail certificate extension is present. |
|
| |
| RFC 9610 | JSON Meta Application Protocol (JMAP) for Contacts |
| |
|
|
This document specifies a data model for synchronising contact data with a server using the JSON Meta Application Protocol (JMAP). |
|
| |
| RFC 9611 | Internet Key Exchange Protocol Version 2 (IKEv2) Support for Per-Resource Child Security Associations (SAs) |
| |
| Authors: | A. Antony, T. Brunner, S. Klassert, P. Wouters. |
| Date: | July 2024 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9611 |
|
In order to increase the bandwidth of IPsec traffic between peers, this document defines one Notify Message Status Types and one NotifyMessage Error Types payload for the Internet Key Exchange ProtocolVersion 2 (IKEv2) to support the negotiation of multiple ChildSecurity Associations (SAs) with the same Traffic Selectors used on different resources, such as CPUs.
The SA_RESOURCE_INFO notification is used to convey information that the negotiated Child SA and subsequent new Child SAs with the sameTraffic Selectors are a logical group of Child SAs where most or all of the Child SAs are bound to a specific resource, such as a specificCPU. The TS_MAX_QUEUE notify conveys that the peer is unwilling to create more additional Child SAs for this particular negotiatedTraffic Selector combination.
Using multiple Child SAs with the same Traffic Selectors has the benefit that each resource holding the Child SA has its own SequenceNumber Counter, ensuring that CPUs don't have to synchronize their cryptographic state or disable their packet replay protection. |
|
| |
| RFC 9612 | Bidirectional Forwarding Detection (BFD) Reverse Path for MPLS Label Switched Paths (LSPs) |
| |
| Authors: | G. Mirsky, J. Tantsura, I. Varlashkin, M. Chen. |
| Date: | July 2024 |
| Formats: | txt json xml html pdf |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9612 |
|
Bidirectional Forwarding Detection (BFD) is expected to be able to monitor a wide variety of encapsulations of paths between systems.When a BFD session monitors an explicitly routed unidirectional path, there may be a need to direct the egress BFD peer to use a specific path for the reverse direction of the BFD session. This document describes an extension to the MPLS Label Switched Path (LSP) echo request that allows a BFD system to request that the remote BFD peer transmit BFD control packets over the specified LSP. |
|
| |
| RFC 9613 | Requirements for Solutions that Support MPLS Network Actions (MNAs) |
| |
| Authors: | M. Bocci, Ed., S. Bryant, J. Drake. |
| Date: | August 2024 |
| Formats: | txt json xml pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9613 |
|
This document specifies requirements for the development of MPLSNetwork Actions (MNAs) that affect the forwarding or other processing of MPLS packets. These requirements are informed by a number of proposals for additions to the MPLS information in the labeled packet to allow such actions to be performed, either by a transit or terminating Label Switching Router (i.e., the Label Edge Router -LER). |
|
| |
| RFC 9614 | Partitioning as an Architecture for Privacy |
| |
| Authors: | M. Kühlewind, T. Pauly, C. A. Wood. |
| Date: | July 2024 |
| Formats: | txt html json xml pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9614 |
|
This document describes the principle of privacy partitioning, which selectively spreads data and communication across multiple parties as a means to improve privacy by separating user identity from user data. This document describes emerging patterns in protocols to partition what data and metadata is revealed through protocol interactions, provides common terminology, and discusses how to analyze such models. |
|
| |
| RFC 9615 | Automatic DNSSEC Bootstrapping Using Authenticated Signals from the Zone's Operator |
| |
|
|
This document introduces an in-band method for DNS operators to publish arbitrary information about the zones for which they are authoritative, in an authenticated fashion and on a per-zone basis.The mechanism allows managed DNS operators to securely announceDNSSEC key parameters for zones under their management, including for zones that are not currently securely delegated.
Whenever DS records are absent for a zone's delegation, this signal enables the parent's registry or registrar to cryptographically validate the CDS/CDNSKEY records found at the child's apex. The parent can then provision DS records for the delegation without resorting to out-of-band validation or weaker types of cross-checks such as "Accept after Delay".
This document establishes the DS enrollment method described inSection 4 of this document as the preferred method over those fromSection 3 of RFC 8078. It also updates RFC 7344. |
|
| |
| RFC 9616 | Delay-Based Metric Extension for the Babel Routing Protocol |
| |
| Authors: | B. Jonglez, J. Chroboczek. |
| Date: | September 2024 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9616 |
|
This document defines an extension to the Babel routing protocol that measures the round-trip time (RTT) between routers and makes it possible to prefer lower-latency links over higher-latency ones. |
|
| |
| RFC 9617 | A YANG Data Model for In Situ Operations, Administration, and Maintenance (IOAM) |
| |
| Authors: | T. Zhou, Ed., J. Guichard, F. Brockners, S. Raghavan. |
| Date: | August 2024 |
| Formats: | txt pdf xml json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9617 |
|
In situ Operations, Administration, and Maintenance (IOAM) is an example of an on-path hybrid measurement method. IOAM defines a method for producing operational and telemetry information that may be exported using the in-band or out-of-band method. RFCs 9197 and9326 discuss the data fields and associated data types for IOAM.This document defines a YANG module for the configuration of IOAM functions. |
|
| |
| RFC 9618 | Updates to X.509 Policy Validation |
| |
|
|
This document updates RFC 5280 to replace the algorithm for X.509 policy validation with an equivalent, more efficient algorithm. The original algorithm built a structure that scaled exponentially in the worst case, leaving implementations vulnerable to denial-of-service attacks. |
|
| |
| RFC 9619 | In the DNS, QDCOUNT Is (Usually) One |
| |
|
|
This document updates RFC 1035 by constraining the allowed value of the QDCOUNT parameter in DNS messages with OPCODE = 0 (QUERY) to a maximum of one, and it specifies the required behavior when values that are not allowed are encountered. |
|
| |
| RFC 9620 | Guidelines for Human Rights Protocol and Architecture Considerations |
| |
|
|
This document sets guidelines for human rights considerations for developers working on network protocols and architectures, similar to the work done on the guidelines for privacy considerations (RFC6973). This is an updated version of the guidelines for human rights considerations in RFC 8280.
This document is a product of the Human Right Protocol Considerations(HRPC) Research Group in the IRTF. |
|
| |
| RFC 9624 | EVPN Broadcast, Unknown Unicast, or Multicast (BUM) Using Bit Index Explicit Replication (BIER) |
| |
| Authors: | Z. Zhang, T. Przygienda, A. Sajassi, J. Rabadan. |
| Date: | August 2024 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9624 |
|
This document specifies protocols and procedures for forwardingBroadcast, Unknown Unicast, or Multicast (BUM) traffic of EthernetVPNs (EVPNs) using Bit Index Explicit Replication (BIER). |
|
| |
| RFC 9625 | EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding |
| |
| Authors: | W. Lin, Z. Zhang, J. Drake, E. Rosen, Ed., J. Rabadan, A. Sajassi. |
| Date: | August 2024 |
| Formats: | txt pdf xml html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9625 |
|
Ethernet VPN (EVPN) provides a service that allows a single LocalArea Network (LAN), comprising a single IP subnet, to be divided into multiple segments. Each segment may be located at a different site, and the segments are interconnected by an IP or MPLS backbone.Intra-subnet traffic (either unicast or multicast) always appears to the end users to be bridged, even when it is actually carried over the IP or MPLS backbone. When a single tenant owns multiple suchLANs, EVPN also allows IP unicast traffic to be routed between thoseLANs. This document specifies new procedures that allow inter-subnetIP multicast traffic to be routed among the LANs of a given tenant while still making intra-subnet IP multicast traffic appear to be bridged. These procedures can provide optimal routing of the inter- subnet multicast traffic and do not require any such traffic to egress a given router and then ingress that same router. These procedures also accommodate IP multicast traffic that originates or is destined to be external to the EVPN domain. |
|
| |
| RFC 9629 | Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS) |
| |
|
|
The Cryptographic Message Syntax (CMS) supports key transport and key agreement algorithms. In recent years, cryptographers have been specifying Key Encapsulation Mechanism (KEM) algorithms, including quantum-secure KEM algorithms. This document defines conventions for the use of KEM algorithms by the originator and recipients to encrypt and decrypt CMS content. This document updates RFC 5652. |
|
| |
| RFC 9630 | Multicast On-Path Telemetry Using In Situ Operations, Administration, and Maintenance (IOAM) |
| |
| Authors: | H. Song, M. McBride, G. Mirsky, G. Mishra, H. Asaeda, T. Zhou. |
| Date: | August 2024 |
| Formats: | txt html pdf json xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9630 |
|
This document specifies two solutions to meet the requirements of on- path telemetry for multicast traffic using IOAM. While IOAM is advantageous for multicast traffic telemetry, some unique challenges are present. This document provides the solutions based on the IOAM trace option and direct export option to support the telemetry data correlation and the multicast tree reconstruction without incurring data redundancy. |
|
| |
| RFC 9631 | The IPv6 Compact Routing Header (CRH) |
| |
| Authors: | R. Bonica, Y. Kamite, A. Alston, D. Henriques, L. Jalil. |
| Date: | August 2024 |
| Formats: | txt html pdf json xml |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9631 |
|
This document describes an experiment in which two new IPv6 Routing headers are implemented and deployed. Collectively, they are called the Compact Routing Header (CRH). Individually, they are calledCRH-16 and CRH-32.
One purpose of this experiment is to demonstrate that the CRH can be implemented and deployed in a production network. Another purpose is to demonstrate that the security considerations described in this document can be addressed with Access Control Lists (ACLs). Finally, this document encourages replication of the experiment. |
|
| |
| RFC 9632 | Finding and Using Geofeed Data |
| |
|
|
This document specifies how to augment the Routing PolicySpecification Language (RPSL) inetnum: class to refer specifically to geofeed comma-separated values (CSV) data files and describes an optional scheme that uses the Resource Public Key Infrastructure(RPKI) to authenticate the geofeed data files. This document obsoletes RFC 9092. |
|
| |
| RFC 9633 | Deterministic Networking (DetNet) YANG Data Model |
| |
| Authors: | X. Geng, Y. Ryoo, D. Fedyk, R. Rahman, Z. Li. |
| Date: | October 2024 |
| Formats: | txt xml pdf json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9633 |
|
This document contains the specification for the DeterministicNetworking (DetNet) YANG data model for configuration and operational data for DetNet flows. The model allows the provisioning of an end- to-end DetNet service on devices along the path without depending on any signaling protocol. It also specifies operational status for flows.
The YANG module defined in this document conforms to the NetworkManagement Datastore Architecture (NMDA). |
|
| |
| RFC 9634 | Operations, Administration, and Maintenance (OAM) for Deterministic Networking (DetNet) with the IP Data Plane |
| |
| Authors: | G. Mirsky, M. Chen, D. Black. |
| Date: | October 2024 |
| Formats: | txt xml html pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9634 |
|
This document discusses the use of existing IP Operations,Administration, and Maintenance protocols and mechanisms inDeterministic Networking networks that use the IP data plane. |
|
| |
| RFC 9635 | Grant Negotiation and Authorization Protocol (GNAP) |
| |
| Authors: | J. Richer, Ed., F. Imbault. |
| Date: | October 2024 |
| Formats: | txt xml html pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9635 |
|
The Grant Negotiation and Authorization Protocol (GNAP) defines a mechanism for delegating authorization to a piece of software and conveying the results and artifacts of that delegation to the software. This delegation can include access to a set of APIs as well as subject information passed directly to the software. |
|
| |
| RFC 9636 | The Time Zone Information Format (TZif) |
| |
|
|
This document specifies the Time Zone Information Format (TZif) for representing and exchanging time zone information, independent of any particular service or protocol. Two media types for this format are also defined.
This document replaces and obsoletes RFC 8536. |
|
| |
| RFC 9637 | Expanding the IPv6 Documentation Space |
| |
|
|
The document describes the reservation of an additional IPv6 address prefix for use in documentation. This update to RFC 3849 expands on the existing 2001:db8::/32 address block with the reservation of an additional, larger prefix. The addition of a /20 prefix allows documented examples to more closely reflect a broader range of realistic, current deployment scenarios and more closely aligns with contemporary allocation models for large networks. |
|
| |
| RFC 9638 | Network Virtualization over Layer 3 (NVO3) Encapsulation Considerations |
| |
| Authors: | S. Boutros, D. Eastlake 3rd, Ed.. |
| Date: | September 2024 |
| Formats: | txt html pdf xml json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9638 |
|
The IETF Network Virtualization Overlays (NVO3) Working Group developed considerations for a common encapsulation that addresses various network virtualization overlay technical concerns. This document provides a record, for the benefit of the IETF community, of the considerations arrived at by the NVO3 Working Group starting from the output of the NVO3 encapsulation Design Team. These considerations may be helpful with future deliberations by working groups over the choice of encapsulation formats.
There are implications of having different encapsulations in real environments consisting of both software and hardware implementations and within and spanning multiple data centers. For example,Operations, Administration, and Maintenance (OAM) functions such as path MTU discovery become challenging with multiple encapsulations along the data path.
Based on these considerations, the NVO3 Working Group determined thatGeneric Network Virtualization Encapsulation (Geneve) with a few modifications is the common encapsulation. This document provides more details, particularly in Section 7. |
|
| |
| RFC 9639 | Free Lossless Audio Codec (FLAC) |
| |
| Authors: | M.Q.C. van Beurden, A. Weaver. |
| Date: | December 2024 |
| Formats: | txt html json pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9639 |
|
This document defines the Free Lossless Audio Codec (FLAC) format and its streamable subset. FLAC is designed to reduce the amount of computer storage space needed to store digital audio signals. It does this losslessly, i.e., it does so without losing information.FLAC is free in the sense that its specification is open and its reference implementation is open source. Compared to other lossless audio coding formats, FLAC is a format with low complexity and can be encoded and decoded with little computing resources. Decoding ofFLAC has been implemented independently for many different platforms, and both encoding and decoding can be implemented without needing floating-point arithmetic. |
|
| |
| RFC 9640 | YANG Data Types and Groupings for Cryptography |
| |
|
|
This document presents a YANG 1.1 (RFC 7950) module defining identities, typedefs, and groupings useful to cryptographic applications. |
|
| |
| RFC 9641 | A YANG Data Model for a Truststore |
| |
|
|
This document presents a YANG module for configuring bags of certificates and bags of public keys that can be referenced by other data models for trust. Notifications are sent when certificates are about to expire. |
|
| |
| RFC 9642 | A YANG Data Model for a Keystore |
| |
|
|
This document presents a YANG module called "ietf-keystore" that enables centralized configuration of both symmetric and asymmetric keys. The secret value for both key types may be encrypted or hidden. Asymmetric keys may be associated with certificates.Notifications are sent when certificates are about to expire. |
|
| |
| RFC 9643 | YANG Groupings for TCP Clients and TCP Servers |
| |
|
|
This document presents three YANG 1.1 modules to support the configuration of TCP clients and TCP servers. The modules include basic parameters of a TCP connection relevant for client or server applications, as well as client configuration required for traversing proxies. The data models defined by these modules may be used directly (e.g., to define a specific TCP client or TCP server) or in conjunction with the configuration defined for higher level protocols that depend on TCP (e.g., SSH, TLS, etc.). Examples of higher level protocol configuration designed to be used in conjunction with this configuration are in RFCs 9644 and 9645. |
|
| |
| RFC 9644 | YANG Groupings for SSH Clients and SSH Servers |
| |
|
|
This document presents three IETF-defined YANG modules and a script used to create four supporting IANA modules.
The three IETF modules are ietf-ssh-common, ietf-ssh-client, and ietf-ssh-server. The "ietf-ssh-client" and "ietf-ssh-server" modules are the primary productions of this work, supporting the configuration and monitoring of Secure Shell (SSH) clients and servers.
The four IANA modules are iana-ssh-encryption-algs, iana-ssh-key- exchange-algs, iana-ssh-mac-algs, and iana-ssh-public-key-algs.These modules each define YANG enumerations providing support for anIANA-maintained algorithm registry. |
|
| |
| RFC 9645 | YANG Groupings for TLS Clients and TLS Servers |
| |
|
|
This document presents four YANG 1.1 modules -- three IETF modules and one supporting IANA module.
The three IETF modules are "ietf-tls-common", "ietf-tls-client", and"ietf-tls-server". The "ietf-tls-client" and "ietf-tls-server" modules are the primary productions of this work, supporting the configuration and monitoring of TLS clients and servers.
The IANA module is "iana-tls-cipher-suite-algs". This module definesYANG enumerations that provide support for an IANA-maintained algorithm registry. |
|
| |
| RFC 9646 | Conveying a Certificate Signing Request (CSR) in a Secure Zero-Touch Provisioning (SZTP) Bootstrapping Request |
| |
|
|
This document extends the input to the "get-bootstrapping-data" RPC defined in RFC 8572 to include an optional certificate signing request (CSR), enabling a bootstrapping device to additionally obtain an identity certificate (e.g., a Local Device Identifier (LDevID) from IEEE 802.1AR) as part of the "onboarding information" response provided in the RPC-reply. |
|
| |
| RFC 9647 | A YANG Data Model for Babel |
| |
| Authors: | M. Jethanandani, B. Stark. |
| Date: | October 2024 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9647 |
|
This document defines a data model for the Babel routing protocol.The data model is defined using the YANG data modeling language. |
|
| |
| RFC 9648 | YANG Data Model for TCP |
| |
| Authors: | M. Scharf, M. Jethanandani, V. Murgai. |
| Date: | October 2024 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9648 |
|
This document specifies a minimal YANG data model for TCP on devices that are configured and managed by network management protocols. TheYANG data model defines a container for all TCP connections and groupings of authentication parameters that can be imported and used in TCP implementations or by other models that need to configure TCP parameters. The model also includes basic TCP statistics. The model is compliant with Network Management Datastore Architecture (NMDA)(RFC 8342). |
|
| |
| RFC 9649 | WebP Image Format |
| |
| Authors: | J. Zern, P. Massimino, J. Alakuijala. |
| Date: | November 2024 |
| Formats: | txt xml json pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9649 |
|
This document defines the WebP image format and registers a media type supporting its use. |
|
| |
| RFC 9650 | Revision to Registration Procedures for IS-IS Neighbor Link-Attribute Bit Values |
| |
|
|
RFC 5029, "Definition of an IS-IS Link Attribute Sub-TLV", defines anIANA registry called "IS-IS Neighbor Link-Attribute Bit Values".This document changes the registration procedure for that registry from "Standards Action" to "Expert Review". This document updatesRFC 5029. |
|
| |
| RFC 9651 | Structured Field Values for HTTP |
| |
|
|
This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handleHTTP header and trailer fields, known as "Structured Fields","Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields.
This document obsoletes RFC 8941. |
|
| |
| RFC 9652 | The Link-Template HTTP Header Field |
| |
|
|
This specification defines the Link-Template HTTP header field, providing a means for describing the structure of a link between two resources so that new links can be generated. |
|
| |
| RFC 9653 | Zero Checksum for the Stream Control Transmission Protocol |
| |
| Authors: | M. Tüxen, V. Boivie, F. Castelli, R. Jesup. |
| Date: | September 2024 |
| Formats: | txt html json xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9653 |
|
The Stream Control Transmission Protocol (SCTP) uses a 32-bit checksum in the common header of each packet to provide some level of data integrity. If another method used by SCTP already provides the same or a higher level of data integrity, computing this checksum does not provide any additional protection but does consume computing resources.
This document provides a simple extension allowing SCTP to save these computing resources by using zero as the checksum in a backwards- compatible way. It also defines how this feature can be used whenSCTP packets are encapsulated in Datagram Transport Layer Security(DTLS) packets. |
|
| |
| RFC 9654 | Online Certificate Status Protocol (OCSP) Nonce Extension |
| |
|
|
RFC 8954 imposed size constraints on the optional Nonce extension for the Online Certificate Status Protocol (OCSP). OCSP is used to check the status of a certificate, and the Nonce extension is used to cryptographically bind an OCSP response message to a particular OCSP request message.
Some environments use cryptographic algorithms that generate a Nonce value that is longer than 32 octets. This document also modifies the"Nonce" section of RFC 6960 to clearly define and differentiate the encoding format and values for easier implementation and understanding. This document obsoletes RFC 8954, which includes updated ASN.1 modules for OCSP, and updates RFC 6960. |
|
| |
| RFC 9655 | Egress Validation in Label Switched Path Ping and Traceroute Mechanisms |
| |
| Authors: | D. Rathi, Ed., S. Hegde, Ed., K. Arora, Z. Ali, N. Nainar. |
| Date: | November 2024 |
| Formats: | txt json xml html pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9655 |
|
The MPLS ping and traceroute mechanisms described in RFC 8029 and the related extensions for Segment Routing (SR) defined in RFC 8287 are highly valuable for validating control plane and data plane synchronization. In certain environments, only some intermediate or transit nodes may have been upgraded to support these validation procedures. A straightforward MPLS ping and traceroute mechanism allows traversal of any path without validation of the control plane state. RFC 8029 supports this mechanism with the Nil ForwardingEquivalence Class (FEC). The procedures outlined in RFC 8029 are primarily applicable when the Nil FEC is used as an intermediate FEC in the FEC stack. However, challenges arise when all labels in the label stack are represented using the Nil FEC.
This document introduces a new Type-Length-Value (TLV) as an extension to the existing Nil FEC. It describes MPLS ping and traceroute procedures using the Nil FEC with this extension to address and overcome these challenges. |
|
| |
| RFC 9656 | A YANG Data Model for Microwave Topology |
| |
| Authors: | S. Mansfield, Ed., J. Ahlberg, M. Ye, X. Li, D. Spreafico. |
| Date: | September 2024 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9656 |
|
This document defines a YANG data model to describe microwave and millimeter-wave radio links in a network topology. |
|
| |
| RFC 9657 | Time-Variant Routing (TVR) Use Cases |
| |
| Authors: | E. Birrane III, N. Kuhn, Y. Qu, R. Taylor, L. Zhang. |
| Date: | October 2024 |
| Formats: | txt pdf xml html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9657 |
|
This document introduces use cases where Time-Variant Routing (TVR) computations (i.e., routing computations that take into consideration time-based or scheduled changes to a network) could improve routing protocol convergence and/or network performance. |
|
| |
| RFC 9658 | Multipoint LDP Extensions for Multi-Topology Routing |
| |
| Authors: | IJ. Wijnands, M. Mishra, Ed., K. Raza, Z. Zhang, A. Gulko. |
| Date: | October 2024 |
| Formats: | txt json pdf xml html |
| Updates: | RFC 7307 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9658 |
|
Multi-Topology Routing (MTR) is a technology that enables service differentiation within an IP network. The Flexible Algorithm (FA) is another mechanism for creating a sub-topology within a topology using defined topology constraints and computation algorithms. In order to deploy Multipoint LDP (mLDP) in a network that supports MTR, FA, or other methods of signaling non-default IGP Algorithms (IPAs), mLDP is required to become topology and algorithm aware. This document specifies extensions to mLDP to support the use of MTR/IPAs such that, when building multipoint Label Switched Paths (LSPs), the LSPs can follow a particular topology and algorithm. This document updates RFC 7307 by allocating eight bits from a previously reserved field to be used as the "IPA" field. |
|
| |
| RFC 9659 | Window Sizing for Zstandard Content Encoding |
| |
|
|
Deployments of Zstandard, or "zstd", can use different window sizes to limit memory usage during compression and decompression. Some browsers and user agents limit window sizes to mitigate memory usage concerns, thereby causing interoperability issues. This document updates the window size limit in RFC 8878 from a recommendation to a requirement in HTTP contexts. |
|
| |
| RFC 9660 | The DNS Zone Version (ZONEVERSION) Option |
| |
| Authors: | H. Salgado, M. Vergara, D. Wessels. |
| Date: | October 2024 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9660 |
|
The DNS ZONEVERSION option is a way for DNS clients to request, and for authoritative DNS servers to provide, information regarding the version of the zone from which a response is generated. The SERIAL field from the Start of Authority (SOA) resource record (RR) is a good example of a zone's version, and it is the only one defined by this specification. Additional version types may be defined by future specifications.
Including zone version data in a response simplifies and improves the quality of debugging and diagnostics since the version and the DNS answer are provided atomically. This can be especially useful for zones and DNS providers that leverage IP anycast or multiple backend systems. It functions similarly to the DNS Name Server Identifier(NSID) option described in RFC 5001. |
|
| |
| RFC 9661 | The JSON Meta Application Protocol (JMAP) for Sieve Scripts |
| |
|
|
This document specifies a data model for managing Sieve scripts on a server using the JSON Meta Application Protocol (JMAP). Clients can use this protocol to efficiently search, access, organize, and validate Sieve scripts. |
|
| |
| RFC 9662 | Updates to the Cipher Suites in Secure Syslog |
| |
|
|
RFCs 5425 and 6012 describe using TLS and DTLS to securely transport syslog messages. This document updates the cipher suites required byRFC 5245 (TLS Transport Mapping for Syslog) and RFC 6012 (DTLSTransport Mapping for Syslog). It also updates the protocol recommended by RFC 6012 for secure datagram transport. |
|
| |
| RFC 9663 | Using DHCPv6 Prefix Delegation (DHCPv6-PD) to Allocate Unique IPv6 Prefixes per Client in Large Broadcast Networks |
| |
| Authors: | L. Colitti, J. Linkova, Ed., X. Ma, Ed.. |
| Date: | October 2024 |
| Formats: | txt html pdf xml json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9663 |
|
This document discusses an IPv6 deployment scenario when individual nodes connected to large broadcast networks (such as enterprise networks or public Wi-Fi networks) are allocated unique prefixes viaDHCPv6 Prefix Delegation (DHCPv6-PD), as specified in RFC 8415. |
|
| |
| RFC 9666 | Area Proxy for IS-IS |
| |
| Authors: | T. Li, S. Chen, V. Ilangovan, G. Mishra. |
| Date: | October 2024 |
| Formats: | txt html json xml pdf |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9666 |
|
Link-state routing protocols have hierarchical abstraction already built into them. However, when lower levels are used for transit, they must expose their internal topologies to each other, thereby leading to scaling issues.
To avoid such issues, this document discusses extensions to the IS-IS routing protocol that allow Level 1 (L1) areas to provide transit but only inject an abstraction of the Level 1 topology into Level 2 (L2).Each Level 1 area is represented as a single Level 2 node, thereby enabling a greater scale. |
|
| |
| RFC 9667 | Dynamic Flooding on Dense Graphs |
| |
| Authors: | T. Li, Ed., P. Psenak, Ed., H. Chen, L. Jalil, S. Dontula. |
| Date: | October 2024 |
| Formats: | txt html xml pdf json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9667 |
|
Routing with link-state protocols in dense network topologies can result in suboptimal convergence times due to the overhead associated with flooding. This can be addressed by decreasing the flooding topology so that it is less dense.
This document discusses the problem in some depth and an architectural solution. Specific protocol changes for IS-IS, OSPFv2, and OSPFv3 are described in this document. |
|
| |
| RFC 9668 | Using Ephemeral Diffie-Hellman Over COSE (EDHOC) with the Constrained Application Protocol (CoAP) and Object Security for Constrained RESTful Environments (OSCORE) |
| |
| Authors: | F. Palombini, M. Tiloca, R. Höglund, S. Hristozov, G. Selander. |
| Date: | November 2024 |
| Formats: | txt json html xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9668 |
|
The lightweight authenticated key exchange protocol Ephemeral Diffie-Hellman Over COSE (EDHOC) can be run over the Constrained ApplicationProtocol (CoAP) and used by two peers to establish a Security Context for the security protocol Object Security for Constrained RESTfulEnvironments (OSCORE). This document details this use of the EDHOC protocol by specifying a number of additional and optional mechanisms, including an optimization approach for combining the execution of EDHOC with the first OSCORE transaction. This combination reduces the number of round trips required to set up anOSCORE Security Context and to complete an OSCORE transaction using that Security Context. |
|
| |
| RFC 9669 | BPF Instruction Set Architecture (ISA) |
| |
|
|
eBPF (which is no longer an acronym for anything), also commonly referred to as BPF, is a technology with origins in the Linux kernel that can run untrusted programs in a privileged context such as an operating system kernel. This document specifies the BPF instruction set architecture (ISA). |
|
| |
| RFC 9670 | JSON Meta Application Protocol (JMAP) Sharing |
| |
|
|
This document specifies a data model for sharing data between users using the JSON Meta Application Protocol (JMAP). Future documents can reference this document when defining data types to support a consistent model of sharing. |
|
| |
| RFC 9671 | Sieve Email Filtering: Extension for Processing Calendar Attachments |
| |
| Authors: | K. Murchison, R. Signes, M. Horsfall. |
| Date: | October 2024 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9671 |
|
This document describes the "processcalendar" extension to the Sieve email filtering language. The "processcalendar" extension givesSieve the ability to process machine-readable calendar data that is encapsulated in an email message using Multipurpose Internet MailExtensions (MIME). |
|
| |
| RFC 9673 | IPv6 Hop-by-Hop Options Processing Procedures |
| |
|
|
This document specifies procedures for processing IPv6 Hop-by-Hop options in IPv6 routers and hosts. It modifies the procedures specified in the IPv6 Protocol Specification (RFC 8200) to make processing of the IPv6 Hop-by-Hop Options header practical with the goal of making IPv6 Hop-by-Hop options useful to deploy and use atIPv6 routers and hosts. This document updates RFC 8200. |
|
| |
| RFC 9674 | Same-Origin Policy for the RPKI Repository Delta Protocol (RRDP) |
| |
|
|
This document describes a Same-Origin Policy (SOP) requirement forResource Public Key Infrastructure (RPKI) Repository Delta Protocol(RRDP) servers and clients. Application of a SOP in RRDP client/ server communication isolates resources such as Delta and Snapshot files from different Repository Servers, reducing possible attack vectors. This document updates RFC 8182. |
|
| |
| RFC 9675 | Delay-Tolerant Networking Management Architecture (DTNMA) |
| |
| Authors: | E. Birrane III, S. Heiner, E. Annis. |
| Date: | November 2024 |
| Formats: | txt json xml pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9675 |
|
The Delay-Tolerant Networking (DTN) architecture describes a type of challenged network in which communications may be significantly affected by long signal propagation delays, frequent link disruptions, or both. The unique characteristics of this environment require a unique approach to network management that supports asynchronous transport, autonomous local control, and a small footprint (in both resources and dependencies) so as to deploy on constrained devices.
This document describes a DTN Management Architecture (DTNMA) suitable for managing devices in any challenged environment but, in particular, those communicating using the DTN Bundle Protocol (BP).Operating over BP requires an architecture that neither presumes synchronized transport behavior nor relies on query-response mechanisms. Implementations compliant with this DTNMA should expect to successfully operate in extremely challenging conditions, such as over unidirectional links and other places where BP is the preferred transport. |
|
| |
| RFC 9677 | Content Delivery Network Interconnection (CDNI) Metadata for Delegated Credentials |
| |
| Authors: | F. Fieau, E. Stephan, G. Bichot, C. Neumann. |
| Date: | October 2024 |
| Formats: | txt html pdf json xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9677 |
|
The delivery of content over HTTPS involving multiple ContentDelivery Networks (CDNs) raises credential management issues. This document defines metadata in the Content Delivery NetworkInterconnection (CDNI) Control and Metadata interface to set up HTTPS delegation using delegated credentials from an upstream CDN (uCDN) to a downstream CDN (dCDN). |
|
| |
| RFC 9679 | CBOR Object Signing and Encryption (COSE) Key Thumbprint |
| |
| Authors: | K. Isobe, H. Tschofenig, O. Steele. |
| Date: | December 2024 |
| Formats: | txt json pdf html xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9679 |
|
This specification defines a method for computing a hash value over aCBOR Object Signing and Encryption (COSE) Key. It specifies which fields within the COSE Key structure are included in the cryptographic hash computation, the process for creating a canonical representation of these fields, and how to hash the resulting byte sequence. The resulting hash value, referred to as a "thumbprint", can be used to identify or select the corresponding key. |
|
| |
| RFC 9680 | Antitrust Guidelines for IETF Participants |
| |
| Authors: | J. Halpern, Ed., J. Daley. |
| Date: | October 2024 |
| Formats: | txt json pdf xml html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9680 |
|
This document provides education and guidance for IETF participants on compliance with antitrust laws and how to reduce antitrust risks in connection with IETF activities. |
|
| |
| RFC 9681 | IS-IS Fast Flooding |
| |
| Authors: | B. Decraene, L. Ginsberg, T. Li, G. Solignac, M. Karasek, G. Van de Velde, T. Przygienda. |
| Date: | November 2024 |
| Formats: | txt pdf xml json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9681 |
|
Current Link State PDU flooding rates are much slower than what modern networks can support. The use of IS-IS at larger scale requires faster flooding rates to achieve desired convergence goals.This document discusses the need for faster flooding, the issues around faster flooding, and some example approaches to achieve faster flooding. It also defines protocol extensions relevant to faster flooding. |
|
| |
| RFC 9682 | Updates to the Concise Data Definition Language (CDDL) Grammar |
| |
|
|
The Concise Data Definition Language (CDDL), as defined in RFCs 8610 and 9165, provides an easy and unambiguous way to express structures for protocol messages and data formats that are represented inConcise Binary Object Representation (CBOR) or JSON.
This document updates RFC 8610 by addressing related errata reports and making other small fixes for the ABNF grammar defined for CDDL. |
|
| |
| RFC 9683 | Remote Integrity Verification of Network Devices Containing Trusted Platform Modules |
| |
| Authors: | G. C. Fedorkow, Ed., E. Voit, J. Fitzgerald-McKay. |
| Date: | December 2024 |
| Formats: | txt html json xml pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9683 |
|
This document describes a workflow for remote attestation of the integrity of firmware and software installed on network devices that contain Trusted Platform Modules (TPMs), as defined by the TrustedComputing Group (TCG), or equivalent hardware implementations that include the protected capabilities, as provided by TPMs. |
|
| |
| RFC 9684 | A YANG Data Model for Challenge-Response-Based Remote Attestation (CHARRA) Procedures Using Trusted Platform Modules (TPMs) |
| |
| Authors: | H. Birkholz, M. Eckel, S. Bhandari, E. Voit, B. Sulzen, L. Xia, T. Laffey, G. C. Fedorkow. |
| Date: | December 2024 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9684 |
|
This document defines the YANG Remote Procedure Calls (RPCs) and configuration nodes that are required to retrieve attestation evidence about integrity measurements from a device, following the operational context defined in RFC 9683 "TPM-based Network DeviceRemote Integrity Verification". Complementary measurement logs originating from one or more Roots of Trust for Measurement (RTMs) are also provided by the YANG RPCs. The defined module requires the inclusion of the following in the device components of the composite device on which the YANG server is running: at least one TrustedPlatform Module (TPM) of either version 1.2 or 2.0 as well as a corresponding TPM Software Stack (TSS), or an equivalent hardware implementation that includes the protected capabilities as provided by TPMs as well as a corresponding software stack. |
|
| |
| RFC 9685 | Listener Subscription for IPv6 Neighbor Discovery Multicast and Anycast Addresses |
| |
|
|
This document updates the 6LoWPAN extensions to IPv6 NeighborDiscovery (specified in RFCs 4861 and 8505) to enable a listener to subscribe to an IPv6 anycast or multicast address. This document also updates the Routing Protocol for Low-Power and Lossy Networks(RPL) (specified in RFCs 6550 and 6553) to add a new Non-Storing multicast mode and new support for anycast addresses in Storing andNon-Storing modes. This document extends RFC 9010 to enable a6LoWPAN Router (6LR) to inject the anycast and multicast addresses inRPL. |
|
| |
| RFC 9686 | Registering Self-Generated IPv6 Addresses Using DHCPv6 |
| |
| Authors: | W. Kumari, S. Krishnan, R. Asati, L. Colitti, J. Linkova, S. Jiang. |
| Date: | December 2024 |
| Formats: | txt pdf html xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9686 |
|
This document defines a method to inform a DHCPv6 server that a device has one or more self-generated or statically configured addresses. |
|
| |
| RFC 9687 | Border Gateway Protocol 4 (BGP-4) Send Hold Timer |
| |
|
|
This document defines the SendHoldTimer, along with theSendHoldTimer_Expires event, for the Border Gateway Protocol (BGP)Finite State Machine (FSM). Implementation of the SendHoldTimer helps overcome situations where a BGP connection is not terminated after the local system detects that the remote system is not processing BGP messages. This document specifies that the local system should close the BGP connection and not solely rely on the remote system for connection closure when the SendHoldTimer expires.This document updates RFC 4271. |
|
| |
| RFC 9688 | Use of the SHA3 One-Way Hash Functions in the Cryptographic Message Syntax (CMS) |
| |
|
|
This document describes the conventions for using the one-way hash functions in the SHA3 family with the Cryptographic Message Syntax(CMS). The SHA3 family can be used as a message digest algorithm, as part of a signature algorithm, as part of a message authentication code, or as part of a Key Derivation Function (KDF). |
|
| |
| RFC 9689 | Use Cases for a PCE as a Central Controller (PCECC) |
| |
| Authors: | Z. Li, D. Dhody, Q. Zhao, Z. Ke, B. Khasanov. |
| Date: | December 2024 |
| Formats: | txt pdf xml json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9689 |
|
The PCE is a core component of a Software-Defined Networking (SDN) system. It can be used to compute optimal paths for network traffic and update existing paths to reflect changes in the network or traffic demands. The PCE was developed to derive Traffic Engineering(TE) paths in MPLS networks, which are supplied to the headend of the paths using the Path Computation Element Communication Protocol(PCEP).
SDN has much broader applicability than signalled MPLS TE networks, and the PCE may be used to determine paths in a range of use cases including static Label-Switched Paths (LSPs), Segment Routing (SR),Service Function Chaining (SFC), and most forms of a routed or switched network. Therefore, it is reasonable to consider PCEP as a control protocol for use in these environments to allow the PCE to be fully enabled as a central controller.
A PCE as a Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN without necessarily completely replacing it. This document describes general considerations for PCECC deployment and examines its applicability and benefits, as well as its challenges and limitations, through a number of use cases. PCEP extensions, which are required for the PCECC use cases, are covered in separate documents. |
|
| |
| RFC 9691 | A Profile for Resource Public Key Infrastructure (RPKI) Trust Anchor Keys (TAKs) |
| |
| Authors: | C. Martinez, G. Michaelson, T. Harrison, T. Bruijnzeels, R. Austein. |
| Date: | December 2024 |
| Formats: | txt xml json pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9691 |
|
A Trust Anchor Locator (TAL) is used by Relying Parties (RPs) in theResource Public Key Infrastructure (RPKI) to locate and validate aTrust Anchor (TA) Certification Authority (CA) certificate used inRPKI validation. This document defines an RPKI signed object for aTrust Anchor Key (TAK). A TAK object can be used by a TA to signal to RPs the location(s) of the accompanying CA certificate for the current public key, as well as the successor public key and the location(s) of its CA certificate. This object helps to support planned key rollovers without impacting RPKI validation. |
|
