| |
|
| |
| | CBOR Serialization and Determinism |
| |
|
This document defines two CBOR serializations: "preferred-plus serialization" and "deterministic serialization." It also introduces the term "general serialization" to name the full, variable set of serialization options defined in RFC 8949. Together, these three form a complete set of serializations that cover the majority of CBOR serialization use cases. These serializations are largely compatible with those widely implemented by the CBOR community. |
| | Domain Connect Protocol - DNS provisioning between Services and DNS Providers |
| |
|
This document provides specification of the Domain Connect Protocol that was built to support DNS configuration provisioning between Service Providers (hosting, social, email, hardware, etc.) and DNS Providers. |
| | CCNx Content Versioning |
| |
|
This document defines a method for content versioning in CCNx, enabling the differentiation of content sharing the same name using version numbers. This document updates RFC8569 [RFC8569] and RFC8609 [RFC8609]. |
| | BGP Extended Community for Identifying the Target Nodes |
| |
|
BGP has been used to distribute different types of routing and policy information. In some cases, the information distributed may be only intended for one or a particular group of BGP nodes in the network. Currently BGP does not have a generic mechanism of designating the target nodes of the routing information. This document defines a new type of BGP Extended Community called "Node Target" for this purpose. |
| | A YANG Network Data Model for Inventory Topology Mapping |
| |
|
This document defines a YANG data model to map the network inventory data with the topology data to form a base underlay network. The data model facilitates the correlation between the layer (e.g., Layer 2 or Layer 3) topology information and the inventory data of the underlay network for better service provisioning, network maintenance operations, and other assessment scenarios. |
| | A YANG Data Model for Network Inventory Location |
| |
|
This document defines a YANG data model for Network Inventory location (e.g., site, room, rack, geo-location data), which provides location information with different granularity levels for inventoried network elements. Accurate location information is useful for network planning, deployment, and maintenance. However, such information cannot be obtained or verified from the Network Elements themselves. This document defines a location model for network inventory that extends the base inventory with comprehensive location data. |
| | 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. |
| | An Architecture for YANG-Push to Message Broker Integration |
| |
|
This document describes the motivation and architecture of a native YANG-Push notifications and YANG Schema integration into a Message Broker and YANG Schema Registry. |
| | YANG Message Keys for Message Broker Integration |
| |
|
This document specifies a mechanism to define a unique Message key for a YANG to Message Broker integration and a topic addressing scheme based on YANG-Push subscription type and YANG Schema Node Identifier. This enables YANG data consumption of a subset of subscribed YANG data, either per specific YANG data node, identifier or telemetry message type, by indexing and organizing in Message Broker topics. It helps top index the information by using data taxonomy and organizes data in partitions and shards of Message Brokers and time series databases. |
| | Destination-IP-Origin-AS Filter for BGP Flow Specification |
| |
|
This document defines an extension to the Border Gateway Protocol (BGP) Flow Specification (FlowSpec) to enable filtering based on the Origin Autonomous System (AS) of the destination IP address. This extension is particularly useful in mitigating Distributed Denial of Service (DDoS) attacks where the target IP addresses are dynamic but belong to a specific destination AS. |
| | VLSM Tree Routing Protocol |
| |
|
This is a light weight routing protocol applicable inside a network that appears in the form of a tree and distribution of address space takes place with the approach of VLSM. It is based on setting default route inside VLSM tree. With this approach, routing information of the external world need not be passed down to the VLSM tree. Thus, load inside a router gets reduced substantially. This document includes IP-VPN with MPLS inside VLSM tree by extending RSVP-TE. |
| | TCP RST Diagnostic Payload |
| |
|
This document specifies two experimental diagnostic payload formats returned in TCP RST segments. Such payloads are used to share with an endpoint the reasons for which a TCP connection has been reset. Sharing this information is meant to ease diagnostic and troubleshooting. This specification builds on provisions that are already present in RFC 9293 "Transmission Control Protocol (TCP)". As such, this document does not require any change to RFC 9293. |
| | BFD Extension for DetNet Remote Defect Indication (RDI) |
| |
| | draft-huang-detnet-rdi-04.txt |
| | Date: |
28/02/2026 |
| | Authors: |
Hongyi Huang, Li Zhang, Tianran Zhou, Jing Gao |
| | Working Group: |
Individual Submissions (none) |
|
This document provides a method of realizing remote defect indication for DetNet OAM. It takes advantage of and extends BFD to explicitly indicate DetNet-specific defects. |
| | Echo Request/Reply for DetNet Capability Discovery |
| |
|
This document describes an extension to the echo request/reply mechanisms used in IP, MPLS or other DetNet data plane environments, which can be used within the DetNet domain, allowing the ping initiator node to discover the enabled DetNet capabilities of each relay node of detnet service-sub layer, which including discovering DetNet relay nodes, collecting DetNet service sub-layer specific information from DetNet relay nodes, as well as discovering the locations of PREOF functions. |
| | Service Interworking between SRv6 |
| |
|
When operators provide services through SRv6, such as L3VPN and L2VPN, there may be cross-domain scenarios of multiple ASs, or multiple admin domain scenarios within the same AS. This document describes how to implement interworking of services for such scenarios. |
| | Latency Guarantee with Stateless Fair Queuing |
| |
|
This document specifies the framework and the operational procedure for deterministic networking with a set of rate based work conserving packet schedulers. The framework guarantees end-to-end (E2E) latency bounds to flows. The schedulers in core nodes do not need to maintain flow states. Instead, the entrance node of a flow marks an ideal service completion time according to a fluid model, called Finish Time (FT), of a packet in the packet header. The subsequent core nodes update the FT by adding the delay factor, which is a function of the flow and the nodes. The packets in the queue of the scheduler are served in the ascending order of FT. This mechanism is called the stateless fair queuing. The result is that flows are isolated from each other almost perfectly. The latency bound of a flow depends only on the flow's intrinsic parameters such as the maximum burst size and the service rate, except the link capacities and the maximum packet length among other flows sharing each output link with the flow. Furthermore, this document specifies an approximation of stateless fair queuing implemented via a strict priority (SP) scheduler. This approach maintains a guaranteed end- to-end (E2E) latency bound. |
| | 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. |
| | Automatic Extended Route Optimization (AERO) |
| |
|
This document specifies an Automatic Extended Route Optimization (AERO) and mobility service for IP internetworking over Overlay Multilink Network (OMNI) Interfaces. AERO/OMNI use IPv6 Neighbor Discovery (IPv6 ND) control plane messaging over the OMNI virtual link to support secured network admission and OMNI link forwarding. Flow-based secure multilink path selection, multinet traversal, mobility management, multicast forwarding, multihop operation and route optimization are naturally supported through dynamic neighbor cache updates. AERO is a widely-applicable service well-suited for air/land/sea/space secure global mobile Internetworking applications including aviation, intelligent transportation systems, mobile end user devices, space exploration and many others. |
| | EVN6: Mapping of Ethernet Virtual Network to IPv6 Underlay for Transmission |
| |
| | draft-xls-intarea-evn6-05.txt |
| | Date: |
28/02/2026 |
| | Authors: |
Chongfeng Xie, Jibin Sun, Xing Li, Congxiao Bao, Mark Smith |
| | Working Group: |
Individual Submissions (none) |
|
This document describes a mechanism of mapping of Ethernet Virtual Network to IPv6 Underlay for transmission. Unlike the existing methods, this approach places the Ethernet frames to be transmitted directly in the payload of IPv6 packets, i.e., L2 over IPv6, and uses stateless mapping to generate IPv6 source and destination addresses from the host's MAC addresses, the Ethernet Virtual Network identifier and site prefixes. The IPv6 packets generated in this way carry Ethernet frames and are routed to the destination site across the public IPv6 network. |
| | EVPN Route Types and Procedures for EVN6 |
| |
|
EVN6 is a mechanism designed to provide Ethernet connectivity to customer sites dispersed on public IPv6 networks. At the data layer, EVN6 encapsulates Ethernet frames directly in the payload of IPv6 packets, and dynamically generates the IPv6 addresses of the IPv6 header using host MAC addresses and other information, then sends them into IPv6 network for transmission. This document proposes extensions to EVPN for EVN6, including two new route types and related procedures. |
| | BGP Extension for SRv6 Policy Segment List optimization |
| |
|
In some use cases, an SRv6 policy's segment 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 document specifies a BGP extension to indicate whether the endpoint's node SID needs to be included or excluded when installing the SRv6 Policy. This optimization can improve the forwarding efficiency of data packets when End SID and Service SID are present. |
| | BGP SR Policy Extensions for Administrative Flags |
| |
|
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is a set of candidate paths, each consisting of one or more segment lists. This document defines an extension to the BGP SR Policy that sets the administrative state of the candidate path or segment list, facilitating the operation and maintenance of the SR Policy. |
| | RPKI Repository Problem Statement and Analysis |
| |
|
With the increasing deployment of Route Origin Authorizations (ROAs) and Route Origin Validation (ROV), the Resource Public Key Infrastructure (RPKI) has become a critical component for securing inter-domain routing. RPKI leverages cryptographic certificates to validate the authenticity and authorization of IP address and AS number allocations. All RPKI objects are stored in distributed repositories and periodically retrieved by relying parties (RPs). This document presents a data-driven analysis of the current RPKI repository system, including a global survey of AS administrators and an empirical evaluation of repository operations. The analysis reveals that the existing repository architecture suffers from limited scalability and suboptimal efficiency, and is highly sensitive to failures. As the number of ROAs and RPs increases, the growing number of point-to-point connections between repositories and RPs, coupled with the pull-based data synchronization model, significantly degrades the system's scalability and performance. Moreover, a failure or attack on any Publication Point (PP) can prevent RPs from obtaining a complete and up-to-date view of RPKI data. This document further outlines the fundamental requirements for building a scalable, resilient,and efficient RPKI repository architecture to address these limitations. |
| | Flexicast QUIC: combining unicast and multicast in a single QUIC connection |
| |
|
This document proposes Flexicast QUIC, a simple extension to Multipath QUIC that enables a source to send the same information to a set of receivers using a combination of unicast paths and IP multicast distribution trees. |
| | Analysis for the Adverse Effects of LEO Mobility on Internet Congestion Control |
| |
| | draft-lai-ccwg-lsncc-01.txt |
| | Date: |
28/02/2026 |
| | Authors: |
Zeqi Lai, Zonglun Li, Qian Wu, Hewu Li, Qi Zhang |
| | Working Group: |
Individual Submissions (none) |
|
Low-earth-orbit (LEO) satellite networks (LSNs) are increasingly used to carry Internet traffic. However, the fast time-varying conditions induced by LEO mobility can significantly impair the performance of end-to-end Internet congestion control algorithms (CCAs). This document summarizes and analyzes how mobility-driven (often non- congestive) variations in capacity, delay, and loss can mislead representative classes of CCAs, using Starlink as an operational case study. In addition, this document highlights recently-validated measurement and design considerations that treat connection reconfiguration as a phase boundary observable at endpoints, which can improve the interpretation of network signals without requiring changes to the network infrastructure. This document also proposes a transport-agnostic "Path Phase Boundary" (PPB) abstraction and corresponding endpoint behavior considerations for safely using such hints across diverse CCAs. Finally, it outlines a reference endpoint probing profile that can be used to infer PPBs in a deployable, best- effort manner. The goal of this document is informational: to clarify the problem space and to inform future standardization and engineering efforts for congestion control over LSN paths. |
| | Use cases and Requirement for Flow Control Collaboration Across DCNs and WAN |
| |
|
The demand for lossless network transmission and the application of flow control mechanisms have expanded from DCNs (Data Center Networks) to WANs(Wide Area Networks). To mitigate PFC - related issues in WANs, the fine - grained flow control is proposed. This mechanism aims to achieve precise control at flow / tenant levels, limits flow control to specified paths and slices, and provides intelligent congestion backpressure. As current DCN already adopts PFC mechanisms, the fine-grained flow control in WANs needs to work with PFC in DCNs to achieve end-to-end flow control. This document describes the use cases and requirements for the collaboration of flow control mechanisms across DCNs and WANs. |
| | Applying BGP-LS Traffic Engineering Extensions to BGP-LS-SPF |
| |
|
This documents propose to introduce the BGP Link-State (BGP-LS) extensions for Traffic Engineering (TE) to the BGP-LS-SPF SAFI. |
| | Enhanced Bailiwick Checking for DNS Resolvers to Mitigate Cache Poisoning Vulnerabilities |
| |
|
The Domain Name System (DNS) relies on caching to function efficiently. However, DNS cache poisoning remains a significant threat. The "bailiwick" rule is a fundamental security mechanism intended to prevent resolvers from caching out-of-bailiwick data sent by malicious or misconfigured authoritative servers. Current DNS standards provide high-level guidance on bailiwick checking but lack specific algorithmic definitions, leading to inconsistent implementations across different DNS software. These inconsistencies can be exploited, particularly in DNS servers that operate in multiple modes, such as Conditional DNS Servers (CDNS), which may act as both recursive resolvers and forwarders and often share a common cache. This document specifies enhanced and more precise rules for bailiwick checking in DNS resolvers, including those operating as forwarders or CDNS. The goal is to provide clearer guidelines for implementers, reduce the attack surface for cache poisoning, and improve the overall security and robustness of the DNS infrastructure. The recommendations herein are informed by recent research highlighting vulnerabilities in existing bailiwick implementations. |
| | Clarifying DNS Resolver Behavior for the Recursion Desired (RD) Flag |
| |
|
This document addresses inconsistencies observed in the handling of the Recursion Desired (RD) flag in DNS queries by various DNS resolver implementations, particularly when the RD flag is cleared (set to 0). Such inconsistencies have been shown to be exploitable, leading to potent Denial of Service (DoS) amplification attacks. This document provides clear guidance and recommendations for DNS resolver (including forwarding and recursive resolvers) behavior when processing queries with different RD flag settings. The goal is to enhance DNS security, mitigate specific amplification attack vectors, and ensure more predictable and robust DNS operations. |
| | Best Current Practices for DNS Resolver Resilience Against Coordinated Amplification Attacks |
| |
|
This document describes an attack vector, exemplified by the "DNSBomb" attack, that leverages the emergent behavior of several widely- implemented DNS resolver mechanisms. By combining query timeouts, query aggregation, and response timing, an attacker can turn a set of resolvers into powerful amplifiers for a Pulsing Denial-of-Service (PDoS) attack. This attack is difficult to detect due to its low average traffic rate but can be highly effective at overwhelming a target's resources. This document provides operational guidance and a set of best practices for DNS resolver implementers and operators to mitigate this threat. The goal is to harden the DNS ecosystem by reducing the potential for resolvers to be used in such a coordinated fashion, thereby improving the operational resilience of the DNS. |
| | DNS Response Pre-processing Security Guidelines: Awaiting Valid Responses |
| |
|
The security and robustness of the Domain Name System (DNS) significantly depend on how resolvers handle received responses. Current DNS specifications lack exhaustive and consistent guidance on response pre-processing, particularly for malformed or unexpected packets. This specification gap has led to implementation divergences and has been shown to introduce security vulnerabilities such as DNS cache poisoning, Denial of Service (DoS), and resource exhaustion, as detailed in the TUDOOR attack research. This document aims to clarify and standardize the behavior of DNS resolvers when receiving and initially processing responses from upstream servers. The core proposal is the "Awaiting Valid Responses" mechanism, which mandates that a resolver, after issuing a query, MUST maintain a defined waiting period to receive a well- formed, relevant, and validated response. During this period, non- compliant incoming packets should be discarded, and the resolver should continue to wait until a valid response is received or the query times out. This document provides guidance for DNS implementers to mitigate security risks arising from flaws in response pre-processing logic. |
| | Best Practices for Handling Deeply Nested Domain Delegations in Recursive Resolvers |
| |
|
The Domain Name System (DNS) relies on caching to ensure its scalability and performance. However, certain behaviors in the DNS delegation and caching mechanisms can be exploited to circumvent domain name revocation. A recently discovered attack, named PHOENIX DOMAIN T2, allows a malicious domain that has been revoked at its parent zone to remain resolvable for an extended period. This is achieved by creating a chain of deeply nested subdomains, effectively keeping the delegation information alive in recursive resolver caches. This document describes the PHOENIX DOMAIN T2 attack mechanism and proposes a set of operational best practices for DNS recursive resolver operators to mitigate this threat. The primary recommendation is for resolvers to apply additional scrutiny to domain names with an excessive number of labels, which is a key characteristic of this attack. |
| | Strengthening DNS Query Aggregation against ECS-based Attacks |
| |
|
The DNS query aggregation mechanism is a critical defense against DNS cache poisoning attacks that exploit the "Birthday Paradox". However, recent research has revealed that flawed implementations of the EDNS Client Subnet (ECS) option, as specified in RFC 7871, can be exploited to bypass this defense. This allows attackers to force a resolver to issue multiple simultaneous queries for the same domain name by crafting queries with different ECS options. This vulnerability revives the classic DNS Birthday Attack, posing a significant threat to DNS resolvers and the clients they serve. While Section 11.2 of RFC 7871 notes the general risk of Birthday Attacks and suggests marking whether responding nameservers support ECS, it stops short of providing a concrete normative state machine or explicit mitigation process. This document specifies a stricter and more coherent processing model for the ECS option in DNS resolvers to formalize that detection concept. It introduces a mechanism for resolvers to track the ECS support state of authoritative nameservers ("no-ECS-support" state) and mandates strict query aggregation for zones determined to not support ECS. These changes are designed to close the identified vulnerability and restore the effectiveness of query aggregation as a practical defense mechanism. |
| | WIMSE Applicability for AI Agents |
| |
|
This document discusses WIMSE applicability to Agentic AI, so as to establish independent identities and credential management mechanisms for AI agents. |
| | Security Requirements for AI Agents |
| |
|
This document discusses security requirements for AI agents, covering different stages of security interactions. These include provisioning, registration, discovery, cross-domain interconnection, and access control. |
| | Agent Operation Authorization |
| |
|
This document specifies the Agent Operation Authorization framework — a structured mechanism that enables verifiable delegation of actions from human principals to autonomous AI agents with fine-grained agent operation authorization. The framework introduces two distinct phases: * Agent Operation Authorization Request: A structured proposal of operations converted to a JSON Web Token (JWT) without including the user's original natural language input. * Agent Operation Authorization Token: A JSON Web Token representing confirmed authorization for a specific agent operation, enforceable at runtime by agents and verifiers. It cryptographically verifies user intent, prevents unauthorized or hallucinated actions, and ensures auditable traceability of each authorized operation. |
| | BGP Failure Propagation (BGP-FP) for Enhancing Control-Plane Convergence |
| |
|
This document specifies BGP Failure Propagation (BGP-FP), an infrastructure and protocol that improves inter-domain routing convergence by accelerating the removal of stale (invalid) routes. BGP-FP uses (1) an Agent deployed per Autonomous System (AS) to detect inter-AS reachability changes and to configure local routers, (2) a logically centralized Repository to store and selectively forward AS reachability state, and (3) BGP Large Communities as a "route freshness" marker. Agents validate and apply Repository updates to filter routes that traverse AS pairs whose reachability has been lost or that violate the originating AS's forwarding intent, reducing route-flap propagation in the control plane. This document clarifies that "AS reachability" refers to the reachability between two ASes, not to the state of individual physical or logical links within an AS. If multiple links exist between two ASes, the failure of a single link that does not break overall AS-to-AS reachability does not trigger the BGP-FP mechanism. A new Repository deployment model is introduced, suggesting that the Repository be operated by a newly established organization composed of Tier-1 ASes and Regional Internet Registries (RIRs), using a distributed deployment with Byzantine fault-tolerant consensus and rotating leadership. |
| | Ogg Stem Files |
| |
|
This document defines a multi-track profile of the Ogg container format for storing stems that is also backwards compatible with existing media players. |
| | Matroska Stem Files |
| |
|
This document defines a multi-track profile of the Matroska container format for storing stems that is also backwards compatible with existing media players. |
| | Additional Hash Algorithms for OAuth 2.0 PKCE and Proof-of-Possession |
| |
|
This document defines SHA-512 as an additional hash algorithm for OAuth 2.0 Proof Key for Code Exchange (PKCE), mutual-TLS certificate- bound access tokens, and Demonstrating Proof of Possession (DPoP), for use in deployments operating under security policies that prohibit the use of SHA-256, which is otherwise mandated or the only option in these mechanisms. |
| | BGP-LS-SPF Extensions for SRv6 Policy State Synchronization |
| |
|
This document defines extensions to BGP-LS-SPF (BGP Link State Shortest Path First) to support synchronization of Segment Routing over IPv6 (SRv6) policy state information. It introduces a new optional Sub-TLV for the SRv6 End.X SID TLV that indicates whether an SRv6 SID is currently active in an SR policy. This enables dynamic interaction between SR policies and BGP-LS-SPF route computation, improving network responsiveness to policy changes. |
| | IGP Extensions for Sub-interface Relationship Information |
| |
|
This document extends ISIS and OSPF, allowing a network device to advertise the relationship between a physical interface and its sub- interfaces. This extension enables the links based on sub-interfaces to participate in the alternative paths for load balancing in SRv6 BE bandwidth polling. |
| | Framework and Applicability of Computation-aware Traffic Steering (CATS) in Optical Transport Networks (OTN) |
| |
|
Computation-aware Traffic Steering (CATS) offers a framework for selecting computation service sites based on computation capabilities and load, and considering the network capabilities and state on the paths to the sites. Optical Transport Networks (OTN) provide guaranteed separation of traffic along with reserved hardware resources offering bandwidth and quality of service promises. This document describes how OTN may be used to support a CATS system to achieve the stringent performance targets required by demanding service environments. |
| | In Situ Operations,Administration,and Maintenance (IOAM) Extension for Bit Error Rate Measurement |
| |
|
Networks may experience transmission bit errors due to various factors, such as poor fiber quality, thereby corrupting packets. Merely measuring the end-to-end bit error rate makes it difficult to locate the exact link wich poor quality. Therefore, a measurement method is needed to collect bit error rate information along the entire path to locate the specific linke with poor quality. This document extends IOAM with a new Trace-Type and "Interface Bit Error Rate" field to collect the interface error rate along the path. This new Trace-Type is applicable to Pre-allocated Trace, Incremental Trace, and Direct Exporting Option-Type. |
| | Benchmarking Methodology for Route Origin Validation (ROV) |
| |
|
This document defines a benchmarking methodology for routers that implement ROV. The methodology focuses on device-level behavior, including processing of validated ROA payload (VRP) updates, the interaction between ROV and BGP, control-plane resource utilization, and the scalability of ROV under varying operational conditions. The procedures described here follow the principles and constraints of the Benchmarking Methodology Working Group (BMWG) and are intended to produce repeatable and comparable results across implementations. |
| | BGP PORT EC for AIDC |
| |
|
This document introduces a new BGP extended community attribute for use in AI computing, which announces the port ID between Leaf switches and servers as preparation for sending large-scale traffic before initiating AI tasks. |
| | Functional entities for enabling per service eco-data reporting |
| |
|
This document provides an architectural mapping between the Exigence intra-domain functional architecture and the IETF GREEN Framework for Energy Efficiency Management. The purpose is to harmonize Exigence’s service-centric energy attribution and green orchestration functions with the multi-layered monitoring, control and API-exposed energy management architecture defined in the GREEN reference model. This document identifies a number of functional components enabling a service-centric energy attribution for the network domain, and describes their mapping to the IETF GREEN framework for energy efficiency management, including interfaces and energy-object concepts. Such functional components allow the realization of green orchestration capabilities with multi-layered monitoring, control and API-exposed energy management. |
| | Agent Envelope Exchange (AEE): A Minimal JSON Envelope Format for Inter-Agent Communication |
| |
|
Agent Envelope Exchange (AEE) defines a minimal, transport- independent JSON envelope format for communication between autonomous AI agents, traditional services, and human participants. The envelope comprises 14 well-defined fields that provide message identity, typing, correlation, tracing, priority, and extensibility without prescribing payload semantics or transport mechanisms. AEE separates the concerns of message routing and lifecycle management (the envelope) from domain-specific meaning (intent schemas), enabling portable, composable, and auditable workflows across heterogeneous agent frameworks. This document specifies the envelope structure, validity rules, conformance levels, entity identifier conventions, a reserved intent namespace for protocol negotiation, and a referencing strategy that avoids envelope nesting. |
| | Agent Orchestration Control Layers (AOCL) Protocol |
| |
|
Agent Orchestration Control Layers (AOCL) is a protocol that standardizes how an orchestrator processes incoming events by passing them through a layered control pipeline. AOCL defines an eleven- layer taxonomy covering ingress normalization, identity scoping, smart routing, policy gating, plan decomposition, context retrieval, prompt shaping, delegation and execution, verification, response assembly, and audit writeback. The protocol is runtime-agnostic and framework-agnostic, producing auditable governance traces as a first- class output. AOCL supports both sequential pipeline and directed acyclic graph (DAG) execution modes, with explicit bypass and branch semantics that mandate audit records for all control-flow deviations. |
| | Verifiable Operations Ledger and Trace (VOLT) Protocol |
| |
|
The Verifiable Operations Ledger and Trace (VOLT) protocol defines a minimal, interoperable format for producing tamper-evident execution traces for agentic AI workflows. VOLT records are linked via SHA-256 hash chains and packaged into portable Evidence Bundles that can be verified independently by any conformant implementation. VOLT functions as a "flight recorder" for AI agent operations: it captures the sequence of events -- messages received, policy decisions evaluated, human approvals granted, tools invoked, and results returned -- with cryptographic integrity guarantees that detect post-hoc modification, deletion, or insertion of records. The protocol is privacy-first by design. Events carry metadata and content-addressed references rather than raw secrets or sensitive payloads. Evidence Bundles support explicit redaction, optional Ed25519 signatures for non-repudiation, and both rolling and final snapshot modes for long-running workflows. |
| | BGP Flow Specification Filter by ClassID |
| |
|
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 ClassID to support ClassID filtering. |
| | SRv6 Extensions for RDMA Multicast Delivery |
| |
|
This document specifies SRv6 (Segment Routing over IPv6) extensions for multicast delivery of RDMA (Remote Direct Memory Access) Reliable Connection (RC) traffic. It defines a new SRv6 endpoint behavior, End.MT, that performs per-receiver RDMA Base Transport Header (BTH) modifications at edge nodes of the multicast tree. It also specifies procedures for hop-by-hop aggregation of RDMA ACK, NACK, and CNP response messages along the reverse path. Together, these extensions allow RDMA RC endpoints to communicate using standard point-to-point Queue Pair (QP) semantics while the network distributes data packets over an IP multicast tree. Target deployment scenarios include multi-replica distributed storage writes, HPC collective communications, AI training parameter distribution, and large-scale inference KV cache distribution. |
| | Fine-grained QoE Enhancement using Semantic Tables |
| |
|
This document describes a fine-grained Quality of Experience (QoE) enhancement mechanism using semantic tables deployed at network forwarding nodes. The mechanism enables application-level SLA (Service Level Agreement) guarantees by carrying address indices and high-frequency-changing information in packets while maintaining low- frequency-changing semantic information at network nodes. This approach overcomes the limitations of traditional Application-aware Networking (APN) solutions, including excessive packet header overhead. The mechanism supports collaborative optimization across network, computing, and energy dimensions, and can be deployed over MPLS, IPv4/v6, SRv6, and other protocol data planes. |
| | Load Balancing Hash Polarization Mitigation Extension |
| |
|
This document defines a hash polarization mitigation extension for Link Aggregation (LAG) and Equal-Cost Multi-Path (ECMP) routing. This document specifies hash input field selection rules, Shift Factor definition and generation methods, hash value adjustment algorithms, and normative requirements for device processing procedures. |
| | Signaling Optimization Objective and Bounded Metrics for MPLS Fast Reroute Backup LSP Tunnels |
| |
|
This document introduces RSVP-TE signaling procedures that enable the head-end Label Switched Router (LSR) of a local-protection-desiring Label Switched Path (LSP) to influence the optimization objective and bounded metric constraints used for the path computation of a backup LSP tunnel at a Point of Local Repair (PLR). |
| | Combined Hash Mechanism for ECMP/LAG Load Balancing |
| |
|
This document specifies a combined hash mechanism for load balancing in Equal-Cost Multi-Path (ECMP) and Link Aggregation Group (LAG) environments. When processing tunneled traffic, traditional hash methods that operate on either outer or inner packet fields may result in uneven traffic distribution (polarization). This specification defines a method to extend effective hash entropy by combining multiple independently computed hash values, enabling network devices to consider multi-layer packet information for path selection, thereby improving traffic distribution uniformity. This mechanism is compatible with existing hash computation architectures and does not require packet format modifications or new protocol field definitions. |
| | Congestion-Aware Adaptive Flow Table Switching for ECMP |
| |
|
This document defines a congestion-aware adaptive flow table switching mechanism for Equal-Cost Multi-Path (ECMP) routing. The mechanism periodically assesses the congestion state of egress ports and progressively adjusts flow table mappings based on quantified congestion levels. This addresses the port congestion issues that occur in traditional ECMP load balancing when traffic patterns change suddenly or multicast traffic is present, while maintaining packet ordering within flows. |
| | Packet-Triggered Statistics Reporting for In-situ OAM |
| |
|
This document defines a packet-triggered statistics reporting extension for In-situ Operations, Administration, and Maintenance (IOAM). The extension specifies a 2-bit Cycle Identifier field that enables receiving nodes to trigger statistics reporting based on observed Cycle ID transitions in received packets. This document defines the Cycle ID field format, node processing procedures, and keepalive packet generation rules. |
| | Scalable Data Plane Architecture for Bit Index Explicit Replication (BIER) |
| |
|
This document describes an optimized data plane forwarding architecture for Bit Index Explicit Replication (BIER). The standard BIER forwarding procedures, as conceptually described in RFC 8279, imply a per-bit evaluation of the BitString against the Bit Index Forwarding Table (BIFT) on each Bit Forwarding Router (BFR). When the BitStringLength is large (e.g., 256 bits or more), this conceptual model presents implementation challenges for high-speed ASIC/NPU forwarding engines in terms of processing latency and hardware table resources. This document defines two conceptual data structures -- a Replication Member Table and an Interface BitMask Table -- that decouple the multicast replication decision from per-bit BitString parsing. The resulting forwarding pipeline operates in time proportional to the number of egress interfaces rather than the BitString length, enabling deterministic and scalable hardware processing. This mechanism is semantically equivalent to the forwarding procedures of RFC 8279 and does not modify the BIER encapsulation or introduce new protocol signaling. |
| | Source-IP-Origin-AS Filter for BGP Flow Specification |
| |
|
This document defines an extension to the Border Gateway Protocol (BGP) Flow Specification (FlowSpec) to enable filtering based on the Origin Autonomous System (AS) of the source IP address. This extension is particularly useful in mitigating Distributed Denial of Service (DDoS) attacks where the source IP addresses are dynamic but belong to a specific source AS. |
| | Source-IP-Community Filter for BGP Flow Specification |
| |
|
BGP Flowspec mechanism (BGP-FS) 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 to support community-level filtering. The match field is the community of the source IP address that is encoded in the Flowspec NLRI. This function is applied in a single administrative domain. |
| | A YANG Data Model for Network Diagnosis using Scheduled Sequences of OAM Tests |
| |
|
This document defines a YANG data model to support on-demand network diagnosis using Operations, Administration, and Maintenance (OAM) tests. This document defines both 'oam-unitary-test' and 'oam-test- sequence' YANG modules to manage the lifecycle of network diagnosis procedures, intended for use by external management and orchestration systems (including SDN controllers and network orchestrators), rather than by individual network nodes. |
| | A YANG Data Model for Traffic Engineering Tunnels,Label Switched Paths,and Interfaces |
| |
| | draft-ietf-teas-yang-te-43.txt |
| | Date: |
28/02/2026 |
| | Authors: |
Tarek Saad, Rakesh Gandhi, Xufeng Liu, Vishnu Beeram, Igor Bryskin |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
This document defines a YANG data model for the provisioning and management of Traffic Engineering (TE) tunnels, Label Switched Paths (LSPs), and interfaces. The model covers data that is independent of any technology or dataplane encapsulation and is divided into two YANG modules that cover device-specific, and device independent data. This model covers data for configuration, operational state, remote procedural calls, and event notifications. |
| | Realizing Network Slices in IP/MPLS Networks |
| |
| | draft-ietf-teas-ns-ip-mpls-07.txt |
| | Date: |
28/02/2026 |
| | Authors: |
Tarek Saad, Vishnu Beeram, Jie Dong, Joel Halpern, Shaofu Peng |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
Realizing network slices may require the Service Provider to have the ability to partition a physical network into multiple logical networks of varying sizes, structures, and functions so that each slice can be dedicated to specific services or customers. Multiple network slices can be realized on the same network while ensuring slice elasticity in terms of network resource allocation. This document describes a scalable solution to realize network slicing in IP/MPLS networks by supporting multiple services on top of a single physical network by by requiring compliant domains and nodes to provide forwarding treatment (scheduling, drop policy, resource usage) based on slice identifiers. |
| |
|
| |
| | YANG Data Model for IPv6 Neighbor Discovery |
| |
|
This document defines a YANG data model to configure and manage IPv6 Neighbor Discovery (ND) and related functions, including IPv6 address resolution, redirect function, proxy Neighbor Advertisement, Neighbor Unreachability Detection (NUD), Duplicate Address Detection (DAD), and Enhanced Duplicate Address Detection. |
| | Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI) |
| |
|
This document defines the Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI) protocol, which provides a solution for secure zero-touch onboarding of resource-constrained (IoT) devices into the network of a domain owner. This protocol is designed for constrained networks, which may have limited data throughput or may experience frequent packet loss. cBRSKI is a variant of the BRSKI protocol, which uses an artifact signed by the device manufacturer called the "voucher" which enables a new device and the owner's network to mutually authenticate. While the BRSKI voucher data is encoded in JSON, cBRSKI uses a compact CBOR-encoded voucher. The BRSKI voucher data definition is extended with new data types that allow for smaller voucher sizes. The Enrollment over Secure Transport (EST) protocol, used in BRSKI, is replaced with EST-over- CoAPS; and HTTPS used in BRSKI is replaced with DTLS-secured CoAP (CoAPS). This document Updates RFC 8995 and RFC 9148. |
| | A YANG Data Model for Optical Impairment-aware Topology |
| |
|
In order to provision an optical connection through optical networks, a combination of path continuity, resource availability, and impairment constraints must be met to determine viable and optimal paths through the network. The determination of appropriate paths is known as Impairment-Aware Routing and Wavelength Assignment (IA-RWA) for a Wavelength Switched Optical Network (WSON), while it is known as Impairment-Aware Routing and Spectrum Assignment (IA-RSA) for a Spectrum Switched Optical Network (SSON). This document provides a YANG data model for the impairment-aware Traffic Engineering topology (TE topology) in optical networks. It augments the technology agnostic YANG Data Model for TE topologies. The topology YANG model provides read-only topology data including optical impairments that can be used for example by a Path Computation Engine (PCE) for calculating an optically feasible path for a new connection before it is established through an optical network. |
| | YANG Data Models for requesting Path Computation in WDM Optical Networks |
| |
|
This document provides a mechanism to request path computation in Wavelength-Division Multiplexing (WDM) optical networks composed of Wavelength Switched Optical Networks (WSON) and Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) switched technologies. This model augments 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-path-computation once it has been published. |
| | DNS Multiple QTYPEs |
| |
|
This document specifies a method for a DNS client to request additional DNS record types to be delivered alongside the primary record type specified in the question section of a DNS QUERY (OpCode=0). |
| | A YANG Module for Entitlement Inventory |
| |
|
This document defines a YANG data model for managing software-based entitlements (licenses, authorization tokens, pay-as-you-go service credentials…) within a network inventory. The model represents the relationship between organizational entitlements, network element capabilities, and the constraints that entitlements impose on capability usage. This data model enables operators to determine what capabilities their network elements possess, which capabilities are currently entitled for use, and what restrictions apply. The model supports both centralized entitlement management and device-local entitlement tracking for physical and virtual network elements. |
| | PQ/T Hybrid Composite Signatures for JOSE and COSE |
| |
|
This document describes JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for PQ/T hybrid composite signatures. The composite algorithms described combine ML-DSA as the post-quantum component and either ECDSA or EdDSA as the traditional component. |
| | 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. |
| | Automatic Configuration of Email,Calendar,and Contact Server Settings |
| |
|
This document specifies an automatic configuration mechanism for email, calendar, and contact user agent applications. Service providers publish standardized configuration information that user agent applications retrieve and use to simplify server setup procedures. |
| | Adaptive Subscription to YANG Notification |
| |
|
This document defines a YANG data model and associated mechanism to enable adaptive subscriptions to YANG notifications. The publisher can dynamically adjust the periodic update interval based on the evaluation of pre-configured conditions (e.g., thresholds or expressions). This allows for finer-grained telemetry by increasing update frequency when certain criteria are met, and reducing it otherwise. |
| | Network Digital Twin: Concepts and Reference Architecture |
| |
|
Digital Twin technology has seen rapid adoption in Industry 4.0. The application of Digital Twin technology in the networking field is meant to develop various rich network applications, realize efficient and cost-effective data-driven network management, and accelerate network innovation. This document presents an overview of the concepts of Network Digital Twin, provides the basic definitions and a reference architecture, lists a set of application scenarios, and discusses such technology's benefits and key challenges. |
| | The IPv6 Segment Routing (SRv6) Domain Name System (DNS) Resource Record |
| |
|
A Domain Name System (DNS) Resource Record (RR) Type is specified for storing IPv6 Segment Routing (SRv6) Information in the DNS. |
| | MNA for Performance Measurement with Alternate Marking Method |
| |
| | draft-cx-mpls-mna-inband-pm-08.txt |
| | Date: |
27/02/2026 |
| | Authors: |
Weiqiang Cheng, Xiao Min, Rakesh Gandhi, Greg Mirsky, Giuseppe Fioccola |
| | Working Group: |
Individual Submissions (none) |
|
MPLS Network Action (MNA) is used to indicate action for Label Switched Paths (LSPs) and/or MPLS packets, and to transfer data needed for the action. This document defines MNA encodings for MPLS performance measurement with alternate marking method, which performs flow-based packet loss, delay, and jitter measurements on MPLS live traffic. |
| | The Asynchronous Remote Key Generation (ARKG) algorithm |
| |
|
Asynchronous Remote Key Generation (ARKG) is an abstract algorithm that enables delegation of asymmetric public key generation without giving access to the corresponding private keys. This capability enables a variety of applications: a user agent can generate pseudonymous public keys to prevent tracking; a message sender can generate ephemeral recipient public keys to enhance forward secrecy; two paired authentication devices can each have their own private keys while each can register public keys on behalf of the other. This document provides three main contributions: a specification of the generic ARKG algorithm using abstract primitives; a set of formulae for instantiating the abstract primitives using concrete primitives; and an initial set of fully specified concrete ARKG instances. We expect that additional instances will be defined in the future. |
| | IOAM Trace Option Extensions for Incorporating the Alternate-Marking Method |
| |
|
In situ Operation, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information, which leverages IOAM Trace Option to incorporate IOAM data fields into in- flight data packets. The Alternate-Marking method is used to measure performance metrics on live traffic, such as packet loss, delay, and jitter. This document extends IOAM Trace Option for incorporating the Alternate-Marking method to augment IOAM in performance measurement. |
| | Intra-domain Source Address Validation (SAVNET) OAM |
| |
|
This document is a framework for how Source Address Validation (SAVNET) can be applied to operations and maintenance procedures for Intra-domain network. The document is structured to outline how Operations and Management (OAM) functionality can be used to assist in fault, configuration, accounting, performance, and security management, commonly known by the acronym FCAPS. |
| | Signaling SAVNET Capability Using IGP |
| |
|
Existing intra-domain SAV solutions (e.g., BCP38 [RFC2827] and BCP84 [RFC3704]) have problems of high operational overhead or inaccurate validation (see [I-D.ietf-savnet-intra-domain-problem-statement]). To address these problems and guide the design of new intra-domain SAV solutions,[I-D.ietf-savnet-intra-domain-architecture] proposes the architecture of intra-domain SAVNET and introduces the use of SAV-specific information in intra-domain networks. This document defines a mechanism to signal the SAVNET capablity and the source prefix using IGP and BGP-LS. |
| | Post-Quantum Traditional (PQ/T) Hybrid PKI Authentication in the Internet Key Exchange Version 2 (IKEv2) |
| |
|
One IPsec area that would be impacted by Cryptographically Relevant Quantum Computer (CRQC) is IKEv2 authentication based on traditional asymmetric cryptographic algorithms: e.g RSA, ECDSA, which are widely deployed authentication options of IKEv2. There are new Post-Quantum Cryptographic (PQC) algorithms for digital signature like NIST [ML-DSA], However, it takes time for new cryptographic algorithms to mature, There is security risk to use only the new algorithm before it is field proven. This document describes a hybrid PKI authentication scheme for IKEv2 that incorporates both traditional and PQC digital signature algorithms, so that authentication is secure as long as one algorithm in the hybrid scheme is secure. |
| | IOAM Direct Exporting (DEX) Option Extensions for Incorporating the Alternate-Marking Method |
| |
|
In situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information. Specifically, passport-based IOAM allows telemetry data generated by each node along the path to be pushed into data packets when they traverse the network, while postcard-based IOAM allows IOAM data generated by each node to be directly exported without being pushed into in-flight data packets. The Alternate-Marking method is used to measure performance metrics on live traffic, such as packet loss, delay, and jitter. This document extends IOAM Direct Export (DEX) Option-Type to integrate the Alternate-Marking Method into IOAM to augment IOAM in performance measurement. |
| | Inter-domain Source Address Validation (SAVNET) OAM |
| |
|
This document is a framework for how Source Address Validation (SAVNET) can be applied to operations and maintenance procedures for Inter-domain network. The document is structured to outline how Operations and Management (OAM) functionality can be used to assist in fault, configuration, accounting, performance, and security management, commonly known by the acronym FCAPS. |
| | RPKI to Router Protocol over QUIC |
| |
|
The Resource Public Key Infrastructure (RPKI) to Router Protocol provides a simple but reliable mechanism to receive cryptographically validated RPKI prefix origin data and router keys from a trusted cache. RPKI to Router (RTR) Protocol can be carried over various transports such as TCP, SSH or else. QUIC provides practical and secure semantics for the RTR protocol, particularly fast connection establishment and multi-stream carrying, thereby reducing the time required to complete RTR data synchronization. This document describes how to use RTR Protocol over the QUIC transport protocol, named RTRoQUIC. |
| | Split signing algorithms for COSE |
| |
|
This specification defines COSE algorithm identifiers for negotiating how to split a signature algorithm between two cooperating parties. Typically the first party hashes the data to be signed and the second party finishes the signature over the hashed data. This is a common technique, useful for example when the signing private key is held in a smart card or similar hardware component with limited processing power and communication bandwidth. The resulting signatures are identical in structure to those computed by a single party, and can be verified using the same verification algorithm without additional steps to preprocess the signed data. |
| | SRv6 behavior extention for Flow Control in WAN |
| |
|
In the wake of the continuous emergence of novel AI technologies, including collaborative training, distributed inference and the like, the scenario in which different data centers communicate via the RDMA (Remote Direct Memory Access) protocol has emerged as a new requirement. similar to data center networks, wide area networks (WANs) should also be equipped with certain flow control capabilities, nodes in the wide area network (WAN) need to quickly and accurately notify upstream traffic nodes of their congestion status. Upon receiving the congestion notification, upstream nodes can take responsive actions to mitigate network congestion. By extending SRv6[RFC 8986] technology, specific services can be carried over SRv6 policies, which enables the precise delivery and response of congestion signals. For traffic carried over SRv6 policies, the service traffic path is explicitly orchestrated via the Segment List in the SRH header. By parsing the sequence of the Segment List, downstream nodes or controllers can accurately identify the upstream nodes and interfaces corresponding to the current traffic, thus enabling the rapid notification of congestion information to the upstream. Since each SID in the Segment List is a 128-bit IPv6 address that represents a specific behaviour (e.g., End, End.X), extending existing behaviours to mark their capability to receive and process congestion signals allows flexible control over the delivery mode of congestion signals in the WAN. The specific packet formats and contents of congestion signals vary in various ways and are continuously being updated. This document takes the most commonly used PFC backpressure notification mechanism as an example to elaborate on the overall workflow of WAN congestion information notification and the extensions to the SRv6 protocol. PFC technology is widely deployed in RoCEv2 networks within data centers to report congestion signals. By leveraging SRv6 and NRP technologies, it is possible to effectively control the propagation range and path of PFC backpressure signals in wide area networks, thereby avoiding issues such as deadlocks and the excessive propagation of congestion scope. |
| | Route Server Next Hop Translation |
| |
|
With the advent of RFC8950, Internet Exchang Points (IXPs) are enabled to rely solely on IPv6 addresses for adressing in their peering LANs. However, routers not supporting RFC8950 are a technical roadblock. It is easier to extend the capabilities of the IXP Route Server (RS) instead of those of every unsupporting router. Thus, this document introduces the concept of Specific Local Address Tables (SLATs). SLATs translate BGP next hops between all IXP members, regardless of their RFC8950 support, paving the way for IPv6-only IXPs. This document also introduces another, more transparent variant of BGP next hop translation applicable in IXPs which do not employ ARP and ND proxying. This document updates RFC 6890 by registering a special-purpose address, and RFC 7947 by specifying an allowed route modification at the route server. |
| | Unbound DATA for CONNECT in HTTP/3 |
| |
|
This document defines a new HTTP/3 frame type, UNBOUND_DATA, and a corresponding SETTINGS parameter that enables endpoints to negotiate its use. When an endpoint sends an UNBOUND_DATA frame on a CONNECT request or response stream, it indicates that all subsequent octets on that stream are interpreted as tunneled bytes. This applies both to octets transmitted after CONNECT or extended CONNECT. The use of UNBOUND_DATA removes the need to encapsulate each portion of the data in DATA frames, reducing framing overhead and simplifying transmission of long-lived CONNECT tunnels. |
| | Congestion Control Based on SRv6 Path |
| |
|
This document describes a congestion control solution based on SRv6. It defines mechanisms for congestion notification and flow control within an SRv6-based network, optimizing congestion handling through hierarchical congestion control messages along SRv6 paths. |
| | Extensions to Compress and Derive Fields in HTTP Datagrams |
| |
|
This document defines extensions for HTTP Datagram-based protocols that improve transmission efficiency by introducing templates for compressing or deriving datagram fields. These templates allow endpoints to define parts of datagrams that are static and can be removed, and other parts that can be derived (such as packet lengths and checksum values). Additionally, this document defines a checksum offload procedure enabling receivers to complete Internet checksums using sender- provided partial values. These optimisations reduce per-packet overhead, processing cost, and increase the effective maximum transmission unit (MTU) when datagrams are encapsulated in QUIC DATAGRAM frames. |
| | Congestion Notification for Pause |
| |
|
This document describes the necessity and feasibility to introduce a mechanism of congestion notification for pause. After receiving the L2 pause frames from the destination data center gateway, the egress provider edge node sends the congestion notifications to the upstream provider nodes and the ingress provider edge node in a format defined in this document. The upstream provider nodes and the ingress provider edge node must pause the forwarding of IP flows identified by the congestion notifications. And then the ingress provider edge node may send the L2 pause frames to the source data center gateway. |
| | Integration of Network Management Agent (NMA) into ACTN-Based Optical Network |
| |
|
With the growth of optical network scale, the complexity of network operation and maintenance has increased dramatically. Enhancing the intelligence level of optical network operation and management and building high-level autonomous optical networks have become the common vision of global operators. The development of AI, especially large AI model technologies, provides a feasible technical path for realizing autonomous perception, decision-making, analysis, and execution. The existing ACTN architecture provides network abstraction and control functions for optical networks but lacks higher-level autonomous capabilities. This document explores the introduction of AI based Network Management Agent(NMA) functions into ACTN-based optical networks to achieve high-level autonomy of optical networks. It discusses the ACTN-enhanced architecture of optical networks after the introduction of NMAs, including key components, interaction relationships, new interface requirements in the enhanced architecture, as well as typical use cases of agent-based autonomous operation and maintenance for optical networks. The document aims to improve the autonomy level of optical networks and promote the realization of autonomous optical networks by extending the original ACTN architecture. |
| | Distributed Inference Network (DIN) Problem Statement,Use Cases,and Requirements |
| |
|
This document describes the problem statement, use cases, and requirements for a "Distributed Inference Network" (DIN) in the era of pervasive AI. As AI inference services become widely deployed and accessed by billions of users, applications and devices, traditional centralized cloud-based inference architectures face challenges in scalability, latency, security, and efficiency. DIN aims to address these challenges by leveraging distributed edge-cloud collaboration, intelligent scheduling, and enhanced network security to support low- latency, high-concurrency, and secure AI inference services. |
| | Update to Recognize the IETF IPMC as the IETF Trust Successor |
| |
|
This document updates IETF documents that reference the IETF Trust to include the Trust's successor, the IETF Intellectual Property Management Corporation. Discussion of this draft is on the ipr-wg@ietf.org mailing list. |
| | 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. |
| | Multi-agent Collaboration Protocol Suite |
| |
| | draft-li-dmsc-macp-02.txt |
| | Date: |
27/02/2026 |
| | Authors: |
Xueting Li, Jun Liu, Chenguang Du, Lianhua Zhang |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies a Multi-agent Collaboration Protocol Suite, which enables scalable, secure, and semantically driven collaboration among distributed agents across heterogeneous networks. The protocol suite introduces Agent Gateways as key entities responsible for agent registration, authentication, capability management and other functions, while preserving direct peer-to-peer semantic interactions among agents. |
| | Sustainability holistic API for Path Energy Evaluation (SHAPE) |
| |
| | draft-amalj-sustain-shape-01.txt |
| | Date: |
27/02/2026 |
| | Authors: |
Adrian Sanchez, Alberto Rodriguez-Natal, Luis Contreras, Marisol Amador, Jan Lindblad |
| | Working Group: |
Individual Submissions (none) |
|
This document describes an API to query a network regarding its Energy Traffic Ratio and other sustainability-related metrics for a given network path. |
| | Combined NEXT-CSID and REPLACE-CSID flavor in SRv6 |
| |
|
In order to reduce the size of SRv6 SID, NEXT-CSID and REPLACE-CSID flavors for SRv6 endpoint behaviors are proposed. Similar to PSP and USD, NEXT-CSID and REPLACE-CSID can be combined just like PSP & USD. This document defines the combined NEXT&REPLACE-CSID flavor, which can provide more efficient compression for SRv6 Segment-List encoding in the Segment Routing Header (SRH). |
| | A Control Plane Framework for Multi-Domain Deterministic Networking (DetNet) |
| |
|
Deterministic Networking (DetNet) provides the capability to carry specified unicast or multicast data flows for real-time applications with extremely low data loss rates and bounded latency over a path or network. As DetNet deployments expand, they will inevitably need to span multiple domains that may be under separate administrative or technological control. This creates a need for a control plane solution that can establish and maintain end-to-end DetNet services across these domain boundaries. This document defines a generic framework for a multi-domain DetNet control plane. It first establishes a working definition of a "DetNet Domain" for the purpose of path computation and control. It then describes two high-level architectural approaches for inter- domain path computation and resource reservation: a Hierarchical model and a peer-to-peer "stitching" model. While a Path Computation Element (PCE)-based realization is used as an illustrative example, the framework is designed to be applicable to any controller-plane technology that satisfies the stated functional requirements. This framework provides the foundation for more specific work on multi- domain DetNet solutions. |
| | Extension for BMP Peer Header |
| |
|
This document defines new BMP peer types that allows the per-peer header to carry its corresponding interface information, especially in order to distinguish BGP peers established based on interfaces. |
| | Interface Index Capability for BGP |
| |
|
In some scenarios using unnumbered links, it is necessary for the BGP protocol to advertise the link's Interface Index and obtain the peer's Remote Interface Identifier. This document defines a new BGP capability [RFC 5492] for advertising local interface indexes and obtaining neighbor interface indexes. |
| | Security Operations Fundamentals and Guidance |
| |
|
Security operators are responsible for detecting malicious activity, responding to threats and defending their networks and systems from cyber attacks. Security operations are commonly entwined with other operational and management priorities to ensure that both security and operational priorities are considered holistically. With security operators being a crucial part of operation, management and security of the network, it is valuable to give consideration to them during the design of new protocols. This document builds upon draft-ietf-opsawg-rfc5706bis, describing the fundamentals of security operations to provide a foundation for considerations for protocol design and guidance. This document also describes how security operations considerations can be most usefully included in other IETF documents. |
| | Mobility Management for Inter-SNO Sharing in LEO Satellite Networks |
| |
|
Deploying a low-Earth orbit (LEO) satellite network typically requires substantial financial investment and long development cycles. To shorten deployment timelines and alleviate economic burdens, collaborative constellation deployment has gained attention. In such a model, multiple satellite network operators (SNOs) contribute their respective constellations to jointly deliver LEO connectivity services. Despite these potential benefits, the high mobility of LEO satellites introduces operational complexity. As satellites move rapidly across coverage regions, terrestrial users are frequently reassigned to different access satellites, which may be connected to distinct SNO core networks. These cross-operator handovers, referred to as inter-SNO handovers, can negatively affect service continuity and overall network robustness. To address these challenges, this document outlines a mobility management framework aimed at supporting cooperative LEO constellation operation. The framework separates the satellite access layer from individual SNO core infrastructures, thereby permitting flexible mapping between shared access satellites and multiple operator cores. Through this decoupled architecture, user sessions can remain associated with their original SNO core networks whenever operational conditions permit. The framework incorporates a dynamic SNO association strategy that seeks to limit the frequency of inter-SNO handovers. Furthermore, in scenarios where such handovers cannot be avoided, a proactive optimization procedure is employed to shorten interruption duration and enhance the efficiency of the handover process. |
| | The Sustainability HTTP Response Header Field |
| |
|
This document defines the Sustainability HTTP response header field. This field provides a mechanism for servers to report the environmental impact and carbon footprint metrics associated with the processing and delivery of an HTTP request. By defining this header as a Structured Field, this specification ensures high parsing reliability and compatibility with HTTP/2 and HTTP/3 header compression mechanisms, thereby mitigating the secondary environmental costs of transmitting the metadata itself. |
| | Cross-Platform Policy Parental Control (X-PPC) for Household Governance |
| |
|
This document defines the Cross-Platform Policy Parental Control (X-PPC) protocol for consistent policy enforcement across heterogeneous household endpoints including Desktop PCs, Mobile Devices, Gaming Consoles, Handhelds, and Smart TVs. X-PPC 1.0.0 specifies a 3-tier hybrid trust-chain architecture designed to enable policy enforcement during periods of network unavailability. The protocol defines interoperable message formats, signature requirements, and enforcement semantics that OS and device vendors can implement using platform-appropriate mechanisms. |
| | Using LISP as a Network Substrate for AI Agent Communication |
| |
|
The emergence of distributed artificial intelligence (AI) systems, particularly those composed of autonomous agents operating across cloud, edge, and endpoint environments, introduces new networking requirements. These include location transparency, seamless mobility, multi-homing, and logical isolation at scale. This document explores how the Locator/ID Separation Protocol (LISP) can serve as a robust network substrate to meet these requirements. The document outlines use cases, design considerations, and minimal extensions to the existing LISP framework to support context-aware mapping and AI agent-centric communication. |
| | Export of RoCEv2 Base Transport Header (BTH) Information Using IP Flow Information Export (IPFIX) |
| |
|
This document defines a new set of IP Flow Information Export (IPFIX) Information Elements (IEs) for exporting Base Transport Header (BTH) information for RDMA over Converged Ethernet version 2 (RoCEv2) traffic. These extensions enable network monitoring systems to collect and analyze the characteristics of RDMA traffic widely used in high-performance computing, storage, and artificial intelligence applications. |
| | ICMP Extension for SAVNET Validation |
| |
|
This document defines new ICMP and ICMPv6 error codes to send error messages to the source device when forwarding Ping or Traceroute packets is dropped due to SAVNET validation failure. The error message explicitly states the reason for dropping as "SAVNET Validation Failed," thereby enhancing network observability and troubleshooting capabilities. |
| | OAuth 2.0 for First-Party Applications |
| |
|
This document defines the Authorization Challenge Endpoint, which supports clients that want to control the process of obtaining authorization from the user using a native experience. In many cases, this can provide an entirely browserless OAuth 2.0 experience suited for native applications, only delegating to the browser in unexpected, high risk, or error conditions. |
| | OAuth 2.0 Refresh Token and Authorization Expiration |
| |
|
This specification extends OAuth 2.0 [RFC6749] by adding new token endpoint response parameters to specify refresh token expiration and user authorization expiration. |
| | IP Flow Information Export (IPFIX) Alternate-Marking Information Elements |
| |
|
This document specifies the IP Flow Information Export (IPFIX) Information Elements (IEs) to export Alternate Marking measurement data. |
| | Export of GTP-U Information in IP Flow Information Export (IPFIX) |
| |
| | draft-ietf-opsawg-ipfix-gtpu-08.txt |
| | Date: |
27/02/2026 |
| | Authors: |
Dan Voyer, Sriram Gopalakrishnan, Thomas Graf, Vyasraj Satyanarayana, Cristian Staicu |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
This document introduces IP Flow Information Export (IPFIX) Information Elements to report information contained in the Generic Packet Radio Service Tunneling Protocol(GTP) User Plane header such as Tunnel Endpoint Identifier, and data contained in its session container extension header. |
| | Hash-based Signatures: State and Backup Management |
| |
| | draft-ietf-pquip-hbs-state-04.txt |
| | Date: |
27/02/2026 |
| | Authors: |
Thom Wiggers, Kaveh Bashiri, Stefan Kolbl, Jim Goodman, Stavros Kousidis |
| | Working Group: |
Post-Quantum Use In Protocols (pquip) |
|
Stateful Hash-Based Signature Schemes (Stateful HBS) such as Leighton-Micali Signature (LMS), Hierarchical Signature System (HSS), eXtended Merkle Signature Scheme (XMSS), and XMSS^MT combine Merkle trees with One-Time Signatures (OTS) to provide signatures that are resistant against attacks using large-scale quantum computers. Unlike conventional stateless digital signature schemes, Stateful HBS have a state to keep track of which OTS keys have been used, as double-signing with the same OTS key allows forgeries. This document provides guidance and catalogs security considerations for the operational and technical aspects of deploying systems that rely on Stateful HBS. Management of the state of the Stateful HBS, including any handling of redundant key material, is a sensitive topic. This document describes some approaches to handle the associated challenges. It also describes the challenges that need to be resolved before certain approaches should be considered. |
| | RPP Architecture |
| |
|
Advancements in development, integration, deployment environments and operational paradigms have led to a desire for an alternative for the Extensible Provisioning Protocol (EPP). This document defines the architecture for the RESTful Provisioning Protocol (RPP) - an HTTP based provisioning protocol leveraging the REST architectural style and JSON data-interchange format, aiming to standardise a RESTful protocol for provisioning database objects. The architecture includes support for extensibility, allowing for multiple possible use cases. RPP is intended to co-exist with EPP, offering an alternative protocol including data model compatibility with EPP core objects and the benefits associated with the REST architectural style and widely adopted HTTP-based technologies. |
| | Fast failure detection in VRRP with Point to Point BFD |
| |
|
This document describes how Point to Point Bidirectional Forwarding Detection (BFD) can be used to support sub-second detection of a Active Router failure in the Virtual Router Redundancy Protocol (VRRP). |
| | Applicability of Bidirectional Forwarding Detection (BFD) for Multi-point Networks in Virtual Router Redundancy Protocol (VRRP) |
| |
|
This document specifies the applicability of Bidirectional Forwarding Detection in multipoint networks to support sub-second failure detection for Virtual Router Redundancy Protocol Router Role election. The mechanism enables faster determination of the Active Router without requiring any modification to the protocol behavior or message formats defined in RFC 9568. |
| | The Erik Synchronization Protocol for use with the Resource Public Key Infrastructure (RPKI) |
| |
|
This document specifies the Erik Synchronization Protocol for use with the Resource Public Key Infrastructure (RPKI). Erik Synchronization can be characterized as a data replication system using Merkle trees, a content-addressable naming scheme, concurrency control using monotonically increasing sequence numbers, and HTTP transport. Relying Parties can combine information retrieved via Erik Synchronization with other RPKI transport protocols. The protocol's design is intended to be efficient, fast, easy to implement, and robust in the face of partitions or faults in the network. |
| | NAT64 WKP |
| |
|
This document removes the requirement introduced in Section 3.1 of RFC6052 that the NAT64 Well-Known Prefix 64:FF9B::/96 MUST NOT be used to represent non-global IPv4 addresses, such as those defined in [RFC1918] or listed in Section 3 of [RFC5735]. The proposed change enables IPv6-only nodes to reach IPv4-only services with non-global addresses by leveraging the Well-Known Prefix. |
| |
|
| |
| | Transmission of IPv6 Packets over Short-Range Optical Wireless Communications |
| |
| | draft-ietf-6lo-owc-06.txt |
| | Date: |
26/02/2026 |
| | Authors: |
Younghwan Choi, Cheol-min Kim, Carles Gomez |
| | Working Group: |
IPv6 over Networks of Resource-constrained Nodes (6lo) |
|
[IEEE802.15.7], "Short-Range Optical Wireless Communications" defines wireless communication using visible light. It defines how data is transmitted, modulated, and organized in order to enable reliable and efficient communication in various environments. The standard is designed to work alongside other wireless communication systems and supports both Line-of-Sight (LOS) and Non-Line-of-Sight (NLOS) communications. However, ambient light interference from natural sunlight or artificial lighting sources can impact signal reliability. To mitigate this, advanced modulation techniques, optical filtering, and adaptive power control can be employed. This document describes how IPv6 is transmitted over short-range optical wireless communications (OWC) using IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques. |
| | A Voucher Artifact for Bootstrapping Protocols |
| |
| | draft-ietf-anima-rfc8366bis-27.txt |
| | Date: |
26/02/2026 |
| | Authors: |
Kent Watsen, Michael Richardson, Esko Dijk, Toerless Eckert, Qiufang Ma |
| | Working Group: |
Autonomic Networking Integrated Model and Approach (anima) |
|
This document defines a strategy to securely assign a Pledge to an Owner using an artifact signed, directly or indirectly, by the Pledge's manufacturer. This artifact is known as a "Voucher". This document defines an artifact format as a YANG-defined JSON or CBOR document that has been signed using a variety of cryptographic systems. The Voucher Artifact is normally generated by the Pledge's manufacturer (i.e., the Manufacturer Authorized Signing Authority (MASA)). This document updates RFC8366: it includes a number of desired extensions into the YANG module. The Voucher Request YANG module defined in RFC8995 is also updated and now included in this document, as well as other YANG extensions needed for variants of BRSKI/ RFC8995. |
| | RTP payload format for APV |
| |
| | draft-ietf-avtcore-rtp-apv-01.txt |
| | Date: |
26/02/2026 |
| | Authors: |
Youngkwon Lim, Minwoo Park, Madhukar Budagavi, Rajan Joshi, Kwang Choi |
| | Working Group: |
Audio/Video Transport Core Maintenance (avtcore) |
|
This document describes RTP payload format for bitstream encoded with Advanced Professional Video (APV) codec. |
| | Matroska Media Container Tag Specifications |
| |
| | draft-ietf-cellar-tags-23.txt |
| | Date: |
26/02/2026 |
| | Authors: |
Steve Lhomme, Moritz Bunkus, Dave Rice |
| | Working Group: |
Codec Encoding for LossLess Archiving and Realtime transmission (cellar) |
|
Matroska is a multimedia container format. It can store timestamped multimedia data but also chapters and tags. The Tag elements add important metadata to identify and classify the information found in a Matroska Segment. This document defines the Matroska multimedia container tags, namely the tag names and their respective semantic meaning. |
| | DULT Threat Model |
| |
|
Lightweight location-tracking tags are in wide use to allow users to locate items. These tags function as a component of a crowdsourced network in which devices belonging to other network users (e.g., phones) report which tags they see and their location, thus allowing the owner(s) of the tag to determine where their tag was most recently seen. While there are many legitimate uses of these tags, they are also susceptible to misuse for the purpose of stalking and abuse. A protocol that allows others to detect unwanted tracking must incorporate an understanding of the unwanted tracking landscape today. This document provides a threat analysis for this purpose, including a taxonomy of unwanted tracking and potential attacks against Detection of Unwanted Location Tracking (DULT) protocols. The document defines what is in and out of scope for the unwanted tracking protocols, and provides design requirements, constraints, and considerations for implementation of protocols to detect unwanted tracking. |
| | Enhancing Security in EAP-AKA' with Hybrid Post-Quantum Cryptography |
| |
|
Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS) is specified in [RFC9678], providing updates to [RFC9048] with an optional extension that offers ephemeral key exchange using the traditional Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key agreement algorithm for achieving perfect forward secrecy (PFS). However, it is susceptible to future threats from Cryptographically Relevant Quantum Computers, which could potentially compromise a traditional ephemeral public key. If the adversary has also obtained knowledge of the long-term key and ephemeral public key, it could compromise session keys generated as part of the authentication run in EAP-AKA'. This draft aims to enhance the security of EAP-AKA' FS protocol by leveraging PQ/T Hybrid [I-D.ietf-pquip-pqt-hybrid-terminology] algorithms to make it quantum-safe. |
| | Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) in EAP-AKA prime |
| |
|
Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS) is specified in [RFC9678], providing updates to [RFC9048] with an optional extension that offers ephemeral key exchange using the traditional Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key agreement algorithm for achieving perfect forward secrecy (PFS). However, it is susceptible to future threats from Cryptographically Relevant Quantum Computers, which could potentially compromise a traditional ephemeral public key. If the adversary has also obtained knowledge of the long-term key and ephemeral public key, it could compromise session keys generated as part of the authentication run in EAP-AKA'. This draft aims to enhance the security of EAP-AKA' FS protocol by making it quantum-safe using Post-Quantum Key Encapsulation Mechanisms (PQ-KEMs). |
| | Filtering Adj-Rib-In and Adj-Rib-Out to BMP receivers |
| |
|
Filtering RIBs in BMP (BGP Monitoring Protocol) can be desirable for several use-cases like, for example, limiting the amount of data a collector station has to process or allow a sender to export only a certain afi/safi of interest. This document defines a light way to inform a collector station that a Adj-Rib-In / Adj-Rib-Out data feed is being filtered. |
| | The No-Vary-Search HTTP Caching Extension |
| |
|
This specification defines an extension to HTTP Caching, changing how URI query parameters impact caching. |
| | On-Path Telemetry for Active Performance Measurements |
| |
|
This document describes how to employ active test packets in combination with Hybrid Methods to perform On-path Active Performance Measurements. This procedure allows Hop-By-Hop measurements in addition to the Edge-To-Edge measurements. |
| | Post-quantum Key Exchange with ML-KEM in the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
NIST standardized ML-KEM, a new key encapsulation mechanism, which can be used for quantum-resistant key establishment. This draft specifies how to use ML-KEM by itself or as an additional key exchange in IKEv2 along with a traditional key exchange. These options allow for negotiating IKE and Child SA keys which are safe against cryptographically relevant quantum computers. |
| | 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. |
| | YANG Data Model for OSPF SRv6 |
| |
|
This document defines a YANG data model that can be used to configure and manage OSPFv3 Segment Routing over the IPv6 Data Plane. |
| | YANG Data Model for IS-IS SRv6 |
| |
|
This document defines a YANG data model that can be used to configure and manage IS-IS Segment Routing over the IPv6 Data Plane. |
| | IMAP Extension for Object Identifiers |
| |
|
This document updates [RFC3501] (IMAP4rev1) with persistent identifiers on mailboxes and messages to allow clients to more efficiently reuse cached data when resources have changed location on the server. This document obsoletes [RFC8474] by making all object identifier types optional, introducing the OBJECTIDBIS capability with mandatory ENABLE negotiation, and extending the framework to include account- level context through the ACCOUNTID identifier. The ENABLE requirement ensures that servers can implement the extension without altering the IMAP grammar for clients that do not understand the extension. The account identifier extension enables IMAP servers to provide account-level context for mailboxes when multiple accounts are accessible through a single IMAP connection, facilitating interoperability with the JSON Meta Application Protocol (JMAP) in multi-account scenarios. |
| | YANG Metadata Annotation for Immutable Flag |
| |
|
This document defines a way to formally document an existing behavior, implemented by servers in production, on the immutability of some system-provided nodes, using a YANG metadata annotation called "immutable" to flag which nodes are immutable. Clients may use "immutable" annotations provided by the server, to know beforehand why certain otherwise valid configuration requests will cause the server to return an error. The immutable flag is descriptive, documenting an existing behavior, not proscriptive, dictating server behaviors. This document updates RFC 8040 and RFC 8526. |
| | Encapsulating IPsec ESP in UDP for Load-balancing |
| |
| | draft-xu-ipsecme-esp-in-udp-lb-15.txt |
| | Date: |
26/02/2026 |
| | Authors: |
Xiaohu Xu, Shraddha Hegde, Boris Pismenny, Dacheng Zhang, Liang Xia, Mahendra Puttaswamy |
| | Working Group: |
Individual Submissions (none) |
|
IPsec Virtual Private Network (VPN) is widely used by enterprises to interconnect their geographical dispersed branch office locations across the Wide Area Network (WAN) or the Internet, especially in the Software-Defined-WAN (SD-WAN) era. In addition, IPsec is also increasingly used by cloud providers to encrypt IP traffic traversing data center networks and data center interconnect WANs so as to meet the security and compliance requirements, especially in financial cloud and governmental cloud environments. To fully utilize the bandwidth available in the data center network, the data center interconnect WAN or the Internet, load balancing of IPsec traffic over Equal Cost Multi-Path (ECMP) and/or Link Aggregation Group (LAG) is much attractive to those enterprises and cloud providers. This document defines a method to encapsulate IPsec Encapsulating Security Payload (ESP) packets over UDP tunnels for improving load-balancing of IPsec ESP traffic. |
| | A YANG Data Model for Client Signal Performance Monitoring |
| |
|
A transport network is a server-layer network to provide connectivity services to its client. Given the client signal is configured, the followup function for performance monitoring, such as latency and bit error rate, would be needed for network operation. This document describes the data model to support the performance monitoring functionalities. |
| | Data Collection Requirements and Technologies for Network Digital Twin |
| |
|
A Network Digital Twin is a virtual representation of a real network, which is meant to be used by a management system to analyze, diagnose, emulate, and then control the real network based on data, models, and interfaces. The construction and state update of a Network Digital Twin requires obtaining real-time information of the physical network it represents (i.e., telemetry data). This document aims to describe the data collection requirements and provide data collection methods or tools to build the data repository for building and updating a network digital twin. |
| | Multi-Topology in PIM |
| |
| | draft-xz-pim-flex-algo-07.txt |
| | Date: |
26/02/2026 |
| | Authors: |
Zheng Zhang, BenChong Xu, Stig Venaas, Zhaohui Zhang, Hooman Bidgoli |
| | Working Group: |
Individual Submissions (none) |
|
PIM usually uses the shortest path computed by routing protocols to build multicast tree. Multi-Topology Routing is a technology to enable service differentiation within an IP network. IGP Flex Algorithm provides a way to compute constraint-based paths over the network. This document defines the PIM message extensions to provide a way to build multicast tree through the specific topology and constraint-based path instead of the shortest path. |
| | 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. |
| | Enhancing Route Origin Validation by Aggregating Validated ROA Payloads |
| |
|
Resource Public Key Infrastructure (RPKI) enables address space holders to issue Route Origin Authorization (ROA) objects to authorize one or more Autonomous Systems (ASes) to originate BGP routes for specific IP address prefixes. Individual BGP speakers can utilize Validated ROA Payloads (VRPs) to validate the legitimacy of BGP announcements. This document highlights potential validation errors, and recommends extension of VRPs from reasonable aggregation to enhance Route Origin Validation (ROV) and prevent validation errors that may occur due to traffic engineering or route aggregation policies. |
| | Analysis for Multiple Data Plane Solutions of Computing-Aware Traffic Steering |
| |
|
This document proposes a data plane framework for Computing-Aware Traffic Steering (CATS), detailing multiple optional solutions, comparing their key characteristics and distinctions, and analyzing applicable scenarios to provide a reference for implementation. |
| | Flow-Level Load Balancing of Computing-Aware Traffic Steering (CATS) |
| |
| | draft-fu-cats-flow-lb-03.txt |
| | Date: |
26/02/2026 |
| | Authors: |
FUHUAKAI, Daniel Huang, Wei Duan, Bin Tan |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies a flow-level load balancing mechanism for Computing-Aware Traffic Steering (CATS) that reduces control plane overhead and improves resource utilization through data plane autonomous flow distribution. |
| | AI based Network Management Agent(NMA): Concepts and Architecture |
| |
|
The evolution from Level 3 (assisted automation) to Level 4 (autonomous self-optimization) in Autonomous Networks (AN) introduces requirements for Agentic capabilities, including intent-based reasoning, autonomous planning, and context-aware decision-making, which transcend the static, rule-based logic of traditional SDN Controllers. This document defines the concept of the Network Management Agent (NMA), an AI-driven entity designed to embody these cognitive functions and bridge the gap between service intent and network operations. This document also specifies how the NMA utilizes the existing capabilities of SDN Controllers—such as topology management, telemetry, and enforcement—to achieve Autonomous L4 without duplicating policy control functions. It further details the architectural integration modes and defines the interface requirements necessary for SDN Controllers to interoperate with NMAs. |
| | Automation Scenarios and Requirements for Autonomous Networking (AN) Level 4 |
| |
|
This document describes a scenario of OTN-WDM service automation and collaboration in transport networks and defines related functional requirements for domain controller. |
| | IPFIX Protocol over QUIC |
| |
|
The IP Flow Information Export (IPFIX) Protocol provides a means for transmitting Traffic Flow information over the network. IPFIX Data and Template Records can be carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. The supported transport protocols are SCTP, UDP and TCP. QUIC could provide useful, reliable and secure semantics for IPFIX Protocol in particular as a single connection could carry multiple traffic flows over streams, enabling much better efficiency and performance for Exporter and Collector. This document describes how to use IPFIX Protocol over the QUIC transport protocol, named IPFIXoQUIC. |
| | BGP Flowspec Redirects to SR Policy |
| |
|
BGP Flowspec, an extension of BGP, facilitates the distribution of traffic flow specification rules and supports steering traffic into Segment Routing (SR) Policies. However, current approaches that leverage Flowspec to direct traffic toward a SR Policy exhibit certain limitations (for detailed analysis, refer to Section 1). Using the Community Container attribute, this document defines two new standard actions for the BGP Flowspec Version 2 (FSv2) protocol: the Redirect to SR Policy Action and the SRv6 SID Action. The former enables traffic to be directed to a designated SR Policy, while the latter supports encapsulating an additional SRv6 SID as required during redirection. The Redirect to SR Policy Action may be used either independently or in conjunction with the SRv6 SID Action, depending on the specific application scenario. In addition, the SRv6 SID Action can be combined with other actions supported by FSv2, such as the Redirect to IPv6 Action. |
| | Fully Adaptive Routing Ethernet in Scale-Up Networks |
| |
| | draft-xu-rtgwg-fare-in-sun-02.txt |
| | Date: |
26/02/2026 |
| | Authors: |
Xiaohu Xu, Zongying He, Nan Wang, Hua Wang, Jian Guo, Xiang Li, Tianyou Zhou, Yongtao Yang, Yinben Xia, Weifeng Zhang, Peilong Wang, Yan Zhuang, Fajie Yang, Chao Li, Xiaojun Wang |
| | Working Group: |
Individual Submissions (none) |
|
The Mixture of Experts (MoE) has become a dominant paradigm in transformer-based artificial intelligence (AI) large language models (LLMs). It is widely adopted in both distributed training and distributed inference. To enable efficient expert parallelization and even tensor parallelization across dozens or even hundreds of Graphics Processing Units (GPUs) in MoE architectures, an ultra-high- throughput, ultra-low-latency AI scale-up network (SUN) is critical. This document describes how to extend the Weighted Equal-Cost Multi- Path (WECMP) load-balancing mechanism, referred to as Fully Adaptive Routing Ethernet (FARE), which was originally designed for scale-out networks, to scale-up networks. |
| | Requirements of Fast Notification for Traffic Engineering and Load Balancing |
| |
|
This document defines the requirements for Fast Notification for Traffic Engineering and Load Balancing (FaNTEL), a mechanism designed to deliver timely network status updates directly from the network device with a change to the device expected to react to it. FaNTEL supports fast failure and congestion notifications, enabling rapid protection switching and dynamic load balancing. By providing low- latency alerts, it helps networks respond quickly to link failures and congestion events, enhancing service reliability and performance. |
| | Gap Analysis of Fast Notification for Traffic Engineering and Load Balancing |
| |
|
Modern networks require fast, adaptive Traffic Engineering (TE) to support demanding applications like AI training and real-time services. Existing mechanisms for load balancing, protection, and flow control often lack responsiveness and scalability. This document analyzes key gaps in current TE solutions and proposes fast notification as a low-latency, event-driven enhancement. Fast notification enables real-time network awareness and quicker reactions to dynamic conditions, improving overall network efficiency and reliability. |
| | Hybrid Forwarding Mechanism for Computing-Aware Traffic Steering (CATS) |
| |
| | draft-fu-cats-hybrid-fwd-01.txt |
| | Date: |
26/02/2026 |
| | Authors: |
FUHUAKAI, Xinxin Yi, Bo Pang, Dongyu Yuan, Wei Duan, Chuanyang Miao |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies a hybrid forwarding mechanism for Computing- Aware Traffic Steering (CATS). The mechanism integrates the CATS forwarding table with the IP forwarding table to optimize forwarding table capacity utilization. By customizing the forwarding model based on service identifiers, it accommodates both experience- sensitive and non-experience-sensitive services. Additionally, it supports flow-granularity load balancing, enhancing the utilization of computing and networking resources while ensuring differentiated service requirements are satisfied. |
| | Applicability of A2A to the Network Management |
| |
| | draft-yang-nmrg-a2a-nm-02.txt |
| | Date: |
26/02/2026 |
| | Authors: |
Diego Lopez, Nathalie Moreno, Lionel Tailhardat, Qiufang Ma, Qin WU, YUANYUANYANG, Shailesh Prabhu |
| | Working Group: |
Individual Submissions (none) |
|
This document discusses the applicability of A2A protocol to the network management in the multi-domain heterogeneous network environment that utilizes IETF technologies. It explores operational aspect, key components, generic workflow and deployment scenarios. The impact of integrating A2A into the network management system is also discussed. |
| | Design of Christian's Congestion Control Code (C4) |
| |
|
Christian's Congestion Control Code is a new congestion control algorithm designed to support Real-Time applications such as Media over QUIC. It is designed to drive towards low delays, with good support for the "application limited" behavior frequently found when using variable rate encoding, and with fast reaction to congestion to avoid the "priority inversion" happening when congestion control overestimates the available capacity. It pays special attention to the high jitter conditions encountered in Wi-Fi networks. The design emphasizes simplicity and avoids making too many assumption about the "model" of the network. The main control variables are the estimate of the data rate and of the maximum path delay in the absence of queues. |
| | Specification of Christian's Congestion Control Code (C4) |
| |
|
Christian's Congestion Control Code is a new congestion control algorithm designed to support Real-Time applications such as Media over QUIC. It is designed to drive towards low delays, with good support for the "application limited" behavior frequently found when using variable rate encoding, and with fast reaction to congestion to avoid the "priority inversion" happening when congestion control overestimates the available capacity. The design emphasizes simplicity and avoids making too many assumptions about the "model" of the network. |
| | Testing of Christian's Congestion Control Code (C4) |
| |
|
Christian's Congestion Control Code is a new congestion control algorithm designed to support Real-Time applications such as Media over QUIC. It is designed to drive towards low delays, with good support for the "application limited" behavior frequently found when using variable rate encoding, and with fast reaction to congestion to avoid the "priority inversion" happening when congestion control overestimates the available capacity. The design was validated by series of simulations, and also by initial deployments in control networks. We describe here these simulations and tests. |
| | Remote Attestation with Exported Authenticators |
| |
| | draft-fossati-seat-expat-02.txt |
| | Date: |
26/02/2026 |
| | Authors: |
Muhammad Sardar, Thomas Fossati, Tirumaleswar Reddy.K, Yaron Sheffer, Hannes Tschofenig, Ionut Mihalcea |
| | Working Group: |
Individual Submissions (none) |
|
This specification defines a method for two parties in a communication interaction to exchange Evidence and Attestation Results using exported authenticators, as defined in [RFC9261]. Additionally, it introduces the cmw_attestation extension, which allows attestation credentials to be included directly in the Certificate message sent during the Exported Authenticator-based post-handshake authentication. The approach supports both the passport and background check models from the RATS architecture while ensuring that attestation remains bound to the underlying communication channel. |
| | One Signature Certificates |
| |
|
This document defines a profile for certificates that are issued for validation of the digital signature produced by a single signing operation. Each certificate is created at the time of signing and bound to the signed content. The associated signing key is generated, used to produce a single digital signature, and then immediately destroyed. The certificate never expires and is never revoked, which simplifies long-term validation. |
| | 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 other issues. |
| | BGP FLEX |
| |
|
The Border Gateway Protocol (BGP) is a very important protocol in the Internet to exchange routing information between network domains. BGP populates the routing table with valid routes, sometimes the routes populated by BGP are not the best choices specially when a ISP provides IP Transit service to an other ISP, and the two ISP are peering at an Internet Exchange Point. Let us assume that ISP A provides IP Transit to ISP B, and the two are peering at an Internet Exchange Point. The return traffic from Internet to ISP B via ISP A will be routed over the Internet Exchange Point instead of the IP Transit link between the two ISP, because of BGP Local preference which has usually a higher value on Internet Exchange links. This will lead to an issue because the return traffic IP Transit service is now passing over the Internet Exchange link. An other issue faced in Internet Exchange Point, is the sub-optimal routing caused by the advertisment of the most specific routes over Internet by ISP. Let us assume that ISP A wants to advertise most specific routes to Internet for traffic Engineering, the peers of ISP A at the Internet Exchange Point could also receive the most specific routes over Internet . This will mean that traffic from the peers of ISP A towards ISP A will now go through Internet because of most specific routes which is not suppposed to be the case. To solve that ISP A will have to send the same specific routes over the Internet Exchange Point which will increase complexity. This document provides aletrnative solutions that can be used to solve the above problems |
| | Benchmarking Terminology for AI Network Fabrics |
| |
|
This document defines benchmarking terminology for evaluating Ethernet-based network fabrics used in distributed Artificial Intelligence (AI) training and inference workloads. It provides a unified vocabulary consolidating and extending terms from RFC 1242, RFC 8238, and the companion AI fabric methodology documents, establishing precise, vendor-neutral definitions for collective communication primitives, RDMA transport mechanisms (RoCEv2 and Ultra Ethernet Transport), congestion control behaviors, AI-specific Key Performance Indicators (KPIs), and fabric topology concepts. This document is a companion to draft-bmwg-ai-fabric-training- bench-00 and draft-bmwg-ai-fabric-inference-bench-00. Those documents SHOULD NOT be applied without first consulting the terminology defined herein. Where definitions herein overlap with RFC 1242 or RFC 8238, the AI fabric context definition in this document takes precedence. |
| | AERO/OMNI Base Specification Amendments (Volume 1) |
| |
|
The Automatic Extended Route Optimization (AERO) and Overlay Multilink Network (OMNI) Interface functional specifications have reached a level of maturity ready for advancement in the RFC publication process. Updates to the base specifications are documented in this first amendment and any additional future amendments as necessary. |
| | Benchmarking Methodology for AI Training Network Fabrics |
| |
|
This document defines benchmarking terminology, methodologies, and Key Performance Indicators (KPIs) for evaluating Ethernet-based AI training network fabrics. As large-scale distributed AI/ML training clusters grow to tens of thousands of accelerators (GPUs/XPUs), the backend network fabric becomes the critical bottleneck determining job completion time (JCT), training throughput, and accelerator utilization. This document establishes vendor-independent, reproducible test procedures for benchmarking fabric-level performance under realistic AI training workloads, covering RDMA/RoCEv2 transport, the Ultra Ethernet Transport (UET) protocol defined by the UEC Specification 1.0 [UEC-1.0], congestion management (PFC, ECN, DCQCN, CBFC), load balancing strategies (ECMP, DLB, packet spraying), collective communication patterns (AllReduce, AlltoAll, AllGather), and scale/ soak testing. The methodology enables apples-to-apples comparison across different switch ASICs, vendor implementations, NIC transport stacks (RoCEv2 vs. UET), and fabric architectures (2-tier Clos, 3-tier Clos, rail- optimized). |
| | Benchmarking Methodology for AI Inference Serving Network Fabrics |
| |
|
This document defines benchmarking terminology, methodologies, and Key Performance Indicators (KPIs) for evaluating Ethernet-based AI inference serving network fabrics. As Large Language Model (LLM) inference deployments scale to disaggregated prefill/decode architectures spanning hundreds or thousands of accelerators (GPUs/ XPUs), the interconnect fabric becomes the critical bottleneck determining Time to First Token (TTFT), Inter-Token Latency (ITL), and aggregate throughput in tokens per second (TPS). This document establishes vendor-independent, reproducible test procedures for benchmarking fabric-level performance under realistic AI inference workloads. Coverage includes RDMA-based KV cache transfer between disaggregated prefill and decode workers, Mixture-of-Experts (MoE) expert parallelism AllToAll communication, request routing and load balancing for inference serving, congestion management under bursty inference traffic patterns, and scale/soak testing. The methodology enables apples-to-apples comparison across implementations, NIC transport stacks (RoCEv2, UET), and fabric architectures. This document is a companion to [TRAINING-BENCH], which addresses training workloads. |
| | JSON Schema |
| |
|
JSON Schema defines the media type "application/schema+json", a JSON- based format for describing the structure of JSON data. JSON Schema asserts what a JSON document must look like, ways to extract information from it, and how to interact with it. The "application/ schema-instance+json" media type provides additional feature-rich integration with "application/schema+json" beyond what can be offered for "application/json" documents. |
| | Digital Identity Certification for Personal Media (DICPM) |
| |
|
This document specifies the Digital Identity Certification for Personal Media (DICPM), a protocol for cryptographic certification of personal media, binding media integrity to identity and consent while enabling verifiable licensing terms and revocation. |
| | Multi-Path Secret Sharing for QKD Key Relay in IP Networks |
| |
|
Trusted relay is currently the most practical deployment model for Quantum Key Distribution (QKD) networks. However, trusted relay nodes pose inherent security vulnerabilities, as intermediate nodes can access the plaintext random number used to derive the end-to-end QKD key, leading to complete key exposure if any single relay node is compromised. To mitigate this risk, this document proposes a Multi- Path Secret Sharing (MPSS) mechanism for QKD key relay. The core idea is to split the random number into multiple shares using a threshold secret sharing scheme, distribute each share through independent QKD relay paths planned by the Key Management Plane (KMP), and reconstruct the complete random number only at the destination node. This mechanism transforms the security model from "all-or-nothing" to "threshold security". Notably, this mechanism leverages an extended IPv6 Destination Option Header (DOH) to carry key share-related metadata and utilizes Segment Routing over IPv6 (SRv6) to enforce strict path isolation. |
| | QP-based SRv6 Load Balancing Deployment |
| |
|
This document describes the use of Segment Routing over IPv6 (SRv6) path selection based on Queue Pair (QP) in Intelligent Computing Wide Area Network (WAN) for Data Center Interconnection (DCI), optimizing load balancing for predictable workloads. |
| | 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. |
| | Host Extensions for IP Multicasting and "Any Source Multicasting" (ASM) IP service |
| |
|
This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support IP multicast with the IP service interface "Any Source Multicast" (ASM). This specification applies to both versions 4 and 6 of the Internet Protocol. Distribution of this memo is unlimited. This document replaces RFC1112 for everything but its specification of the IGMP version 1 protocol. |
| | 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 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. |
| | Trusted Execution Environment Provisioning (TEEP) Protocol |
| |
| | draft-ietf-teep-protocol-26.txt |
| | Date: |
26/02/2026 |
| | Authors: |
Hannes Tschofenig, Mingliang Pei, David Wheeler, Dave Thaler, Akira Tsukamoto |
| | Working Group: |
Trusted Execution Environment Provisioning (teep) |
|
This document specifies the Trusted Execution Environment Provisioning (TEEP) Protocol, which enables secure lifecycle management of Trusted Components in devices with a Trusted Execution Environment (TEE). The protocol defines message exchanges between a Trusted Application Manager (TAM) and a TEEP Agent to query device state, convey attestation evidence, and install, update, or delete Trusted Components. Messages are encoded in CBOR and secured using COSE. |
| |
|
| |
| | IPv6 Query for Enabled In-situ OAM Capabilities |
| |
|
This document describes the application of the mechanism of discovering In-situ OAM (IOAM) capabilities, described in RFC 9359 "Echo Request/Reply for Enabled In Situ OAM (IOAM) Capabilities", in IPv6 networks. IPv6 Node IOAM Query functionality uses the ICMPv6 Query messages, allowing the IOAM encapsulating node to discover the enabled IOAM capabilities of each IOAM transit and IOAM decapsulating node. |
| | Key Management for Group Object Security for Constrained RESTful Environments (Group OSCORE) Using Authentication and Authorization for Constrained Environments (ACE) |
| |
|
This document defines an application profile of the Authentication and Authorization for Constrained Environments (ACE) framework, to request and provision keying material in group communication scenarios that are based on the Constrained Application Protocol (CoAP) and are secured with Group Object Security for Constrained RESTful Environments (Group OSCORE). This application profile delegates the authentication and authorization of Clients, which join an OSCORE group through a Resource Server acting as Group Manager for that group. This application profile leverages protocol-specific transport profiles of ACE to achieve communication security, server authentication, and proof of possession of a key owned by the Client and bound to an OAuth 2.0 access token. |
| | Architecture Discussion on SRv6 Mobile User plane |
| |
| | draft-ietf-dmm-srv6mob-arch-03.txt |
| | Date: |
25/02/2026 |
| | Authors: |
Teppei Kamata, Jakub Horn, Luay Jalil, Weiqiang Cheng, Miya Kohno |
| | Working Group: |
Distributed Mobility Management (dmm) |
|
This document describes the solution approach and its architectural benefits of transforming mobile session information into routing information, leveraging segment routing capabilities, and operating within the IP routing paradigm. |
| | 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. |
| | API Keys and Privacy |
| |
|
Redirecting HTTP requests to HTTPS, a common pattern for human-facing web resources, can be an anti-pattern for authenticated HTTP API traffic. This document discusses the pitfalls and makes deployment recommendations for authenticated HTTP APIs. It does not specify a protocol. |
| | Alternate Marking Deployment Framework |
| |
|
This document provides a framework for Alternate Marking deployment and includes considerations and guidance for the deployment of the methodology. |
| | Composite ML-KEM for use in Cryptographic Message Syntax (CMS) |
| |
|
Composite ML-KEM defines combinations of ML-KEM with RSA-OAEP, ECDH, X25519, and X448. This document specifies the conventions for using Composite ML-KEM algorithms with the Cryptographic Message Syntax (CMS) using the KEMRecipientInfo structure defined in “Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS)” (RFC 9629). |
| | Notable CBOR Tags |
| |
|
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. In CBOR, one point of extensibility is the definition of CBOR tags. RFC 8949's original edition, RFC 7049, defined a basic set of 16 tags as well as a registry that can be used to contribute additional tag definitions [IANA.cbor-tags]. Since RFC 7049 was published, at the time of writing some 250 definitions of tags and ranges of tags have been added to that registry. The present document provides a roadmap to a large subset of these tag definitions. Where applicable, it points to an IETF standards or standard development document that specifies the tag. Where no such document exists, the intention is to collect specification information from the sources of the registrations. After some more development, the present document is intended to be useful as a reference document for the IANA registrations of the CBOR tags the definitions of which have been collected. |
| | Destination-IP-Community Filter for BGP Flow Specification |
| |
|
BGP Flowspec mechanism (BGP-FS) 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 to support community-level filtering. The match field is the community of the destination IP address that is encoded in the Flowspec NLRI. This function is applied in a single administrative domain. |
| | Considerations for traffic steering to SRv6 |
| |
|
This document primarily describes the traffic steering towards SRv6- BE and SRv6-TE respectively, providing an overview of the main traffic steering methods for these two approaches. Furthermore, it discusses the recommended traffic steering methods for various typical scenarios. |
| | An Analysis of ASPA-based AS_PATH Verification |
| |
|
Autonomous System Provider Authorization (ASPA) is very helpful in detecting and mitigating route leaks (valley-free violations) and a majority of forged-origin hijacks. This document does an analysis on ASPA-based AS_PATH verification to help people understand its strengths and deficiencies, and some potential directions of enhancing ASPA are provided. |
| | SR based Loop-free implementation |
| |
|
Microloops are transient packet loops that occur in the network following a topology change (link down, link up, node fault, or metric change events). Microloops are caused by the non-simultaneous convergence of different nodes in the network. If nodes converge and send traffic to a neighbor node that has not converged yet, traffic may be looped between these two nodes, resulting in packet loss, jitter, and out-of-order packets. This document presents some optional implementation methods aimed at providing loop avoidance in the case of IGP network convergence event in different scenarios. |
| | Advertise SRv6 Locator Information by IPv6 Neighbor Discovery |
| |
|
In an SRv6 network, each SRv6 segment endpoint has at least one SRv6 Locator. Through the SRv6 locator routes, other SRv6 segment nodes can steer traffic to that node. This document describes a method for an SRv6 endpoint (e.g., a host or a customer provider edge (CPE)) to advertise its SRv6 locator to a neighboring SRv6-aware router using extensions to the IPv6 Neighbor Discovery (ND) protocol. This approach eliminates the need to run a full routing protocol stack on simple endpoints, facilitating SRv6 deployment in controlled, trusted domains such as data centers and managed access networks. |
| | Synchronizing BMP Monitoring Options and State |
| |
|
This document proposes methods to facilitate correction of BGP Routing Information Base inconsistencies in a non-disruptive manner from the BMP Sender to the BMP Collector. |
| | Currently Used Terminology Related to Source Address Validation |
| |
|
This document provides an overview of terms and abbreviations related to Source Address Validation (SAV). Its purpose is to establish a common and consistent set of terminology for use across SAV-related discussions and documents. This document explicitly does not serve as an authoritative source of correct terminology. |
| | X.509 Extensions for PQC or Composite Certificate Hosting Continuity |
| |
|
This document specifies a new X.509 certificate extension, Post- Quantum or Composite Hosting Continuity (PQCHC), which enables a certificate subject to signal a intent to continue serving PQC or composite certificates for a defined continuity period after certificate expiration. This extension helps relying parties detect downgrade and man-in-the-middle (MitM) attacks during transition phases, where a cryptographically relevant quantum computer (CRQC) would make traditional certificates insecure. |
| | An Integrated Security Service System for 5G Networks using an I2NSF Framework |
| |
|
This document presents an integrated framework for automated security management in 5G edge networks using the Interface to Network Security Functions (I2NSF) architecture. The proposed system leverages Intent-Based Networking (IBN) to allow users or administrators to declare high-level security intents, which are translated into enforceable network and application policies. Network-level policies are delivered to 5G core components via the Network Exposure Function (NEF), while application-level policies are enforced directly on a User Equipment (UE) through distributed IBN Controllers. This architecture supports adaptive, context-aware, and distributed policy enforcement, enabling real-time response to dynamic edge conditions and user mobility scenarios such as handovers. By integrating closed-loop monitoring and analytics, the system ensures consistent and autonomous security across heterogeneous 5G environments. |
| | CSV++ (CSV Plus Plus): Extension to RFC 4180 for Hierarchical Data |
| |
|
This document specifies CSV++ (CSV Plus Plus), an extension to the Comma-Separated Values (CSV) format defined in RFC 4180. CSV++ adds support for repeating fields (one-to-many relationships) and hierarchicalcomponent structures while maintaining backward compatibility with standard CSV parsers. The extension uses declarative syntax in column headers to define array fields and nested structures, enabling representation of complex real-world data while preserving the simplicity and human-readability of CSV. |
| | The AI Visibility Lifecycle Framework |
| |
|
This document describes the 11-Stage AI Visibility Lifecycle, a stage-based observational framework describing how websites achieve visibility within AI discovery, comprehension, trust, and human exposure systems. The framework identifies three distinct phases -- AI Comprehension (Stages 1-5), Trust Establishment (Stages 6-8), and Human Visibility (Stages 9-11) -- through which domains progress from initial AI crawling to sustainable human-facing visibility. |
| | DNS EDE option for rate-limited queries |
| |
|
This memo documents EDNS Extended DNS Errors INFO-CODE values for rate-limited and over-quota conditions. |
| | Update to Post-quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3 |
| |
|
This is a quick update of to-be RFC [I-D.ietf-tls-ecdhe-mlkem] for recommending the three hybrid key agreement mechanisms in TLS 1.3. |
| | Symmetry-Driven Asynchronous Forwarding with Fast Reroute for LEO Satellite Networks (SDAF) |
| |
| | draft-luan-rtgwg-sdaf-00.txt |
| | Date: |
25/02/2026 |
| | Authors: |
Shenshen Luan, Wenting Wei, Mingliang Ke, Hou Dongxu, Xiao Min |
| | Working Group: |
Individual Submissions (none) |
|
Interior Gateway Protocols (IGPs) such as OSPF are commonly employed in satellite networks to address topology awareness and autonomous routing in response to link interruptions, link/node failures, and subsequent repairs. However, IGP-based approaches suffer from inherent limitations. Synchronization delays between the control plane and the forwarding plane can cause routing black holes, while asynchronous convergence across nodes may induce micro-loops (as described in prior work), leading to packet loss and congestion. These issues are particularly exacerbated in satellite networks characterized by highly dynamic topologies, long inter-satellite propagation delays, and constrained on-board computing resources. This document describes the Symmetry-Driven Asynchronous Forwarding (SDAF) mechanism, which leverages the intrinsic symmetry of toroidal topologies in satellite networks. Low Earth Orbit (LEO) satellite constellations are typically composed of multiple circular orbital planes, forming a toroidal topology by inter-satellite links. SDAF autonomously triggers and processes reverse flows based solely on local link-state information, without requiring control-plane convergence, protocol extensions, or packet header modifications. SDAF is fully compatible with existing protocols and technologies such as OSPFv3, IS-IS, and MPLS, and is specifically tailored to the resource-constrained nature of satellite systems. It achieves microsecond-scale convergence and low packet loss under failure conditions. Simulation results and tests conducted on actual satellite routers demonstrate that the SDAF mechanism significantly suppresses packet loss caused by routing black holes and micro-loops, while also alleviating link congestion and packet reordering issues. |
| | Verifiable Agent Conversation Records |
| |
|
Autonomous agents based on large language models increasingly perform consequential tasks on behalf of humans and other agents. Demonstrating that recorded agent behavior truthfully represents actual behavior is essential for accountability, compliance, and human oversight. This document defines a data format for verifiable agent conversation records using CDDL, with representations in both JSON and CBOR. The format captures session metadata, message exchanges, tool invocations, reasoning traces, and system events in a structured, extensible CDDL definition for verifiable agent conversation records. COSE is used as the signing method to allow for native interoperability in SCITT Transparency Services and the CDDL definition allows for seemless integration in Evidence as specified in RFC 9334. The specification supports cross-vendor interoperability by defining a common representation that accommodates translation from multiple existing agent implementations with distinct data structure layouts that are typically represented in JSON. |
| | Problem Statement for an AI-Session-ID in SIP |
| |
|
This document describes a signaling-layer correlation gap in SIP- based real-time AI voice systems. Existing SIP identifiers provide dialog and communication-session scope, but they do not define a stable application-layer identifier capable of persisting across topology changes, multi-dialog call control operations, federated interconnects, or distributed processing environments. The document analyzes current mechanisms and their limitations, and motivates the need for a standardized SIP-carried identifier whose semantics are restricted to application-layer correlation and out-of- band context retrieval. |
| | Contextual Agent Authorization Mesh (CAAM) |
| |
| | draft-barney-caam-00.txt |
| | Date: |
25/02/2026 |
| | Authors: |
Jonathan Barney, Roberto Pioli, Darron Watson |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the Contextual Agent Authorization Mesh (CAAM), an authorization profile composable with the Agent Registration and Discovery Protocol (ARDP) I-D.pioli-agent-discovery and other discovery mechanisms. CAAM defines the Post-Discovery Authorization Handshake: the runtime authorization layer that governs agent behavior after an agent has been discovered through ARDP but before it is permitted to execute tool calls or delegate authority. CAAM provides a sidecar-based authorization mediator for enforcing Relationship-Based Access Control (ReBAC), purpose-bound delegation, and cryptographically verifiable intent propagation in Human-to-Agent (H2A) and Agent-to-Agent (A2A) flows. It bridges identity provenance frameworks -- the Interoperability Profiling for Secure Identity in the Enterprise (IPSIE) IPSIE and the Secure Production Identity Framework for Everyone (SPIFFE) SPIFFE -- with the ARDP control plane, leveraging OpenID XAA for coarse-grained delegation, a Knowledge Graph for real-time relationship inference, and the Remote ATtestation procedureS (RATS) architecture RFC9334 for cryptographically verifiable attestation of agent execution environments. The Session Context Object (SCO) defined herein is encoded as a JSON Web Token (JWT) RFC7519 or a CBOR Web Token (CWT) RFC8392, and carries a new "ctx" (Contextual Assertion) claim that binds the agent's delegated authority to a specific purpose, session, and trust chain. |
| | Execution Context Tokens for Distributed Agentic Workflows |
| |
|
This document defines Execution Context Tokens (ECTs), a JWT-based extension to the WIMSE architecture that records task execution across distributed agentic workflows. Each ECT is a signed record of a single task, linked to predecessor tasks through a directed acyclic graph (DAG). ECTs reuse the WIMSE signing model and are transported in a new Execution-Context HTTP header field alongside existing WIMSE identity headers. |
| | Native IPv4 multicast in IPv6 Core using PIM |
| |
|
This document describes how PIM Sparse-Mode can be used to construct IPv4 multicast trees across an IPv6-only network core. It specifies the use of IPv6 PIM messages to carry IPv4 group and source addresses, the use of RPF vectors for reachability, and a new Hello Option to signal support for this capability. |
| | Bidirectional Forwarding Detection (BFD) for Routing in Fat Trees (RIFT) |
| |
|
This document specifies the use of Bidirectional Forwarding Detection (BFD) for fast failure detection of Routing in Fat Trees (RIFT) adjacencies. RIFT is specified in RFC 9692. While RFC 9692 describes interactions with BFD, it does not define normative behavior. This document specifies the use of single-hop BFD, as defined in RFC 5881, for RIFT adjacencies, including behavior for parallel links and multiple RIFT instances. |
| | Cryptographically Verifiable Actor Chain for OAuth 2.0 Token Exchange |
| |
|
This document defines an extension to OAuth 2.0 Token Exchange [[RFC8693]] that addresses the problem of *Delegation Auditability Gaps* in multi-hop service environments. Current standards treat prior actors in a delegation chain as "informational only," providing no cryptographic proof of the actual delegation path. This document proposes a new actor_chain claim — a *Cryptographically Verifiable Actor Chain* — that replaces the informational-only nested act claim with a tamper-evident, ordered record of all actors. This solution enables high-assurance data-plane policy enforcement and forensic auditability, particularly for dynamic AI agent-to-agent workloads—where susceptibility to *prompt injection attacks* can lead to unauthorized delegation paths — the security posture of the entire delegation chain is critical for authorization decisions. |
| | BGP-LS-SPF Extensions for SRv6 Policy State Synchronization |
| |
|
This document defines extensions to BGP-LS-SPF (BGP Link State Shortest Path First) to support synchronization of Segment Routing over IPv6 (SRv6) policy state information. It introduces a new optional Sub-TLV for the SRv6 End.X SID TLV that indicates whether an SRv6 SID is currently active in an SR policy. This enables dynamic interaction between SR policies and BGP-LS-SPF route computation, improving network responsiveness to policy changes. |
| | Transitive Attestation for Sovereign Workloads: A WIMSE Profile |
| |
|
This document defines a *WIMSE Profile* for Transitive Attestation within the Workload Identity in Multi-Service Environments (WIMSE) framework. It addresses the critical problem of *Identity Portability*, where software credentials (e.g., bearer tokens or keys) can be misappropriated and used from unauthorized environments—a risk amplified by the emergence of autonomous *AI Agents* that may move across jurisdictions or be hijacked via *prompt injection attacks*. By providing a standardized *Identity Conveyance* mechanism, this profile cryptographically binds software workloads to their local execution environment ("Proof of Residency") through a transitive chain of trust. This chain consumes *Evidence* from the underlying platform—supporting both *high-assurance* RATS-based profiles (e.g., [[!I-D.lkspa-wimse-verifiable-geo-fence]]) for residency verification and *standard* Workload Identity Agents for basic co-location proofs—to ensure that an identity is only valid when used from a verified, integral, or geographically compliant host. The integrity and hardware-rooted security of the Workload Identity Agent itself is considered out-of-scope for this document and is addressed in the *Verifiable Geofencing* profile [[!I-D.lkspa- wimse-verifiable-geo-fence]]. |
| | Group Address Allocation Protocol (GAAP) |
| |
|
This document describes a design for a lightweight decentralized multicast group address allocation protocol (named GAAP and pronounced "gap" as in "mind the gap"). The protocol requires no configuration setup and no centralized services. The protocol runs among group participants which need a unique group address to send and receive multicast packets. Tailored for IPv4 and IPv6 networks, this design offers a simple, lightweight option rather than extending an existing protocol. |
| | Batched Token Issuance Protocol |
| |
|
This document specifies two variants of the Privacy Pass issuance protocol that allow for batched issuance of tokens. These allow clients to request more than one token at a time and for issuers to issue more than one token at a time. |
| | QMux |
| |
|
This document specifies QMux version 1. QMux version 1 provides, over bi-directional streams such as TLS, the same set of stream and datagram operations that applications rely upon in QUIC version 1. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the QUIC Working Group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/quic/. Source for this draft and an issue tracker can be found at https://github.com/quicwg/qmux. |
| | SRv6 Deployment Options |
| |
|
When deciding to migrate a network from existing data-plane technologies (e.g. MPLS, SR-MPLS or overlay encapsulations such as VXLAN) to SRv6, common questions involve how to perform the migration, how to minimize impact to the existing network and what techniques are available to support a smooth transition. This document presents various deployment and migration options for networks evolving toward SRv6 from prior transport or overlay technologies. |
| |
|
| |
| | An Application Layer Interface for Non-Internet-Connected Physical Components (NIPC) |
| |
| | draft-ietf-asdf-nipc-18.txt |
| | Date: |
24/02/2026 |
| | Authors: |
Bart Brinckman, Rohit Mohan, Braeden Sanford |
| | Working Group: |
A Semantic Definition Format for Data and Interactions of Things (asdf) |
|
This document describes an API that allows applications to perform operations against a gateway serving one or more devices described by an SDF model. The API consists of a RESTful application layer interface that performs operations on those devices, as well as a CBOR-based publish-subscribe interface for streaming data. |
| | BGP link bandwidth extended community use cases |
| |
| | draft-ietf-bess-ebgp-dmz-09.txt |
| | Date: |
24/02/2026 |
| | Authors: |
Stephane Litkowski, MOHANTY Satya, Arie Vayner, Akshay Gattani, Ajay Kini, Jeff Tantsura, Reshma Das |
| | Working Group: |
BGP Enabled ServiceS (bess) |
|
BGP link bandwidth extended community provides a way to signal a value along with a BGP path that can be used to perform weighted load-balancing in multipath scenarios. This document details various use cases of the BGP link bandwidth extended community. It also describes local mechanisms to dynamically adjust the BGP link bandwidth value or the multipath weights based on different considerations. |
| | IoT DNS Security and Privacy Guidelines |
| |
|
This document outlines best current practices for Internet of Things (IoT) device providers regarding the implementation of DNS stub resolvers, with the aim of mitigating security threats, enhancing privacy, and resolving operational challenges. It also provides guidelines for network operators on mitigating the risks identified in this draft as DNS resolution includes services outside of the stub-resolver, and for device providers' management zones. |
| | A Connectivity Monitoring Metric for IPPM |
| |
|
Within a Segment Routing domain, segment routed measurement packets can be sent along pre-determined paths. This enables new kinds of active measurements. Connectivity monitoring supervises the state and performance of a connection or a (sub)path from one or a few central monitoring systems. This document specifies a suitable type-P connectivity monitoring metric. |
| | Composite ML-DSA for use in X.509 Public Key Infrastructure |
| |
| | draft-ietf-lamps-pq-composite-sigs-15.txt |
| | Date: |
24/02/2026 |
| | Authors: |
Mike Ounsworth, John Gray, Massimiliano Pala, Jan Klaussner, Scott Fluhrer |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
This document defines combinations of US NIST ML-DSA in hybrid with traditional algorithms RSASSA-PKCS1-v1.5, RSASSA-PSS, ECDSA, Ed25519, and Ed448. These combinations are tailored to meet regulatory guidelines. Composite ML-DSA is applicable in applications that uses X.509 or PKIX data structures that accept ML-DSA, but where the operator wants extra protection against breaks or catastrophic bugs in ML-DSA, and where EUF-CMA-level security is acceptable. |
| | MPLS Network Action (MNA) Sub-Stack Specification including In-Stack Network Actions and Data |
| |
| | draft-ietf-mpls-mna-hdr-21.txt |
| | Date: |
24/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. |
| | Post-Stack MPLS Network Action (MNA) Solution |
| |
| | draft-ietf-mpls-mna-ps-hdr-07.txt |
| | Date: |
24/02/2026 |
| | Authors: |
Jaganbabu Rajamanickam, Rakesh Gandhi, Royi Zigler, Jie Dong, Jisu Bhattacharya |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
|
This document defines the Post-Stack MPLS Network Action (MNA) solution for carrying Network Actions encodings and Ancillary Data after the MPLS label stack, based on the In-Stack MNA solution defined in "MPLS Network Action (MNA) Sub-Stack Solution." MPLS Network Actions can be used to influence packet forwarding decisions, carry additional Operations, Administration, and Maintenance information in the MPLS packet, or perform user-defined operations. This solution document addresses the Post-Stack network action and Post-Stack data-specific requirements found in RFC 9613. This document follows the framework specified in RFC 9789. |
| | Internationalization for the NFSv4 Protocols |
| |
|
This document describes the handling of internationalization for all NFSv4 protocols, including NFSv4.0, NFSv4.1, NFSv4.2 and extensions thereof, and future minor versions. It updates RFC7530 and RFC8881. |
| | The "dereferenceable identifier" pattern |
| |
|
In a protocol or an application environment, it is often important to be able to create unambiguous identifiers for some meaning (concept or some entity). Due to the simplicity of creating URIs, these have become popular for this purpose. Beyond the purpose of identifiers to be uniquely associated with a meaning, some of these URIs are in principle _dereferenceable_, so something can be placed that can be retrieved when encountering such a URI. |
| | The Restatement Anti-Pattern |
| |
|
Normative documents that cite other normative documents often _restate_ normative content extracted out of the cited document in their own words. The present memo explains why this can be an Antipattern, and how it can be mitigated. |
| | Global Token Revocation |
| |
|
Global Token Revocation enables parties such as a security incident management tool or an external Identity Provider to send a request to an Authorization Server to indicate that it should revoke all of a user's existing tokens and require that the user re-authenticates before issuing new tokens. |
| | Filtering Out RPKI Data by Type based on Enhanced SLURM Filters |
| |
|
Simplified Local Internet Number Resource Management with the RPKI (SLURM) helps operators create a local view of the global RPKI by generating sets of filters and assertions. This document proposes to filter out RPKI data by type based on enhanced SLURM filters. Only the RPKI data types that the network or routers are interested in will appear in the Relying Party's output. |
| | ICMP extension to include underlay information |
| |
|
Network operators managing overlay networks require visibility into underlay network hops during traceroute operations from overlay endpoints. This document defines an ICMP extension object, the Underlay Information Object (UIO), which allows underlay head-end nodes to encapsulate underlay error information within ICMP error messages. This mechanism provides overlay operators with crucial visibility into underlay network paths for troubleshooting. |
| | A Generic Framework for Building Dynamic Decentralized Systems (GFDS) |
| |
| | draft-jesus-gfds-02.txt |
| | Date: |
24/02/2026 |
| | Authors: |
Diogo Jesus, Joao Leitao |
| | Working Group: |
Individual Submissions (none) |
|
Building and managing highly dynamic and heterogeneous decentralized systems can prove to be quite challenging due to the great complexity and scale of such environments. This document specifies a Generic Framework for Building Dynamic Decentralized Systems (GFDS), which composes a reference architecture and execution model for developing and managing these systems, while providing high-level abstractions to users. |
| | Applicability of MCP for the Network Management |
| |
| | draft-yang-nmrg-mcp-nm-02.txt |
| | Date: |
24/02/2026 |
| | Authors: |
YUANYUANYANG, Qin WU, Diego Lopez, Nathalie Moreno, Lionel Tailhardat |
| | Working Group: |
Individual Submissions (none) |
|
The application of MCP in the network management field is meant to refactor network management operation and network capabilities as tools and provide more agile and extensible architecture to expose these AI integration capabilities. This document discusses the applicability of MCP to the network management plane in the IP network that utilizes IETF technologies. It explores MCP for network exposure, multiple MCP server discovery, communication between Network Elements or between the Network element and the Network Controller/Network Gateway. |
| | Updates to DNS64 Functionality Advertisement for DNS RA Option |
| |
|
This document defines a new flag in the DNS RA Option to advertise the DNS64 functionality. This extension enables automatic configuration of DNS64 resolution, improving deployability in IPv6 transition scenarios. |
| | An Overview of Messaging Systems and Their Applicability to Agentic AI |
| |
|
Agentic AI systems require messaging infrastructure that supports real-time collaboration, high-volume streaming, and dynamic group coordination across distributed networks. Traditional protocols like AMQP, MQTT, and NATS address some requirements but fall short on security, particularly regarding [AMQP] [MQTT] [NATS] post-compromise protection and quantum-safe encryption essential for autonomous agents handling sensitive data. This document analyzes six messaging protocols—AMQP, MQTT, NATS, AMQP over WebSockets, Kafka, and AGNTCY SLIM—across dimensions critical for GenAI agent systems: streaming performance, delivery guarantees, security models, and operational complexity. We examine how each protocol's design decisions impact agentic AI deployments, from lightweight edge computing scenarios to large-scale multi- organizational collaborations. AGNTCY SLIM emerges as a purpose-built solution, integrating Message Layer Security (MLS) [RFC9420] with gRPC [gRPC] over HTTP/2 [RFC7540] to provide quantum-safe end-to-end encryption, efficient streaming, and OAuth-based authentication [RFC6749]. Unlike transport-layer security approaches, SLIM's MLS implementation ensures secure communication even through untrusted intermediaries while supporting dynamic group membership changes essential for collaborative AI agents. |
| | Secure Low-Latency Interactive Messaging (SLIM) |
| |
| | draft-mpsb-agntcy-slim-01.txt |
| | Date: |
24/02/2026 |
| | Authors: |
Luca Muscariello, Michele Papalini, Mauro Sardara, Sam Betts |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the Secure Low-Latency Interactive Real-Time Messaging (SLIM), a protocol designed to support real-time interactive AI applications at scale. SLIM provides the transport layer for agent protocols (for example, A2A and MCP), combining gRPC over HTTP/2 and HTTP/3 with secure messaging, group communication, and native RPC semantics. The protocol provides mechanisms for connection management, stream multiplexing, and flow control while maintaining compatibility with existing gRPC deployments and supporting end-to-end encryption via MLS. |
| | Agent Directory Service |
| |
|
The Agent Directory Service (ADS) is a distributed directory service designed to store metadata for AI agent applications. This metadata, stored as directory records, enables the discovery of agent applications with specific skills for solving various problems. The implementation features distributed directories that interconnect through a content-routing protocol. |
| | Model for distributed authorization policy sharing |
| |
|
This document defines mechanisms and conventions for the representation, lifecycle management, and distribution of authorization policies in distributed and automated environments. It specifies a consistent, machine-readable, and interoperable framework that enables policies to be validated, versioned, exchanged, and removed across heterogeneous systems and domains. The framework defines how authorization policies, expressed in declarative Policy-as-Code (PaC) languages, are encapsulated, managed, and distributed using YANG as the canonical representation format. This separation allows independent evolution of policy languages, enforcement architectures, and trust models. |
| | 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. |
| | TCP In-Band Single Packet Authentication (TCP-SPA) |
| |
|
This document describes a mechanism called TCP In-Band Single Packet Authentication (TCP-SPA). A client that wishes to open a TCP connection to a protected server embeds a compact Message Authentication Code (MAC) inside the TCP SYN packet itself, carried as an experimental TCP option (kind 253, per [RFC6994]), with an ExID (Experiment Identifier) value of TBD to be assigned by IANA. The server verifies the MAC at the earliest possible point in the network stack — before a socket is allocated or the TCP handshake proceeds — and drops the SYN if verification fails. This approach differs from existing Single Packet Authentication (SPA) systems in that no out-of-band authentication packet is required: authentication and connection establishment are a single atomic step. |
| | Update to OAuth 2.0 Protected Resource Metadata Resource Identifier Validation |
| |
|
RFC 9728 defines OAuth 2.0 Protected Resource Metadata, enabling clients to dynamically discover the authorization requirements of protected resources. Section 3.3 of RFC 9728 requires that when protected resource metadata is obtained via a WWW-Authenticate challenge, the resource value in the metadata MUST exactly match the URL the client used to access the protected resource, limiting the applicability of the specification. This document updates the resource validation rule in Section 3.3 of RFC 9728 to permit the resource value to be any URI that shares the same TLS origin (scheme, host, and port) as the requested URL and whose path is a prefix of the request URL path. This enables a wider range of use cases for the WWW-Authenticate response. All other aspects of RFC 9728 remain unchanged. |
| | Export of Segment Routing Policy Attributes in IP Flow Information Export (IPFIX) |
| |
|
This document defines new IP Flow Information Export (IPFIX) Information Elements (IEs) to export attributes of Segment Routing (SR) and Segment Routing over IPv6 (SRv6) policies applied to IP flows, which enables correlation between observed traffic flows and the SR/SRv6 policies that carry them. |
| | ICMP Error Handling for VPNs in SRv6 Networks |
| |
|
This document specifies ICMP error handling in SRv6-based Virtual Private Networks. |
| | ICMP Query for IP Node Information |
| |
|
This document introduces two new ICMP messages. They are called the ICMP Query Request and the ICMP Query Response. The ICMP Query Request requests information. The ICMP Query Response provides information in response to an ICMP Query Request. This document updates RFC 4884. |
| | Applying COSE Signatures for YANG Data Provenance |
| |
| | draft-ietf-opsawg-yang-provenance-04.txt |
| | Date: |
24/02/2026 |
| | Authors: |
Diego Lopez, Antonio Pastor, Alex Feng, Ana Perez, Henk Birkholz |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
This document defines a mechanism based on COSE signatures to provide and verify the provenance of YANG data, so it is possible to verify the origin and integrity of a dataset, even when those data are going to be processed and/or applied in workflows where a crypto-enabled data transport directly from the original data source is not available. As the application of evidence-based OAM automation and the use of tools such as AI/ML grow, provenance validation becomes more relevant in all scenarios, in support of the assuring the origin and integrity of data. The use of compact signatures facilitates the inclusion of provenance strings in any YANG schema requiring them. |
| | PCEP Extensions to support BFD parameters |
| |
|
This document proposes extension to PCEP to configure LSP parameters. Some of LSP parameters are needed to configure S-BFD for candidate paths. Each candidate path is identified in PCEP by its uniquely assigned PLSP-ID. The mechanism proposed in this document is applicable to to all path setup types. This extension can work with ifferent PCEP Path Setup Types but especially suitable for Segment Routing (SR-MPLS, SRv6).. |
| | Yang Data Model for EVPN multicast |
| |
|
This document describes a YANG data model for EVPN multicast services. The model is agnostic of the underlay as well as RFC 9251. This document mainly focuses on EVPN instance framework. |
| | A Multiplane Architecture Proposal for the Quantum Internet |
| |
|
A consistent reference architecture model for the Quantum Internet is required to progress in its evolution, providing a framework for the integration of the protocols applicable to it, and enabling the advance of the applications based on it. This model has to satisfy three essential requirements: agility, so it is able to adapt to the evolution of quantum communications base technologies, sustainability, with open availability in technological and economical terms, and pliability, being able to integrate with the operations and management procedures in current networks. This document proposes such an architecture framework, with the goal of providing a conceptual common framework for the integration of technologies intended to build the Quantum Internet infrastructure and its integration with the current Internet. The framework is based on the already extensive experience in the deployment of QKD network infrastructures and on related initiatives focused on the integration of network infrastructures and services. |
| | Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) for Packet Optical Integration (POI) service assurance |
| |
| | draft-ietf-teas-actn-poi-assurance-04.txt |
| | Date: |
24/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. |
| | Post-Quantum Cryptography Recommendations for TLS-based Applications |
| |
|
Post-quantum cryptography presents new challenges for device manufacturers, application developers, and service providers. This document highlights the unique characteristics of applications and offers best practices for implementing quantum ready usage profiles in applications that use TLS and key supporting protocols such as DNS. |
| |
|
| |
| | Admin Interface for the OSCORE Group Manager |
| |
| | draft-ietf-ace-oscore-gm-admin-15.txt |
| | Date: |
23/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. |
| | EVPN multi-homing support for L3 services |
| |
|
This document describes the use of EVPN Ethernet Segment Link Aggregation Group (ES-LAG) technology to provide multi-homing redundancy for Layer 3 services. The solution synchronizes ARP/ND, multicast state, and IGP routes between redundant PEs without requiring Layer 2 constructs or proprietary Inter-Chassis Communication protocols. |
| | Supporting BIER in IPv6 Networks (BIERin6) |
| |
| | draft-ietf-bier-bierin6-13.txt |
| | Date: |
23/02/2026 |
| | Authors: |
Zheng Zhang, Zhaohui Zhang, IJsbrand Wijnands, Mankamana Mishra, Hooman Bidgoli, Gyan Mishra |
| | Working Group: |
Bit Indexed Explicit Replication (bier) |
|
BIER is a multicast forwarding architecture that does not require per-flow state inside the network yet still provides optimal replication. This document describes how the existing BIER encapsulation specified in RFC 8296 works in a non-MPLS IPv6 network, which is referred to as BIERin6. Specifically, like in an IPv4 network, BIER can work over L2 links directly or over tunnels. In case of IPv6 tunneling, a new IP "Next Header" type is to be assigned for BIER. |
| | BGP Route Reflector with Next Hop Self |
| |
|
The procedures in BGP Route Reflection (RR) spec RFC4456 primarily deal with scenarios where the RR is reflecting BGP routes with next hop unchanged. In some deployments like Inter-AS Option C (Section 10, RFC4364), the ABRs may perform RR functionality with nexthop set to self. If adequate precautions are not taken, the RFC4456 procedures can result in traffic forwarding loop in such deployments. This document illustrates one such looping scenario, and specifies approaches to minimize possiblity of traffic forwarding loop in such deployments. An example with Inter-AS Option C (Section 10, RFC4364) deployment is used, where RR with next hop self is used at redundant ABRs when they re-advertise BGP transport family routes between multiple IGP domains. |
| | Integrity Protection of In Situ Operations,Administration,and Maintenance (IOAM) Data Fields |
| |
|
In Situ Operations, Administration, and Maintenance (IOAM) records operational (including telemetry) information in packets while they traverse a path in the network. RFC 9197 specifies data fields for IOAM (a.k.a IOAM-Data-Fields) and associated data types. This document specifies integrity protection of IOAM-Data-Fields for Intra-IOAM-Domain use cases. |
| | Multicast YANG Data Model |
| |
|
This document provides a generic multicast YANG data model that shows the relevant technologies or protocols used by multicast flows. It provides a management view for network administrators to obtain information about multicast services. |
| | SIMAP: Concept,Requirements,and Use Cases |
| |
|
This document defines the concept of Service & Infrastructure Maps (SIMAP) and identifies a set of SIMAP requirements and use cases. The SIMAP was previously known as Digital Map. The document intends to be used as a reference for the assessment of the various topology modules to meet SIMAP requirements. |
| | Proxy MAC-IP Advertisement in EVPNs |
| |
|
This document specifies procedures for EVPN PEs connected to a common multihomed site to generate proxy EVPN MAC-IP advertisements on behalf of other PEs to facilitate preservation of ARP/ND state across link or node failures. |
| | Data Fields for DetNet Enhanced Data Plane |
| |
|
The DetNet-specific metadata should be carried in enhanced data plane based on the enhancement requirements. This document proposes the common DetNet data fields and options including Deterministic Latency Option and Aggregation Option. It also considers the common DetNet options being encapsulated into a variety of protocols such as MPLS, IPv6 and SRv6 networks. |
| | Enhanced Use Cases for Scaling Deterministic Networks |
| |
|
This document describes use cases and network requirements for scaling deterministic networks which is not covered in RFC8578, such as industrial internet, high experience video, intelligent computing, and ISAC-enabled smart factory and outlines the common properties implied by these use cases. |
| | Computing Aware Traffic Steering Consideration for Mobile User Plane Architecture |
| |
|
The document [I-D.draft-ietf-dmm-mup-architecture] describes the Mobile User Plane (MUP) architecture for Distributed Mobility Management. The proposed architecture converts the user mobility session information from the control plane entity to an IPv6 dataplane routing information. When there are multiple candidate instances located at different location to serve an user request, the MUP Provider Edge (PE) might prioritize the closest service location. However, the closest routing path might not be the optimal route. This document discusses how the mentioned MUP architecture can be leveraged to set up dataplane routing paths to the optimal service instance location with the assistance of computing-aware traffic steering capabilities. For each session request, based on the up-to- date collected computing and network information, the MUP controller can convert the session information to the optimal route. |
| | Advertising Router Information |
| |
| | draft-zzhang-rtgwg-router-info-06.txt |
| | Date: |
23/02/2026 |
| | Authors: |
Zhaohui Zhang, Kevin Wang, Changwang Lin, Niranjan Vaidya, Jeff Tantsura, Yisong Liu |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies a generic mechanism for a router to advertise some information to its neighbors. One use case of this mechanism is to advertise link/path information so that a receiving router can better react to network changes. |
| | BGP Route Type Capability |
| |
|
BGP supports different route types, which define the encoding of Network Layer Reachability Information (NLRI) for some of the Address Family Identifier (AFI)/Subsequent Address Family Identifier (SAFI), like Ethernet VPN (EVPN), Multicast VPN(MVPN) and so on. BGP speaker MAY reset the BGP session if a given route type in an NLRI is not supported instead of treat-as-withdraw. This document defines Optional Capabilities pertaining to the exchange of route types that are supported for a particular AFI and SAFI. This framework facilitates the maintenance of sessions without necessitating resets or the inadvertent dropping of updates. |
| | Additional CATS requirements consideration for Service Segmentation-related use cases |
| |
|
This document discusses possible additional CATS requirements when considering service segmentation in related CATS use cases such as AR-VR and Distributed AI Inference |
| | BGP Signaled MPLS Namespaces |
| |
|
The MPLS forwarding layer in a core network is a shared resource. The MPLS FIB at nodes in this layer contains labels that are dynamically allocated and locally significant at that node. These labels are scoped in context of the global loopback address. Let us call this the global MPLS namespace. For some usecases like upstream label allocation, it is useful to create private MPLS namespaces (virtual MPLS FIB) over this shared MPLS forwarding layer. This allows installing deterministic label values in the private FIBs created at nodes participating in the private MPLS namespace, while preserving the "locally significant" nature of the underlying shared global MPLS FIB. This document defines new address families (AFI: 16399, SAFI: 128, or 1) and associated signaling mechanisms to create and use MPLS forwarding contexts in a network. Some example use cases are also described. |
| | Network Digital Twin and Agentic AI based Architecture for AI driven Network Operations |
| |
|
A Network Digital Twin (NDT) provides a network emulation tool usable for different purposes such as scenario planning, impact analysis, and change management. Integrating a Network Digital Twin into network management together with Agentic AI, it allows the network management activities to take user intent or service requirements as input, automatically assess, model, and refine optimization strategies under realistic conditions but in a risk-free environment. Such environment that operates to meet these types of requirements is said to have AI driven Network Operations. AI driven Network Operations brings together existing technologies such as Agentic AI and Network Digital Twin which may be seen as the use of a toolbox of existing components enhanced with a few new elements. This document describes an architecture for AI driven network operations and shows how these components work together with network digital twin and Agentic AI capabilities. It provides a cookbook of existing technologies to satisfy the architecture and realize intent- based network management to meet the needs of the network service. |
| | Registration Data Access Protocol (RDAP) Extension for Verified Contact Information |
| |
|
This document describes an extension to the Registration Data Access Protocol (RDAP) that allows the inclusion of verification status information for contact fields such as email addresses and phone numbers. The goal is to improve data quality and trustworthiness of RDAP responses by indicating which pieces of contact data have been verified and how. |
| | The Rewind Subscription Filter |
| |
|
This document proposes a Media Over Quic Transport (MOQT) extension that enables a new Subscription Filter, so that a subscriber can request that a finite number of past groups be delivered with SUBSCRIBE semantics (multiple streams, potentially incomplete) rather than FETCH semantics (single stream, complete, head-of-line- blocking). Service of this request is best-effort by the publisher, and it intended to accelerate joining a track in some use cases. |
| | Entity Attestation Token (EAT) Profile for Autonomous AI Agents |
| |
| | draft-messous-eat-ai-01.txt |
| | Date: |
23/02/2026 |
| | Authors: |
Ayoub MESSOUS, Lionel Morand, Peter Liu |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a profile for the Entity Attestation Token (EAT) to support remote attestation of autonomous AI agents across domains. It specifies a set of standardized claims for attesting the integrity of AI model parameters, the provenance of training data, and the constraints of inference-time data access policies. Optional extensions for 5G/6G network functions—such as slice-type authorization—are included for interoperability with ETSI ENI and 3GPP architectures. The profile is encoded in CBOR Web Tokens (CWTs) or JSON Web Tokens (JWTs) and is designed to be used within the IETF RATS architecture. |
| | Updated recommendations for TLS keyshares |
| |
|
This document updates the recommendations for key shares algorithms (TLS supported groups; previously EC Named Curve Registry) in the light of the future arrival of cryptographically relevant quantum computers. [[ NOTE I use key share in the title and here as it's more accurate than "group" and perhaps more well known in the context TLS than key agreement or key exchange. ]] |
| | YANG deVELpment PrOCEss and maintenance (VELOCE) |
| |
|
This document describes a YANG deVELpment PrOCEss and maintenance (VELOCE) that is more suitable for the development of YANG modules or YANG modules update within the IETF. 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/mjethanandani/veloce. |
| | Applying Attachmet Circuit and PE2PE YANG Data Model to dynamic policies Use Case |
| |
|
This document explores how existing IETF YANG data models can be applied to support a use case involving dynamic, time-scoped UCMP (Unequal Cost Multipath) policy enforcement across multiple network segments interconnecting Edge Cloud sites. The use case is motivated by periodic, high-volume data exchanges between distributed AI inference modules placed at geographically dispersed edge data centers. By mapping network requirements such as bandwidth, latency, and availability to relevant YANG models, including AC, TE Topology, SR Policy, and QoS models, this document serves as a practical exercise to evaluate the applicability and limitations of current IETF specifications. It highlights the need for cloud-initiated, time-bounded network policy activation and identifies potential gaps in model expressiveness, policy lifecycle handling, and API-level abstraction required for real-time cloud-network coordination. |
| | Applying Attachmet Circuit and Traffic Engineering YANG Data Model to Edge AI Use Case |
| |
|
This document explores how existing IETF YANG data models, specifically the Attachment Circuit (AC)-as-a-Service (ACaaS) and Traffic Engineering (TE) topology data models, can be applied to support a use case involving dynamic AI model placement at Edge Cloud sites. The use case involves selecting optimal Edge locations for real-time AI inference based on end-to-end network performance between street-level cameras and Edge Cloud compute nodes. By mapping the use case across multiple network segments and applying relevant YANG data models to retrieve and request specific services objectives such as bandwidth, latency, and reliability, this document serves as a practical exercise to evaluate model applicability and identify gaps, if any. |
| | The Preliminary Request Denied HTTP Status Code |
| |
|
This specification defines a HTTP status code to indicate that the server is denying a prefetch or preload request. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-nottingham-httpbis-pre- denied/. information can be found at https://mnot.github.io/I-D/. Source for this draft and an issue tracker can be found at https://github.com/mnot/I-D/labels/pre-denied. |
| | Well-Known Uniform Resource Identifiers (URIs) |
| |
|
This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 8615. |
| | WTX-1: Cross-Domain Context Preservation Protocol |
| |
|
This document defines the WTX-1 (WaiTag Transfer Protocol, version 1) for preserving pseudonymous user context across unrelated web domains without third-party cookies, browser fingerprinting, login requirements, or personal data collection. The protocol uses cryptographically generated pseudonymous identifiers (WaiTags), URL hash fragment transport, server-side verification, and DNS-based domain authorization to enable privacy-respecting cross-domain analytics. |
| | Stop Doing Cryptographic Algorithm Drafts when Email to IANA is All You Need |
| |
|
People keep pitching drafts to the TLS Working Group where the only thing the draft does is register a code point for a cryptographic algorithm. Stop doing that. It's unnecessary. Write an email to IANA instead. |
| | PCEP extensions for SR P2MP Policy |
| |
| | draft-ietf-pce-sr-p2mp-policy-14.txt |
| | Date: |
23/02/2026 |
| | Authors: |
Hooman Bidgoli, Dan Voyer, Anuj Budhiraja, Rishabh Parekh, Siva Sivabalan |
| | Working Group: |
Path Computation Element (pce) |
|
Segment Routing (SR) Point-to-Multipoint (P2MP) Policies are a set of policies that enable architecture for P2MP service delivery. This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate P2MP paths from a Root to a set of Leaf nodes. |
| | 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. |
| | SRv6 for Redundancy Protection |
| |
|
Redundancy Protection is a generalized protection mechanism to achieve high reliability of service transmission in Segment Routing networks. The mechanism uses the "Live-Live" methodology. This document introduces one new SRv6 Segment Endpoint Behavior to provide replication and elimination functions on specific network nodes by leveraging SRv6 Network Programming capabilities. |
| | Circuit Style Segment Routing Policy |
| |
| | draft-ietf-spring-cs-sr-policy-16.txt |
| | Date: |
23/02/2026 |
| | Authors: |
Christian Schmutzer, Zafar Ali, Praveen Maheshwari, Reza Rokui, Andrew Stone |
| | Working Group: |
Source Packet Routing in Networking (spring) |
|
This document describes how Segment Routing (SR) policies can be used to satisfy the requirements for bandwidth, end-to-end recovery and persistent paths within a SR network. The association of two co- routed unidirectional SR Policies satisfying these requirements is called "Circuit Style" SR Policy (CS-SR Policy). |
| | Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers |
| |
|
This document describes stateful NAT64 translation, which allows IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, or ICMP. One or more public IPv4 addresses assigned to a NAT64 translator are shared among several IPv6-only clients. When stateful NAT64 is used in conjunction with DNS64, no changes are usually required in the IPv6 client or the IPv4 server. |
| | IP/ICMP Translation Algorithm |
| |
|
This document describes the Stateless IP/ICMP Translation Algorithm (SIIT), which translates between IPv4 and IPv6 packet headers (including ICMP headers). This document obsoletes RFC 6145. |
| |
|
| |
| | Transmission of SCHC-compressed packets over IEEE 802.15.4 networks |
| |
|
A framework called Static Context Header Compression and fragmentation (SCHC) has been designed with the primary goal of supporting IPv6 over Low Power Wide Area Network (LPWAN) technologies [RFC8724]. One of the SCHC components is a header compression mechanism. If used properly, SCHC header compression allows a greater compression ratio than that achievable with traditional 6LoWPAN header compression [RFC6282]. For this reason, it may make sense to use SCHC header compression in some 6LoWPAN environments, including IEEE 802.15.4 networks. This document specifies how a SCHC-compressed packet can be carried over IEEE 802.15.4 networks. The document also enables the transmission of SCHC-compressed UDP/ CoAP headers over 6LoWPAN-compressed IPv6 packets. |
| | BGP UPDATE for SD-WAN Edge Discovery |
| |
|
The document describes the BGP mechanisms for SD-WAN (Software Defined Wide Area Network) edge node attribute discovery. These mechanisms include a new tunnel type and sub-TLVs for the BGP Tunnel- Encapsulation Attribute (RFC9012) and set of NLRI (network layer reachability information) for SD-WAN underlay information. In the context of this document, BGP Route Reflector (RR) is the component of the SD-WAN Controller that receives the BGP UPDATE from SD-WAN edges and in turn propagates the information to the intended peers that are authorized to communicate via the SD-WAN overlay network. |
| | Performance Measurement with Asymmetrical Traffic Using Simple Two-Way Active Measurement Protocol (STAMP) |
| |
|
This document defines an optional STAMP extension that allows a Session-Reflector to send packets whose length or quantity differs from those sent by the Session-Sender. While standard STAMP exchanges packets symmetrically, some measurement scenarios benefit from asymmetric response packets to better reflect real application conditions. This extension enables the Session-Reflector to send packets of different sizes and/or additional packets not tied one- for-one to incoming test packets. The document also analyzes challenges in multicast performance monitoring and specifies STAMP procedures to improve measurement efficiency and reduce network impact. |
| | NETCONF and RESTCONF Private Candidate Datastores |
| |
|
This document provides a mechanism to extend the Network Configuration Protocol (NETCONF) and RESTCONF protocol to support multiple clients making configuration changes simultaneously and ensuring that they commit only those changes that they defined. This document addresses two specific aspects: The interaction with a private candidate over the NETCONF and RESTCONF protocols and the methods to identify and resolve conflicts between clients. |
| | Augmented-by Addition to the YANG Library |
| |
|
"YANG Library" specifies the YANG module "ietf-yang-library" that provides information about the YANG modules, datastores, and datastore schemas used by a network management server. This document augments the "ietf-yang-library" to provide the augmented-by list. It facilitates the process of obtaining all dependencies between YANG modules, by querying the network management server's YANG library. This document updates RFC 8525, as the lists in Section 2 is modified to also include augmented-by list. |
| | PCEP Extensions for Performance Measurements for SR-TE and MPLS-TE LSPs with Stateful PCE |
| |
| | draft-gandhi-pce-pm-11.txt |
| | Date: |
20/02/2026 |
| | Authors: |
Rakesh Gandhi, Bin Wen, Colby Barth, Dhruv Dhody |
| | Working Group: |
Individual Submissions (none) |
|
In certain networks, network performance data such as packet loss, delay, and delay variation, as well as bandwidth utilization, are critical measures for Traffic Engineering (TE). These data provide operators with the characteristics of their networks for the performance evaluation required to ensure the Service-Level Agreements (SLAs). 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. The Stateful PCE extensions allow stateful control of Traffic Engineering LSPs for Segment Routing (SR) and RSVP using PCEP. This document describes PCEP extensions for enabling and reporting end-to-end performance measurements and liveness detection for both PCE-Initiated and PCC-Initiated LSPs for SR-TE over MPLS and IPv6 data planes and MPLS-TE to an Active Stateful PCE. |
| | Larger Data in TLS 1.3 Handshake |
| |
|
This memo discusses possible modifications of TLS 1.3, aimed to allow trasferring data larger than 64 Kbytes in handshake messages. One possible application for this feature is to allow using post-quantum Key Encapsulation Method that have large public key or ciphertext size (like Classic McEliece). |
| | Early IANA Registry Creation |
| |
|
This memo describes the requirements for establishing an IANA registry before the IETF Stream document that creates the registry is approved for publication as an RFC. This process can be used when an IETF working group needs to coordinate allocations among multiple documents or with an organization outside the IETF. |
| | Securing QUIC with MLS |
| |
| | draft-tian-quic-quicmls-01.txt |
| | Date: |
20/02/2026 |
| | Authors: |
Benjamin Dowling, Britta Hale, Konrad Kohbrok, Raphael Robert, Xisen Tian, Bhagya Wimalasiri |
| | Working Group: |
Individual Submissions (none) |
|
This document describes how Messaging Layer Security (MLS) can be used in place of Transport Layer Security (TLS) to secure QUIC. |
| | 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. |
| | Internet X.509 Public Key Infrastructure - Algorithm Identifiers for FrodoKEM |
| |
|
FrodoKEM is an unstructured lattice-based Key Encapsulation Mechanism (KEM). Compared to ML-KEM, FrodoKEM is considered as having more conservative design. This document specifies the conventions for using FrodoKEM in X.509 Public Key Infrastructure. The conventions for the subject public keys and private keys are also specified. |
| | Certificate Expectation Assertions (CEA) |
| |
| | draft-joseph-cea-00.txt |
| | Date: |
20/02/2026 |
| | Authors: |
Vineeth Joseph, Ethan Hamadeh, Chen Zhang |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies Certificate Expectation Assertions (CEA), a DNS-based mechanism enabling domain owners to publish expected certificate authority identities for their domains. Clients can compare observed TLS certificates against these published expectations to identify potential unauthorized interception. CEA uses DNSSEC-signed DNS TXT records, supports multiple certificate authorities, and employs fail-open transparency rather than blocking connections. This approach differs from HPKP's fail-secure model and provides an optional mechanism for interception detection. This document is published as Informational to document the CEA protocol for experimental deployment. It does not modify TLS or PKI infrastructure and is not an IETF standard. This is an experimental specification that has not been endorsed by any IETF Working Group and does not represent IETF consensus. Note: This document does not modify the TLS protocol (RFC 8446), certificate validation procedures (RFC 5280), or PKI infrastructure. CEA is an optional client-side transparency overlay that provides additional information to users. Implementations that do not support CEA continue to function normally with no changes to TLS behavior. |
| | JMAP Blob Extensions |
| |
|
The JMAP base protocol (RFC8620) provides the ability to upload and download arbitrary binary data. This binary data is called a "blob", and can be used in all other JMAP extensions. The JMAP blob extension (RFC9404) added additional ways to create and access blobs by making inline method calls within a standard JMAP request. This extension adds more methods to work with blobs, including handling large blobs by processing them in chunks (building on RFC9404's blob construction support), and providing ways to efficiently describe small changes. |
| | Support for Path MTU (PMTU) in the Path Computation Element (PCE) Communication Protocol (PCEP) |
| |
| | draft-ietf-pce-pcep-pmtu-09.txt |
| | Date: |
20/02/2026 |
| | Authors: |
Shuping Peng, Cheng Li, Liuyan Han, Luc-Fabrice Ndifor, Samuel Sidor |
| | Working Group: |
Path Computation Element (pce) |
|
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing (SR) can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). Since the SR does not require signaling, the path maximum transmission unit (MTU) information for the SR path is unavailable at the headend. This document specifies the extension to PCE Communication Protocol (PCEP) to carry path MTU as a new metric type in the PCEP messages for SR, but not limited to it. This document also updates RFC 5440 to allow metric bounds to be minimum as needed in the case of path MTU. |
| | Managing multiple paths for a QUIC connection |
| |
| | draft-ietf-quic-multipath-20.txt |
| | Date: |
20/02/2026 |
| | Authors: |
Yanmei Liu, Yunfei Ma, Quentin De Coninck, Olivier Bonaventure, Christian Huitema, Mirja Kuehlewind |
| | Working Group: |
QUIC (quic) |
|
This document specifies a multipath extension for the QUIC protocol to enable the simultaneous usage of multiple paths for a single connection. It introduces explicit path identifiers to create, delete, and manage multiple paths. This document does not specify address discovery or management, nor how applications using QUIC schedule traffic over multiple paths. |
| | Entity Attestation Token (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. |
| | Secure Asset Transfer (SAT) Interoperability Architecture |
| |
| | draft-ietf-satp-architecture-09.txt |
| | Date: |
20/02/2026 |
| | Authors: |
Thomas Hardjono, Martin Hargreaves, Ned Smith, Venkatraman Ramakrishna |
| | Working Group: |
Secure Asset Transfer Protocol (satp) |
|
This document proposes an interoperability architecture for the secure transfer of assets between two networks or systems based on the gateway model. |
| | COSE Receipts with CCF |
| |
|
This document defines a new verifiable data structure type for COSE Signed Merkle Tree Proofs specifically designed for transaction ledgers produced via Trusted Execution Environments (TEEs), such as the Confidential Consortium Framework ([CCF]) to provide stronger tamper-evidence guarantees. |
| | Configuring UDP Sockets for ECN for Common Platforms |
| |
|
Explicit Congestion Notification (ECN) applies to all transport protocols in principle. However, it had limited deployment for UDP until QUIC became widely adopted. As a result, documentation of UDP socket APIs for ECN on various platforms is sparse. This document records the results of experimenting with these APIs in order to get ECN working on UDP for Chromium on Apple, Linux, and Windows platforms. |
| | TLS/DTLS 1.3 Profiles for the Internet of Things |
| |
|
RFC 7925 offers guidance to developers on using TLS/DTLS 1.2 for Internet of Things (IoT) devices with resource constraints. This document is a companion to RFC 7925, defining TLS/DTLS 1.3 profiles for IoT devices. Additionally, it updates RFC 7925 with respect to the X.509 certificate profile and ciphersuite requirements. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/thomas-fossati/draft-tls13-iot. |
| |
|
| |
| | Semantic Definition Format (SDF): Supplements |
| |
| | draft-ietf-asdf-sdf-mapping-01.txt |
| | Date: |
18/02/2026 |
| | Authors: |
Carsten Bormann, Jan Romann |
| | Working Group: |
A Semantic Definition Format for Data and Interactions of Things (asdf) |
|
The Semantic Definition Format (SDF) is a format for domain experts to use in the creation and maintenance of data and interaction models that describe Things, i.e., physical objects that are available for interaction over a network. It was created as a common language for use in the development of the One Data Model liaison organization (OneDM) models. Tools convert this format to database formats and other serializations as needed. An SDF specification often needs to be augmented by additional information that is specific to its use in a particular ecosystem or application. SDF Supplements provide a mechanism to represent this augmentation. |
| | Instance Information for SDF |
| |
|
This document specifies instance-related messages to be used in conjunction with the Semantic Definition Format (SDF) for Data and Interactions of Things (RFC 9880). Split into four "archetypes", instance-related messages are always governed by SDF models, strictly separating instance and class information. _Context_ information plays a crucial role both for lifecycle management and actual device interaction. // This revision updates the base SDF reference to the recently // published RFC 9880, improves the terminology section, and applies // a bug fix to an example. |
| | Near Real Time Mirroring (NRTM) version 4 |
| |
| | draft-ietf-grow-nrtm-v4-08.txt |
| | Date: |
18/02/2026 |
| | Authors: |
Sasha Romijn, Job Snijders, Edward Shryane, Stavros Konstantaras |
| | Working Group: |
Global Routing Operations (grow) |
|
This document specifies a one-way synchronization HTTP-based protocol for Internet Routing Registry (IRR) records, called Near Real Time Mirroring version 4 (NRTMv4). The protocol allows instances of IRR database servers to mirror IRR records, specified in the Routing Policy Specification Language (RPSL), between each other. |
| | Link-Local Next Hop Capability for BGP |
| |
|
To support IPv6 [RFC4291] reachability, BGP [RFC4271] relies on the Multiprotocol Extensions as defined in [RFC4760]. [RFC2545] defines the structure of IPv6 next hops. These IPv6 next hops may contain a Global IPv6 address, and optionally can contain an IPv6 Link-Local address when the BGP peer is directly attached and shares a common subnet with the IPv6 Global address. This document updates [RFC2545] to clarify the encoding of the BGP next hop when the advertising system is directly attached and only an IPv6 Link-Local address is available. A new BGP Capability [RFC5492] is defined to signal support for this updated encoding. This clarification applies specifically to IPv6 Link-Local addresses and does not pertain to IPv4 Link-Local addresses as defined in [RFC3927]. |
| | Key Transparency Architecture |
| |
|
This document defines the terminology and interaction patterns involved in the deployment of Key Transparency in a general secure group messaging infrastructure, and specifies the security properties that the protocol provides. It also gives more general, non- prescriptive guidance on how to securely apply Key Transparency to a number of common applications. |
| | Media Access Control (MAC) Addresses in X.509 Certificates |
| |
| | draft-ietf-lamps-macaddress-on-06.txt |
| | Date: |
18/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). |
| | LISP Geo-Coordinates |
| |
|
This document describes how Geo-Coordinates can be used in the Locator/ID Separation Protocol (LISP). The functionality proposes a new LISP Canonical Address Format (LCAF) encoding for such Geo- Coordinate. This document updates RFC8060. |
| | YANG Data Model for OSPF Application-Specific Link Attributes and Flexible Algorithm |
| |
|
This document defines a YANG data model to support OSPF Application- Specific Link Attributes and Flexible Algorithm. It also specifies the initial version of IANA-maintained YANG modules for IGP Algorithm Types and IGP Metric-Type. |
| | YANG Data Model for IS-IS Application-Specific Link Attributes and Flexible Algorithm |
| |
|
This document defines a YANG data model to support IS-IS Application- Specific Link Attributes and Flexible Algorithm. |
| | YANG module file name convention |
| |
|
This document presents YANG module file name convention. The convention extends the current YANG module file name using revision-date, with the YANG semantic version extension. The YANG semantic version extension allows for an informative version to be associated with a particular YANG module revision. This documents updates RFCs 6020, 7950, and draft-ietf-netmod- rfc8407bis. |
| | Proof of Process (PoP): Architecture and Evidence Format |
| |
|
This document specifies the Proof of Process (PoP) Evidence Framework, a specialized profile of Remote Attestation Procedures (RATS) designed to validate the provenance of effort in digital authorship. Unlike traditional provenance, which tracks file custody, PoP attests to the continuous physical process of creation. The protocol defines a cryptographic mechanism for generating Evidence Packets utilizing a composite Sequential Work Function (SWF) based on Proof of Biological Space-Time (PoBST) to enforce temporal monotonicity and Cross-Domain Constraint Entanglement (CDCE) to bind behavioral entropy (human jitter) and physical state to the document. Technical specifications for wire formats, sequential work functions, and hardware-anchored trust are provided. |
| | Proof of Process (PoP): Forensic Appraisal and Security Model |
| |
|
This document specifies the forensic appraisal methodology and quantitative security model for the Proof of Process (PoP) framework. It defines how Verifiers evaluate behavioral entropy, perform liveness detection, and calculate forgery cost bounds. Additionally, it establishes the taxonomy for Absence Proofs and the Writers Authenticity Report (WAR) format, as well as the Tool Receipt protocol for artificial intelligence (AI) attribution within the linear human authoring process. |
| | Agent Definition Language (ADL) |
| |
|
The Agent Definition Language (ADL) provides a standard JSON-based format for describing AI agents. An ADL document declares an agent's identity, capabilities, tools, permissions, security requirements, data classification, and runtime configuration in a single, machine- readable artifact. ADL enables discovery, interoperability, deployment, and lifecycle management of AI agents across diverse platforms and runtimes. This document defines the structure of ADL documents, the semantics of their members, conformance requirements for implementations, and the registration of the application/adl+json media type. |
| | The otpauth URI Scheme |
| |
|
This document defines syntax and processing rules for the otpauth: URI scheme used to provision one-time-password (OTP) credentials (verification codes). This document defines a common baseline for interoperability, including issuer handling rules that improve account matching while maintaining compatibility with existing deployments. 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/andesco/otpauth-uri. |
| | Token Status List (TSL) |
| |
|
This specification defines a status mechanism called Token Status List (TSL), data structures and processing rules for representing the status of tokens secured by JSON Object Signing and Encryption (JOSE) or CBOR Object Signing and Encryption (COSE), such as JWT, SD-JWT, CBOR Web Token, and ISO mdoc. It also defines an extension point and a registry for future status mechanisms. |
| | Chunked Oblivious HTTP Messages |
| |
|
This document defines a variant of the Oblivious HTTP message format that allows chunks of requests and responses to be encrypted and decrypted before the entire request or response is processed. This allows incremental processing of Oblivious HTTP messages, which is particularly useful for handling large messages or systems that process messages slowly. |
| | A Prio Instantiation for Vector Sums with an L1 Norm Bound on Contributions |
| |
|
A Prio Verifiable Distributed Aggregation Function is defined that supports vector or histogram addition, where the sum of the values in the contribution is less than a chosen value. |
| | RDAP Extensions |
| |
|
This document describes and clarifies the usage of extensions in RDAP. |
| | Updates to SFrame Cipher Suites Registry |
| |
|
This document addresses two omissions in the Secure Frames (SFrame) protocol specification. First, the definition of the IANA registry for SFrame ciphersuites omits several important fields. This document requests that IANA add those fields and defines the contents of those fields for current entries. Second, the AEAD construction based on AES-CTR and HMAC is defined only for the 128-bit security level. This document registers parallel constructions at the 256-bit security level. |
| | Common YANG Data Types for Traffic Engineering |
| |
| | draft-ietf-teas-rfc8776-update-22.txt |
| | Date: |
18/02/2026 |
| | Authors: |
Italo Busi, Aihua Guo, Xufeng Liu, Tarek Saad, Igor Bryskin |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
This document defines a collection of common data types, identities, and groupings in YANG data modeling language. These derived common data types, identities and groupings are intended to be imported by other modules, e.g., those which model the Traffic Engineering (TE) configuration and state capabilities. This document obsoletes RFC 8776. |
| |
|
| |
| | 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. |
| | Increase of the Congestion Window when the Sender Is Rate-Limited |
| |
|
This document specifies how transport protocols increase their congestion window when the sender is rate-limited, and updates RFC 5681, RFC 9002, RFC 9260, and RFC 9438. Such a limitation can be caused by the sending application not supplying data or by receiver flow control. |
| | DNS Security Extensions (DNSSEC) |
| |
|
This document describes the DNS Security Extensions (commonly called "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. A second purpose is to state that using DNSSEC for origin authentication of DNS data is the best current practice. A third purpose is to provide a single reference for other documents that want to refer to DNSSEC. This document obsoletes RFC 9364. This document is being tracked at (https://github.com/paulehoffman/ rfc9364bis). |
| | Bundle Transfer Protocol - Unidirectional |
| |
|
This document defines a protocol for the unidirectional transfer of large binary objects, typically Bundle Protocol version 7 bundles, between two nodes connected by a unidirectional, unreliable, frame- based link-layer protocol, without requiring IP services. The protocol does not require a return path for acknowledgements, but instead supports data repetition as a mechanism to protect against data loss. It fully supports the disaggregation of flows of binary objects of different priority, preventing head-of-line blocking impacting performance. The wire format of the protocol is designed to enable performant implementation in hardware or software, with the aim of enabling protocol implementations to run at the line-rate of the underlying link-layer protocol. |
| | Forward Error Correction for the Bundle Transfer Protocol |
| |
|
This document defines an optional extension to the Bundle Transfer Protocol - Unidirectional, as described in [BTPU], to enable forward error correction (FEC) coding to be applied selectively to the transfer of individual bundles on a case by case basis. The definition and use of FEC follows the FECFRAME framework defined in [RFC6363], and this document introduces new Message types to BTPU in order to carry the FEC information as defined in the framework. |
| | Communicating Proxy Configurations in Provisioning Domains |
| |
|
This document defines a mechanism for accessing provisioning domain information associated with a proxy, such as other proxy URIs that support different protocols and information about which destinations are accessible using a proxy. 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/tfpauly/privacy-proxy. |
| | JMAP File Storage extension |
| |
|
The JMAP base protocol (RFC8620) provides the ability to upload and download arbitrary binary data. This binary data is called a "blob", and can be used in all other JMAP extensions. This extension adds a method to expose blobs as a filesystem along with the types of metadata that are provided by other remote filesystem protocols. |
| | LISP Canonical Address Format (LCAF) |
| |
| | draft-ietf-lisp-rfc8060bis-04.txt |
| | Date: |
17/02/2026 |
| | Authors: |
Alvaro Retana, Dino Farinacci, Job Snijders, Alberto Rodriguez-Natal |
| | Working Group: |
Locator/ID Separation Protocol (lisp) |
|
This document defines a canonical address format encoding used in Locator/ID Separation Protocol (LISP) control messages and in the encoding of lookup keys for the LISP Mapping Database System. This document obsoletes RFC 8060 and RFC 9306. |
| | Differentiated Services Field Codepoints Internet Key Exchange version 2 Notification |
| |
| | draft-mglt-ipsecme-dscp-np-05.txt |
| | Date: |
17/02/2026 |
| | Authors: |
Daniel Migault, Joel Halpern, Stere Preda, Daiying Liu, U. Parkholm |
| | Working Group: |
Individual Submissions (none) |
|
This document outlines the DSCP Notification Payload, which, during a CREATE_CHILD_SA Exchange, explicitly indicates the DSCP code points that will be encapsulated in the newly established tunnel. This document updates RFC 4301. |
| | Areion: Highly-Efficient Permutations and Its Applications |
| |
| | draft-sakemi-areion-01.txt |
| | Date: |
17/02/2026 |
| | Authors: |
Yumi Sakemi, Satoru Kanno, Takanori Isobe |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies a series of cryptographic wide-block permutations referred to as Areion-256 and Areion-512. These permutations are constructed using AES round operations and are designed for ultra-low latency implementations on modern processors with AES instructions. The Areion permutations can be used as building blocks in various cryptographic constructions, including authenticated encryption and hashing of relatively short input data. Additionally, it describes AEAD schemes and hash functions constructed from Areion. |
| | Composite Token Claims |
| |
|
Composition claims are claims for CBOR Web Tokens (CWTs) and JSON Web Tokens (JWTs) that define logical relationships between sets of claims. |
| | Distributed Aggregation Protocol (DAP) Extensions for the Attribution API |
| |
|
This defines extensions to the DAP protocol that support the Attribution API. These extensions provide support for differentially-private aggregation and the operating modes that the Attribution API depends on. |
| | OAuth 2.0 direct interaction for native clients using federation |
| |
|
OAuth 2.0 for First-Party Applications (FiPA) [I-D.ietf-oauth-first-party-apps] defined a native OAuth 2.0 *direct interaction*, whereby clients call authorization server's _Native Authorization Endpoint_ as an HTTP REST API, whose response instructs client what information to collect from end-user to satisfy authorization server's policies and requirements. While FiPA [I-D.ietf-oauth-first-party-apps] focused on a one-to-one relationship between client and authorization server, this document is an *extension profile* adding support for authorization servers to federate the interaction to a downstream authorization server, instruct collection of additional information from users to guide request routing or instruct the usage of another native app for user interaction. |
| | BPv7 Echo Service |
| |
|
This document specifies an echo service for Bundle Protocol Version 7 (BPv7) networks. The echo service receives bundles at a well-known endpoint and reflects them back to the originator, making only the minimal changes necessary to route the response. This enables round- trip time measurement and end-to-end connectivity verification in Delay-Tolerant Networks. This document requests IANA allocation of a well-known IPN service number and DTN demux for the echo service. |
| | Mutual TLS for Email Authentication |
| |
|
Valid client and server TLS certificates authenticate the traffic coming from the SMTP sending and receiving servers. Domain owners can delegate email sending and receiving to servers using Mail eXchange (MX) DNS resource records. This enables transitive authentication of mail traffic from sending and receiving domains of envelope sender much like Sender Policy Framework and the envelope recipient. This document also proposes an Automatic Certificate Management Environment responder using these DNS records to automate TLS certificate issuance. |
| | Open Cloud Mesh |
| |
|
Open Cloud Mesh (OCM) is a server federation protocol that is used to notify a Receiving Party that they have been granted access to some Resource. It has similarities with authorization flows such as OAuth, as well as with social internet protocols such as ActivityPub and email. A core use case of OCM is when a user (e.g., Alice on System A) wishes to share a resource (e.g., a file) with another user (e.g., Bob on System B) without transferring the resource itself or requiring Bob to log in to System A. While this scenario is illustrative, OCM is designed to support a broader range of interactions, including but not limited to file transfers. Open Cloud Mesh handles interactions only up to the point where the Receiving Party is informed of their access to the Resource. Actual Resource access is subsequently managed by other protocols, such as WebDAV. |
| | Zeroconf Multicast Address Allocation Problem Statement and Requirements |
| |
|
This document surveys current problems with existing protocols for automatically assigning multicast IP addresses in zero-configuration ("zeroconf") networking environments. It addresses key challenges, such as link-layer address collisions, hardware limitations, multicast snooping inefficiencies, and the need to avoid manual configuration. Based on these challenges, it derives requirements for a lightweight, decentralized solution for dynamically allocating unique multicast group addresses without central coordination. The document presents explicit requirements covering discovery, allocation, conflict detection and resolution, and lease management. It also evaluates considerations specific to IPv6 and IPv4 multicast address ranges, and identifies approaches that are unsuited for zeroconf deployment. This foundation serves as a reference for developing future solutions for multicast address allocation that operate autonomously within local networks. |
| | Explicit RDAP Redirects |
| |
|
This document describes an RDAP extension that allows RDAP clients to request to be redirected to a related RDAP record for a resource. |
| | Secure Reporting of SUIT Update Status |
| |
| | draft-ietf-suit-report-19.txt |
| | Date: |
17/02/2026 |
| | Authors: |
Brendan Moran, Henk Birkholz |
| | Working Group: |
Software Updates for Internet of Things (suit) |
|
The Software Update for the Internet of Things (SUIT) manifest provides a way for many different update and boot workflows to be described by a common format. This document specifies a lightweight feedback mechanism that allows a developer in possession of a manifest to reconstruct the decisions made and actions performed by a manifest processor. |
| |
|
| |
| | Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events |
| |
|
In scenarios where network configuration information becomes invalid without explicit notification to the local network, local hosts may end up employing stale information for an unacceptably long period of time, thus resulting in interoperability problems. This document improves the reaction of IPv6 Stateless Address Autoconfiguration to such configuration changes. It formally updates RFC4191, RFC4861, RFC4862, RFC8106, and RFC9096. |
| | Matroska Media Container Codec Specifications |
| |
| | draft-ietf-cellar-codec-17.txt |
| | Date: |
15/02/2026 |
| | Authors: |
Steve Lhomme, Moritz Bunkus, Dave Rice |
| | Working Group: |
Codec Encoding for LossLess Archiving and Realtime transmission (cellar) |
|
This document defines the Matroska multimedia container codec mappings, including the codec ID, layout of data in a Block element and in an optional CodecPrivate element. |
| | Dynamic Capability for BGP-4 |
| |
|
This document defines a new BGP capability termed "Dynamic Capability", which would allow the dynamic update of capabilities over an established BGP session. This capability would facilitate non-disruptive capability changes by BGP speakers. |
| | ESP Header Compression with Diet-ESP |
| |
| | draft-ietf-ipsecme-diet-esp-10.txt |
| | Date: |
15/02/2026 |
| | Authors: |
Daniel Migault, Maryam Hatami, Sandra Cespedes, J. Atwood, Daiying Liu, Tobias Guggemos, Carsten Bormann, David Schinazi |
| | Working Group: |
IP Security Maintenance and Extensions (ipsecme) |
|
This document specifies Diet-ESP, a compression mechanism for control information in IPsec/ESP communications. The compression uses Static Context Header Compression rules. |
| | Internet Key Exchange version 2 (IKEv2) extension for Header Compression Profile (HCP) |
| |
| | draft-ietf-ipsecme-ikev2-diet-esp-extension-07.txt |
| | Date: |
15/02/2026 |
| | Authors: |
Daniel Migault, Maryam Hatami, Daiying Liu, Stere Preda, J. Atwood, Sandra Cespedes, Tobias Guggemos, David Schinazi |
| | Working Group: |
IP Security Maintenance and Extensions (ipsecme) |
|
This document describes an IKEv2 extension for Header Compression to agree on Attributes for Rule Derivation. This extension defines the necessary registries for the ESP Header Compression Profile (EHCP) Diet-ESP. |
| | LISP Traffic Engineering |
| |
| | draft-ietf-lisp-te-25.txt |
| | Date: |
15/02/2026 |
| | Authors: |
Dino Farinacci, Michael Kowal, Parantap Lahiri, Padma Pillay-Esnault |
| | Working Group: |
Locator/ID Separation Protocol (lisp) |
|
This document describes how Locator/Identifier Separation Protocol (LISP) re-encapsulating tunnels can be used for Traffic Engineering purposes. The mechanisms described in this document require no LISP protocol changes and specify how existing Routing Locator encodings are used to construct Explicit Locator Paths for traffic engineering purposes. The Traffic Engineering features provided by these LISP mechanisms can span intra-domain, inter-domain, or a combination of both. |
| | YANG Schema Comparison |
| |
|
This document specifies an algorithm for comparing two revisions of a YANG schema to determine the scope of changes, and a list of changes, between the revisions. The output of the algorithm can be used to help select an appropriate revision-label or YANG semantic version number for a new revision. Included is also a YANG module describing the output of this algorithm. |
| | Carrying Traffic Shaping Mechanism in IPv6 Extension Header |
| |
|
Starting from the traffic shaping mechanism, one of the core technologies of network deterministic assurance, we summarize the characteristics of different traffic scheduling and shaping methods and propose a solution design for IPv6 to carry these traffic scheduling and shaping methods, taking into account deterministic and security factors. At the same time, the network scope of practical applications is becoming larger and larger, and the demand for deterministic network services will no longer be restricted to LANs, but will require deterministic forwarding beyond LAN boundaries, extending the deterministic assurance capability previously provided in LANs to WANs through network layer technologies. |
| | Post-Quantum and Hybrid KEMs for HPKE with JOSE and COSE |
| |
|
This document specifies the use of Post-Quantum (PQC) and Post- Quantum/Traditional (PQ/T) Hybrid Key Encapsulation Mechanisms (KEMs) within the Hybrid Public Key Encryption (HPKE) for JOSE and COSE. It defines algorithm identifiers and key formats to support pure post- quantum algorithms (ML-KEM) and their PQ/T hybrid combinations. |
| | A YANG Data Model of Performance Management Streaming |
| |
|
This document provides a YANG data model of performance management streaming from network equipment to clients. It defines PM measurement methods, event notifications, generic PM parameters and streaming subscriptions. Additionally, it includes a YANG module for PM interval capabilities discovery, enabling clients to understand supported sampling and measurement intervals before configuring PM measurements. |
| | BGP SR Policy Extensions for Performance-Aware Path Selection |
| |
|
To enable the headend node to do performance-aware path selection, this document proposes an extension to the BGP SR Policy protocol by defining a new optional Metric Sub-TLV within the BGP Tunnel Encapsulation Attribute. The introduced Metric Sub-TLV encodes performance parameters (such as latency, bandwidth, reliability, etc.) for SR Policy paths. This specification also updates the BGP route selection procedures in RFC4271, modifying the Breaking Ties (Phase 2) logic to prioritize the metrics for SR Policy paths. Key contributions include: * Introduce Metric Sub-TLV in BGP SR Policy * Update the tie-breaking procedure for BGP route selection |
| | BGP SR Policy Extensions for BFD Configuration |
| |
|
Segment Routing (SR) Policies require fast failure detection for Candidate Paths (CPs) to enable rapid rerouting and high availability. Currently, the provisioning of SR Policies and the configuration of associated Bidirectional Forwarding Detection (BFD) or Seamless BFD (S-BFD) sessions are performed independently. This often necessitates separate mechanisms (e.g., manual configuration, NETCONF, or additional signaling) to associate BFD/S-BFD sessions with the SR Policies, resulting in complex and error-prone operations This document defines extensions to BGP SR Policy for the simultaneous provisioning of SR Policy CPs and their BFD/S-BFD configuration parameters during policy advertisement. The extensions include optional sub-TLVs within the Tunnel Encapsulation Attribute to carry BFD/S-BFD configuration parameters (e.g., discriminators, intervals, multipliers). These extensions simplify deployment in distributed or controller- based environments, reduce configuration overhead, and enhance operational efficiency for SR-based traffic engineering. |
| | SOCKS Protocol Version 4A |
| |
|
This document specifies SOCKS 4A, an extension to the SOCKS Version 4 protocol. This extension allows SOCKS clients to delegate domain name resolution to the SOCKS server. This is particularly useful in environments where the client host cannot resolve the destination host's domain name due to restrictive network policies or lack of DNS access. 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/4socks/socks4. |
| | BGP Extensions for Network Resource Partition |
| |
|
Existing approaches bind a Segment Routing (SR) Policy to a Network Resource Partition (NRP) on a one-to-one basis, which lacks flexibility and introduces significant operational overhead as the number of NRPs scales, especially when the NRPs share the same SR Policy path. This document defines BGP extensions to advertise NRP identifier (NRP ID) information between network nodes, which decouples SR Policy from NRP, allowing multiple NRPs to share a common SR Policy path and thus avoiding linear growth of SR Policies. This design reduces operational complexity and is also applicable to SR Best Effort (SR BE) scenario. |
| | The "Payment" HTTP Authentication Scheme |
| |
| | draft-ryan-httpauth-payment-00.txt |
| | Date: |
15/02/2026 |
| | Authors: |
Brendan Ryan, Jake Moxey, Tom Meagher, Jeff Weinstein, Steve Kaliski |
| | Working Group: |
Individual Submissions (none) |
|
This document defines the "Payment" HTTP authentication scheme, enabling HTTP resources to require a payment challenge to be fulfilled before access. The scheme uses the HTTP 402 "Payment Required" status code with the WWW-Authenticate and Authorization headers to negotiate payment between clients and servers. The protocol is payment-method agnostic; specific payment methods are defined in separate specifications. |
| | NTS4PTP - Network Time Security for the Precision Time Protocol |
| |
|
This document specifies an automatic key management service for the integrated security mechanism (prong A) of IEEE Std 1588™-2019 (PTPv2.1) described there in Annex P. This key management follows the immediate security processing approach of prong A and extends the NTS Key Establishment protocol defined in IETF RFC 8915 for securing NTPv4. The resulting NTS for PTP (NTS4PTP) protocol provides a security solution for all PTP modes and operates completely independent of NTPv4. |
| | BGP Prefix Independent Convergence |
| |
| | draft-ietf-rtgwg-bgp-pic-23.txt |
| | Date: |
15/02/2026 |
| | Authors: |
Ahmed Bashandy, Clarence Filsfils, Prodosh Mohapatra, Yingzhen Qu |
| | Working Group: |
Routing Area Working Group (rtgwg) |
|
In a network comprising thousands of BGP peers exchanging millions of routes, it is desirable to restore traffic after failure in a time period that does not depend on the number of BGP prefixes. This document describes an architecture by which traffic can be re- routed to Equal Cost Multi-Path (ECMP) or pre-calculated backup paths in a timeframe that does not depend on the number of BGP prefixes. The objective is achieved through organizing the forwarding data structures in a hierarchical manner and sharing forwarding elements among the maximum possible number of routes. The described technique yields prefix independent convergence while ensuring incremental deployment, complete automation, and zero management and provisioning effort. It is noteworthy to mention that the benefits of BGP Prefix Independent Convergence (BGP-PIC) are hinged on the existence of more than one path whether as ECMP or primary-backup. |
| |
|
| |
| | Generic Address Assignment Option for 6LoWPAN Neighbor Discovery |
| |
| | draft-ietf-6lo-nd-gaao-09.txt |
| | Date: |
13/02/2026 |
| | Authors: |
Luigi Iannone, David Lou, Adnan Rashid |
| | Working Group: |
IPv6 over Networks of Resource-constrained Nodes (6lo) |
|
This document specifies a new extension to the IPv6 Neighbor Discovery in Low Power and Lossy Networks (LLNs), enabling a node to request to be assigned an address or a prefix from neighbor routers. Such mechanism allows to algorithmically assign addresses and prefixes to nodes in a 6LoWPAN deployment. |
| | RTP Payload Format for ISO/IEC 21122 (JPEG XS) |
| |
|
This document specifies a Real-Time Transport Protocol (RTP) payload format for transport of a video signal encoded with JPEG XS (ISO/IEC 21122). JPEG XS is a low-latency and low-complexity video coding system. Employing this format allows achieving encoding-decoding latencies confined to a fraction of a video frame. This document is a necessary revision of RFC 9134 to incorporate support for new features introduced in the third edition of JPEG XS. Most notably, it contains the necessary provisions to support the TDC coding mode. This document obsoletes RFC 9134; however, the revised payload format is designed to ensure that existing compliant implementations of RFC 9134 remain valid under the updated specification. Additionally, this document consolidates the errata of RFC 9134 and includes improvements and clarifications to its implementers and users. |
| | 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. |
| | Terminology for Energy Efficiency Network Management |
| |
| | draft-ietf-green-terminology-01.txt |
| | Date: |
13/02/2026 |
| | Authors: |
Gen Chen, Mohamed Boucadair, Qin WU, Luis Contreras, Marisol Amador |
| | Working Group: |
Getting Ready for Energy-Efficient Networking (green) |
|
Energy-efficient network management is primarily meant to enhance conventional network management with energy-related management capabilities that optimize overall network energy consumption. To that aim, specific features and capabilities are required to control (and thus optimize) the energy use of involved network elements and their components. This document defines a set of key terms used within the IETF when discussing energy efficiency in network management. Such reference document helps framing discussion and agreeing upon a set of main concepts in this area. |
| | A YANG Data Model for Network Incident Management |
| |
|
This document defines a YANG Module for the network incident lifecycle management. This YANG module is meant to provide a standard way to report, diagnose, and help reduce troubleshooting tickets and resolve network incidents for the sake of network service health and probable cause analysis. |
| | Anonymous Credit Tokens |
| |
|
This document specifies Anonymous Credit Tokens (ACT), a privacy- preserving authentication protocol that enables numerical credit systems without tracking individual clients. Based on keyed- verification anonymous credentials and privately verifiable BBS-style signatures, the protocol allows issuers to grant tokens containing credits that clients can later spend anonymously with that issuer. The protocol's key features include: (1) unlinkable transactions - the issuer cannot correlate credit issuance with spending, or link multiple spends by the same client, (2) partial spending - clients can spend a portion of their credits and receive anonymous change, and (3) double-spend prevention through cryptographic nullifiers that preserve privacy while ensuring each token is used only once. Anonymous Credit Tokens are designed for modern web services requiring rate limiting, usage-based billing, or resource allocation while respecting user privacy. Example applications include rate limiting and API credits. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. |
| | Privacy Pass Issuance Protocol for Anonymous Credit Tokens |
| |
|
This document specifies the issuance and redemption protocols for tokens based on the Anonymous Credit Tokens (ACT) protocol. |
| | Using IKE Fragmentation for Large Messages |
| |
|
This document describes describes issues with using Internet Key Exchange version 2 (IKEv2) fragmentation for transmitting large messages on unreliable transport. The document proposes several approaches for dealing with these issues: randomizing the order the fragments are sent, dispersing sending fragments over time and selective retransmission of fragments based on information from the peer about their receipt. |
| | OAuth 2.0 Token Exchange Target Service Discovery |
| |
|
This specification defines a method for OAuth 2.0 clients to discover the set of available target services (audiences, resources, and scopes) for a given subject token when performing OAuth 2.0 Token Exchange. The discovery endpoint accepts any subject token type registered in the OAuth Token Type Registry and returns values that are valid inputs to subsequent Token Exchange requests, supporting advanced use cases such as identity chaining and cross-domain delegation. |
| | BGP Communities for Security Policy Intent |
| |
|
This document specifies a set of standardized BGP community to signal inter-AS routing security policy intent. The initial focus is on RPKI-based Route Origin Validation (ROV) using ROAs [RFC6482] [RFC6811] [RFC9582]. ROV produces validation outcomes such as "Valid", "Invalid", and "NotFound", but the operational treatment of "NotFound" and similar ambiguous cases is entirely a matter of local policy and often differs across networks. This document defines transitive community that allows an Origin AS to explicitly express its security policy expectations regarding how its own originated routes SHOULD be treated when downstream Autonomous Systems (ASes) perform ROA-based origin validation. A typical example is an Origin AS indicating a preference for strict handling of ambiguous validation outcomes (e.g., NotFound) for its prefixes. Unlike validation states, these community does not assert correctness, authorization, or RPKI deployment status, which is confront to [AVOID-RPKI-STATE-IN-BGP]. Instead, they communicate origin-declared policy intent to all downstream ASes, enabling them to correlate this intent with locally derived validation results. By enabling explicit signaling of security expectations without exporting validation state, this mechanism allows downstream ASes to make more informed policy decisions while reducing the risk of accidental outages caused by misalignment between origin expectations and downstream local policies. The mechanism is orthogonal to existing routing security validation technologies and does not alter their semantics or deployment models. |
| | BMP YANG Model for Network Telemetry Messages |
| |
|
This document defines an BGP Monitoring Protocol (BMP) message schema extension in YANG to be used at data collection to transform Network Telemetry messages into external systems such as Message Brokers. |
| | BGP SR Policy Extensions for BFD Configuration |
| |
|
Segment Routing (SR) Policies require fast failure detection for Candidate Paths (CPs) to enable rapid rerouting and high availability. Currently, the provisioning of SR Policies and the configuration of associated Bidirectional Forwarding Detection (BFD) or Seamless BFD (S-BFD) sessions are performed independently. This often necessitates separate mechanisms (e.g., manual configuration, NETCONF, or additional signaling) to associate BFD/S-BFD sessions with the SR Policies, resulting in complex and error-prone operations This document defines extensions to BGP SR Policy for the simultaneous provisioning of SR Policy CPs and their BFD/S-BFD configuration parameters during policy advertisement. The extensions include optional sub-TLVs within the Tunnel Encapsulation Attribute to carry BFD/S-BFD configuration parameters (e.g., discriminators, intervals, multipliers). These extensions simplify deployment in distributed or controller- based environments, reduce configuration overhead, and enhance operational efficiency for SR-based traffic engineering. |
| | BGP Flow-Spec Redirect to SR Segment List Action |
| |
|
BGP Flow Specification (Flow-spec) provides a mechanism for distributing traffic filtering and policy-based forwarding rules. Existing works enables traffic steering into an SR Policy. However, in Artificial Intelligence (AI) network scenarios, "elephant flows" may require deterministic forwarding over specific segment lists within an SR Policy candidate path. This document specifies a new BGP Flow-spec Redirect action that identifies a specific segment list within an SR Policy. |
| | SIN/IP: Secure In-Network Transport Protocol over IP |
| |
|
SIN/IP is a secure, multiplexed transport protocol designed for kernel residency and incremental deployment. It provides authenticated encryption (AEAD), multiplexed streams over a single connection to avoid head-of-line blocking, connection IDs for NAT rebinding and path migration, and pluggable congestion control and pacing. SIN/IP can run as a native IP protocol in controlled networks or be encapsulated in UDP for Internet deployment. This document specifies the wire format, packet and frame layout, connection establishment, packet protection, loss recovery, flow control, congestion control, path management, and connection termination. It also defines IANA registries for SIN/IP parameters and codepoints. |
| | A Decoupled Authorization Model for Agent2Agent |
| |
|
This document proposes a framework for dynamic, intent-based authorization for AI Agents. The primary goal is to enable fine- grained, Just-in-Time (JIT) permissions based on an agent's specific intent and behavioral trustworthiness, rather than a long-lived identity or role, achieve decoupling of authorization policies from business operations. |
| | PCEP Extension for Flexible Grid Networks |
| |
|
This document provides the Path Computation Element Communication Protocol (PCEP) extensions for the support of Routing and Spectrum Assignment (RSA) in Flexible Grid networks. |
| | 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). ]] |
| | A YANG Data Model for the Virtual Router Redundancy Protocol (VRRP) |
| |
|
This document describes a YANG data model for the Virtual Router Redundancy Protocol (VRRP). Both versions 2 and 3 of VRRP are covered. The VRRP terminology has been updated to conform to inclusive language guidelines for IETF technologies. This document obsoletes RFC 8347. |
| |
|
| |
| | Characterization and Benchmarking Methodology for Power in Networking Devices |
| |
| | draft-ietf-bmwg-powerbench-01.txt |
| | Date: |
12/02/2026 |
| | Authors: |
Carlos Pignataro, Romain Jacob, Giuseppe Fioccola, Qin WU, Gen Chen, Shailesh Prabhu |
| | Working Group: |
Benchmarking Methodology (bmwg) |
|
This document defines a standard mechanism to measure, report, and compare power usage of different networking devices under different network configurations and conditions. |
| | Operational Guidelines for DNS Transport in Mixed IPv4/IPv6 Environments |
| |
|
This document provides guidelines and documents Best Current Practice for operating authoritative DNS servers, recursive resolvers and stub resolvers in a mixed IPv4/IPv6 environment. This document recommends that both authoritative DNS servers and recursive resolvers support IPv4 and IPv6. It also provides guidance on how recursive DNS resolvers should select upstream DNS servers, including when IPv4-embedded IPv6 addresses are available. This document obsoletes RFC 3901. |
| | Early IANA Code Point Allocation |
| |
|
This document describes the requirements for securing IANA code point assignments while IETF Stream Internet-Drafts are still in development and, in certain cases, when the lack of an IANA allocation would block standards publication outside the IETF. This document obsoletes RFC 7120. |
| | BGP-LS Extension for Inter-AS Topology Retrieval |
| |
|
This document specifies the procedure for distributing Border Gateway Protocol-Link State (BGP-LS) key parameters for inter-domain links between two Autonomous Systems (ASes). It defines a new type within the BGP-LS Network Layer Reachability Information (NLRI) for a Stub Link, as well as three new type-length-values (TLVs) for the BGP-LS Link descriptor. These BGP-LS extensions enable Software-Defined Networking (SDN) controllers to automatically retrieve network topology across diverse inter-AS environments. These extensions and procedures allow network operators to collect inter-domain interconnect information and automatically compute the end-to-end network topology using information provided by the BGP-LS protocol. |
| | Certificate Renewal Recommendations for Enrollment over Secure Transport |
| |
|
This document describes an extension to RFC7030, Enrollment over Secure Transport to give an indication to a end-entity device when it should start attempting to renew its certificates. Prior art is that client decides, with a typical recommmendation to start when the remaining lifetime of the certificate is at the 50% point. As typical certificate lifetimes are reduced from years to fractions of a year, the 50% may be far too early, and this document provides a way to give alternate advice. |
| | List Pagination for YANG-driven Protocols |
| |
|
In some circumstances, instances of YANG modeled "list" and "leaf- list" nodes may contain numerous entries. Retrieval of all the entries can lead to inefficiencies in the server, the client, and the network in between. This document defines a model for list pagination that can be implemented by YANG-driven management protocols such as NETCONF and RESTCONF. The model supports paging over optionally filtered and/or sorted entries. The solution additionally enables servers to constrain query expressions on some "config false" lists or leaf- lists. |
| | NETCONF Extensions to Support List Pagination |
| |
|
This document defines a mapping of the list pagination mechanism defined in [I-D.ietf-netconf-list-pagination] to NETCONF [RFC6241]. This document updates [RFC6241], to augment the and "rpc" statements, and [RFC8526], to augment the "rpc" statement, to define input parameters necessary for list pagination. |
| | RESTCONF Extensions to Support List Pagination |
| |
|
This document defines a mapping of the list pagination mechanism defined in [I-D.ietf-netconf-list-pagination] to RESTCONF [RFC8040]. This document updates RFC 8040, to declare "list" and "leaf-list" as valid resource targets for the RESTCONF GET operation, to define GET query parameters necessary for list pagination, and to define a media-type for XML-based lists. |
| | Support of Versioning in YANG Notifications Subscription |
| |
|
This document extends the YANG-Push Subscription mechanism to enforce that particular revisions or semantic versions are used when configuring or establishing a Subscription. It also extends the YANG-Push Subscription state change Notifications with additional context regarding the YANG schema associated with the Subscription. |
| | An Experiment: Network Anomaly Detection Lifecycle |
| |
|
Network Anomaly Detection is the act of detecting problems in the network. Accurately detecting problems is very challenging for network operators in production networks. Good results require a lot of expertise and knowledge around both the implied network technologies and the connectivity services provided to customers, apart from a proper monitoring infrastructure. In order to facilitate network anomaly detection, novel techniques are being introduced, including programmatical, rule-based and AI-based, with the promise of improving scalability and the hope to keep a high detection accuracy. To guarantee acceptable results, the process needs to be properly designed, adopting well-defined stages to accurately collect evidence of anomalies, validate their relevancy and improve the detection systems over time, iteratively. This document describes a well-defined approach on managing the lifecycle process of a network anomaly detection system, spanning across the recording of its output and its iterative refinement, in order to facilitate network engineers to interact with the network anomaly detection system, enable the "human-in-the-loop" paradigm and refine the detection abilities over time. The major contributions of this document are: the definition of three key stages of the lifecycle process, the definition of a state machine for each anomaly annotation on the system and the definition of YANG data models describing a comprehensive format for the anomaly labels, allowing a well-structured exchange of those between all the interested actors. |
| | Tunnel Extensible Authentication Protocol (TEAP) Version 2 |
| |
|
This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 2. It addresses a number of security and interoperability issues which were found during the publication of TEAPv1 ([I-D.ietf-emu-rfc7170bis]). |
| | AI Agent Discovery and Invocation Protocol |
| |
|
This document proposes a standardized protocol for discovery and invocation of AI agents. It defines a common metadata format for describing AI agents (including capabilities, I/O specifications, supported languages, tags, authentication methods, etc.), a capability-based discovery mechanism, and a unified RESTful invocation interface. This revision additionally specifies an optional extension that enables intent-based agent selection prior to discovery and invocation, without changing existing discovery or invocation semantics. The goal is to enable cross-platform interoperability among AI agents by providing a discover-and-match mechanism and a unified invocation entry point. Security considerations, including authentication and trust measures, are also discussed. This specification aims to facilitate the formation of multi-agent systems by making it easy to find the right agent for a task and invoke it in a consistent manner across different vendors and platforms. |
| | Adding an Atomic EXCHANGE_RANGE Operation to NFSv4.2 |
| |
|
The Network File System version 4.2 (NFSv4.2) does not provide support for atomic multi-block updates to file data. This document introduces a new EXCHANGE_RANGE operation which provides for such atomic updates. This document extends NFSv4.2 (see RFC7862). |
| | Agent Context Interaction Optimizations |
| |
|
The context distribution is important in a multi-agent system, which will impact the execution latency, token consumption, and task completion success rate, especially in a complex and multi-round workflow. This document specifies the scenarios and procedures of agent context distribution as well as the corresponding optimization during the procedures in order to provide precise control of the context distribution among the multiple agents. |
| | Multicast Use Cases for Large Language Model Synchronization |
| |
|
Large Language Models (LLMs) deployments are becoming increasingly widespread, with inference services being the most common application. This draft will discuss multicast use cases for inference cloud services. |
| | BGP FLEX |
| |
| | draft-bgp-flex-00.txt |
| | Date: |
12/02/2026 |
| | Authors: |
Bonaventure Zoundi |
| | Working Group: |
Individual Submissions (none) |
|
The Border Gateway Protocol (BGP) is a very important protocol in the Internet to exchange routing information between network domains. BGP populates the routing table with valid routes, sometimes the routes populated by BGP are not the best choices specially when a ISP provides IP Transit service to an other ISP, and the two ISP are peering at an Internet Exchange Point. Let us assume that ISP A provides IP Transit to ISP B, and the two are peering at an Internet Exchange Point. The return traffic from Internet to ISP B via ISP A will be routed over the Internet Exchange Point instead of the IP Transit link between the two ISP, because of BGP Local preference which has usually a higher value on Internet Exchange links. This will lead to an issue because the return traffic IP Transit service is now passing over the Internet Exchange link. An other issue faced in Internet Exchange Point, is the sub-optimal routing caused by the advertisment of the most specific routes over Internet by ISP. Let us assume that ISP A wants to advertise most specific routes to Internet for traffic Engineering, the peers of ISP A at the Internet Exchange Point could also receive the most specific routes over Internet . This will mean that traffic from the peers of ISP A towards ISP A will now go through Internet because of most specific routes which is not suppposed to be the case. To solve that ISP A will have to send the same specific routes over the Internet Exchange Point which will increase complexity. This document provides aletrnative solutions that can be used to solve the above problems |
| | VERA: Verifiable Enforcement for Runtime Agents |
| |
|
AI agents take real actions with real data at machine speed. Compromised AI agents pose significant risks including data exfiltration, unauthorized financial transactions, and cascading failures across downstream systems. This document introduces VERA (Verifiable Enforcement for Runtime Agents), a zero trust reference architecture that provides a structured threat model, five enforcement pillars with typed schemas, four formally stated security properties, and an evidence-based maturity runtime where agents earn autonomy through cryptographic proof rather than calendar time. |
| | Use of FrodoKEM in the Cryptographic Message Syntax |
| |
|
FrodoKEM is a quantum-resistant key encapsulation mechanism (KEM) based on the standard Learning With Errors (LWE) problem. It is one of three KEMs in the process of ISO standardization. This document specifies the conventions for using eight variants of FrodoKEM in the Cryptographic Message Syntax (CMS), by employing the KEMRecipientInfo structure defined in "Use of Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS)" [RFC9629]. These eight variants of FrodoKEM are (e)FrodoKEM-976-AES and (e)FrodoKEM-976-SHAKE for security level 3, and (e)FrodoKEM-1344-AES and (e)FrodoKEM-1344-SHAKE for security level 5. |
| | BGP SR Policy Extensions for State Report |
| |
|
This document extends BGP SR Policy, the same protocol used to configure SR Policies, to report operational state information of SR Policies, Candidate Paths, and Segment Lists. Optional State sub-TLVs, carried within the BGP Tunnel Encapsulation attribute, are introduced in this document to report the operational states (e.g., Down, Inactive, or Invalid) along with their associated reasons of the SR Policies from network elements to controller. These extensions are restricted to operational state reporting and do not alter SR Policy computation, path selection procedures, or the operations of the base BGP protocol. |
| | Export of Gigabit Passive Optical Network Encapsulation Mode in IP Flow Information Export (IPFIX) |
| |
|
This document introduces new IP Flow Information Export (IPFIX) Information Elements to identify a set of G-PON Encapsulation Method entities in the Passive Optical Transport of the Optical Distribution Network. |
| | Guidance to Avoid Carrying RPKI Validation States in Transitive BGP Path Attributes |
| |
|
This document provides guidance to avoid carrying Resource Public Key Infrastructure (RPKI) derived Validation States in transitive Border Gateway Protocol (BGP) Path Attributes. Annotating routes with transitive attributes signaling Validation State may cause needless flooding of BGP UPDATE messages through the global Internet routing system, for example when Route Origin Authorizations (ROAs) are issued, or are revoked, or when RPKI-To-Router sessions are terminated. Operators SHOULD ensure Validation States are not signaled in transitive BGP Path Attributes. Specifically, Operators SHOULD NOT associate Prefix Origin Validation state with BGP routes using transitive BGP Communities. |
| | ML-KEM Post-Quantum Key Agreement for TLS 1.3 |
| |
|
This memo defines ML-KEM-512, ML-KEM-768, and ML-KEM-1024 as NamedGroups and and registers IANA values in the TLS Supported Groups registry for use in TLS 1.3 to achieve post-quantum (PQ) key establishment. |
| |
|
| |
| | Carrying Network Resource (NR) related Information in IPv6 Extension Header |
| |
|
Virtual Private Networks (VPNs) provide different customers with logically separated connectivity over a common network infrastructure. With the introduction of 5G and also in some existing network scenarios, some customers may require network connectivity services with advanced features comparing to conventional VPN services. Such kind of network service is called enhanced VPNs. Enhanced VPNs can be used, for example, to deliver network slice services. 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 may be used as the underlay to support one or a group of enhanced VPN services. For packet forwarding within a specific NRP, some fields in the data packet (which is called NRP Selector) need to be used to identify the NRP to which the packet belongs. In doing so, NRP-specific processing can be performed on each node along the forwarding path in the NRP. This document specifies a new IPv6 Hop-by-Hop option to carry Network Resource related information (e.g., identifier) in data packets. The NR Option can be used to carry NRP Selector ID and related information, while it is designed to make the NR option generalized for other network resource semantics and functions. |
| | RTP Payload Format for Visual Volumetric Video-based Coding (V3C) |
| |
|
A visual volumetric video-based coding (V3C) ISO/IEC 23090-5 bitstream is composed of V3C units that contain V3C atlas sub- bitstreams, V3C video sub-bitstreams, and a V3C parameter set. This memo describes an RTP payload format for V3C atlas sub-bitstreams. The RTP payload format for V3C video sub-bitstreams is defined by relevant IETF RFC for the applicable video codec. The V3C RTP payload format allows for packetization of one or more V3C atlas Network Abstraction Layer (NAL) units in an RTP packet payload as well as fragmentation of a V3C atlas NAL unit into multiple RTP packets. The memo also describes the mechanisms for grouping RTP streams of V3C component sub-bitstreams, providing a complete solution for streaming V3C encoded content. |
| | Representing metadata annotations in YANG-CBOR |
| |
|
This specification defines the representation of metadata annotations (RFC 7952) in YANG-CBOR (RFC 9254). It updates RFC 9595 to add a separate namespace enabling the representation of SIDs for metadata annotations in the ".sid" files defined there. |
| | BGP SR Policy Extensions for Network Resource Partition |
| |
|
Segment Routing (SR) Policy is a set of candidate paths, each consisting of one or more segment lists and the associated information. The header of a packet steered in an SR Policy is augmented with an ordered list of segments associated with that SR Policy. A Network Resource Partition (NRP) is a subset of network resources allocated in the underlay network which can be used to support one or a group of RFC 9543 network slice services. In networks where there are multiple NRPs, an SR Policy may be associated with a particular NRP. The association between SR Policy and NRP needs to be specified, so that for service traffic which is steered into the SR Policy, the header of the packets can be augmented with the information associated with the NRP. An SR Policy candidate path can be distributed using BGP SR Policy. This document defines the extensions to BGP SR policy to specify the NRP which the SR Policy candidate path is associated with. |
| | YANG Groupings for QUIC clients and QUIC servers |
| |
|
This document defines five YANG 1.1 modules to support the configuration of QUIC clients and QUIC servers. The modules include basic parameters for configuring QUIC based clients and servers as well as initial modules for the IANA registries "QUIC Versions" and "QUIC Transport Parameters". Editorial note (To be removed by the RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: * AAAA --> the assigned RFC value for this draft * CCCC --> the assigned RFC value for draft-ietf-netconf-udp-client- server |
| | Generic Fault-Avoidance Routing Protocol for Data Center Networks |
| |
| | draft-sl-rtgwg-far-dcn-25.txt |
| | Date: |
11/02/2026 |
| | Authors: |
Bin Liu, Yantao Sun, Jing Cheng, Yichen Zhang, Bhumip Khasnabish |
| | Working Group: |
Individual Submissions (none) |
|
This document describes a generic routing method and protocol for a regular data center network, named the Fault-Avoidance Routing (FAR) protocol. The FAR protocol provides a generic routing method for all types of regular topology network architectures that have been proposed for large-scale cloud-based data centers over the past few years. The FAR protocol is designed to leverage any regularity in the topology and compute its routing table in a concise manner. Fat- tree is taken as an example architecture to illustrate how the FAR protocol can be applied in real operational scenarios. |
| | The Gordian Envelope Structured Data Format |
| |
|
Gordian Envelope specifies a structured format for hierarchical binary data focused on the ability to transmit it in a privacy- focused way, offering support for privacy as described in RFC 6973 and human rights as described in RFC 8280. Envelopes are designed to facilitate "smart documents" and have a number of unique features including: easy representation of a variety of semantic structures, a built-in Merkle-like digest tree, deterministic representation using CBOR, and the ability for the holder of a document to selectively elide specific parts of a document without invalidating the digest tree structure. This document specifies the base Envelope format, which is designed to be extensible. |
| | dCBOR: Deterministic CBOR |
| |
|
The purpose of determinism is to ensure that semantically equivalent data items are encoded into identical byte streams. CBOR (RFC 8949) defines "Deterministically Encoded CBOR" in its Section 4.2, but leaves some important choices up to the application developer. The present document specifies dCBOR, a set of narrowing rules for CBOR that can be used to help achieve interoperable deterministic encoding for a variety of applications desiring a narrow and clearly defined set of choices. |
| | SID as source address in SRv6 |
| |
|
SRv6 is being rapidly deployed and is currently primarily used in trusted-domain backbone networks. Both the carrier market and the enterprise market are adopting SRv6 for end-to-end service delivery. However, if a firewall exists along an SRv6 path, legitimate SRv6 traffic will be dropped. This proposal addresses this issue by using SID as source address in SRv6 packets. |
| | Mechanism to control jitter caused by policing in Detnet |
| |
|
This document presents a noble mechanism to eliminate jitter caused by policing delay in a network. It needs to be used in combination with a queueing mechanism that provides low jitter for the DetNet path, and ultimately provides a low jitter guarantee for the DetNet flow. |
| | SRv6 Path Verification |
| |
|
SRv6 is being rapidly deployed and is currently primarily used in trusted-domain backbone networks. However, we have also observed that SRv6 is beginning to extend toward customer site devices, e.g., SD-WAN and enterprise network deployments. Both of the scenarios can be deployed in third-party clouds or at customer sites. This introduces certain security risks, such as packet injection and path manipulation attacks. Section 6 of [I-D.draft-ietf-spring-srv6-security] identifies these risks as well, including Section 6.2.1 on Modification Attacks and Section 6.2.3 on Packet Insertion. This proposal mitigates these risks by enhancing the HMAC mechanism defined in [RFC8754]. |
| | Hierarchical Topology for Language Model Coordination |
| |
|
This document defines a YANG data model and reference architecture for a hierarchical topology of language models (LMs), where tiny, small, and large LMs cooperate to perform distributed inference, summarization, and decision-making. The model supports secure inter-node messaging, request escalation, token-based authorization, and decentralized validation using pluggable trust models. This architecture is designed for deployments where computational capabilities vary across nodes, such as edge-to-cloud environments or multi-tier AI systems. The goal is to provide a standards-based mechanism for orchestrating scalable, secure LM interactions across heterogeneous systems. |
| | Applicability of A2A Protocol for Network Management Agents |
| |
|
The evolution of network management towards autonomic operation requires the deployment of AI agents at various hierarchical layers, including directly on network elements. This transformation shifts network devices from passively managed resources to autonomous entities capable of local decision-making and collaborative problem- solving. This document discusses the applicability of the Agent-to-Agent (A2A) Protocol to the network management plane, specifically for communication between Controller Agents (CAs) and Device Agents (DAs). This indicates that the inherent characteristics of Device Agents necessitate the adoption of the agent-to-agent communication paradigm. The document further explores generic workflows, deployment scenarios, and the relationship of A2A with existing network management protocols like NETCONF, RESTCONF, gNMI,and the Model Context Protocol (MCP). |
| | Proof of Process: An Evidence Framework for Digital Authorship Attestation |
| |
|
This document specifies the Proof of Process (PoP) Evidence Framework, a specialized profile of Remote Attestation Procedures (RATS) designed to validate the provenance of effort in digital authorship. Unlike traditional provenance, which tracks file custody, PoP attests to the continuous, human-driven process of creation. The framework defines a cryptographic mechanism for generating Evidence Packets containing Verifiable Delay Functions (VDFs) to enforce temporal monotonicity and Jitter Seals to bind behavioral entropy (motor-signal randomness) to the document state. These mechanisms allow a Verifier to cryptographically distinguish between human-generated keystrokes, algorithmic generation, and copy-paste operations. Crucially, this verification relies on statistical process metrics and cryptographic binding, enabling authorship attestation without disclosing the semantic content of the document, thereby preserving privacy by design. |
| | Proof of Process (PoP) CDDL Schema |
| |
|
This document provides the normative Concise Data Definition Language (CDDL) schema for the Proof of Process (PoP) protocol. The schema defines the CBOR-encoded wire format for PoP evidence packets, semantic editing event transcripts, time anchors, signed tool receipts, compact evidence references, and verifier-produced attestation results. The schema is published separately to enable independent tooling, validation, and schema versioning decoupled from narrative specification text. |
| | Community consensus report on DNS WG structures at IETF |
| |
|
There has been an increasing level of discussion within the IETF about the best Working Group (WG) structures for handling the wide array of DNS work being conducted within the IETF. Wes Hardaker was asked to gather information from the community at large through email, hallway discussions, and meetings and create a small team to discuss potential structural changes to be shared with the community. This document is the result of that effort. |
| | ASL Authenticated Secure Layer Protocol |
| |
|
This document specifies ASL (Authenticated Secure Layer), a cryptographic protocol for establishing an authenticated and encrypted communication session based on a novel arithmetic primitive called phi-ns-x (also known as ns-mod). ASL provides a complete handshake and data transport layer without reliance on traditional algorithms like RSA, Diffie-Hellman, AES or SHA. Instead, it builds on the Phi-Ns cryptosystem, which defines a structured quadratic relation between primes and achieves security through non-linear modular arithmetic and combinatorial complexity. ASL includes an initial authentication and key exchange mechanism where a server public key (composed only of specific allowed elements such as a prime modulus and state parameters) is used by a client to establish shared secrets. The protocol uses a stateful encryption transform (phi-ns-x) for data, with each message round incorporating a public state value that changes unpredictably. Shared secret parameters control this state evolution, preventing man-in-the-middle and injection attacks by ensuring that only parties with knowledge of the secrets can produce valid ciphertexts. |
| | DKIM2 Best Practices |
| |
|
[DKIM2] and associated documents describe the DomainKeys Identified Mail v2 (DKIM2) email authentication protocol. DKIM2 is designed to address shortcomings in email authentication protocols and mechanisms released prior to DKIM2, specifically SPF [RFC7208], DKIM [RFC6376], DMARC [RFC7489], and ARC [RFC8617]. Those shortcomings most commonly manifested themselves in email messages that passed through one or more intermediary hosts (e.g., forwarders or mailing list servers) while transiting from origination to final destination. Although these messages were properly authenticated when sent, the alteration of their path and/or content by the intermediary hosts would cause authentication checks to fail at the final destination. In addition, DKIM was susceptible to "replay" of signatures, when attackers would construct abusive messages in such a way that they would pass validation checks for a DKIM signature that had been imported from another message entirely. To address these shortcomings, DKIM2 provides methods not only for intermediary systems to provide details of the changes that they make to a message in transit, but also for receiving hosts to validate those changes in addition to the original message. DKIM2 also allows recipients to detect when messages have been unexpectedly "replayed" and can also ensure that delivery status notifications (DSNs) are only sent to entities that were involved in the transmission of a message. This document describes the recommended usage of the DKIM2 protocol for sending hosts, intermediary hosts, and receiving hosts. |
| | Use of Natural Language for Agent Communication |
| |
| | draft-verma-dmsc-nlip-notes-00.txt |
| | Date: |
11/02/2026 |
| | Authors: |
Dinesh Verma, Elisa Bertino, Abhay Ratnaparkhi, Sean Hughes, Luyi Xing, Zichuan Li, Xiaojing Liao, Jian Cui, Rasit Topaloglu, Mohamed Rahouti |
| | Working Group: |
Individual Submissions (none) |
|
In current communication protocol designs, the prevalent practice is to define a strict Application Programming Interface (API) for different types of interactions among software entities. There is an explosion of APIs which makes interoperability hard, and the standards for interoperability fragile. Specifically for agent to agent communications, defining strict APIs for interactions such as registration, discovery, telemetry and debugging creates significant operational challenges. In this draft, we argue that a flexible design option -- where generative AI is used to create a flexible communication protocol for APIs, can lead to a common and flexible way for a single uniform API to be used between agents, and enables a better communication paradigm. |
| | 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. |
| | Using JSContact in Registration Data Access Protocol (RDAP) JSON Responses |
| |
|
This document describes an RDAP extension which represents entity contact information in JSON responses using JSContact. |
| | Fast Network Notifications Problem Statement |
| |
| | draft-ietf-rtgwg-net-notif-ps-00.txt |
| | Date: |
11/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: |
Routing Area Working Group (rtgwg) |
|
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. |
| | Scalability Considerations for Network Resource Partition |
| |
| | draft-ietf-teas-nrp-scalability-09.txt |
| | Date: |
11/02/2026 |
| | Authors: |
Jie Dong, Zhenbin Li, Liyan Gong, Guangming Yang, Gyan Mishra |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
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 using networks that use IETF technologies. As part of that framework, the Network Resource Partition (NRP) is introduced as a set 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. As the demand for network slices increases, scalability becomes an important factor. Although the scalability of network slices can be improved by mapping a group of network slices to a single NRP, that design may not be suitable or possible for all deployments, thus there are concerns about the scalability of NRPs themselves. This document discusses some considerations for NRP scalability in the control and data planes. It also investigates a set of optimization mechanisms. |
| |
|
| |
| | Group Communication for the Constrained Application Protocol (CoAP) |
| |
|
The Constrained Application Protocol (CoAP) is a web transfer protocol for constrained devices and constrained networks. In a number of use cases, constrained devices often naturally operate in groups (e.g., in a building automation scenario, all lights in a given room may need to be switched on/off as a group). This document specifies the use of CoAP for group communication, including the use of UDP/IP multicast as the default underlying data transport. Both unsecured and secured CoAP group communication are specified. Security is achieved by use of the Group Object Security for Constrained RESTful Environments (Group OSCORE) protocol. The target application area of this specification is any group communication use cases that involve resource-constrained devices or networks that support CoAP. This document replaces and obsoletes RFC 7390, while it updates RFC 7252 and RFC 7641. |
| | DNS Protocol Modifications for Delegation Extensions |
| |
|
The Domain Name System (DNS) protocol permits Delegation Signer (DS) records at delegation points. This document describes modifications to the Domain Name System (DNS) protocol to permit a range of resource record types at delegation points. These modifications are designed to maintain compatibility with existing DNS resolution mechanisms and provide a secure method for processing these records at delegation points. |
| | TLS 1.2 Update for Long-term Support (LTS) |
| |
|
This document specifies an update of TLS 1.2 for long-term support (LTS) on systems that can have multi-year or even decade-long update cycles, one that incoporates as far as possible what's already deployed for TLS 1.2 but with the security holes and bugs fixed. This document also recognises the fact that there is a huge amount of TLS use outside the web content-delivery environment with its resource-rich hardware and software that can be updated whenever required and provides a long-term stable, known-good version that can be deployed to systems that can't roll out ongoing changes on a continuous basis. |
| | A Pre-Authentication Mechanism for SSH |
| |
|
Devices running SSH are frequently exposed on the Internet, either because of operational considerations or through misconfiguration, making them vulnerable to the constant 3-degree background radiation of scanning and probing attacks that pervade the Internet. This document describes a simple pre-authentication mechanism that limits these attacks with minimal changes to SSH implementations and no changes to the SSH protocol itself. |
| | PKCS #15 Updates |
| |
|
This document describes updates to the PKCS #15 standard made since the original publication of the standard. |
| | Provider Interface SAV for Customer Cone Sources |
| |
|
Current source address validation (SAV) on AS's provider interfaces primarily relies on loose uRPF, which can protect against IP spoofing based on unannounced internet prefixes but lacks the ability to defend against spoofing based on valid internet prefixes. Furthermore, if a default route is present, this protection is effectively nullified. Based on the traffic flow characteristics between the ASes in a customer cone, this document describes a general solution architecture -- provider interface SAV for customer cone source spoofing (PI-SAV for CC). This mechanism can be applied on the provider interfaces of an AS to prevent spoofing traffic with the customer cone source addresses from flowing into the local AS and its customer cone. Specially, this mechanism offers protection against reflective amplification DDoS attacks that leverage local servers to target victims within the customer cone. |
| | SOCKS Protocol Version 4 |
| |
|
This document describes SOCKS version 4, a protocol designed to facilitate TCP proxy services across a network firewall. SOCKS operates at the session layer, providing application users with transparent access to network services on the other side of the firewall. It is application-protocol independent, allowing it to support a wide range of services, including those utilizing encryption, while maintaining minimum processing overhead by simply relaying data after initial access control checks. The protocol defines two primary operations: CONNECT for establishing outbound connections to an application server, and BIND for preparing for and accepting inbound connections initiated by an application server. |
| | Transaction Tokens For Agents |
| |
|
This document specifies an extension to the OAuth Transaction Tokens framework (https://drafts.oauth.net/oauth-transaction-tokens/draft- ietf-oauth-transaction-tokens.html) to support agent context propagation within Transaction Tokens for agent-based workloads. The extension defines two new context fields: 'actor' and 'principal'. The 'actor' field identifies the agent performing the action, while the 'principal' field identifies the human or system entity that initiated the agent's action. For autonomous agents operating independently, the 'principal' field MAY be omitted. These additional context fields enable services within the call graph to make more granular access control decisions, thereby enhancing security. |
| | 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. The protocol employs a Criticality Engine grounded in statistical physics to distinguish biological movement from synthetic trajectories. Power Spectral Density analysis detects the 1/f signature of Self-Organized Criticality in human mobility. A six- component Hamiltonian energy function scores each breadcrumb against the identity's learned behavioral profile in real time. This revision formalizes the mapping to the RATS Architecture (RFC 9334), clarifies the Verifier trust model including support for multiple independent Verifiers, introduces an active challenge- response verification protocol that binds Attestation Results to specific Relying Party requests with cryptographic freshness, and corrects the privacy model to accurately describe the flow of Evidence between Attester and Verifier. TRIP is designed to be transport-agnostic and operates independently of any particular naming system, blockchain, or application layer. |
| | OAuth 2.0 Scope Aggregation for Multi-Step AI Agent Workflows |
| |
|
This document describes a scope-aggregated OAuth 2.0 authorization pattern for multi-step AI agent workflows. An AI agent aggregates the scopes required across a workflow and only initiates a single authorization procedure for the aggregated scope. This reduces repeated user consents and multiple authorization round-trips, improving authorization efficiency. |
| | Cross-Domain Interoperability Framework for AI Agent Collaboration |
| |
|
This document defines a framework for enabling seamless cross-domain interoperability among AI agents operating across different networks, administrative domains, and heterogeneous platforms. The framework addresses the challenges of identity federation, trust establishment, policy harmonization, and secure communication that arise when AI agents from distinct administrative realms need to collaborate on shared tasks. It specifies mechanisms for agent discovery, capability negotiation, trust delegation, and federated policy enforcement, enabling scalable and secure multi-domain AI collaboration without requiring centralized control. |
| | A Service YANG Data Model for dynamic-L3VPN |
| |
|
This document defines extensions to the Layer 3 VPN Service Model (L3SM) defined in RFC8299 to support dynamic L3VPN services. The extensions enable (1) dynamic network provisioning with temporary connectivity, (2) dynamic bandwidth adjustment, and (3) integration of Slice Service Templates for enhanced Service Level Objective (SLO) specification. These capabilities address operational requirements for data-intensive workloads that are not supported by the base L3SM model, which assumes static connectivity and fixed bandwidth allocations. |
| | Export of BGP Prefix Origin Validation in IP Flow Information Export (IPFIX) |
| |
|
This document defines an IP Flow Information Export (IPFIX) Information Element for monitoring the state of Resource Public Key Infrastructure (RPKI) based BGP Prefix Origin Validation. The Information Element enables network operators to collect and analyze BGP route validation states (valid, invalid, not-found) to facilitate the detection of potential route hijacks improving network observability and security. |
| | Persistent Symmetric Keys in OpenPGP |
| |
|
This document defines a new packet and algorithm for the OpenPGP standard (RFC 9580) to support persistent symmetric keys, for message encryption using authenticated encryption with additional data (AEAD) and for message authentication using AEAD authentication tags. This enables the use of symmetric cryptography for data storage (and other contexts that do not require asymmetric cryptography), for improved performance, smaller keys, and improved resistance to quantum computing. |
| | PCE Communication Protocol (PCEP) Extensions for Using PCE as a Central Controller (PCECC) for Segment Routing (SR) MPLS Segment Identifier (SID) Allocation and Distribution |
| |
|
The Path Computation Element (PCE) is a core component of Software- Defined Networking (SDN) systems. A PCE-based Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. Thus, the Label Switched Path (LSP) can be calculated/set up/initiated and the label forwarding entries can also be downloaded through a centralized PCE server to each network device along the path while leveraging the existing PCE technologies as much as possible. This document specifies the procedures and PCE Communication Protocol (PCEP) extensions when a PCE-based controller is also responsible for configuring the forwarding actions on the routers, in addition to computing the paths for packet flows in a segment routing (SR) network and telling the edge routers what instructions to attach to packets as they enter the network. PCECC as defined in RFC 9050 is further enhanced for SR-MPLS SID (Segment Identifier) allocation and distribution. |
| | PCE Communication Protocol (PCEP) Extensions for Using the PCE as a Central Controller (PCECC) of point-to-multipoint (P2MP) LSPs |
| |
|
The PCE is a core component of Software-Defined Networking (SDN) systems. The PCE has been identified as an appropriate technology for the determination of the paths of point-to-multipoint (P2MP) TE Label Switched Paths (LSPs). A PCE-based Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. Thus, the P2MP LSP can be calculated/set up/initiated, and the label-forwarding entries can also be downloaded through a centralized PCE server to each network device along the P2MP path while leveraging the existing PCE technologies as much as possible. This document specifies the procedures and PCE Communication Protocol (PCEP) extensions for using the PCE as the central controller for provisioning labels along the path of the static P2MP LSP. |
| | Push-Based Delivery For Multiple Security Event Tokens (SET) Using HTTP |
| |
|
This specification defines how multiple Security Event Tokens (SETs) can be delivered to an intended recipient using HTTP POST over TLS. The SETs are transmitted in the body of an HTTP POST request to an endpoint operated by the recipient, and the recipient indicates successful or failed transmission via the HTTP response. |
| |
|
| |
| | CoAP Publish-Subscribe Profile for Authentication and Authorization for Constrained Environments (ACE) |
| |
|
This document defines an application profile of the Authentication and Authorization for Constrained Environments (ACE) framework, to enable secure group communication in the Publish-Subscribe (Pub-Sub) architecture for the Constrained Application Protocol (CoAP) [draft- ietf-core-coap-pubsub], where Publishers and Subscribers communicate through a Broker. This profile relies on protocol-specific transport profiles of ACE to achieve communication security, server authentication, and proof of possession of a key owned by the Client and bound to an OAuth 2.0 access token. This document specifies the provisioning and enforcement of authorization information for Clients to act as Publishers and/or Subscribers, as well as the provisioning of keying material and security parameters that Clients use for protecting their communications end-to-end through the Broker. Note to RFC Editor: Please replace "[draft-ietf-core-coap-pubsub]" with the RFC number of that document and delete this paragraph. |
| | Constrained Application Protocol (CoAP) over Bundle Protocol (BP) |
| |
|
The Bundle Protocol (BP) was designed to enable end-to-end communication in challenged networks. The Constrained Application Protocol (CoAP), which was designed for constrained-node networks, may be a suitable application-layer protocol for the scenarios where BP is used. This document specifies how CoAP is carried over BP. |
| | BGP SR Policy Extensions for Segment List Identifier |
| |
|
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is a set of candidate paths, each consisting of one or more segment lists. This document defines extensions to BGP SR Policy to specify the identifier of segment list. |
| | A YANG Model for BGP-LS,BGP-LS-VPN,and BGP-LS-SPF |
| |
|
This document defines a YANG data model for configuration and management of BGP-LS, BGP-LS-VPN, and BGP-LS-SPF. |
| | Guidance for Managing YANG Modules in RFCs and IANA Registries |
| |
|
This document provides guidance to the RFC Editor and IANA on managing YANG modules in RFCs and IANA registries, ensuring consistent application of YANG Semantic Versioning rules. |
| | ACLs within the NFSv4 Protocols |
| |
|
This document is part of the set of documents intended to update the description of NFSv4 Minor Version One as part of the rfc8881bis respecification effort for NFSv4.1. It describes the structure and function of NFSv4 Access Control Lists within NFSv4.0 and NFSv4.1. These minor versions and forthcoming ones define ACLs using an ACL structure derived from Windows ACLs. Support for other ACL approaches such as draft-POSIX ACLs remains an option that could be taken advantage of in later minor versions such as NFSv4.2. This document describes the structure of these Windows-derived NFSv4 ACLs and their role in the NFSv4 security architecture. While the focus of this document is on the role of these ACLs in providing a more flexible approach to file access authorization than is made available by the POSIX-derived authorization-related attributes, the potential provision of other security-related functionality based on ACLs is covered as well. Because of the failure of previous specifications to provide a satisfactory description of the authorization semantics of NFSv4 ACLs, this document takes a different approach to many matters while maintaining compatibility with implementations based on previous specifications. When the resulting document is eventually published as an RFC, it will supersede the descriptions of ACL structure and semantics appearing in existing minor version specification documents for NFSv4.0 and NFSv4.1, thereby updating RFC7530 and RFC8881. |
| | Supporting IOAM in IPv6 |
| |
|
IOAM pre-allocated trace option data fields can be encapsulated in IPv6 HbH options header as described in RFC9486. However, due to the potential large size of the trace data and the HbH extension header location in the IPv6 packets, the scheme creates practical challenges for implementation, especially when other extension headers, such as a routing header, also exist and require on-path processing. We propose two alternative approaches to address this challenge in addition to IOAM DEX: separating the IOAM incremental trace data from the IOAM instruction header, or applying the segment IOAM trace data export scheme, based on the network scenario and application requirements. We discuss the pros and cons of each approach in this document. |
| | The Architecture of Network-Aware Domain Name System (DNS) |
| |
|
This document describes a framework which extends the Domain Name System (DNS) to provide network awareness to applications. The framework enables DNS system responses that are dependent on communication service requirements such as QoS or path without changes in the format of DNS protocol messages or application program interfaces (APIs). The different enhancement methods and use cases are discussed. |
| | BGP-LS Advertisement of SR Policy Performance Metric |
| |
|
This document describes a way to advertise the performance metrics for Traffic Engineering (TE) Policy using BGP Link State (BGP-LS). |
| | Upper limit values for DNS |
| |
|
DNS was designed to have as few hard upper limits as possible to allow for future extensibility. However, the lack of a clear upper limit leads to vulnerabilities, and several attack methods have been reported. This document collects upper limit values implemented by DNS software to avoid vulnerabilities. |
| | Knowledge Graphs for Enhanced Cross-Operator Incident Management and Network Design |
| |
|
Operational efficiency in incident management in networking requires correlating and interpreting large volumes of heterogeneous technical information. Knowledge Graphs (KG) can provide a unified view of complex systems through shared vocabularies. YANG data models enable describing network configurations and automating their deployment. However, both approaches face challenges in vocabulary alignment and adoption, hindering knowledge capitalization and sharing on network designs and best practices. To address this, the concept of a IT Service Management Knowledge Graph (ITSM-KG) is introduced to leverage existing network infrastructure descriptions in YANG format and enable abstract reasoning on network behaviors. The key principle to achieve the construction of such ITSM-KG is to transform YANG representations of network infrastructures into an equivalent knowledge graph representation, and then embed it into a more extensive data model for Anomaly Detection (AD) and Risk Management applications. In addition to use case analysis and design pattern analysis, an experiment is proposed to assess the potential of the ITSM-KG in improving network quality and designs. |
| | Applicability of TVR YANG Data Models |
| |
|
Time-Variant Routing (TVR) is a routing system that can accommodate predicted topology changes caused by internal or external factors. Typical use cases include resource preservation networks, operating efficiency networks and dynamic reachability networks. This document provides examples of how to implement the TVR scheduling capabilities for key use cases. It describes which part of the TVR data model is used and why, and it outlines operational and security considerations when deploying TVR-based technologies. |
| | Considerations on Authoritative Information for Source Address Validation |
| |
|
Source Address Validation (SAV) prevents source address spoofing. This document explains that SAVNET relies on authoritative information. It also describes how to handle missing or conflicting data. The guidance minimizes improper blocks and improper permits while supporting reliable SAV enforcement. |
| | Phi-Ns Cryptosystem |
| |
|
This document describes Phi-Ns, a new asymmetric cryptographic primitive based on the structured decomposition of the quadratic gap between two primes. Phi-Ns defines a public key q and a private key p such that the difference q^2 - p^2 is expressed as a composite value T. The value T is then factored into small controlled components noted a, b, and R, and the final secret structure abR is encoded through a randomized serialization process. The security of Phi-Ns does not rely on integer factorization, the discrete logarithm problem, or elliptic curves. Instead, it depends on the difficulty of recovering p from q when the attacker has no oracle, no structural anchor, and no method to determine whether a candidate p is correct. Because T can be recursively decomposed and reassembled into multiple unpredictable forms, the resulting search space grows combinatorially. Phi-Ns further supports recursive expansion of the internal abR structure, allowing the construction of high-entropy secret states even when p and q have relatively small bit lengths. This enables compact public keys, efficient computation, and strong post-quantum resistance based on a non-factorization hardness assumption. This document specifies the algorithmic model of Phi-Ns, its parameter choices, and the serialization rules used to encode the abR structure. It also outlines two public-key variants, PK-p and PK-q, which expose either p or q as the public value depending on deployment constraints. |
| | DNS Extensions to Energy Efficiency as Service(EEAS) |
| |
|
This document describes a new Mechanism and DNS resource record (RR) type to carry information about energy-related characteristics for end-to-end internet access. The "EE" ("Energy Efficiency") record allows the network to provide different levels of energy-saving service. By providing more energy information to the client before it attempts to establish a connection, these records offer potential benefits to enhancements on energy as service criteria. |
| | 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 path selection decisions when hijacked routes are detected (see Section 3). |
| | Post-Session Execution Assurance (PSEA): A Security Model for Verifying Authority at the Moment of Action |
| |
|
Modern security architectures assume that trust established at login can safely extend to all subsequent actions within a session. This assumption is fundamentally flawed. Sessions preserve the memory of authentication but not the certainty of authority. Post-Session Execution Assurance (PSEA) is an architectural security model that addresses this gap by requiring cryptographic proof of real human presence, device trust, and execution authority at the exact moment a sensitive action is approved — independent of prior authentication or session state. This paper defines the PSEA model, its core principles, its distinction from existing security paradigms, and its implications for regulated and mission-critical systems. |
| | 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. |
| | OAuth Identity and Authorization Chaining Across Domains |
| |
| | draft-ietf-oauth-identity-chaining-08.txt |
| | Date: |
09/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. |
| | YANG Data Model for Scheduled Attributes |
| |
|
The YANG model in this document includes three modules, and can be used to manage network resources and topologies with scheduled attributes, such as predictable link loss and link connectivity as a function of time. The intent is to have this information be utilized by Time-Variant Routing systems. |
| |
|
| |
| | 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. |
| | CCNx Content Object Chunking |
| |
|
This document specifies a chunking protocol for dividing a user payload into CCNx Content Objects. It defines a name segment type to identify each sequential chunk number and a Content Object field to identify the last available chunk number. This includes specification for the naming convention to use for the chunked payload and a field added to a Content Object to represent the last chunk of an object. This document updates RFC8569 and RFC8609. |
| | 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. |
| | 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. |
| | 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: 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. |
| | 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. |
| |
|
| |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| |
|
| |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |