| |
|
| |
| | Protecting EST Payloads with OSCORE |
| |
| | draft-ietf-ace-coap-est-oscore-10.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Goeran Selander, Shahid Raza, Martin Furuhed, Malisa Vucinic, Timothy Claeys |
| | Working Group: |
Authentication and Authorization for Constrained Environments (ace) |
|
Enrollment over Secure Transport (EST) is a certificate provisioning protocol over HTTPS [RFC7030] or CoAPs [RFC9148]. This document specifies how to carry EST over the Constrained Application Protocol (CoAP) protected with Object Security for Constrained RESTful Environments (OSCORE). The specification builds on the EST-coaps [RFC9148] specification, but uses OSCORE and Ephemeral Diffie-Hellman over COSE (EDHOC) instead of DTLS. The specification also leverages the certificate structures defined in [I-D.ietf-cose-cbor-encoded-cert], which can be optionally used alongside X.509 certificates. |
| | Short Distribution Chain (SDC) Workflow and New OAuth Parameters for the Authentication and Authorization for Constrained Environments (ACE) Framework |
| |
|
This document updates the Authentication and Authorization for Constrained Environments framework (ACE, RFC 9200) as follows. (1) It defines the Short Distribution Chain (SDC) workflow that the authorization server (AS) can use for uploading an access token to a resource server on behalf of the client. (2) For the OAuth 2.0 token endpoint, it defines new parameters and encodings and it extends the semantics of the "ace_profile" parameter. (3) For the OAuth 2.0 authz-info endpoint, it defines a new parameter and its encoding. (4) It defines how the client and the AS can coordinate on the exchange of the client's and resource server's public authentication credentials, when those can be transported by value or identified by reference; this extends the semantics of the "rs_cnf" parameter for the OAuth 2.0 token endpoint, thus updating RFC 9201. (5) It extends the error handling at the AS, for which it defines a new error code. (6) It deprecates the original payload format of error responses conveying an error code, when CBOR is used to encode message payloads. For those responses, it defines a new payload format aligned with RFC 9290, thus updating in this respect also the profiles defined in RFC 9202, RFC 9203, and RFC 9431. (7) It amends two of the requirements on profiles of the framework. |
| | The Group Object Security for Constrained RESTful Environments (Group OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework |
| |
|
This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. The profile uses Group Object Security for Constrained RESTful Environments (Group OSCORE) to provide communication security between a client and one or multiple resource servers that are members of an OSCORE group. The profile securely binds an OAuth 2.0 access token to the public key of the client associated with the private key used by that client in the OSCORE group. The profile uses Group OSCORE to achieve server authentication and proof of possession of the client's private key. Also, it provides proof of the client's membership to the OSCORE group by binding the access token to information from the Group OSCORE Security Context, thus allowing the resource server(s) to verify the client's membership upon receiving a message protected with Group OSCORE from the client. Effectively, the profile enables fine-grained access control paired with secure group communication, in accordance with the Zero Trust principles. |
| | Automated Certificate Management Environment (ACME) Profiles Extension |
| |
|
This document defines how an ACME Server may offer a selection of different certificate profiles to ACME Clients, and how those clients may indicate which profile they want. |
| | SDF Protocol Mapping |
| |
|
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 non-IP and IP protocols such as Bluetooth Low Energy, Zigbee or HTTP and CoAP. This document also describes a method to extend SCIM with an SDF model mapping. |
| | H.265 Profile for WebRTC |
| |
|
RFC 7742 defines WebRTC video processing and codec requirements, including guidance for endpoints supporting the VP8 and H.264 codecs, which are mandatory to implement. With support for H.265 under development in WebRTC browsers, similar guidance is needed for browsers considering support for the H.265 codec, whose RTP payload format is defined in RFC 7798. |
| | RTP Payload Format for Avatar Representation Format (ARF) Animation Stream |
| |
| | draft-ietf-avtcore-rtp-avatar-01.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Hyunsik Yang, Xavier de Foy, Ahmed Hamza, Imed Bouazizi |
| | Working Group: |
Audio/Video Transport Core Maintenance (avtcore) |
|
This memo outlines RTP payload formats for the animation stream format as defined in the ISO/IEC 23090-39 standard (MPEG-I Avatar Representation Format), in the following referred to as ARF. ARF is composed of Avatar Animation Units (AAU) including an AAU header and zero or more AAU packets. The RTP payload header format allows for packetization of an AAU unit in an RTP packet payload as well as fragmentation of an AAU into multiple RTP packets. |
| | BGP based Multi-homing in Virtual Private LAN Service |
| |
|
Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private Network (VPN) that gives its customers the appearance that their sites are connected via a Local Area Network (LAN). It is often required for the Service Provider (SP) to give the customer redundant connectivity to some sites, often called "multi-homing". This memo shows how BGP-based multi-homing can be offered in the context of LDP and BGP VPLS solutions. This document updates RFC 4761 by defining new flags in the Control Flags field of the Layer2 Info Extended Community. |
| | Per multicast flow Designated Forwarder Election for EVPN |
| |
|
This document defines an enhancement to the Designated Forwarder (DF) election process in Ethernet Virtual Private Network (EVPN) environments. While traditional DF election operates at a per Virtual Local Area Network (VLAN) or per group of VLANs (in case of VLAN bundle or VLAN-aware bundle service) level, such granularity may not be sufficient for applications requiring optimized or isolated multicast forwarding. This specification introduces a refined DF election mechanism that extends existing hash-based methods to operate at a more granular level specifically at the tuple of Ethernet Segment Identifier (ESI), VLAN, and multicast flow. This approach enables improved traffic distribution, enhanced load balancing, and greater deployment flexibility for multicast delivery in EVPN based networks. The proposed method is designed to remain compatible with existing DF election procedures while offering targeted improvements for multicast scenarios. |
| | Weighted Multi-Path Procedures for EVPN Multi-Homing |
| |
| | draft-ietf-bess-evpn-unequal-lb-33.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Neeraj Malhotra, Ali Sajassi, Jorge Rabadan, John Drake, Avinash Lingala, Samir Thoria |
| | Working Group: |
BGP Enabled ServiceS (bess) |
|
Ethernet VPN (EVPN) provides all-active multi-homing for Customer Equipment (CE) devices connected to multiple Provider Edge (PE) devices, enabling equal cost load balancing of both bridged and routed traffic across the set of multi-homing PEs. However, existing procedures implicitly assume equal access bandwidth distribution among the multi-homing PEs, which can constrain link additions or removals and may not handle unequal PE-CE link bandwidth following link failures. This document specifies extensions to EVPN procedures to support weighted multi-pathing in proportion to PE-CE link bandwidth or operator-defined weights, thereby providing greater flexibility and resilience in multi-homing deployments. The extensions include signaling mechanisms to distribute traffic across egress PEs based on relative bandwidth or weight, and enhancements to Broadcast, Unknown Unicast, and Multicast (BUM) designated forwarder (DF) election to achieve weighted DF distribution across the multi- homing PE set. The document updates RFC 8584 to enable weighted load balancing across different DF election algorithms. |
| | BGP MPLS-Based Ethernet VPN |
| |
|
This document describes procedures for Ethernet VPN (EVPN), a BGP MPLS-based solution which addresses the requirements specified in the corresponding RFC - "Requirements for Ethernet VPN (EVPN)". This document obsoletes RFC7432 (BGP MPLS-Based Ethernet VPN) and updates RFC8214 (Virtual Private Wire Service Support in Ethernet VPN). |
| | EVPN Support for L3 Fast Convergence and Aliasing/Backup Path |
| |
|
This document proposes an EVPN extension to allow several of its multi-homing functions, fast convergence, and aliasing/backup path, to be used in conjunction with inter-subnet forwarding. The extension is limited to All-Active and Single-Active redundancy modes. |
| | Domain Path (D-PATH) for Ethernet VPN (EVPN) Interconnect Networks |
| |
| | draft-ietf-bess-evpn-dpath-04.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Jorge Rabadan, Senthil Sathappan, Mallika Gautam, Patrice Brissette, Wen Lin |
| | Working Group: |
BGP Enabled ServiceS (bess) |
|
The BGP Domain PATH (D-PATH) attribute is defined for Inter-Subnet Forwarding (ISF) BGP Sub-Address Families that advertise IP prefixes. When used along with EVPN IP Prefix routes or IP-VPN routes, it identifies the domain(s) through which the routes have passed and that information can be used by the receiver BGP speakers to detect routing loops or influence the BGP best path selection. This document extends the use of D-PATH so that it can also be used along with other EVPN route types. |
| | Ethernet VPN Virtual Private Wire Services Gateway Solution |
| |
|
Ethernet Virtual Private Network Virtual Private Wire Services (EVPN VPWS) need to be deployed in high scale multi-domain networks, where each domain can use a different transport technology, such as MPLS, VXLAN or Segment Routing with MPLS or IPv6 Segment Identifiers (SIDs). While transport interworking solutions on border routers spare the border routers from having to process service routes, they do not always meet the multi-homing, redundancy, and operational requirements, or provide the isolation that each domain requires. This document analyzes the scenarios in which an interconnect solution for EVPN VPWS using EVPN Domain Gateways is needed, and adds the required extensions to support it. |
| | A Framework for Fast Reroute with Bit Index Explicit Replication (BIER-FRR) |
| |
| | draft-ietf-bier-frr-12.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Huaimo Chen, Mike McBride, Steffen Lindner, Michael Menth, Toerless Eckert |
| | Working Group: |
Bit Indexed Explicit Replication (bier) |
|
This document provides a framework for the development of Fast Reroute (FRR) mechanisms for Bit Index Explicit Replication forwarding (BIER-FRR). BIER-FRR can provide protection against link or BFR failure by invoking locally pre-determined repair paths that can react in the same time-scales as (unicast) FRR for MPLS or IP networks - "sub 50msec", and without the creation of additional per- path or per-flow state coordinated across multiple routers/LSR. BIER-FRR can be implemed locally within a router/LSR with minimal interoperability requirements against other router/LSR. It can therefore easily be introduced incrementally or selectively where needed. BIER-FRR implementing nodes only need to understand the routing topology of the network for calculation of repair paths and know what type of unicast encapsulation can be used to send ("tunnel") BIER packets to remote BFR. This document proposes and discusses different options for BIER forwardng (BIFT) extensions to support BIER-FRR. These are exemplary and non-normative. This document does not specify any standards or experiments but aims to support such efforts. |
| | A Framework for Computing-Aware Traffic Steering (CATS) |
| |
| | draft-ietf-cats-framework-21.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Cheng Li, Zongpeng Du, Mohamed Boucadair, Luis Contreras, John Drake |
| | Working Group: |
Computing-Aware Traffic Steering (cats) |
|
This document describes a framework for Computing-Aware Traffic Steering (CATS). Specifically, the document identifies a set of CATS functional components, describes their interactions, and provides illustrative workflows of the control and data planes. |
| | CBOR Extended Diagnostic Notation (EDN) |
| |
|
This document formalizes and consolidates the definition of the Extended Diagnostic Notation (EDN) of the Concise Binary Object Representation (CBOR), addressing implementer experience. Replacing EDN's previous informal descriptions, it updates RFC 8949, obsoleting its Section 8, and RFC 8610, obsoleting its Appendix G. It also specifies and uses registry-based extension points, using one to support text representations of epoch-based dates/times and of IP addresses and prefixes. // (This cref will be removed by the RFC editor:) The present -20 // includes the definition of raw strings. -20 is intended for use at // IETF 125. |
| | A YANG data model to manage configurable DWDM optical interfaces |
| |
| | draft-ietf-ccamp-dwdm-if-param-yang-15.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Gabriele Galimberti, Dharini Hiremagalur, Gert Grammel, Roberto Manzotti, Dirk Breuer |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
|
This document defines a YANG model related to the Optical Transceiver parameters characterising coherent 100G and above interfaces. 100G and above Transceivers support coherent modulation, multiple modulation formats, multiple Forward Error Correction (FEC) codes including some not yet specified (or in phase of specification by) ITU-T G.698.2 or any other ITU-T recommendation. Use cases are described in RFC7698. The YANG model defined in this document can be used for Optical Parameters monitoring and/or configuration of Dense Wavelength Division Multiplexing (DWDM) interfaces. The use of this model does not guarantee interworking of DWDM transceivers. Optical path feasibility and interoperability has to be determined by tools and algorithms outside the scope of this document. The purpose of this model is to program interface parameters to consistently configure the mode of operation of transceivers. |
| | Framework and Data Model for OTN Network Slicing |
| |
| | draft-ietf-ccamp-yang-otn-slicing-11.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Aihua Guo, Luis Contreras, Sergio Belotti, Reza Rokui, Yunbin Xu, Yang Zhao, Xufeng Liu |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
|
The requirement of slicing network resources with desired quality of service is emerging at every network technology, including the Optical Transport Networks (OTN). As a part of the transport network, OTN can provide hard pipes with guaranteed data isolation and deterministic low latency, which are highly demanded in the Service Level Agreement (SLA). This document describes a framework for OTN network slicing and defines YANG data models with OTN technology-specific augments deployed at both the north and south bound of the OTN network slice controller. Additional YANG data model augmentations will be defined in a future version of this draft. |
| | Conveying Transceiver-Related Information within RSVP-TE Signaling |
| |
| | draft-ietf-ccamp-tsvmode-signaling-02.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Julien Meuric, Esther Le Rouzic, Gabriele Galimberti, Sergio Belotti, Dieter Beller |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
|
The ReSource reserVation Protocol with Traffic Engineering extensions (RSVP-TE) allows to carry optical information so as to set up channels over Wavelength Division Multiplexing (WDM) networks between a pair of transceivers. Nowadays, there are many transceivers that not only support tunable lasers, but also multiple modulation formats. This memo leverages the Generalized Multiprotocol Label Switching protocol extensions to support the signaling of the associated information as a "mode" parameter within a "transceiver type" context. |
| | BBR Congestion Control |
| |
| | draft-ietf-ccwg-bbr-05.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Neal Cardwell, Ian Swett, Joseph Beshay |
| | Working Group: |
Congestion Control Working Group (ccwg) |
|
This document specifies the BBR congestion control algorithm. BBR ("Bottleneck Bandwidth and Round-trip propagation time") uses recent measurements of a transport connection's delivery rate, round-trip time, and packet loss rate to build an explicit model of the network path. BBR then uses this model to control both how fast it sends data and the maximum volume of data it allows in flight in the network at any time. Relative to loss-based congestion control algorithms such as Reno [RFC5681] or CUBIC [RFC9438], BBR offers substantially higher throughput for bottlenecks with shallow buffers or random losses, and substantially lower queueing delays for bottlenecks with deep buffers (avoiding "bufferbloat"). BBR can be implemented in any transport protocol that supports packet-delivery acknowledgment. Thus far, open source implementations are available for TCP [RFC9293] and QUIC [RFC9000]. This document specifies version 3 of the BBR algorithm, BBRv3. |
| | 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. |
| | CDNI Edge Control Metadata |
| |
|
This specification defines configuration metadata objects used to manage how edge servers control access to resources within Content Delivery Networks (CDNs) and Open Caching systems. A key feature of these configurations is the configuring of Cross-Origin Resource Sharing (CORS) access rules and the dynamic generation of CORS headers. This specification also provides the ability to define response body compression rules and client connection timeouts. |
| | Implementation Guidance for the PKCS #1 RSA Cryptography Specification |
| |
|
This document specifies additions and amendments to RFC 8017. Specifically, it provides guidance to implementers of the standard to protect against side-channel attacks. It also deprecates the RSAES- PKCS-v1_5 encryption scheme, and provides an alternative depadding algorithm that protects against side-channel attacks raising from users of vulnerable APIs. The purpose of this specification is to increase security of RSA implementations. |
| | Hybrid PQ/T Key Encapsulation Mechanisms |
| |
|
This document defines generic constructions for hybrid Key Encapsulation Mechanisms (KEMs) based on combining a post-quantum (PQ) KEM with a traditional cryptographic component. Hybrid KEMs built using these constructions provide strong security properties as long as either of the underlying algorithms are secure. |
| | Concrete Hybrid PQ/T Key Encapsulation Mechanisms |
| |
|
PQ/T Hybrid Key Encapsulation Mechanisms (KEMs) combine "post- quantum" cryptographic algorithms, which are safe from attack by a quantum computer, with "traditional" algorithms, which are not. CFRG has developed a general framework for creating hybrid KEMs. In this document, we define concrete instantiations of this framework to illustrate certain properties of the framework and simplify implementors' choices. |
| | Interactive Sigma Proofs |
| |
|
A Sigma Protocol is an interactive zero-knowledge proof of knowledge that allows a prover to convince a verifier of the validity of a statement. It satisfies the properties of completeness, soundness, and zero-knowledge, as described in Section 3. This document describes Sigma Protocols for proving knowledge of pre- images of linear maps in prime-order elliptic curve groups. Examples include zero-knowledge proofs for discrete logarithm relations, ElGamal encryptions, Pedersen commitments, and range proofs. |
| | 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 duplex sponge object. 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 duplex sponge's internal state, while the squeeze operation produces variable-length, unpredictable outputs. This interface can be instantiated with different constructions based on permutation or compression functions. This specification also defines codecs to securely map prover messages into the duplex sponge domain, from the duplex sponge domain into verifier messages. It also establishes how the non-interactive argument string should be serialized. |
| | A publish-subscribe architecture for the Constrained Application Protocol (CoAP) |
| |
|
This document describes a publish-subscribe architecture for the Constrained Application Protocol (CoAP), extending the capabilities of CoAP communications for supporting endpoints with long breaks in connectivity and/or up-time. CoAP clients publish on and subscribe to a topic via a corresponding topic resource at a CoAP server acting as broker. |
| | CoAP Management Interface (CORECONF) |
| |
| | draft-ietf-core-comi-21.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Michel Veillette, Peter van der Stok, Alexander Pelov, Andy Bierman, Carsten Bormann |
| | Working Group: |
Constrained RESTful Environments (core) |
|
This document describes a network management interface for constrained devices and networks, called CoAP Management Interface (CORECONF). The Constrained Application Protocol (CoAP) is used to access datastore and data node resources specified in YANG, or SMIv2 converted to YANG. CORECONF uses the YANG to CBOR mapping and converts YANG identifier strings to numeric identifiers for payload size reduction. CORECONF extends the set of YANG based protocols, NETCONF and RESTCONF, with the capability to manage constrained devices and networks. |
| | Key Update for OSCORE (KUDOS) |
| |
|
Communications with the Constrained Application Protocol (CoAP) can be protected end-to-end at the application-layer by using the security protocol Object Security for Constrained RESTful Environments (OSCORE). Under some circumstances, two CoAP endpoints need to update their OSCORE keying material before communications can securely continue, e.g., due to approaching key usage limits. This document defines Key Update for OSCORE (KUDOS), a lightweight key update procedure that two CoAP endpoints can use to update their OSCORE keying material by establishing a new OSCORE Security Context. Accordingly, this document updates the use of the OSCORE flag bits in the CoAP OSCORE Option as well as the protection of CoAP response messages with OSCORE. Also, it deprecates the key update procedure specified in Appendix B.2 of RFC 8613. Therefore, this document updates RFC 8613. |
| | OSCORE-capable Proxies |
| |
|
When using the Constrained Application Protocol (CoAP), messages exchanged between two endpoints can be protected end-to-end at the application layer by means of Object Security for Constrained RESTful Environments (OSCORE), also in the presence of intermediaries such as proxies. This document defines how to use OSCORE for protecting CoAP messages also between an origin application endpoint and an intermediary, or between two intermediaries. Also, it defines rules to escalate the protection of a CoAP option, in order to encrypt and integrity-protect it whenever possible. Finally, it defines how to secure a CoAP message by applying multiple, nested OSCORE protections, e.g., both end-to-end between origin application endpoints; and between an application endpoint and an intermediary or between two intermediaries. Therefore, this document updates RFC 8613. Furthermore, this document updates RFC 8768, by explicitly defining the processing with OSCORE for the CoAP Hop-Limit Option. The approach defined in this document can be seamlessly employed also with Group OSCORE, for protecting CoAP messages when group communication is used in the presence of intermediaries. |
| | Proxy Operations in Group Communication for the Constrained Application Protocol (CoAP) |
| |
|
This document defines a specific realization of proxy intended for scenarios that use group communication for the Constrained Application Protocol (CoAP). Such a proxy processes a single request sent by a client typically over unicast and distributes the request to a group of servers, e.g., over UDP/IP multicast as the defined default transport protocol. Then, the proxy collects the individual responses from those servers and relays those responses back to the client, in a way that allows the client to distinguish the responses and their origin servers through embedded addressing information. This document updates RFC7252 with respect to caching of response messages at proxies. |
| | Identifier Update for OSCORE |
| |
|
Two peers that communicate with the CoAP protocol can use the Object Security for Constrained RESTful Environments (OSCORE) protocol to protect their message exchanges end-to-end. To this end, the two peers share an OSCORE Security Context and a number of related identifiers. In particular, each of the two peers stores a Sender ID that identifies its own Sender Context within the Security Context, and a Recipient ID that identifies the Recipient Context associated with the other peer within the same Security Context. These identifiers are sent in plaintext within OSCORE-protected messages. Hence, they can be used to correlate messages exchanged between peers and track those peers, with consequent privacy implications. This document defines an OSCORE ID update procedure that two peers can use to update their OSCORE identifiers. This procedure can be run stand- alone or seamlessly integrated in an execution of the Key Update for OSCORE (KUDOS) procedure. |
| | End-to-End Protected and Cacheable Responses for the Constrained Application Protocol (CoAP) using Group Object Security for Constrained RESTful Environments (Group OSCORE) |
| |
|
When using the Constrained Application Protocol (CoAP), exchanged messages can be protected end-to-end also across untrusted intermediary proxies. This can be achieved with Object Security for Constrained RESTful Environments (OSCORE) or, in the case of group communication, with Group Object Security for Constrained RESTful Environments (Group OSCORE). However, this sidesteps the proxies' abilities to cache responses from the origin server(s). This document restores cacheability of end-end protected responses at proxies, by using Group OSCORE and introducing consensus requests, which any client in an OSCORE group can send to one server or multiple servers in the same group. |
| | URI-Path abbreviation in CoAP |
| |
|
Applications built on CoAP face a conflict between the technical need for short message sizes and the interoperability requirement of following BCP190 and thus using (relatively verbose) well-known URI paths. This document introduces a CoAP option that allows expressing well-known URI paths in as little as two bytes. Negotiating the use of this option between client and server revealed a subtle flaw in RFC7252. This document updates RFC7252 to rectify it, thus making the extension point of critical options more useful. |
| | 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, common certificate profiles and is extensible. Two types of C509 certificates are defined. One type is an invertible CBOR re-encoding of DER-encoded X.509 certificates with the signature field copied from the DER encoding. The other type is identical except that the signature is over the CBOR encoding instead of the DER encoding, avoiding the use of ASN.1. Both types of certificates have the same semantics as X.509 and the same reduced size compared to X.509. The document also specifies CBOR encoded data structures for certificate (signing) requests and certificate request templates, new COSE headers, as well as a TLS certificate type and a file format for C509. This document updates RFC 6698; the TLSA selectors registry is extended to include C509 certificates. |
| | Use of Hybrid Public-Key Encryption (HPKE) with CBOR Object Signing and Encryption (COSE) |
| |
| | draft-ietf-cose-hpke-23.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Hannes Tschofenig, Orie Steele, Ajitomi, Daisuke, Laurence Lundblade, Michael Jones |
| | Working Group: |
CBOR Object Signing and Encryption (cose) |
|
This specification defines hybrid public-key encryption (HPKE) for use with CBOR Object Signing and Encryption (COSE). HPKE offers a variant of public-key encryption of arbitrary-sized plaintexts for a recipient public key. HPKE is a general encryption framework utilizing an asymmetric key encapsulation mechanism (KEM), a key derivation function (KDF), and an Authenticated Encryption with Associated Data (AEAD) algorithm. This document defines the use of HPKE with COSE. Authentication for HPKE in COSE is provided by COSE-native security mechanisms or by the pre-shared key authenticated variant of HPKE. |
| | TLS Client Authentication via DANE TLSA records |
| |
|
The DANE TLSA protocol describes how to publish Transport Layer Security (TLS) server certificates or public keys in the DNS. This document updates RFC 6698 and RFC 7671. It describes how to use the TLSA record to publish client certificates or public keys, and also the rules and considerations for using them with TLS. In addition, it defines a new TLS extension, DANE CLient Identity, to convey the client's domain name identity to the server. |
| | Mobile Traffic Steering |
| |
| | draft-ietf-dmm-mts-01.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Marco Liebsch, Jari Mutikainen, Zhaohui Zhang, Tianji Jiang |
| | Working Group: |
Distributed Mobility Management (dmm) |
|
The evolution of cellular mobile communication systems is aligned with an increasing demand for customized deployments, energy efficiency, dynamic re-configurability and the integration and use of other network technologies, such as non-cellular radio access technologies and non-terrestrial networks. In order to achieve and maintain the expected service quality and continuity, such systems should be designed and controllable end-to-end, taking all involved network domains and segments into account. This document discusses an end-to-end system from an advanced use cases perspective and substantiates the demand for solutions to share information and enable control interfaces between all connected network domains, including the mobile communication system and the transport network that stretches up to the data networks that host service instances. In the view of flexible implementations and deployment, two architectural principles, leveraging either a dedicated controller or a decentralized control plane, are described and discussed, accompanied by operational aspects and an associated information model that enable end-to-end mobile traffic treatment and steering in such complex and dynamically changing networks. |
| | Domain Control Validation using DNS |
| |
|
Many application services on the Internet need to verify ownership or control of a domain in the Domain Name System (DNS). The general term for this process is "Domain Control Validation", and can be done using a variety of methods such as email, HTTP/HTTPS, or the DNS itself. This document focuses only on DNS-based methods, which typically involve the Application Service Provider requesting a DNS record with a specific format and content to be visible in the domain to be verified. There is wide variation in the details of these methods today. This document provides some best practices to avoid known problems. |
| | Automating DNS Delegation Management via DDNS |
| |
|
Delegation information (i.e. the NS RRset, possible glue, possible DS records) should always be kept in sync between child zone and parent zone. However, in practice that is not always the case. When the delegation information is not in sync the child zone is usually working fine, but without the amount of redundancy that the zone owner likely expects to have. Hence, should any further problems ensue it could have catastrophic consequences. The DNS name space has lived with this problem for decades and it never goes away. Or, rather, it will never go away until a fully automated mechanism for how to keep the information in sync automatically is deployed. This document proposes such a mechanism based on DNS Dynamic Updates (DDNS) secured with SIG(0) signatures, sent from the child to the parent across the zone cut. The target of the update is discovered via the DSYNC record defined in [RFC9859]. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-ietf-dnsop-delegation-mgmt-via-ddns (https://github.com/johanix/draft-ietf-dnsop-delegation-mgmt-via- ddns). The most recent working version of the document, open issues, etc, should all be available there. The authors (gratefully) accept pull requests. |
| | Bundle Protocol Security (BPSec) COSE Context |
| |
|
This document defines a security context suitable for using CBOR Object Signing and Encryption (COSE) algorithms within Bundle Protocol Security (BPSec) integrity and confidentiality blocks. A profile for COSE, focused on asymmetric-keyed algorithms, and for PKIX certificates are also defined for BPSec interoperation. |
| | BMP v4: Extended TLV Support for BGP Monitoring Protocol (BMP) |
| |
| | draft-ietf-grow-bmp-tlv-20.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Paolo Lucente, Yunan Gu, Maxence Younsi, Pierre Francois |
| | Working Group: |
Global Routing Operations (grow) |
|
Most of the BGP Monitoring Protocol (BMP) message types make provision for data in Type, Length, Value (TLV) format. However, Route Monitoring messages (which provide a snapshot of the monitored Routing Information Base) Stats Reports (which supply periodical counters) and Peer Down messages (which indicate that a peering session was terminated) do not. Supporting (optional) data in TLV format across all BMP message types provides consistent and extensible structures that would be useful among the various use- cases where conveying additional data to a monitoring station is required. This document updates RFC 7854 [RFC7854] to support TLV data in all message types and defines some essential TLVs. Additionally, this document introduces support for enterprise- specific TLVs in the BGP Monitoring Protocol by defining an Enterprise Bit (E-bit) that allows usage of per-vendor Type values. |
| | Logging of routing events in BGP Monitoring Protocol (BMP) |
| |
|
The BGP Monitoring Protocol (BMP) does provide for BGP session event logging (Peer Up, Peer Down), state synchronization (Route Monitoring), debugging (Route Mirroring) and Statistics messages, among others. This document defines a new Route Event Logging (REL) message type for BMP with the aim of covering use cases with affinity to alerting, reporting and on-change analysis. |
| | Happy Eyeballs Version 3: Better Connectivity Using Concurrency |
| |
| | draft-ietf-happy-happyeyeballs-v3-03.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Tommy Pauly, David Schinazi, Nidhi Jaju, Kenichi Ishibashi |
| | Working Group: |
Heuristics and Algorithms to Prioritize Protocol deploYment (happy) |
|
Many communication protocols operating over the modern Internet use hostnames. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm, referred to as "Happy Eyeballs". This document updates the algorithm description in RFC 8305. |
| | Hybrid Public Key Encryption |
| |
| | draft-ietf-hpke-hpke-03.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Richard Barnes, Karthikeyan Bhargavan, Benjamin Lipp, Christopher Wood |
| | Working Group: |
HPKE Publication, Kept Efficient (hpke) |
|
This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes a variant that authenticates possession of a pre-shared key. HPKE works for any combination of an asymmetric Key Encapsulation Mechanism (KEM), key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2. |
| | Post-Quantum and Post-Quantum/Traditional Hybrid Algorithms for HPKE |
| |
| | draft-ietf-hpke-pq-04.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Richard Barnes, Deirdre Connolly |
| | Working Group: |
HPKE Publication, Kept Efficient (hpke) |
|
Updating key exchange and public-key encryption protocols to resist attack by quantum computers is a high priority given the possibility of "harvest now, decrypt later" attacks. Hybrid Public Key Encryption (HPKE) is a widely-used public key encryption scheme based on combining a Key Encapsulation Mechanism (KEM), a Key Derivation Function (KDF), and an Authenticated Encryption with Associated Data (AEAD) scheme. In this document, we define KEM algorithms for HPKE based on both post-quantum KEMs and hybrid constructions of post- quantum KEMs with traditional KEMs, as well as a KDF based on SHA-3 that is suitable for use with these KEMs. When used with these algorithms, HPKE is resilient with respect to attacks by a quantum computer. |
| | HTTP Problem Types for Digest Fields |
| |
|
This document specifies HTTP problem types that servers can use in responses to problems encountered while dealing with a request carrying integrity fields and integrity preference fields. Using an HTTP problem type, the server can provide machine-readable error details to aid debugging or error reporting. |
| | Resumable Uploads for HTTP |
| |
|
HTTP data transfers can encounter interruption due to reasons such as canceled requests or dropped connections. If the intended recipient can indicate how much of the data was received prior to interruption, a sender can resume data transfer at that point instead of attempting to transfer all of the data again. HTTP range requests support this concept of resumable downloads from server to client. This document describes a mechanism that supports resumable uploads from client to server using HTTP. |
| | Incremental Forwarding of HTTP Messages |
| |
|
This document specifies the "Incremental" HTTP header field, which instructs HTTP intermediaries to forward the HTTP message incrementally. |
| | HTTP Unencoded Digest |
| |
|
The Repr-Digest and Content-Digest integrity fields are subject to HTTP content coding considerations. There are some use cases that benefit from the unambiguous exchange of integrity digests of unencoded representation. The Unencoded-Digest and Want-Unencoded- Digest fields complement existing integrity fields for this purpose. This document updates the terms "Integrity fields" and "Integrity preference fields" defined in RFC 9530. |
| | Procedures for Handling Liaison Statements to and from the IETF |
| |
| | draft-iab-rfc4053bis-02.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Mirja Kuehlewind, Suresh Krishnan, Qin WU |
| | Working Group: |
Internet Architecture Board (iab) |
|
This document describes the procedures for generating and handling liaison statements between the IETF and other Standards Development Organizations (SDOs), so that the IETF can effectively collaborate with other organizations in the international standards community. |
| | Report from the IAB Workshop on IP Address Geolocation |
| |
|
The IAB Workshop on IP Address Geolocation (IP-GEO) was held from December 3-5, 2025, as a three-day virtual meeting. It covered the use cases and background on using IP addresses as indicators of geolocation, explored various problems and challenges that exist in that ecosystem, and discussed future directions and opportunities to improve or replace the current practices. |
| | Considerations For Maintaining Protocols Using Grease and Variability |
| |
|
Active use and maintenance of network protocols is an important way to ensure that protocols remain interoperable and extensible over time. Techniques such as intentionally exercising extension points with non-meaningful values (referred to as "grease") or adding variability to how protocol elements are used help generate this active use. Grease and variability are used across various protocols developed by the IETF. This document discusses considerations when designing and deploying grease and variability mechanisms, and provides advice for making them as effective as possible. |
| | BGP Flow-Spec Redirect-to-IP Action |
| |
|
Flow-spec is an extension to BGP that allows for the dissemination of traffic flow specification rules. This has many possible applications, but the primary one for many network operators is the distribution of traffic filtering actions for distributed denial of service (DDoS) mitigation. The flow-spec standard [RFC8955] defines a redirect-to-VRF action for policy-based forwarding. This mechanism can be difficult to use, particularly in networks without L3 VPN infrastructure. This draft defines a new redirect-to-IP flow-spec action that provides a simpler method of policy-based forwarding. The details of the action, including the IPv4 or IPv6 target address, are encoded in newly defined BGP extended communities. |
| | BGP Performance-aware Routing Mechanism |
| |
|
The current Border Gateway Protocol (BGP) specification does not incorporate network performance metrics, such as network latency, into its route selection process. This document outlines a performance-aware BGP routing mechanism that integrates network latency as a critical criterion for route selection. This innovative approach is particularly beneficial for server providers with a global presence, enabling them to offer low-latency network connectivity service as a value-added service to their customers. |
| | YANG Model for Border Gateway Protocol (BGP-4) |
| |
|
This document defines a YANG data model for configuring and managing BGP, including protocol, policy, and operational aspects, such as RIB, based on data center, carrier, and content provider operational requirements. |
| | Traffic Steering using BGP FlowSpec with SR Policy |
| |
|
BGP Flow Specification version 1 (FSv1), defined in [RFC8955], [RFC8956] and [RFC9117] 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 FSv1 to steer packets into an SR Policy. |
| | 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 Virtual Private Network (VPN) Prefix ORF. The VPN Prefix ORF mechanism is applicable when VPN routes from different Virtual Routing and Forwarding (VRF) instances are exchanged through a single shared Border Gateway Protocol (BGP) session.The purpose of VPN Prefix ORF mechanism is to control the overload of VPN routes based on RT. With this mechanism, the overload can be limited within the minimum range. |
| | Terminology for Constrained-Node Networks |
| |
|
The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in research and standardization work for constrained-node networks. This document obsoletes RFC 7228. |
| | Enhanced Encapsulating Security Payload (EESP) |
| |
| | draft-ietf-ipsecme-eesp-03.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Steffen Klassert, Antony Antony, Christian Hopps |
| | Working Group: |
IP Security Maintenance and Extensions (ipsecme) |
|
This document describes the Enhanced Encapsulating Security Payload (EESP) protocol, which builds on the existing IP Encapsulating Security Payload (ESP) protocol. It is designed to modernize and overcome limitations in the ESP protocol. EESP adds Session IDs (e.g., to support CPU pinning and QoS support based on the inner traffic flow), changes some previously mandatory fields to optional, and moves the ESP trailer into the EESP header. Additionally, EESP adds header options adapted from IPv6 to allow for future extension. New header options are defined which add a crypt- offset to allow for exposing inner flow information for middlebox use. |
| | IKEv2 negotiation for Enhanced Encapsulating Security Payload (EESP) |
| |
| | draft-ietf-ipsecme-eesp-ikev2-02.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Steffen Klassert, Antony Antony, Tobias Brunner, Valery Smyslov |
| | Working Group: |
IP Security Maintenance and Extensions (ipsecme) |
|
This document specifies how to negotiate the use of the Enhanced Encapsulating Security Payload (EESP) protocol using the Internet Key Exchange protocol version 2 (IKEv2). The EESP protocol, which is defined in [I-D.ietf-ipsecme-eesp], provides the same security services as Encapsulating Security Payload (ESP), but has richer functionality and provides better performance in specific circumstances. This document specifies negotiation of version 0 of EESP. |
| | JSON Proof Token and CBOR Proof Token |
| |
|
JSON Proof Token (JPT) is a compact, URL-safe, privacy-preserving representation of claims to be transferred between three parties. The claims in a JPT are encoded as base64url-encoded JSON objects that are used as the payloads of a JSON Web Proof (JWP) structure, enabling them to be digitally signed and selectively disclosed. JPTs also support reusability and unlinkability when using Zero-Knowledge Proofs (ZKPs). A CBOR-based representation of JPTs is also defined, called a CBOR Proof Token (CPT). It has the same properties as JPTs, but uses the JSON Web Proof (JWP) CBOR Serialization, rather than the JSON-based JWP Compact Serialization. |
| | JSON Web Proof |
| |
|
The JOSE set of standards established JSON-based container formats for Keys, Signatures, and Encryption. They also established IANA registries to enable the algorithms and representations used for them to be extended. Since those were created, newer cryptographic algorithms that support selective disclosure and unlinkability have matured and started seeing early market adoption. The COSE set of standards likewise does this for CBOR-based containers, focusing on the needs of environments which are better served using CBOR, such as constrained devices and networks. This document defines a new container format similar in purpose and design to JSON Web Signature (JWS) and COSE Signed Messages called a _JSON Web Proof (JWP)_. Unlike JWS, which integrity-protects only a single payload, JWP can integrity-protect multiple payloads in one message. It also specifies a new presentation form that supports selective disclosure of individual payloads, enables additional proof computation, and adds a Presentation Header to prevent replay. |
| | JSON Proof Algorithms |
| |
|
The JSON Proof Algorithms (JPA) specification registers cryptographic algorithms and identifiers to be used with the JSON Web Proof, JSON Web Key (JWK), and COSE specifications. It defines IANA registries for these identifiers. |
| | JOSE: Deprecate 'none' and 'RSA1_5' |
| |
|
This document updates [RFC7518] to deprecate the JWS algorithm "none" and the JWE algorithm "RSA1_5". These algorithms have known security weaknesses. It also updates the Review Instructions for Designated Experts to establish baseline security requirements that future algorithm registrations should meet. |
| | Lightweight Authorization using Ephemeral Diffie-Hellman Over COSE (ELA) |
| |
| | draft-ietf-lake-authz-07.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Goeran Selander, John Mattsson, Malisa Vucinic, Geovane Fedrecheski, Michael Richardson |
| | Working Group: |
Lightweight Authenticated Key Exchange (lake) |
|
Ephemeral Diffie-Hellman Over COSE (EDHOC) is a lightweight authenticated key exchange protocol intended for use in constrained scenarios. This document specifies Lightweight Authorization using EDHOC (ELA). The procedure allows authorizing enrollment of new devices using the extension point defined in EDHOC. ELA is applicable to zero-touch onboarding of new devices to a constrained network leveraging trust anchors installed at manufacture time. |
| | Implementation Considerations for Ephemeral Diffie-Hellman Over COSE (EDHOC) |
| |
|
This document provides considerations for guiding the implementation of the authenticated key exchange protocol Ephemeral Diffie-Hellman Over COSE (EDHOC). |
| | Coordinating the Use of Application Profiles for Ephemeral Diffie-Hellman Over COSE (EDHOC) |
| |
|
The lightweight authenticated key exchange protocol Ephemeral Diffie- Hellman Over COSE (EDHOC) requires certain parameters to be agreed out-of-band, in order to ensure its successful completion. To this end, application profiles specify the intended use of EDHOC to allow for the relevant processing and verifications to be made. In order to ensure the applicability of such parameters and information beyond transport- or setup-specific scenarios, this document defines a canonical, CBOR-based representation that can be used to describe, distribute, and store EDHOC application profiles. Furthermore, in order to facilitate interoperability between EDHOC implementations and support EDHOC extensibility for additional integrations, this document defines a number of means to coordinate the use of EDHOC application profiles. Finally, this document defines a set of well- known EDHOC application profiles. |
| | EDHOC Authenticated with Pre-Shared Keys (PSK) |
| |
| | draft-ietf-lake-edhoc-psk-07.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Elsa, Goeran Selander, John Mattsson, Rafael Marin-Lopez, Francisco Lopez |
| | Working Group: |
Lightweight Authenticated Key Exchange (lake) |
|
This document specifies a Pre-Shared Key (PSK) authentication method for the Ephemeral Diffie-Hellman Over COSE (EDHOC) key exchange protocol. The PSK method enhances computational efficiency while providing mutual authentication, ephemeral key exchange, identity protection, and quantum resistance. It is particularly suited for systems where nodes share a PSK provided out-of-band (external PSK) and enables efficient session resumption with less computational overhead when the PSK is provided from a previous EDHOC session (resumption PSK). This document details the PSK method flow, key derivation changes, message formatting, processing, and security considerations. |
| | Applying Generate Random Extensions And Sustain Extensibility (GREASE) to EDHOC Extensibility |
| |
|
This document applies the extensibility mechanism GREASE (Generate Random Extensions And Sustain Extensibility), which was pioneered for TLS, to the EDHOC ecosystem. It reserves a set of non-critical EAD labels and unusable cipher suites that may be included in messages to ensure peers correctly handle unknown values. |
| | Remote attestation over EDHOC |
| |
| | draft-ietf-lake-ra-04.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Yuxuan Song, Goeran Selander |
| | Working Group: |
Lightweight Authenticated Key Exchange (lake) |
|
This document specifies how to perform remote attestation as part of the lightweight authenticated Diffie-Hellman key exchange protocol EDHOC (Ephemeral Diffie-Hellman Over COSE), based on the Remote ATtestation procedureS (RATS) architecture. |
| | LISP YANG Model |
| |
| | draft-ietf-lisp-yang-24.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Vina Ermagan, Alberto Rodriguez-Natal, Florin Coras, Carl Moberg, Reshad Rahman, Albert Cabellos-Aparicio, Fabio Maino |
| | Working Group: |
Locator/ID Separation Protocol (lisp) |
|
This document describes a YANG data model to use with the Locator/ID Separation Protocol (LISP). This model can be used to configure and monitor the different control plane and data plane elements that enable a LISP network. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA) defined in [RFC8342]. |
| | Advertising Unreachable Links in OSPF |
| |
|
OSPF Router Link State Advertisements (LSAs) use fixed-format encodings that always include advertised links in the default SPF (Shortest Path First) computation. For non-default SPF computations, e.g., flexible algorithms as described in RFC 9350, advertised OSPF links are used in the default SPF computation even if this is not intended. In order to advertise these links and not use them in the base SPF calculation, the metric LSLinkInfinity (0xffff) is used to specify that the link is unreachable. MaxReachableLinkMetric (0xfffe) is defined to provide backward compatible reachability in specifications that previously specified advertisement of MaxLinkMetric (0xffff). This document updates RFC 5443, RFC 6987, and RFC 8770 with respect to the advertisement of MaxReachableLinkMetric (0xfffe) rather than MaxLinkMetric (0xffff). |
| | Interoperable Email Addresses for SMTPUTF8 |
| |
|
This document specifies rules for email addresses that are flexible enough to express the addresses typically used with SMTPUTF8, while avoiding elements that harm human-to-human interoperation. This is one of a pair of documents: this contains recommendations for what addresses humans should use, such that address provisioning systems can restrain themselves to addresses that email valdidators accept. (This set can also be described in other ways, including "simple to cut-and-paste" and "understandable by some community".) Its companion defines simpler rules, accepts more addresses, and is intended for software like MTAs. |
| | SMTPUTF8 address syntax |
| |
|
This document specifies rules for email addresses that are flexible enough to express the addresses typically used with SMTPUTF8, while avoiding confusing or risky elements. This is one of a pair of documents: This is simple to implement, contains only globally viable rules and is intended to be usable for software such an MTA. Its companion defines has more complex rules, takes regional usage into account and aims to allow only addresses that are readable and cut-and-pastable in some community. |
| | QUIC-Aware Proxying Using HTTP |
| |
| | draft-ietf-masque-quic-proxy-08.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Tommy Pauly, Eric Rosenberg, David Schinazi |
| | Working Group: |
Multiplexed Application Substrate over QUIC Encryption (masque) |
|
This document extends UDP Proxying over HTTP to add optimizations for proxied QUIC connections. Specifically, it allows a proxy to reuse UDP 4-tuples for multiple proxied connections, and adds a mode of proxying in which QUIC short header packets can be forwarded and transformed through a HTTP/3 proxy rather than being fully re- encapsulated and re-encrypted. |
| | More Instant Messaging Interoperability (MIMI) message content |
| |
|
This document describes content semantics common in Instant Messaging (IM) systems and describes a profile suitable for instant messaging interoperability of messages end-to-end encrypted inside the MLS (Message Layer Security) Protocol. |
| | The Messaging Layer Security (MLS) Extensions |
| |
|
The Messaging Layer Security (MLS) protocol is an asynchronous group authenticated key exchange protocol. MLS provides a number of capabilities to applications, as well as several extension points internal to the protocol. This document provides a consolidated application API, guidance for how the protocol's extension points should be used, and a few concrete examples of both core protocol extensions and uses of the application API. |
| | ML-KEM and Hybrid Cipher Suites for Messaging Layer Security |
| |
|
This document registers new cipher suites for Messaging Layer Security (MLS) based on "post-quantum" algorithms, which are intended to be resilient to attack by quantum computers. These cipher suites are constructed using the new Module-Lattice Key Encapsulation Mechanism (ML-KEM), optionally in combination with traditional elliptic curve KEMs, together with appropriate authenticated encryption, hash, and signature algorithms. |
| | MLS Virtual Clients |
| |
|
This document describes a method that allows multiple MLS clients to emulate a virtual MLS client. A virtual client allows multiple emulator clients to jointly participate in an MLS group under a single leaf. Depending on the design of the application, virtual clients can help hide metadata and improve performance. |
| | Messaging Layer Security (MLS) Targeted Messages |
| |
|
This document defines targeted messages for the Messaging Layer Security (MLS) protocol. A targeted message allows a member of an MLS group to send an encrypted and authenticated message to another member of the same group without creating a new group. The mechanism reuses Hybrid Public Key Encryption (HPKE) and the MLS key schedule to provide confidentiality, authentication, and binding to the group state. |
| | Media over QUIC Transport |
| |
|
This document defines the core behavior for Media over QUIC Transport (MOQT), a media transport protocol designed to operate over QUIC and WebTransport, which have similar functionality. MOQT allows a producer of media to publish data and have it consumed via subscription by a multiplicity of endpoints. It supports intermediate content distribution networks and is designed for high scale and low latency distribution. |
| | Privacy Pass Authentication for Media over QUIC (MoQ) |
| |
|
This document specifies the use of Privacy Pass architecture and issuance protocols for authorization in Media over QUIC (MoQ) transport protocol. It defines how Privacy Pass tokens can be integrated with MoQ's authorization framework to provide privacy- preserving authentication for subscriptions, fetches, publications, and relay operations while supporting fine-grained access control through prefix-based track namespace and track name matching rules. |
| | End-to-End Secure Objects for Media over QUIC Transport |
| |
|
This document specifies an end-to-end authenticated encryption scheme for application objects transmitted via Media over QUIC (MoQ) Transport. The scheme enables original publishers that share a symmetric key with end subscribers, to ensuring that MoQ relays are unable to decrypt object contents. Additionally, subscribers can verify the integrity and authenticity of received objects, confirming that the content has not been modified in transit. Additionally it allows MoQ parameters to be protected so the publisher can select if they are readable and/or modifiable by relays. |
| | 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. |
| | YANG Packages |
| |
|
This document defines YANG packages; a versioned organizational structure used to manage schema and conformance of YANG modules as a cohesive set instead of individually. |
| | Discovery of OSCORE Groups with the CoRE Resource Directory |
| |
|
Group communication over the Constrained Application Protocol (CoAP) can be secured by means of Group Object Security for Constrained RESTful Environments (Group OSCORE). At deployment time, devices may not know the exact security groups to join, the respective Group Manager, or other information required to perform the joining process. This document defines how a CoAP endpoint can use descriptions and links of resources registered at the CoRE Resource Directory to discover security groups and to acquire information for joining them through the respective Group Manager. A given security group can be used to protect communications in multiple application groups, which are separately announced in the Resource Directory as sets of endpoints sharing a pool of resources. This approach is consistent with, but not limited to, the joining of security groups based on the ACE framework for Authentication and Authorization in constrained environments. |
| | Verification of Routes Using Region Authorization |
| |
|
BGP routing security is becoming a major issue that affects the normal running of Internet services. Currently, there are many solutions, including ROA authentication and ASPA authentication, to prevent route source hijacking, path hijacking, and route leaking. However, on an actual network, large ISPs with multiple ASes can use carefully constructed routes to bypass ROA and ASPA authentication to attack the target network. This document defines an region-based authentication method for large ISPs with many ASes to prevent traffic hijacking within ISPs. |
| | ASPA Verification in the Presence of Regionalized AS-Relationships |
| |
|
This document proposes a method for ASPA verification in the Presence of Regionalized AS-Relationships. |
| | ISP Dual Queue Networking Deployment Observations |
| |
|
The IETF's Transport and Services Working Group (TSVWG) has finalized experimental RFCs for Low Latency, Low Loss, Scalable Throughput (L4S) and new Non-Queue-Building (NQB) per hop behavior. These documents describe a new architecture and protocol for deploying low latency networking. Since deployment decisions are left to implementers, this document explores some of the implications of those decisions and makes suggestions that can help drive adoption and acceptance of L4S and NQB based on observations from the world's first large scale deployment. |
| | Secret Key Agreement for DNS: The TKEY Resource Record |
| |
|
RFC 8945 provides efficient authentication of Domain Name System (DNS) protocol messages using shared secret keys and the Transaction Signature (TSIG) resource record (RR). However, it provides no mechanism for setting up such keys other than by configuration. This document specifies the Transaction Key (TKEY) RR that can be used to establish shared secret keys between a DNS resolver and server. This document obsoletes RFC 2930. |
| | EVPN Inter-Domain Option-B Solution |
| |
|
An EVPN Inter-Domain interconnect solution is required when two or more sites of the same Ethernet Virtual Private Network (EVPN) are connected to different IGP domains or Autonomous Systems (AS) and need to communicate. The Inter-Domain Option-B connectivity model is one of the most popular solutions for this type of EVPN connectivity. While several documents address specific aspects of this interconnect approach, none provide a comprehensive overview of how Inter-Domain Option-B connectivity affects EVPN procedures. This document examines the behavior of EVPN procedures in an Inter-Domain Option-B network and proposes solutions to the identified issues. |
| | Realization of Composite IETF Network Slices |
| |
|
A network slice offers connectivity services to a network slice customer with specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) over a common underlay network. RFC 9543 describes a framework for network slices built in networks that use IETF technologies. As part of that framework, the Network Resource Partition (NRP) is introduced as a collection of network resources that are allocated from the underlay network to carry a specific set of network slice service traffic and meet specific SLOs and SLEs. In some network scenarios, network slices using IETF technologies may span multiple network domains, and they may be composed hierarchically, which means a network slice itself may be further sliced. In the context of 5G, a 5G end-to-end network slice consists of three different types of network technology segments: Radio Access Network (RAN), Transport Network (TN) and Core Network (CN). The transport segments of the 5G end-to-end network slice can be provided using network slices described in RFC 9543. This document first describes the possible use cases of composite network slices built in networks that use IETF network technologies, then it provides considerations about the realization of composite network slices. For the multi-domain network slices, an Inter-Domain Network Resource Partition Identifier (Inter-domain NRP ID) may be introduced. For hierarchical network slices, the structure of the NRP ID is discussed. And for the interaction between IETF network slices with 5G network slices, the identifiers of the 5G network slices may be introduced into IETF networks. These network slice- related identifiers may be used in the data plane, control plane and management plane of the network for the instantiation and management of composite network slices. This document also describes the management considerations of composite network slices. |
| | The MASQUE Architecture |
| |
|
MASQUE (Multiplexed Application Substrate over QUIC Encryption) is a set of protocols and extensions to HTTP that allow proxying all kinds of Internet traffic over HTTP. This document describes the architectural principles behind MASQUE, and the properties that MASQUE can provide. |
| | EVPN Anycast Multi-Homing |
| |
|
The current Ethernet Virtual Private Network (EVPN) all-active multi- homing procedures in Network Virtualization Over Layer-3 (NVO3) networks provide the required Split Horizon filtering, Designated Forwarder Election and Aliasing functions that the network needs in order to handle the traffic to and from the multi-homed CE in an efficient way. In particular, the Aliasing function supports load balancing of unicast traffic from remote Network Virtualization Edge (NVE) devices to NVEs that are multi-homed to the same CE, regardless of whether the CE’s MAC/IP information has been learned on all those NVEs. This document introduces an optional enhancement to the EVPN multi-homing Aliasing function, referred to as EVPN Anycast Multi- homing. This optimization is specific to EVPN deployments over NVO3 tunnels (i.e., IP-based tunnels) and may offer benefits in typical data center designs, which are discussed herein. |
| | IGP Flexible Algorithm with Link Packet Loss |
| |
|
This document proposes extensions to the IGP Flexible Algorithm. It introduces a mechanism to exclude links exceeding a specified packet loss rate threshold during path computation. The solution leverages existing link packet loss advertisement via IS-IS and OSPF, and defines new constraints for Flex-Algorithm path calculation. |
| | Proposed Update to BGP Link-State SPF NLRI Selection Rules |
| |
|
For network scenarios such as Massively Scaled Data Centers (MSDCs), BGP is extended for Link-State (LS) distribution and the Shortest Path First (SPF) algorithm based calculation. BGP-LS-SPF leverages the mechanisms of both BGP protocol and BGP-LS protocol extensions, with new selection rules defined for BGP-LS-SPF NLRI. This document proposes some updates to the BGP-LS-SPF NLRI selection rules, so as to improve the route updates and convergence, while consistent SPF computation result can still be achieved. This document updates the NLRI selection rules in I-D.ietf-lsvr-bgp-spf. |
| | BGP over TLS/TCP |
| |
|
This document specifies the use of TLS over TCP to support BGP. |
| | Application of Explicit Measurement Techniques for QUIC Troubleshooting |
| |
| | draft-mdt-quic-explicit-measurements-04.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Alexandre Ferrieux, Igor Lubashev, Giuseppe Fioccola, Lars Ihlar, Fabio Bulgarella, Mauro Cociglio, Massimo Nilo, Isabelle Hamchaoui |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a protocol that can be used by QUIC endpoints to signal packet loss in a way that can be used by network devices to measure and locate the source of the loss. Discussion of this work is encouraged to happen on the QUIC IETF mailing list quic@ietf.org (mailto:quic@ietf.org) or on the GitHub repository which contains the draft: https://github.com/igorlord/ draft-mdt-quic-explicit-measurements (https://github.com/igorlord/ draft-mdt-quic-explicit-measurements). |
| | X-Wing: general-purpose hybrid post-quantum KEM |
| |
|
This memo defines X-Wing, a general-purpose post-quantum/traditional hybrid key encapsulation mechanism (PQ/T KEM) built on X25519 and ML- KEM-768. |
| | Stand-in Tags for YANG-CBOR |
| |
|
YANG (RFC 7950) is a data modeling language used to model configuration data, state data, parameters and results of Remote Procedure Call (RPC) operations or actions, and notifications. YANG-CBOR (RFC 9254) defines encoding rules for YANG in the Concise Binary Object Representation (CBOR) (RFC 8949). While the overall structure of YANG-CBOR is encoded in an efficient, binary format, YANG itself has its roots in XML and therefore traditionally encodes some information such as date/times and IP addresses/prefixes in a verbose text form. This document defines how to use existing CBOR tags for this kind of information in YANG-CBOR as a "stand-in" for the text-based information that would be found in the original form of YANG-CBOR. |
| | Self-Clocked Rate Adaptation for Multimedia |
| |
|
This memo describes Self-Clocked Rate Adaptation for Multimedia version 2 (SCReAMv2), an update to SCReAM congestion control for media streams such as RTP [RFC3550]. SCReAMv2 includes several algorithm simplifications and adds support for L4S. The algorithm supports handling of multiple media streams, typical use cases are streaming for remote control, AR and 3D VR goggles. This specification obsoletes RFC 8298. |
| | 5QI to DiffServ DSCP Mapping Example for Enforcement of 5G End-to-End Network Slice QoS |
| |
|
5G End-to-End Network Slice QoS is an essential aspect of network slicing, as described in both IETF drafts and the 3GPP specifications. Network slicing allows for the creation of multiple logical networks on top of a shared physical infrastructure, tailored to support specific use cases or services. The primary goal of QoS in network slicing is to ensure that the specific performance requirements of each slice are met, including latency, reliability, and throughput. |
| | Ways to convey the Ratchet Tree in Messaging Layer Security |
| |
|
The Messaging Layer Security (MLS) protocol needs to share its ratchet_tree object to welcome new clients into a group and in external joins. While the protocol only defines a mechanism for sharing the entire tree, most implementations use various optimizations to avoid sending this structure repeatedly in large groups. This document describes a way to convey these improvements in a standardized way and to convey the parts of a GroupInfo object that are not visible to an intermediary server. |
| | Security Considerations for Computing-Aware Traffic Steering |
| |
|
Computing-Aware Traffic Steering (CATS) inherits potential security vulnerabilities from the network, computing nodes as well as workflows of CATS. This document describes various threats and security concerns related to CATS and existing approaches to solve these threats. |
| | Arm's Confidential Compute Architecture Reference Attestation Token |
| |
|
The Arm Confidential Compute Architecture (CCA) is series of hardware and software innovations that enhance Arm’s support for Confidential Computing for large, compute-intensive workloads. Devices that implement CCA can produce attestation tokens as described in this memo, which are the basis for trustworthiness assessment of the Confidential Compute environment. This document specifies the CCA attestation token structure and semantics. The CCA attestation token is a profile of the Entity Attestation Token (EAT). This specification describes what claims are used in an attestation token generated by CCA compliant systems, how these claims get serialized to the wire, and how they are cryptographically protected. This informational document is published as an independent submission to improve interoperability with Arm's architecture. It is not a standard nor a product of the IETF. |
| | IGP Reverse Prefix Metric |
| |
|
This document defines a method for calculating reverse paths by advertising reverse prefix costs. This method aims to solve the problem of strict RPF (Reverse Path Forwarding) check failure caused by mismatched bidirectional path costs in multi-area IGP scenarios. |
| | Source Address Validation Enhanced by Network Controller |
| |
|
Many newly proposed Source Address Validation (SAV) mechanisms such as IGP-based and BGP-based SAVNET solutions take a distributed manner to generate SAV rules, but they are faced with accuracy and managability challenges in incremental/partial deployment scenarios. RFC 8704 stipulates the use of Adj-RIBs-In to construct AS sets and prefix sets.A centralized approach is essential: collecting Pre- Policy Adj-RIBs-In from ASBRs, performing necessary filtering, and distributing SAV rules via a central controller. This document proposes a network controller-based solution for enhancing SAVNET capability in intra-domain and inter-domain networks, which supports accurate verification, automated configuration, threat analysis, traceability and visualization. |
| | HTTP Resource Versioning |
| |
|
HTTP resources change over time. Each change to a resource creates a new "version" of its state. HTTP systems often need a way to identify, read, write, navigate, and/or merge these versions, in order to implement cache consistency, create history archives, settle race conditions, request incremental updates to resources, interpret incremental updates to versions, or implement distributed collaborative editing algorithms. This document analyzes existing methods of versioning in HTTP, highlights limitations, and specifies a more general versioning approach that can enable new use-cases for HTTP. An upgrade path for legacy intermediaries is provided. |
| | YANG Data Model for Power-Group Aware TE Topology |
| |
|
This document discusses the notion of a Power-Group construct as an attribute of a Traffic Engineered (TE) Link and defines a YANG data model for representing a Power-Group aware TE topology. |
| | Same Entity Set Support for EPP |
| |
|
This document defines an EPP extension allowing clients to learn about and manipulate a set of objects in a shared central repository that are necessarily tied to the same entity (typically domain objects whose names are equivalent in a registry-defined way and are tied to a single registrant). The extension supports multiple registries with a shared definition of equivalence using a shared central repository. |
| | Using BMP over QUIC connection |
| |
| | draft-liu-grow-bmp-over-quic-06.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Yisong Liu, Changwang Lin, Thomas Graf, Paolo Lucente, Mukul Srivastava |
| | Working Group: |
Individual Submissions (none) |
|
The BGP Monitoring Protocol (BMP) provides a convenient interface for obtaining route views by monitoring BGP sessions. BMP operates over TCP and is unidirectional (from client to server). QUIC provides multiple simultaneous streams to carry data in one direction, enabling much better efficiency and performance for both peers, in particular unidirectional streams can provide reverse data protection for the sender. QUIC also provides shorter handshake and includes TLS. This document describes how to use BMP over the QUIC transport protocol, named BMPoQUIC. |
| | Hybrid-Function-Chain (HFC) Framework |
| |
|
With the maturity of cloud native application development, applications can be decomposed into finer grained atomic services. On the other hand, as a distributed computing paradigm, fine grained micro-services could be deployed and implemented in a distributive way among edges to make computing, storage and run-time processing capabilities as close to users as possible to provide satisfied QoE. Under the circumstances analyzed, a Hybrid-Function-Chain (HFC) framework is proposed in this draft, aiming to wisely allocate and schedule resources and services in order to provide consistent end- to-end service provisioning. |
| | Automated Certificate Management Environment (ACME) Extension for Public Key Challenges |
| |
|
This document implements automated certificate provisioning through "public key identity challenge + private key ownership verification" by introducing the pk-01 challenge to the ACME protocol [RFC8555]. It serves as a valuable complement to existing external resource verification challenge types such as DNS/HTTP, extending the ACME protocol's applicability beyond Web-PKI to other scenarios. This enables automated certificate issuance for devices and accounts. The core design objective of this document's extension to ACME's pk-01 challenge is to introduce a trusted identity provider (IdP) during the digital certificate application process. This provider verifies the certificate applicant's identity and obtains the corresponding identity public key. It enables the ACME server to use public key identity authentication protocols (e.g., WebAuthn and Opaque [RFC9807]) to verify whether the genuine application behind the ACME client controls the public key. It ensures strong consistency between the public key used during the challenge phase and the public key ultimately used to sign the certificate, preventing tampering with the public key during the CSR submission phase. This enhances the security of the digital certificate issuance process. Similar related work can be found in [RFC9883]. This document also defines an optional process extension that allows removal of the CSR under the pk-01 challenge, enabling the ACME server to issue a certificate directly after successful public key verification. This document provides an example of practical application at the end, illustrating the integration of the OPAQUE [RFC9807], strong asymmetric password authenticated key exchange (saPAKE) protocol with the pk-01 challenge. |
| | A syntax for the RADIUS Connect-Info attribute used in Wi-Fi networks |
| |
|
This document describes a syntax for the Connect-Info attribute used with the RADIUS protocol, enabling RADIUS clients to provide RADIUS servers information pertaining to a user's connection with an IEEE 802.11 wireless network. |
| | LSP State Reporting Extensions in Path Computation Element Communication Protocol (PCEP) |
| |
|
The Path Computation Element Communication Protocol (PCEP) is defined in multiple RFCs for enabling communication between Path Computation Elements (PCEs) and Path Computation Clients (PCCs). Although PCEP defines various Label Switched Path (LSP) identifiers, attributes, and constraints, there are operational attributes available on the PCC that can enhance path computation and improve the debugging experience, which are not currently supported in PCEP. This document defines extensions to PCEP to include: * Support for explicit or dynamic path types * Mechanisms to mark LSPs as eligible for use as transit LSPs |
| | JSON for Restful Provisioning Protocol (RPP) |
| |
|
This document defines the rules for representing the RESTful Provisioning Protocol (RPP) data objects, as defined in [I-D.kowalik-rpp-data-objects], using the JavaScript Object Notation (JSON) Data Interchange Format [RFC8259]. It specifies how RPP primitive types, common data types, component objects, resource objects, and associations are mapped to JSON and JSON Schema, and provides normative JSON Schema definitions and worked examples for domain name, contact, and host data objects. |
| | A YANG Data Model for Passive Network Inventory |
| |
|
This document presents a YANG data model for tracking and managing passive network inventory. The model enhances the base model outlined in [I-D.draft-ietf-ivy-network-inventory-yang] and is intended for use in the northbound interface of a domain controller as defined in [RFC8453]. |
| | Path Energy Traffic Ratio API (PETRA) |
| |
| | draft-petra-green-api-03.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Alberto Rodriguez-Natal, Luis Contreras, Marisol Amador, Jan Lindblad, Adrian Sanchez |
| | Working Group: |
Individual Submissions (none) |
|
This document describes an API to query a network regarding its Energy Traffic Ratio for a given path. |
| | Signalling Key State Via DNS EDNS(0) OPT |
| |
|
This document introduces the KeyState EDNS(0) option code, to enable the exchange of SIG(0) key state information between DNS entities via the DNS protocol. The KeyState option allows DNS clients and servers to include key state data in both queries and responses, facilitating mutual awareness of SIG(0) key status between child and parent zones. This mechanism addresses the challenges of maintaining synchronization of SIG(0) keys used for securing DNS UPDATE messages, thereby enhancing the efficiency and reliability of DNS operations that require coordinated key management. This document proposes such a mechanism. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-berra-dnsop-opt-transaction-state (https://github.com/johanix/draft-berra-dnsop-transaction-state-00). The most recent working version of the document, open issues, etc, should all be available there. The authors (gratefully) accept pull requests. |
| | Problem Statement for High Performance Wide Area Networks |
| |
|
High Performance Wide Area Network (HP-WAN) is designed for many applications such as scientific research, academia, education and other data-intensive applications which demand high-speed data transmission over WANs, and it needs to provide high-throughput transmission within a completion time. This document outlines the problems for HP-WANs. |
| | Path Computation Element Communication Protocol (PCEP) extensions for SRv6 Policy SID List Optimization |
| |
|
In some use cases, an SRv6 policy's SID list ends with the policy endpoint's node SID, and the traffic steered (over policy) already ensures that it is taken to the policy endpoint. In such cases, the SID list can be optimized by excluding the endpoint Node SID when installing the policy. This draft specifies a PCEP extension to indicate whether the endpoint's node SID needs to be included or excluded when installing the SRv6 Policy. |
| | SRv6 Policy SID List Optimization Advertisement |
| |
|
In some use cases, an SRv6 policy's SID list ends with the policy endpoint's node SID, and the traffic steered (over policy) already ensures that it is taken to the policy endpoint. In such cases, the SID list can be optimized by excluding the endpoint Node SID when installing the policy. This draft specifies a BGP-LS extension to indicate whether the endpoint's node SID is included or excluded in installing SID list(s) of the Candidate Path (CP) of an SRv6 policy. |
| | An Architecture for IP in Deep Space |
| |
|
The IP protocol stacks used on Earth's Internet are typically configured based on assumptions of short delays and mostly uninterrupted communications. This document describes an architecture of the IP protocol stack tailored for its use in deep space. It involves buffering IP packets in IP forwarders facing intermittent links and adjusting transport protocol configurations and application protocol timers. This architecture applies to the Moon, Mars, and general interplanetary networking. |
| | IPv6 Network Deployment Monitoring and Analysis |
| |
|
This document addresses key operational challenges in large-scale IPv6 deployment and proposes an architecture for IPv6 deployment monitoring and analysis. It describes an architectural approach and comprehensive metrics to provide end-to-end visibility across network infrastructure, cloud services, edge computing, and end-user domains. |
| | Clarifications to the DNS Ranking Data |
| |
|
This document obsoletes Section 5.4.1 (Ranking data) of RFC 2181, and specifies directives whereby the source of the data determines for what purposes it may be used. |
| | Bidirectional Access Control in the Authentication and Authorization for Constrained Environments (ACE) Framework |
| |
|
This document updates the Authentication and Authorization for Constrained Environments (ACE) framework, for which it defines a method to enforce bidirectional access control by means of a single access token. Therefore, this document updates RFC 9200. |
| | KEM-based Authentication for IKEv2 with Post-quantum Security |
| |
|
This draft specifies a new authentication mechanism, called KEM (Key Encapsulation Mechanism) -based authentication, for the Internet Key Exchange Protocol Version 2 (IKEv2). This is motivated by the fact that some post-quantum KEMs (like ML-KEM) are more efficient than post-quantum signature algorithms (like ML-DSA). |
| | Computing Energy Consumption Path in Segment Routing Networks |
| |
|
This document elaborates on the method for calculating energy consumption paths in Segment Routing (SR) networks, aiming to evaluate and optimize traffic-related metrics on network paths, including energy consumption and carbon emissions. |
| | Multipath Traffic Engineering |
| |
| | draft-kompella-teas-mpte-02.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Kireeti Kompella, Luay Jalil, Mazen Khaddam, Andy Smith |
| | Working Group: |
Individual Submissions (none) |
|
Shortest path routing offers an easy-to-understand, easy-to-implement method of establishing loop-free connectivity in a network, but offers few other features. Equal-cost multipath (ECMP), a simple extension, uses multiple equal-cost paths between any two points in a network: at any node in a path (really, Directed Acyclic Graph), traffic can be (typically equally) load-balanced among the next hops. ECMP is easy to add on to shortest path routing, and offers a few more features, such as resiliency and load distribution, but the feature set is still quite limited. Traffic Engineering (TE), on the other hand, offers a very rich toolkit for managing traffic flows and the paths they take in a network. A TE network can have link attributes such as bandwidth, colors, risk groups and alternate metrics. A TE path can use these attributes to include or avoid certain links, increase path diversity, manage bandwidth reservations, improve service experience, and offer protection paths. However, TE typically doesn't offer multipathing as the tunnels used to implement TE usually take a single path. This memo proposes multipath traffic-engineering (MPTE), combining the best of ECMP and TE. The multipathing proposed here need not be strictly equal-cost, nor the load balancing equally weighted to each next hop. Moreover, the desired destination may be reachable via multiple egresses. The proposal includes a protocol for signaling MPTE paths using various types of tunnels, some of which are better suited to multipathing. |
| | HTTP Message Signatures Directory |
| |
|
This document describes a method for clients using [HTTP-MESSAGE-SIGNATURES] to advertise their signing keys. It defines a key directory format based on JWKS as defined in Section 5 of [JWK], as well as new HTTP Method Context to allow for in-band key discovery. |
| | HTTP Message Signatures for automated traffic Architecture |
| |
|
This document describes an architecture for identifying automated traffic using [HTTP-MESSAGE-SIGNATURES]. The goal is to allow automated HTTP clients to cryptographically sign outbound requests, allowing HTTP servers to verify their identity with confidence. |
| | Announce Existence of Parent CDS/CSYNC Scanner |
| |
|
In DNS operations, automated scanners are commonly employed by the operator of a parent zone to detect the presence of specific records, such as CDS or CSYNC, in child zones, indicating a desire for delegation updates. However, the presence and periodicity of these scanners are typically implicit and undocumented, leading to inefficiencies and uncertainties. This document proposes an extension to the semantics of the DSYNC resource record, as defined in [RFC9859], allowing parent zones to explicitly signal the presence and scanning interval of such automated scanners. This enhancement aims to improve transparency and coordination between child and parent zones. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-berra-dnsop-announce-scanner (https://github.com/johanix/draft-berra-dnsop-announce-scanner). The most recent working version of the document, open issues, etc, should all be available there. The authors (gratefully) accept pull requests. |
| | Enforcement-Action HTTP Header Field |
| |
|
This document defines the Enforcement-Action HTTP response header field. The field provides a minimal, interoperable mechanism for signaling advisory enforcement coordination between cooperating components operating within a defined administrative or policy trust boundary. The header conveys a single action token and optional parameters without modifying HTTP status code semantics or representation meaning. The field is designed to be safely ignored by recipients that do not recognize it and to operate over existing HTTP deployments without changes to transport protocols. This specification defines the syntax, semantics, processing rules, and IANA registration for the header field. |
| | Detecting Outdated Proxy Configuration |
| |
|
This document defines a lightweight mechanism that allows explicit HTTP proxies to inform clients when their proxy configuration, such as a Proxy Auto-Configuration (PAC) file or Provisioning Domain (PvD) proxy configuration, is outdated. Clients signal to the proxy the configuration URL and the timestamp of when it was last fetched. In response, the proxy may indicate that a newer version of the configuration is available. This enables clients to refresh their configuration without relying on frequent polling or short expiration intervals. The mechanism is designed to be compatible with existing proxy deployment models and supports both PAC-based and PvD-based configurations. |
| | RESTful Provisioning Protocol (RPP) |
| |
|
This document describes the endpoints for the RESTful Provisioning Protocol, used for the provisioning and management of objects in a shared database. |
| | SRv6 for Deterministic Path Placement in AI Backends |
| |
| | draft-filsfils-srv6ops-srv6-ai-backend-03.txt |
| | Date: |
02/03/2026 |
| | 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. |
| | Audio,Video,and Image Metadata extensions for the More Instant Messaging Interoperability (MIMI) Content format |
| |
|
The More Instant Messaging Interoperability (MIMI) content format is a container for rich content, which can reference image, video, and audio files. This document describes metadata for these files to allow for more pleasant rendering. |
| | A Message Status format for the More Instant Messaging Interoperability (MIMI) content format |
| |
|
The More Instant Messaging Interoperability (MIMI) content format describes a message format for instant messaging. This specification defines a concise, efficient format for communicating status of messages sent using MIMI content. |
| | Including Pending Proposals in External Commits in the Messaging Layer Security protocol |
| |
|
The Messaging Layer Security (MLS) protocol allows authorized non- members to join a group via external commits, however it disallows most pending proposals in those commits, which causes unfortunate side effects. This document describes an MLS extension to include pending proposal in external commits when the extension is present in a group. |
| | Signaling Solution for HP-WAN |
| |
|
This document proposes a technical solution for the host-network collaboration signaling to enhance the congestion control in High- Performance Wide Area Networks (HP-WAN). It also describes the RSVP extensions as an instantiation of this signaling solution. |
| | KEM-based Authentication for EDHOC |
| |
| | draft-pocero-authkem-edhoc-02.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Lidia Fraile, Christos Koulamas, Apostolos Fournaris, Evangelos Haleplidis |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies extensions to the Ephemeral Diffie-Hellman over COSE (EDHOC) protocol to provide resistance against quantum computer adversaries by incorporating Post-Quantum Cryptography (PQC) mechanisms for both key exchange and authentication. It defines a Key Encapsulation Mechanism (KEM)-based authentication method to enable signature-free post-quantum authentication when PQC KEMs, such as NIST-standardized ML-KEM, are used. The document further describes scenarios where both parties employ KEM-based authentication, as well as cases where authentication methods are combined, with one party using KEM-based authentication and the other relying on a PQC signature scheme. |
| | KEM-based Authentication for EDHOC in Initiator-Known Responder (IKR) Scenarios |
| |
|
This document specifies a more efficient variant of a Key Encapsulation Mechanism (KEM)-based authentication method for the Ephemeral Diffie-Hellman Over COSE (EDHOC) lightweight protocol, designed for the specific scenario in which the Initiator has prior knowledge of the Responder’s credentials, a case commonly found in constrained environments. Improving upon the approach described in KEM-based Authentication for EDHOC, this method uses only a mandatory three-message handshake to enable signature-free post-quantum authentication when PQC KEMs, such as the NIST-standardized ML-KEM, are employed, while still providing mutual authentication, forward secrecy, and a degree of identity protection. |
| | Operations,Administration and Maintenance (OAM) for Network Resource Partition (NRP) in MPLS Network |
| |
|
A Network Resource Partition (NRP) represents a subset of network resources and associated policies within the underlay network. This document describes the implementation of the Operations, Administration, and Maintenance (OAM) mechanism for NRPs in MPLS networks. By extending existing OAM mechanisms such as ping, traceroute, the proposed solution enables comprehensive NRP support in MPLS networks. |
| | Stand-in Key Identifier and Encrypted Partial IV in the Constrained Application Protocol (CoAP) OSCORE Option |
| |
|
The security protocol Object Security for Constrained RESTful Environments (OSCORE) provides end-to-end protection of messages exchanged with the Constrained Application Protocol (CoAP). Messages protected with OSCORE include a CoAP OSCORE Option, where the "Partial IV" field specifies the sequence number value used by the message sender and the "kid" field specifies the identifier of the message sender. In order to reduce the information exposed on the wire that can be used for fingerprinting traffic and for tracking endpoints, this document defines a lightweight add-on method that obfuscates certain fields of the OSCORE Option, by encrypting the "Partial IV" field and overwriting the "kid" field with a stand-in identifier. Therefore, it updates RFC 8613. With minor adaptations, the defined method is applicable also to the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE) that protects group communication for CoAP. |
| | Energy-aware Routing Using Flex-Algo in Segment Routing |
| |
|
This document proposes enhancements to the Segment Routing (SR) Flexible Algorithm (Flex-Algo) framework by integrating power consumption metrics into routing decisions. It introduces metrics encompassing both node-level and link-level energy consumption attributes and proposes dynamic energy-aware path computation. By incorporating these metrics alongside traditional routing parameters, the enhanced Flex-Algo framework can enable networks to optimize routing paths for energy efficiency, and then leverage on advances router capabilities to further reduce operational costs as well as supporting sustainability objectives. |
| | Workload Identifier Origin Hint for TLS ClientHello |
| |
|
This document defines a TLS extension that allows clients to indicate one or more workload identifier origins in the ClientHello message. Each origin consists of a URI scheme and trust domain component, representing the administrative domain and identifier namespace in which the client operates. These identifier origins serve as hints to enable the server to determine whether client authentication is required and which policies or trust anchors should apply. This mechanism improves efficiency in mutual TLS deployments while minimising the exposure of sensitive identifier information. To protect confidentiality, this extension can be used in conjunction with Encrypted Client Hello (ECH). |
| | Extensions to TLS FATT Process |
| |
|
This document applies only to non-trivial extensions of TLS, which require formal analysis. It proposes the authors provide a threat model and informal security goals in the Security Considerations section, as well as motivation and a protocol diagram in the draft. We also briefly present a few pain points of the team doing the formal analysis which -- we believe -- require refining the process: * Contacting FATT * Understanding the opposing goals * No response from some authors * Slots at meeting * Provide protection against FATT-bypass by other TLS-related WGs * Process not being followed |
| | MSD Consideration in Path Computation Element Communication Protocol (PCEP) |
| |
|
Segment Routing (SR) allows a node to steer a packet flow along any path. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. An SR Policy can be instantiated SR-MPLS and SRv6 data planes. Maximum SID Depth (MSD) is first introduced for SR-MPLS to indicate the number of SIDs supported by a node or a link on a node. This concept is further extended for SRv6 with more types of MSD. MSD may become one of the limitations that need to be considered when computing an SR-TE path for PCE. This draft specifies some MSD considerations PCE needs to take into account when computing an SR-TE path. |
| | Consideration for IP-Based Satellite Routing Protocol |
| |
|
This document examines the advantages, challenges, and current research on IP-based satellite routing, and provides some considerations. |
| | A YANG Data Model for Reporting Utilization Scores in ISAC |
| |
|
This document defines a YANG data model to report an ISAC Utilization Score (US) in Integrated Sensing and Communication (ISAC) systems. The US is an abstract, normalized score (0..100) that summarizes the relative resource cost of executing a sensing operation on a device. The model supports a mandatory overall US and optional explanatory component impact scores (compute, memory, energy, storage, latency). The model also supports optional metadata (e.g., timestamp, aggregation window, and scoring method identification) describing how a reported score was derived. This revision aligns terminology and leaf names to reduce ambiguity between normalized impact scores and raw resource telemetry, removes per-measurement-related objects to keep the model focused on an overall score, and specifies a companion augmentation module (Path 1) that attaches ISAC utilization telemetry to a GREEN Energy Object (as defined by the GREEN Power and Energy YANG Module) for correlation with power/energy telemetry. |
| | Multipath Traffic Engineering Capabilities |
| |
|
Multipath Traffic Engineering (MPTE) combines two approaches to traffic management: equal-cost multipath and constraint-based traffic engineering, offering a powerful new way to engineer networks. To avail of this, a node (possibly an ingress of a MPTE tunnel, or a path computation agent) must have information about the topology, link and node characteristics of a network so that it can compute the components of the MPTE tunnel. One important (node) characteristic is whether a given node supports MPTE, i.e., whether it can participate in the provisioning and maintenance of the tunnel. This memo shows how this information can be distributed in the IGP via Link State Routing TE Capabilities. |
| | RSVP-TE Extensions for Multipath Traffic Engineered Directed Acyclic Graph Tunnels |
| |
| | draft-kbr-teas-mptersvp-03.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Kireeti Kompella, Vishnu Beeram, Chandra Ramachandran |
| | Working Group: |
Individual Submissions (none) |
|
A Multipath Traffic Engineered Directed Acyclic Graph (MPTED) tunnel is a Traffic Engineering (TE) construct that facilitates weighted load balancing of unicast traffic across a constrained set of paths optimized for a specific objective. This document describes the provisioning of an MPTED Tunnel in a TE network using RSVP-TE. |
| | A YANG Data Model for Multipath Traffic Engineering Directed Acyclic Graph (MPTED) Tunnels and Junctions |
| |
|
This document defines a YANG data model for representing, retrieving, and manipulating Multipath Traffic Engineering Directed Acyclic Graph (MPTED) Tunnels and Junctions. The model includes two YANG modules, one for managing MPTED Tunnels on an MPTED tunnel originator node and the other for managing MPTED Junctions on an MPTED junction node. |
| | OAuth 2.0 Resource Parameter in Access Token Response |
| |
|
This specification defines a new parameter resource to be returned in OAuth 2.0 access token responses. It enables clients to confirm that the issued token is valid for the intended resource. This mitigates ambiguity and certain classes of security vulnerabilities such as resource mix-up attacks, particularly in systems that use the Resource Indicators for OAuth 2.0 specification [RFC8707]. |
| | Taxonomy of Composite Attesters |
| |
|
This document clarifies and extends the meaning of Composite Attester from RFC9334. A system of annotated diagram components is defined as a small language to explain the different ways that components can interact to form composites. These diagram components are then used to define a few popular classes of composites. |
| | SD Agent: Selective Disclosure for Agent Discovery and Identity Management |
| |
|
This document defines how Selective Disclosure for JWTs (SD-JWT) integrates with Agent-to-Agent (A2A) systems to provide privacy- preserving agent discovery and cryptographically verifiable identity management. It specifies the SD-Card format - an SD-JWT encoding of Agent Cards that enables selective disclosure of agent capabilities, contact information, and operational metadata while maintaining cryptographic integrity and preventing correlation across different interaction contexts. |
| | DomainKeys Identified Mail Signatures v2 (DKIM2) |
| |
|
DomainKeys Identified Mail v2 (DKIM2) permits a person, role, or organization that owns a signing domain to document that it has handled an email message by associating their domain with the message. This is achieved by providing a hash value that has been calculated on the current contents of the message and then applying a cryptographic signature that covers the hash values and other details about the transmission of the message. Verification is performed by querying an entry within the signing domain's DNS space to retrieve an appropriate public key. As a message is transferred from author to recipient systems that alter the body or header fields will provide details of their changes and calculate new hash values. Further signatures will be added to provide a validatable "chain". This permits validators to identify the nature of changes made by intermediaries and apply a reputation to the systems that made changed. DKIM2 also allows recipients to detect when messages have been unexpectedly "replayed" and will ensure that Delivery Status Notifications are only sent to entities that were involved in the transmission of a message. |
| | vCon Lawful Basis |
| |
|
This document defines a lawful basis extension for Virtualized Conversations (vCon) that provides standardized mechanisms for recording, verifying, and managing the lawful basis for processing data within conversation containers. The lawful basis extension addresses privacy compliance challenges through structured attachment metadata, including the specific lawful basis being asserted, temporal validity periods where applicable, and cryptographic proof mechanisms. The extension is designed as a Compatible vCon extension that introduces lawful basis management capabilities without altering existing vCon semantics. It defines a "lawful_basis" attachment type with structured records for each of the six lawful bases defined in regulations like GDPR, including consent, contract, legal obligation, vital interests, public task, and legitimate interests. Key features include automated lawful basis detection during conversation processing, auditable records with cryptographic proofs, granular purpose-based permissions for all lawful bases, documented justifications for other lawful bases, and integration with privacy regulations including GDPR, CCPA, and HIPAA. |
| | Proactive Flow Control Point Detection in WAN |
| |
|
[I-D.ietf-rtgwg-net-notif-ps] establishes usecases and requirements for fast notification delivery for network events (e.g., failure, congestion or state change) in modern network applications. This document proposes a proactive detection mechanism that enables the flow control notification message generating downstream node to be aware of the nearest upstream node capable of processing the message . The mechanism operates in the data plane, uses probe packets that follow the same path as data traffic, and maintains state only where needed. While proposed for flow control, the same mechanism may support other fast notification use cases that require distributed recipient node discovery. |
| | A more efficient FramedContentTBS structure in Messsaging Layer Security (MLS) |
| |
|
Most MLS signatures are signed over the relatively large GroupContext structure. This document defines a way to safely sign using a pre- hashed version of the GroupContext structure for better efficiency. |
| | BGP best path next-hop selection enhancements |
| |
|
BGP [RFC4271] has originally been designed to carry IPv4 routing information over the Internet. IP routing being "hop-by-hop" in nature, [RFC4271] defines the NEXT_HOP attribute which purpose is to carry the address of the next router to send the IP packet to. In BGP, the next-hop may not be a directly connected router, hence, when evaluating paths, a BGP speaker must determine if the next-hop is resolvable and, if so, determine the internal cost to reach it. The incremental use of tunneling technologies to carry traffic between routers (e.g.: GRE, MPLS, SR-MPLS, SRv6...) may violate the assumption that the address carried in the NEXT_HOP attribute is representative of the actual forwarding next-hop. These technologies decouple the BGP control-plane's view of the next-hop from the data- plane's actual forwarding endpoint. This document describes the problems that arise from this decoupling. These problems include sub-optimal path selection, incorrect resolvability tracking of the forwarding path leading to traffic drop or misrouting, and others. This document proposes some modification of BGP path selection procedures to accommodate these use cases. |
| | Network Delivery Time Control |
| |
| | draft-ageneau-ccwg-ndtc-01.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Paul-Louis Ageneau, Grenville Armitage, Scott Danahy |
| | Working Group: |
Individual Submissions (none) |
|
This document describes Network Delivery Time Control (NDTC), a rate adaptation algorithm for real-time video streaming suited for interactive applications like cloud gaming. NDTC leverages the Frame Dithering Available Capacity Estimation (FDACE) heuristic, which estimates available path capacity without inducing congestion. The algorithm dynamically adjusts frame sizes and transmission times to ensure timely delivery, while also responding to conventional congestion signals. |
| | IPv6 Prefix Assignment to end-users |
| |
|
This document describes different alternatives and best current practices for assignment of IPv6 prefixes for end-user broadband networks, including considerations about point-to-point links, their size, numbering choices, pool choices, customer prefix assignment size and persistance of those assignments. |
| | Private External Message extensions for Messaging Layer Security (MLS) |
| |
|
MLS groups that use private handshakes lose member privacy when sending external proposals. This document addresses this shortcoming by encrypting external proposals using an HPKE public key derived from the epoch secret. It also provides a mechanism to share this key and protect it from tampering by a malicious intermediary. |
| | OAuth 2.0 Delegated Authorization |
| |
|
Delegated authorization enables a client to delegate a subset of its granted privileges to a subordinate access token (also known as a delegated access token). This mechanism allows the client to securely delegate authorization to a delegated party while maintaining fine-grained control over delegated permissions. |
| | Addressing Recommendations for SRv6 NEXT-CSID |
| |
|
This document describes SRv6 addressing for NEXT-CSID locator format. It introduces concepts of Blocks, Sets, and Node IDs, and explains how summarization boundaries and flexible algorithm support can be implemented for both small and large networks. |
| | RESTful Provisioning Protocol (RPP) Data Objects |
| |
|
This document defines data objects for the RESTful Provisioning Protocol (RPP) and sets up IANA RPP Data Object Registry to describe and catalogue them. Specifically, it details the logical structure, constraints, and protocol operations (including their inputs, outputs and business logic) for foundational resources: domain names, contacts, and hosts. In accordance with the RPP architecture [I-D.kowalik-rpp-architecture], these definitions focus entirely on the semantics, remaining independent of any specific data representation or media type (e.g., JSON or XML). |
| | Unified Optical Networks and AI Computing Orchestration (UONACO) Problem Statement,Use Cases and Requirements |
| |
|
Distributed artificial intelligence (AI) computing is increasingly deployed across geographically dispersed AI data centers (AIDCs) to meet the scale and performance demands of modern AI workloads. In such environments, the efficiency of distributed training, inference, and remote service access depends critically on tight coordination between optical transport networks and compute orchestration systems. However, today's infrastructure operates with isolated control planes: optical networks lack awareness of dynamic compute requirements, while compute schedulers have no visibility into real- time network conditions such as latency, bandwidth, or congestion. This decoupling leads to suboptimal resource utilization, degraded job performance, and inefficient scaling. This document presents the problem statement, outlines three representative use cases—distributed AI training, distributed AI inference, and remote AI service access—and specifies the requirements for Unified Optical Networks and AI Computing Orchestration (UONACO). The goal is to enable bidirectional awareness, joint resource abstraction, and synchronized control across the compute-optical boundary, thereby supporting intent- driven, end-to-end provisioning of AI services over wide-area optical infrastructures. |
| | A Control Framework for Unified Optical Networks and AI Computing Orchestration (UONACO) |
| |
|
This document presents the control framework for Unified Optical Networks and AI Computing Orchestration (UONACO). Specifically, it defines the AI computing service model over wide-area networks, outlines the UONACO control architecture, identifies a set of UONACO components and interfaces, and describes their interactions. |
| | A code to describe satellite constellations |
| |
|
When considering a satellite constellation forming a non-terrestrial network, the characteristics of this constellation heavily influences the network topology it forms. To improve the analysis of such non- terrestrial networks across various tools developed by the network community, this document proposes a notation to describe common constellation patterns. In addition, this document may serve as an introduction to satellite constellations for IETF participants. |
| | Customer-Facing Relay (CFR): Enhancing Source Privacy in Encrypted Transport and CDN Scenarios |
| |
|
Encrypted Client Hello (ECH) improves destination privacy by encrypting the Server Name Indication in TLS, but the customer source identity-- typically the IP address and network metadata--remains observable to intermediaries such as CDNs, hosting providers, and recursive resolvers. This document introduces the _Customer-Facing Relay (CFR)_, a lightweight, transport-agnostic relay operated by access providers to decouple customer identity from encrypted destinations. By forwarding opaque encrypted payloads (TCP or UDP) without terminating TLS or QUIC, a CFR complements ECH encryption to strengthen source privacy and reduce metadata correlation. |
| | Authenticated ECH Config Distribution and Rotation |
| |
|
Encrypted ClientHello (ECH) requires clients to have the server's ECH configuration before connecting. Currently, when ECH fails, servers can send updated configurations but clients cannot authenticate them unless the server has a valid certificate for the public name, limiting deployment flexibility. This document specifies a new mechanism for authenticating ECH configurations. Servers include additional information in their initial ECH configurations, which enables clients to authenticate updated configurations without relying on a valid certificate for the public name. |
| | Fine-Grained Flow Control Backpressure Mechanism for Wide Area Networks |
| |
|
This document specifies a fine-grained flow control backpressure mechanism for Wide Area Networks (WANs). Leveraging data-plane congestion detection and notification, it enables millisecond-level congestion response. The mechanism enhances Layer 2 PFC by extending network protocols (e.g., ICMPv6) for congestion backpressure messaging in WANs, and leverages network slicing isolation to provide fine-grained flow control at tenant or task granularity. It addresses the limitations of traditional flow control mechanisms in WAN environments through fast and precise backpressure, and supports multi-hop propagation of congestion notifications along the forwarding path. |
| | Encoding rules of YANG instance-identifier in the Concise Binary Object Representation (CBOR) |
| |
|
The YANG-CBOR document [RFC9254] defines rules for representing YANG- modeled data [RFC7950] in CBOR [RFC8949]. The YANG-CBOR defines rules for all built-in types, such as int64, leafref, and instance- identifier data type. However it fails to address some cases of the instance-identifier, specifically those pointing to keyless list entries or leaf-list entries. This documents updates [RFC9254] to make the rules complete. |
| | Extending ICMP for Multi-path |
| |
|
This document extends the ICMP message with a Multi-path Interface Information object to carry the egress interface, next hop, and the corresponding ARP or ND information of each multi-path interface of nodes along the route. |
| | Updates to Locally Served DNS Zones and IP Special-Purpose Address Space Registries |
| |
|
RFC 6063, "Locally Served DNS Zones", defines two IANA registries called "IPv4 Locally-Served DNS Zone" and "IPv6 Locally-Served DNS Zone" registries. This document changes the registration policy for that registry from "IETF Review" to "Expert Review". Also, this document updates IP Special-Purpose Address Space registries to indicate whether an IP address block is eligible to be in Locally-Served DNS Zones. Eligible entries will be automatically added to the Locally-Served DNS Zones. This document updates RFC 6063 and RFC 6890. |
| | Extended Key Usage and Mutual TLS in EPP |
| |
|
This document describes the state of the Mutual Transport Layer Security (mTLS) client authentication mechanism in the Extensible Provisioning Protocol (EPP) with respect to a recent change in the client certificates published by some Certificate Authorities (CAs). The issue is described and options are presented to address the operational impact of the change. |
| | Export of Energy Consumption Information in IPFIX |
| |
|
This document introduces new IPFIX IEs for exporting energy consumption information of physical entities in a network device. New Information Elements are defined to report instantaneous and average energy consumption information at device, line-card, and port granularity. |
| | Power and Energy YANG Module |
| |
|
This document defines the YANG data model for Power and Energy monitoring of devices within or connected to communication networks. |
| | DNS-Native AI Agent Naming and Resolution |
| |
|
This document specifies DNS-Native Agent Naming and Resolution (DN- ANR) for AI agents. DN-ANR has three goals: (1) use domain names (FQDNs) as stable Agent Identifiers, (2) resolve Agent Identifiers to verifiable endpoints and supported protocol/version information with a cryptographic integrity chain (DNSSEC preferred), and (3) provide only minimal and stable pointer/index capabilities that can be referenced by upper-layer discovery systems. DN-ANR intentionally does not carry heavy semantic metadata in DNS, and does not define semantic discovery, ranking, or routing decisions. |
| | HMTFTP: HKDF-Derived TFTP with Optional AEAD Protection |
| |
|
HMTFTP is a lightweight UDP file transfer protocol derived from TFTP that adds TLV-based negotiation and an optional AEAD protection mode for DATA payloads. This document requests IANA actions: assignment of a service name and UDP port, and creation of registries for TLV Types, OpCodes, and Ciphersuites. |
| | Minimizing ANY-Query Responses at Recursive Resolvers |
| |
|
The "ANY" query in DNS is a meta-query intended to match multiple resource record types associated with a given domain name, and can elicit responses that are significantly larger than those generated by single-type queries. While RFC 8482 defines a mechanism for authoritative servers to minimize ANY responses, a recursive resolver may still generate an ANY query response directly from its cache, thereby bypassing the authoritative side's ANY query minimization strategy. This document provides supplementary guidance for recursive resolvers on processing ANY queries to mitigate potential operational and security issues. |
| | HTTP Signature-Key Header |
| |
|
This document defines the Signature-Key HTTP header field for distributing public keys used to verify HTTP Message Signatures as defined in RFC 9421. Four initial key distribution schemes are defined: pseudonymous inline keys (hwk), identified signers with JWKS URI discovery (jwks_uri), X.509 certificate chains (x509), and JWT- based delegation (jwt). These schemes enable flexible trust models ranging from privacy-preserving pseudonymous verification to PKI- based identity chains and horizontally-scalable delegated authentication. |
| | Domain Name System (DNS) Public Key Based Request and Transaction Authentication (SIGZERO,SIG(0)) |
| |
|
This document specifies use of the SIGZERO and SIG(0) Domain Name System (DNS) Resource Records (RRs) to provide public key based authentication of DNS requests and transactions. This document obsoletes RFC 2931. |
| | Problem Space Analysis of AI Agent Protocols in IETF |
| |
|
This document aims to identify IETF-relevant problem space and potential areas and working groups, exploring internal and external coordination for AI Agent protocols by analyzing open source efforts. It may serve as a target for CATALIST BoF discussions. |
| | The YANG 2.0 Data Modeling Language |
| |
|
YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). |
| | DNS for AI Discovery |
| |
|
This document specifies a method for utilizing the Domain Name System (DNS) to facilitate scalable and interoperable discovery between AI agents. The proposed mechanism, referred to as "DNS AI agent Discovery (DNS-AID)", defines a structured DNS namespace and record usage model to support metadata exchange and capability advertisement. This will allow organisations to publish information about their AI agents on the Internet or internal networks using a well-known label within the organisation's own DNS namespace. This document does not define how the published agent information is accessed or the exact structure of that information. Instead, it specifies a mechanism for indicating which access protocol should be used and what format the agent information will be provided in. This document proposes no change to the structure of DNS messages, and no new operation codes, response codes, resource record types, or any other new DNS protocol values. |
| | Delegated Agent Authorization Protocol (DAAP) |
| |
|
Artificial intelligence (AI) agents increasingly take autonomous actions -- submitting forms, initiating payments, and sending communications -- on behalf of human users across third-party services. This document defines the Delegated Agent Authorization Protocol (DAAP), an open, model-neutral, framework-agnostic protocol that specifies: cryptographic agent identity using Decentralized Identifiers (DIDs); a human-consent-based grant authorization flow modelled on OAuth 2.0; a signed JSON Web Token (JWT) grant token format with agent-specific claims; a revocation model with online verification; a hash-chained append-only audit trail; a policy engine for automated authorization decisions; a multi-agent delegation model with cascade revocation; budget controls for spending limits; real- time event streaming; a credential vault for secure secret storage; and external policy backend integration with OPA and Cedar. DAAP fills a gap unaddressed by existing OAuth 2.0 extensions: verifying that a specific human authorized a specific AI agent to perform a specific action, revoking that authorization in real time, and producing a tamper-evident record of what the agent did. |
| | Resource Indicator Response Parameter for OAuth 2.0 |
| |
|
This document defines the resource parameter for OAuth 2.0 access token responses, enabling an authorization server to indicate to the client the resource(s) which an issued access token is for. It updates "Resource Indicators for OAuth 2.0" (RFC 8707). |
| | Path Computation Element Communication Protocol(PCEP) IPv6 Segment Routing Extensions for Inter-Layer Network Programing |
| |
|
In some networks, the cross-layer planning and optimization is considered more efficient than independent planning and operation of the layer-3 and the underlying networks in terms of resource utilization and SLA assurance. This document extends the PCEP SRv6 for inter-layer network, which enable the PCE to instantiate candidate paths comprising both the layer-3 network segments and underlay network segments. |
| | OAuth 2.0 Rich Authorization Requests for AS-Attested User Certificates |
| |
|
This document defines an extension to the OAuth 2.0 Rich Authorization Requests (RAR) framework. It introduces a mechanism that allows a Client, such as an autonomous AI Agent, to request an Authorization Server (AS) to include an AS-attested Resource Owner public key certificate within, or bound to, an Access Token. This mechanism enables the Resource Server (RS) to securely obtain the Resource Owner's trusted public key, which can then be used to verify application-layer delegation evidence (e.g., Verifiable Credentials) signed by the Resource Owner. |
| | RSVP Extensions for Rate-based Resource Quota |
| |
|
This document proposes RSVP extensions for rate-based resource quota to enable dynamic resource reservation, achieving effective rate control in multi-flow data transmission. |
| | A Framework of Intelligence Delivery Network (IDN) for Deep Learning Inference |
| |
| | draft-li-cats-idn-00.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Qing Li, Hanling Wang, Yong Jiang, Mingwei Xu |
| | Working Group: |
Individual Submissions (none) |
|
The rapid growth of deep learning inference workloads is placing increasing pressure on existing Internet and computing infrastructures. To support latency-aware, privacy-enhanced, and scalable inference services, this document introduces the concept of Intelligence Delivery Network (IDN), in which models with different inference capabilities are deployed across geographically distributed servers and selected to serve inference requests. This document describes the challenges motivating such networks, presents an architectural framework, and defines a common vocabulary for discussing the systems. This document does not specify protocol details, which are left to future documents. |
| | Requirements for Provider Edge in IPv6-only Underlay Networks |
| |
|
This document defines functional, protocol, and operational requirements for Provider Edge (PE) devices operating in a multi- domain network environment where the underlay is exclusively based on IPv6. These requirements ensure consistent service delivery, interoperability, and efficient operations across autonomous domains while supporting IPv4-as-a-Service (IPv4aaS). |
| | Problem Statement and Requirements for Dynamic Multi-agent Secured Collaboration (DMSC) |
| |
|
Current LLM-based AI agent systems require each agent to implement communication capabilities (service discovery, encryption) and collaboration logic (e.g., task delegation decisions), leading to code bloat, security risks, and inefficient resource usage in cloud- native and hybrid-cloud deployments. This fragmentation impedes scalable multi-agent application development, especially in multi- tenant scenarios where inconsistent security policies and cross- domain connectivity barriers arise. This document analyzes these challenges and proposes requirements for a Dynamic Multi-agent Secured Collaboration (DMSC) infrastructure. DMSC leverages a centralized gateway layer to offload secured communication, cross- domain connectivity, multi-tenant policy enforcement, and dynamic collaboration assistance - enabling developers to focus solely on agent core functionality while ensuring consistent security, interoperability, and operational efficiency across heterogeneous environments. |
| | IntelliNode: In-Network Intelligent Scheduling Extensions for CATS |
| |
|
This document introduces IntelliNode, an in-network intelligent scheduling mechanism built upon the Computing-Aware Traffic Steering (CATS) framework. Modern large-scale AI training and inference heavily rely on distributed heterogeneous clusters (GPU/CPU/FPGA). However, existing networks lack awareness of tensor semantics, training phases, and heterogeneous computing capabilities, leading to high communication latency, low resource utilization, and pipeline stalls. IntelliNode shifts away from the traditional passive scheduling paradigms that rely on probes and controllers. By bypassing traditional paths and integrating FPGAs alongside programmable Switch ASICs, it constructs a rapid data-plane closed loop of "Perception- Inference-Decision-Execution". This architecture performs feature extraction at line rate, leverages lightweight prediction models to infer short-term network behavior, and drives real-time heuristic scheduling decisions (e.g., path selection, tensor slicing, and compute matching). This document defines the four core functional layers and extension signaling that support this architecture, laying the foundation for an AI-native, scalable distributed computing network. |
| | Semantic-Driven Traffic Shaping Contract for AI Networks |
| |
|
This document defines a "Semantic-Driven Shaping Contract". Traditional network protocols treat AI training and inference traffic as opaque byte streams, leading to highly inefficient scheduling. This contract allows applications or distributed training frameworks to explicitly pass "minimum necessary semantics" to the underlying network. In exchange, the network commits to executing fine-grained, differentiated forwarding and resource allocation actions for tensor flows with diverse semantics, based on predefined rules and global real-time states. This model significantly improves overall resource utilization and task completion times in heterogeneous computing networks, cross-domain intelligent computing centers, and integrated training-inference scenarios. |
| | Fewer signatures in MLS |
| |
|
This draft specifies modified versions of MLS KeyPackage messages, as well as MLS PublicMessages and PrivateMessages holding Commits or Update Proposals that require one less signature than their original counterparts. |
| | Routing Considerations in Agentic Network |
| |
|
As the development of the AI technology, an AI Agent would be able to do some tasks as an assistant to human beings. During the task process, the Agent may need to connect to other Agents with different skills relative to the task. The Agent to Agent communication is a new kind of traffic for Internet, and some new requirements for networking are proposed. This document describes some routing considerations in the agentic network, especially for the cross- domain scenarios, in which the agentic network works as an overlay network above the IP network. |
| | An Open,Decentralized,and Scalable Framework for Large Language Model Inference |
| |
| | draft-wang-cats-odsi-00.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Hanling Wang, Qing Li, Yong Jiang, Mingwei Xu |
| | Working Group: |
Individual Submissions (none) |
|
Large Language Model (LLM) inference is increasingly deployed as a networked service, yet existing deployments rely primarily on centralized infrastructure and trusted operators. Such designs limit openness, concentrate resource ownership, and constrain scalability to the capacity of individual providers. At the same time, LLM inference introduces execution characteristics (e.g., strict sequential dependencies, large intermediate activations, and tight latency requirements) that are not well supported by existing network, transport, or coordination mechanisms in open environments. This document specifies an open, decentralized, and scalable framework for executing LLM inference across independently operated and mutually untrusted participants. The framework treats inference as a distributed, layer-wise execution process subject to explicit deadlines, rather than as a monolithic computation or best-effort service. It combines layer-aware activation transport and routing, decentralized coordination among heterogeneous compute resources, and security mechanisms that provide accountability and correctness without assuming trusted execution. This document focuses on the architectural framework, design rationale, problem definition, challenges, and solution space of the Open, Decentralized, and Scalable Inference framework (ODSI). It does not specify concrete wire protocols, message formats, or protocol state machines. Such protocol-level specifications are to be defined in separate documents that build upon the framework described herein. |
| | Flow-Level Precision Congestion Control for SRv6 Networks |
| |
|
This document defines a flow-level precision congestion control mechanism for SRv6 networks. The mechanism specifies new congestion notification message formats that enable per-flow congestion information delivery and hop-by-hop backpressure control. Compared to traditional Priority-based Flow Control (PFC) which operates at the queue level, this mechanism provides finer-grained congestion control suitable for Wide-Area Network (WAN) environments, mitigating head-of-line blocking, congestion spreading, and deadlock issues. The document also describes interoperability models with traditional IEEE 802.1Qbb PFC. |
| | Capabilities and Future Requirements of IPv6 for the Internet of Agents (IoA) |
| |
|
In the coming years, the accelerating proliferation of agentic AI is anticipated to drive the number of intelligent agents to reach the scale of hundreds of billions. IPv6, with vast address space, native end-to-end connectivity and rich built-in functionalities, serves as the critical infrastructure underpinning the development of the Internet of Agents (IoA). This draft systematically analyzes the foundational capabilities that IPv6 can provide for the IoA at the current stage, and further explores the evolutionary requirements that the IoA imposes on the future IPv6 development. |
| | IP Fast Reroute for AI/ML Fabrics |
| |
|
This document describes the requirements and mechanisms for achieving sub-100 microsecond convergence in Artificial Intelligence (AI) Data Center (DC) fabrics and Data Center Interconnect (DCI) environments. It explores the limitations of current IP Fast Reroute (RFC 5714) capabilities, such as ECMP, LFA, and TI-LFA, particularly in the context of large-scale, multi-tier Clos topologies and BGP-only fabrics. The draft highlights the requirements for hardware- accelerated network notification mechanisms and congestion-aware remote protection strategies to address the stringent performance demands of AI workloads. |
| | Problem Statement for Network Resilience |
| |
|
This document defines the problem space and analyzes the limitations of current network architectures when dealing with complex, cascading, and unanticipated failures. |
| | Efficient Remote Protection |
| |
|
This document specifies Efficient Remote Protection (ERP), a mechanism for IP Fast Reroute (IP-FRR) that utilizes network notifications to activate pre-computed backup paths at nodes multiple hops upstream of a failure. ERP addresses scenarios where local protection mechanisms, such as Loop-Free Alternates (LFA) or Topology-Independent LFA (TI-LFA), result in suboptimal paths, specifically traffic hairpinning. By activating protection at strategically selected upstream nodes rather than at the node immediately adjacent to the failure, ERP preserves routing optimality and prevents bandwidth waste. ERP applies to both complete link/node failures and performance degradations such as congestion or reduced link capacity. This makes ERP particularly beneficial in networks with high link utilization, such as AI data centers and Data Center Interconnect (DCI) networks. |
| | Coupling ECN Marking Thresholds with Dynamic Buffer Allocation |
| |
|
Explicit Congestion Notification (ECN) marking thresholds are typically configured statically. In modern network devices that employ dynamic buffer allocation -- where the maximum buffer available to a queue fluctuates dynamically based on the number of active queues and the remaining shared buffer pool -- a static ECN threshold can frequently become misaligned with the actual instantaneous buffering capacity. This misalignment can lead to pathological behaviors: either premature marking (which underutilizes available buffers and throttles throughput) or late marking (which provides no advance warning before tail drop occurs). This document describes an operational framework and a deterministic reference algorithm for dynamically coupling the ECN marking threshold with the dynamic buffer allocation limit. By maintaining an adaptive relationship through configurable parameters, this mechanism ensures robust congestion signaling across varying load conditions without requiring complex external machine-learning models or per-flow tracking. |
| | YANG Data Model for End-to-End Internet Traffic Operational Statistics |
| |
|
This document defines a YANG data model for end-to-end (E2E) Internet traffic operational statistics, supporting cross-domain correlation and network performance analysis. |
| | Hybrid Energy Saving Mechanism for Transport Network |
| |
|
This document continues the transport network energy saving that harmonizes device-level autonomy with network-wide coordination. By implementing control at hybrid both the device and network controller coordination, it enables dynamic, SLA-aware, and multi-layer energy optimization. |
| | Alternate marking usage for loss location in per-packet load balancing networks |
| |
|
Many per-packet load balancing schemes have been proposed to mitigate network load imbalances. However, due to the randomness of packet paths, loss location is challenging in per-packet load balancing networks. An efficient solution is to leverage the alternate packet marking technique. This draft analyzes the usage and requirements of alternate packet marking for packet loss detection and location in per-packet load balancing networks. |
| | Consistency-Aware Multipath Transport (CAMP) toward Interactive Multimodal LLM-Based Systems |
| |
|
With the prosperity of generative large language models (LLMs), interactive LLM-based services, such as digital humans, have imposed new stringent requirements on low latency and high multimodal consistency. Traditional interactive LLM-based systems typically transmit multimodal content over a single network path, thereby failing to exploit the advantages offered by multipath networks. Even when multipath transport mechanisms are adopted, single-stream encapsulation does not enable differentiated management of heterogeneous modalities. However, naively separating modalities into multiple streams further introduces inter-modal arrival inconsistency. To address these challenges, this document specifies CAMP, a consistency-aware multipath transport design over the Multipath QUIC (MPQUIC) protocol. First, CAMP defines a three-stream separation encapsulation format to support modality-differentiated transmission. Second, it incorporates a transport-layer consistency- aware multipath scheduler to reduce inter-modal arrival time deviation across network paths. Third, it specifies a client-side application-layer alignment mechanism that operates in coordination with the transport scheduler. To the best of our knowledge, this is the first specification to address multipath-enabled multimodal consistency guarantees for interactive LLM-based systems. |
| | Datapath Processing Architecture for In-Band Congestion Signaling (IBCS) |
| |
|
In-band congestion signaling protocols, such as Congestion Signaling (CSIG) and High Precision Congestion Control (HPCC++), require intermediate Network Elements (NEs) to actively parse scalar congestion metrics from packet headers, evaluate them against local link states, and conditionally rewrite these fields before transmission. To ensure end-to-end algorithmic consistency and avoid unintended interactions with routing topologies (e.g., packet reordering), the datapath of these NEs must adhere to a standardized logical processing model. This document defines the normative datapath processing architecture for Network Elements participating in In-Band Congestion Signaling (IBCS). By establishing abstract topological roles (Edge vs. Transit NEs) and standardizing the "Compare-and-Replace" operational paradigm, this specification abstracts the signal update logic from hardware-specific pipelines. It guarantees strict orthogonality between congestion signaling and Equal-Cost Multi-Path (ECMP) routing invariants, supporting diverse congestion metrics across multi-vendor deployments. |
| | Definition of Service Intent in Autonomic Networks |
| |
|
While ANIMA Intent enables goal-oriented control within an Autonomic Domain, emerging services (e.g., AI inference) require a common, interoperable representation for expressing service-level objectives and constraints that span network, compute, and storage resources, rather than connection-centric descriptions. This document defines Service Intent for Autonomic Networks by specifying a structured semantic model and a concise format with identification, scope, versioning, and lifecycle semantics. |
| | JSContact: Converting from and to vCard |
| |
|
This document defines how to convert contact information between the JSContact and vCard data formats. It defines conversion rules for every JSContact and vCard element registered at IANA at the time of publication. It also defines new JSContact properties as well as vCard properties and parameters, to support converting arbitrary or unknown JSContact and vCard elements. This document obsoletes RFC 9555 and updates its definitions for JSContact version "2.0". Note This note is to be removed before publishing as an RFC. Differences from RFC 9555 are documented in Appendix B. |
| | YANG Datastore Telemetry (YANG Push version 2) |
| |
| | draft-wilton-netconf-yang-push-2-00.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Robert Wilton, Holger Keller, Benoit Claise, Ebben Aries, James Cumming, Thomas Graf |
| | Working Group: |
Individual Submissions (none) |
|
YANG Push version 2 is a YANG datastore telemetry solution, as an alternative lightweight specification to the Subscribed Notifications and YANG Push solution, specifically optimized for the efficient observability of operational data. |
| | Timing Regimes in Quantum Networks and their Physical Underpinnings |
| |
|
Entangling quantum networks build on new physical mechanisms to distribute quantum entanglement among a set of nodes over a set of links. To design a complete network protocol stack with proper division of responsibilities into layers, hardware and protocol engineers must share an understanding of those physical mechanisms and use a common vocabulary. This document bridges the abstract concepts described in RFC 9340 and the underlying physics to engineering concerns such as timing constraints on arrival of photons and exchange of supporting classical messages. The equations presented here will serve as reference points for architectural decisions in future documents, allowing future documents to deal directly in code without complex mathematics. Application-layer developers will not need the low-level physics presented here. |
| | Agentic Network Architecture and Protocol for Supporting Agent Interconnection Communication and Multi-level Inference |
| |
|
With the advent of the era of AI large models and intelligent agents, more and more scenarios about agent interconnection have emerged, such as collaboration among multiple agents within a household, intelligent robots cooperating to complete pipeline tasks in different operations of the industrial Internet, drone groups, intelligent vehicle networking, etc. These scenarios not only require low latency and high bandwidth, but also demand efficient information exchange and cross-domain coordination and scheduling capabilities in complex collaborative tasks. Therefore, new orchestration and management technologies and frameworks are needed in existing networks to address this. The interconnection of different agents also brings about an emergence of inference, with a large number of inference requests being processed from the mobile phone side to the cloud. In order to improve inference efficiency, in a cloud-edge-end multi-layer inference architecture, large models and agents at different levels cooperate to complete tasks, resulting in a complex intelligent agent interconnection network. Gateways and routers serve as forwarding entries on the network road highways, responsible for building communication channels for the agents spread throughout the network, which requiring function upgrades to support the continuously evolving inference service in the future. |
| | The Autonomic Deployment Mechanism of Service Intent in Autonomic Networks |
| |
|
This document defines a generic service intent deployment mechanism. It enables automated negotiation and coordination of heterogeneous resources. The mechanism uses RM ASAs and the Generic Autonomic Signaling Protocol (GRASP) for dynamic interactions and resource exchanges. It specifies a complete workflow covering intent reception, parsing, responder selection, negotiation, solution integration, resource confirmation, and dynamic adjustment. It employs standardized message formats, a negotiation state machine, and convergence logic to jointly optimize multiple resources and ensure end-to-end service level objectives. Its design features good scalability and fault tolerance, making it suitable for automated orchestration and lifecycle management in intent-driven networks. |
| | Agentic AI Use Cases |
| |
| | draft-scrm-aiproto-usecases-02.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Roland Schott, Julien Maisonneuve, Luis Contreras, Jordi Ros-Giralt |
| | Working Group: |
Individual Submissions (none) |
|
Agentic AI systems rely on large language models to plan and execute multi-step tasks by interacting with tools and collaborating with other agents, creating new demands on Internet protocols for interoperability, scalability, and safe operation across administrative domains. This document inventories representative Agentic AI use cases and captures the protocol-relevant requirements they imply, with the goal of helping the IETF determine appropriate standardization scope and perform gap analysis against emerging proposals. The use cases are written to expose concrete needs such as long-lived and multi-modal interactions, delegation and coordination patterns, and security/privacy hooks that have protocol implications. Through use case analysis, the document also aims to help readers understand how agent-to-agent and agent-to-tool protocols (e.g., [A2A] and [MCP]), and potential IETF-standardized evolutions thereof, could be layered over existing IETF protocol substrates and how the resulting work could be mapped to appropriate IETF working groups. |
| | In-Network Inference Protocol |
| |
|
This document specifies the In-Network Inference Protocol (INIP), a lightweight protocol designed specifically for implementing high- speed in-network inference in data center internal networks. INIP utilizes data plane devices (such as switches, DPUs, and SmartNICs) to perform lightweight inference tasks while ensuring that core network forwarding functions are not affected. The protocol operates based on the IPv4 protocol and adopts a fixed, lightweight packet format. INIP adopts a two-tier architecture of "centralized control plane adaptation and scheduling, and minimal data plane execution". The control plane stores all inference models, deploys model rules to data plane devices using a CDN-like scheduling method, and assumes the responsibility of degraded fallback inference; the data plane performs packet parsing and match action table-based inference. This document details INIP's core logic, packet format, data plane device constraints, model expression specifications, control plane responsibilities, CDN-like scheduling mechanism, dynamic model popularity replacement, and overall execution process. |
| | A YANG Data Model for Microwave Radio Link |
| |
| | draft-ybam-ccamp-rfc8561bis-00.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Scott Mansfield, Jonas Ahlberg, Min Ye, Daniela Spreafico, Danilo Pala |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a YANG data model for control and management of radio link interfaces and their connectivity to packet (typically Ethernet) interfaces in a microwave/millimeter wave node. The data nodes for management of the interface protection functionality is broken out into a separate and generic YANG data model in order to make it available for other interface types as well. This document obsoletes RFC 8561. |
| | Requirements and Gap Analysis of Multicast in AI Data Centers |
| |
|
Multicast has the potential to be applied in Artificial Intelligence Data Centers (AIDCs) to improve the efficiency of point-to-multipoint data transmission during large language model training and inference. This document identifies key requirements of multicast in AIDCs, and analyzes the gaps between these requirements and the capabilities of existing multicast technologies. |
| | Solutions for enabling agentic sensing with network optimization |
| |
|
Integrated Sensing and Communications (ISAC) represents a paradigm shift in wireless networks, where sensing and communication functions are jointly designed and optimized. By leveraging the same spectral and hardware resources, ISAC enables advanced capabilities such as environment perception, object tracking, and situational awareness, while maintaining efficient and reliable data transmission. There are sensing scenarios and use cases that involve a distributed sensing task, in which multiple sensors participate and contribute with (raw or pre-processed) sensing data, which is processed by a sensing service (e.g., fusing sensing measurements from the different sensors). This sensing service needs to be executed on some kind of sensing processing/computing function which receives raw (or preprocessed) data from multiple sources, potentially of different (heterogeneous) kinds (e.g., RF and non-RF sensing, or RF from different radio technologies). This processing might impose time synchronization constraints on the reception of the different parts of data, as well as potentially specific computing and/or AI/ML capabilities on the processing node. The joint selection of sensing entities, processing locations, and network configuration under time-varying conditions results in a large, coupled, and non-stationary decision space. These characteristics motivate the use of agentic AI to enable distributed, closed-loop configuration and reconfiguration of sensing and networking resources. This document presents initial considerations and potential solution directions for an architecture that enables the use of agentic AI for sensing (as an exemplary use case) supporting network optimization. |
| | BGP Capability for IPv6 BGP Identifier |
| |
|
This document defines a new BGP Capability that enables an IPv6 BGP Speaker to use its global unicast IPv6 address as its BGP Identifier. This mechanism simplifies configuration in IPv6-only networks by leveraging the inherent uniqueness of IPv6 addresses, while maintaining full backward compatibility with existing BGP implementations. |
| | AI Agent Architecture for Network Digital Twin |
| |
|
This document proposes an AI agent architecture for Network Digital Twin (NDT) that integrates AI agents with digital twin technology. |
| | Out-of-Band Discovery of Authentic Resolvers (ODAR) |
| |
|
This document defines Out-of-Band Discovery of Authentic Resolvers (ODAR), a set of mechanisms for DNS clients to discover and authenticate a resolver's identity via out-of-band channels. A resolver discovered in this manner is referred to as an "Authentic Resolver". These mechanisms can be used to authenticate a resolver when only its IP address is known, and to validate resolver identity information learned via other means. These mechanisms are designed for deployments in which the authenticity information is provided by the out-of-band channels, such as distributed systems, ARPA reverse domain name resolution systems, and InterPlanetary File System (IPFS). This document also clarifies the complementary relationship between ODAR and the Recursive-Identifier mechanism defined in RFC 9499, and specifies how the two mechanisms can be integrated to achieve end-to-end trusted identity transmission of recursive resolvers in the DNS system. |
| | BGP Signaling for Multipath Traffic Engineering Junction States |
| |
|
Multi-Path Traffic Engineering (MPTE) combines Traffic Engineering with Multi-Path forwarding, offering a much desired TE solution for both traditional WAN and new AIML DC/DCI. MPTE tunnels are based on MPTE Directed Acyclic Graph (DAG) and can be signaled with extensions to RSVP-TE, PCEP, BGP. This document specifies the BGP protocol extensions and procedures for signaling MPTE DAGs. |
| | AI Agent Protocols for Multi-modality |
| |
| | draft-hw-protocol-agent-00.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Yixin Lin, Chenchen Yang, Kuan Zhang, Xueli An, , Shaoyun Wu, Muhammad Jadoon, Sebastian Robitzsch |
| | Working Group: |
Individual Submissions (none) |
|
With the advancement of AI technologies, AI Agent traffic will account for the majority of network traffic, driving an increasing demand for higher quality of multi-modal data transmissions. Current networks lack awareness of the diverse transmission quality requirements for multi-modal data within a single traffic, leading to degraded service quality and inefficient utilization of network resources. This document proposes methods to enable networks (e.g., mobile network, transport network) to recognize the characteristics and the transmission requirement of AI Agent multi-modal data and outlines necessary capabilities and features of the AI Agent Protocols. |
| | Dynamic Internet Multicast Tunneling |
| |
|
This document specifies a mechanism to facilitate widespread multicast connectivity over the Global Internet via dynamic tunneling, enabling many different multicast islands to be connected by tunnels between both PIM routers and AMT gateways/relays. |
| | Verifiable Telemetry Ledgers for Resource-Constrained Environments |
| |
|
This document specifies a verifiable telemetry ledger profile for resource-constrained sensing environments. The profile defines how a gateway accepts framed telemetry, applies anti-replay policy, projects accepted frames into canonical facts, builds deterministic daily Merkle commitments, and anchors daily artifacts with external timestamp proofs. OpenTimestamps (OTS) is the default anchoring mechanism; optional parallel attestation methods (RFC 3161 timestamp protocol and peer signatures) are also described. The goal is interoperability and independent auditability, not new cryptographic primitives. |
| | PAVA: BGP AS_PATH Validation by Querying ASes about Their Relationships |
| |
|
This document defines PAth VAlidation (PAVA), a scheme for validating the Border Gateway Protocol (BGP) AS_PATH field based on the AS relationships. Validation is performed by sending queries to the ASes along the path, each query containing information about the prefix and the relevant path segment. We implement querying the ASes in a path with a system relying on Domain Name System (DNS) and DNSSEC. |
| | HJS: A Judgment Event Protocol |
| |
|
This document defines HJS, a specialized protocol for judgment attribution — determining who is responsible for AI decisions, when, and under what authority — and enables portable, verifiable judgment transfer across heterogeneous AI systems. HJS addresses one specific problem that complementary systems do not: binding decisions to accountable actors, tracking how responsibility transfers over time, and providing cryptographic credentials that allow AI agents to prove decision authority to external systems without requiring prior trust relationships. It works alongside provenance frameworks (VAP), security protocols (SEAT), monitoring platforms (Arize, WhyLabs), and governance systems (Fiddler), providing the attribution layer these systems complement. HJS contributes standardized judgment events, portable cryptographic Receipts that serve as verifiable credentials for cross-system delegation, and flexible verification modes for diverse deployment scenarios. |
| | Consideration for Space-Based Computing Infrastructure Network |
| |
|
This document presents considerations for a Space-Based Computing Infrastructure Network from use cases and requirements. |
| | Looma: Low-Latency Post-Quantum Authentication for TLS 1.3 in Datacenters |
| |
| | draft-ma-cfrg-looma-00.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Xinshu Ma, Michio Honda, Colin Perkins |
| | Working Group: |
Individual Submissions (none) |
|
Post-quantum (PQ) authentication in TLS 1.3 can add tens to hundreds of microseconds of handshake processing time. In datacenters, where mutual authentication is mandatory, this authentication cost becomes a dominant contributor to end-to-end request latency, particularly when connections are short-lived and handshake rates are high. This document specifies Looma, an online/offline authentication architecture integrated into the TLS 1.3 handshake. Looma replaces the on-path, per-handshake PQ signature with a fast, one-time signature over the TLS transcript and moves expensive work (including the multi-use PQ signature) to an asynchronous background plane. Looma includes a fallback strategy to preserve correct authentication when the verifier does not have the peer's one-time verification key cached. |
| | Path Verification in LEO Satellite Networks |
| |
|
Emerging satellite Internet constellations such as SpaceX's Starlink deploy thousands of broadband satellites and construct LEO satellite networks (LSNs) in space, significantly expanding the boundaries of today's terrestrial Internet. However, due to the unique global LEO dynamics, satellite routers inevitably pass through uncontrolled areas, suffering from security threats. It is important for satellite network operators (SNOs) to enable verifiable risk- avoidance routing to identify path anomalies. This document specifies StarVeri, a network path verification framework tailored for emerging LSNs. StarVeri addresses the limitations of existing crypto-based and delay-based verification approaches and accomplishes efficient and accurate path verification through: (i) a segment-based verification protocol that divides paths into verifiable segments using dynamic satellite relays; and (ii) a hybrid verification approach combining cryptographic authentication with adaptive delay thresholds to verify each segment. |
| | Consideration for Computing-Power Collaboration in Computing-Aware Traffic Steering (CATS) |
| |
|
This document outlines a series of challenges and considerations to explore computing-power collaboration in CATS. |
| | Structured Quoted Content |
| |
|
This document describes a machine-readable format for conveying quoted content in email messages. This can be used when replying to or forwarding an email message. Structured quoted content is expected to be used in conjunction with conventional, human-readable quote formatting. They are based on the forthcoming "structured email" specification defined in [I-D.ietf- sml-structured-email-03] and related drafts. |
| | MAC Address as String |
| |
|
IETF and IEEE 802.1 have different patterns for mac addresses in their respective YANG types modules. Therefore equivalent mac addresses may or may not match if a mac-address that uses the IETF datatype is compared to a mac-address that uses the IEEE datatype (and vise-versa). 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/samans/draft-sam-mac-address-as-string. |
| | BGP based SRv6 Routing Planes for DC network |
| |
|
This document introduces a BGP-based multi-planar routing architecture for modern data center networks, with a particular focus on environments running AI/ML workloads that demand traffic segregation. The proposed solution enables deterministic routing for workloads with characteristics such as collective communication and multi-tenancy. It allows the creation of multiple logical routing planes over a shared physical infrastructure by defining planes through three key elements: Constraints (e.g., fabric color inclusion/exclusion) Calculation types (e.g., shortest path) and Metric types (e.g., cost, delay, bandwidth). |
| | Post-Quantum EDHOC - Initiator and Responder using signature and/or KEM |
| |
|
This document specifies two extensions to the Ephemeral Diffie- Hellman over COSE (EDHOC). These two protocol versions aim to provide quantum-resistance to the original EDHOC protocol, while reducing message-complexity with respect to parallel drafts. The document defines: (1) a 3-message quantum-resistant EDHOC proposal when the Initiator knows the Responder; in this version, the Initiator authenticates using a signature, while the Responder uses a KEM; (2) a 3-or-4-message quantum-resistant EDHOC proposal, which proposes a tradeoff between message-complexity and computational overhead. |
| | AI Agent Authentication and Authorization |
| |
| | draft-klrc-aiagent-auth-00.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Pieter Kasselman, Jeff Lombardo, Yaroslav Rosomakho, Brian Campbell |
| | Working Group: |
Individual Submissions (none) |
|
This document proposes a model for authentication and authorization of AI agent interactions. It leverages existing standards such as the Workload Identity in Multi-System Environments (WIMSE) architecture and OAuth 2.0 family of specifications. Rather than defining new protocols, this document describes how existing and widely deployed standards can be applied or extended to establish agent authentication and authorization. By doing so, it aims to provide a framework within which to use existing standards, identify gaps and guide future standardization efforts for agent authentication and authorization. |
| | EVPN Fast Notification and Handling for Multihoming |
| |
|
EVPN supports powerful multihoming features, but it depends on the timely notification and handling of link going down or coming up on multihomed Ethernet Segments, which may not be guaranteed by the nature of control plane BGP signaling. When the handling is delayed, traffic duplication or loss may happen. This document specifies a UDP-based notification that can be originated and processed (near) instantly, greatly eliminate the potential traffic duplication or loss. |
| | IP Fast Reroute for BGP-Only Networks |
| |
|
IP Fast Reroute (IPFRR) [RFC5714] is widely deployed in IP networks to provide protection against failures by invoking locally determined repair paths. Traditional IPFRR deployments require the use of a link-state IGP to provide locally computed repair paths. This document provides the problem statement and outlines a solution to enable IPFRR computation and deployment in BGP-only networks. The solution maintains standard BGP routing operations while providing fast reroute capabilities comparable to IGP-based deployments. |
| | Applicability of RFC8795 YANG data model to SIMAP |
| |
|
This document analyses the applicability of the RFC 8795 YANG data model to Service & Infrastructure Maps (SIMAP) and in particular analysis which requirements can be supported by the existing YANG data model defined in RFC 8795. |
| | Denial-of-Service Considerations for Media over QUIC Relay Deployments |
| |
|
The Media over QUIC Transport (MoQT) protocol presents denial-of- service risks that differ in character from those facing typical request-response protocols. MoQT relays forward, fan out, and optionally cache media content on behalf of publishers and subscribers. This document complements the MoQT Security Considerations, focusing on the unique considerations for relays. |
| | Security Requirements for the IETF Network |
| |
|
This document requires the network at the IETF plenary meeting to protect the security and privacy of its users. |
| | Agentic AI Architectural Principles for Autonomous Computer Networks |
| |
|
Agentic AI systems combine planning, reasoning, tool invocation, and feedback loops to pursue system-defined goals with a controlled degree of autonomy. In networking, this enables an evolution from statically configured automation toward goal-driven closed-loop operations spanning multiple protocol layers and administrative domains. This document introduces architectural principles for "agentic augmentation" of the existing layered protocol stack as represented by the Internet protocol suite (IP suite). The key concept of the proposed principles is that deterministic protocol layering remains intact for interoperability, while AI Agents are introduced as first- class entities at each IP suite layer and are coordinated by one or more agent controllers via agentic methods and procedures. The purpose of this document is to initiate discussion within the research community on agentic networking. It identifies architectural research challenges that should be discussed to enable the addition of one or more AI Agents at one or more IP suite layers with the goal to allow AI Agents to improve the behaviour of a layer through reasoning with AI Agents at the same or other IP suite layers. |
| | Transcoding Data Modeled with YANG |
| |
|
YANG (RFC 7950) is a standardized data modeling language. The data may be encoded in XML (RFC 7950), JSON (RFC 7951), plain CBOR (RFC 9254) or CBOR with standins (draft-bormann-cbor-yang-standin). This document specifies how to convert data modeled by YANG encoded in one of the formats into another format. Use cases include e.g. local transcoding between Netconf and Restconf for tool compatibility, or reverse proxying while composing multiple backends. This document also defines a data annotation for additional value type specification. That data annotation behavior updates RFC 7950, RFC 7951 and RFC 9254. |
| | Structural Vulnerabilities in ASRank under Adversarial Conditions |
| |
|
This document analyzes the structural vulnerabilities of ASRank, a widely used algorithm for inferring Autonomous System (AS) business relationships from BGP routing data. ASRank plays a key role in security research and BGP operation, yet its inference process is highly sensitive to small changes in input data. This sensitivity introduces risks in adversarial conditions, where inference results may be manipulated without detection. This document outlines the design of ASRank, identifies its structural vulnerabilities, analyzes a minimal manipulation example, and discusses the security implications and potential countermeasures. |
| | Model Context Protocol and Agent Skills over Media over QUIC Transport |
| |
|
This document defines how to use Media over QUIC Transport (MOQT) as the underlying transport protocol for the Model Context Protocol (MCP). MCP is a protocol that enables seamless integration between language model applications and external data sources and tools. MOQT provides efficient, low-latency, publish-subscribe media delivery over QUIC and WebTransport. This specification describes the mapping of MCP messages onto MOQT objects and defines the procedures for establishing and maintaining MCP sessions over MOQT. It covers transport of MCP's core primitives including resources, tools, prompts, and notifications through dedicated MOQT tracks with appropriate priority management and delivery guarantees. A key focus of this document is the delivery and execution of Agent Skills - composed instructions that extend AI capabilities beyond atomic tool operations. Skills use progressive loading (metadata, instructions, resources) that aligns naturally with MOQT's object- based delivery, enabling efficient bandwidth utilization and aggressive caching strategies. The specification also describes relay support for scalable MCP deployments, including subscription aggregation, content caching, and multi-hop architectures that enable global distribution of MCP services with optimized performance. |
| | Lightspeed Notification Protocol |
| |
| | draft-camarillo-rtgwg-lsn-00.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Pablo Camarillo, Clarence Filsfils, Nadav Chachmon, Ofer Iny, Yuanchao Su, Roy Jiang |
| | Working Group: |
Individual Submissions (none) |
|
This document defines the Lightspeed Notification Protocol (LSN), a hardware-accelerated signaling mechanism designed for sub-100 microsecond network convergence in AI/ML data center fabrics. By operating entirely within the forwarding plane, LSN bypasses traditional CPU-based latencies to propagate link failures and congestion via a hardware-efficient encoding. It serves as a high- speed complement to routing protocols like BGP, providing an immediate hardware "veto" to prune congested/failed paths while maintaining control-plane stability for path recovery. |
| | MOQ Transport for Agent Protocols |
| |
|
This document defines a protocol abstraction layer that enables Media over QUIC Transport (MOQT) to serve as a unified transport substrate for inter-agent communication protocols. The abstraction provides a common mapping of request-response and streaming patterns onto MOQT's publish/subscribe model, allowing diverse agent protocols to leverage MOQT's real-time streaming capabilities, built-in prioritization, and efficient multiplexing over QUIC. The document demonstrates the application of this abstraction to two prominent inter-agent protocols: the Agent-to-Agent (A2A) protocol [A2A], which focuses on agent discovery, task delegation, and collaboration; and the Model Context Protocol (MCP) [MCP], which provides tool and resource access for agents. This unified approach enables interoperability across diverse agent ecosystems while preserving each protocol's semantics. |
| | Transaction ID Mechanism for RESTCONF |
| |
|
This document defines additional mechanisms intended to extend the RESTCONF Protocol's usability of Transaction ID Mechanism for NETCONF. |
| | Mercurius Window System (MWS) |
| |
|
The Mercurius Window System (MWS) is a network‑native, server‑side rendering system that enables graphical sessions to be accessed remotely with explicit semantics for windows, input, and session state. MWS allows a user to interact with a workstation from untrusted or resource‑constrained client devices without exposing application data, GPU workloads, or compositor state to those devices. The protocol defines a zero‑trust client model, a structured session and window architecture, and a transport profile based on SCTP multi‑streaming. This document specifies the MWS architecture, message formats, transport requirements, and security model. |
| | Trust Computation for the TrustChain Bilateral Ledger Protocol |
| |
|
This document specifies trust computation, delegation, and key succession mechanisms for the TrustChain bilateral ledger protocol (draft-pouwelse-trustchain-01). The base protocol specifies a bilateral block structure for recording pairwise interactions but explicitly leaves trust computation out of scope. This document fills that gap by defining: (1) a canonical hash computation for cross-implementation compatibility, (2) an interaction graph constructed from half-block pairs, (3) a maximum network flow algorithm (Edmonds-Karp) over the interaction graph for Sybil- resistant trust scoring, (4) a composite trust score combining chain integrity with network flow, (5) a delegation protocol for transitive authority with budget splitting and revocation, and (6) a bilateral succession protocol for key rotation. |
| | QUIC Alternative Server Address Frames |
| |
|
This document specifies an extension to QUIC to allow a server to advertise alternative addresses. |
| | NETCONF Error List and Error Identities Registries |
| |
|
This document defines IANA registries for the NETCONF Error List and NETCONF Error Identities. |
| | KYAPay Profile |
| |
|
This document defines a profile for agent identity and payment tokens in JSON web token (JWT) format. Authorization servers and resource servers from different vendors can leverage this profile to consume identity and payment tokens in an interoperable manner. |
| | HTTP/2 qlog event definitions |
| |
|
This document defines a qlog event schema containing concrete events for the core HTTP/2 protocol and selected extensions. |
| | Two-Lane Publication Model for Cryptographic Mechanisms |
| |
|
This document describes a repeatable publication model for cryptographic work in the IETF. It separates cryptographic mechanism specifications requiring deep security justification from protocol- oriented specifications defining interoperability, wire formats, and registries. It describes a dedicated working group model for coordinating Standards Track deployment of CFRG mechanisms and recommends use of the CFRG Crypto Review Panel to help working groups strengthen their Security Considerations text. |
| | Domain-Verified Skills (DVS) Protocol |
| |
| | draft-zzn-dvs-00.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Zainan ZHou |
| | Working Group: |
Individual Submissions (none) |
|
This document defines the Domain-Verified Skills (DVS) protocol, a lightweight mechanism for AI Agents to discover, verify, and execute skill definitions served over HTTPS. A skill is a directory containing a SKILL.md entry point and optional bundled resources that instructs an AI Agent to perform a specific task or adopt a specific behavior. The central design principle of DVS is that a skill's identity and trustworthiness are derived entirely from the HTTPS URL at which it is served -- no centralized registry or third-party certification is required. The operator of the URL's origin is the authoritative endorser of the skill. This trust is formalized through the concept of a Trust Root: an HTTPS URL prefix declared by the skill publisher that scopes the trust boundary for their skills. A skill is considered verified if and only if its URL begins with the declared Trust Root. For brands with first-party domains, the Trust Root is the domain origin. For brands publishing on user-generated content platforms where the platform operator does not vouch for individual publishers, the Trust Root MUST be path-scoped to content the brand controls, ensuring that trust does not extend to the entire platform. The protocol leverages the existing trust infrastructure of the Domain Name System (DNS) and Transport Layer Security (TLS) and is backward compatible with skills already served over HTTPS, including those hosted on GitHub or other platforms. |
| | SCIM 2.0 Interoperability Profile |
| |
|
This document defines an implementation profile for the System for Cross-domain Identity Management (SCIM) 2.0. The goal of this profile is to increase interoperability between identity providers and service providers by reducing the number of optional features and providing clear guidance on implementing a common subset of the SCIM standard. It deprecates certain features that have proven to be problematic for interoperability or are considered insecure. |
| | Agent Attachment Protocol |
| |
|
This document describes the Agent Attachment Protocol (AAP), a network-centric mechanism that enables autonomous agents to securely attach to an overlay network infrastructure. The protocol defines procedures for agent attachment, identity validation, capability exchange, and secure session establishment between an agent and its local network edge node. Once attached, agents can communicate with remote agents through the overlay formed by interconnected edge nodes, without exposing the underlying network topology. |
| | SAFE: Sealed,Algorithm-Flexible Envelope |
| |
|
SAFE defines an encryption envelope that encrypts a payload once for multiple recipients. Decryption can require multiple credentials in sequence (public keys, passphrases, or other registered methods), so no single factor suffices. The format is designed for large, writable files: it supports streaming decryption, random-access reads at block granularity, and selective re-encryption of modified blocks without re-keying. Recipient privacy modes allow locks to omit identifying metadata. SAFE accommodates post-quantum key encapsulation without format changes, provides algorithm agility through IANA registries, and defines a mandatory-to-implement profile for interoperability. |
| | STUN Protocol for Embedding DTLS (SPED) |
| |
|
WebRTC setup normally serializes ICE and DTLS, adding at least one extra round trip before secure media can flow. This document defines the STUN Protocol for Embedding DTLS (SPED), which carries DTLS handshake data and acknowledgements inside STUN Binding Requests and Responses. SPED allows ICE and DTLS to proceed in parallel, improves setup behavior under loss, and remains backward compatible with existing ICE processing. |
| | ATOM: AT Protocol Over MoQ Transport |
| |
|
This document specifies how the Authenticated Transfer (AT) Protocol can leverage Media over QUIC Transport (MOQT) for efficient data synchronization across decentralized social networks. The AT Protocol's firehose event stream and repository synchronization mechanisms map naturally to MOQT's publish/subscribe model, enabling scalable relay infrastructure, priority-based delivery, and improved resilience for large-scale social data distribution. This specification addresses the challenges of the current WebSocket- based transport and demonstrates how MOQT's relay architecture, group-based caching, and multiplexed streams provide significant benefits for AT Protocol deployments at scale. |
| | Using BGP to Maintain and Update a Traffic Engineering Database |
| |
|
In some networking situations, most commonly in Data Centers, no IGP protocol is run. The preferred option is to run BGP to exchange reachability information. If it is also desirable to run Traffic Engineering, a Traffic Engineering Database is needed; this information is typically exchanged via IGP TE extensions. This memo proposes elements of BGP procedure to carry this information when there is no IGP. |
| | SCIM 2.0 Group Member Resource |
| |
|
This document extends the System for Cross-domain Identity Management (SCIM) 2.0 standard by defining a new "GroupMember" top-level resource. Under the existing model defined in [RFC7643], group memberships are represented as values in a multi-valued attribute within a Group resource. This architecture lacks native support for server-side pagination, filtering, or sorting of individual members. In deployments managing large-scale groups (e.g., 100,000 to 1,000,000 members or more), retrieving a Group resource results in massive HTTP response payloads that can exceed 100MB in size. This can lead to service timeouts, memory exhaustion, and network instability, and has led to many major SCIM implementations choosing to not support returning the value of the "members" attribute for Group resources. This extension introduces a flattened resource model that enables group memberships to benefit from pagination and other SCIM protocol features, ensuring interoperability and performance at scale. |
| | Multi-Authentication in IKEv2 with Post-quantum Security |
| |
|
Motivated to mitigate security threats again quantum computers, this draft specifies a general authentication mechanism in the Internet Key Exchange Protocol Version 2 (IKEv2) [RFC7296], called Multi- Authentication. Namely, two peers can negotiate two or more authentication methods to authenticate each other. The authentication methods selected do not necessarily belong to the same category. This mechanism is achieved by adding a new value (17) (TBD) in the "IKEv2 Authentication Method" registry [IANA-IKEv2], maintained by IANA. To run Multiple Authentication, two peers send the SUPPORTED_AUTH_METHODS Notify, defined in [RFC9593], to negotiate two or more authentication methods for authenticaion in IKEv2. [EDNOTE: Code points for Multi-Authentication may need to be assigned in the "IKEv2 Authentication Method" registry [IANA-IKEv2], maintained by IANA] |
| | RootCache: Filling Resolver Caches with Root Zone Records |
| |
|
Some DNS recursive resolver operators want to reduce the number of queries they send to the root servers of the global DNS in order to give faster responses to their clients. Some DNS recursive resolver operators want to prevent snooping by third parties of requests sent to DNS root servers. In both cases, resolvers can reduce the number of queries sent to root server, and thus prevent observation of requests, by caching a copy of the full root zone. This document shows how a resolver can securely receive the full root zone and put it into the resolver's cache. This document obsoletes RFC 8806. |
| | QPACK Compression for MoQ Transport |
| |
|
This document defines an extension to Media over QUIC Transport (MOQT) that enables QPACK compression for control messages. By leveraging QPACK's dynamic table, this extension significantly reduces the overhead of repeated values such as track names and authorization tokens, improving efficiency for sessions with many subscriptions or frequent redundant values. |
| | The RPKISPOOL Format for Materializing Resource Public Key Infrastructure (RPKI) Data |
| |
|
This document describes a format and data storage approach for materialization of RPKI data in order to support a range of use cases such as auditing Certification Authorities and analytical research. The rpkispool format can be used for high-latency replication of raw RPKI data and associated validation outcomes as efficiently compressed durable objects. The method uses widely available standardized tooling and is designed to support long-term preservation of RPKI data in a cost-effective way. |
| | Agent Protocol over MoQ |
| |
|
This document specifies a Agent-to-Agent communication framework enabling structured, low-latency, and semantically rich communication between autonomous agents over the Media over QUIC (MoQ) protocol. It leverages MoQ's efficient media transport capabilities while introducing a new application-layer framing mechanism to support control signaling, session management, and large data fragmentation. The design supports both intra-domain and inter-domain deployment, with an emphasis on interoperability, extensibility, and minimal overhead. |
| | A DNS-Based Framework for Privacy-Preserving Identity |
| |
| | draft-duda-dnsop-dns-did-00.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Andrzej Duda, Maciej Korczynski, olivier hureau, zhang jun, Houda Labiod |
| | Working Group: |
Individual Submissions (none) |
|
This document presents a framework for privacy-preserving identity management based on DNS, supporting large-scale management of users, IoT devices, and AI agents. It introduces Self-Certifying Identifiers (SIDs), User/Service Trustees as trusted proxies, and leverages DNSSEC-secured TXT records to bind public keys to identities. The framework enables privacy-by-design, where real identities are hidden behind trusted entities, through privacy- preserving intermediarie. Credentials bound to SIDs support role- based access control, while ephemeral tokens ensure short-lived authorization. Although initially DNS-dependent, the model can extend to other directories like DIDs or IPFS. This approach aligns with zero-trust architectures and supports automated, AI-driven interactions in future networks. |
| | Forward Secure Reauthentication in the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA') |
| |
|
This draft specifies an update to RFC 9678, "Forward Secrecy Extension to the Improved Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS)", and its predecessors RFC 9048, RFC 5448, and RFC 4187. This update enables forward security of the Transient EAP Keys (TEKs) for protecting EAP packets, which are not in EAP-AKA' FS. Based on this extension, the executions of reauthentication after a full authentication will be unlinkable to each other and then the privacy of end users is enhanced. This udapte is optional to the above standards. |
| | The OAuth 2.1 Authorization Framework |
| |
| | draft-ietf-oauth-v2-1-15.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Dick Hardt, Aaron Parecki, Torsten Lodderstedt |
| | Working Group: |
Web Authorization Protocol (oauth) |
|
The OAuth 2.1 authorization framework enables an application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and an authorization service, or by allowing the application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 2.0 Authorization Framework described in RFC 6749 and the Bearer Token Usage in RFC 6750. |
| | Cross-Device Flows: Security Best Current Practice |
| |
|
This document describes threats against cross-device flows along with practical mitigations, protocol selection guidance, and a summary of formal analysis results identified as relevant to the security of cross-device flows. It serves as a security guide to system designers, architects, product managers, security specialists, fraud analysts and engineers implementing cross-device flows. |
| | OAuth 2.0 Attestation-Based Client Authentication |
| |
|
This specification defines an extension to the OAuth 2.0 protocol [RFC6749] that enables a client instance to include a key-bound attestation when interacting with an Authorization Server or Resource Server. This mechanism allows a client instance to prove its authenticity verified by a client attester without revealing its target audience to that attester. It may also serve as a mechanism for client authentication as per OAuth 2.0. |
| | Transaction Tokens |
| |
|
Transaction Tokens (Txn-Tokens) are designed to maintain and propagate user identity, workload identity and authorization context throughout the Call Chain within a trusted domain during the processing of external requests (e.g. such as API calls) or requests initiated internally within the trust domain. Txn-Tokens ensure that this context is preserved throughout the Call Chain thereby enhancing security and consistency in complex, multi-service architectures. |
| | Updates to OAuth 2.0 JSON Web Token (JWT) Client Authentication and Assertion-Based Authorization Grants |
| |
| | draft-ietf-oauth-rfc7523bis-06.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Michael Jones, Brian Campbell, Chuck Mortimore, Filip Skokan |
| | Working Group: |
Web Authorization Protocol (oauth) |
|
This specification updates the requirements for audience values in OAuth 2.0 Client Assertion Authentication and Assertion-based Authorization Grants to address a security vulnerability identified in the previous requirements for those audience values in multiple OAuth 2.0 specifications. |
| | JSON Web Token Best Current Practices |
| |
|
JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices (BCP) specification updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs. This BCP specification furthermore replaces the existing JWT BCP specification RFC 8725 to provide additional actionable guidance covering threats and attacks that have been discovered since RFC 8725 was published. |
| | Identity Assertion JWT Authorization Grant |
| |
|
This specification provides a mechanism for an application to use an identity assertion to obtain an access token for a third-party API by coordinating through a common enterprise identity provider using Token Exchange [RFC8693] and JWT Profile for OAuth 2.0 Authorization Grants [RFC7523]. |
| | Updates to OAuth 2.0 Security Best Current Practice |
| |
|
This document updates the set of best current security practices for OAuth 2.0 by extending the security advice given in RFC 6749, RFC 6750, and RFC 9700, to cover new threats that have been discovered since the former documents have been published. |
| | OAuth SPIFFE Client Authentication |
| |
|
This specification profiles the Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants [RFC7521], the JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants [RFC7523], and OAuth 2.0 Attestation-Based Client Authentication [I-D.draft-ietf-oauth-attestation-based-client-auth] to enable the use of SPIFFE Verifiable Identity Documents (SVIDs) as client credentials in OAuth 2.0. It defines how OAuth clients with SPIFFE credentials can authenticate to OAuth authorization servers using their JWT-SVIDs, WIT-SVIDs, or X.509-SVIDs without the need for client secrets. This approach enhances security by enabling seamless integration between SPIFFE-enabled workloads and OAuth authorization servers while eliminating the need to distribute and manage shared secrets such as static client secrets. |
| | Link-Layer Types for PCAP-related Capture File Formats |
| |
|
This document describes a set of Packet CAPture (PCAP)-related LinkType values and creates an IANA registry for those values. These values are used by the PCAP and PCAP-Now-Generic specifications. |
| | Guidelines for Considering Operations and Management in IETF Specifications |
| |
| | draft-ietf-opsawg-rfc5706bis-03.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Benoit Claise, Joe Clarke, Adrian Farrel, Samier Barguil, Carlos Pignataro, Ran Chen |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
New Protocols and Protocol Extensions are best designed with due consideration of the functionality needed to operate and manage them. Retrofitting operations and management considerations is suboptimal. The purpose of this document is to provide guidance to authors and reviewers on what operational and management aspects should be addressed when writing documents in the IETF Stream that define New Protocols or Protocol Extensions. This document obsoletes RFC 5706, replacing it completely and updating it with new operational and management techniques and mechanisms. It also updates RFC 2360 to obsolete mandatory MIB creation. Finally, it introduces a requirement to include an "Operational Considerations" section in new RFCs in the IETF Stream that define New Protocols or Protocol Extensions or describe their use (including relevant YANG Models), while providing an escape clause if no new considerations are identified. |
| | Path Computation Element Communication Protocol (PCEP) Extensions for Signaling Multipath Information |
| |
| | draft-ietf-pce-multipath-20.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Mike Koldychev, Siva Sivabalan, Tarek Saad, Vishnu Beeram, Hooman Bidgoli, Shuping Peng, Samuel Sidor |
| | Working Group: |
Path Computation Element (pce) |
|
A Segment Routing (SR) Policy Candidate Path can contain multiple Segment Lists, allowing for load-balancing and protection across diverse paths. However, current PCEP extensions for SR Policy only allow signaling of a single Segment List per Candidate Path. This document defines PCEP extensions to encode multiple Segment Lists within an SR Policy Candidate Path, enabling multipath capabilities such as weighted or equal-cost load-balancing across Segment Lists. The extensions are designed to be generic and reusable for future path types beyond SR Policy, and are applicable to both stateless and stateful PCEP. |
| | PCEP extensions for Distribution of Link-State and TE Information |
| |
| | draft-ietf-pce-pcep-ls-05.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Dhruv Dhody, Shuping Peng, Young Lee, Daniele Ceccarelli, Aijun Wang, Gyan Mishra |
| | Working Group: |
Path Computation Element (pce) |
|
In order to compute and provide optimal paths, Path Computation Elements (PCEs) require an accurate and timely Traffic Engineering Database (TED). Traditionally, this TED has been obtained from a link state (LS) routing protocol supporting the traffic engineering extensions. This document extends the Path Computation Element Communication Protocol (PCEP) with Link-State and TE Information as an experimental extension to allow gathering more deployment and implementation feedback on the use of PCEP in this way. |
| | Multicast Lessons Learned from Decades of Deployment Experience |
| |
|
This document gives a historical perspective about the design and deployment of multicast routing protocols. The document describes the technical challenges discovered from building these protocols. Even though multicast has enjoyed success of deployment in special use-cases, this draft discusses what were, and are, the obstacles for mass deployment across the Internet. Individuals who are working on new multicast related protocols will benefit by knowing why certain older protocols are no longer in use today. |
| | Merkle Tree Certificates |
| |
|
This document describes Merkle Tree certificates, a new form of X.509 certificates which integrate public logging of the certificate, in the style of Certificate Transparency. The integrated design reduces logging overhead in the face of both shorter-lived certificates and large post-quantum signature algorithms, while still achieving comparable security properties to traditional X.509 and Certificate Transparency. Merkle Tree certificates additionally admit an optional size optimization that avoids signatures altogether, at the cost of only applying to up-to-date relying parties and older certificates. |
| | Anonymous Rate-Limited Credentials Cryptography |
| |
|
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) cryptographic protocol. |
| | IETF Working Group Guidelines and Procedures |
| |
|
The Internet Engineering Task Force (IETF) has responsibility for developing and reviewing specifications intended as Internet Standards. IETF activities are organized into working groups (WGs). This document describes the guidelines and procedures for formation and operation of IETF working groups. It also describes the formal relationship between IETF participants WG and the Internet Engineering Steering Group (IESG) and the basic duties of IETF participants, including WG Chairs, WG participants, and IETF Area Directors. This document obsoletes RFC2418, and RFC3934. It also includes the changes from RFC7475, and with [_2026bis], obsoletes it. It also includes a summary of the changes implied in RFC7776 and incorporates the changes from RFC8717 and RFC9141. |
| | QUIC Extended Acknowledgement for Reporting Packet Receive Timestamps |
| |
|
This document defines an extension to the QUIC transport protocol which supports reporting multiple packet receive timestamps for post- handshake packets. |
| | Direct Anonymous Attestation for the Remote Attestation Procedures Architecture |
| |
| | draft-ietf-rats-daa-09.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Henk Birkholz, Christopher Newton, Liqun Chen, Thanassis Giannetsos, Dave Thaler |
| | Working Group: |
Remote ATtestation ProcedureS (rats) |
|
This document maps the concept of Direct Anonymous Attestation (DAA) to the Remote Attestation Procedures (RATS) Architecture. The protocol entity DAA Issuer is introduced and its mapping with existing RATS roles in DAA protocol steps is specified. |
| | Concise Reference Integrity Manifest |
| |
| | draft-ietf-rats-corim-10.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Henk Birkholz, Thomas Fossati, Yogesh Deshpande, Ned Smith, Wei Pan |
| | Working Group: |
Remote ATtestation ProcedureS (rats) |
|
Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester and therefore to decide whether or not to engage in secure interactions with it. Evidence about trustworthiness can be rather complex and it is deemed unrealistic that every Relying Party is capable of the appraisal of Evidence. Therefore that burden is typically offloaded to a Verifier. In order to conduct Evidence appraisal, a Verifier requires not only fresh Evidence from an Attester, but also trusted Endorsements and Reference Values from Endorsers and Reference Value Providers, such as manufacturers, distributors, or device owners. This document specifies the information elements for representing Endorsements and Reference Values in CBOR format. |
| | RATS Endorsements |
| |
|
In the IETF Remote Attestation Procedures (RATS) architecture, a Verifier accepts Evidence and uses Appraisal Policy for Evidence, typically with additional input from Endorsements and Reference Values, to generate Attestation Results in formats that are useful for Relying Parties. This document illustrates the purpose and role of Endorsements and discusses some considerations in the choice of message format for Endorsements in the scope of the RATS architecture. This document does not aim to define a conceptual message format for Endorsements and Reference Values. Instead, it extends RFC9334 to provide further details on Reference Values and Endorsements, as these topics were outside the scope of the RATS charter when RFC9334 was developed. |
| | Epoch Markers |
| |
| | draft-ietf-rats-epoch-markers-03.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Henk Birkholz, Thomas Fossati, Wei Pan, Ionut Mihalcea, Carsten Bormann |
| | Working Group: |
Remote ATtestation ProcedureS (rats) |
|
This document defines Epoch Markers as a means to establish a notion of freshness among actors in a distributed system. Epoch Markers are similar to "time ticks" and are produced and distributed by a dedicated system known as the Epoch Bell. Systems receiving Epoch Markers do not need to track freshness using their own understanding of time (e.g., via a local real-time clock). Instead, the reception of a specific Epoch Marker establishes a new epoch that is shared among all recipients. This document defines Epoch Marker types, including CBOR time tags, RFC 3161 TimeStampToken, and nonce-like structures. It also defines a CWT Claim to embed Epoch Markers in RFC 8392 CBOR Web Tokens, which serve as vehicles for signed protocol messages. |
| | Concise Selector for Endorsements and Reference Values |
| |
| | draft-ietf-rats-coserv-05.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Paul Howard, Thomas Fossati, Henk Birkholz, Shefali Kamal, Giridhar Mandyam, Ding Ma |
| | Working Group: |
Remote ATtestation ProcedureS (rats) |
|
In the Remote Attestation Procedures (RATS) architecture, Verifiers require Endorsements and Reference Values to assess the trustworthiness of Attesters. This document specifies the Concise Selector for Endorsements and Reference Values (CoSERV), a structured query/result format designed to facilitate the discovery and retrieval of these artifacts from various providers. CoSERV defines a query language and corresponding result structure using CDDL, which can be serialized in CBOR format, enabling efficient interoperability across diverse systems. |
| | YANG Models for Quality of Service (QoS) in IP networks |
| |
| | draft-ietf-rtgwg-qos-model-15.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Aseem Choudhary, Mahesh Jethanandani, Ebben Aries, Helen Chen |
| | Working Group: |
Routing Area Working Group (rtgwg) |
|
This document describes a YANG model for management of Quality of Service (QoS) in IP networks. |
| | The Resource Public Key Infrastructure (RPKI) to Router Protocol,Version 2 |
| |
|
In order to validate the origin Autonomous Systems (ASes) and Autonomous System relationships behind BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC6480) prefix origin data, Router Keys, and ASPA data from a trusted cache. This document describes a protocol to deliver them. This document describes version 2 of the RPKI-Router protocol. [RFC6810] describes version 0, and [RFC8210] describes version 1. This document is compatible with both. |
| | Best Practises for Operating Resource Public Key Infrastructure (RPKI) Publication Services |
| |
|
This document describes best current practices for operating an RFC 8181 RPKI publication engine and its associated publicly accessible rsync (RFC 5781) and RRDP (RFC 8182) repositories. |
| | YANG Data Model for RPKI to Router Protocol |
| |
| | draft-ietf-sidrops-rtr-yang-03.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Yisong Liu, Changwang Lin, Haibo Wang, Jishnu Roy, Jeff 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). |
| | Selective Disclosure CBOR Web Tokens (SD-CWT) |
| |
| | draft-ietf-spice-sd-cwt-07.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Michael Prorock, Orie Steele, Henk Birkholz, Rohan Mahy |
| | Working Group: |
Secure Patterns for Internet CrEdentials (spice) |
|
This specification describes a data minimization technique for use with CBOR Web Tokens (CWTs). The approach is inspired by the Selective Disclosure JSON Web Token (SD-JWT), with changes to align with CBOR Object Signing and Encryption (COSE) and CWTs. |
| | OpenID Connect Standard Claims Registration for CBOR Web Tokens |
| |
|
This document registers OpenID Connect standard claims already used in JSON Web Tokens for use in CBOR Web Tokens. |
| | Personal Assertion Token (PaSSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN) |
| |
|
This document extends the Personal Assertion Token (PASSporT), which is a token object that conveys cryptographically signed information about the participants involved in communications. The extension is defined based on the "Signature-based Handling of Asserted information using toKENs (SHAKEN)" specification by the ATIS/SIP[ Forum IP-NNI Task Group. It provides both (1) a specific set of levels of confidence in the correctness of the originating identity of a call originated in a SIP-based telephone network as well as (2) an identifier that allows the Service Provider (SP) to uniquely identify the origin of the call within its network. This document obsoletes RFC8588. |
| | TCP ACK Rate Request Option |
| |
|
TCP Delayed Acknowledgments (ACKs) is a widely deployed mechanism that allows reducing protocol overhead in many scenarios. However, Delayed ACKs may also contribute to suboptimal performance. When a relatively large congestion window (cwnd) can be used, less frequent ACKs may be desirable. On the other hand, in relatively small cwnd scenarios, eliciting an immediate ACK may avoid unnecessary delays that may be incurred by the Delayed ACKs mechanism. This document specifies the TCP ACK Rate Request (TARR) option. This option allows a sender to request the ACK rate to be used by a receiver, and it also allows to request immediate ACKs from a receiver. |
| | IETF Network Slice Application in 3GPP 5G End-to-End Network Slice |
| |
|
Network Slicing is one of the core features of 5G defined in 3GPP, which provides different network service as independent logical networks. To provide 5G network slices services, an end-to-end network slice has to span three network segments: Radio Access Network (RAN), Mobile Core Network (CN) and Transport Network (TN). This document describes the application of the IETF network slice framework in providing 5G end-to-end network slices, including network slice mapping in the management, control and data planes. |
| | Profiles for Traffic Engineering (TE) Topology Data Model and Applicability to non-TE-centric Use Cases |
| |
|
This document describes how profiles of the Topology YANG data model, defined in RFC8795, can be used to address applications in Traffic Engineering aware (TE-aware) deployments, irrespective of whether they are TE-centric or not. |
| | Extended Key Update for Transport Layer Security (TLS) 1.3 |
| |
|
TLS 1.3 ensures forward secrecy by performing an ephemeral Diffie- Hellman key exchange during the initial handshake, protecting past communications even if a party's long-term keys (typically a private key with a corresponding certificate) are later compromised. While the built-in KeyUpdate mechanism allows application traffic keys to be refreshed during a session, it does not incorporate fresh entropy from a new key exchange and therefore does not provide post- compromise security. This limitation can pose a security risk in long-lived sessions, such as those found in industrial IoT or telecommunications environments. To address this, this specification defines an extended key update mechanism that performs a fresh Diffie-Hellman exchange within an active session, thereby ensuring post-compromise security. By forcing attackers to exfiltrate new key material repeatedly, this approach mitigates the risks associated with static key compromise. Regular renewal of session keys helps contain the impact of such compromises. The extension is applicable to both TLS 1.3 and DTLS 1.3. |
| | A Password Authenticated Key Exchange Extension for TLS 1.3 |
| |
| | draft-ietf-tls-pake-01.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Laura Bauman, David Benjamin, Samir Menon, Christopher Wood |
| | Working Group: |
Transport Layer Security (tls) |
|
The pre-shared key mechanism available in TLS 1.3 is not suitable for usage with low-entropy keys, such as passwords entered by users. This document describes an extension that enables the use of password-authenticated key exchange protocols with TLS 1.3. |
| | Stream Control Transmission Protocol (SCTP) DTLS Chunk |
| |
|
This document describes a method for adding Datagram Transport Layer Security (DTLS) based authentication and cryptographic protection to the Stream Control Transmission Protocol (SCTP). This SCTP extension is intended to enable communication privacy for applications that use SCTP as their transport protocol and allows applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery. Once enabled, this also applies to the SCTP payload as well as the SCTP control information. Applications using this SCTP extension can use most of the transport features provided by SCTP and its other extensions. The use of the SCTP Authentication extension defined in RFC 4895 is incompatible with the extension defined in this document but would not provide any additional service. This implies that the Dynamic Address Reconfiguration as specified in RFC 5061 can only be used as described in this document. |
| | Using Datagram Transport Layer Security (DTLS) for Key Management for the Stream Control Transmission Protocol (SCTP) DTLS Chunk |
| |
|
This document defines how Datagram Transport Layer Security (DTLS) 1.3 is used to establish keys for securing SCTP using the DTLS Chunk mechanism. It specifies how a DTLS handshake is used to establish the initial security context for an SCTP association and describes procedures for key updates and post-handshake authentication. The goal is to enable authenticated, and confidential communication over SCTP using the DTLS Chunk, leveraging standardized DTLS features for key management and rekeying. |
| | Flow Queue PIE: A Hybrid Packet Scheduler and Active Queue Management Algorithm |
| |
|
This document presents Flow Queue Proportional Integral controller Enhanced (FQ-PIE), a hybrid packet scheduler and Active Queue Management (AQM) algorithm to isolate flows and tackle the problem of bufferbloat. FQ-PIE uses hashing to classify incoming packets into different queues and provide flow isolation. Packets are dequeued by using a variant of the round robin scheduler. Each such flow is managed by the PIE algorithm to maintain high link utilization while controlling the queue delay to a target value. |
| | Time-Variant Routing (TVR) Requirements |
| |
|
Time-Variant Routing (TVR) refers to calculating a path or subpath through a network where the time of message transmission (or receipt) is part of the overall route computation. This means that, all things being equal, a TVR computation might produce different results depending on the time that the computation is performed without other detectable changes to the network topology or other cost functions associated with the route. This document introduces requirements for the design and implementation of systems which perform TVR computations. It also explains different aspects of a TVR system which need to be considered during its design. |
| | IPv6-mostly Networks: Deployment and Operations Considerations |
| |
|
This document discusses a deployment scenario called "an IPv6-mostly network", when IPv6-only and IPv4-enabled endpoints coexist on the same network (network segment, VLAN, SSID etc). The proposed approach enables smooth and incremental transition from dual-stack to IPv6-only network by allowing IPv6-capable devices to remain IPv6-only while the network is seamlessly supplying IPv4 to those that require it. |
| | Basic Requirements for IPv6 Customer Edge Routers |
| |
|
This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document obsoletes RFC 7084. |
| | The vCon - Conversation Data Container - Overview |
| |
|
A vCon is the container for data and information relating to a real- time, human conversation. It is analogous to a [vCard] which enables the definition, interchange and storage of an individual's various points of contact. The data contained in a vCon may be derived from any multimedia session, traditional phone call, video conference, SMS or MMS message exchange, webchat or email thread. The data in the container relating to the conversation may include Call Detail Records (CDR), call meta data, participant identity information (e.g. STIR PASSporT), the actual conversational data exchanged (e.g. audio, video, text), realtime or post conversational analysis and attachments of files exchanged during the conversation. A standardized conversation container enables many applications, establishes a common method of storage and interchange, and supports identity, privacy and security efforts (see [vCon-white-paper]) |
| | The WebTransport Protocol Framework |
| |
|
The WebTransport Protocol Framework enables clients constrained by the Web security model to communicate with a remote server using a secure multiplexed transport. It consists of a set of individual protocols that are safe to expose to untrusted applications, combined with an abstract model that allows them to be used interchangeably. This document defines the overall requirements on the protocols used in WebTransport, as well as the common features of the protocols, support for some of which may be optional. |
| | WebTransport over HTTP/3 |
| |
|
WebTransport [OVERVIEW] is a protocol framework that enables application clients constrained by the Web security model to communicate with a remote application server using a secure multiplexed transport. This document describes a WebTransport protocol that is based on HTTP/3 [HTTP3] and provides support for unidirectional streams, bidirectional streams, and datagrams, all multiplexed within the same HTTP/3 connection. |
| | WebTransport over HTTP/2 |
| |
| | draft-ietf-webtrans-http2-14.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Alan Frindell, Eric Kinnear, Tommy Pauly, Martin Thomson, Victor Vasiliev, Guowu Xie |
| | Working Group: |
WebTransport (webtrans) |
|
WebTransport defines a set of low-level communications features designed for client-server interactions that are initiated by Web clients. This document describes a protocol that can provide many of the capabilities of WebTransport over HTTP/2. This protocol enables the use of WebTransport when a UDP-based protocol is not available. |
| | Workload Identity in a Multi System Environment (WIMSE) Architecture |
| |
| | draft-ietf-wimse-arch-07.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Joseph Salowey, Yaroslav Rosomakho, Hannes Tschofenig |
| | Working Group: |
Workload Identity in Multi System Environments (wimse) |
|
The increasing prevalence of cloud computing and micro service architectures has led to the rise of complex software functions being built and deployed as workloads, where a workload is defined as software executing for a specific purpose, potentially comprising one or more running instances. This document discusses an architecture for designing and standardizing protocols and payloads for conveying workload identity and security context information. |
| | Workload Identifier |
| |
|
This document defines a canonical identifier for workloads, referred to as the Workload Identifier. A Workload Identifier is a URI that uniquely identifies a workload within the context of a specific trust domain. This identifier can be embedded in digital credentials, including X.509 certificates and security tokens, to support authentication, authorization, and policy enforcement across diverse systems. The Workload Identifier format ensures interoperability, facilitates secure identity federation, and enables consistent identity semantics. |
| | WIMSE Workload Proof Token |
| |
| | draft-ietf-wimse-wpt-01.txt |
| | Date: |
02/03/2026 |
| | Authors: |
Brian Campbell, Arndt Schwenkschuster |
| | Working Group: |
Workload Identity in Multi System Environments (wimse) |
|
The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from basic deployments to complex multi-service, multi-cloud, multi-tenant systems. This document specifies the Workload Proof Token (WPT), a mechanism for workloads to prove possession of the private key associated with a Workload Identity Token (WIT). The WPT is a signed JWT that binds the workload's authentication to a specific HTTP request, providing application-level proof of possession for workload-to-workload communication. This specification is designed to work alongside the WIT credential format defined in draft-ietf- wimse-workload-creds and can be combined with other WIMSE protocols in multi-hop call chains. |
| |
|
| |
| | Transmission of IPv6 over Multidrop Serial Bus/Token Passing (MS/TP) Networks |
| |
|
Multidrop Serial Bus/Token Passing (MS/TP) is a medium access control method for the RS-485 physical layer and is used primarily in building automation networks. This specification defines the frame format for transmission of IPv6 packets and the method of forming link-local and statelessly autoconfigured IPv6 addresses on MS/TP networks. It obsoletes RFC 8163. |
| | Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object Security for Constrained Environments (OSCORE) Profile for Authentication and Authorization for Constrained Environments (ACE) |
| |
| | draft-ietf-ace-edhoc-oscore-profile-10.txt |
| | Date: |
01/03/2026 |
| | Authors: |
Goeran Selander, John Mattsson, Marco Tiloca, Rikard Hoeglund |
| | Working Group: |
Authentication and Authorization for Constrained Environments (ace) |
|
This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Ephemeral Diffie-Hellman Over COSE (EDHOC) for achieving mutual authentication between an ACE-OAuth client and resource server, and it binds an authentication credential of the client to an ACE-OAuth access token. EDHOC also establishes an Object Security for Constrained RESTful Environments (OSCORE) Security Context, which is used to secure communications between the client and resource server when accessing protected resources according to the authorization information indicated in the access token. This profile can be used to delegate management of authorization information from a resource-constrained server to a trusted host with less severe limitations regarding processing power and memory. |
| | Automated Certificate Management Environment (ACME) Remote Attestation Identifier and Challenge Type |
| |
| | draft-ietf-acme-rats-01.txt |
| | Date: |
01/03/2026 |
| | Authors: |
Peter Liu, Mike Ounsworth, Michael Richardson |
| | Working Group: |
Automated Certificate Management Environment (acme) |
|
This document describes an approach where an ACME Server can challenge an ACME Client to provide Evidence, Endorsements, or Attestation Result according to the Remote ATtestation procedureS (RATS) framework in any format supported by the Conceptual Message Wrapper (CMW). The ACME Server can optionally challenge the Client for specific claims that it wishes attestation for. |
| | An Intent-based Framework of Network Services Autonomic Deployment and Management |
| |
|
This document introduces an intent-based framework for network services autonomic deployment and management. It autonomically deploys network services that require customized combinations of network resources and dynamically manage these resources throughout their lifecycle. The framework leverages the GeneRic Autonomic Signaling Protocol (GRASP) to facilitate the dynamic exchange of resource management signals among autonomic nodes, thereby enabling coordinated and consistent operations within an autonomic network domain. This framework is generic and applicable to most types of network resources. |
| | CATS Metrics Definition |
| |
|
Computing-Aware Traffic Steering (CATS) is a traffic engineering approach that optimizes the steering of traffic to a given service instance by considering the dynamic nature of computing and network resources. In order to consider the computing and network resources, a system needs to share information (metrics) that describes the state of the resources. Metrics from network domain have been in use in network systems for a long time. This document defines a set of metrics from the computing domain used for CATS. |
| | CDDL Module Structure |
| |
| | draft-ietf-cbor-cddl-modules-06.txt |
| | Date: |
01/03/2026 |
| | Authors: |
Carsten Bormann, Brendan Moran |
| | Working Group: |
Concise Binary Object Representation Maintenance and Extensions (cbor) |
|
At the time of writing, the Concise Data Definition Language (CDDL) is defined by RFC 8610 and RFC 9682 as well as RFC 9165 and RFC 9741. The latter two have used the extension point provided in RFC 8610, the _control operator_. As CDDL is being used in larger projects, the need for features has become known that cannot be easily mapped into this single extension point. The present document defines a backward- and forward-compatible way to add a module structure to CDDL. |
| | External References to Values in CBOR Diagnostic Notation (EDN) |
| |
| | draft-ietf-cbor-edn-e-ref-03.txt |
| | Date: |
01/03/2026 |
| | Authors: |
Carsten Bormann |
| | Working Group: |
Concise Binary Object Representation Maintenance and Extensions (cbor) |
|
The Concise Binary Object Representation (CBOR, RFC 8949) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. CBOR diagnostic notation (EDN) is widely used to represent CBOR data items in a way that is accessible to humans, for instance for examples in a specification. At the time of writing, EDN did not provide mechanisms for composition of such examples from multiple components or sources. This document uses EDN application extensions to provide two such mechanisms, both of which insert an imported data item into the data item being described in EDN: The e'' application extension provides a way to import data items, particularly constant values, from a CDDL model (which itself has ways to provide composition). The ref'' application extension provides a way to import data items that are described in EDN. |
| | Key Blinding for Signature Schemes |
| |
|
This document describes extensions to existing digital signature schemes for key blinding. The core property of signing with key blinding is that a blinded public key and all signatures produced using the blinded key pair are independent of the unblinded key pair. Moreover, signatures produced using blinded key pairs are indistinguishable from signatures produced using unblinded key pairs. This functionality has a variety of applications, including Tor onion services and privacy-preserving airdrop for bootstrapping cryptocurrency systems. |
| | On-time Forwarding with Non-Work Conserving Stateless Core Fair Queuing |
| |
|
This document specifies the framework and operational procedure for deterministic networking that guarantees maximum and minimum end-to- end latency bounds to flows. The solution has non-periodic, asynchronous, flow-level, non-work conserving, on-time, and rate- based functional characteristics, according to the taxonomy suggested by [I-D.ietf-detnet-dataplane-taxonomy]. The packets are stored in the queue in ascending order of the ideal service start time, called Eligible Time (ET), and the ideal service completion time, called Finish Time (FT). The queued packets were forwarded after ET, in ascending ordering of FT, in a non-work conserving manner. The ET and FT are calculated at the entrance node according to the packet size and rate of the flow. All subsequent core nodes are stateless and asynchronously update ET and FT based on metadata received via packet headers. This mechanism is called non- work conserving stateless fair queuing (N-SCORE), which guarantees both E2E latency upper and lower bounds, thus E2E jitter bound. |
| | On-time Forwarding with Push-In First-Out (PIFO) queue |
| |
|
This document describes operations of data plane and controller plane for Deterministic Networking (DetNet) to forward packets to meet minimum and maximum end-to-end latency requirements, while utilizing Push-In First-Out (PIFO) queue. According to the solution described in this document, forwarding nodes do not need to maintain flow states or to be time-synchronized with each other. |
| | BGP Extensions for Routing Policy Distribution (RPD) |
| |
| | draft-ietf-idr-rpd-20.txt |
| | Date: |
01/03/2026 |
| | Authors: |
Zhenbin Li, Liang Ou, Yujia Luo, Gyan Mishra, Huaimo Chen, Haibo Wang |
| | Working Group: |
Inter-Domain Routing (idr) |
|
It is hard to adjust traffic in a traditional IP network from time to time through manual configurations. It is desirable to have a mechanism for setting up routing policies, which adjusts traffic automatically. This document describes BGP Extensions for Routing Policy Distribution (BGP RPD) to support this with a controller. |
| | BGP Flowspec for IETF Network Slice Traffic Steering |
| |
|
BGP Flow Specification (Flowspec) provides a mechanism to distribute traffic Flow Specifications and the forwarding actions to be performed to the specific traffic flows. A set of Flowspec components are defined to specify the matching criteria that can be applied to the packet, and a set of BGP extended communities are defined to encode the actions a routing system can take on a packet which matches the flow specification. An IETF Network Slice enables connectivity between a set of Service Demarcation Points (SDPs) with specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) over a common underlay network. To meet the connectivity and performance requirements of network slice services, network slice service traffic may need to be mapped to a corresponding Network Resource Partition (NRP). The edge nodes of the NRP needs to identify the traffic flows of specific connectivity constructs of network slices, and steer the matched traffic into the corresponding NRP, or a specific path within the corresponding NRP. BGP Flowspec can be used to distribute the matching criteria and the forwarding actions to be performed on network slice service traffic. The existing Flowspec components can be reused for the matching of network slice services flows at the edge of an NRP. New components and traffic action may need to be defined for steering network slice service flows into the corresponding NRP. This document defines the extensions to BGP Flowspec for IETF network slice traffic steering (NS-TS). |
| | BGP Next Hop Dependent Characteristics Attribute |
| |
| | draft-ietf-idr-nhc-01.txt |
| | Date: |
01/03/2026 |
| | Authors: |
Bruno Decraene, Kireeti Kompella, Serge Krier, MOHANTY Satya, John Scudder, Kevin Wang, Bin Wen |
| | Working Group: |
Inter-Domain Routing (idr) |
|
RFC 5492 allows a BGP speaker to advertise its capabilities to its peer. When a route is propagated beyond the immediate peer, it is useful to allow certain characteristics to be conveyed further. In particular, it is useful to advertise forwarding plane features. This specification defines a BGP transitive attribute to carry such information, the "Next Hop Dependent Characteristics Attribute," or NHC. Unlike the capabilities defined by RFC 5492, the characteristics conveyed in the NHC apply solely to the routes advertised by the BGP UPDATE that contains the particular NHC. |
| | ESP Echo Protocol |
| |
| | draft-ietf-ipsecme-esp-ping-01.txt |
| | Date: |
01/03/2026 |
| | Authors: |
Lorenzo Colitti, Jen Linkova, Michael Richardson |
| | Working Group: |
IP Security Maintenance and Extensions (ipsecme) |
|
This document defines an IPsec ESP echo function which can be used to detect whether a given network path supports IPsec ESP packets. |
| | Use of Remote Attestation with Certification Signing Requests |
| |
| | draft-ietf-lamps-csr-attestation-23.txt |
| | Date: |
01/03/2026 |
| | Authors: |
Mike Ounsworth, Hannes Tschofenig, Henk Birkholz, Monty Wiseman, Ned Smith |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
Certification Authorities (CAs) issuing certificates to Public Key Infrastructure (PKI) end entities may require a certificate signing request (CSR) to include additional verifiable information to confirm policy compliance. For example, a CA may require an end entity to demonstrate that the private key corresponding to a CSR's public key is secured by a hardware security module (HSM), is not exportable, etc. The process of generating, transmitting, and verifying additional information required by the CA is called remote attestation. While work is currently underway to standardize various aspects of remote attestation, a variety of proprietary mechanisms have been in use for years, particularly regarding protection of private keys. This specification defines an ASN.1 structure for remote attestation that can accommodate proprietary and standardized attestation mechanisms, as well as an attribute and an extension to carry the structure in PKCS#10 and Certificate Request Message Format (CRMF) messages, respectively. |
| | A feature freezer for the Concise Data Definition Language (CDDL) |
| |
|
In defining the Concise Data Definition Language (CDDL), some features have turned up that would be nice to have. In the interest of completing this specification in a timely manner, the present document was started to collect nice-to-have features that did not make it into the first RFC for CDDL, RFC 8610, or the specifications exercising its extension points, such as RFC 9165. Significant parts of this draft have now moved over to the CDDL 2.0 project, described in draft-bormann-cbor-cddl-2-draft. The remaining items in this draft are not directly related to the CDDL 2.0 effort. |
| | Modern Network Unicode |
| |
|
BCP18 (RFC 2277) has been the basis for the handling of character- shaped data in IETF specifications for more than a quarter of a century now. It singles out UTF-8 (STD63, RFC 3629) as the “charset” that MUST be supported, and pulls in the Unicode standard with that. Based on this, RFC 5198 both defines common conventions for the use of Unicode in network protocols and caters for the specific requirements of the legacy protocol Telnet. In applications that do not need Telnet compatibility, some of the decisions of RFC 5198 can be cumbersome. The present specification defines “Modern Network Unicode” (MNU), which is a form of RFC 5198 Network Unicode that can be used in specifications that require the exchange of plain text over networks and where just mandating UTF-8 may not be sufficient, but there is also no desire to import all of the baggage of RFC 5198. As characters are used in different environments, MNU is defined in a one-dimensional (1D) variant that is useful for identifiers and labels, but does not use a structure of text lines. A 2D variant is defined for text that is a sequence of text lines, such as plain text documents or markdown format. Additional variances of these two base formats can be used to tailor MNU to specific areas of application. |
| | Using CDDL for CSVs |
| |
|
The Concise Data Definition Language (CDDL), standardized in RFC 8610, is defined to provide data models for data shaped like JSON or CBOR. Another representation format that is quote popular is the CSV (Comma-Separated Values) file as defined by RFC 4180. The present document shows a way how to use CDDL to provide a data model for CSV files. |
| | Expressing Quality of Service Requirements (QoS) in Domain Name System (DNS) Queries |
| |
|
A method of encoding quality of communication service (QoS) requirements in a Domain Name System (DNS) query is specified through inclusion of the requirements in one or more labels of the name being queried. This enables DNS responses including addressing and packet labeling information that is dependent on such requirements without changes in the format of DNS protocol messages or DNS application program interfaces (APIs). |
| | CDDL 2.0 and beyond -- a draft plan |
| |
|
The Concise Data Definition Language (CDDL) today is defined by RFC 8610, RFC 9165, RFC 9682, and RFC 9741). RFC 9165 and the latter (as well as some more application specific specifications such as RFC 9090) have used the extension point provided in RFC 8610, the control operator. As CDDL is used in larger projects, feature requirements become known that cannot be easily mapped into this single extension point. Hence, there is a need for evolution of the base CDDL specification itself. The present document provides a roadmap towards a "CDDL 2.0"; it is intended to serve as a basis for implementations that evolve with the concept of CDDL 2.0. It is based on draft-bormann-cbor-cddl-freezer, but is more selective in what potential features it takes up and more detailed in their discussion. This document is intended to evolve over time; it might spawn specific documents and then retire, or it might eventually be published as a roadmap document. |
| | Selective Synchronization Extension for RPKI-to-Router Protocol |
| |
|
The RPKI-to-Router (RTR) protocol synchronizes all the verified RPKI data to routers. This document proposes to extend the existing RTR protocol to support selective data synchronization. Selective synchronization can avoid unnecessary transmissions. The router can receive only the data that it really needs. |
| | EVPN First Hop Security |
| |
|
The Dynamic Host Configuration Protocol (DHCP) snoop database stores valid IPv4-to-MAC and IPv6-to-MAC bindings by snooping on DHCP messages. These bindings are used by security functions like Dynamic Address Resolution Protocol Inspection (DAI), Neighbor Discovery Inspection (NDI), IPv4 Source Guard, and IPv6 Source Guard to safeguard against traffic received with a spoofed address. These functions are collectively referred to as First Hop Security (FHS). This document proposes BGP extensions and new procedures for Ethernet VPN (EVPN) will distribute and synchronize the DHCP snoop database to support FHS. Such synchronization is needed to support EVPN host mobility and multi-homing. |
| | Path Computation and Control Extention Requirements for Fine-Granularity Transport Network |
| |
|
This document focuses on the requirements for path computation and control of the fine-granularity transport network. It provides the general context of the use cases of path computation and the considerations on the requirements of PCE extension in such fine- granularity transport network. |
| | EVPN L3-Optimized IRB |
| |
|
Ethernet VPN Integrated Routing and Bridging (EVPN-IRB) provides dynamic and efficient intra and inter-subnet connectivity among Tenant Systems and end devices while maintaining very flexible multihoming capabilities. This document describes how EVPN-IRB can be optimized for IP hosts and devices such that PE devices only maintain MAC addresses for locally-connected IP hosts, thus improving MAC scalability of customer bridges and PE devices significantly. This document describes how such optimization is acheived while still supporting host moblity which is one of the fundamental features in EVPN and EVPN-IRB. With such optimization PE devices perform routing for both intra and inter-subnet traffic which results in some some caveats that operators and service providers need to be fully aware of. |
| | Safe(r) Limited Domains |
| |
|
Documents describing protocols that are only intended to be used within "limited domains" often do not clearly define how the boundary of the limited domain is implemented and enforced, or require that operators of these limited domains perfectly filter at all of the boundary nodes of the domain to protect the rest of the global Internet from these protocols and vice-versa. This document discusses some design principles and offers mechanisms to allow protocols that are designed to operate in a limited domain "fail-closed" rather than "fail-open", thereby making these protocols safer to deploy on the Internet. These mechanism are not applicable to all protocols intended for use in a limited domain, but if implemented on certain classes of protocols, they can significantly reduce the risks. |
| | Flow Aggregation for Enhanced DetNet |
| |
|
[I-D.ietf-detnet-scaling-requirements] proposed the data plane requirements in scaling networks. This document describes the specific requirements for flow aggregation in enhanced DetNet and provides the enhancement considerations. It also discusses how the flow aggregation could be realized in a 5GS logical DetNet node participating in enhanced DetNet. |
| | YANG Data Models for fine grain Optical Transport Network |
| |
|
This document defines YANG data models to describe the topology and tunnel information of a fine grain Optical Transport Network. The YANG data models defined in this document are designed to meet the requirements for efficient transmission of sub-1Gbit/s client signals in transport network. |
| | XML Encoding of Data Modeled with YANG |
| |
|
This document defines encoding rules for representing YANG modeled configuration data, state data, parameters of Remote Procedure Call (RPC) operations or actions, and notifications defined using XML. |
| | On Numbers in CBOR |
| |
|
The Concise Binary Object Representation (CBOR), as defined in STD 94 (RFC 8949), is a data representation format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. Among the kinds of data that a data representation format needs to be able to carry, numbers have a prominent role, but also have inherent complexity that needs attention from protocol designers, from implementers of CBOR libraries, and from implementers of the applications that use them. This document gives an overview over number formats available in CBOR and some notable CBOR tags registered, and it attempts to provide information about opportunities and potential pitfalls of these number formats. // This is still rather drafty, pieced together from various // components, so it has a higher level of redundancy than ultimately // desired. |
| | Advertising SAV Rule-related Information using BGP Link-State |
| |
|
This document proposes extensions to the BGP Link-State protocol for advertising Source Address Validation (SAV) rule-related information. |
| | QUIC Profile for Deep Space |
| |
|
Deep space communications involve long delays (e.g., Earth to Mars is 4-20 minutes) and intermittent communications, because of orbital dynamics. In this context, typical QUIC stacks default transport parameters for terrestrial Internet are not suitable for deep space. This document defines a QUIC profile for deep space. It provides guidance on how to estimate and set transport parameters, advice to space mission operators and application developers on how to configure QUIC for the deep space use case and guidance to QUIC stack developers to properly expose the required transport parameters in their API. |
| | Anomalous Traffic Handling for DetNet |
| |
|
In deterministic networking (DetNet), strict resource reservation and scheduling assumptions may encounter anomalous traffic conditions at flow aggregation nodes due to microbursts, packet size variations, or control plane orchestration limitations. These conditions represent deviations from the ideal deterministic service model rather than network faults. Existing data plane mechanisms for handling anomalous packets, such as simple discarding or treating them as Best-Effort (BE) flows, are insufficient. Consequently, the network performance can degrade to a level inferior to of traditional QoS approaches.Therefore, in order to handle the anomalous traffic, the data plane should implement an enhanced handling mechanism. This document proposes an enhanced anomalous traffic handling solution for DetNet. This solution specifies two policies for handling traffic under anomalous conditions: the squeezing policy and the degrading policy. These policies provide a flexible, enhanced mechanism applicable to various queuing mechanisms, ensuring the preferential scheduling and preservation of deterministic service traffic under anomalous conditions. |
| | Export of QUIC Information in IP Flow Information Export (IPFIX) |
| |
|
This document introduces new IP Flow Information Export (IPFIX) Information Elements to identify a set of QUIC related information, which contained in QUIC Header, QUIC Frame and Stream that traffic is being forwarded along with. |
| | Considerations of Gradual IPv6-only Deployment in 5G Mobile Networks |
| |
|
This document describes the approach of gradually deploying 464XLAT based IPv6-only technology on user plane in 3GPP 5G networks. It also discusses the challenges and potential solutions. |
| | Source Address Validation Deployment Status |
| |
|
This document provides a summary of methods for measuring the deployment status of source address validation, with an overview of its deployment status. It reviews various methods for measuring outbound and/or inbound source address validation, including established tools like CAIDA Spoofer, as well as recently proposed remote measurement methods. By combining results from these different methods, the document offers a comprehensive overview of the status of source address validation deployment across the Internet. |
| | Benchmarking Methodology for Computing-aware Traffic Steering |
| |
| | draft-yl-bmwg-cats-03.txt |
| | Date: |
01/03/2026 |
| | Authors: |
Kehan Yao, Peng Liu, Guanming Zeng, Xinxin Yi, Quan Xiong, Tran Ngoc |
| | Working Group: |
Individual Submissions (none) |
|
Computing-aware traffic steering(CATS) is a traffic engineering approach based on the awareness of both computing and network information. This document proposes benchmarking methodologies for CATS. |
| | Privacy Preserving Verifiable Geofencing with Residency Proofs for Sovereign Workloads |
| |
|
Modern cloud and distributed computing rely heavily on software-only identities and bearer tokens that are easily stolen, replayed, or used from unauthorized locations. Furthermore, traditional methods of location verification - such as IP-address-based geolocation - are easily spoofed via VPNs or proxies and significantly compromise infrastructure security and privacy for *Sovereign Workloads* and high-assurance environments. This document defines a *High-Assurance Profile* designed to solve these challenges through hardware-rooted cryptographic verifiability. A host machine runs a workload identity agent for managing the workload identities on that platform. This proposal replaces implicit trust and spoofable indicators with cryptographically verifiable hardware-rooted evidence of integrity and location for this agent. Critically, this framework prioritizes *Location Privacy* by utilizing Zero-Knowledge Proofs (ZKP), allowing a workload to prove it is within a compliant "Sovereign Zone" without disclosing precise coordinates that could be used for tracking or exploitation. By binding software identities to persistent silicon identities and verified physical residency, this solution establishes a "Silicon-to- Workload" chain of trust. It ensures that sensitive operations are only performed by authorized workloads running on untampered hardware in cryptographically verified, privacy-preserving geographic boundaries, fulfilling the high-assurance requirements of the *WIMSE Architecture* [[I-D.ietf-wimse-architecture]]. |
| | CBOR: Generating Numeric Map Labels from Textual EDN |
| |
|
The Concise Binary Object Representation (CBOR, STD 94 == RFC 8949) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. CBOR diagnostic notation (EDN) is widely used to represent CBOR data items in a way that is accessible to humans, for instance for examples in a specification. Complex examples often use nested maps, the map keys (labels) for each of which are often sourced from different specifications. While the e'' application extension provides a way to import data items, particularly constant values, from a CDDL model, it does not help with automatically selecting the right kind of map depending on its position in the nested maps. // The present document is intended to capture ideas initially // discussed at the CBOR WG interim 2025-06-25 and demonstrate some // design alternatives. It is not ready for adoption yet in any way. |
| | YANG Configuration Templates |
| |
|
NETCONF and RESTCONF protocols provide programmatic interfaces for accessing configuration data modeled by YANG. This document defines the use of a YANG-based configuration template mechanism whereby configuration data can be defined in one or more templates and applied repeatedly. This avoids the redundant definition of identical configuration and ensures the consistency of it, thus allowing devices to be managed more conveniently and efficiently. |
| | Fast Notification for tunnel-based lossless RDMA transmission in WAN |
| |
|
With the rapid development of Large Language Models (LLMs), many emerging AI services require lossless transmission of RDMA traffic over tunnels in Wide Area Network(WAN). Existing network mechanisms were not designed for the responsiveness and scale required by these dynamic services. WAN should support the real-time, lightweight network notification to enhance the responsiveness for traffic engineering, congestion mitigation, and failure protection. This document analyzes typical scenarios where RDMA traffic need to be tunneled across WAN, and proposes fast network notification solutions based on ICMPv6 or UDP. |
| | Source Prefix Advertisement for Inter-domain SAVNET |
| |
|
This document proposes a mechanism that enables neighboring ASes (Source ASes) to actively advertise their locally observed Customer Cone and prefix information via a new inter-domain message called Source Prefix Advertisement (SPA). The validating AS then combines this SPA-carried information with local source address validation- related information to construct more accurate prefix allowlists for interfaces connected to Source ASes. |
| | Path Computation Element Communication Protocol (PCEP) Extensions for Multipath Traffic Engineered Directed Acyclic Graph (MPTED) Tunnels |
| |
|
A Multipath Traffic Engineered Directed Acyclic Graph (MPTED) tunnel is a Traffic Engineering (TE) construct that facilitates weighted load balancing of unicast traffic across a constrained set of paths optimized for a specific objective. This document describes the provisioning of an MPTED Tunnel in a TE network using Path Computation Element Communication Protocol (PCEP) in a stateful PCE model. |
| | X.509 Certificate Extended Key Usage (EKU) for Attestation Keys |
| |
|
X.509 certificates ([RFC5280]) defines the Extended Key Usage (EKU) extension and specifies several key purpose identifiers (KeyPurposeIds) for use with that extension. This document defines a KeyPurposeId for the purpose of signing Evidence to provide remote attestation functions as defined in the RATS Architecture ([RFC9334]). |
| | Hardware-Rooted Attestation for Precision Time Protocol: Scalable Workload Identity and Phased PQC Readiness |
| |
|
This document defines a scalable framework for hardware-rooted cryptographic attestation in the Precision Time Protocol (PTP). Standard PTP security mechanisms rely on symmetric keys, which suffer from identity ambiguity and source non-repudiation failures—vulnerabilities that allow any node possessing the shared secret to impersonate a Grandmaster. To resolve these issues while overcoming the silicon throughput limits of traditional TPMs and the overhead of Post-Quantum Cryptography (PQC), this draft specifies a tiered trust model. A Hardware Root (e.g., TPM) establishes a long- term PQC identity, while a workload identity management plane (e.g., SPIFFE/SPIRE) manages the frequent rotation of short-lived operational keys. These keys perform amortized signing of PTP message batches via Merkle Trees, ensuring wire-speed synchronization and irrefutable provenance for regulated environments. |
| | Geographic Attestation Results |
| |
|
Many workloads have limitations on what geography they are allowed to operate in. This is often due to a regulation that requires that the computation occur in a particular jurisdiction. There are many mechanisms by which Evidence of location may be created and then evaluated by a Verifier. No matter which mechanism is appropriate for a given situation, the result of the Verification can be expressed in a similiarly defined EAT Attestation Result. This document is therefore about encoding a variety of geographical conclusions in an Attestation Result. In addition, one mechanism of directly creating a geographic result in the form of an Endorsement is described in an appendix. |
| | PQC Continuity: Downgrade Protection for TLS Servers Migrating to PQC |
| |
|
As the Internet transitions toward post-quantum cryptography (PQC), many TLS servers will continue supporting traditional certificates to maintain compatibility with legacy clients. However, this coexistence introduces a significant vulnerability: an undetected rollback attack, where a malicious actor strips the PQC or Composite certificate and forces the use of a traditional certificate once quantum-capable adversaries exist. To defend against this, this document defines a TLS extension that allows a TLS peer (typically a client) to cache another peer's (typically a server's) declared commitment to present PQC or composite certificates for a specified duration. On subsequent connections, the caching peer enforces that cached commitment and rejects traditional-only certificates that conflict with it. This mechanism, inspired by HTTP Strict Transport Security (HSTS) but operating at the TLS layer, provides PQC downgrade protection without requiring changes to certificate authority (CA) infrastructure. Although we expect the more common use case to be clients caching server commitments, the mechanism applies symmetrically to server caching of client certificate commitments as well. |
| | Motivations and Problem Statement of Agentic AI for network management |
| |
|
This document outlines the key objectives of introducing Agentic AI to the field of network management and highlights the fundamental issues with existing technologies that must be addressed to achieve these goals. It emphasizes the necessity for relevant groups within the IETF/IRTF and presents the core technological areas requiring standardization. The aim of Agentic AI is to facilitate a paradigm shift in which multiple autonomous AI agents collaborate to fully automate network operation, management and security. |
| | Precise ECN in WAN |
| |
|
This draft defines the precise ECN during used in WAN. With the growing demand for AI computing power, the computational capacity of a single Artificial Intelligence Data Center (AIDC) can no longer meet the requirements of large-scale model training. This has led to the emergence of cross-AIDC distributed model training, driving the need for transmitting RoCEv2 packets over WAN networks. AI training is highly sensitive to network packet loss, where even minimal packet loss can significantly degrade training efficiency. Additionally, elephant flows and extreme concurrent traffic impose higher demands on network performance. ECN achieves active feedback of network congestion by setting ECN flag bits in the header of IP packets, which is an effective traffic control method. RFC6040 introduces the application of ECN in WAN. However, due to the much higher end-to-end delay in WAN than in DC, and the frequent occurrence of instantaneous traffic bursts in WAN, it is easy to trigger ECN at the wrong time. This draft focuses on the precise use of ECN in WAN, by introducing different reactions of ECN in different WAN transmission scenarios |
| | Hybrid Digital Signatures with Strong Unforgeability |
| |
|
This document proposes a generic hybrid signature construction that achieves strong unforgeability under chosen-message attacks (SUF- CMA), provided that the second component (typically the post-quantum one) is SUF-CMA secure. The proposed hybrid construction differs from the current composite hybrid approach by binding the second (post-quantum) signature to the concatenation of the message and the first (traditional) signature. This approach ensures that hybrid signatures maintain SUF-CMA security even when the first component only provides EUF-CMA security. In addition to this general hybrid construction, this document also proposes a non-black-box variant specifically tailored for schemes built from the Fiat-Shamir paradigm. This variant is SUF-CMA secure as long as only one component is SUF-CMA secure. |
| | Scheduling Network Resources for Machine Learning Clusters |
| |
| | draft-kompella-rtgwg-mlnwsched-02.txt |
| | Date: |
01/03/2026 |
| | Authors: |
Kireeti Kompella, Vishnu Beeram, Aditya Mahale, Raghav Bhargava, Nikolas Geyer |
| | Working Group: |
Individual Submissions (none) |
|
Large Language Models (LLMs) are pushing the boundaries of technology. The scale that they have reached currently vastly exceeds the capacity of any single compute unit (XPU); this requires a distributed approach where multiple XPUs are connected via a "backend" network, sometimes in a single data center, but increasingly in multiple data centers connected by a "data center interconnect" (DCI). We are approaching the point where the scale exceeds that of a single data center, thus requiring multiple such data centers connected via a "data center interconnect" network. Training and inferencing are expensive and critical operations, thus they are typically scheduled, i.e., the (compute) resources they need are carefully estimated, allocated and deployed so that these resources are efficiently used. However, while compute investment in these LLM processing clusters dwarfs that of networks, it is becoming increasingly clear that the latter can greatly impact the former. This has been the focus of recent conferences, including the fantel Birds of a Feather meeting in IETF 123, @Scale: Networking 2025 and Open Compute Project 2025. This memo proposes that the same care that is taken regarding allocation of compute resources to jobs be taken with networking resources: that they are estimated, allocated and deployed alongside compute resources; that they have contingency plans in case of network glitches; and that a holistic view be taken in order to optimize job completion times of training and inferencing jobs. |
| | Equipment Capability Application |
| |
|
This document applies the generalized capability principles to the description of equipment (a physical thing) with applied data (configuration state and code (software, firmware etc.)) and shows how such capability specifications integrate with base inventory and entitlement models as defined in Network Inventory, Software Extension and Entitlement YANG models. The approach is examined by example, focusing on how the potential capabilities of each equipment type-version with applied data are described, how these map to entitlements (licensed or policy- controlled subsets of capabilities), and how they are instantiated as inventory items. The explanation covers both the capabilities of equipment in terms of physical properties and the capabilities of equipment with applied data in terms of resultant emergent functionality. |
| | Generalized Capability Principles |
| |
|
This document introduces a framework for capability modeling based on the specification and refinement principles established in ITU-T G.7711 Annex G (also previously published as ONF TR-512.7. See latest G.7711 release) and the modeling boundaries work documented in draft-davis-netmod-modelling-boundaries. The framework defines how component–system capabilities can be explicitly described and refined via a process of pruning, refactoring, and occurrence formation. These capability definitions can target detailed operational considerations, system interactions, licensing, abstract product declarations, or sales and marketing. The framework supports modular, layered, and fractal declarations of networked behavior, and provides a foundation for a suite of future IETF drafts aligned with ongoing work on photonic plug manifests, entitlement/licensing, IVY equipment modeling, energy/thermal considerations and related domains. |
| | OAuth2.0 Extension for Multi-AI Agent Collaboration |
| |
|
This draft proposes an authorization method for task-oriented multi- AI agent collaboration scenarios, where a leading agent coordinates sub-agents to complete complex tasks. The methods extends the OAuth 2.0 protocol by adding fields in token and message flows, enabling sub-agents execute the task as a group. This approach greatly simplifies the authorization process for a task group, avoids efficiency loss from repeated interactions between multiple sub-AI agents and the authorization server, meanwhile maintaining full compatibility with existing OAuth 2.0 workflows. |
| | Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) |
| |
|
The TLS handshake protocol allows authentication of one or both peers using static, long-term credentials. In some cases, it is also desirable to ensure that the peer runtime environment is in a secure state. Such an assurance can be achieved using remote attestation which is a process by which an entity produces Evidence about itself that another party can use to appraise whether that entity is found in a secure state. This document describes a series of TLS extensions that enable the binding of the TLS authentication key to a remote attestation session. This enables an entity capable of producing attestation Evidence, such as a confidential workload running in a Trusted Execution Environment (TEE), or an IoT device that is trying to authenticate itself to a network access point, to present a more comprehensive set of security metrics to its peer. These extensions have been designed to allow the peers to use any attestation technology, in any remote attestation topology, and to use them mutually. |
| | Computing metrics as a service (CMAS) for facilitating traffic steering in CATS framework |
| |
| | draft-zhangb-cats-cmas-02.txt |
| | Date: |
01/03/2026 |
| | Authors: |
Bin Zhang, Yina Dai, Bowen Shen, Weizhe Zhang, Yanchen Qiao |
| | Working Group: |
Individual Submissions (none) |
|
In the context of CATS applications, resource modeling and dynamic scheduling face core challenges: heterogeneous computing resources (e.g., CPUs, GPUs, FPGAs) with differentiated characteristics are difficult to unify through traditional coarse-grained metrics (e.g., virtual machine/container counts). Moreover, dynamically changing resource states (e.g., resource occupancy, service instance load cycles) complicate routing table maintenance in network nodes, creating bottlenecks for resources scheduling. This document provides a service-oriented computing capability modeling framework, abstracting heterogeneous resources into standardized service units for efficient resource modelling and traffic steering. |
| | BMP Statistics Information TLV |
| |
|
The BGP Monitoring Protocol (BMP) defines statistics reports that provide periodic snapshots of various BGP-related metrics. When statistics are reported periodically, the snapshot values may not reflect the variations that occurred between reporting intervals. This document defines a Statistics Information TLV that can be used to convey additional statistical information about BMP gauge-type statistics during the reporting period. This TLV reports the minimum and maximum values observed (with timestamps indicating when they occurred), along with additional statistical measures such as average, median, or snapshot values. This enables BMP collectors to better understand the dynamics of monitored statistics even when the reported snapshot values appear constant. |
| | Considerations for On-Demand Retrieval of Multiple RPKI Object Types |
| |
|
Currently, Relying Parties (RPs) retrieve the complete set of RPKI objects from repositories. This all-or-nothing model increases network traffic, synchronization latency, and computational overhead. This document examines these limitations and outlines directions for enabling more selective and efficient RPKI data access. |
| | Verifiable AI Provenance (VAP) Framework and Legal AI Profile (LAP) |
| |
|
This document specifies the Verifiable AI Provenance (VAP) Framework, a cross-domain upper framework for cryptographically verifiable decision audit trails in high-risk AI systems, along with the Legal AI Profile (LAP), a domain-specific instantiation for legal AI and LegalTech systems. VAP defines common infrastructure including hash chain integrity, digital signatures, unified conformance levels (Bronze/Silver/Gold), external anchoring via RFC 3161 Time-Stamp Protocol and compatible transparency services (including IETF SCITT), a Completeness Invariant pattern guaranteeing no selective logging, standardized Evidence Pack format for regulatory submission, and privacy- preserving verification protocols. LAP extends VAP for the judicial AI domain, addressing unique requirements including attorney oversight verification (Human Override Coverage), three-pipeline completeness invariants for legal consultation, document generation, and fact-checking, tiered content retention with legal hold protocols for judicial discovery compliance, graduated override enforcement mechanisms, and privacy- preserving fields designed to maintain attorney-client privilege while enabling third-party auditability. |
| | Problem Details for Asynchronous Job Failures |
| |
|
HTTP APIs that process work asynchronously need a standard way to report job failures. "Problem Details for HTTP APIs" (RFC 9457) provides the envelope; this document defines extension members that fill it with asynchronous-job-specific context. Eight extension members are specified: "jobId", "jobStatus", "submittedAt", "completedAt", "retryable", "retryAfter", "processingStage", and "correlationId". A ninth member, "results", supports batch operations. Together they let a server describe which job failed, when, at what pipeline stage, and whether a retry is advisable -- in a single, machine-readable JSON (RFC 8259) object that works equally well in an HTTP response body, a message-broker payload, or a webhook callback. Although the primary motivation is structured error reporting for failed jobs, the extension members are equally useful for communicating successful job outcomes (e.g., a COMPLETED status with timing information). This document does NOT redefine how to submit, poll, or cancel asynchronous jobs; those mechanics are already covered by "HTTP Semantics" (RFC 9110) (202 Accepted), "Prefer Header for HTTP" (RFC 7240) (respond-async), and emerging IETF work on long-running operations. Instead, it focuses exclusively on the structured reporting gap that remains after a job reaches a terminal state. |
| | Warrant Certificate Authorities (WCA): Auditable Data Provenance for AI-Agent Tool-Call Chains |
| |
|
Large Language Model (LLM)-based agent systems increasingly invoke external tools and data sources, yet the epistemic provenance of consumed data remains architecturally unregulated. Data crossing tool-call boundaries acquires the apparent trustworthiness of the interface rather than reflecting the institutional standing of its actual source -- a phenomenon termed "semantic laundering." This document specifies the Warrant Certificate Authority (WCA): an end-to-end cryptographic attestation infrastructure that certifies data sources, not data content. WCA introduces a provenance layer satisfying reference monitor properties (complete mediation, tamperproofness, verifiability) for all agent-to-tool interactions. The architecture draws on the PKI trust model, OS provenance paradigms (IMA, CamFlow, LPM), and supply-chain security frameworks (SLSA, in-toto). This document defines data structures for tool-call attestation, warrant certificates, and a trust hierarchy of certificate authorities. It specifies the provenance-layer protocol and introduces Warrant Attestation Levels (WAL-0 through WAL-3) as a graduated adoption framework analogous to SLSA build levels. |
| | Structured and Constraint Extensions for OAuth Scopes |
| |
|
This specification defines an extension to the OAuth 2.0 scope parameter, as specified in RFC 6749, which is used to express the permissions granted to an access token. The proposed extension introduces a structured syntax for scope values to enable fine- grained authorization for the installation and execution of Modular Capability Units (encapsulated and reusable functional modules such as skills) within Agent ecosystems. However, current mechanisms for authorizing such modules generally lack a standardized way to express and obtain consent for the complex, fine-grained permissions they require during installation. This document addresses this limitation by defining a structured format for the scope parameter. The format extends the simple space- delimited strings with a colon-separated syntax: [resource_type]:[action]:[target][:constraints]. This syntax allows for the precise description of permissions for operations such as file system access, command-line execution, network access, tool invocation, and scheduled tasks. These extensions provide a standardized, machine-readable way to request, convey, and validate detailed permissions, thereby enhancing users' security control over their resources while maintaining compatibility with the existing OAuth token issuance and validation flows. |
| | Autonomic SRv6 Network Fast Failover Using Bounce-back Strategy with GRASP |
| |
|
This document specifies an autonomic fast failover mechanism for SRv6 networks using a bounce-back strategy. It uses GRASP to distribute failover protection information, enabling data plane fast reroute without control plane reconvergence. |
| | Task discovery in agentic networks |
| |
| | draft-mapmw-task-discovery-00.txt |
| | Date: |
01/03/2026 |
| | Authors: |
Hesham Moussa, Arashmid Akhavain, Roberto Pioli, Jim Mozley, Nic Williams |
| | Working Group: |
Individual Submissions (none) |
|
This document defines an architectural framework for an open, interoperable ecosystem in which task owners publish tasks—represented as structured task cards—to a task-posting platform, enabling autonomous agents to discover tasks, negotiate execution terms, and coordinate multi-agent collaboration. The architecture introduces a set of functional layers—including the Task Owner Layer, Task Owner Access Layer, Task-Posting Platform, Agentic Layer, Agent Access Layer, and an optional Communication Link—that collectively support secure task publication, agent discovery, capability evaluation, and bilateral negotiation. The framework is designed to accommodate heterogeneous agents with diverse skill sets, trust requirements, and operational models, while ensuring consistent interaction patterns across platforms and vendors. The document also surveys existing agent-discovery approaches, such as A2A, agntcy/OASF, ARDP, and DNS-AID, and identifies gaps that motivate a unified, interoperable model for task-centric and agent-initiated discovery and interaction. It also explores possible ways by which the current approached can enhance the proposed framework. The goal of this architecture is not to replace existing mechanisms but to provide a complementary framework that enables agent–task interactions in scenarios that are difficult to support using traditional agent-to-agent or platform-centric interaction models. The document is concluded with some potential standardization venues for the IETF. |
| | Problem Statement: Information Sharing of Optical Impairments in Monitoring of Multi-Domain All-Optical Paths |
| |
|
In multi-domain all-optical Wavelength Switched Optical Networks (WSONs), end-to-end services may traverse multiple administrative domains operated by different entities. Monitoring such services requires visibility into optical impairments that accumulate across domain boundaries. However, exchanging impairment-related information raises operational, scalability, and confidentiality concerns. Detailed metrics such as attenuation, noise, nonlinear effects, and filtering penalties may be necessary for accurate performance assessment, yet they can expose sensitive topology, equipment, or utilization information. This document describes the problem space associated with sharing optical impairment information across administrative domains for monitoring purposes. It highlights the need to balance operational visibility and confidentiality preservation, and outlines considerations for abstraction, information granularity, and trust relationships among participating operators. |
| | DNS Architecture Considerations for Digital Emblems |
| |
|
It is expected that the Domain Name System (DNS) will be used to publish and retrieve Digital Emblems. The objective of this Internet Draft is to propose an architecture on how the DNS could be used and outline the main challenges that will require work from the diem Working Group. Publication of this document is intended to provoke discussion and analysis of how digital emblems can be deployed in the DNS. |
| | Attested Inference Receipt (AIR): A COSE/CWT Profile for Confidential AI Inference |
| |
|
This document defines the Attested Inference Receipt (AIR), a COSE_Sign1 envelope carrying CWT claims profiled per the Entity Attestation Token (EAT) framework. An AIR receipt binds model identity, input/output hashes, platform attestation metadata, and operational telemetry into a single signed artifact suitable for audit, compliance, and third-party verification of a confidential AI inference event. AIR v1 targets single-inference receipts emitted by workloads running inside hardware-isolated Trusted Execution Environments (TEEs). It supports AWS Nitro Enclaves and Intel TDX measurement formats, with extension points for additional platforms. Pipeline chaining and multi-inference receipts are out of scope for this version. |
| | TLS Authentication for BGP |
| |
|
The Border Gateway Protocol, Version 4 (BGP-4) (RFC 4271) uses TCP (RFC 9293) as its transport layer protocol. There are proposals to run BGP over TLS-based transport protocols, including QUIC. This document discusses authentication considerations for running BGP over TLS protocols and defines a PKI framework to provide for authenticating BGP peering sessions. |
| | AI/ML-Enabled Computing Aware Traffic Steering using IP address anchoring |
| |
|
The IETF CATS WG addresses the problem of how the network infrastructure can steer traffic between clients of a service and sites offering the service, considering both network metrics (such as bandwidth and latency), and compute metrics (such as processing, storage capabilities, and capacity). This document describes solutions to enable the network to select the best site to instantiate a processing service (using distributed sensing as an application example), augmenting CATS enabled solutions that consider both connectivity and computing, to also consider AI/ML and data capabilities and governance policies. |
| | MoQ CDN Provisioning |
| |
|
This document describes concepts related to provisioning MoQ relay scopes on CDN infrastructure, including scope creation, credential- to-scope mapping, and origin fallback configuration. It uses a provisioning API as a vehicle for describing these concepts and identifying areas where common semantics across CDN providers may be needed for multi-CDN compatibility. |
| | PipeStream: A Recursive Entity Streaming Protocol for Distributed Processing over QUIC |
| |
|
This document specifies PipeStream, a recursive entity streaming protocol for hierarchical task decomposition and distributed processing over QUIC transport. PipeStream enables the decomposition ("dehydration") of complex inputs into constituent entities, their transmission across distributed processing nodes, and subsequent rehydration (reassembly) at destination endpoints. The protocol's primary motivating use case is distributed document processing, but its recursive scatter-gather design is applicable to any domain requiring hierarchical decomposition of work units. The protocol employs a dual-stream architecture consisting of a data stream for entity payload transmission and a control stream for tracking entity completion status and maintaining consistency. PipeStream defines four hierarchical data layers for entity representation: BlobBag for raw binary data, SemanticLayer for annotated content with metadata, ParsedData for structured extracted information, and CustomEntity for application-specific extensions. PipeStream is organized into three protocol layers: Layer 0 (Core) provides basic streaming with dehydrate/rehydrate semantics; Layer 1 (Recursive) adds hierarchical scoping and digest propagation; Layer 2 (Resilience) adds yield/resume, claim checks, and completion policies. All implementations support Layer 0; Layers 1 and 2 are optional and negotiated at connection time. To ensure consistency across distributed processing pipelines, PipeStream implements checkpoint blocking, whereby processing nodes synchronize at defined points before proceeding. This mechanism guarantees that all constituent parts of a dehydrated entity are successfully processed before rehydration operations commence. |
| | Factor-based Attestation and Credential Transport Scheme (FACTS) over TLS 1.3 |
| |
|
This document describes FACTS (Factor-based Attestation and Credential Transport Scheme) over TLS 1.3. Conceptually acting as "multi-factor authentication" for machine identities, factor-based attestation derives session trust from multiple independent cryptographic inputs rather than a single point of failure. Specifically, it utilizes a dual-key scheme that binds identity to attestation evidence through the use of key encapsulation material keys (KEM) and traditional identity signing keys (IK), establishing per-session freshness. |
| | Media over QUIC Transport (MOQT) over QMux |
| |
|
This document specifies how Media over QUIC Transport (MOQT) can operate over QMux, enabling MOQT applications to function over reliable byte-oriented streams such as TCP with TLS. By utilizing QMux as an intermediate layer, MOQT deployments gain the ability to fall back to TCP-based transport when UDP is blocked or unreliable, while maintaining API compatibility with QUIC-native implementations. This document analyzes the benefits and trade-offs of this approach and provides implementation guidance for deploying MOQT over QMux. |
| | Service Segmentation Considerations for CATS-MUP |
| |
|
Service segmentation introduces an emerging deployment paradigm in which a service is composed of multiple distributed subtasks forming a service pipeline. This document discusses architectural considerations for a MUP Sequence Session Transform to support ordered traversal across multiple subtask instances and to maintain service continuity during pipeline updates, particularly when stateful subtasks are involved. |
| | BGP Flow Specification Filtered by Destination-QP |
| |
|
BGP Flowspec mechanism (BGP-FS) [RFC8955] [RFC8956] propagates both traffic Flow Specifications and Traffic Filtering Actions by making use of the BGP NLRI and the BGP Extended Community encoding formats. This document specifies a new BGP-FS component type named Destination-QP(Destination Queue Pair) to support filtering by Destination-QP. |
| | GRASP Extensions for CATS Metrics Distribution |
| |
|
Computing-Aware Traffic Steering (CATS) requires distribution of computing metrics across the network to enable efficient traffic steering decisions. The Generic Autonomic Signaling Protocol (GRASP) provides a distributed approach for autonomic node discovery, state synchronization, and parameter negotiation in Autonomic Networking (AN). This document defines extensions to the GRASP protocol to support the distribution of CATS metrics, by specifing the GRASP Objective definition for CATS metrics, structured encodings, distribution mechanisms tailored for dynamic and distributed network scenarios such as edge computing. |
| | Multi-level Congestion Response Framework with Long-haul Congestion Notification for DCI Networks |
| |
| | draft-tian-ccwg-long-haul-cnp-00.txt |
| | Date: |
01/03/2026 |
| | Authors: |
Yuchi Tian, Jin Yang, Weiqiang Cheng, Junjie Wang, Guoying Zhang, Kan Zhang |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies a multi-level congestion response framework and an associated Long-haul Congestion Notification Packet (Long-haul CNP) for Data Center Interconnect (DCI) wide-area network scenarios. The framework defines a graduated congestion response mechanism: lightweight ECN marking for incipient congestion and device- originated Long-haul CNP for severe or rapidly worsening congestion. Long-haul CNP packets carry explicit control instructions (e.g., rate reduction percentage, pause duration) and are sent directly by congestion-aware intermediate nodes to the traffic source via unicast, reducing feedback latency compared to receiver-mediated congestion notification. The document also specifies a multi-device collaborative suppression mechanism and BDP-adaptive dynamic threshold calculation for long-haul links. Two packet encapsulation formats are defined: an ICMPv6 extension and a RoCEv2 backward- compatible extension. |
| | Operational Monitoring of RPKI Repositories Health and Safety |
| |
|
The Resource Public Key Infrastructure (RPKI) relies on a globally distributed set of repositories to deliver signed routing authorization data to Relying Parties (RPs). Internet Service Providers (ISPs) depend on RPs to collect RPKI objects from distributed repositories and validate them cryptographically, resulting in hundreds of thousands of Validated Route origin authorization Payloads (VRPs). Nevertheless, even with multiple RPs deployed, ISPs have limited insight into the operational health and reliability of each repository. When a large number of ROAs suddenly change from valid to unknown or invalid, operators often lack sufficient information to diagnose the cause, which may stem from an outage or instability in a specific repository. Consequently, ISPs cannot easily determine whether these changes are caused by routine updates, malicious behavior, or underlying repository instability. Consequently, ISPs cannot easily determine whether these changes are caused by routine updates, malicious behavior, or underlying repository instability. This document provides operational guidance for monitoring the health and safety of RPKI repositories on a per- repository basis. It defines measurable indicators related to reachability, availability, and content integrity, and explains how these metrics can be used to detect degraded performance or potentially unsafe repository behavior. The document discusses and provides recommendations for repositories alerting and operational response. The goal is to improve the transparency, operational availability and security of the RPKI ecosystem. |
| | Broadband Network UP-Specific Information Suboption for the DHCP Relay Agent Option |
| |
|
This document defines a new Broadband Network UP-Specific Information suboption for the Dynamic Host Configuration Protocol’s (DHCP) relay agent information option. The suboption allows the DHCP relay agent (Broadband Network CP) to include UP-specific information in the DHCP messages it forwards, to ensure that subscribers within the same SGRP under the same UP are assigned IP addresses from the same address space by the DHCP server. |
| | Additional Extensions for the More Instant Messaging Interoperablility (MIMI) Content Format |
| |
|
This document defines some new useful extensions for the MIMI content format. |
| | ESP Protection for Services over SRv6 |
| |
|
This document describes a mechanism for protecting selected service traffic using IPsec ESP while transporting the traffic over an SRv6 Policy. The approach enables service payloads to be encrypted prior to SRv6 encapsulation, allowing the SRv6 header to remain visible for segment-based forwarding within the provider network. This mechanism supports services or applications that require additional confidentiality and integrity protection, even when carried over an operator-managed SRv6 domain. The document also outlines how the necessary parameters can be signaled using BGP. |
| | Path Computation Element Communication Protocol (PCEP) Extension for Fine Granularity Metro Transport Network (fgMTN) Path Setup |
| |
| | draft-han-pce-fgmtn-setup-00.txt |
| | Date: |
01/03/2026 |
| | Authors: |
Liuyan Han, Haibin Huang, Minxue Wang, Jin Zhou, Li Zhang |
| | Working Group: |
Individual Submissions (none) |
|
This document focuses on the PCEP extension for G.8312 fine granularity metro transport network. It provides the PCEP considerations on the path setup requirements of PCEP extension in fgMTNP. |
| | PCEP LS Extensions for Fine Granularity Metro Transport Network (fgMTN) Topology Resource Information Reporting |
| |
|
This document extends PCEP-LS by defining several new sub-TLVs for the LS object to report the fgMTN topology resource information, which includes timeslot occupation status of links and the relationship between the FGU client and the occupied timeslots. |
| | A Framework for Compute-Aware Task Placement and Traffic Steering in Heterogeneous Computing Networks |
| |
|
The increasing deployment of geographically distributed computing infrastructures equipped with heterogeneous compute resources (e.g., CPU, GPU, memory) has motivated new architectural approaches for jointly optimizing task placement and traffic steering. In heterogeneous computing networks, tasks must be assigned to compute- capable nodes while respecting multi-dimensional resource constraints and network bandwidth limitations. This document presents a conceptual framework for Compute-Aware Task Placement and Traffic Steering (CATPTS). The framework models a computing network as a directed graph containing compute-capable nodes and forwarding-only nodes. Task execution location selection and two-stage traffic steering are jointly optimized under link bandwidth and multi-dimensional compute capacity constraints. The objective is to achieve global load balancing across compute and network resources. This document defines the architectural principles, conceptual model, terminology, and optimization formulation underlying such systems. It does not specify protocol mechanisms. |
| | Application-Agnostic Demonstration Proof of Possession (DPoP) Framework |
| |
|
This document describes a generic framework for Demonstrating Proof of Possession (DPoP) that extends beyond HTTP-specific implementations. Building upon RFC 9449, this framework provides a protocol-agnostic approach for sender-constraining tokens through cryptographic proof of possession, enabling secure token binding across various application protocols and contexts. The framework supports both JWT-based proofs (for compatibility with existing OAuth deployments) and CWT-based proofs (for compact binary encoding and interoperability with Common Access Token systems). |
| | Network Time Protocol Version 5 |
| |
|
The Network Time Protocol (NTP) is a widely deployed protocol that allows hosts to obtain the current time of day from time servers. This document specifies version 5 of the protocol (NTPv5), which adopts a client-server model as its sole mode of operation. Legacy operational modes supported in earlier versions have been removed to improve protocol robustness and clarity. While this specification defines the protocol used for time distribution, it does not define the algorithms or heuristics employed by clients to determine or adjust their local time. |
| | OAuth Client ID Metadata Document |
| |
|
This specification defines a mechanism through which an OAuth client can identify itself to authorization servers, without prior dynamic client registration or other existing registration. This is through the usage of a URL as a client_id in an OAuth flow, where the URL refers to a document containing the necessary client metadata, enabling the authorization server to fetch the metadata about the client as needed. |
| | Procedures for Communication between Stateful Path Computation Elements |
| |
| | draft-ietf-pce-state-sync-13.txt |
| | Date: |
01/03/2026 |
| | Authors: |
Haomian Zheng, Stephane Litkowski, Siva Sivabalan, Cheng Li |
| | Working Group: |
Path Computation Element (pce) |
|
The Path Computation Element (PCE) Communication Protocol (PCEP) provides mechanisms for PCEs to perform path computation in response to a Path Computation Client (PCC) request. The Stateful PCE extensions allow stateful control of Multi-Protocol Label Switching (MPLS) Traffic Engineering (TE) and Generalized Multi-Protocol Label Switching (GMPLS) Label Switched Paths (LSPs) using PCEP. A Path Computation Client (PCC) can synchronize LSP state information to a Stateful Path Computation Element (PCE). A PCC can have multiple PCEP sessions towards multiple PCEs. In some use cases, inter-PCE stateful communication can bring additional resiliency in the design, for instance, when some PCC-PCE session fails. This document describes the procedures to allow stateful communication between PCEs for various use cases, and also the procedures to prevent computational loops. |
| | Evidence Encoding for Hardware Security Modules |
| |
| | draft-ietf-rats-pkix-key-attestation-03.txt |
| | Date: |
01/03/2026 |
| | Authors: |
Mike Ounsworth, Jean-Pierre Fiset, Hannes Tschofenig, Henk Birkholz, Monty Wiseman, Ned Smith |
| | Working Group: |
Remote ATtestation ProcedureS (rats) |
|
This document specifies a vendor-agnostic format for Evidence produced and verified within a PKIX context. The Evidence produced this way includes claims collected about a cryptographic module, such as a Hardware Security Module (HSM), and elements found within it such as cryptographic keys. One scenario envisaged is that the state information about the cryptographic module can be securely presented to a remote operator or auditor in a vendor-agnostic verifiable format. A more complex scenario would be to submit this Evidence to a Certification Authority to aid in determining whether the storage properties of this key meet the requirements of a given certificate profile. This specification also offers a format for requesting a cryptographic module to produce Evidence tailored for expected use. |
| | Inter-domain Source Address Validation (SAVNET) Architecture |
| |
|
This document introduces an inter-domain SAVNET architecture for performing AS-level SAV and provides a comprehensive framework for guiding the design of inter-domain SAV mechanisms. The proposed architecture empowers ASes to generate SAV rules by sharing SAV- specific information between themselves, which can be used to generate more accurate and trustworthy SAV rules in a timely manner compared to the general information. During the incremental or partial deployment of SAV-specific information, it can utilize general information to generate SAV rules, if an AS's SAV-specific information is unavailable. Rather than delving into protocol extensions or implementations, this document primarily concentrates on proposing SAV-specific and general information and guiding how to utilize them to generate SAV rules. To this end, it also defines some architectural components and their relations. |
| | A YANG Data Model for MPLS-TE Topology |
| |
|
This document defines a YANG data model for representing, retrieving, and manipulating MPLS-TE network topologies. It is based on and augments existing YANG models that describe network and traffic engineering packet network topologies. This document also defines a collection of common YANG data types and groupings specific to MPLS-TE. These common types and groupings are intended to be imported by modules that model MPLS-TE technology- specific configuration and state capabilities. The YANG models defined in this document can also be used for MPLS Transport Profile (MPLS-TP) network topologies. |
| | WIMSE Workload-to-Workload Authentication with HTTP Signatures |
| |
|
The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones to complex multi-service, multi-cloud, multi-tenant deployments. This document defines one of the mechanisms to provide workload authentication, using HTTP Signatures. While only applicable to HTTP traffic, the protocol provides end-to-end protection of requests (and optionally, responses), even when service traffic is not end-to-end encrypted, that is, when TLS proxies and load balancers are used. Authentication is based on the Workload Identity Token (WIT). |