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