| |
|
| |
| | Protocol-Specific Profiles for JSContact |
| |
|
This document defines JSContact profiles, an IANA registry for named subsets of JSContact elements. It aims to facilitate using JSContact in context of contact data exchange protocols or other use cases, in which supporting all JSContact semantics might be inappropriate. |
| | Extensible Delegation for DNS |
| |
| | draft-ietf-deleg-07.txt |
| | Date: |
06/02/2026 |
| | Authors: |
Petr Spacek, Ralf Weber, tale |
| | Working Group: |
DNS Delegation (deleg) |
|
This document proposes a new extensible method for the delegation of authority for a domain in the Domain Name System (DNS) using DELEG and DELEGPARAM records. A delegation in the DNS enables efficient and distributed management of the DNS namespace. The traditional DNS delegation is based on NS records which contain only hostnames of servers and no other parameters. The new delegation records are extensible, can be secured with DNSSEC, and eliminate the problem of having two sources of truth for delegation information. |
| | Operational Recommendations for DS Automation |
| |
|
Enabling support for automatic acceptance of DS parameters from the Child DNS operator (via RFCs 7344, 8078, 9615) requires the parental agent, often a registry or registrar, to make a number of technical decisions around acceptance checks, error and sucess reporting, and multi-party issues such as concurrent updates. This document describes how these points are best addressed in practice. |
| | Certificate Management over CMS (CMC) |
| |
|
This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet Public Key Infrastructure (PKI) community: |
| | Certificate Management over CMS (CMC): Transport Protocols |
| |
|
This document defines a number of transport mechanisms that are used to move CMC (Certificate Management over CMS (Cryptographic Message Syntax)) messages. The transport mechanisms described in this document are HTTP, file, mail, and TCP. This document obsoletes RFC 5273 and RFC 6402. |
| | Certificate Management Messages over CMS (CMC): Compliance Requirements |
| |
|
This document provides a set of compliance statements about the CMC (Certificate Management over CMS) enrollment protocol. The ASN.1 structures and the transport mechanisms for the CMC enrollment protocol are covered in other documents. This document provides the information needed to make a compliant version of CMC. This document obsoletes RFC 5274 and RFC 6402. |
| | MPLS Network Action (MNA) Sub-Stack Specification including In-Stack Network Actions and Data |
| |
| | draft-ietf-mpls-mna-hdr-20.txt |
| | Date: |
06/02/2026 |
| | Authors: |
Jaganbabu Rajamanickam, Rakesh Gandhi, Royi Zigler, Haoyu Song, Kireeti Kompella |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
|
This document specifies the MPLS Network Actions (MNA) sub-stack for carrying Network Actions and Ancillary Data in the MPLS label stack. MNA can be used to influence packet forwarding decisions, carry additional Operations, Administration, and Maintenance information in the MPLS packet or perform user-defined operations. |
| | Extensible YANG Model for YANG-Push Notifications |
| |
|
This document defines a new extensible Notification structure, defined in YANG, for use in YANG-Push Notification messages, both for NETCONF and RESTCONF, enabling any YANG-compatible encodings such as XML, JSON, or CBOR. Additionally, it defines two essential extensions to this structure, the support of a hostname and a sequence number and the support of a timestamp characterizing the moment when the data was observed. |
| | CBOR Encoding for HTTPS-based YANG Notifications Transport |
| |
|
This document extends [I-D.draft-ietf-netconf-https-notif] by introducing CBOR encoding for YANG notifications over HTTPS Transport in addition to the existing JSON and XML encoding schemes. |
| | PCEP Extension for Distribution of Link-State and TE Information for Optical Networks |
| |
| | draft-lee-pce-pcep-ls-optical-16.txt |
| | Date: |
06/02/2026 |
| | Authors: |
Yang Zhao, Haomian Zheng, Daniele Ceccarelli, Wei Wang, Peter Park, Bin Yoon, Adrian Farrel |
| | Working Group: |
Individual Submissions (none) |
|
In order to compute and provide optimal paths, Path Computation Elements (PCEs) require an accurate and timely Traffic Engineering Database (TED). This Link State and TE information has previously been obtained from a link state routing protocol that supports traffic engineering extensions. An existing experimental document extends the Path Computation Element Communication Protocol (PCEP) with Link-State and Traffic Engineering (TE) Information. This document provides further experimental extensions to collect Link-State and TE information for optical networks. |
| | 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. |
| | SCION Data Plane |
| |
|
This document describes the Data Plane of SCION (Scalability, Control, and Isolation On Next-generation networks), a path-aware, inter-domain network architecture. Unlike IP-based forwarding, SCION embeds inter-domain forwarding directives in the packet header, enabling endpoints to construct and select end-to-end paths from segments discovered by the Control Plane. The role of the Data Plane is to combine such segments into end-to-end paths, and to forward data according to the specified path. This document describes the SCION packet format, header structure, and extension headers. It also describes the cryptographic mechanisms used for path authorization, processing at routers including a life of a packet example. This document contains new approaches to secure path aware networking. It is not an Internet Standard, has not received any formal review of the IETF, nor was the work developed through the rough consensus process. The approaches offered in this work are offered to the community for its consideration in the further evolution of the Internet. |
| | Transmission of IP Packets over Overlay Multilink Network (OMNI) Interfaces |
| |
|
Mobile nodes that operate in air/land/sea/space domains (e.g., aircraft of various configurations, terrestrial vehicles, seagoing vessels, space systems, enterprise wireless devices, pedestrians with cell phones, etc.) configure mobile routers to connect end user network peers with Internetwork correspondents over wireless and/or wired-line data links. This document presents a multilink virtual interface specification that supports mobile node coordination with a network-based mobility service, fixed node correspondents and/or other mobile node peers. The virtual interface provides an adaptation layer service that supports secure global mobile Internetworking. This document specifies the transmission of IP packets over Overlay Multilink Network (OMNI) Interfaces. |
| | BGP Extensions of SR Policy for Composite Candidate Path |
| |
|
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is associated with one or more candidate paths. A candidate path is either dynamic, explicit or composite. This document defines extensions to BGP to distribute SR policies carrying composite candidate path information. So that composite candidate paths can be installed when the SR policy is applied. |
| | ISIS Hierarchical SNPs |
| |
|
The document presents an optional new type of SNP called a Hierarchical SNP (HSNP). When feasible, it compresses traditional CSNP exchanges into a Merkle tree-like structure, which speeds up synchronization of large databases and adjacency numbers while reducing the load from regular CSNP exchanges during normal operation. |
| | BGP extensions for SRv6/MPLS Transport Interworking |
| |
|
This document defines the BGP extensions required to provide transport interworking between SRv6 and MPLS in SRv6 deployment. |
| | x509 Decentralized Identifier |
| |
| | draft-birkholz-did-x509-02.txt |
| | Date: |
06/02/2026 |
| | Authors: |
Maik Riechert, Antoine Delignat-Lavaud, Henk Birkholz, Amaury Chamayou |
| | Working Group: |
Individual Submissions (none) |
|
This document defines the did:x509 decentralized identifier method, which enables a direct, resolvable binding between X.509 certificate chains and compact issuer identifiers (DID string). In particular, the did:x509 identifier format in this documents comes with a CWT Claims definition. In general, this identifier is a compact and interoperable mechanism for certificate-based identification by combining a certificate fingerprint with optional policies for subject names, subject alternative names, extended key usage, and issuer information. It is especially useful for policy evaluation and reference in transparency services and similar systems requiring cryptographic binding to certificate material. This Informational document is published as an Independent Submission to improve interoperability with Microsoft's architecture. It is not a standard nor a product of the IETF. |
| | DetNet EDP Interoperation |
| |
|
This document analyzes the interoperation between different EDP solutions. It also suggests which metadata should be used as common fields. |
| | Cross-Domain AuthZ Information sharing for Agents |
| |
| | draft-diaconu-agents-authz-info-sharing-00.txt |
| | Date: |
06/02/2026 |
| | Authors: |
Jean Diaconu, Marcelo Yannuzzi, Herve Muyal, Frank Brockners, Nik Kale, Ankit Agarwal, Jeffrey Hickman, Amritha Lal |
| | Working Group: |
Individual Submissions (none) |
|
Distributed Multi-Agent Systems consist of Agents and MCP Servers operating across multiple administrative domains, each with its own Identity Providers (IdPs) and Authorization Servers (AS). This document discusses the challenges and solution approaches for sharing authorization information securely and flexibly across domains, including the use of dynamic identity, interoperable claims, and verifiable credentials. |
| | The "llm" URI Scheme |
| |
|
This document defines the "llm" Uniform Resource Identifier (URI) scheme for identifying Large Language Model (LLM) endpoints and their configuration. The scheme encodes provider host, model identifier, authentication credentials, and inference parameters into a single, portable connection string, analogous to database connection URIs such as those used by PostgreSQL and MongoDB. This document registers the scheme name in the IANA "Uniform Resource Identifier (URI) Schemes" registry as a provisional registration per RFC 7595. |
| | Proof of Process: An Evidence Framework for Digital Authorship Attestation |
| |
|
This document specifies Proof of Process (PoP), an evidence framework for digital authorship attestation. The framework produces tamper- evident, independently verifiable process evidence describing how documents evolve over time, without capturing document content or keystroke data. Proof of Process implements a specialized profile of the Remote ATtestation procedureS (RATS) architecture, extending it with behavioral entropy bindings, Verifiable Delay Function (VDF) temporal proofs, and a taxonomy of absence claims with explicit trust requirements. The specification defines two complementary CBOR- encoded formats: Evidence Packets (.pop) produced by Attesters during document authorship, and Attestation Results (.war) produced by Verifiers after appraising Evidence. The framework is designed around four core principles: privacy by construction (no content storage), zero trust (locally generated, independently verifiable), evidence over inference (observable facts, not conclusions), and cost-asymmetric forgery (expensive to fake, not impossible). This specification does not address AI detection, stylometric analysis, or intent inference. |
| | Proof of Process CDDL Schema |
| |
|
This document provides the normative Concise Data Definition Language (CDDL) schema for the Proof of Process specification. The schema defines the complete wire format for Evidence Packets (.pop files) and Attestation Results (.war files) as specified in the companion architecture document. |
| | Proof of Process: Worked Examples |
| |
|
This document provides worked examples demonstrating the Proof of Process Evidence format and Attestation Results. Examples include minimal Evidence packets, multi-checkpoint scenarios, jitter seal verification, VDF causality chains, and salt mode configurations. This companion document supplements the main Proof of Process specification with practical reference implementations. |
| | OAuth Identity and Authorization Chaining Across Domains |
| |
| | draft-ietf-oauth-identity-chaining-07.txt |
| | Date: |
06/02/2026 |
| | Authors: |
Arndt Schwenkschuster, Pieter Kasselman, Kelley Burgin, Michael Jenkins, Brian Campbell |
| | Working Group: |
Web Authorization Protocol (oauth) |
|
This specification defines a mechanism to preserve identity and authorization information across trust domains that use the OAuth 2.0 Framework. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (oauth@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/oauth/. Source for this draft and an issue tracker can be found at https://github.com/oauth-wg/oauth-identity-chaining. |
| | Path Computation Element Communication Protocol (PCEP) extensions for Circuit Style Policies |
| |
|
Segment Routing (SR) enables a node to steer packet flows along a specified path without the need for intermediate per-path states, due to the utilization of source routing. An SR Policy can consist of one or a set of candidate paths, where each candidate path is represented by a segment list or a set of segment lists, which are essentially instructions that define a source-routed path. This document specifies a set of extensions to the Path Computation Element Communication Protocol (PCEP) for Segment Routing Policies that are designed to satisfy requirements for connection-oriented transport services (Circuit-Style SR policies). They include the ability to control path modification and the option to request a strict hop-by-hop path, being also applicable for generic SR policy use cases where controlling path modification or deterministic and persistent path requirements are applicable. |
| | A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network |
| |
| | draft-ietf-rtgwg-atn-bgp-30.txt |
| | Date: |
06/02/2026 |
| | Authors: |
Fred Templin, Greg Saccone, Gaurav Dawra, Acee Lindem, Victor Moreno |
| | Working Group: |
Routing Area Working Group (rtgwg) |
|
The International Civil Aviation Organization (ICAO) is investigating mobile routing solutions for a worldwide Aeronautical Telecommunications Network with Internet Protocol Services (ATN/IPS). The ATN/IPS will eventually replace existing communication services with an IP-based service supporting pervasive Air Traffic Management (ATM) for Air Traffic Controllers (ATC), Airline Operations Controllers (AOC), and all commercial aircraft worldwide. This informational document describes a simple and extensible mobile routing service based on the industry-standard Border Gateway Protocol (BGP) to address the ATN/IPS requirements. |
| | A Profile for Autonomous System Provider Authorization |
| |
| | draft-ietf-sidrops-aspa-profile-22.txt |
| | Date: |
06/02/2026 |
| | Authors: |
Alexander Azimov, Eugene Uskov, Randy Bush, Job Snijders, Russ Housley, Ben Maddison |
| | Working Group: |
SIDR Operations (sidrops) |
|
This document defines a Cryptographic Message Syntax (CMS) protected content type for Autonomous System Provider Authorization (ASPA) objects for use with the Resource Public Key Infrastructure (RPKI). An ASPA is a digitally signed object through which the issuer (the holder of an Autonomous System identifier), can authorize one or more other Autonomous Systems (ASes) as its upstream providers. When validated, an ASPA's eContent can be used for detection and mitigation of route leaks. |
| |
|
| |
| | Report from the IAB/W3C Workshop on Age-Based Restrictions on Content Access |
| |
|
The Workshop on Age-Based Restrictions on Content Access was convened by the Internet Architecture Board (IAB) and World Wide Web Consortium (W3C) in October 2025. This report summarizes its significant points of discussion and identifies topics that may warrant further consideration and work. Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB or W3C views and positions. |
| | BGP SR Policy Extensions for metric |
| |
|
SR Policy candidate paths can be represented in BGP UPDATE messages. BGP can then be used to propagate the SR Policy candidate paths to the headend nodes in the network. After SR Policy is installed on the ingress node, the packets can be steered into SR Policy through route selection. Therefore, route selection may be performed on the ingress node of the SR Policy. If there are multiple routes to the same destination, the route selection node can select routes based on the local policy. The local policy may use the IGP metric of the selected path, which is the IGP Metric of the SR Policy. Thus the BGP UPDATE message needs to carry the metric of each segment list of the SR Policy Candidate Path, which can be used in path selection of routing. |
| | A Base YANG Data Model for Network Inventory |
| |
|
This document defines a base YANG data model for reporting network inventory. The scope of this base model is set to be application- and technology-agnostic. The base data model can be augmented with application- and technology-specific details. |
| | Composite ML-DSA for use in Cryptographic Message Syntax (CMS) |
| |
|
Composite ML-DSA defines combinations of ML-DSA with RSA, ECDSA, and EdDSA. This document specifies the conventions for using Composite ML-DSA algorithms within the Cryptographic Message Syntax (CMS). |
| | BGP SR Policy Extensions for template |
| |
|
Segment Routing(SR) Policies can be advertised using BGP. An SR Policy may has lots of attributes, and as the application and features evolve, the SR Policy may need have more and more attribute attributes. To avoid modifying BGP when attributes are added to an SR Policy, we can define a template. The identifier and content of the template are defined by the receiver of the SR Policy. The advertiser of an SR policy only needs to know the ID of the template. When advertising SR policy, the advertiser carries the template ID in the tunnel encapsulation information of the SR policy. After receiving the SR Policy information, the receiver obtains the corresponding template and content according to the template ID, thereby obtaining abundant constraint configuration information. |
| | Supplement of BGP-LS Distribution for SR Policies and State |
| |
|
This document supplements additional information of the segment list in the BGP-LS advertisement for SR Policy state information. A new flag and a new sub-TLV are introduced in the SR Segment List TLV of BGP-LS SR Policy Candidate Path NLRI. |
| | SRv6 SFC Architecture with SR-aware Functions |
| |
|
This document describes the architecture of Segment Routing over IPv6 (SRv6) Service Function Chaining (SFC) with SR-aware functions. This architecture provides the following benefits: * Comprehensive Management: a centralized controller for SFC, handling SR Policy, link-state, and network metrics. * Simplicity: no SFC proxies, which reduces the number of nodes and address resource consumption. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Source Packet Routing in Networking Working Group mailing list (spring@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/spring/. Source for this draft and an issue tracker can be found at https://github.com/watal. |
| | Data Plane Failure Detection Mechanisms for EVPN over SRv6 |
| |
|
For MPLS EVPN, RFC9489 specifies the mechanisms for detecting data plane failures using LSP Ping. This document proposes a similar mechanism to detect data plane failures for EVPN over SRv6. |
| | Securing BPSec Against Arbitrary Packet Dropping |
| |
| | draft-tian-dtn-sbam-02.txt |
| | Date: |
05/02/2026 |
| | Authors: |
Benjamin Dowling, Britta Hale, Xisen Tian, Bhagya Wimalasiri |
| | Working Group: |
Individual Submissions (none) |
|
In this document we describe Strong Bundle Protocol Audit Mechanism (SBAM), an authentication protocol designed to provide cryptographic auditing services for the Bundle Security protocol. |
| | Interface to In-Network Computing Functions for Cooperative Intelligent Transportation Systems |
| |
| | draft-an-nmrg-i2icf-cits-01.txt |
| | Date: |
05/02/2026 |
| | Authors: |
Byoungman An, Jaehoon Jeong, Pusik Park, Soohyun Jang |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies a structured framework for orchestrating, managing, and monitoring In-Network Computing Functions (ICFs) in Cooperative Intelligent Transportation Systems (C-ITS). For example, in the context of Vehicle-to-Everything (V2X) communications, efficient management of Vehicle-to-Vehicle (V2V) communications and their integration with C-ITS can greatly benefit from in-network computing. By leveraging ICFs, it becomes possible to optimize real- time communication, streamline traffic management, and enhance data processing and security services at the network edge. Moreover, by incorporating the Agent-to-Agent (A2A) communication paradigm, intelligent agents within vehicles, Roadside Units (RSUs), and network domains can directly collaborate to negotiate resources, exchange contextual information, and coordinate computing tasks, enabling adaptive and scalable orchestration across multi-domain C-ITS environments. |
| | Computing metrics as a service (CMAS) for facilitating traffic steering in CATS framework |
| |
|
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. |
| | Intent-based Agent Interconnection Protocol at Agent Gateway |
| |
|
This document specifies the Intent-based Agent Interconnection Protocol (IAIP) operating at the Agent Gateways (AG), which defines the interaction mechanisms between AI Agents (at the Agent Domain) and the AG (at the Interconnection Services Domain). This specification focuses on dynamic interconnection among agents based on semantic intent, rather than static network addressing alone. This protocols defines the mechanisms for agent registration via capability advertisement, Gateway Validation, Intent Resolution and Matching, Routing Decisions and Forwarding, enabling the discovery, selection and dispatching of intent queries based on agent capabilities and task requirements at AG. |
| | MANET Internetworking with AERO/OMNI |
| |
|
[RFC2501] defines a MANET as "an autonomous system of mobile nodes. The system may operate in isolation, or may have gateways to and interface with a fixed network" (such as the global public Internet). This document presents a MANET Internetworking framework based on the Automatic Extended Route Optimization (AERO) and Overlay Multilink Network (OMNI) Interface technologies. |
| | Using the MLS Handshake in TLS 1.3 |
| |
|
This document specifies an extension to the Transport Layer Security (TLS) Protocol Version 1.3 that allows TLS clients and servers to use the Message Layer Security (MLS) Protocol handshake to establish the shared secret instead to the traditional shared secret establishment mechanism. The MLS protocol provides straightforward mechanism to update the shared secret that can be initiated by either the client or the server during the TLS session, and each epoch provides forward security and post-compromise security. |
| | Multi-agent Collaboration Protocol Suite based on Agent Gateway |
| |
|
This document specifies a Multi-agent Collaboration Protocol Suite based on Agent Gateway, which enables scalable, secure, and semantically driven collaboration among distributed agents across heterogeneous networks. The protocol suite introduces Agent Gateways as control-plane entities responsible for agent registration, authentication, capability management, semantic routing and other functions, while preserving direct peer-to-peer semantic interactions among agents. |
| | A Profile for ROV Deployment Transparency |
| |
|
This document defines a Cryptographic Message Syntax (CMS) protected content type for ROV Deployment Transparency (ROV_TAG) objects for use with the Resource Public Key Infrastructure (RPKI). An ROV_TAG is a digitally signed object through which an Autonomous System (AS) that has deployed Route Origin Validation (ROV) can declare its ROV deployment status. When validated, an ROV_TAG's eContent can be used by ASes to identify which ASes have deployed ROV, enabling secure path selection and optimized ROV validation that reduces redundant validation operations in partial ROV deployment scenarios. |
| | SD-JWT-based Verifiable Digital Credentials (SD-JWT VC) |
| |
|
This specification describes data formats as well as validation and processing rules to express Verifiable Digital Credentials with JSON payloads with and without selective disclosure based on the SD-JWT [RFC9901] format. |
| | The "_for-sale" Underscored and Globally Scoped DNS Node Name |
| |
|
This document defines an operational convention that uses the reserved underscored DNS leaf node name "_for-sale" to indicate the parent domain name is available for purchase. The convention can be deployed without disrupting existing operations, and it may be applied even when the domain name is still actively in use. |
| | QUIC Acknowledgment Frequency |
| |
|
This document specifies an extension to QUIC that enables an endpoint to request its peer change its behavior when sending or delaying acknowledgments. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=quic. Source code and issues list for this draft can be found at https://github.com/quicwg/ack-frequency. Working Group information can be found at https://github.com/quicwg. |
| | 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. |
| | Constraining RPKI Trust Anchors |
| |
|
This document describes an approach for Resource Public Key Infrastructure (RPKI) Relying Parties (RPs) to impose locally configured Constraints on cryptographic products subordinate to Trust Anchors (TAs). The ability to constrain a Trust Anchor operator's effective signing authority to a limited set of Internet Number Resources (INRs) allows Relying Parties to enjoy the potential benefits of assuming trust - within a bounded scope. The specified approach and configuration format allow RPKI operators to communicate efficiently about observations related to Trust Anchor operations. |
| | A YANG Data Model for requesting path computation |
| |
|
There are scenarios, typically in a hierarchical Software-Defined Networking (SDN) context, where the topology information provided by a Traffic Engineering (TE) network provider may be insufficient for its client to perform multi-domain path computation. In these cases the client would need to request the TE network provider to compute some intra-domain paths to be used by the client to choose the optimal multi-domain paths. This document provides a mechanism to request path computation by augmenting the Remote Procedure Calls (RPCs) defined in RFC YYYY. [RFC EDITOR NOTE: Please replace RFC YYYY with the RFC number of draft-ietf-teas-yang-te once it has been published. Moreover, this document describes some use cases where the path computation request, via YANG-based protocols (e.g., NETCONF or RESTCONF), can be needed. |
| | Framework for Multi-domain IPv6-only Underlay Network and IPv4-as-a-Service |
| |
|
For the IPv6 transition, IPv6-only is considered the final stage where only IPv6 protocol is used for transport while maintaining global reachability for both IPv6 and IPv4 services. This document introduces a framework for a multi-domain IPv6-only underlay network from the perspective of network operators. In particular, it proposes stateless address mapping as the basis for enabling IPv4 service data transmission in a multi-domain IPv6-only environment (i.e., IPv4-as-a-Service). It describes the methodology of stateless IPv4/IPv6 mapping, illustrates the behaviors of network devices, analyzes the options of IPv6 mapping prefix allocation, and discusses the security considerations. This framework is not intended to replace existing IPv6-only technologies, but rather to leverage or remain compatible with them. |
| |
|
| |
| | YANG Data Models for the Application-Layer Traffic Optimization (ALTO) Protocol |
| |
| | draft-ietf-alto-oam-yang-18.txt |
| | Date: |
04/02/2026 |
| | Authors: |
Jingxuan Zhang, Dhruv Dhody, Kai Gao, Roland Schott, Qiufang Ma |
| | Working Group: |
Application-Layer Traffic Optimization (alto) |
|
This document defines a YANG data model for Operations, Administration, and Maintenance (OAM) & Management of the Application-Layer Traffic Optimization (ALTO) Protocol. The operator of an ALTO server can use this data model to (1) set up the ALTO server, (2) configure server discovery, (3) create, update and remove ALTO information resources, (4) manage the access control of each ALTO information resource, and (5) collect statistical data from the ALTO server. The application provider can also use this data model to configure ALTO clients to communicate with known ALTO servers. |
| | Weighted Multi-Path Procedures for EVPN Multi-Homing |
| |
| | draft-ietf-bess-evpn-unequal-lb-31.txt |
| | Date: |
04/02/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. |
| | A YANG Data Model for Transport Network Client Signals |
| |
|
A transport network is a server-layer network to provide connectivity services to its client. The topology and tunnel information in the transport layer has already been defined by generic Traffic- engineered models and technology-specific models (e.g., OTN, WSON). However, how the client signals are accessing to the network has not been described. These information is necessary to both client and provider. This draft describes how the client signals are carried over transport network and defines YANG data models which are required during configuration procedure. More specifically, several client signal (of transport network) models including ETH, STM-n, FC and so on, are defined in this draft. |
| | 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. |
| | Media Access Control (MAC) Addresses in X.509 Certificates |
| |
| | draft-ietf-lamps-macaddress-on-05.txt |
| | Date: |
04/02/2026 |
| | Authors: |
Russ Housley, Corey Bonnell, Joe Mandel, Tomofumi Okubo, Michael StJohns |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
This document defines a new GeneralName.otherName for inclusion in the X.509 Subject Alternative Name (SAN) and Issuer Alternative Name (IAN) extensions to carry an IEEE Media Access Control (MAC) address. The new name form makes it possible to bind a layer-2 interface identifier to a public key certificate. Additionally, this document defines how constraints on this name form can be encoded and processed in the X.509 Name Constraints extension (NCE). |
| | YANG Groupings for HTTP Clients and HTTP Servers |
| |
|
This document presents three YANG 1.1 modules as follows. The "iana- http-versions" module defines a YANG "typedef" for HTTP protocol versions. The "ietf-http-client" module defines a YANG "grouping" for configuring an HTTP client's ability to communicate with an HTTP service endpoint. The "ietf-http-server" module defines a "grouping" for configuring an HTTP server's service endpoints. |
| | Subscription to Notifications in a Distributed Architecture |
| |
|
This document describes extensions to the YANG notifications subscription to allow metrics being published directly from processors on line cards to target receivers, while subscription is still maintained at the route processor in a distributed forwarding system of a network node. |
| | A Concise Binary Object Representation (CBOR) of DNS Messages |
| |
| | draft-lenders-dns-cbor-16.txt |
| | Date: |
04/02/2026 |
| | Authors: |
Martine Lenders, Carsten Bormann, Mikolai Guetschow, Thomas Schmidt, Matthias Waehlisch |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies a compact data format of DNS messages using the Concise Binary Object Representation [RFC8949]. The primary purpose is to keep DNS messages small in constrained networks. |
| | SCION Control Plane |
| |
|
This document describes the Control Plane of the path-aware, inter- domain network architecture SCION (Scalability, Control, and Isolation On Next-generation networks). A fundamental characteristic of SCION is that it gives path control to SCION-capable endpoints that can choose between multiple path options, thereby enabling the optimization of network paths. The SCION Control Plane is responsible for discovering these paths and making them available to the endpoints. The SCION Control Plane creates and securely disseminates path segments between SCION Autonomous Systems (AS) which can then be combined into forwarding paths to transmit packets in the data plane. This document describes mechanisms of path exploration through beaconing and path registration. In addition, it describes how Endpoints construct end-to-end paths from a set of possible path segments through a path lookup process. This document contains new approaches to secure path aware networking. It is not an Internet Standard, has not received any formal review of the IETF, nor was the work developed through the rough consensus process. The approaches in this work are offered to the community for its consideration in the further evolution of the Internet. |
| | IP Address Space for Outer Space |
| |
|
The exploration of outer space depends heavily upon communications technology and in many cases, uses IP. IP address allocation has been formally assigned to Regional Internet Registries (RIRs), but there is no formal allocation of address space for networks in outer space. This document describes updates existing address allocation procedures to include address space for outer space. |
| | MoQ qlog event definitions |
| |
|
This document defines a qlog event schema containing concrete events for MoQ. |
| | SSH Support of ML-DSA |
| |
|
This document describes the use of ML-DSA digital signatures in the Secure Shell (SSH) protocol. |
| | Guidelines for Security Considerations of RATS |
| |
|
This document aims to provide guidelines and best practices for writing security considerations for technical specifications for RATS targeting the needs of implementers, researchers, and protocol designers. The current version presents an outline of the topics that future versions will cover in more detail. * Corrections in published RATS RFCs * Security concerns in two RATS drafts * General security guidelines, baseline or template for RATS |
| | Export of L4S ECN in IP Flow Information Export (IPFIX) |
| |
|
This document defines a set of IP Flow Information Export (IPFIX) Information Elements for monitoring the Low Latency, Low Loss, and Scalable throughput (L4S) service. Specially, these elements enable network operators to monitor the Explicit Congestion Notification (ECN) information of L4S deployment and performance of traffic. |
| | TCP Provenance Identifier Option |
| |
|
This document describes a TCP option that carries a Provenance Identifier (ProvID) to enable correlation of TCP connections when transport-layer identifiers change along the path. |
| | Dynamic Multi-agent Secured Collaboration Infrastructure Architecture |
| |
|
This document presents an architectural framework for dynamic multi- agent collaboration from an infrastructure perspective. It outlines the network requirements introduced by large-scale agents collaboration, and proposes a systematic approach to enabling Dynamic Multi-agent Secured Collaboration (DMSC) through infrastructure capabilities. The architecture focuses on how network control and forwarding functions can actively participate in agent collaboration. |
| | Ontology-based Semantic Interaction for Internet of Agents |
| |
|
This document specifies a normative semantic layer for agent-to-agent interaction in the Internet of Agents (IoA). The semantic layer provides a common ontology model and a JSON-LD serialization profile (RECOMMENDED), while allowing other RDF serializations for expressing capabilities, intents, tasks, and context. The document defines required classes and properties, a negotiation procedure, and alignment rules for heterogeneous ontologies. This layer is designed to be used by interaction and discovery protocols but does not define transport, session, or security protocols. It enables deterministic semantic interoperability across domains. |
| | RPKI-based BGP Origin Attestation |
| |
|
The Resource Public Key Infrastructure (RPKI) provides a framework for Route Origin Validation (ROV), but its deployment faces two critical challenges: 1) high false positive rates for "invalid" states and the operational burden these create; 2) incremental deployment has been hindered by limited immediate value when ROA coverage is incomplete and ROV deployment remains sparse. This document proposes a paradigm shift from reactive ROV validation to proactive origin attestation. We introduce two complementary mechanisms: 1) "Pre-validation before propagation" where routers validate self-originated routes against local RPKI Verified ROA Payload (VRP) cache before advertisement, holding invalid routes for operator intervention; and 2) A BGP extension that carries cryptographically signed origin attestation in BGP UPDATE messages. Unlike traditional ROV which only validates against outband RPKI- based ROAs, this approach enables originating ASes to actively attest to the legitimacy of their routes. This provides immediate security benefits even with partial deployment: each deploying AS gains stronger protection for its own prefixes, and downstream ASes receive clearer signals to distinguish legitimate routes from potential hijacks. The mechanisms dramatically reduce false positives while creating a deployable path toward comprehensive route origin security. |
| | Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Segment Routing (SR) LSPs |
| |
|
The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. Segment Routing (SR) can be used to steer packets through a network employing the source routing paradigm. SR can be applied to both MPLS (SR-MPLS) and IPv6 (SRv6) data planes. Stateful PCEP extensions for SR allow a PCE to maintain state and to control and initiate SR Traffic Engineering (TE) LSPs. PCEP supports grouping of two unidirectional MPLS-TE Label Switched Paths (LSPs), signaled via RSVP-TE, using association. This document defines PCEP extensions for grouping two unidirectional SR LSPs (one in each direction in the network) into a single associated bidirectional SR LSP. The mechanisms defined in this document are applicable to both stateless and stateful PCEs for PCE-initiated and PCC-initiated LSPs. |
| | 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. |
| | EAT Measured Component |
| |
|
The term "measured component" refers to an object within the attester's target environment whose state can be sampled and typically digested using a cryptographic hash function. Examples of measured components include firmware stored in flash memory, software loaded into memory at start time, data stored in a file system, or values in a CPU register. This document provides the information model for the "measured component" and two associated data models. This separation is intentional: the JSON and CBOR serializations, coupled with the media types and associated Constrained Application Protocol (CoAP) Content-Formats, enable the immediate use of the semantics within the Entity Attestation Token (EAT) framework. Meanwhile, the information model can be reused in future specifications to provide additional serializations, for example using ASN.1. |
| | SCITT Reference APIs |
| |
| | draft-ietf-scitt-scrapi-07.txt |
| | Date: |
04/02/2026 |
| | Authors: |
Henk Birkholz, Jon Geater |
| | Working Group: |
Supply Chain Integrity, Transparency, and Trust (scitt) |
|
This document describes a REST API that supports the normative requirements of the SCITT Architecture. Optional key discovery and query interfaces are provided to support interoperability with X.509 Certificates, alternative methods commonly used to support public key discovery and Artifact Repositories. |
| | Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) for Packet Optical Integration (POI) service assurance |
| |
| | draft-ietf-teas-actn-poi-assurance-03.txt |
| | Date: |
04/02/2026 |
| | Authors: |
Italo Busi, Jean-Francois Bouquier, Fabio Peruzzini, Paolo Volpato, Prasenjit Manna |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
This document extends the analysis of the applicability of Abstraction and Control of TE Networks (ACTN) architecture to Packet Optical Integration (POI) to cover multi-layer service assurance scenarios. Specifically, the ACTN architecture enables the detection and handling of different failures that may happen either at the optical or the packet layer. It is assumed that the underlying transport optical network carries end-to-end IP services such as L2VPN or L3VPN connectivity services, with specific Service Level Agreement (SLA) requirements. Existing IETF protocols and data models are identified for each multi-layer (packet over optical) service assurance scenario with a specific focus on the MPI (Multi-Domain Service Coordinator to Provisioning Network Controllers Interface) in the ACTN architecture. |
| |
|
| |
| | EAP defaults for devices that need to onboard |
| |
|
This document describes a method by which an unconfigured device can use EAP-TLS to join a network on which further device onboarding, network attestation or other remediation can be done. While RFC 5216 supports EAP-TLS without a client certificate, that document defines no method by which unauthenticated EAP-TLS can be used. This draft addresses that issue. |
| | Performance Measurement with Asymmetrical Traffic Using Simple Two-Way Active Measurement Protocol (STAMP) |
| |
|
This document specifies an optional extension to the Simple Two-way Active Measurement Protocol (STAMP) to control the length and/or number of packets sent by a Session-Reflector in response to a single test packet from the Session-Sender during a STAMP test session. By default, a STAMP Session-Sender and Session-Reflector exchange packets symmetrically: the number of packets sent by the Session- Reflector and the Session-Sender are the same as is the length of the packets sent by the Session-Reflector and the Session-Sender. However, there are cases where a Session-Reflector responding with Asymmetrical Packets would ensure a closer approximation between active performance measurements and the conditions experienced by monitored application. The STAMP extension proposed in this document allows the operator to establish tests where a Session-Reflector sends Asymmetrical Packets, packets whose length is not symmetrical to test packet sent by the Session-Sender and/or packets that are not sent in direct response to a packet received from a Session-Sender. The document also includes an analysis of challenges related to performance monitoring in a multicast network. It specifies procedures and STAMP extensions to achieve more efficient measurements with a lesser impact on a network. |
| | Best Practices for Signed Attributes in CMS SignedData |
| |
|
The Cryptographic Message Syntax (CMS) has different signature verification behaviour based on whether signed attributes are present or not. This results in a potential existential forgery vulnerability in CMS and protocols which use CMS. This document describes the vulnerability and lists mitigations and best practices to avoid it. |
| | YANG Data Model for MPLS mLDP |
| |
| | draft-ietf-mpls-mldp-yang-16.txt |
| | Date: |
03/02/2026 |
| | Authors: |
Syed Raza, Xufeng Liu, Santosh Esale, Loa Andersson, Jeff Tantsura |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
|
This document describes a YANG data model for the Multiprotocol Label Switching (MPLS) Multipoint Label Distribution Protocol (mLDP). The mLDP YANG data model augments the MPLS LDP YANG data model. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). |
| | LSP Ping/Traceroute for Prefix SID in Multi-Algorithm/Multi-Topology Networks |
| |
| | draft-ietf-mpls-algo-mt-oam-00.txt |
| | Date: |
03/02/2026 |
| | Authors: |
Zafar Ali, Deepti Rathi, Shraddha Hegde, Changwang Lin, Jie Dong |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
|
[RFC8287] defines the extensions to MPLS LSP Ping and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifier (SIDs) with an MPLS data plane. The machinery defined in [RFC8287] works well in single topology, single algorithm deployments where each Prefix SID is only associated with a single IP prefix. In multi-topology networks, or networks deploying multiple algorithms for the same IP Prefix, MPLS echo request needs to carry additional information in the Target FEC Stack sub-TLVs to properly validate IGP Prefix SID. This document updates [RFC8287] by modifying IPv4 and IPv6 IGP-Prefix Segment ID FEC sub-TLVs to also include algorithm identification while maintaining backwards compatibility. This document also introduces new Target FEC Stack sub-TLVs for Prefix SID validation in multi-topology networks. |
| | Use of Composite ML-DSA in TLS 1.3 |
| |
|
Compositing the post-quantum ML-DSA signature with traditional signature algorithms provides protection against potential breaks or critical bugs in ML-DSA or the ML-DSA implementation. This document specifies how such a composite signature can be formed using ML-DSA with RSA-PKCS#1 v1.5, RSA-PSS, ECDSA, Ed25519, and Ed448 to provide authentication in TLS 1.3, including use in certificates. |
| | Bitwise IP Filters for BGP FlowSpec |
| |
|
This draft introduces the bitwise matching filters for source or destination IPv4/IPv6 address fields. These filters enhance the functionalities of the BGP Flow Specification framework and aid scenarios involving symmetric traffic load balancing. |
| | Path Computation Element Communication Protocol for Source Address Validation |
| |
| | draft-song-pce-pcep-sav-02.txt |
| | Date: |
03/02/2026 |
| | Authors: |
Xueyan Song, Weiqiang Cheng, 1211176911910469110103 |
| | Working Group: |
Individual Submissions (none) |
|
This document presents a method of Path Computation Element (PCE) for Source Address Validation (SAV) in networks. It extends Path Computation Element Communication Protocol (PCEP) to support SAV policy distribution and synchronization between PCEP speakers for threat mitigation for source address spoofing. |
| | Remote Procedure Call Identity Squashing via x.509 Certificate Fields |
| |
|
This document extends RPC-with-TLS, as described in [RFC9289], so that a client's x.509 certificate may carry instructions to the RPC server to execute all RPC transactions from that client as a single user identity. |
| | HMTFTP: HMAC-Derived TFTP with Optional AEAD Protection (v0.3) |
| |
|
HMTFTP is a lightweight UDP file transfer protocol derived from TFTP that adds a compact TLV mechanism and an optional AEAD protection mode for DATA payloads. Version v0.3 clarifies interoperability and extension governance rules so that independent implementations can evolve safely over time. The default UDP port is TBD1 and implementations MUST allow it to be configured. |
| | PRISM: Protocol for Routing Intelligent Service Mapping - Application-Aware Traffic Steering for SD-WAN |
| |
|
This document specifies PRISM, an application-aware traffic steering protocol for Software-Defined Wide Area Networks (SD-WAN). PRISM provides deep application identification, per-flow tracking, Service Level Agreement (SLA) enforcement, and policy-based path selection integration with Segment Routing over IPv6 (SRv6). PRISM is designed as a companion protocol to CONDUIT (Cryptographic Orchestration of Network Distributed Underlay for IPsec Transport), together providing a complete open-standard SD-WAN solution. CONDUIT manages the encrypted tunnel fabric while PRISM provides the application intelligence and policy enforcement. The protocol is fully programmable via gRPC, supports distributed and centralized deployment models, and mandates compliance with Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) cryptographic requirements. |
| | Agent Registration and Discovery Protocol (ARDP) |
| |
|
This document specifies the Agent Registration and Discovery Protocol (ARDP), a lightweight protocol for registering, discovering, and reaching autonomous software agents in distributed and federated environments. ARDP provides stable agent identities, dynamic endpoint resolution, capability advertisement (including protocol selection among MCP, A2A, HTTP, and gRPC), minimal presence signaling, and a security-first discovery control plane. ARDP is transport-agnostic and complementary to existing agent interaction protocols. |
| | A two-party profile for MLS |
| |
|
TODO Abstract |
| | L3ND Upper-Layer Protocol Configuration |
| |
|
This document adds PDUs to the Layer-3 Neighbor Discovery protocol to communicate the parameters needed to exchange inter-device Upper Layer Protocol Configuration for upper-layer protocols such as the BGP family. |
| | Delay-Tolerant Networking QUIC Convergence Layer Protocol Version 1 |
| |
|
This document describes a QUIC convergence layer (QUICCL) for Delay- Tolerant Networking (DTN). QUICCL uses BPv7 bundles encoded by the Concise Binary Object Representation (CBOR) as its service data unit being transported and makes use of either QUIC streams (RFC 9001) or QUIC datagrams (RFC 9221) to transport such bundles. QUICCL design is largely based on TCPCLv4 specification (RFC9174), with three significant differences. First, as QUIC incorporates TLS security, all security related parts of TCPCLv4 were dropped. Second, QUICCL provides two new transport services, notified and unreliable, in addition to the reliable service; Third, in the reliable service, by taking advantage of QUIC streams, four levels of priority are offered. |
| | AI Preferences for Real-Time Protocol Bindings |
| |
|
This document defines how Artificial Intelligence (AI) preference expressions are bound to signaling and media protocols used for real- time, session-based communications such as the Session Initiation Protocol (SIP) and associated Session Description Protocol (SDP) offers. It specifies a reusable binding model, concrete SIP header field conventions, and SDP attributes that allow endpoints, intermediary services, and AI assistants to advertise, negotiate, and enforce requirements about AI-driven processing of session metadata, media control events, and telemetry. The goal is to align real-time protocol behavior with the AI Preferences (AIPREF) vocabulary without disrupting existing call control semantics. |
| | ONSEN Problem Statement |
| |
| | draft-xie-onsen-problem-statement-00.txt |
| | Date: |
03/02/2026 |
| | Authors: |
Chongfeng Xie, Sun Qiong, Benoit Claise, Linda Dunbar, Luis Contreras, Kris Lambrechts, Bo Wu |
| | Working Group: |
Individual Submissions (none) |
|
Exposure of network and service abstractions to external systems via YANG-based APIs has become an important means for operators to enhance their competitiveness. Despite the availability of numerous YANG data models, operators continue to face significant challenges in operationalizing these APIs in a consistent, scalable, and interoperable manner. Based on a typical use case, this document describes the problem space associated with operationalizing YANG- based service APIs, drawing on operator experience, IAB workshop findings to motivate requirements for improving API predictability and operational effectiveness through the upcoming ONSEN WG. In addition, it intends to gather operational needs and motivations for network and service abstractions to inform YANG data model refresh work. |
| | Policy and Lifecycle Extensions for OAuth Rich Authorization Requests |
| |
|
OAuth 2.0 Rich Authorization Requests (RAR), as defined in RFC 9396, provides a mechanism for clients to request fine-grained, structured authorization details. However, in emerging ecosystems of collaborating AI agents and long-running automated tasks, two critical authorization dimensions remain implicit: the required security assurance level of the authorization policy and the strict binding of authorization lifetime to a task's lifecycle. This document extends the "authorization_details" object of RAR by introducing two new members: "policy_context" and "lifecycle_binding". The "policy_context" member allows a client to explicitly request that the authorization be evaluated and granted under a specific policy assurance level, mitigating policy downgrade attacks and enhancing user consent. The "lifecycle_binding" member enables the validity of an authorization grant to be tied directly to the state of an external entity, such as an automated task, ensuring permissions are automatically and immediately revoked upon task completion. These extensions provide a standardized way to achieve more secure, transparent, and context-aware authorization in complex, automated environments. |
| | Advertising IGP Measurement Group using TLV |
| |
|
This document defines an IS-IS capability sub-TLV for advertising measurement group membership for Active Measurement Protocols (AMPs) such as TWAMP and STAMP. The mechanism allows IGP routers to discover other routers participating in different measurement groups, enabling automatic discovery of measurement endpoints across IGP areas. The solution uses interface addresses (IPv4 or IPv6) to identify measurement group membership, where the same interface address may be used for multiple measurement groups. |
| | A YANG Data Model and RADIUS Extension for Policy-Based Network Access Control |
| |
| | draft-ietf-opsawg-ucl-acl-12.txt |
| | Date: |
03/02/2026 |
| | Authors: |
Qiufang Ma, Qin WU, Mohamed Boucadair, Daniel King |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
This document defines a YANG data model for policy-based network access control, which provides enforcement of network access control policies based on group identity. Additionally, the YANG data model defined in the document also extends ACLs (Access Control Lists) with date and time parameters to support schedule-aware policy enforcement. Specifically in scenarios where network access is triggered by user authentication, this document defines a mechanism to ease the maintenance of the mapping between a user group identifier and a set of IP/MAC addresses to enforce policy-based network access control. Moreover, the document defines a Remote Authentication Dial-in User Service (RADIUS) attribute that is used to communicate the user group identifier as part of identification and authorization information. |
| | Multicast over SRv6 networks |
| |
|
This document presents solutions for deploying multicast in SRv6 networks. It explores the use of the native IPv6 multicast data plane for multicast distribution. The document discusses distributed control plane mechanisms, including PIM, and its integration with IGP Flex-Algo to optimize multicast delivery. The document also addresses overlay multicast solutions for both the Global Table Multicast (GTM) and Multicast VPNs (MVPNs), utilizing IP-in- IPv6 encapsulation without requiring additional shim layers. |
| | 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. |
| | RadSec: RADIUS over Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) |
| |
|
This document defines transport profiles for running RADIUS over Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS), allowing the secure and reliable transport of RADIUS messages. RADIUS/TLS and RADIUS/DTLS are collectively referred to as RadSec. This document obsoletes RFC6614 and RFC7360, which specified experimental versions of RADIUS over TLS and DTLS. |
| | Text in RFCs |
| |
|
This document sets policy for the inclusion of characters in the definitive versions and publication formats of RFCs. The policy for the RFC Series is that all displayable text is allowed as long as there is a high expectation that readers of an RFC will be able to interpret its text as intended. This document obsoletes RFC 7997. [[ A repository for this draft can be found here (https://github.com/ paulehoffman/7997bis). ]] |
| | TLS/DTLS 1.3 Profiles for the Internet of Things |
| |
|
RFC 7925 offers guidance to developers on using TLS/DTLS 1.2 for Internet of Things (IoT) devices with resource constraints. This document is a companion to RFC 7925, defining TLS/DTLS 1.3 profiles for IoT devices. Additionally, it updates RFC 7925 with respect to the X.509 certificate profile and ciphersuite requirements. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/thomas-fossati/draft-tls13-iot. |
| |
|
| |
| | Computing-Aware Traffic Steering (CATS) Problem Statement,Use Cases,and Requirements |
| |
|
Distributed computing enhances service response time and energy efficiency by utilizing diverse computing facilities for compute- intensive and delay-sensitive services. To optimize throughput and response time, "Computing-Aware Traffic Steering" (CATS) selects servers and directs traffic based on compute capabilities and resources, rather than static dispatch or connectivity metrics alone. This document outlines the problem statement and scenarios for CATS within a single domain, and drives requirements for the CATS framework. |
| | 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. |
| | Packed CBOR |
| |
| | draft-ietf-cbor-packed-19.txt |
| | Date: |
02/02/2026 |
| | Authors: |
Carsten Bormann, Mikolai Guetschow |
| | Working Group: |
Concise Binary Object Representation Maintenance and Extensions (cbor) |
|
The Concise Binary Object Representation (CBOR, RFC 8949 == STD 94) 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 does not provide any forms of data compression. CBOR data items, in particular when generated from legacy data models, often allow considerable gains in compactness when applying data compression. While traditional data compression techniques such as DEFLATE (RFC 1951) can work well for CBOR encoded data items, their disadvantage is that the recipient needs to decompress the compressed form before it can make use of the data. This specification describes Packed CBOR, a set of CBOR tags and simple values that enable a simple transformation of an original CBOR data item into a Packed CBOR data item that is almost as easy to consume as the original CBOR data item. A separate decompression step is therefore often not required at the recipient. // (This cref will be removed by the RFC editor:) The present // revision -19 is a work-in-progress release in preparation for // another cbor-packed side meeting. This revision resolves the use // of the tunables A/B/C by setting A=16, B=8, and C=8, and choosing // requested simple values and tag numbers, in preparation for // continuing the early allocation process. |
| | A YANG Data Model for Flexi-Grid Optical Networks |
| |
| | draft-ietf-ccamp-flexigrid-yang-19.txt |
| | Date: |
02/02/2026 |
| | Authors: |
Universidad de Madrid, Daniel Burrero, Daniel King, Young Lee, Haomian Zheng |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
|
This document defines a YANG module for managing flexi-grid optical networks. The model defined in this document specifies a flexi-grid traffic engineering database that is used to describe the topology of a flexi-grid network. It is based on and augments existing YANG models that describe network and traffic engineering topologies. |
| | Use of Hybrid Public-Key Encryption (HPKE) with CBOR Object Signing and Encryption (COSE) |
| |
| | draft-ietf-cose-hpke-21.txt |
| | Date: |
02/02/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. |
| | Validity of SR Policy Candidate Path |
| |
|
An SR Policy comprises one or more candidate paths of which at a given time one and only one may be active (i.e., installed in forwarding plane and usable for steering of traffic). Each candidate path, in turn, may have one or more segment lists of which one or more may be active. When multiple segment lists are active, traffic is load balanced over them. Currently, a candidate path is valid as long as at least one of its segment lists is active. However, this default validity criterion does not meet the requirements of some scenarios. This document defines the new candidate path validity criterion. |
| | Considerations for Integrating Merkle Tree Ladder (MTL) Mode Signatures into Applications |
| |
|
This document provides design considerations for application designers on how to add Merkle Tree Ladder (MTL) Mode signatures into their applications. It provides general considerations relevant to any signature algorithm in addition to specific considerations for MTL mode such as for grouping and ordering messages to be signed, computing and signing ladders, and forming signatures exchanged between application components, including handling caching between the signer and the verifier. |
| | 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. |
| | Fast Network Notifications Problem Statement |
| |
| | draft-dong-fantel-problem-statement-05.txt |
| | Date: |
02/02/2026 |
| | Authors: |
Jie Dong, Mike McBride, Francois Clad, Zhaohui Zhang, Yongqing Zhu, Xiaohu Xu, Rui Zhuang, Ran Pang, Hao Lu, Yadong Liu, Luis Contreras, DURMUS Mehmet, Reshad Rahman |
| | Working Group: |
Individual Submissions (none) |
|
Modern network applications, ranging from Artificial Intelligence (AI) /Machine Learning (ML) training to large-scale cloud services, require adaptive networks to ensure reliable and congestion-free data transfer within or across multiple data centers. A good and timely understanding of network operational status can help to enable faster response to critical events, so as to enable the selection of paths with reduced latency and improve network utilization. This document describes the existing problems and the need of fast network notification solutions. |
| | 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. |
| | Agent Authorization Profile (AAP) for OAuth 2.0 |
| |
|
This document defines the Agent Authorization Profile (AAP), an authorization profile for OAuth 2.0 and JWT designed for autonomous AI agents. AAP extends existing standards with structured claims and validation rules so that systems can reason about agent identity, task context, operational constraints, delegation chains, and human oversight requirements. It does not introduce a new protocol; it specifies how to use OAuth 2.0, JWT, Token Exchange, and proof-of- possession mechanisms in agent-to-API (M2M) scenarios with context- aware, auditable authorization. |
| | Some Anachronisms in IETF Standards Process Documents |
| |
|
This document discusses some aspects of documents describing the IETF standards process that have been overtaken by events. It covers the six-month expiry of Internet-Drafts, the citation of Internet-Drafts, the reality of the two-stage standards process, and BOF approvals. |
| | Congestion-Aware Multipath Tunnel Selection for Transport Services |
| |
|
This document addresses the transport-layer challenges of path selection in environments with multiple available tunneling options and congestion control mechanisms. It identifies congestion control conflicts that arise from nested tunneling protocols and proposes a congestion-aware multipath tunnel selection algorithm that conforms to the guidelines established in [RFC9599] for adding congestion notification to protocols that encapsulate IP. The proposed approach considers Explicit Congestion Notification (ECN) propagation, transport protocol characteristics, and network conditions to optimize path selection while avoiding multilevel congestion control issues. This work aligns with current Transport and Services Working Group efforts on Non-Queue-Building (NQB) behaviors, careful congestion control resume, and multipath transport protocols. |
| | Path Computation Element Communication Protocol (PCEP) Extensions for Signaling Multipath Information |
| |
| | draft-ietf-pce-multipath-19.txt |
| | Date: |
02/02/2026 |
| | Authors: |
Mike Koldychev, Siva Sivabalan, Tarek Saad, Vishnu Beeram, Hooman Bidgoli, Shuping Peng, Samuel Sidor |
| | Working Group: |
Path Computation Element (pce) |
|
Certain traffic engineering path computation problems require solutions that consist of multiple traffic paths that together form a solution. However, current PCEP extensions can only return a single traffic path, which cannot meet the requirements. This document defines mechanisms to encode multiple paths for a single set of objectives and constraints. This allows encoding of multiple Segment Lists per Candidate Path within a Segment Routing Policy. The new Path Computation Element Communication Protocol (PCEP) mechanisms are designed to be generic, which allows for future re-use outside of SR Policy. The new PCEP mechanisms are applicable to both stateless and stateful PCEP. Additionally, this document updates RFC 8231 and RFC 8281 to allow encoding of multiple Segment Lists in PCEP. |
| | The Internet Standards Process |
| |
|
This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages, and the types of documents used during this process. It also addresses the intellectual property rights and copyright issues associated with the standards process. This document obsoletes RFC 2026, RFC 5657, RFC 6410, RFC 7100, RFC 7127, RFC 8789, and RFC 9282. It also includes the changes from RFC 7475. If this document and [_2418bis] are published as RFCs, then taken together the two of them make RFC 7475 obsolete. |
| | Extensible Provisioning Protocol (EPP) Transport over QUIC |
| |
| | draft-ietf-regext-epp-quic-03.txt |
| | Date: |
02/02/2026 |
| | Authors: |
Jiankang Yao, Hongtao Li, Zhang, Dan Keathley, James Gould |
| | Working Group: |
Registration Protocols Extensions (regext) |
|
This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a QUIC connection. EPP over QUIC (EoQ) leverages the performance and security features of the QUIC protocol as an EPP transport. |
| | Extension Registry for the Extensible Provisioning Protocol |
| |
|
The Extensible Provisioning Protocol (EPP) includes features to add functionality by extending the protocol. It does not, however, describe how those extensions are managed. This document describes a procedure for the registration and management of extensions to EPP, and it specifies a format for an IANA registry to record those extensions. |
| | Segment Routing IPv6 Security Considerations |
| |
| | draft-ietf-spring-srv6-security-11.txt |
| | Date: |
02/02/2026 |
| | Authors: |
Nick Buraglio, Tal Mizrahi, tongtian124, Luis Contreras, Fernando Gont |
| | Working Group: |
Source Packet Routing in Networking (spring) |
|
SRv6 is a traffic engineering, encapsulation and steering mechanism utilizing IPv6 addresses to identify segments in a pre-defined policy. This document discusses security considerations in SRv6 networks, including the potential threats and the possible mitigation methods. The document does not define any new security protocols or extensions to existing protocols. |
| | PQ/T Hybrid Key Exchange with ML-KEM in SSH |
| |
|
This document defines Post-Quantum Traditional (PQ/T) Hybrid key exchange methods based on the quantum-resistant the Module-Lattice- Based Key-Encapsulation Mechanism (ML-KEM) standard and traditional Elliptic-curve Diffie–Hellman (ECDH) key exchange schemes. These methods are defined for use in the SSH Transport Layer Protocol. |
| | YANG models for Virtual Network (VN)/TE Performance Monitoring Telemetry and Scaling Intent Autonomics |
| |
|
This document provides YANG data models that describe the performance monitoring parameters and scaling intent mechanisms for Traffic Engineering (TE) tunnels and Virtual Networks (VNs). Their performance monitoring parameters are exposed as the key telemetry data for tunnels and VNs. The models presented in this document allow customers to subscribe to and monitor the key performance data of the TE-tunnel or the VN. The models also provide customers with the ability to program autonomic scaling intent mechanisms on the level of TE-tunnel as well as VN. |
| | Quic Logging for Convergence of Congestion Control from Retained State |
| |
|
This document specifies a logging format for a cautious method for Careful Resume when using the IETF quic transport protocol. It defines the logging format for qlog. |
| |
|
| |
| | Admin Interface for the OSCORE Group Manager |
| |
| | draft-ietf-ace-oscore-gm-admin-14.txt |
| | Date: |
01/02/2026 |
| | Authors: |
Marco Tiloca, Rikard Hoeglund, Peter van der Stok, Francesca Palombini |
| | Working Group: |
Authentication and Authorization for Constrained Environments (ace) |
|
Group communication for the Constrained Application Protocol (CoAP) can be secured using Group Object Security for Constrained RESTful Environments (Group OSCORE). A Group Manager is responsible for handling the joining of new group members, as well as for managing and distributing the group keying material. This document defines a RESTful admin interface at the Group Manager that allows an Administrator entity to create and delete OSCORE groups, as well as to retrieve and update their configuration. The ACE framework for Authentication and Authorization is used to enforce authentication and authorization of the Administrator at the Group Manager. Protocol-specific transport profiles of ACE are used to achieve communication security, proof of possession, and server authentication. |
| | CPace,a balanced composable PAKE |
| |
|
This document describes CPace which is a protocol that allows two parties that share a low-entropy secret (password) to derive a strong shared key without disclosing the secret to offline dictionary attacks. The CPace protocol was tailored for constrained devices and can be used on groups of prime- and non-prime order. |
| | 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. |
| | Structured Error Data for Filtered DNS |
| |
|
DNS filtering is widely deployed for various reasons, including network security. However, filtered DNS responses lack structured information for end users to understand the reason for the filtering. Existing mechanisms to provide explanatory details to end users cause harm especially if the blocked DNS response is for HTTPS resources. This document updates RFC 8914 by signaling client support for structuring the EXTRA-TEXT field of the Extended DNS Error to provide details on the DNS filtering. Such details can be parsed by the client and displayed, logged, or used for other purposes. |
| | Traffic Steering using BGP FlowSpec with SR Policy |
| |
|
BGP Flow Specification (FlowSpec) [RFC8955] and [RFC8956] has been proposed to distribute BGP [RFC4271] FlowSpec NLRI to FlowSpec clients to mitigate (distributed) denial-of-service attacks, and to provide traffic filtering in the context of a BGP/MPLS VPN service. Recently, traffic steering applications in the context of SR-MPLS and SRv6 using FlowSpec are being used in networks. This document introduces the usage of BGP FlowSpec to steer packets into an SR Policy. |
| | Adding an Uncacheable Directory-Entry Metadata Attribute to NFSv4.2 |
| |
|
Network File System version 4.2 (NFSv4.2) clients commonly cache directory entries (dirents) to improve performance. While effective in many cases, such caching can prevent servers from enforcing per- user access controls on directory entries and up-to-date directory entry attributes such as size and timestamps. This document introduces a new uncacheable dirent metadata attribute for NFSv4.2 that allows servers to advise clients that caching of directory entry metadata is unsuitable. This enables servers to present directory contents based on user-specific access permissions while remaining compatible with existing NFSv4.2 clients. |
| | Deterministic Networking SRv6 Data Plane |
| |
|
This document specifies the Deterministic Networking (DetNet) data plane when operating over an IPv6/SRv6 Packet Switched Network. It leverages existing IPv6 encapsulations and behaviors. It uses the Redundancy SIDs in DetNet scenarios and optionally the Traffic Engineering mechanisms provided by SRv6. This document builds on the DetNet architecture and data plane framework. |
| | End-to-End Semantics in a World Without Ambient Reachability |
| |
|
This document examines the Internet's current connectivity model as an observed architectural equilibrium rather than as a failure to be corrected. It argues that the deployed Internet no longer provides ambient, unsolicited end-to-end transport reachability, not because of a single design error, but as the cumulative result of rational responses to scale, security exposure, administrative autonomy, and cost containment. Default-deny boundaries and policy enforcement have become structural features of the network. Under these conditions, applications and services that require mutual visibility rely on a recurring set of mechanisms, including relays, overlays, tunnels, rendezvous services, and long-lived outbound connections, to enable interaction. These mechanisms are widely deployed, often effective, and serve multiple legitimate roles, including constrained initiation, resource discovery, and intentional mediation or fan-out. Their persistence reflects sustained demand for controlled initiation in the absence of an explicit transport- layer admission capability. The document treats the convergence of these mechanisms into steady- state infrastructure as diagnostic evidence. When distinct interaction roles are collapsed into a common architectural form, local correctness is preserved, but predictable system-level effects emerge, including loss of locality, concentration of load, obscured failure semantics, and elevation of coordination and authorization semantics into higher layers. This analysis is diagnostic rather than prescriptive. It does not propose new protocols, standards, or deployment requirements, nor does it advocate restoring ambient reachability. Instead, it argues that if transport-visible end-to-end semantics (properties observable and enforceable without application payload inspection) are to remain meaningful under contemporary conditions, the architecture must provide some form of explicit, policy-bounded admission at boundaries. Any architectural responses discussed are illustrative only, intended to make these constraints concrete rather than to mandate specific mechanisms. The intent of this document is to make the present connectivity equilibrium visible as an architectural condition in its own right, and to provide a clearer foundation for subsequent analysis, design, or standardization efforts that engage with end-to-end semantics under real operational constraints. |
| | TRIP: Trajectory-based Recognition of Identity Proof |
| |
|
This document specifies the Trajectory-based Recognition of Identity Proof (TRIP) protocol, a decentralized mechanism for establishing claims of physical-world presence through cryptographically signed, spatially quantized location attestations called "breadcrumbs." Breadcrumbs are chained into an append-only log, bundled into verifiable epochs, and distilled into a Trajectory Identity Token (TIT) that serves as a persistent pseudonymous identifier. Trust in a TIT accumulates through spatiotemporal diversity of the underlying trajectory rather than through biometric capture or centralized credential issuance. TRIP is designed to be transport-agnostic and operates independently of any particular naming system, blockchain, or application layer. |
| | PCEP Extension for Flow Specification Version 2 |
| |
|
Traffic flows may be categorized and described using "Flow Specifications". RFC8955 defines the Flow Specification and describes how Flow Specification components are used to describe traffic flows. RFC8955 also defines how Flow Specifications may be distributed in BGP to allow specific traffic flows to be associated with routes. The flow specification protocol defined in RFC8955, RFC8956, RFC9117 is called BGP flow specification version 1 (BGP FSv1). RFC9168 specifies a set of extensions to PCEP to support the dissemination of Flow Specifications. This allows a PCE to indicate what traffic should be placed on each path that it is aware of. RFC9168 inherits the BGP Flow Spec registry and ordering rules as well as the limitations in BGP FSv1. This document proposes extensions to PCEP to add the support of Flow Specification v2 to allow the user to order the flow specification rules. |
| | Interactive DPoP |
| |
|
This document describes IDPoP, an extension to DPoP [RFC9449] that uses a key derivation scheme to separate access control from identity. It mitigates credential exfiltration risks by requiring fresh hardware attestation to unseal identity keys via an interactive challenge. |
| | Trusted Execution Environment Provisioning (TEEP) Protocol |
| |
| | draft-ietf-teep-protocol-23.txt |
| | Date: |
01/02/2026 |
| | Authors: |
Hannes Tschofenig, Mingliang Pei, David Wheeler, Dave Thaler, Akira Tsukamoto |
| | Working Group: |
Trusted Execution Environment Provisioning (teep) |
|
This document specifies a protocol that installs, updates, and deletes Trusted Components in a device with a Trusted Execution Environment (TEE). This specification defines an interoperable protocol for managing the lifecycle of Trusted Components. |