| |
|
| |
| | Simple Two-way Active Measurement Protocol (STAMP) for MPLS Label Switched Paths (LSPs) |
| |
|
Simple Two-way Active Measurement Protocol (STAMP), defined in RFC 8762 and RFC 8972, is expected to be able to monitor the performance of paths between systems that use a wide variety of encapsulations. This document defines encapsulation and bootstrapping of a STAMP test session over an MPLS Label Switched Path. |
| | The Restatement Anti-Pattern |
| |
|
Normative documents that cite other normative documents often _restate_ normative content extracted out of the cited document in their own words. The present memo explains why this can be an Antipattern, and how it can be mitigated. |
| | EVPN-Specific BMP RIB Statistics Extensions |
| |
|
This document defines EVPN-specific BGP Monitoring Protocol (BMP) statistics types that extend the generic BMP RIB statistics defined in draft-ietf-grow-bmp-bgp-rib-stats. These extensions include scalar counters for EVPN route types (1-8), locally originated routes, multihoming Ethernet Segments, multihomed EVIs, aliased paths, dynamic inter-VRF route leaking (IVRL), and segment failure impacts, with a 16-bit bitmap for route-map/policy modifications in the high-order 16 bits of a 64-bit field. All counters are applicable to Adj-RIB-In, Adj-RIB-Out, and Local-RIB for the EVPN address family (AFI=25, SAFI=70), using 64-bit gauges unless explicitly specified otherwise. |
| | Segment Routing MPLS Point-to-Multipoint (P2MP) Policy Ping |
| |
|
Point-to-Multipoint (P2MP) Policies are used to define and manage explicit P2MP paths within a network. These policies are typically calculated via a controller-based mechanism and installed via, e.g., a Path Computation Element (PCE). In other cases these policies can be installed via using NETCONF/YANG or CLI. They are used to steer multicast traffic along optimized paths from a Root to a set of Leaf routers. This document defines extensions to Ping and Traceroute mechanisms for SR-P2MP Policy with MPLS encapsulation to provide OAM (Operations, Administration, and Maintenance) capabilities. The extensions enable operators to verify connectivity, diagnose failures and troubleshoot forwarding issues within P2MP Policy multicast trees. By introducing new mechanisms for detecting failures and validating path integrity, this document enhances the operational robustness of P2MP multicast deployments. Additionally, it ensures that existing MPLS and SR-based OAM tools can be effectively applied to networks utilizing P2MP Policies. |
| |
|
| |
| | Bootstrapping Remote Secure Key Infrastructure (BRSKI) Cloud Registrar |
| |
| | draft-ietf-anima-brski-cloud-17.txt |
| | Date: |
22/08/2025 |
| | Authors: |
Owen Friel, Rifaat Shekh-Yusef, Michael Richardson |
| | Working Group: |
Autonomic Networking Integrated Model and Approach (anima) |
|
Bootstrapping Remote Secure Key Infrastructures (BRSKI) defines how to onboard a device securely into an operator-maintained infrastructure. It assumes that there is local network infrastructure for the device to discover. On networks without that, there is nothing present to help onboard the device. This document extends BRSKI and defines behavior for bootstrapping devices for deployments where no local infrastructure is available, such as in a home or remote office. This document defines how the device can use a well-defined "call-home" mechanism to find the operator-maintained infrastructure. This document defines how to contact a well-known Cloud Registrar, and two ways in which the device may be redirected towards the operator-maintained infrastructure. The Cloud Registrar enables discovery of the operator-maintained infrastructure, and may enable establishment of trust with operator-maintained infrastructure that does not support BRSKI mechanisms. This document updates RFC 8995 (BRSKI). |
| | Domain-based Message Authentication,Reporting,and Conformance (DMARC) Failure Reporting |
| |
|
Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a Domain Owner can request feedback about email messages using their domain in the From: address field. This document describes "failure reports," or "failed message reports", which provide details about individual messages that failed to authenticate according to the DMARC mechanism. |
| | BGP CT - Adaptation to SRv6 dataplane |
| |
|
This document specifies how the mechanisms for "Intent Driven Service Mapping" defined in [BGP-CT] are applied to SRv6 dataplane. The extensions needed for SRv6 dataplane operations are specified. Base procedures of BGP CT are followed unaltered. Illustration of how BGP CT procedures work in SRv6 dataplane is provided in this document. |
| | BGP Route Reflector with Next Hop Self |
| |
|
The procedures in BGP Route Reflection (RR) spec RFC4456 primarily deal with scenarios where the RR is reflecting BGP routes with next hop unchanged. In some deployments like Inter-AS Option C (Section 10, RFC4364), the ABRs may perform RR functionality with nexthop set to self. If adequate precautions are not taken, the RFC4456 procedures can result in traffic forwarding loop in such deployments. This document illustrates one such looping scenario, and specifies approaches to minimize possiblity of traffic forwarding loop in such deployments. An example with Inter-AS Option C (Section 10, RFC4364) deployment is used, where RR with next hop self is used at redundant ABRs when they re-advertise BGP transport family routes between multiple IGP domains. |
| | Advertising Unreachable Links in OSPF |
| |
|
In certain scenarios, it is necessary to advertise unreachable links in OSPF, which should be explicitly excluded from the related SPF calculation. This document specifies using LSLinkInfinity(0xffff) to advertise an OSPF link as unreachable. Stub Router Advertisement (RFC 6987) defines MaxLinkMetric (0xffff) to indicate a router-LSA link should not be used for transit traffic. This document updates RFC 6987 and RFC 8770. When an OSPFv2 router supports the Unreachable Link support capability defined in this document, the OSPFv2 stub router MaxLinkMetric(0xffff) MUST be updated to MaxReachableLinkMetric(0xfffe). |
| | PQ/T Hybrid Composite Signatures for JOSE and COSE |
| |
|
This document describes JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for PQ/T hybrid composite signatures. The composite algorithms described combine ML-DSA as the post-quantum component and either ECDSA or EdDSA as the traditional component. |
| | Export of SRv6 Path Segment Identifier Information in IPFIX |
| |
|
This document introduces a new IPFIX Information Element to identify the Path Segment Identifier(PSID) in the SRH for SRv6 path identification purpose. |
| | BGP Extended Communities Attribute |
| |
|
This document describes the "extended community" BGP-4 attribute. This attribute provides a mechanism for labeling information carried in BGP-4. These labels can be used to control the distribution of this information, or for other applications. This document obsoletes [RFC4360]. |
| | Segment Routing Point-to-Multipoint Policy |
| |
| | draft-ietf-pim-sr-p2mp-policy-19.txt |
| | Date: |
22/08/2025 |
| | Authors: |
Rishabh Parekh, Dan Voyer, Clarence Filsfils, Hooman Bidgoli, Zhaohui Zhang |
| | Working Group: |
Protocols for IP Multicast (pim) |
|
Point-to-Multipoint (P2MP) Policy enables creation of P2MP trees for efficient multi-point packet delivery in a Segment Routing (SR) domain. This document specifies the architecture, signaling, and procedures for SR P2MP Policies with Segment Routing over MPLS (SR- MPLS) and Segment Routing over IPv6 (SRv6). It defines the SR P2MP Policy construct, candidate paths (CP) of an SR P2MP Policy and the instantiation of the P2MP tree instances of a candidate path using Replication segments. Additionally, it describes the required extensions for a controller to support P2MP path computation and provisioning. |
| |
|
| |
| | BIER Prefix Redistribute |
| |
|
This document defines a BIER proxy function to support one single BIER sub-domain over multiple underlay routing protocol regions (Autonomous Systems or IGP areas). A new BIER proxy range sub-TLV is defined to redistribute BIER BFR-id information across the routing regions. |
| | Media Type Registration for Protocol Buffers |
| |
|
This document registers media types for Protocol Buffers, a common extensible mechanism for serializing structured data. |
| | IPv4 routes with an IPv6 next hop |
| |
|
This document proposes "v4-via-v6" routing, a technique that uses IPv6 next-hop addresses for routing IPv4 packets, thus making it possible to route IPv4 packets across a network where routers have not been assigned IPv4 addresses. The document both describes the technique, as well as discussing its operational implications. |
| | Internet Key Exchange version 2 (IKEv2) extension for Header Compression Profile (HCP) |
| |
| | draft-ietf-ipsecme-ikev2-diet-esp-extension-06.txt |
| | Date: |
21/08/2025 |
| | Authors: |
Daniel Migault, Maryam Hatami, Daiying Liu, Stere Preda, J. Atwood, Sandra Cespedes, Tobias Guggemos, David Schinazi |
| | Working Group: |
IP Security Maintenance and Extensions (ipsecme) |
|
This document describes an IKEv2 extension for Header Compression to agree on Attributes for Rule Derivation. This extension defines the necessary registries for the ESP Header Compression Profile (EHCP) Diet-ESP. |
| | Media Type Specifications and Registration Procedures |
| |
|
This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. |
| | BGP Signaled MPLS Namespaces |
| |
|
The MPLS forwarding layer in a core network is a shared resource. The MPLS FIB at nodes in this layer contains labels that are dynamically allocated and locally significant at that node. These labels are scoped in context of the global loopback address. Let us call this the global MPLS namespace. For some usecases like upstream label allocation, it is useful to create private MPLS namespaces (virtual MPLS FIB) over this shared MPLS forwarding layer. This allows installing deterministic label values in the private FIBs created at nodes participating in the private MPLS namespace, while preserving the "locally significant" nature of the underlying shared global MPLS FIB. This document defines new address families (AFI: 16399, SAFI: 128, or 1) and associated signaling mechanisms to create and use MPLS forwarding contexts in a network. Some example use cases are also described. |
| | Distributed Remote Attestation |
| |
|
In the RATS architecture, remote attestation typically involves multiple roles: verifier, attester, endorser, reference value provider, and relying party. However, in complex networks, the large number of entities in each role can significantly increase the cost of communication and computational resources. This document proposes a simplified remote attestation method based on distributed ledger(DL) technology, which aims to reduce the overhead for participants in multi-party networks. |
| | Yang Data Model for EVPN multicast |
| |
|
This document describes a YANG data model for EVPN multicast services. The model is agnostic of the underlay as well as RFC 9251. This document mainly focuses on EVPN instance framework. |
| | Multipath Extension for QUIC |
| |
| | draft-ietf-quic-multipath-16.txt |
| | Date: |
21/08/2025 |
| | Authors: |
Yanmei Liu, Yunfei Ma, Quentin De Coninck, Olivier Bonaventure, Christian Huitema, Mirja Kuehlewind |
| | Working Group: |
QUIC (quic) |
|
This document specifies a multipath extension for the QUIC protocol to enable the simultaneous usage of multiple paths for a single connection. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the QUIC Working Group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/quic/. Source for this draft and an issue tracker can be found at https://github.com/quicwg/multipath. |
| | Segment Routing IPv6 Security Considerations |
| |
| | draft-ietf-spring-srv6-security-05.txt |
| | Date: |
21/08/2025 |
| | Authors: |
Nick Buraglio, Tal Mizrahi, tongtian124, Luis Contreras, Fernando Gont |
| | Working Group: |
Source Packet Routing in Networking (spring) |
|
SRv6 is a traffic engineering, encapsulation and steering mechanism utilizing IPv6 addresses to identify segments in a pre-defined policy. This document discusses security considerations in SRv6 networks, including the potential threats and the possible mitigation methods. The document does not define any new security protocols or extensions to existing protocols. |
| |
|
| |
| | IPv6 Neighbor Discovery Prefix Registration |
| |
|
This document updates IPv6 Neighbor Discovery (RFC 4861) and IPv6 Subnet Neighbor Discovery (RFC 8505, RFC 8928) to enable a node that owns or is directly connected to a prefix to register that prefix to neighbor routers. The registration indicates that the registered prefix can be reached via the advertising node without a loop. The unicast prefix registration allows the node to request neighbor router(s) to redistribute the prefix in another routing domain regardless of the routing protocol used in that domain. This document updates Routing Protocol for Low-Power and Lossy Networks (RPL) (RFC 6550, RFC 9010) to enable a 6LoWPAN Router (6LR) to inject the registered prefix in RPL. |
| | Protocol-Specific Profiles for JSContact |
| |
|
This document defines JSContact profiles, an IANA registry for named subsets of JSContact elements. It aims to facilitate using JSContact in context of contact data exchange protocols or other use cases, in which supporting all of JSContact semantics might be inappropriate. |
| | JSContact Version 2.0: A JSON Representation of Contact Data |
| |
|
This document defines version "2.0" of JSContact. It defines the "uid" property of a Card object to be optional, rather than mandatory as defined in previous version "1.0". Other than changing the "uid" property, all other definitions of JSContact version "1.0" remain as defined in RFC 9553. This document updates RFC 9555 by redefining how to convert the now optional "uid" property from and to vCard. |
| | Security Considerations for Optimistic Protocol Transitions in HTTP/1.1 |
| |
|
In HTTP/1.1, the client can request a change to a new protocol on the existing connection. This document discusses the security considerations that apply to data sent by the client before this request is confirmed, and updates RFC 9112 and RFC 9298 to avoid related security issues. |
| | Link-Local Next Hop Capability for BGP |
| |
|
To support IPv6 reachability, BGP [RFC4271] relies on the Multiprotocol Extensions as defined in [RFC4760]. [RFC2545] defines the structure of IPv6 next hops. These IPv6 next hops may contain a Global IPv6 address, and optionally can contain an IPv6 Link-Local address when the BGP peer is directly attached and shares a common subnet with the IPv6 Global address. This document updates [RFC2545] to clarify the encoding of the BGP next hop when the advertising system is directly attached and only an IPv6 Link-Local address is available. A new BGP Capbility [RFC5492] is defined to signal support for this updated encoding. This clarification applies specifically to IPv6 Link-Local addresses and does not pertain to IPv4 Link-Local addresses as defined in [RFC3927]. |
| | ICMP Extension Structure Length Field |
| |
|
The ICMP Extension Structure (RFC4884) does not have a length field. Therefore, unless the length of the Extension Structure can be inferred from other data in the ICMP message, the Extension Structure must be the last item in the ICMP message. This document updates RFC 4884 to define a length field for the ICMP Extension Structure. When length information is provided, receivers can use it to parse ICMP messages. Specifically, receivers can use length information to determine the offset at which the item after the ICMP Extension Structure begins. |
| | HTTP Live Streaming 2nd Edition |
| |
|
This document obsoletes RFC 8216. It describes a protocol for transferring unbounded streams of multimedia data. It specifies the data format of the files and the actions to be taken by the server (sender) and the clients (receivers) of the streams. It describes version 13 of this protocol. |
| | The IPv6 Segment Routing (SRv6) Domain Name System (DNS) Resource Record |
| |
|
A Domain Name System (DNS) Resource Record (RR) Type is specified for storing IPv6 Segment Routing (SRv6) Information in the DNS. |
| | Intra-domain Source Address Validation (SAVNET) OAM |
| |
|
This document is a framework for how Source Address Validation (SAVNET) can be applied to operations and maintenance procedures for Intra-domain network. The document is structured to outline how Operations and Management (OAM) functionality can be used to assist in fault, configuration, accounting, performance, and security management, commonly known by the acronym FCAPS. |
| | Signaling SAVNET Capability Using IGP |
| |
|
Existing intra-domain SAV solutions (e.g., BCP38 [RFC2827] and BCP84 [RFC3704]) have problems of high operational overhead or inaccurate validation (see [I-D.ietf-savnet-intra-domain-problem-statement]). To address these problems and guide the design of new intra-domain SAV solutions,[I-D.ietf-savnet-intra-domain-architecture] proposes the architecture of intra-domain SAVNET and introduces the use of SAV-specific information in intra-domain networks. This document defines a mechanism to signal the SAVNET capablity and the source prefix using IGP and BGP-LS. |
| | Open Cloud Mesh |
| |
|
Open Cloud Mesh (OCM) is a server federation protocol that is used to notify a Receiving Party that they have been granted access to some Resource. It has similarities with authorization flows such as OAuth, as well as with social internet protocols such as ActivityPub and email. A core use case of OCM is when a user (e.g., Alice on System A) wishes to share a resource (e.g., a file) with another user (e.g., Bob on System B) without transferring the resource itself or requiring Bob to log in to System A. While this scenario is illustrative, OCM is designed to support a broader range of interactions, including but not limited to file transfers. Open Cloud Mesh handles interactions only up to the point where the Receiving Party is informed of their access to the Resource. Actual Resource access is subsequently managed by other protocols, such as WebDAV. |
| | Content Steering |
| |
|
This document describes a mechanism for servers to communicate their preferences to clients about utilizing alternate servers for streaming content. These alternate servers are typically distinct Content Delivery Networks or any other servers that offer similar distribution services. The mechanism described in this document is designed to be universally applicable and independent of any specific Content Delivery Protocol. |
| | Bitwise IP Filters for BGP FlowSpec |
| |
|
This draft introduces the bitwise matching filters for source or destination IPv4/IPv6 address fields. These filters enhance the functionalities of the BGP Flow Specification framework and aid scenarios involving symmetric traffic load balancing. |
| | ICMPv6 Prefix Redirect Messages |
| |
|
The existing IPv6 ICMPv6 Redirect Message informs a host of a better next hop for a single destination IPv6 address. There are use cases for informing a host of a better next hop for a prefix or range of IPv6 addresses that includes or covers the single destination address that triggered the ICMPv6 redirect message. This memo specifies an ICMPv6 Prefix Redirect Message for this purpose. |
| | BGP-4 Path Attribute Filtering Capability |
| |
|
Path Attributes in the BGP-4 protocol (RFC 4271) carry data associated with BGP routes. Many of the Path Attributes carried in BGP are intended for limited scope deployment. However, the extension mechanism defined by BGP that carries these attributes often carries them farther than necessary, sometimes with unfortunate results. This document defines a mechanism using BGP Capabilities (RFC 5492) that permits eBGP speakers to determine what Path Attributes should be permitted to cross external BGP routing boundaries. |
| | Identification,Sequence Number and Payload Option for IPv6 NDP and IPv4 ARP Ping |
| |
|
IPv6 Neighbor Discovery Protocol (NDP) and IPv4 Address Resolution Protocol (ARP) can be used to perform "ping" tests that overcome nodes' refusal to respond to IPv6 and IPv4 ICMP Echo Requests. A drawback is that NDP and ARP do not carry an Identification, Sequence Number and Payload for these ping tests. This memo proposes an IPv6 Neighbor Discovery Option that adds these fields to the NDP and ARP packets used to perform ping tests. |
| | LISP-Based Network for AI Infrastructure |
| |
|
The LISP control plane provides the mechanisms to support both Scale- Up and Scale-Out backend networks within AI infrastructure. This document outlines how LISP can enable a unified control plane architecture that accommodates both scaling technologies, offering flexibility in deployment. This approach allows AI/ML applications—whether focused on training or inference—to operate workloads efficiently with resiliency on a converged infrastructure, supporting diverse deployment scenarios using the same underlying network fabric. |
| | Proquints: Readable,Spellable,and Pronounceable Identifiers |
| |
|
This document specifies "proquints" (PRO-nounceable QUINT-uplets), a human-friendly encoding that maps binary data to pronounceable identifiers using fixed consonant-vowel patterns. The concept was originally described by Daniel Shawcross Wilkerson in 2009. This document formalizes the format for archival and reference. |
| | A YANG Data Model for ARP |
| |
|
This document defines a YANG data model for the management of the Address Resolution Protocol (ARP). It extends the basic ARP functionality contained in the ietf-ip YANG data model, defined in RFC 8344, to provide management of optional ARP features and statistics. |
| | Contextual Authentication Presentation Protocol (CAPP) |
| |
| | draft-shim-capp-00.txt |
| | Date: |
20/08/2025 |
| | Authors: |
Ace Shim, Lukas.J Han |
| | Working Group: |
Individual Submissions (none) |
|
CAPP is a decentralized presentation protocol for Verifiable Credentials that enables frictionless, context-triggered, pre- consented credential sharing without requiring interactive challenge- response cycles. It is optimized for physical access, transit, event entry, and other passive authentication scenarios. |
| | PCEP Extensions to support BFD parameters |
| |
|
This document proposes extension to PCEP to configure LSP parameters. Some of LSP parameters are needed to configure S-BFD for candidate paths. Each candidate path is identified in PCEP by its uniquely assigned PLSP-ID. The mechanism proposed in this document is applicable to to all path setup types. This extension can work with ifferent PCEP Path Setup Types but especially suitable for Segment Routing (SR-MPLS, SRv6).. |
| |
|
| |
| | Internet Control Message Protocol (ICMPv6) Reflection |
| |
|
This document describes the ICMPv6 Reflection utility. The ICMPv6 Reflection utility is a diagnostic tool, similar to Ping and the ICMPv6 Probe utility. It is similar to Ping and Probe in that it relies on a stateless message exchange between a probing node and a probed node. The probing node sends a request to the probed node and the probed node responds to the request. The ICMPv6 Reflection utility differs from Ping and Probe because, in the ICMPv6 Reflection utility, the probing node requests a snapshot of the message that it sent, as it was when arrived at the probed node. The probed node returns the requested snapshot. The ICMPv6 Reflection utility is useful because it can allow the user to see how the network modified the request as it traveled from the probing node to the probed node. |
| | An Application Layer Interface for Non-IP device control (NIPC) |
| |
| | draft-ietf-asdf-nipc-12.txt |
| | Date: |
19/08/2025 |
| | Authors: |
Bart Brinckman, Rohit Mohan, Braeden Sanford |
| | Working Group: |
A Semantic Definition Format for Data and Interactions of Things (asdf) |
|
This memo specifies RESTful application layer interface for gateways providing operations against non-IP devices, as well as a CBOR-based publish-subscribe interface for streaming data. The described interfaces are extensible. |
| | Optimizing BFD Authentication |
| |
|
This document describes an experimental optimization to BFD Authentication. It provides procedure where BFD state transitions require strong authentication and permits the majority of BFD Control Packets to use a less computationally intensive authentication mechanism. This enables BFD to scale better when there is a desire to use strong authentication. |
| | LSR Extensions for BIER non-MPLS Encapsulation |
| |
|
Bit Index Explicit Replication (BIER) is an architecture that provides multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast related per-flow state. BIER can be supported in MPLS and non-MPLS networks. This document updates RFC8296 and specifies the required extensions to the IS-IS, OSPFv2 and OSPFv3 protocols for supporting BIER in non- MPLS networks using BIER non-MPLS encapsulation. |
| | DRIP Entity Tags in the Domain Name System |
| |
|
This document defines the Domain Name System (DNS) functionality of a Drone Remote Identification Protocol (DRIP) Identity Management Entity (DIME). It is built around DRIP Entity Tags (DETs) to standardize a hierarchical registry structure and associated processes to facilitate trustable and scalable registration and lookup of information related to Unmanned Aircraft Systems (UAS). The registry system supports issuance, discovery, and verification of DETs, enabling secure identification and association of UAS and their operators. It also defines the interactions between different classes of registries (root, organizational, and individual) and their respective roles in maintaining the integrity of the registration data. This architecture enables decentralized, federated operation while supporting privacy, traceability, and regulatory compliance requirements in the context of UAS Remote ID and other services. |
| | Adding Extensions to ICMP Errors for Originating Node Identification |
| |
|
RFC5837 describes a mechanism for Extending ICMP for Interface and Next-Hop Identification, which allows providing additional information in an ICMP error that helps identify interfaces participating in the path. This is especially useful in environments where a given interface may not have a unique IP address to respond to, e.g., a traceroute. This document introduces a similar ICMP extension for Node Identification. It allows providing a unique IP address and/or a textual name for the node, in the case where each node may not have a unique IP address (e.g., a deployment in which all interfaces have IPv6 addresses and all nexthops are IPv6 nexthops, even for IPv4 routes). |
| | Signal-Free Locator/ID Separation Protocol (LISP) Multicast |
| |
|
This document describes the design for inter-domain multicast overlays using the Locator/ID Separation Protocol (LISP). The document specifies how LISP multicast overlays operate over a unicast underlays. When multicast sources and receivers are active at Locator/ID Separation Protocol (LISP) sites, the core network is required to use native multicast so packets can be delivered from sources to group members. When multicast is not available to connect the multicast sites together, a signal-free mechanism can be used to allow traffic to flow between sites. The mechanism within here uses unicast replication and encapsulation over the core network for the data plane and uses the LISP mapping database system so encapsulators at the source LISP multicast site can find decapsulators at the receiver LISP multicast sites. |
| | Network File System (NFS) Version 4 Minor Version 1 Protocol |
| |
|
This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC 7530) and protocol extensions made as part of Minor Version 1. The later minor version has no dependencies on NFS version 4 minor version 0, and was, until recently, documented as a completely separate protocol. This document is part of a set of documents which collectively obsolete RFCs 8881 and 8434. In addition to many corrections and clarifications, it will rely on NFSv4-wide documents to substantially revise the treatment of protocol extension, internationalization, and security, superseding the descriptions of those aspects of the protocol appearing in RFCs 5661 and 8881. |
| | Analysis for Multiple Data Plane Solutions of Computing-Aware Traffic Steering |
| |
| | draft-fu-cats-muti-dp-solution-03.txt |
| | Date: |
19/08/2025 |
| | Authors: |
FUHUAKAI, Bo Liu, Zhenqiang Li, Daniel Huang, Dongyu Yuan, Liwei Ma, Wei Duan |
| | Working Group: |
Individual Submissions (none) |
|
This document proposes a data plane framework for Computing-Aware Traffic Steering (CATS), detailing multiple optional solutions, comparing their key characteristics and distinctions, and analyzing applicable scenarios to provide a reference for implementation. |
| | Flow-Level Load Balancing of Computing-Aware Traffic Steering (CATS) |
| |
| | draft-fu-cats-flow-lb-02.txt |
| | Date: |
19/08/2025 |
| | Authors: |
FUHUAKAI, Daniel Huang, Liwei Ma, Wei Duan, Bin Tan |
| | Working Group: |
Individual Submissions (none) |
|
This document proposes a flow-level load balancing solution for CATS, and is designed to effectively manage CS-ID traffic by addressing issues like frequent control plane operations and uneven use of computing resources. The approach entails concurrently identifying multiple next-hop choices, factoring in both network pathways and service instances. Traffic is then distributed among these service instances using flow-based load balancing, which relies on the five- tuple characteristics of packets. |
| | SSH Agent Protocol |
| |
|
This document describes a key agent protocol for use in the Secure Shell (SSH) protocol. Note This note is to be removed before publishing as an RFC. In the IANA considerations section, please replace "thisRFC" with "RFC" and the assigned number, when known. |
| | TLS/DTLS 1.3 Profiles for the Internet of Things |
| |
|
RFC 7925 offers guidance to developers on using TLS/DTLS 1.2 for Internet of Things (IoT) devices with resource constraints. This document is a companion to RFC 7925, defining TLS/DTLS 1.3 profiles for IoT devices. Additionally, it updates RFC 7925 with respect to the X.509 certificate profile and ciphersuite requirements. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/thomas-fossati/draft-tls13-iot. |
| |
|
| |
| | Semantic Definition Format (SDF) modeling for Digital Twin |
| |
| | draft-ietf-asdf-digital-twin-00.txt |
| | Date: |
18/08/2025 |
| | Authors: |
Hyunjeong Lee, Jungha Hong |
| | Working Group: |
A Semantic Definition Format for Data and Interactions of Things (asdf) |
|
This memo specifies SDF modeling for a digital twin, i.e. a digital twin system, and its Things. An SDF is a format that is used to create and maintain data and interaction, and to represent the various kinds of data that is exchanged for these interactions. The SDF format can be used to model the characteristics, behavior and interactions of Things, i.e. physical objects, in a digital twin that contain Things as components. |
| | CBOR Encoded X.509 Certificates (C509 Certificates) |
| |
|
This document specifies a CBOR encoding of X.509 certificates. The resulting certificates are called C509 Certificates. The CBOR encoding supports a large subset of RFC 5280 and all certificates compatible with the RFC 7925, IEEE 802.1AR (DevID), CNSA 1.0, RPKI, GSMA eUICC, and CA/Browser Forum Baseline Requirements profiles. C509 is deployed in different settings including, in-vehicle and vehicle-to-cloud communication, Unmanned Aircraft Systems (UAS), and Global Navigation Satellite System (GNSS). When used to re-encode DER encoded X.509 certificates, the CBOR encoding can in many cases reduce the size of RFC 7925 profiled certificates by over 50% while also significantly reducing memory and code size compared to ASN.1. The CBOR encoded structure can alternatively be signed directly ("natively signed"), which does not require re-encoding for the signature to be verified. The TLSA selectors registry defined in RFC 6698 is extended to include C509 certificates. The document also specifies C509 Certificate Requests, C509 COSE headers, a C509 TLS certificate type, and a C509 file format. |
| | Some Key Terms for Network Fault and Problem Management |
| |
| | draft-ietf-nmop-terminology-23.txt |
| | Date: |
18/08/2025 |
| | Authors: |
Nigel Davis, Adrian Farrel, Thomas Graf, Qin WU, Chaode Yu |
| | Working Group: |
Network Management Operations (nmop) |
|
This document sets out some terms that are fundamental to a common understanding of network fault and problem management within the IETF. The purpose of this document is to bring clarity to discussions and other work related to network fault and problem management, in particular to YANG data models and management protocols that report, make visible, or manage network faults and problems. |
| | Supporting IOAM in IPv6 |
| |
|
IOAM pre-allocated trace option data fields can be encapsulated in IPv6 HbH options header as described in RFC9486. However, due to the potential large size of the trace data and the HbH extension header location in the IPv6 packets, the scheme creates practical challenges for implementation, especially when other extension headers, such as a routing header, also exist and require on-path processing. We propose two alternative approaches to address this challenge in addition to IOAM DEX: separating the IOAM incremental trace data from the IOAM instruction header, or applying the segment IOAM trace data export scheme, based on the network scenario and application requirements. We discuss the pros and cons of each approach in this document. |
| | The Architecture of Network-Aware Domain Name System (DNS) |
| |
|
This document describes a framework which extends the Domain Name System (DNS) to provide network awareness to applications. The framework enables DNS system responses that are dependent on communication service requirements such as QoS or path without changes in the format of DNS protocol messages or application program interfaces (APIs). The different enhancement methods and use cases are discussed. |
| | Using ShangMi in the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
This document defines a set of cryptographic transforms for use in the Internet Key Exchange Protocol version 2 (IKEv2). The transforms are based on ISO and Chinese cryptographic standard algorithms (called "ShangMi" or “SM” algorithms). The use of these algorithms with IKEv2 is not endorsed by the IETF. The SM algorithms is ISO standardization and are mandatory for some scenario in China, so this document provides a description of how to use the SM algorithms with IKEv2 and specifies a set of cryptographic transforms so that implementers can produce interworking implementations. |
| | ICMP extension to include underlay information |
| |
|
Network operators operating overlay networks require the ability to identify hops in an underlay network when traceroute in the overlay. This document defines an ICMP Error extension message to carry the underlay error information to the overlay network endpoint. |
| | OAuth 2.0 App2App Browser-less Flow |
| |
|
This document describes a protocol allowing a _Client App_ to obtain an OAuth grant from an _Authorization Server's Native App_ using the [App2App] pattern, providing *native* app navigation user-experience (no web browser used), despite both apps belonging to different trust domains. |
| | SRv6 for Deterministic Path Placement in AI Backends |
| |
| | draft-filsfils-srv6ops-srv6-ai-backend-02.txt |
| | Date: |
18/08/2025 |
| | Authors: |
Clarence Filsfils, Chris Martin, Kiran Pillai, Pablo Camarillo, Ahmed Abdelsalam, Jeff Tantsura, Keyur Patel |
| | Working Group: |
Individual Submissions (none) |
|
This document describes the use of SRv6 to enable deterministic path placement in AI backends, optimizing load balancing and congestion control for predictable GPU workloads. |
| | Anonymous Credit Tokens |
| |
|
This document specifies Anonymous Credit Tokens (ACT), a privacy- preserving authentication protocol that enables numerical credit systems without tracking individual clients. Based on keyed- verification anonymous credentials and privately verifiable BBS-style signatures, the protocol allows issuers to grant tokens containing credits that clients can later spend anonymously with that issuer. The protocol's key features include: (1) unlinkable transactions - the issuer cannot correlate credit issuance with spending, or link multiple spends by the same client, (2) partial spending - clients can spend a portion of their credits and receive anonymous change, and (3) double-spend prevention through cryptographic nullifiers that preserve privacy while ensuring each token is used only once. Anonymous Credit Tokens are designed for modern web services requiring rate limiting, usage-based billing, or resource allocation while respecting user privacy. Example applications include rate limiting and API credits. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. |
| | Protocol Mapping for SDF |
| |
|
This document defines protocol mapping extensions for the Semantic Definition Format (SDF) to enable mapping of protocol-agnostic SDF affordances to protocol-specific operations. The protocol mapping mechanism allows SDF models to specify how properties, actions, and events should be accessed using specific IP and non-IP protocols such as Bluetooth Low Energy, Zigbee or HTTP and CoAP. |
| | System for Cross-domain Identity Management: Agentic Identity Schema |
| |
|
The System for Cross-domain Identity Management (SCIM) specifications are designed to make identity management in cloud-based applications and services easier. This document provides a platform-neutral schema for representing AI agents' identities in JSON format, enabling them to be transferred in the SCIM protocol to the service. This establishes an agentic identity so that an agent can subsequently be authenticated and authorized to interact with the service. |
| | Multi-segment SD-WAN via Cloud DCs |
| |
|
This document describes a method for seamlessly interconnecting geographically separated SD-WAN segments via a Cloud Backbone without requiring Cloud Gateways (GWs) to decrypt and re-encrypt traffic. By encapsulating IPsec- encrypted payloads within GENEVE headers (RFC 8926), the approach enables Cloud GWs to forward encrypted traffic directly between distant Customer Premises Equipment (CPEs). This reduces processing overhead, improves scalability, and preserves the confidentiality of enterprise data while ensuring secure and efficient multi-segment SD-WAN. connectivity. |
| | A Profile for Autonomous System Provider Authorization |
| |
| | draft-ietf-sidrops-aspa-profile-20.txt |
| | Date: |
18/08/2025 |
| | Authors: |
Alexander Azimov, Eugene Uskov, Randy Bush, Job Snijders, Russ Housley, Ben Maddison |
| | Working Group: |
SIDR Operations (sidrops) |
|
This document defines a Cryptographic Message Syntax (CMS) protected content type for Autonomous System Provider Authorization (ASPA) objects for use with the Resource Public Key Infrastructure (RPKI). An ASPA is a digitally signed object through which the issuer (the holder of an Autonomous System identifier), can authorize one or more other Autonomous Systems (ASes) as its upstream providers. When validated, an ASPA's eContent can be used for detection and mitigation of route leaks. |
| | Resource Public Key Infrastructure (RPKI) Manifest Number Handling |
| |
|
The Resource Public Key Infrastructure (RPKI) makes use of signed objects called manifests, each of which includes a "manifest number". This document updates RFC9286 by specifying issuer and RP behaviour when a manifest number reaches the largest possible value, a situation not considered in RFC9286. |
| | WebRTC-HTTP Egress Protocol (WHEP) |
| |
| | draft-ietf-wish-whep-03.txt |
| | Date: |
18/08/2025 |
| | Authors: |
Sergio Murillo, Cheng Chen, Dan Jenkins |
| | Working Group: |
WebRTC Ingest Signaling over HTTPS (wish) |
|
This document describes a simple HTTP-based protocol that will allow WebRTC-based viewers to watch content from streaming services and/or Content Delivery Networks (CDNs) or WebRTC Transmission Network (WTNs). |
| |
|
| |
| | ESP Header Compression with Diet-ESP |
| |
| | draft-ietf-ipsecme-diet-esp-09.txt |
| | Date: |
17/08/2025 |
| | Authors: |
Daniel Migault, Maryam Hatami, Sandra Cespedes, J. Atwood, Daiying Liu, Tobias Guggemos, Carsten Bormann, David Schinazi |
| | Working Group: |
IP Security Maintenance and Extensions (ipsecme) |
|
This document specifies Diet-ESP, a compression mechanism for control information in IPsec/ESP communications. The compression uses Static Context Header Compression rules. |
| | Multicast Redundant Ingress Router Failover |
| |
|
This document analyzes the problem of failover between redundant ingress routers in multicast domains. It describes cold, warm, and hot standby modes, detailing their advantages, limitations, and deployment considerations to help operators select appropriate mechanisms. |
| | TLS 1.2 Update for Long-term Support (LTS) |
| |
|
This document specifies an update of TLS 1.2 for long-term support (LTS) on systems that can have multi-year or even decade-long update cycles, one that incoporates as far as possible what's already deployed for TLS 1.2 but with the security holes and bugs fixed. This document also recognises the fact that there is a huge amount of TLS use outside the web content-delivery environment with its resource-rich hardware and software that can be updated whenever required and provides a long-term stable, known-good version that can be deployed to systems that can't roll out ongoing changes on a continuous basis. |
| | A Pre-Authentication Mechanism for SSH |
| |
|
Devices running SSH are frequently exposed on the Internet, either because of operational considerations or through misconfiguration, making them vulnerable to the constant 3-degree background radiation of scanning and probing attacks that pervade the Internet. This document describes a simple pre-authentication mechanism that limits these attacks with minimal changes to SSH implementations and no changes to the SSH protocol itself. |
| | PKCS #15 Updates |
| |
|
This document describes updates to the PKCS #15 standard made since the original publication of the standard. |
| | Methods for IP Address Encryption and Obfuscation |
| |
|
This document specifies methods for encrypting and obfuscating IP addresses for privacy-preserving storage, logging, and analytics. These encrypted addresses enable data analysis while protecting user privacy from third parties without key access, addressing data minimization concerns raised in [RFC6973]. Three concrete instantiations are defined: ipcrypt-deterministic provides deterministic, format-preserving encryption, while ipcrypt- nd and ipcrypt-ndx introduce randomness to prevent correlation. All methods are reversible with the encryption key. |
| | Hierarchical Topology for Language Model Coordination |
| |
|
This document defines a YANG data model and reference architecture for a hierarchical topology of language models (LMs), where tiny, small, and large LMs cooperate to perform distributed inference, summarization, and decision-making. The model supports secure inter-node messaging, request escalation, token-based authorization, and decentralized validation using pluggable trust models. This architecture is designed for deployments where computational capabilities vary across nodes, such as edge-to-cloud environments or multi-tier AI systems. The goal is to provide a standards-based mechanism for orchestrating scalable, secure LM interactions across heterogeneous systems. |
| | OpenPGP Key Replacement |
| |
|
This document specifies a method in OpenPGP to suggest a replacement for an expired, revoked, or deprecated primary key. |
| | Support for Path MTU (PMTU) in the Path Computation Element (PCE) Communication Protocol (PCEP) |
| |
| | draft-ietf-pce-pcep-pmtu-08.txt |
| | Date: |
17/08/2025 |
| | Authors: |
Shuping Peng, Cheng Li, Liuyan Han, Luc-Fabrice Ndifor, Samuel Sidor |
| | Working Group: |
Path Computation Element (pce) |
|
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing (SR) can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). Since the SR does not require signaling, the path maximum transmission unit (MTU) information for the SR path is unavailable at the headend. This document specifies the extension to PCE Communication Protocol (PCEP) to carry path MTU as a new metric type in the PCEP messages for SR, but not limited to it. This document also updates RFC 5440 to allow metric bounds to be minimum as needed in the case of path MTU. |
| | Reverse Change-of-Authorization (CoA) in RADIUS/(D)TLS |
| |
|
This document defines a "reverse Change-of-Authorization (CoA)" path for RADIUS packets. A TLS connection is normally used to forward request packets from a client to a server and to send responses from the server to the client. This specification allows a server to send CoA request packets to the client in "reverse" down that connection, and for the client to send responses to the server. Without this capability, it is in general impossible for a server to send CoA packets to a Network Access Server (NAS) that is located behind a firewall or NAT. This reverse CoA functionality extends the available transport methods for CoA packets, but it does not change anything else about how CoA packets are handled. This document updates RFC8559. |
| | User Ports for Experiments |
| |
|
This document defines user ports for experiments using transport protocols. It describes the use of experiment identifiers to enable shared use of these user ports. It also updates RFC 4727 to recommend the use of these experimental identifiers for the system ports for experiments in the same manner. |
| |
|
| |
| | A YANG data model for Tree Engineering for Bit Index Explicit Replication (BIER-TE) |
| |
| | draft-ietf-bier-te-yang-09.txt |
| | Date: |
15/08/2025 |
| | Authors: |
Zheng Zhang, Cui(Linda) Wang, Ran Chen, fangwei hu, Mahesh Sivakumar, chenhuanan |
| | Working Group: |
Bit Indexed Explicit Replication (bier) |
|
This document defines a YANG data module for Tree Engineering for Bit Index Explicit Replication (BIER-TE) configuration and operation. |
| | Content Delivery Network Interconnection (CDNI) Control Interface / Triggers 2nd Edition |
| |
|
This document obsoletes RFC8007. The document describes the part of Content Delivery Network Interconnection (CDNI) Control interface that allows a CDN to trigger activity in an interconnected CDN that is configured to deliver content on its behalf. The upstream CDN MAY use this mechanism to request that the downstream CDN preposition, invalidate and/or purge metadata and/or content. The upstream CDN MAY monitor the status of activity that it has triggered in the downstream CDN. |
| | Extensible Delegation for DNS |
| |
| | draft-ietf-deleg-02.txt |
| | Date: |
15/08/2025 |
| | Authors: |
Tim April, Petr Spacek, Ralf Weber, tale |
| | Working Group: |
DNS Delegation (deleg) |
|
A delegation in the Domain Name System (DNS) is a mechanism that enables efficient and distributed management of the DNS namespace. It involves delegating authority over subdomains to specific DNS servers via NS records, allowing for a hierarchical structure and distributing the responsibility for maintaining DNS records. An NS record contains the hostname of the nameserver for the delegated namespace. Any facilities of that nameserver must be discovered through other mechanisms. This document proposes a new extensible DNS record type, DELEG, for delegation of the authority for a domain. Future documents then can use this mechanism to use additional information about the delegated namespace and the capabilities of authoritative nameservers for the delegated namespace. |
| | Internationalization for the NFSv4 Protocols |
| |
|
This document describes the handling of internationalization for all NFSv4 protocols, including NFSv4.0, NFSv4.1, NFSv4.2 and extensions thereof, and future minor versions. It updates RFC7530 and RFC8881. |
| | CDNI Delivery Metadata |
| |
|
This specification adds to the core set of configuration metadata defined in RFC8006, providing delivery metadata to define traffic types, request delegation behavior for downstream CDN (dCDN) node selection, and request routing modes of traffic delegation. |
| | Lightweight Authentication Methods for IP Header |
| |
|
This document specifies a lightweight method for authenticating encapsulation headers, such as GENEVE, SRH, and UDP options, used to steer encrypted IPsec traffic across a Cloud Backbone, ensuring forwarding integrity without Cloud GWs decrypting the payloads. |
| | NTS4PTP - Network Time Security for the Precision Time Protocol |
| |
|
This document specifies an automatic key management service for the integrated security mechanism (prong A) of IEEE Std 1588™-2019 (PTPv2.1) described there in Annex P. This key management follows the immediate security processing approach of prong A and extends the NTS Key Establishment protocol defined in IETF RFC 8915 for securing NTPv4. The resulting NTS for PTP (NTS4PTP) protocol provides a security solution for all PTP modes and operates completely independent of NTPv4. It also provides measures against known attack vectors targeting PTP. |
| | Protocol Independent Multicast - Sparse Mode (PIM-SM) Designated Router (DR) Improvement |
| |
|
Protocol Independent Multicast - Sparse Mode (PIM-SM) is a widely deployed multicast protocol. As deployment for the PIM protocol is growing day by day, a user expects lower packet loss and faster convergence regardless of the cause of the network failure. This document defines an extension to the existing protocol, which improves the PIM's stability with respect to packet loss and convergence time when the PIM Designated Router (DR) role changes. |
| | Attestation Results for Secure Interactions |
| |
| | draft-ietf-rats-ar4si-09.txt |
| | Date: |
15/08/2025 |
| | Authors: |
Eric Voit, Henk Birkholz, Thomas Hardjono, Thomas Fossati, Vincent Scarlata |
| | Working Group: |
Remote ATtestation ProcedureS (rats) |
|
This document defines reusable Attestation Result information elements. When these elements are offered to Relying Parties as Evidence, different aspects of Attester trustworthiness can be evaluated. Additionally, where the Relying Party is interfacing with a heterogeneous mix of Attesting Environment and Verifier types, consistent policies can be applied to subsequent information exchange between each Attester and the Relying Party. This document also defines two serialisations of the proposed information model, utilising CBOR and JSON. |
| | An Architecture for Trustworthy and Transparent Digital Supply Chains |
| |
| | draft-ietf-scitt-architecture-18.txt |
| | Date: |
15/08/2025 |
| | Authors: |
Henk Birkholz, Antoine Delignat-Lavaud, Cedric Fournet, Yogesh Deshpande, Steve Lasker |
| | Working Group: |
Supply Chain Integrity, Transparency, and Trust (scitt) |
|
Traceability in supply chains is a growing security concern. While verifiable data structures have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document proposes a scalable architecture for single-issuer signed statement transparency applicable to any supply chain. It ensures flexibility, interoperability between different transparency services, and compliance with various auditing procedures and regulatory requirements. |
| | Secure Shell (SSH) Key Exchange Method Using Hybrid Streamlined NTRU Prime sntrup761 and X25519 with SHA-512: sntrup761x25519-sha512 |
| |
|
This document describes a widely deployed hybrid key exchange method in the Secure Shell (SSH) protocol that is based on Streamlined NTRU Prime sntrup761 and X25519 with SHA-512. |
| |
|
| |
| | Semantic Definition Format (SDF) Extension for Non-Affordance Information |
| |
|
This document describes an extension to the Semantic Definition Format (SDF) for representing non-affordance information of Things, such as physical, contextual, and descriptive metadata. This extension introduces a new class, sdfNonAffordance, that enables comprehensive modeling of Things and improves semantic clarity. |
| | RTP Control Protocol (RTCP) Messages for Temporal-Spatial Resolution |
| |
|
This specification describes an RTCP feedback message format for the ISO/IEC International Standard 23001-11, known as Energy Efficient Media Consumption (Green metadata), developed by the ISO/IEC JTC 1/SC 29/ WG 3 MPEG System. The RTCP payload format specified in this specification enables receivers to provide feedback to the senders and thus allows for short-term adaptation and feedback-based energy efficient mechanisms to be implemented. The payload format has broad applicability in real-time video communication services. |
| | DHCPv4-over-DHCPv6 with Relay Agent Support |
| |
|
This document describes a mechanism for networks with legacy IPv4-only clients to use services provided by DHCPv4-over-DHCPv6 in a Relay Agent. RFC7341 specifies use of DHCPv4-over-DHCPv6 in the client only. This document specifies a RFC7341-based approach that allows a Relay Agent to implement the DHCP 4o6 encapsulation and decapsulation of DHCPv4 messages in DHCPv6 messages on behalf of a DHCPv4 client. |
| | IMAP Extensions Suggestions |
| |
|
This document presents a set of IMAP extensions, each of which is recommended as a priority for general-purpose IMAP client and server implementations. |
| | Paths Limit for Multiple Paths in BGP |
| |
|
This document specifies a BGP capability that complements the ADD- PATH Capability by indicating the maximum number of paths a BGP speaker can receive from a peer, optimizing the transmission of BGP routes by selectively relaying pertinent routes instead of the entire set. |
| | AI Boundary Declaration Protocol (AIBDP) |
| |
|
This document defines the AI Boundary Declaration Protocol (AIBDP), a declarative framework for expressing usage boundaries around web- hosted content in relation to AI systems. It builds on the mechanisms of RFC 2196 and RFC 9116, as well as on the HTTP semantics of RFC 9110 and the robots-style inclusion rules of RFC 7725, to provide machine-readable permissions and denials for indexing, training, mimicry, representation, derivative construction, analytical exploitation, and agentic access. AIBDP supports ethical infrastructure, agentic AI governance, and procedural clarity across the Internet. |
| |
|
| |
| | JSCalendar: Converting from and to iCalendar |
| |
|
This document defines how to convert calendaring information between the JSCalendar and iCalendar data formats. It considers every JSCalendar and iCalendar element registered at IANA at the time of publication. It defines conversion rules for all elements that are common to both formats, as well as how convert arbitrary or unknown JSCalendar and iCalendar elements. |
| | Applicability of Border Gateway Protocol - Link State (BGP-LS) with Multi-Topology (MT) for Segment Routing based Network Resource Partitions (NRPs) |
| |
|
When Segment Routing (SR) is used for building Network Resource Partitions (NRPs), each NRP can be allocated with a group of Segment Identifiers (SIDs) to identify the topology and resource attributes of network segments in the NRP. This document describes how BGP-Link State (BGP-LS) with Multi-Topology (MT) can be used to distribute the information of SR based NRPs to the network controller when each NRP is associated with a separate logical network topology identified by a Multi-Topology ID (MT-ID). |
| | IETF Community Moderation |
| |
|
The IETF community will treat people with kindness and grace, but not endless patience. This memo describes the moderation of disruptive participation across the IETF's various public contribution channels and discussion fora. It establishes guardrails for moderation and a moderator team. That team will develop a uniform set of guidelines and facilitate their consistent implementation with chairs and administrators. |
| | Carrying NRP related Information in MPLS Packets |
| |
|
A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP could be used as the underlay to support one or a group of enhanced VPN services. Multiple NRPs can be created by network operator to meet the diverse requirements of different enhanced VPN services. In packet forwarding, some fields in the data packet needs to be used as the NRP Selector to identify the NRP the packet belongs to, so that the NRP-specific processing can be executed on the packet. This document proposes a mechanism to carry the NRP Selector ID and related information in MPLS packets. The procedure for processing the NRP Selector ID and related information is also specified. |
| | SSH Certificate Format |
| |
|
This document presents a simple certificate format that may be used in the context of the Secure Shell (SSH) protocol for user and host authentication. |
| | MPLS On-Path Telemetry Network Action Flag for OAM |
| |
|
This document describes the postcard-based on-path telemetry with packet marking (PBT-M) using an MPLS Network Actions (MNA) flag to support OAM in MPLS networks. The scheme uses a single bit in the MNA header opcode dedicated for the flag-based actions. The document provides the solutions to address the requirements for applying PBT-M in MPLS networks. |
| | Guidelines for Characterizing "OAM" |
| |
|
As the IETF continues to produce and standardize different Operations, Administration, and Maintenance (OAM) protocols and technologies, various qualifiers and modifiers are prepended to the OAM abbreviation. While, at first glance, the most used appear to be well understood, the same qualifier may be interpreted differently in different contexts. A case in point is the qualifiers "in-band" and "out-of-band" which have their origins in the radio lexicon, and which have been extrapolated into other communication networks. This document considers some common qualifiers and modifiers that are prepended, within the context of packet networks, to the OAM abbreviation and lays out guidelines for their use in future IETF work. This document updates RFC 6291 by adding to the guidelines for the use of the term "OAM". It does not modify any other part of RFC 6291. |
| | Updates to Private Header (P-Header) Extension Usage in Session Initiation Protocol (SIP) Requests and Responses |
| |
| | draft-ietf-sipcore-rfc7976bis-04.txt |
| | Date: |
13/08/2025 |
| | Authors: |
Christer Holmberg, Nevenka Biondic, Gonzalo Salgueiro, Roland Jesske |
| | Working Group: |
Session Initiation Protocol Core (sipcore) |
|
The Third Generation Partnership Project (3GPP) has identified cases where different SIP private header extensions referred to as "P-" header fields, and defined in RFC 7315, need to be included in SIP requests and responses currently not allowed according to RFC 7315. This document updates RFC 7315, in order to allow inclusion of the affected "P-" header fields in such requests and responses. This Document obsoletes RFC 7976. The changes related to RFC7976 involve the inclusion of the P-Visited-Network-ID header field in SIP responses. This document also makes updates for RFC 7315 in order to fix misalignments that occurred when RFC 3455 was updated and subsequently obsoleted by the publication of RFC 7315. |
| |
|
| |
| | COSE Header parameter for RFC 3161 Time-Stamp Tokens |
| |
|
This document defines two CBOR Signing And Encrypted (COSE) header parameters for incorporating RFC 3161-based timestamping into COSE message structures (COSE_Sign and COSE_Sign1). This enables the use of established RFC 3161 timestamping infrastructure in COSE-based protocols. |
| | BGP Link Bandwidth Extended Community |
| |
| | draft-ietf-idr-link-bandwidth-15.txt |
| | Date: |
12/08/2025 |
| | Authors: |
Prodosh Mohapatra, Reshma Das, MOHANTY Satya, Serge Krier, Rafal Szarecki, Akshay Gattani |
| | Working Group: |
Inter-Domain Routing (idr) |
|
This document describes an application of BGP extended communities that allows a router to perform WECMP (Weighted Equal-Cost Multipath). |
| | VPN Prefix Outbound Route Filter (VPN Prefix ORF) for BGP-4 |
| |
|
This draft defines a new type of Outbound Route Filter (ORF), known as the VPN Prefix ORF. The VPN Prefix ORF mechanism is applicable when VPN routes from different VRFs are exchanged through a single shared BGP session. |
| | YANG Semantic Versioning |
| |
| | draft-ietf-netmod-yang-semver-23.txt |
| | Date: |
12/08/2025 |
| | Authors: |
Joe Clarke, Robert Wilton, Reshad Rahman, Balazs Lengyel, Jason Sterne, Benoit Claise |
| | Working Group: |
Network Modeling (netmod) |
|
This document specifies a YANG extension along with guidelines for applying an extended set of semantic versioning rules to revisions of YANG artifacts (e.g., modules and packages). Additionally, this document defines a YANG extension for controlling module imports based on these modified semantic versioning rules. This document updates RFCs 7950, 8407, and 8525. |
| | RATS Conceptual Messages Wrapper (CMW) |
| |
| | draft-ietf-rats-msg-wrap-17.txt |
| | Date: |
12/08/2025 |
| | Authors: |
Henk Birkholz, Ned Smith, Thomas Fossati, Hannes Tschofenig, Dionna Glaze |
| | Working Group: |
Remote ATtestation ProcedureS (rats) |
|
The Remote Attestation Procedures architecture (RFC 9334) defines several types of conceptual messages, such as Evidence, Attestation Results, Endorsements, and Reference Values. These messages can appear in different formats and be transported via various protocols. This document introduces the Conceptual Message Wrapper (CMW) that provides a common structure to encapsulate these messages. It defines a dedicated CBOR tag, corresponding JSON Web Token (JWT) and CBOR Web Token (CWT) claims, and an X.509 extension. This allows CMWs to be used in CBOR-based protocols, web APIs using JWTs and CWTs, and PKIX artifacts like X.509 certificates. Additionally, the draft defines a media type and a CoAP content format to transport CMWs over protocols like HTTP, MIME, and CoAP. The goal is to improve the interoperability and flexibility of remote attestation protocols. By introducing a shared message format like the CMW, we can consistently support different attestation message types, evolve message serialization formats without breaking compatibility, and avoid having to redefine how messages are handled in each protocol. |
| | Introducing Resource Awareness to SR Segments |
| |
|
This document describes a mechanism to allocate network resources to one or a set of Segment Routing Identifiers (SIDs). Such SIDs are referred to as resource-aware SIDs. The resource-aware SIDs retain their original forwarding semantics, with the additional semantics to identify the set of network resources available for the packet processing and forwarding action. The proposed mechanism is applicable to both segment routing with MPLS data plane (SR-MPLS) and segment routing with IPv6 data plane (SRv6). |
| | Convergence of Congestion Control from Retained State |
| |
| | draft-ietf-tsvwg-careful-resume-21.txt |
| | Date: |
12/08/2025 |
| | Authors: |
Nicolas Kuhn, Emile Stephan, Gorry Fairhurst, Raffaello Secchi, Christian Huitema |
| | Working Group: |
Transport and Services Working Group (tsvwg) |
|
This document specifies a cautious method for IETF transports that enables fast startup of congestion control for a wide range of connections, known as "Careful Resume". It reuses a set of computed congestion control parameters that are based on previously observed path characteristics between the same pair of transport endpoints. These parameters are saved, allowing them to be later used to modify the congestion control behaviour of a subsequent connection. It describes assumptions and defines requirements for how a sender utilises these parameters to provide opportunities for a connection to more rapidly get up to speed and rapidly utilise available capacity. It discusses how use of this method impacts the capacity at a shared network bottleneck and the safe response that is needed after any indication that the new rate is inappropriate. |
| |
|
| |
| | Prioritizing known-local IPv6 ULAs through address selection policy |
| |
|
This document updates the default address selection algorithm for Internet Protocol Version 6 (IPv6), originally specified in RFC 6724, based on accumulated operational experience. It introduces the concept of "known-local" Unique Local Address (ULA) prefixes within the fd00::/8 block and specifies that ULA-to-ULA communications using such prefixes should be preferred over both IPv4-to-IPv4 and GUA-to- GUA (Global Unicast Address) communications in local use scenarios. The document defines mechanisms for nodes to identify and incorporate known-local prefixes into their address selection policy tables. It introduces a requirement to implement Rule 5.5 of RFC 6724 and reduces the default precedence for 6to4 addresses. These updates enhance the supportability of typical deployment environments, including automatic and unmanaged configurations, and promote consistent IPv6-over-IPv4 precedence behavior for both ULA and GUA within local networks. The document acknowledges that certain atypical deployment models may require explicit configuration to achieve intended operational outcomes. |
| | ACME End User Client and Code Signing Certificates |
| |
|
Automated Certificate Management Environment (ACME) core protocol addresses the use case of web server certificates for TLS. This document extends the ACME protocol to add 3 challenge types that may support service account authentication credentials, micro-service accounts credentials, device client, code signing, document signing certificates and keys. |
| | RTP Payload Format for Visual Volumetric Video-based Coding (V3C) |
| |
|
A visual volumetric video-based coding (V3C) [ISO.IEC.23090-5] bitstream is composed of V3C units that contain V3C atlas sub- bitstreams, V3C video sub-bitstreams, and a V3C parameter set. This memo describes an RTP payload format for V3C atlas sub-bitstreams. The RTP payload format for V3C video sub-bitstreams is defined by relevant Internet Standards for the applicable video codec. The V3C RTP payload format allows for packetization of one or more V3C atlas Network Abstraction Layer (NAL) units in an RTP packet payload as well as fragmentation of a V3C atlas NAL unit into multiple RTP packets. The memo also describes the mechanisms for grouping RTP streams of V3C component sub-bitstreams, providing a complete solution for streaming V3C encoded content. |
| | ALPN ID Specification for CoAP over DTLS |
| |
| | draft-ietf-core-coap-dtls-alpn-05.txt |
| | Date: |
11/08/2025 |
| | Authors: |
Martine Lenders, Christian Amsuess, Thomas Schmidt, Matthias Waehlisch |
| | Working Group: |
Constrained RESTful Environments (core) |
|
This document specifies an Application-Layer Protocol Negotiation (ALPN) ID for transport-layer-secured Constrained Application Protocol (CoAP) services. |
| | DNS IPv6 Transport Operational Guidelines |
| |
|
This memo provides guidelines and documents Best Current Practice for operating authoritative DNS servers as well as recursive and stub DNS resolvers, given that queries and responses are carried in a mixed environment of IPv4 and IPv6 networks. This document expands on RFC 3901 by recommending that authoritative DNS servers as well as recursive DNS resolvers support both IPv4 and IPv6. It furthermore provides guidance for how recursive DNS resolver should select upstream DNS servers, if synthesized and non-synthesized IPv6 addresses are available. This document obsoletes RFC3901. (if approved) |
| | Advanced Professional Video |
| |
| | draft-lim-apv-06.txt |
| | Date: |
11/08/2025 |
| | Authors: |
Youngkwon Lim, Minwoo Park, Madhukar Budagavi, Rajan Joshi, Kwang Choi |
| | Working Group: |
Individual Submissions (none) |
|
This document describes bitstream format of Advanced Professional Video (APV) and decoding process of it. APV is a professional video codec providing visually lossless compression mainly for recording and post production. APV is designed and developed to be open public standard with no licensing and royalty is required for use. |
| | DNS to Web3 Wallet Mapping |
| |
|
This document proposes an implementation standard for mapping wallets to domain names using the new WALLET RRType, allowing for TXT record fallback while the WALLET RRType propagates through DNS providers. The goal is to provide a secure and scalable and unbiased way to associate wallets with domain names, enabling seamless lookup as well as suggesting required authentication mechanism. The proposal relies on DNSSEC or security successors to ensure trust and security. |
| | Verifiable STI Persona (VESPER) Use Cases and Requirements |
| |
|
This document discusses a set of use cases and requirements for an extension to Secure Telephone Identity Revisited (STIR) called Verifiable STI PERsona (VESPER). VESPER fundamentally enhances STIR by establishing an authoritative and cryptographically verifiable Right-to-Use (RTU) relationship between telephone numbers and their assigned entities, business organizations or individuals, through digital signatures that bind an entity to a set of asserted claims, delegate certificates that govern the assertion of those claims to a responsible party, and Authority Tokens that prove the validation of those claims by authoritative parties. This cryptographic binding ensures explicit non-repudiation, removing ambiguity around who is accountable for calls or messages originating from specific telephone numbers, significantly deterring spoofing and fraud. |
| | SSH Support of ML-DSA |
| |
|
This document describes the use of ML-DSA digital signatures in the Secure Shell (SSH) protocol. |
| | CBOR : : Core - CBOR Cross Platform Profile |
| |
|
This document defines CBOR::Core, a platform profile for CBOR (RFC 8949) intended to serve as a viable replacement for JSON in computationally advanced systems like Internet browsers, mobile phones, and Web servers. To foster interoperability, deterministic encoding is mandated. Furthermore, the document outlines how deterministic encoding combined with enhanced CBOR tools, enable cryptographic methods like signing and hashing, to optionally use "raw" (non-wrapped) CBOR data as input. This document mainly targets CBOR tool developers. |
| | A YANG Data Model for requesting path computation |
| |
|
There are scenarios, typically in a hierarchical Software-Defined Networking (SDN) context, where the topology information provided by a Traffic Engineering (TE) network provider may be insufficient for its client to perform multi-domain path computation. In these cases the client would need to request the TE network provider to compute some intra-domain paths to be used by the client to choose the optimal multi-domain paths. This document provides a mechanism to request path computation by augmenting the Remote Procedure Calls (RPCs) defined in RFC YYYY. [RFC EDITOR NOTE: Please replace RFC YYYY with the RFC number of draft-ietf-teas-yang-te once it has been published. Moreover, this document describes some use cases where the path computation request, via YANG-based protocols (e.g., NETCONF or RESTCONF), can be needed. |
| |
|
| |
| | The AEGIS Family of Authenticated Encryption Algorithms |
| |
|
This document describes the AEGIS-128L, AEGIS-256, AEGIS-128X, and AEGIS-256X AES-based authenticated encryption algorithms designed for high-performance applications. The document is a product of the Crypto Forum Research Group (CFRG). It is not an IETF product and is not a standard. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/cfrg/draft-irtf-cfrg-aegis-aead. |
| | Applicability Statement for IETF Core Email Protocols |
| |
| | draft-ietf-emailcore-as-21.txt |
| | Date: |
10/08/2025 |
| | Authors: |
John Klensin, Kenneth Murchison |
| | Working Group: |
Revision of core Email specifications (emailcore) |
|
Electronic mail is one of the oldest Internet applications that is still in very active use. While the basic protocols and formats for mail transport and message formats have evolved slowly over the years, events and thinking in more recent years have supplemented those core protocols with additional features and suggestions for their use. This Applicability Statement describes the relationship among many of those protocols and provides guidance and makes recommendations for the use of features of the core protocols. |
| | HTTP Link Hints |
| |
|
This memo specifies "HTTP Link Hints", a mechanism for annotating Web links to HTTP(S) resources with information that otherwise might be discovered by interacting with them. |
| | Updates to Anycast Property advertisement for OSPFv2 |
| |
|
An IPv4 prefix may be configured as anycast and as such the same value can be advertised by multiple routers. It is useful for other routers to know that the advertisement is for an anycast identifier. Each OSPF prefix is advertised along with an 8-bit field of capabilities, by using the flag flield in the OSPFv2 Extended Prefix TLV, but the definition of anycast flag to identify the IPv4 prefix as anycast has not yet been defined. This document defines a new flag in the OSPFv2 Extended Prefix TLV Flags to advertise the anycast property. |
| | OAuth Profile for Open Public Clients |
| |
|
This document specifies a profile of the OAuth authorization protocol to allow for interoperability between native clients and servers using open protocols, such as JMAP, IMAP, SMTP, POP, CalDAV, and CardDAV. |
| | dCBOR: A Deterministic CBOR Application Profile |
| |
|
The purpose of determinism is to ensure that semantically equivalent data items are encoded into identical byte streams. CBOR (RFC 8949) defines "Deterministically Encoded CBOR" in its Section 4.2, but leaves some important choices up to the application developer. The CBOR Common Deterministic Encoding (CDE) Internet Draft builds on this by specifying a baseline for application profiles that wish to implement deterministic encoding with CBOR. The present document provides an application profile "dCBOR" that can be used to help achieve interoperable deterministic encoding based on CDE for a variety of applications wishing an even narrower and clearly defined set of choices. |
| | Automated Certificate Management Environment (ACME) Challenge for Persistent DNS TXT Record Validation |
| |
|
This document specifies "dns-persist-01", a new validation method for the Automated Certificate Management Environment (ACME) protocol. This method allows a Certification Authority (CA) to verify control over a domain by confirming the presence of a persistent DNS TXT record containing CA and account identification information. This method is particularly suited for environments where traditional challenge methods are impractical, such as IoT deployments, multi- tenant platforms, and scenarios requiring batch certificate operations. The validation method is designed with a strong focus on security and robustness, incorporating widely adopted industry best practices for persistent domain control validation. This design aims to make it suitable for Certification Authorities operating under various policy environments, including those that align with the CA/ Browser Forum Baseline Requirements. |
| |
|
| |
| | Automatic Peering for SIP Trunks |
| |
|
This document specifies a framework that enables enterprise telephony Session Initiation Protocol (SIP) networks to solicit and obtain a capability set document from a SIP service provider. The capability set document encodes a set of characteristics that enable easy peering between enterprise and service provider SIP networks. |
| | Registration of further IMAP/JMAP keywords and mailbox name attributes |
| |
|
This document defines a number of keywords and mailbox name attributes that have been in use across different server and client implementations. It defines the intended use of these keywords and mailbox name attributes. This document registers all of these with IANA to avoid name collisions. |
| | IMAP UIDBATCHES Extension |
| |
|
The UIDBATCHES extension of the Internet Message Access Protocol (IMAP) allows clients to retrieve UID ranges that partition a mailbox's messages into equally sized batches. This enables clients to perform operations such as FETCH, SEARCH, and STORE on specific message batches, providing better control over resource usage and response sizes. The extension is particularly useful with the UIDONLY mode where sequence numbers are unavailable. |
| | HGCP: A Voluntary Signing Framework for Human Expression in the Age of AI |
| |
|
In an era where AI-generated content has become indistinguishable from human writing, the Human-Generated Content Protocol (HGCP) proposes a voluntary signing framework that enables human authors to publicly acknowledge their expressions. Rather than detecting or classifying content origin, HGCP allows individuals to declare, in a structured and verifiable format, that they take responsibility for a specific piece of content. The protocol is platform-neutral, identity-flexible, and suitable for both real-name and pseudonymous use. It does not evaluate accuracy, originality, or quality; it simply enables people to say: “This is mine, and I stand by it.” By providing a lightweight, human-first declaration format, HGCP aims to preserve the visibility of human agency within an increasingly synthetic information ecosystem. |
| |
|
| |
| | Interactive Sigma Proofs |
| |
|
This document describes interactive sigma protocols, a class of secure, general-purpose zero-knowledge proofs of knowledge consisting of three moves: commitment, challenge, and response. Concretely, the protocol allows one to prove knowledge of a secret witness without revealing any information about it. |
| | Fiat-Shamir Transformation |
| |
|
This document describes how to construct a non-interactive proof via the Fiat–Shamir transformation, using a generic procedure that compiles an interactive proof into a non-interactive one by relying on a stateful hash object that provides a duplex sponge interface. The duplex sponge interface requires two methods: absorb and squeeze, which respectively read and write elements of a specified base type. The absorb operation incrementally updates the sponge's internal hash state, while the squeeze operation produces variable-length, unpredictable outputs. This interface can be instantiated with various hash functions based on permutation or compression functions. This specification also defines codecs to securely map elements from the prover into the duplex sponge domain, and from the duplex sponge domain into verifier messages. |
| | OpenPGP HTTP Keyserver Protocol |
| |
|
This document specifies a series of conventions to implement an OpenPGP keyserver using the Hypertext Transfer Protocol (HTTP). As this document is a codification and extension of a protocol that is already in wide use, strict attention is paid to backward compatibility with these existing implementations. |
| | SRv6 Deployment Options |
| |
|
When deciding to migrate a network from MPLS/SR-MPLS to SRv6, common questions involve how to go about performing the migration, what's the least amount of impact to an existing network and what existing techniques are available. This document presents various options for networks being migrated from MPLS/SR-MPLS to SRv6. |
| | GREASE Code Points in OpenPGP |
| |
|
This document reserves code points in various OpenPGP registries for use in interoperability testing, by analogy with GREASE in TLS. |
| | BMPS: Transport Layer Security for BGP Monitoring Protocol |
| |
|
The BGP Monitoring Protocol (BMP) defines the communication between a BMP station and multiple routers, referred to as network elements (NEs). This document describes BMP over TLS, which uses Transport Layer Security (TLS) to ensure secure transport between the NE and the BMP monitoring station. It updates [RFC7854] regarding BMP session establishment and termination. |
| | OpenID Connect Email Account Linking Extension |
| |
|
This document extends OpenID Connect's standard email functionality to support secure linking between multiple email accounts. It enables users to associate secondary email addresses with their primary account while maintaining backward compatibility with existing implementations. The extension provides methods for establishing, managing, and utilizing these relationships within the OpenID Connect email scope. |
| | Media Types for OpenPGP |
| |
|
This document updates the specification of existing media types, and specifies additional media types, for the identification of OpenPGP data in non-MIME contexts. |
| | Age Verification: Age vs. Youth -- One is not Like the Other |
| |
|
Solely technical measures advertised to allow for the age verification of minors online face fundamental challenges on a conceptual and implementation level. Organizational measures, on the other hand, have been established as best practices by peer groups who are both high risk and digitally savvy, which exists to protect minors. These approaches can be strengthened via technical measures, and two such candidates are the Qualified Website Authentication Certificates (QWACS), introduced by the EU as part of eIDAS 2.0 [QWACS] and potentially the work of IETF's digital emblems working group [DIEM]. Based on early analysis of the use and abuse cases as well as privacy and security considerations, we provide arguments why non-scaling organizational measures are a necessity and strengthening these with technical measures is a way to enable the security for minors online. |
| |
|
| |
| | YANG Data Model for IPv6 Neighbor Discovery |
| |
|
This document defines a YANG data model to configure and manage IPv6 Neighbor Discovery (ND) and related functions, including IPv6 address resolution, redirect function, proxy Neighbor Advertisement, Neighbor Unreachability Detection (NUD), Duplicate Address Detection (DAD), SEcure Neighbor Discovery (SEND), and Secure ND Proxy. |
| | Common YANG Data Types for Layer 0 Optical Networks |
| |
| | draft-ietf-ccamp-rfc9093-bis-16.txt |
| | Date: |
07/08/2025 |
| | Authors: |
Sergio Belotti, Italo Busi, Dieter Beller, Esther Le Rouzic, Aihua Guo |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
|
This document defines a collection of common data types, identities, and groupings in the YANG data modeling language. These common types and groupings, derived from the built-in YANG data types, identities, and groupings are intended to be imported by modules that model Optical Layer 0 configuration and state capabilities, such as Wavelength Switched Optical Networks (WSONs) and flexi-grid Dense Wavelength Division Multiplexing (DWDM) networks. This document obsoletes RFC 9093 by replacing the YANG module it contained with a new revision that includes additional YANG data types, identities and groupings. |
| | COSE Receipts |
| |
|
COSE (CBOR Object Signing and Encryption) Receipts prove properties of a verifiable data structure to a verifier. Verifiable data structures and associated proof types enable security properties, such as minimal disclosure, transparency and non-equivocation. Transparency helps maintain trust over time, and has been applied to certificates, end to end encrypted messaging systems, and supply chain security. This specification enables concise transparency oriented systems, by building on CBOR (Concise Binary Object Representation) and COSE. The extensibility of the approach is demonstrated by providing CBOR encodings for RFC9162. |
| | Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) for JOSE and COSE |
| |
| | draft-ietf-jose-pqc-kem-03.txt |
| | Date: |
07/08/2025 |
| | Authors: |
Tirumaleswar Reddy.K, Aritra Banerjee, Hannes Tschofenig |
| | Working Group: |
Javascript Object Signing and Encryption (jose) |
|
This document describes the conventions for using Post-Quantum Key Encapsulation Mechanisms (PQ-KEMs) within JOSE and COSE. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-jose-pqc/. Discussion of this document takes place on the jose Working Group mailing list (mailto:jose@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/cose/. Subscribe at https://www.ietf.org/mailman/listinfo/jose/. |
| | A Common YANG Data Model for Scheduling |
| |
|
This document defines common types and groupings that are meant to be used for scheduling purposes such as event, policy, services, or resources based on date and time. For the sake of better modularity, the YANG module includes a set of recurrence-related groupings with varying levels of representation (i.e., from basic to advanced) to accommodate a variety of requirements. It also defines groupings for validating requested schedules and reporting scheduling status. |
| | An Update to YANG Module Names Registration |
| |
|
This document amends the IANA guidance on the uniqueness of YANG module and submodule names. The document updates RFC 6020 to clarify how modules and their revisions are handled by IANA. |
| | An Update of Operators Requirements on Network Management Protocols and Modelling |
| |
|
The IAB organized an important workshop to establish a dialog between network operators and protocol developers, and to guide the IETF focus on work regarding network management. The outcome of that workshop was documented in the "IAB Network Management Workshop" (RFC 3535) which was instrumental for developing NETCONF and YANG, in particular. |
| | DNS Filtering Details for Applications |
| |
|
[I-D.ietf-dnsop-structured-dns-error] introduces structured error data for DNS responses that have been filtered. This specification allows more specific details of filtering incidents to be conveyed. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/mnot/public-resolver-errors. |
| | Guidelines for Considering Operations and Management in IETF Specifications |
| |
| | draft-opsarea-rfc5706bis-04.txt |
| | Date: |
07/08/2025 |
| | Authors: |
Benoit Claise, Joe Clarke, Adrian Farrel, Samier Barguil, Carlos Pignataro, Ran Chen |
| | Working Group: |
Individual Submissions (none) |
|
New Protocols or Protocol Extensions are best designed with due consideration of the functionality needed to operate and manage the protocols. Retrofitting operations and management is sub-optimal. The purpose of this document is to provide guidance to authors and reviewers of documents that define New Protocols or Protocol Extensions regarding aspects of operations and management that they should consider and include in their documents. This document obsoletes RFC 5706, replacing it completely and updating it with new operational and management techniques and mechanisms. It also introduces a requirement to include an "Operational Considerations" section in new RFCs in the IETF Stream. |
| | The IETF is for Everyone: Toward Inclusive and Equitable Participation in Internet Governance |
| |
|
This document aims to foster a deeper reflection within the IETF community on inclusive participation, equitable access, and the implications of global meeting venue selections on diverse contributors. It seeks to complement existing RFCs by proposing additional dialogue, tools, and evaluation mechanisms. |
| | Operational Recommendations for DS Automation |
| |
|
Enabling support for automatic acceptance of DS parameters from the Child DNS operator (via RFCs 7344, 8078, 9615) requires the parent operator, often a registry or registrar, to make a number of technical decisions. This document describes recommendations for new deployments of such DS automation. |
| | A Best Current Practice for Agentic Interactions over HTTP |
| |
|
This document describes a set of best practices for facilitating interactions between automated software agents (AI agents) using the Hypertext Transfer Protocol (HTTP). As agentic systems proliferate, they frequently utilize HTTP in ad-hoc ways, leading to interoperability challenges and the rise of proprietary, "walled garden" ecosystems. This document proposes a minimalist, standardized framework based on existing HTTP semantics to promote a more cohesive, efficient, and open ecosystem. The primary recommendations codify the principles of the Agentic Hypercall Protocol (AHP), including tool invocation via GET requests, a stateless authentication scheme, and the formalization of the 402 (Payment Required) status code to enable a native economic layer for the machine economy. |
| | PCE Communication Protocol (PCEP) Extensions for Using the PCE as a Central Controller (PCECC) of point-to-multipoint (P2MP) LSPs |
| |
|
The PCE is a core component of Software-Defined Networking (SDN) systems. The PCE has been identified as an appropriate technology for the determination of the paths of point-to-multipoint (P2MP) TE Label Switched Paths (LSPs). A PCE-based Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. Thus, the P2MP LSP can be calculated/set up/initiated, and the label-forwarding entries can also be downloaded through a centralized PCE server to each network device along the P2MP path while leveraging the existing PCE technologies as much as possible. This document specifies the procedures and PCE Communication Protocol (PCEP) extensions for using the PCE as the central controller for provisioning labels along the path of the static P2MP LSP. |
| | RDAP Extension for DNS Time-To-Live (TTL Values) |
| |
|
This document describes an extension to the Registration Data Access Protocol ([RFC9083]) which allows the Time-To-Live (TTL) values for relevant DNS record types to be included in RDAP responses. About this draft This note is to be removed before publishing as an RFC. The source for this draft, and an issue tracker, may can be found at https://github.com/gbxyz/rdap-ttl-extension. |
| | Secure Asset Transfer Protocol (SATP) Core |
| |
| | draft-ietf-satp-core-11.txt |
| | Date: |
07/08/2025 |
| | Authors: |
Martin Hargreaves, Thomas Hardjono, Rafael Belchior, Venkatraman Ramakrishna, Alexandru Chiriac |
| | Working Group: |
Secure Asset Transfer Protocol (satp) |
|
This memo describes the Secure Asset Transfer (SAT) Protocol for digital assets. SAT is a protocol operating between two gateways that conducts the transfer of a digital asset from one gateway to another, each representing their corresponding digital asset networks. The protocol establishes a secure channel between the endpoints and implements a 2-phase commit (2PC) to ensure the properties of transfer atomicity, consistency, isolation and durability. |
| | Recommendations for Discovering IPv6 Prefix Used for IPv6 Address Synthesis |
| |
|
On networks providing IPv4-IPv6 translation (RFC7915), hosts and other endpoints need to know the IPv6 prefix(es) used for translation (the NAT64 prefix, RFC6052). This document provides guidelines for NAT64 prefix discovery, specifically recommending obtaining the NAT64 prefix from Router Advertisement option (RFC8781) when available. |
| |
|
| |
| | DULT Threat Model |
| |
|
Lightweight location tracking tags are in wide use to allow users to locate items. These tags function as a component of a crowdsourced tracking network in which devices belonging to other network users (e.g., phones) report which tags they see and their location, thus allowing the owner(s) of the tag to determine where their tag was most recently seen. While there are many legitimate uses of these tags, they are also susceptible to misuse for the purpose of stalking and abuse. A protocol that allows others to detect unwanted location trackers must incorporate an understanding of the unwanted tracking landscape today. This document provides a threat analysis for this purpose, including a taxonomy of unwanted tracking and potential attacks against detection of unwanted location tracking (DULT) protocols. The document defines what is in and out of scope for the unwanted location tracking protocols, and provides design requirements, constraints, and considerations for implementation of protocols to detect unwanted location tracking. |
| | Post-quantum Hybrid Key Exchange with ML-KEM in the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
NIST recently standardized ML-KEM, a new key encapsulation mechanism, which can be used for quantum-resistant key establishment. This draft specifies how to use ML-KEM as an additional key exchange in IKEv2 along with traditional key exchanges. This Post-Quantum Traditional Hybrid Key Encapsulation Mechanism approach allows for negotiating IKE and Child SA keys which are safe against cryptanalytically-relevant quantum computers and theoretical weaknesses in ML-KEM. |
| | Anonymous Rate-Limited Credentials |
| |
| | draft-yun-cfrg-arc-01.txt |
| | Date: |
06/08/2025 |
| | Authors: |
Cathie Yun, Christopher Wood |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the Anonymous Rate-Limited Credential (ARC) protocol, a specialization of keyed-verification anonymous credentials with support for rate limiting. ARC credentials can be presented from client to server up to some fixed number of times, where each presentation is cryptographically bound to client secrets and application-specific public information, such that each presentation is unlinkable from the others as well as the original credential creation. ARC is useful in applications where a server needs to throttle or rate-limit access from anonymous clients. |
| | Privacy Pass Issuance Protocol for Anonymous Rate-Limited Credentials |
| |
|
This document specifies the issuance and redemption protocols for tokens based on the Anonymous Rate-Limited Credential (ARC) protocol. |
| | Using IS-IS To Advertise Power Group Membership |
| |
|
This document introduces Power Groups. A Power Group is a hierarchical abstraction of power consumed by hardware components. In IS-IS, interfaces can reference the Power Group to which they belong. Therefore, Power Groups provide a method of organizing interfaces into groups by power characteristics. The TE path placement algorithm can use Power Group membership information to implement TE policy. Power Group information is particularly useful when implementing TE policies that support power- savings and sustainability. |
| | A Bound End-to-End Tunnel (BEET) mode for ESP |
| |
|
This document is an update to the Bound End-to-End Tunnel (BEET) mode for ESP in as described in [RFC7402]. It brings the description in alignment with the addition of BEET mode for IKEv2 without any processing changes as described in [RFC7402] |
| | Designing an Intermediate Data Format |
| |
|
Intermediate data formats (IDFs), also known as external data formats or data-interchange formats, are used to exchange data between networked applications. Example formats are JavaScript Object Notation (JSON) and Abstract Syntax Notation One (ASN.1). IDFs are ubiquitous in networking. Despite their importance, there's remarkably little written guidance about how to actually design or architect an IDF. This guidance gap exists despite fifty years of experience designing and deploying IDFs, going back to the days of ARPANET. As a result, even recently developed IDFs have obvious flaws that could have been avoided. The purpose of this memo is to provide basic basic guidance about how to design an IDF. This memo is NOT the product of any IETF or IRTF working group. |
| | A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services |
| |
| | draft-ietf-tsvwg-nqb-31.txt |
| | Date: |
06/08/2025 |
| | Authors: |
Greg White, Thomas Fossati, Ruediger Geib |
| | Working Group: |
Transport and Services Working Group (tsvwg) |
|
This document specifies characteristics of a Non-Queue-Building Per- Hop Behavior (NQB PHB). The NQB PHB provides a shallow-buffered, best-effort service as a complement to a Default deep-buffered best- effort service for Internet services. The purpose of this NQB PHB is to provide a separate queue that enables smooth (i.e. non-bursty), low-data-rate, application-limited traffic microflows, which would ordinarily share a queue with bursty and capacity-seeking traffic, to avoid the delay, delay variation and loss caused by such traffic. This PHB is implemented without prioritization and can be implemented without rate policing, making it suitable for environments where the use of these features is restricted. The NQB PHB has been developed primarily for use by access network segments, where queuing delay and queuing loss caused by Queue-Building protocols are manifested, but its use is not limited to such segments. In particular, the application of NQB PHB to cable broadband links, Wi-Fi links, and mobile network radio and core segments are discussed. This document recommends a specific Differentiated Services Code Point (DSCP) to identify Non-Queue-Building microflows, and updates the RFC8325 guidance on mapping Diffserv to IEEE 802.11 for this codepoint. [NOTE (to be removed by RFC-Editor): This document references an ISE submission draft (I-D.briscoe-docsis-q-protection) that is approved for publication as an RFC. This draft should be held for publication until the queue protection RFC can be referenced.] |
| |
|
| |
| | IGP Flexible Algorithms Reverse Affinity Constraint |
| |
|
An IGP Flexible Algorithm (Flex-Algorithm) enables the computation of constraint-based paths within an IGP domain, allowing operators to influence path selection according to administrative policies. This document defines an extension to Flex-Algorithm that allows the inclusion or exclusion of links from path computation based on Administrative Groups (also known as link affinities) associated with the reverse direction of the path under computation. This extension enhances the path selection capabilities of Flex- Algorithm by enabling reverse-affinity-based constraints, which are particularly useful for scenarios where path symmetry or directional link attributes are operationally significant. This document updates [RFC9350] and [I-D.ietf-lsr-flex-algo-bw-con] by introducing the new IANA registry that specifies the ordered set of rules that are used to prune links from the topology during the Flex-Algorithm path computation. |
| | Compressed Routing Header (CRH) Helper Option |
| |
|
This document introduces a new IPv6 Destination Option called the CRH Helper. The CRH Helper is used with the Compact Routing Header (CRH) [RFC 9631]. It contains information required to convert a CRH SID to the IPv6 address of a interface on a packet's delivery path. Because the CRH Helper contains this information, it eliminates the need for a CRH-FIB. It also eliminates the need for CRH-FIB support in the control plane. The CRH helper is useful in underlay networks, where all interfaces are numbered from a few /112 or /96 prefixes. |
| | MoQ qlog event definitions |
| |
|
This document defines a qlog event schema containing concrete events for MoQ. |
| | Time Synchronization over QUIC |
| |
|
This document proposes a modern, secure, and extensible time synchronization protocol designed to operate over the QUIC transport protocol. Known as TSQ (Time Synchronization over QUIC), this protocol aims to address the limitations of traditional NTP by leveraging QUIC's encryption, widespread UDP/443 acceptance, and multiplexed stream capabilities. TSQ is designed for contemporary deployment environments, including enterprise networks, cloud-native systems, containers, and mobile devices, where traditional UDP-based NTP struggles with security, scalability, or operational reliability. |
| | Extended Key Usage (EKU) for X.509 Certificates associated with Attestation Keys |
| |
|
As described in RFC5280, key usages are specified in X.509 certificates using the certificate extensions "Key Usage" and "Extended Key Usage". This document defines an Extended Key Usage (EKU) relating to keys that are dedicated to the purpose of signing attestation evidence as introduced in RFC9334. |
| |
|
| |
| | Traffic Steering using BGP FlowSpec with SR Policy |
| |
|
BGP Flow Specification (FlowSpec) [RFC8955] and [RFC8956] has been proposed to distribute BGP [RFC4271] FlowSpec NLRI to FlowSpec clients to mitigate (distributed) denial-of-service attacks, and to provide traffic filtering in the context of a BGP/MPLS VPN service. Recently, traffic steering applications in the context of SR-MPLS and SRv6 using FlowSpec are being used in networks. This document introduces the usage of BGP FlowSpec to steer packets into an SR Policy. |
| | BGP Extension for SR-MPLS Entropy Label Position |
| |
|
This document proposes extensions for BGP to indicate the entropy label position in the SR-MPLS label stack when delivering SR Policy via BGP. |
| | Advertising SID Algorithm Information in BGP |
| |
|
This document defines new Segment Types and proposes extensions for BGP to provide algorithm information for SR-MPLS Adjacency-SIDs when delivering SR Policy via BGP. |
| | LISP Control-Plane ECDSA Authentication and Authorization |
| |
|
This draft describes how LISP control-plane messages can be individually authenticated and authorized without a a priori shared- key configuration. Public-key cryptography is used with no new PKI infrastructure required. |
| | IS-IS Extension to Advertise SRv6 SIDs using SID Block |
| |
|
This document proposes a simplified method to advertise SRv6 SIDs in IS-IS. The SRv6 SID Block is composed of a number of continuous SIDs within the address range of a Locator. When a SID is assigned from the SID Block, it is described by an index based on the SID Block, instead of the whole 128-bit IPv6 address. |
| | Service Interworking between SRv6 |
| |
|
When operators provide services through SRv6, such as L3VPN and L2VPN, there may be cross-domain scenarios of multiple ASs, or multiple admin domain scenarios within the same AS. This document describes how to implement interworking of services for such scenarios. |
| | Ping Path Consistency over SRv6 |
| |
|
In the SRv6 network, the headend node could use Ping (ICMPv6 Echo) to detect the connectivity of the SRv6 path to implement path switching. When a headend use Ping to detect the segment list/CPath of SRv6 Policy, the forward path of ICMPv6 Echo Request message is indicated by segment list, the reverse path of ICMPv6 Echo Reply message is via the shortest path from the destination node to the source as determined by routing. The forward path and reverse path of ICMPv6 message are likely inconsistent going through different intermediate nodes or links. This document describes how to ensure the consistency of the forward path and the reverse path when using ICMPv6 Echo messages to detect SRv6 Policy. |
| | Path-aware Remote Protection Framework |
| |
|
This document describes the framework of path-aware remote protection. |
| | SRv6 SFC Architecture with SR-aware Functions |
| |
|
This document describes the architecture of Segment Routing over IPv6 (SRv6) Service Function Chaining (SFC) with SR-aware functions. This architecture provides the following benefits: * Comprehensive Management: a centralized controller for SFC, handling SR Policy, link-state, and network metrics. * Simplicity: no SFC proxies, which reduces the number of nodes and address resource consumption. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Source Packet Routing in Networking Working Group mailing list (spring@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/spring/. Source for this draft and an issue tracker can be found at https://https/github.com/watal. |
| | Considerations for Integrating Merkle Tree Ladder (MTL) Mode Signatures into Applications |
| |
|
This document provides design considerations for application designers on how to add Merkle Tree Ladder (MTL) Mode signatures into their applications. It provides general considerations relevant to any signature algorithm in addition to specific considerations for MTL mode such as for grouping and ordering messages to be signed, computing and signing ladders, and forming signatures exchanged between application components, including handling caching between the signer and the verifier. |
| | IPFIX Protocol over QUIC |
| |
|
The IP Flow Information Export (IPFIX) Protocol provides a means for transmitting Traffic Flow information over the network. IPFIX Data and Template Records can be carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. The supported transport protocols are SCTP, UDP and TCP. QUIC could provide useful, reliable and secure semantics for IPFIX Protocol in particular as a single connection could carry multiple traffic flows over streams, enabling much better efficiency and performance for Exporter and Collector. This document describes how to use IPFIX Protocol over the QUIC transport protocol, named IPFIXoQUIC. |
| | Task-Oriented Multi-Agent Recovery Framework for High-Reliability in Converged Mobile Networks |
| |
|
This document defines a task-oriented, agent-based method for fault recovery in converged public-private mobile networks. The proposed method introduces a multi-agent collaboration framework that enables autonomous failure detection, scoped diagnosis, inter-domain coordination, and intent-driven policy reconfiguration. It is particularly applicable in complex 5G/6G network deployments, such as Multi-Operator Core Networks (MOCN) and Standalone Non-Public Networks (SNPN), where traditional centralized management is insufficient for ensuring high service reliability and dynamic recovery. The document also specifies protocol requirements for inter-agent communication, state consistency, and secure coordination, aiming to support interoperability and resilience across heterogeneous network domains. |
| | Architectural Considerations of Age Restriction |
| |
|
Around the world, policymakers are considering (and in some cases implementing) age restriction systems for Internet content. This document explores the unwanted impacts on the Internet that these systems are likely to have, and makes recommendations to increase their chances of becoming a successful part of the Internet infrastructure. |
| | YANG Data Model for RPKI to Router Protocol |
| |
| | draft-ietf-sidrops-rtr-yang-00.txt |
| | Date: |
04/08/2025 |
| | Authors: |
Yisong Liu, Changwang Lin, Haibo Wang, ROY Jishnu, Jeffrey Haas, Hongwei Liu, Di Ma |
| | Working Group: |
SIDR Operations (sidrops) |
|
This document defines YANG data models for configuring and managing Resource Public Key Infrastructure (RPKI) to Router Protocol (RFC6810 and RFC8210). |
| |
|
| |
| | Clarifications on CDS/CDNSKEY and CSYNC Consistency |
| |
|
Maintenance of DNS delegations requires occasional changes of the DS and NS record sets on the parent side of the delegation. For the case of DS records, RFC 7344 provides automation by allowing the child to publish CDS and/or CDNSKEY records holding the prospective DS parameters which the parent can ingest. Similarly, RFC 7477 specifies CSYNC records to indicate a desired update of the delegation's NS (and glue) records. Parent-side entities (e.g. Registries, Registrars) can query these records from the child and, after validation, use them to update the parent-side RRsets of the delegation. This document specifies that when performing such queries, parent- side entities MUST ensure that updates triggered via CDS/CDNSKEY and CSYNC records are consistent across the child's authoritative nameservers, before taking any action based on these records. |
| | Transaction ID Mechanism for NETCONF |
| |
|
NETCONF clients and servers often need to have a synchronized view of the server's configuration data stores. The volume of configuration data in a server may be very large, while data store changes typically are small when observed at typical client resynchronization intervals. Rereading the entire data store and analyzing the response for changes is inefficient for synchronization. This document specifies a NETCONF extension that allows clients and servers to keep synchronized with a much smaller data exchange and without any need for servers to store information about the clients. |
| | Computing-Aware Traffic Steering (CATS) Using Segment Routing |
| |
|
This document describes a solution that adheres to the Computing- Aware Traffic Steering (CATS) framework. The solution uses anycast IP addresses as the CATS service identifier and Segment Routing (SR) as the data plane encapsulation to achieve computing-aware traffic steering among multiple services instances. |
| | RIFT Key/Value TIE Structure and Processing |
| |
|
The RIFT (Routing in Fat Trees) protocol allows for key/value pairs to be advertised within Key-Value Topology Information Elements (KV TIEs). The data contained within these KV TIEs can be used for any imaginable purpose. This document defines the various Key-Types (i.e. Well-Known, OUI, and Experimental) and a method to structure corresponding values. |
| | Protocol Numbers for SCHC |
| |
|
This document requests an Internet Protocol Number, and an Ethertype assignment for SCHC. The Internet Protocol Number request is so that SCHC can be used for IP independent SCHC of other transports such as UDP and ESP. The Ethertype is to support generic use of native SCHC over any IEEE 802 technology for IP and non-IP protocols. |