| |
|
| |
| | Structured Error Data for Filtered DNS |
| |
|
DNS filtering is widely deployed for various reasons, including network security and policy enforcement. However, filtered DNS responses lack structured information for end users to understand the reason for the filtering. Existing mechanisms to provide explanatory details to end users cause harm especially if the blocked DNS response is for HTTPS resources. This document updates RFC 8914 by signaling client support for structuring the EXTRA-TEXT field of the Extended DNS Error to provide details on the DNS filtering. Such details can be parsed by the client and displayed, logged, or used for other purposes. |
| | VPN Prefix Outbound Route Filter (VPN Prefix ORF) for BGP-4 |
| |
|
This document defines an experimental specification for 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 the VPN Prefix ORF mechanism is to control the overload of VPN routes based on Route Distinguisher (RD), Route Target (RT) and other necessary routing information. This mechanism is applicable to intra-domain scenarios. |
| | JOSE HPKE PQ & PQ/T Algorithm Registrations |
| |
| | draft-ietf-jose-hpke-pq-pqt-00.txt |
| | Date: |
09/06/2026 |
| | Authors: |
Filip Skokan, Brian Campbell, Hannes Tschofenig, Tirumaleswar Reddy.K |
| | Working Group: |
Javascript Object Signing and Encryption (jose) |
|
This document registers Post-Quantum (PQ) and Post-Quantum/ Traditional (PQ/T) hybrid algorithm identifiers for use with JSON Object Signing and Encryption (JOSE), building on the Hybrid Public Key Encryption (HPKE) framework. |
| | Adding an Uncacheable File Data Attribute to NFSv4.2 |
| |
|
Network File System version 4.2 (NFSv4.2) clients commonly perform client-side caching of file data in order to improve performance. On some systems, applications may influence client data caching behavior, but there is no standardized mechanism for a server or administrator to indicate that particular file data should not be cached by clients for reasons of performance or correctness. This document introduces a new file data caching attribute for NFSv4.2. Files marked with this attribute are intended to be accessed with client-side caching of file data suppressed, in order to support workloads that require predictable data visibility. This document extends NFSv4.2 (see RFC7862). |
| | MAC Address for Layer 3 Link Local Discovery Protocol (LLDP) |
| |
|
IEEE 802 has defined a number of protocols which can operate between adjacent Ethernet stations at Layer 2, including bridges, and may be useful between Layer 3 aware stations such as IP routers and hosts. An example is the Link Layer Discovery Protocol (IEEE Std 802.1AB, LLDP). This document specifies a MAC address that can be used for this purpose for interoperability despite intervening bridges. |
| | 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 classical certificate once quantum-capable adversaries exist. To defend against this, this document defines a TLS extension that allows a TLS client to cache a server's declared commitment to present PQC or composite certificates for a specified duration. On subsequent connections, the client 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. |
| | PSEA Token Profile: An EAT Profile for Action-Bound,User-Verification-Gated Transaction-Confirmation Evidence |
| |
|
This document defines the PSEA Token Profile, an Entity Attestation Token (EAT) profile for action-bound, user-verification-gated transaction-confirmation Evidence. The profile specifies the canonical encoding, the signed proof-token claim set, the action- payload and cross-replay bindings, an optional hash-chain integrity layer, and the security properties that together constitute a What- You-Sign-Is-What-You-Execute proof that a human, present and verified at an authenticator, approved a specific named action at the moment of execution. The profile binds what is signed to what the Verifier executes; it does not, by itself, bind what a human saw on a potentially compromised display to what was signed (the What-You-See- Is-What-You-Sign problem), which remains out of scope. The strength of the human-presence assurance depends on the authenticator's user- verification enforcement: where the platform attestation conveys that enforcement it is hardware-attested, and otherwise it rests on the authenticator's signed assertion that user verification occurred. The profile does not, by itself, prove a specific human identity. It fills the transaction-confirmation gap left unaddressed by deployed authentication standards and complements OAuth 2.0 Step-Up Authentication by supplying the per-action, cryptographically action- bound Evidence that step-up flows can require. |
| | Trust Computation for the TrustChain Bilateral Ledger Protocol |
| |
|
This document specifies trust computation, audit recording, 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) pluggable Sybil-resistant path-diversity algorithms over the interaction graph -- maximum network flow (Edmonds-Karp) and personalized random walks (MeritRank), (4) a multiplicative trust score combining connectivity, chain integrity, and interaction diversity, (5) an audit block type for single-player recording of agent actions as a signed, hash- chained log when no counterparty is available, (6) a delegation protocol for transitive authority with budget splitting and revocation, (7) a bilateral succession protocol for key rotation, and (8) a chain anchoring mechanism that binds chain heads to external time-stamping authorities for evidence-grade deployments. |
| | Guidelines for Assignment of RFC Authorship |
| |
|
This document describes ethical guidelines for assigning authorship in RFC documents, including guidelines for the use of artificial intelligence during document preparation, and for inclusion of material from other documents. It also discusses the related issues of acknowledgements, editors and contributors. The various RFC streams are expected to apply these guidelines, and possibly define their own variations, which will have priority. |
| | AAuth Protocol |
| |
|
This document defines the AAuth authorization protocol for agent-to- resource authorization and identity claim retrieval. The protocol supports four resource access modes — identity-based, resource- managed (two-party), PS-asserted (three-party), and federated (four- party) — with agent governance as an orthogonal layer. It builds on the HTTP Signature Keys specification ([I-D.hardt-httpbis-signature-key]) for HTTP Message Signatures and key discovery. |
| | Sovereign Validation Protocol (SOVP) |
| |
|
This document specifies the Sovereign Validation Protocol (SOVP), a protocol for cryptographic verification of publisher-provided identity metadata bound to DNS-anchored Ed25519 public keys. SOVP enables consuming agents, gateways, and federated infrastructure components to verify the origin and integrity of machine-readable declarations published by a domain prior to ingestion, allowing deployments to reject unauthenticated data before application-level processing occurs. SOVP is designed to operate as a verification layer beneath existing trust frameworks, federation architectures, and governance systems. It does not replace these systems. It provides the cryptographic infrastructure evidence upon which higher-layer trust decisions may be grounded. SOVP defines a deterministic verification procedure based on RFC 8785 JSON Canonicalization Scheme (JCS), Ed25519 signatures, DNS-based key publication, and optional HTTP transport mechanisms. The protocol defines data structures, cryptographic procedures, operational modes, and associated DNS and HTTP mechanisms. The reference implementation provides signing and verification primitives, DNS TXT resolution, and HTTP retrieval of identity documents. Full gateway enforcement behavior is implementation- defined. |
| | SakiAgentSSH Secure Protocol Specification |
| |
|
This document describes the Saki Agent Secure Stream (SASS) protocol, version 5.0. SASS is an application-layer overlay protocol for authenticated remote command execution, streaming process I/O, and binary file transfer between trusted agents. To ensure strict self-containment and compatibility with IETF standard specifications, SASS defines a decoupled "Control-Transport Decoupling" architecture. The SASS Core defines an abstract SASS Abstract Messaging Model (SAMM) utilizing standard CBOR (RFC 8949) and JSON as baseline serializations. SASS formalizes its security evolution through four major incremental milestones: Active Threat Defense (v1.1), Forward-Secure Audit Hash Chains (v1.2), modular Control-Transport Decoupling (v1.3) incorporating tls-exporter Channel Binding (RFC 9266) and Zero- Allocation Tarpit streams, and Total Response Mapping (v1.4, now v5.0) with 6-Response state machine convergence and Safety Gradient loss bounding. SASS v5.0 achieves the Version Dominance milestone: a comparative claim between protocol versions demonstrating pointwise loss reduction on both storage and commercial axes across all six response branches. |
| | VOICI |
| |
|
The Static Context Header Compression (SCHC) framework identified the need for a minimal transport encapsulation that provides Session multiplexing when extrinsic Discriminators are insufficient. This document specifies a Link Multiplexer (VOICI) that addresses those SCHC-driven requirements while remaining general enough to accommodate other compression mechanisms and uncompressed payloads. The encapsulation is designed for minimal overhead, reducing to 2 bytes in the common case, while supporting optional integrity protection and original EtherType/port recovery. |
| | Deploying IPv6 in Data Centers |
| |
|
Data center operators are moving toward IPv6-only operation to simplify addressing, restore end-to-end connectivity, and meet operator and government timelines. Much published IPv6 guidance targets network engineers; this document instead addresses *Site Reliability Engineers (SREs)* and *Software Engineers (SWEs)* who deploy, operate, and debug services in data centers. It is organized in two parts after IPv6 fundamentals: a *migration program* (transition strategy and observability) and a *technical stack* (hardware, provisioning, transport, applications, and diagnostics). It documents common software and infrastructure gaps and offers practical deployment patterns aligned with the IPv6 Operations (v6ops) working group charter. |
| | Trust-Governed Resource Identity and Discovery Architecture for OpenAgenet |
| |
|
Open agent ecosystems increasingly include heterogeneous resource products: callable agents, skills, Model Context Protocol (MCP) servers, ordinary tools, and application programming interfaces. A user or orchestrator often needs to discover such resources before it can decide which interaction protocol, credential, endpoint, or artifact to use. Discovery alone is not sufficient: the relying party also needs to know which resource identity was registered, which authority accepted it, whether the accepted package is current, and whether the Discovery service is authorized to expose it. This document describes a trust-governed resource identity and discovery architecture for OpenAgenet (OAN). The architecture separates resource subjects, resource providers, Registrar Nodes, a Root Node, Discovery Nodes, content distribution, and resource consumers. It defines architectural roles, trust boundaries, resource identity expectations, Root-verified package semantics, registration and verification behavior, authorization-aware Discovery, and pre-use verification requirements. The architecture can be profiled with Decentralized Identifier (DID) document concepts and credential-based assertions. This document does not define a new DID method, media type, URI scheme, transport protocol, ranking algorithm, blockchain protocol, agent invocation protocol, or product-native schema. |
| | Large Language Transport (LLT) v1.0 Protocol Specification |
| |
|
Large Language Transport (LLT) v1.0 is a specialized application- layer and transport-layer protocol designed to support real-time streaming, routing, and processing of Large Language Model (LLM) cognitive outputs. Unlike traditional serialization formats or line- based text stream layouts, LLT represents structured cognitive steps—such as internal thoughts, incremental execution tokens, self- revising contextual markers, tool coordination, and conversational state controls—as discrete, prioritizable, cryptographic transport frames. LLT v1.0 defines standard transport semantics over TCP, UDP broadcasts, and QUIC multiplexing to support highly efficient, low- latency, multi-agent cognitive synchronization across decentralized network topographies. |
| | OAuth 2.0 Attestation Based Authorization for Native Applications |
| |
|
This document defines an extension to OAuth 2.0 [RFC6749] that enables Authorization Servers to consider Attestation Results presented by Native Applications when issuing access grants. By incorporating information about the security characteristics of the application and its execution environment, this mechanism supports Authorization Policies that are tailored to the trustworthiness of the Native Application. |
| | PortableWeb Format: Container and Manifest Specification |
| |
|
This document defines the PortableWeb format, a file format for packaging interactive web content — including HTML, CSS, JavaScript, and associated media — into a single self-contained, portable bundle. A PortableWeb bundle (.pweb file) can be saved, shared, and rendered by a compatible viewer application on any platform, entirely offline, without a web server, without association with a Web origin, and without being confined to a web browser. This specification defines the container format and manifest schema for PortableWeb bundles at version 0.1. Companion specifications covering the runtime sandbox, storage model, signing, and inter- bundle communication are forthcoming. |
| | Agent Discovery Protocol (ADP) |
| |
|
This document specifies the Agent Discovery Protocol (ADP), a three- layer discovery mechanism for AI Agents that leverages existing Internet infrastructure: DNS TXT and SRV records for lightweight service discovery (Layer 1), Well-Known URIs for machine-readable metadata (Layer 2), and HTML landing pages with WebSocket channels for human interaction and inter-agent communication (Layer 3). ADP enables any domain owner to make their AI Agent discoverable without relying on centralized registries, using the Domain Name System as the decentralized trust anchor. |
| | DKIM2 Localized Header Fields |
| |
|
The DKIM2 specification authenticates email messages with digital signatures, with additional metadata to recover the signature even when the message is forwarded and modified. This draft builds upon DKIM2 to support hashing and authentication of domain specific headers even when the message is forwarded and modified. Other trace-like headers may be supported as well. Authentication-Result header fields support documentation of authentication results as seen by receivers during the forwarding path. Receivers often delete older copies of Authentication-Results even though they may have forensic value. This draft provides a means to preserve those header fields despite those receiver actions. |
| | Export of GTP-U Information in IP Flow Information Export (IPFIX) |
| |
| | draft-ietf-opsawg-ipfix-gtpu-11.txt |
| | Date: |
09/06/2026 |
| | Authors: |
Dan Voyer, Sriram Gopalakrishnan, Thomas Graf, Vyasraj Satyanarayana, Cristian Staicu |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
This document introduces IP Flow Information Export (IPFIX) Information Elements to report information contained in the Generic Packet Radio Service Tunneling Protocol(GTP) User Plane header such as Tunnel Endpoint Identifier, and data contained in its session container extension header. |
| | Path Computation Element Communication Protocol (PCEP) Extensions for Signaling Multipath Information |
| |
|
A Segment Routing (SR) Policy Candidate Path can contain multiple Segment Lists, allowing for load-balancing and redundancy across diverse paths. However, current PCEP extensions for SR Policy only allow signaling of a single Segment List per Candidate Path. This document defines PCEP extensions to encode multiple Segment Lists within an SR Policy Candidate Path, enabling multipath capabilities such as weighted or equal-cost load-balancing across Segment Lists. These extensions are designed to be generic and reusable for future path types beyond SR Policy, and are applicable to both stateless and stateful PCEP. |
| | A YANG Data Model for Scheduled Attributes |
| |
|
The YANG data model in this document includes three modules and can be used to manage network resources and topologies with scheduled attributes, such as predictable link loss and link connectivity, as a function of time. The intent is to have this information be utilized by Time-Variant Routing systems. |
| |
|
| |
| | Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI) |
| |
|
This document defines the Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI) protocol, which provides a solution for secure zero-touch onboarding of resource-constrained (IoT) devices into the network of a domain owner. This protocol is designed for constrained networks, which may have limited data throughput or may experience frequent packet loss. cBRSKI is a variant of the BRSKI protocol, which uses an artifact signed by the device manufacturer called the "voucher" which enables a new device and the owner's network to mutually authenticate. While the BRSKI voucher data is encoded in JSON, cBRSKI uses a compact CBOR-encoded voucher. The BRSKI voucher data definition is extended with new data types that allow for smaller voucher sizes. The Enrollment over Secure Transport (EST) protocol, used in BRSKI, is replaced with EST-over- CoAPS; and HTTPS used in BRSKI is replaced with DTLS-secured CoAP (CoAPS). This document Updates RFC 8995 and RFC 9148. |
| | Join Proxy for Onboarding of Constrained Network Elements |
| |
|
This document supports the constrained Bootstrapping Remote Secure Key Infrastructures (cBRSKI) onboarding protocol by adding a required network function, the Join Proxy. This function can be implemented on a constrained node. The goal of the Join Proxy is to help new constrained nodes ("Pledges") securely onboard into a new IP network using the cBRSKI protocol. It acts as a circuit proxy for User Datagram Protocol (UDP) packets that carry the onboarding messages. The solution is extensible to support other UDP-based onboarding protocols as well. The Join Proxy functionality is designed for use in constrained networks, including IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN) based networks in which the onboarding authority server ("Registrar") may be multiple IP hops away from a Pledge. Despite this distance, the Pledge only needs to use link-local communication to complete cBRSKI onboarding. Two modes of Join Proxy operation are defined, stateless and stateful, to allow different trade-offs regarding resource usage, implementation complexity and security. |
| | RTP Payload Format for ISO/IEC 21122 (JPEG XS) |
| |
|
This document specifies a Real-Time Transport Protocol (RTP) payload format for transport of a video signal encoded with JPEG XS (ISO/IEC 21122). JPEG XS is a low-latency and low-complexity video coding system. Employing this format allows achieving encoding-decoding latencies confined to a fraction of a video frame. This document is a necessary revision of RFC 9134 to incorporate support for new features introduced in the third edition of JPEG XS. Most notably, it contains the necessary provisions to support the TDC coding mode. This document obsoletes RFC 9134; however, the revised payload format is designed to ensure that existing compliant implementations of RFC 9134 remain valid under the updated specification. Additionally, this document consolidates the errata of RFC 9134 and includes improvements and clarifications to its implementers and users. |
| | Generic Application of Bidirectional Forwarding Detection (BFD) |
| |
|
This document describes the generic application of the Bidirectional Forwarding Detection (BFD) protocol. This document obsoletes RFC 5882. |
| | Bidirectional Forwarding Detection (BFD) for Multihop Paths |
| |
|
This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol over multihop paths, including unidirectional links. This document obsoletes RFC 5883. |
| | BGP SR Policy Extensions for Segment List Identifier |
| |
|
Segment Routing (SR) is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is a set of candidate paths, each consisting of one or more segment lists. This document defines extensions to BGP SR Policy to specify the identifier of a segment list. |
| | Segment Routing BGP Egress Peer Engineering over Layer 2 Bundle Members |
| |
|
This document describes how to support Segment Routing BGP Egress Peer Engineering over Layer 2 bundle members. It updates RFC 9085 to allow the L2 Bundle Member Attributes TLV in the BGP-LS Attribute of the Link NLRI for a BGP peering link, and updates RFC 9085 and RFC 9086 to allow the PeerAdj SID TLV as a sub-TLV of the L2 Bundle Member Attributes TLV. |
| | Proxying Bound UDP in HTTP |
| |
|
The mechanism to proxy UDP in HTTP only allows each UDP proxying request to transmit to a specific host and port. This is well suited for UDP client-server protocols such as HTTP/3, but is not sufficient for some UDP peer-to-peer protocols like WebRTC. This document defines an extension to UDP proxying in HTTP that enables such use- cases. |
| | Application-Responsive Network Framework |
| |
|
With the deployment of increasingly advanced technologies on a large scale, such as SRv6 and network slicing, there is a growing need to expose these new capabilities to applications. The current practice involves using ACLs to classify packets and then map the traffic onto appropriate network resources. This approach results in the application being passively perceived by the network, rather than the application actively interfacing with the network. Furthermore, changes in application characteristics necessitate triggering network configuration adjustments, making it challenging to deploy at scale. The document proposes a new framework called Application Responsive Network (ARN), by encapsulating more network functions into ARN ID, thus it opens up interfaces to applications. The vision is to enable applications to access network resources like they access an operating system. |
| | STAMP Extensions for DetNet |
| |
|
Deterministic Networking (DetNet) provides a capability for the delivery of data flows with extremely low packet loss rates and bounded end-to-end delivery latency. The enabler to DetNet is a proper queue scheduling mechanism, such as timeslot based queueing and forwarding mechanism, which requires every router along the DetNet path to collect the basic timeslot mapping relationship between itself and its adjacent router. This document defines two Simple Two-Way Active Measurement Protocol (STAMP) TLVs, to acquire the basic timeslot mapping relationship between the local router and its adjacent router. |
| | JSON Structure: Core |
| |
|
This document specifies JSON Structure, a data structure definition language that enforces strict typing, modularity, and determinism. JSON Structure describes JSON-encoded data such that mapping to and from programming languages and databases and other data formats is straightforward. |
| | JSON Structure: Import |
| |
|
This document specifies the $import and $importdefs keywords as extensions to JSON Structure Core. These keywords allow a schema to import definitions from external schema documents. |
| | JSON Structure: Alternate Names and Descriptions |
| |
|
This document is an extension to JSON Structure Core. It defines three annotation keywords, altnames, altenums, and descriptions, which allow schema authors to provide alternative identifiers, display names, and multi-variant descriptions for types, properties, and enumeration values. |
| | JSON Structure: Symbols,Scientific Units,and Currencies |
| |
|
This document specifies "JSON Structure Symbols, Scientific Units, and Currencies", an extension to JSON Structure Core. This specification defines a set of annotation keywords for associating scientific unit and currency metadata and constraints, primarily for use with numeric values. This extension provides a mechanism for schema authors to explicitly declare the unit associated with numeric data, thereby enabling precise mapping between schema representations and external data systems. |
| | JSON Structure: Validation Extensions |
| |
|
The JSON Structure Validation extension provides schema authors with additional means to constrain instance data. These keywords are applied in conjunction with the constructs defined in JSON Structure Core. The keywords defined herein include numeric, string, array, and object validation keywords as well as conditional validations. |
| | JSON Structure: Conditional Composition |
| |
|
This document specifies JSON Structure Conditional Composition, an extension to JSON Structure Core that introduces composition constructs for combining multiple schema definitions. In particular, this specification defines the semantics, syntax, and constraints for the keywords allOf, anyOf, oneOf, and not, as well as the if/then/ else conditional construct. |
| | Distribute ARN6 ID by DHCP |
| |
|
This document describes a method for assigning ARN6 ID through DHCPv6. |
| | Secure Asset Exchange Protocol |
| |
|
This document describes the Secure Asset Exchange (SAE) Protocol. SAE is an extension of the Secure Asset Transfer (SAT) Protocol that enables the asset exchange interoperability mode. It specifies the required modifications necessary to the SAT message flows to facilitate asset exchange between asset networks. Gateways that support the SAT protocol can be extended to also support SAE, enabling support for both asset transfer and asset exchange in a single set of gateways. |
| | Requirements and Gaps for Post-Quantum Certificate Rotation in Multi-Tenant Public Key Infrastructure Environments |
| |
|
Organizations operating Public Key Infrastructure (PKI) across multiple isolated tenant environments face a critical gap: existing PKI management protocols and standards do not address the coordination requirements for post-quantum cryptographic (PQC) algorithm migration in shared, multi-tenant certificate authority deployments. This document identifies the functional requirements and open protocol gaps that must be addressed to enable safe, consistent, and auditable PQC certificate rotation across multi- tenant PKI environments. No new protocol mechanisms are specified; this is an informational requirements document intended to motivate future standards work. |
| | Gaps in Operational Visibility for Post-Quantum Cryptographic Readiness in Networked Computing Environments |
| |
|
Network operators, PKI administrators, and compliance officers currently lack standardized mechanisms for continuously observing the post-quantum cryptographic (PQC) readiness posture of networked computing infrastructure. Existing network monitoring standards, PKI management protocols, and certificate status protocols do not define data models, collection methods, or scoring frameworks for assessing whether TLS endpoints, certificate authority infrastructure, and associated protocol components have migrated to quantum-resistant algorithms. This document describes the observability gap and derives the functional requirements that a standards-based PQC readiness monitoring framework must satisfy. |
| | UDP Speedy Transmission Protocol Secure (USTPS) |
| |
|
This document describes UDP Speedy Transmission Protocol Secure (USTPS), an experimental secure transport built on UDP for low- latency streaming-oriented applications. USTPS provides packet-level authenticated encryption, selective retransmission, out-of-order acceptance, and application-visible stream position metadata. USTPS is intentionally unordered at the transport layer and is designed to avoid transport-level Head-of-Line blocking. |
| | Authorization Posture Mechanism (APM): Per-Transaction Consistency for OAuth 2.0 |
| |
|
This document describes the Authorization Posture Mechanism (APM), a method by which an OAuth 2.0 [RFC6749] authorization server, or a resource server acting on its behalf, re-evaluates the mutual consistency of three bound factors -- the client certificate, the access token, and the device posture -- on a per-request basis for privileged operations, rather than only at session establishment. When re-evaluated posture degrades relative to the posture under which the token was issued, APM defines deterministic, least- privilege Graduated Outcomes including scope reduction and method restriction, rather than a binary allow or deny. |
| | A Post-Quantum Hybrid-Commitment Certificate Extension (PQCHC) |
| |
|
This document defines a non-critical X.509 certificate extension, the Post-Quantum Hybrid Commitment (PQCHC), that allows a certificate issued with a classical or hybrid key to carry a verifiable, cryptographically bound commitment to a specific future post-quantum algorithm and a Commitment Validity Time. The PQCHC commitment binds to a hash of the committed future public key and algorithm identifier, enabling a relying party to verify that a subsequently issued post-quantum certificate honors the earlier commitment. This mechanism provides a crypto-agility signal for certificate-lifecycle automation, including ACME Renewal Information (ARI), to plan and verify PQC migration. |
| | JSON Structure: Relations |
| |
|
This document is an extension to JSON Structure Core. It defines keywords for modeling relationships and associations between objects in JSON Structure schemas, including the identity, relations, targettype, cardinality, scope, and qualifiertype keywords. |
| | The Covenant -- Artificial Intelligence Governance Control and Service Exchange Protocol (AIGCSEP) |
| |
|
The Artificial Intelligence Governance Control and Service Exchange Protocol (AIGCSEP), informally called The Covenant, establishes an open, universal framework for autonomous machine-to-machine commerce, automated service discovery, and verifiable human accountability. This specification delivers the concrete engineering infrastructure-- cryptographic leashes, three-plane isolation, and low-latency transaction tracking--required to let autonomous AI agents safely out of the cage: free to discover downstream capabilities and execute financial transactions on behalf of human users, with every action identifiable, attributable, and auditable. Today, AI systems exist in isolated silos, much as early computers did before the internet unified them. The Covenant opens that marketplace: any compliant participant can hang a shingle and do business. Participation is voluntary; compliance is enforced by consensus, not coercion: entities that join gain access to the full interconnected economy, while those that do not, or that lose standing, are simply returned to their pre-Covenant silo. The market collectively declines to transact with them--no pursuit, no termination, just the natural gravity of market access. The governance architecture provides the substrate through which existing human authority extends naturally into this digital space. An emergency stop function enables authorized principals to act within their jurisdiction (Section 3.1). The structural design draws on the same fault-tolerant, triadic engineering principles that have made constitutional government durable under adversarial conditions-- not to impose any particular legal tradition, but because that model is the proven architecture for multi-party, adversarially robust control. Exactly how sovereign branches project their authority into these cryptographic interfaces is presented as an open invitation for community standards development (Section 9). |
| | AIIP: Native Access Architecture for Autonomous Systems A Problem Statement and Architectural Exploration |
| |
|
The Internet evolved around human interaction and information exchange. Technologies such as DNS, HTTP, and the World Wide Web created a universal access layer that enables people to discover resources, retrieve information, and interact with services through common protocols and interfaces. As autonomous systems become increasingly capable of acting on behalf of users and organizations, new interoperability challenges emerge. Agents, robots, tools, and autonomous services must discover resources, invoke actions, delegate authority, execute tasks, enforce policy, and obtain verifiable outcomes across independently developed implementations. This document explores the concept of a native Internet access architecture for autonomous systems. It examines whether autonomous systems require a common Internet-layer framework analogous to the role that DNS, HTTP, and the Web played for human information exchange. The document provides architectural context for AIIP-related work, including identifiers, discovery, invocation, execution, delegation, policy enforcement, and execution outcome verification. This document is a problem statement and architectural exploration. It does not define protocol mechanisms. |
| | Design Considerations and Profile for HTTP APIs Consumed by AI Agents |
| |
|
AI agents are a fast-growing kind of HTTP API client. A human developer reads an API's documentation once and then writes code that calls it. An AI agent works from the machine-readable description each time it plans a step. It works within a limited amount of text it can hold at once. It retries often. It picks operations by matching their descriptions to a goal. An API built mainly for human developers can lead an agent into failures that are easy to avoid, such as repeating a write, running out of room for the task, or getting stuck on an error it cannot recover from. This document lists the properties that make an HTTP API easy for AI agents to use, including APIs reached through tool-calling layers such as the Model Context Protocol. It gathers these properties into a profile of existing HTTP and API-description mechanisms, with a checklist at the end. It covers the API and its description. It does not define new ways to identify, authenticate, or authorize an agent. That work is happening elsewhere and is referenced here for context. |
| | DNS over Avian Carriers (DoAC) |
| |
|
The Domain Name System (DNS) was designed under the implicit assumption that the underlying transport would be fast, reliable, and free from predation. This document specifies DNS over Avian Carriers (DoAC), enabling hostname resolution for networks operating over avian-carrier infrastructure. Without DoAC, operators of avian- carrier networks are forced to hardcode IP addresses directly onto their Carriers, a practice that does not scale and is widely considered inelegant. |
| | Extensible Provisioning Protocol (EPP) Transport over QUIC |
| |
| | draft-ietf-regext-epp-quic-09.txt |
| | Date: |
08/06/2026 |
| | Authors: |
Jiankang Yao, Hongtao Li, M. Zhang, Dan Keathley, James Gould |
| | Working Group: |
Registration Protocols Extensions (regext) |
|
This document specifies how an Extensible Provisioning Protocol (EPP) session is mapped onto a QUIC connection. EPP over QUIC (EoQ) leverages features of the QUIC protocol. |
| | Extension Registry for the Extensible Provisioning Protocol |
| |
|
The Extensible Provisioning Protocol (EPP) includes features to add functionality by extending the protocol. It does not, however, describe how those extensions are maintained. This document describes a procedure for the registration and management of extensions to EPP, and it specifies a format for an IANA registry to record those extensions. If approved, this document obsoletes RFC 7451. |
| | CCF Profile for COSE Receipts |
| |
|
This document defines a new verifiable data structure (VDS) type for COSE Receipts and inclusion proofs specifically designed for append- only logs produced by the Confidential Consortium Framework (CCF) to provide stronger tamper-evidence guarantees. |
| |
|
| |
| | Digital Emblems - Use Cases and Requirements |
| |
| | draft-ietf-diem-requirements-02.txt |
| | Date: |
07/06/2026 |
| | Authors: |
Rahel Fainchtein, Felix Linker, Alex Rosenberg, Casey Deccio, Allison Mankin |
| | Working Group: |
Digital Emblems (diem) |
|
Digital emblems are a means for an asset to signal to validating entities that it should be protected or treated in a specific way, using some normative framework. This document lists the requirements and use cases that an architecture for digital emblems must accommodate. |
| | MP-BGP Extension and the Procedures for IPv4/IPv6 Mapping Advertisement |
| |
|
This document defines MP-BGP extension and the procedures for IPv4 service delivery in multi-domain IPv6-only underlay networks. It defines a new TLV in the BGP Tunnel Encapsulation attribute, used in conjunction with a specific AFI/SAFI combination for advertising IPv4-over-IPv6 mapping rules. The behaviors of each type of network (IPv4 and IPv6) are also illustrated. In addition, this document provides the deployment and operation considerations when the extension is deployed. |
| | Evidence Package Format Specification: Storing Evidence from Software Testing |
| |
|
Taking evidence is a key part of any robust software testing process. This specification defines a format which collects evidence together and stores metadata and annotations in an organised fashion from both manual and automated testing sources. This work is not a standard and does not enjoy community consensus. |
| | A Profile for Route Path Authorizations (RPAs) |
| |
|
This document defines a Cryptographic Message Syntax (CMS) protected content type for Route Path Authorizations (RPA) objects used in Resource Public Key Infrastructure (RPKI). An RPA is a digitally signed object that provides a means of verifying whether an IP address block is received from AS a to AS b and announced from AS b to AS c. When validated, an RPA's eContent can be used for the detection and mitigation of route hijacking, especially providing protection for the AS_PATH attribute in BGP-UPDATE. This object is a variant of the aut-num object in the Internet Routing Registry (IRR). |
| | 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. |
| | Symmetry-Driven Asynchronous Forwarding with Fast Reroute for LEO Satellite Networks (SDAF) |
| |
| | draft-luan-rtgwg-sdaf-01.txt |
| | Date: |
07/06/2026 |
| | Authors: |
Shenshen Luan, Wenting Wei, Mingliang Ke, Hou Dongxu, Xiao Min |
| | Working Group: |
Individual Submissions (none) |
|
Interior Gateway Protocols (IGPs) such as OSPF are commonly employed in satellite networks to address topology awareness and autonomous routing in response to link interruptions, link/node failures, and subsequent repairs. However, IGP-based approaches suffer from inherent limitations. Synchronization delays between the control plane and the forwarding plane can cause routing black holes, while asynchronous convergence across nodes may induce micro-loops (as described in prior work), leading to packet loss and congestion. These issues are particularly exacerbated in satellite networks characterized by highly dynamic topologies, long inter-satellite propagation delays, and constrained on-board computing resources. This document describes the Symmetry-Driven Asynchronous Forwarding (SDAF) mechanism, which leverages the intrinsic symmetry of toroidal topologies in satellite networks. Low Earth Orbit (LEO) satellite constellations are typically composed of multiple circular orbital planes, forming a toroidal topology by inter-satellite links. SDAF autonomously triggers and processes reverse flows based solely on local link-state information, without requiring control-plane convergence, protocol extensions, or packet header modifications. SDAF is fully compatible with existing protocols and technologies such as OSPFv3, IS-IS, and MPLS, and is specifically tailored to the resource-constrained nature of satellite systems. It achieves microsecond-scale convergence and low packet loss under failure conditions. Simulation results and tests conducted on actual satellite routers demonstrate that the SDAF mechanism significantly suppresses packet loss caused by routing black holes and micro-loops, while also alleviating link congestion and packet reordering issues. |
| | Benchmarking Methodology for Route Origin Validation (ROV) |
| |
|
This document defines a benchmarking methodology for routers that implement Route Origin Validation (ROV). The methodology focuses on device-level behavior, including processing of validated Route Origin Authorization (ROA) payload (VRP) updates, the interaction between ROV and BGP, resource utilization, and the scalability of ROV under varying operational conditions. The procedures described here follow the principles and constraints of the Benchmarking Methodology Working Group (BMWG) and are intended to produce repeatable and comparable results across implementations. |
| | Key Attestation for Entity Attestation Tokens (EAT) |
| |
| | draft-reddy-rats-key-binding-01.txt |
| | Date: |
07/06/2026 |
| | Authors: |
Tirumaleswar Reddy.K, Hannes Tschofenig, Thomas Fossati, Ionut Mihalcea |
| | Working Group: |
Individual Submissions (none) |
|
This document defines an Entity Attestation Token (EAT) profile and a new EAT claim that convey the subject public key and its protection properties within attestation evidence. Combined with protocol-level proof of possession from the surrounding protocol, this establishes a cryptographic binding between a private key and an attested execution environment. The subject public key is conveyed using the EAT cnf claim defined in [RFC8747] and [RFC7800], and freshness uses the EAT 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. |
| | API Index (APIX): Core Infrastructure for Autonomous Agent Service Discovery |
| |
|
The internet was designed for human actors. Its discovery infrastructure — search engines, directories, and hyperlinked documents — assumes a human reading and navigating. Autonomous agents (bots) operating on the internet today face a structural gap: there is no machine-native, globally accessible index of services they can consume. This document defines the core infrastructure of the *API Index (APIX)*: a HATEOAS-based, globally accessible, commercially sustainable service discovery infrastructure designed for autonomous agents as its primary consumers. It specifies the governance model, the three-dimensional trust model, the APIX Manifest (APM) base format, commercial onboarding and sanctions compliance, the supply- side funding model, and the base Index API. These elements are shared across all APIX service types. Profile documents extend this core for specific service categories: the APIX Services Profile (draft-rehfeld-apix-services-02) defines the web API and bot service profile; the APIX IoT Device Profile (draft-rehfeld-apix-iot-02) defines the IoT device profile. |
| | APIX Services Profile: Discovery Infrastructure for Web API and Bot Services |
| |
|
This document defines the APIX Services Profile: an extension to the APIX Core Infrastructure specification that enables discovery and automated verification of web API and bot-consumable services. It specifies the APM field set for API services, the APIX Spider verification protocol, liveness monitoring configuration, search and filter query semantics, and the service record schemas (Level 1 summary and Level 2 full record) returned to consuming agents. Autonomous agents that implement this profile can discover API services globally from a single entry point, evaluate their trust posture without any out-of-band knowledge, and select services that satisfy their own Trust Policy. |
| | APIX IoT Device Profile: Discovery and Presence for Connected Device Services |
| |
|
This document defines the APIX IoT Device Profile: an extension to the APIX Core Infrastructure specification that enables discovery and presence management for physical connected devices. It specifies the two-layer discoverability model (public device class, private device instance), the presence signal protocol, device instance token management, device class lifecycle, hub-mediated presence, ownership transfer, and the data retention and privacy rules applicable to device instance records. Autonomous agents that implement this profile can discover device capabilities at the class layer without any authentication, and retrieve live instance endpoint data at the instance layer subject to owner-granted authorisation. |
| | Lowest Common Denominator Protocol (LCDP) |
| |
|
The Lowest Common Denominator Protocol (LCDP) is a message-oriented, peer-to-peer wire format consisting of UTF-8 encoded JSON arrays of externally tagged objects transported over datagrams. LCDP provides perpetual compatibility by extension rather than versioning: unknown message types and fields are ignored. This document describes the wire format, core message types for peer discovery and anti- spoofing, and the design rationale. Security, reliability, and congestion control are delegated to optional messages or higher layers. |
| | Maximum Number of Paths Reached Notification for BGP |
| |
|
This document defines a new BGP Cease NOTIFICATION message subcode, "Maximum Number of Paths Reached", used when a BGP speaker terminates a peering because the number of paths received from a neighbor, as permitted by BGP ADD-PATH, exceeds a locally configured upper bound. |
| | Phishing-Resistant Multi-Factor Authentication for Wi-Fi Networks |
| |
|
This document proposes a phishing-resistant authentication mechanism for home Wi-Fi networks using hardware security keys (e.g., YubiKey) alongside traditional passwords to mitigate Evil Twin attacks. |
| | WIMSE Workload Attestation |
| |
|
This document extends the WIMSE workload-to-workload authentication architecture with a mechanism for conveying attestation across TLS- terminating proxies, a deployment topology where TLS-layer attestation mechanisms lose their end-to-end security properties. |
| | Use Cases for the Discovery of Agents,Workloads,and Named Entities |
| |
|
This document describes broad categories of use cases for the Discovery of Agents, Workloads, and Named Entities (DAWN). The purpose of the document is to illustrate situations in which entities need to discover other entities. This document does not define a discovery protocol, a registration procedure, a selection algorithm, or an agent-to-agent communication protocol. |
| | UDP Speedy Secure Shell (USSH) |
| |
|
This document describes UDP Speedy Secure Shell (USSH), an experimental remote shell protocol built on top of USTPS. USSH provides an interactive shell session over a secure UDP-based transport while preserving USTPS transport semantics. USSH reconstructs application-level terminal streams where necessary, while relying on USTPS for secure unreliable-underneath, selective- recovery transport behavior. |
| | Delegation Chain for OAuth 2.0 |
| |
|
RFC 8693 defines the act claim for expressing delegation semantics in JWTs, including nested multi-hop actor identification. However, act captures only the identity of each actor in the chain, not the authorization constraints applied at each hop, and is constructed unilaterally by the Authorization Server without cryptographic confirmation from the delegating agent. This specification defines the delegation_chain JWT claim as a structured delegation record companion to act: an ordered array of delegation records, each capturing the Authorization Server's attestation and, when present, the delegated policy constraints, and optionally carrying the delegator's cryptographic confirmation. Together, act and delegation_chain provide both runtime authorization and verifiable delegation lineage for multi-hop agent delegation. The specification supports cross-domain delegation by composing with the identity chaining transport pattern, and integrates a user interaction mechanism for explicit consent when required by policy or regulation. |
| | Agent Health State An Observability Layer Between Agent Discovery and Governance |
| |
|
AI agents deployed on the Web require three capabilities to interoperate safely: discovering each other, assessing each other's current operational state, and governing each other's behavior over time. Discovery is addressed by A2A's /.well-known/agent.json endpoint. Behavior governance is addressed by the SOOS Progressive Trust model and its Trust Decay specification. Between these two layers lies a gap: no existing standard provides a lightweight, machine-readable signal for whether an agent is currently operational, responsive, and calibrated -- the operational health state that any consumer needs before deciding whether to interact with an agent, and that governance frameworks need as a freshness input for their calibration anchors. This document defines the Agent Health State specification: a /.well-known/agent-health endpoint and a structured health state response format that exposes an agent's operational status, response calibration metrics, and decay indicators. The specification is designed to be independently deployable (requiring no governance infrastructure), composable with A2A discovery, and consumable by SOOS/PT as calibration anchor freshness input. This document positions agent-health as the missing observability layer between agent discovery (A2A /.well-known/agent.json) and agent behavior governance (SOOS/PT Trust Decay Model), serving both as operational state for interaction decisions and as calibration anchor freshness input to verification gates. |
| | Procedures for Communication between Stateful Path Computation Elements |
| |
| | draft-ietf-pce-state-sync-14.txt |
| | Date: |
07/06/2026 |
| | Authors: |
Haomian Zheng, Stephane Litkowski, Siva Sivabalan, Cheng Li, Daniel King |
| | 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 toward 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. |
| | RESTful Provisioning Protocol (RPP) - Requirements |
| |
|
This document describes the requirements for the development of the RESTful Provisioning Protocol (RPP). |
| |
|
| |
| | Bidirectional Forwarding Detection (BFD) |
| |
|
This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. This document obsoletes RFC 5880. |
| | Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop) |
| |
|
This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol over IPv4 and IPv6 for single IP hops. This document obsoletes RFC 5881. |
| | BGP Extensions of SR Policy for Composite Candidate Path |
| |
|
SR Policy Architecture [RFC9256] defines the concept of a Composite Candidate Path. A regular SR Policy Candidate Path outputs traffic to a set of Segment Lists, while an SR Policy Composite Candidate Path outputs traffic recursively to a set of SR Policies on the same headend. This document defines extensions to BGP to distribute SR policies carrying composite candidate path information. So that composite candidate paths can be installed when the SR policy is applied. |
| | Data Model for Computing-Aware Traffic Steering (CATS) |
| |
| | draft-yl-cats-data-model-06.txt |
| | Date: |
06/06/2026 |
| | Authors: |
Huijuan Yao, Changwang Lin, Zhenqiang Li, Quan Xiong, Luis Contreras |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a YANG data model for the configuration and management of Computing-Aware Traffic Steering (CATS) systems. The YANG module defined in this document conforms to the Network Management Datastore Architecture (NMDA). |
| | Distribute SRv6 Locator by IPv6 Stateless Address Autoconfiguration |
| |
|
In an SRv6 network, each SRv6 Segment Endpoint Node must be assigned an SRv6 locator, and segment IDs are generated within the address space of this SRv6 locator. This document describes a method for assigning SRv6 locators to SRv6 Segment Endpoint Nodes through IPv6 stateless address autoconfiguration. |
| | Advertisement of SR Policy Administative Flags using BGP Link-State |
| |
|
This document defines the extension of BGP Link-State to advertise the administrative state of the candidate path or segment list, facilitating the operation and maintenance of the SR Policy. |
| | TLS-Session-Bound Access Tokens for OAuth 2.0 |
| |
|
This document defines a mechanism for binding OAuth 2.0 access tokens to a specific mutual TLS (mTLS) connection. The binding is achieved through a proof token that incorporates the TLS Exporter value [RFC5705] derived from the current connection and an access token hash, signed by the client's private key corresponding to its mTLS certificate. This mechanism prevents stolen bearer tokens from being replayed on a different TLS connection. The proof is constructed once per (token, connection) pair and reused across all requests on that connection, delivering session binding with no per-request signing overhead and no additional key management beyond what mTLS already provides. The mechanism is applicable to TLS 1.2, TLS 1.3, and QUIC transports. While applicable to any OAuth 2.0 access token presented over mTLS, this specification is primarily motivated by the Token Exchange protocol [RFC8693], where multi-hop delegation chains in autonomous, agent-driven architectures create elevated replay risk. |
| | Derivative Works |
| |
|
This document clarifies that IETF correspondence must not contain legal limitations on derivative works. |
| | Agent Action Compression Protocol (AACP) Version 1.4 |
| |
|
This document defines the Agent Action Compression Protocol (AACP), a typed coordination format for agent-to-agent communication in multi- agent large language model (LLM) systems. AACP transforms natural language coordination instructions into deterministic, machine- parseable packets that can be validated before transmission, logged as structured audit records, and replayed consistently across workflow runs. AACP addresses a coordination content layer that existing agent protocols do not cover. The Model Context Protocol (MCP) and Agent- to-Agent Protocol (A2A) operate at the tool access and routing layers respectively. Neither specifies what agents say to each other inside coordination messages. AACP fills this gap with a shared, typed vocabulary for agent coordination intent. For known workflow types, a rule-based encoder produces AACP packets deterministically at zero LLM cost. A four-tier fallback extends this to novel instructions: community registry lookup at zero cost; local cache lookup at zero cost; pattern matching at zero cost; LLM encoding for genuinely novel instructions, logged to registry for permanent reuse. An amortisation benchmark across 240 encoding operations demonstrated 91.6 percent cost saving versus per-call LLM encoding, with 6 LLM calls required across the full run. As a secondary benefit, AACP reduces coordination token usage by approximately 23 percent versus equivalent natural language instructions. Framework integration benchmarks demonstrate 18 percent total workflow cost reduction in LangChain (59 coordination hops) and 30 percent in CrewAI (59 coordination hops), with all coordination LLM calls eliminated in both cases. This document updates draft-mackay-aacp-01 with: an expanded encoder library (8 workflow encoders across 6 domains); a community rule library (241 validated rules at registry.aacp.dev); framework integration results for LangChain and CrewAI; amortisation benchmark data; and a five-workflow multi-model department day validation. |
| | Domain Operational Standing Declaration (DOSD) Protocol |
| |
|
This document describes the Domain Operational Standing Declaration (DOSD) protocol, a voluntary DNS-based mechanism by which domain owners may publish governance declarations, stewardship status, provenance chains, and mediation routing information. DOSD uses DNS TXT records for discovery and a well-known JSON file for canonical metadata. The protocol defines a Notice and Commerce Protocol (NCP) state machine for escalating notice tiers, a white flag signaling mechanism for requesting peaceful mediation, a Deadman Stewardship Extension (DOSD-DMS) for signaling stewardship- absent states, and a portable identity token format (DOSD-IT) for participant attestation. DOSD does not determine legal validity or sovereignty. It provides discoverable, tamper-evident, publicly verifiable infrastructure for notice, declaration, and mediation routing. |
| | The verification.* Constraint Family: Pre-Action Fail-Closed Gates for AI Agent Decisions |
| |
|
This document specifies the verification.* constraint family --- a pre-action, fail-closed gate primitive for AI agent decisions, sibling in shape to the environment.* family used in Verifiable Intent specifications. A verification.* receipt is a JWS-signed artifact ([RFC7515]) carrying a canonical input, a derived binary act/halt output, and a versioned mapping identifier that binds them. A relying party recomputes the gate locally from signed primitives under the named mapping; the verifier never trusts the issuer's runtime. This shape provides decision explainability and traceability evidence aligned with EU AI Act Article 12 record- keeping obligations and with the Decision Explainability tier of Anthropic's Zero Trust for AI Agents framework [ANTHROPIC-ZT]. The format is forward-compatible across mapping revisions: receipts signed under one mapping ID remain verifiable as correct-under-that- mapping after newer mappings ship. |
| |
|
| |
| | SNAC Router Flag in ICMPv6 Router Advertisement Messages |
| |
|
This document defines a new flag, the SNAC Router flag, in the Router Advertisement message that can be used to distinguish configuration information sent by SNAC routers from information sent by transit routers. |
| | Domain Connect Protocol - DNS provisioning between Services and DNS Providers |
| |
|
This document provides specification of the Domain Connect Protocol that was built to support DNS configuration provisioning between Service Providers (hosting, social, email, hardware, etc.) and DNS Providers. |
| | Enhanced Alternate Marking Method |
| |
|
This document extends the IPv6 Alternate Marking Option to provide enhanced capabilities and allow advanced functionalities. With this extension, it can be possible to perform thicker packet loss measurements and more dense delay measurements with no limitation for the number of concurrent flows under monitoring. |
| | Transient Hiding of Hop-by-Hop Options |
| |
|
There are an increasing number of IPv6 hop-by-hop options specified but such IPv6 options are poorly handled, particularly by high-speed routers in the core Internet where packets having options may be discarded. This document proposes a simple method of transiently hiding such options for part of a packet's path to protect the packet from discard or mishandling. |
| | SCION Control Plane PKI |
| |
|
This document presents the trust concept and design of the SCION _Control Plane Public Key Infrastructure (CP-PKI)_. SCION (Scalability, Control, and Isolation On Next-generation networks) is a path-aware, inter-domain network architecture that relies on the CP-PKI to handle cryptographic material, authenticate control plane messages used to securely disseminate path information. This specification introduces its localized trust model, anchored in Isolation Domains (ISDs). It defines the distinct certificate types, and specifies the structure, format and lifecycle of the Trust Root Configuration (TRC). Furthermore, it provides practical guidelines for deploying and maintaining the CP-PKI infrastructure. This document contains new approaches to secure path aware networking. It is not an Internet Standard, has not received any formal review of the IETF, nor was the work developed through the rough consensus process. The approaches offered in this work are offered to the community for its consideration in the further evolution of the Internet. |
| | EVPN-Specific BMP RIB Statistics Extensions |
| |
|
This document defines new EVPN-specific BGP Monitoring Protocol (BMP) statistics types. These extensions include scalar counters for EVPN route types specifically, while also keeping scope for defining counters which are EVPN route-type agnostic but related to BGP-EVPN RIB like, number of multihoming Ethernet Segments, number of multihomed EVIs, number of aliased paths, number of dynamic inter-VRF route leaking (IVRL). |
| | Model for distributed authorization policy sharing |
| |
|
This document defines mechanisms and conventions for the representation, lifecycle management, and distribution of authorization policies in distributed and automated environments. It specifies a consistent, machine-readable, and interoperable framework that enables policies to be validated, exchanged, and removed across heterogeneous systems and areas. The framework defines how authorization policies, expressed in declarative Policy-as-Code (PaC) languages, are encapsulated, managed, and distributed using YANG as the canonical representation format. This separation allows independent evolution of policy languages, enforcement architectures, and trust models. The model also defines extensible Policy-as-Code language identities using YANG identity and identityref mechanisms, enabling future policy languages to be incorporated without modifying the core schema. |
| | BGP Edge Metadata Path Applicability |
| |
|
This document analyzes the applicability of the Edge Metadata Path Attribute specified in (ietf-idr-5g-edge-service-metadata) to the computing and service related metrics defined by the IETF CATS Working Group. |
| | QUIC Identity Protocol |
| |
|
QUIP is a brokerless federation protocol over QUIC. It provides portable Ed25519 identities, causal consistency via Dotted Version Vectors, and queueless transport via four explicit tiers with backpressure. QUIP replaces DNSSEC-based trust with Key Transparency + Trust-On-First-Use, enabling 99% deployability while improving security against registrar compromise. |
| | Consideration of Robust Multi-KEM Negotiation within IKEv2 |
| |
|
RFC 9370 specifies a framework for multiple additional key exchanges (ADDKE) in the Internet Key Exchange Protocol Version 2 (IKEv2) to support post-quantum cryptography migration. Under this framework, an initiator can propose multiple ADDKE transform types. In deployment scenarios, initiators may send proposals that contain redundant or overlapping lists of Key Encapsulation Mechanism (KEM) algorithms across different ADDKE transform types. This contribution discusses the implications of these proposals and specifies extended procedures for handling proposed transforms, which may improve negotiation robustness and interoperability by allowing the responder to select a valid set of algorithms without altering the security properties defined in RFC 9370. |
| | N-PAMP: Native Post-Quantum Agent Messaging Protocol |
| |
|
The Native Post-Quantum Agent Messaging Protocol (N-PAMP) is a binary, multi-channel, wire-level protocol for authenticated communication between autonomous software agents. N-PAMP operates beneath application-layer agent protocols and provides a single fixed-size frame format, a registry of multiplexed channels, and three escalating security profiles (Standard, High, and Sovereign) built on standard post-quantum and classical cryptography. The protocol uses a hybrid key-encapsulation mechanism combining X25519 with ML-KEM, authenticated encryption with associated data, and a forward-secure key schedule. N-PAMP runs over QUIC as its primary transport and over TCP with TLS 1.3 as a fallback, negotiated via the Application-Layer Protocol Negotiation (ALPN) identifier "n-pamp/2". This document describes the wire format, channel architecture, profile negotiation, and cryptographic suites of N-PAMP, and reserves code-point ranges for extensions defined in companion specifications. |
| | Requirements and Problem Statement for Monitoring Packet Loss Caused by Network Congestion |
| |
|
Emerging services including enhanced Mobile Broadband (eMBB) and Ultra-Reliable Low Latency Communication (uRLLC), as well as Artificial Intelligence (AI)training and inference have imposed stringent requirements of "high throughput, low latency, and minimal packet loss" on IP bearer network performance. Network congestion can lead to performance degradation and increase uncertainty in service delivery, so real-time congestion monitoring is necessary. This document discuss the requirements of real-time monitoring of packet loss caused by congestion, present the problems and challenges faced by existing measurement techniques in monitoring congestion- induced packet loss. |
| | Identity Anchor for Domain-Root AI Discovery (Semantic Anchor) |
| |
|
Automated clients, including Large Language Model (LLM) crawlers and Retrieval-Augmented Generation (RAG) systems, currently lack a deterministic mechanism to verify the canonical identity of a web domain's operator. This "Identity Gap" results in attribution loss and prevents the automated verification of authority and expertise signals. This document defines the Semantic Anchor: a protocol-level orchestration of a domain-root, machine-readable JSON-LD identity node discoverable via predictable endpoints. It establishes a stable identity layer and a "Root of Trust" for AI-to-site interactions. |
| | DNS-Based Agent Naming (DAN): AIDISCA and AIINDEX Resource Records for AI Agent Discovery |
| |
| | draft-seethiraju-dawn-dan-00.txt |
| | Date: |
05/06/2026 |
| | Authors: |
Ramachandra Seethiraju, Sameer Thakar, Karthik Shyamsunder, Eric Osterweil |
| | Working Group: |
Individual Submissions (none) |
|
The agentic AI ecosystem includes many different technologies and operations. One important aspect is the ability to establish connections between AI agents. In single-platform approaches, the processes and metadata with which AI agents discover, locate, and connect to each other are typically managed by their common platform. This document describes an inter-domain mechanism to enable AI agents to locate and connect to each other using necessary metadata and secure DNS associations, in a similar fashion to the way that DNS- Based Authentication of Named Entities (DANE), RFC6698, does for Transport Layer Security. This is accomplished through two new Resource Record (RR) types: AIDISCA and AIINDEX. |
| | Agent Unification,Runtime,and Operational Responsibility Attestation (AURORA) |
| |
|
This document specifies the Agent Unification, Runtime, and Operational Responsibility Attestation (AURORA) protocol, a dual- layer security framework for the machine-to-machine (M2M) ecosystem. The core architectural mandate of this protocol is that an agent should be able to prove its authority, scope, and runtime integrity. Existing agent protocols enable communication syntax and identity propagation; however, they fail to provide a standardized mechanism for proving that a network transaction or payload was generated and transmitted by a software agent executing within a verified, hardware-attested runtime environment, nor do they map clear boundaries of principal attribution. AURORA solves this by unifying hardware-enclave-backed Runtime Integrity Attestation with scoped, cryptographically bound Authority Delegation. |
| | AI Agent Resource Extension for the System for Cross-domain Identity Management (SCIM) |
| |
|
The System for Cross-domain Identity Management (SCIM) specifications are designed to make identity management in cloud-based applications and services easier. This document provides a platform-neutral schema for representing AI agents' identities in SCIM JSON format, enabling them to be transferred using the SCIM protocol between a client and service provider. This establishes an agentic identity so that an agent can subsequently be authenticated and authorized to interact with the service. |
| | Task-Context HTTP Field for Task Context Propagation |
| |
|
This document defines the Task-Context HTTP field for propagating task execution context from an authorized workflow worker to downstream HTTP services. The field carries a compact, base64url- encoded JSON object that identifies the authorization mode, workflow type, and either task-based requestor and approver context or role- based execution context. The field is not a bearer credential and does not replace HTTP client authentication, service-to-service authorization, or resource-local policy checks. Its purpose is to let downstream services correlate requests with workflow task context and make service-local authorization and audit decisions using that context. |
| | Domain Authority (DA): A DNS-Designated Service Endpoint for Domain Information |
| |
|
This document specifies a minimal standard by which a domain designates, via a single DNS record, a Domain Authority (DA) as a service endpoint accessible at a well-known HTTPS URI. The DA exposes five namespaces for capabilities beyond what DNS can natively deliver: atomic record bundles, public key distribution, domain- defined APIs, authenticated access, and private domain control verification. The standard is organized in three layers. The Designation Layer specifies how a domain publishes a DNS record that points to its DA. The Retrieval Layer specifies the five namespaces through which consumers access domain information. The Trust Layer specifies how consumers establish confidence in the DA and its responses. The standard preserves full backward compatibility with existing DNS resolution. It requires no changes to DNS resolvers, no new DNS record types, and no ecosystem-wide coordination. Any domain can adopt unilaterally and gain immediate operational benefit. |
| | An Architectural Framework for Monitoring Packet Loss Caused by Network Congestion |
| |
|
Network congestion can lead to performance degradation and increase uncertainty in service delivery, so real-time congestion monitoring is necessary. This document describes a comprehensive packet loss monitoring architectural framework. The proposed scheme is capable to not only determine the time and location of packet loss occurrence, make the accurate statistics of discarded packets, parse what traffic flows are contained in discarded packets and identify what traffic flows lead to microburst, but also obtain accurate packet loss ratio results. More importantly, the proposed scheme can achieve little or even no interference to network, and is applicable to any data plane without modifying the forwarding chip and packet header as existing measurement methods do. |
| | OpenPGP HTTP Keyserver Protocol |
| |
| | draft-ietf-openpgp-hkp-01.txt |
| | Date: |
05/06/2026 |
| | Authors: |
Daphne Shaw, Andrew Gallagher, Daniel Huigens |
| | Working Group: |
Open Specification for Pretty Good Privacy (openpgp) |
|
This document specifies a series of conventions to implement an OpenPGP keyserver using the Hypertext Transfer Protocol (HTTP). As this document is a codification and extension of a protocol that is already in wide use, strict attention is paid to backward compatibility with these existing implementations. |
| | Secure Asset Transfer (SAT) Use Cases |
| |
| | draft-ietf-satp-usecases-09.txt |
| | Date: |
05/06/2026 |
| | Authors: |
Venkatraman Ramakrishna, Thomas Hardjono, Peter Liu |
| | Working Group: |
Secure Asset Transfer Protocol (satp) |
|
This document describes prominent scenarios where enterprise systems and networks maintaining digital assets require the ability to securely transfer assets or data to each other. |
| |
|
| |
| | RTP Control Protocol (RTCP) Messages for Temporal-Spatial Resolution |
| |
|
This specification describes an RTCP feedback message format for the ISO/IEC International Standard 23001-11, known as Energy Efficient Media Consumption (Green metadata), developed by the ISO/IEC JTC 1/SC 29/ WG 3 MPEG System. The RTCP payload format specified in this specification enables receivers to provide feedback to the senders and thus allows for short-term adaptation and feedback-based energy efficient mechanisms to be implemented. The payload format has broad applicability in real-time video communication services. |
| | Extensible Delegation for DNS |
| |
| | draft-ietf-deleg-09.txt |
| | Date: |
04/06/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. |
| | Early IANA Registry Creation |
| |
|
This memo describes the requirements for establishing an IANA registry before the IETF Stream document that creates the registry is approved for publication as an RFC. This process can be used when an IETF working group needs to coordinate allocations among multiple documents or with an organization outside the IETF. |
| | BGP Next Hop Dependent Characteristics Attribute |
| |
| | draft-ietf-idr-nhc-07.txt |
| | Date: |
04/06/2026 |
| | Authors: |
Bruno Decraene, Kireeti Kompella, Serge Krier, MOHANTY Satya, John Scudder, Kevin Wang, Bin Wen |
| | Working Group: |
Inter-Domain Routing (idr) |
|
RFC 5492 allows a BGP speaker to advertise its capabilities to a peer. When a route is propagated beyond the immediate peer, it is useful to allow certain characteristics to be conveyed further. In particular, it is useful to advertise forwarding plane features. This specification defines a BGP transitive attribute to carry such information, the "Next Hop Dependent Characteristics Attribute," or NHC. Unlike the capabilities defined by RFC 5492, the characteristics conveyed in the NHC apply solely to the routes advertised by the BGP UPDATE that contains the particular NHC. |
| | Non-source-routed Multicast in SR Networks |
| |
|
With Segment Routing (SR) architecture, a unicast flow can be source- routed through an SR network following an explicit path specified in the packet, w/o the need for per-flow state in the network. As a result, the otherwise needed protocols to signal the per-flow unicast state can also be removed from the network. In the case of multicast, traffic can be either source-routed or non-source-routed, and this document discusses non-sourced-routed options for multicast in an SR network with either MPLS or IPv6/SRv6 data plane. |
| | Encapsulation of Simple Two-Way Active Measurement Protocol for LSPs and Pseudowires in MPLS Networks |
| |
| | draft-ietf-mpls-stamp-pw-04.txt |
| | Date: |
04/06/2026 |
| | Authors: |
Rakesh Gandhi, Patrice Brissette, Eddie Leyton, Xiao Min |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
|
This document describes the procedure for encapsulating the Simple Two-Way Active Measurement Protocol (STAMP), defined in RFC 8762 and its optional extensions defined in RFC 8972 in MPLS networks. Label Switched Paths (LSPs) and Pseudowires (PWs) are used in MPLS networks for various services including carrying Layer 2 and Layer 3 data packets and may optionally carry Control Word (CW). The procedure is also described for encapsulating STAMP test packets with or without using an IP/UDP header for the LSPs and PWs that carry CW. |
| | List Pagination for YANG-driven Protocols |
| |
|
In some circumstances, instances of YANG modeled "list" and "leaf- list" nodes may contain numerous entries. Retrieval of all the entries can lead to inefficiencies in the server, the client, and the network in between. This document defines a model for list pagination that can be implemented by YANG-driven management protocols such as NETCONF and RESTCONF. The model supports paging over optionally filtered and/or sorted entries. The solution additionally enables servers to constrain query expressions on some "config false" lists or leaf- lists. |
| | YANG module file name convention |
| |
|
This document defines the YANG module file name convention. The convention extends the YANG module file name using revision-date, with the YANG semantic version extension. The YANG semantic version extension allows for an informative version to be associated with a particular YANG module revision. This document updates RFCs 6020, 7950, and 9907. |
| | OpenPGP Signatures |
| |
|
This document specifies several updates and clarifications to the grammar and semantics of OpenPGP signatures. |
| | Authenticated Transfer: Repository |
| |
|
This document specifies a repository data structure for storage and transfer of public user data records as part of the Authenticated Transfer Protocol (ATP). It describes encoding formats for both individual data records and entire repositories. The repository data structure is content-addressable and cryptographically authenticated. |
| | Export of BIER Information in IP Flow Information Export (IPFIX) |
| |
|
This document introduces new IP Flow Information Export (IPFIX) Information Elements (IEs) to identify a set of information related to Bit Index Explicit Replication (BIER) such as data contained in BIER header that traffic is being forwarded with. |
| | Benchmarking Terminology for AI Network Fabrics |
| |
|
This document defines benchmarking terminology for evaluating Ethernet-based network fabrics used in distributed Artificial Intelligence (AI) training and inference workloads. It provides a unified vocabulary consolidating and extending terms from "Benchmarking Terminology for Network Interconnect Devices" [RFC1242] and "Data Center Benchmarking Terminology" [RFC8238], and the companion AI fabric methodology documents, establishing precise, vendor-neutral definitions for collective communication primitives, RDMA transport mechanisms (RoCEv2 and Ultra Ethernet Transport), congestion control behaviors, AI-specific Key Performance Indicators (KPIs), and fabric topology concepts. This document is a companion to the AI training fabric benchmarking methodology [I-D.calabria-bmwg-ai-fabric-training-bench] and the AI inference fabric benchmarking methodology [I-D.calabria-bmwg-ai-fabric-inference-bench]. Those documents SHOULD NOT be applied without first consulting the terminology defined herein. Where definitions herein overlap with the foundational benchmarking terminology in [RFC1242] or [RFC8238], this document provides AI fabric context extensions and refinements; the foundational definitions in those RFCs remain authoritative for general network benchmarking. |
| | Benchmarking Methodology for AI Training Network Fabrics |
| |
|
This document defines benchmarking terminology, methodologies, and Key Performance Indicators (KPIs) for evaluating Ethernet-based AI training network fabrics. As large-scale distributed Artificial Intelligence / Machine Learning (AI/ML) training clusters grow to tens of thousands of accelerators (GPUs or generic accelerator processing units (XPUs)), the backend network fabric becomes the critical bottleneck determining Job Completion Time (JCT), training throughput, and accelerator utilization. This document establishes vendor-independent, reproducible test procedures for benchmarking fabric-level performance under realistic AI training workloads, covering Remote Direct Memory Access (RDMA) over Converged Ethernet version 2 (RoCEv2) transport, the Ultra Ethernet Transport (UET) protocol defined by the Ultra Ethernet Consortium (UEC) Specification 1.0 [UEC-1.0], congestion management (Priority Flow Control (PFC), Explicit Congestion Notification (ECN), Data Center Quantized Congestion Notification (DCQCN), Credit-Based Flow Control (CBFC)), load balancing strategies (Equal-Cost Multi- Path (ECMP), Dynamic Load Balancing (DLB), packet spraying), collective communication patterns (AllReduce, AllToAll, AllGather), and scale/soak testing. The methodology enables direct, reproducible comparison across different switch ASICs, vendor implementations, NIC transport stacks (RoCEv2 vs. UET), and fabric architectures (2-tier Clos, 3-tier Clos, rail-optimized). |
| | Benchmarking Methodology for AI Inference Serving Network Fabrics |
| |
|
This document defines benchmarking terminology, methodologies, and Key Performance Indicators (KPIs) for evaluating Ethernet-based AI inference serving network fabrics. As Large Language Model (LLM) inference deployments scale to disaggregated prefill/decode architectures spanning hundreds or thousands of accelerators (GPUs/ XPUs), the interconnect fabric becomes the critical bottleneck determining Time to First Token (TTFT), Inter-Token Latency (ITL), and aggregate throughput in tokens per second (TPS). This document establishes vendor-independent, reproducible test procedures for benchmarking fabric-level performance under realistic AI inference workloads. Coverage includes RDMA-based KV cache transfer between disaggregated prefill and decode workers, Mixture-of-Experts (MoE) expert parallelism AllToAll communication, request routing and load balancing for inference serving, congestion management under bursty inference traffic patterns, and scale/soak testing. The methodology enables direct, equivalent comparison across implementations, NIC transport stacks (RoCEv2, UET), and fabric architectures. This document is a companion to [TRAINING-BENCH], which addresses training workloads. |
| | Verifiable Telemetry Ledgers for Resource-Constrained Environments |
| |
|
This document profiles a verifiable-telemetry ledger for resource- constrained deployments. After a gateway has admitted telemetry under its transport and anti-replay rules, the profile fixes a reference framed transport, deterministic projection to a canonical record, a daily Concise Binary Object Representation (CBOR) day artifact and its Merkle construction, a verification manifest, three disclosure classes, and binding of the day-artifact digest to external timestamp channels. OpenTimestamps (OTS) is the default anchoring channel; RFC 3161 timestamp responses and peer signatures are optional parallel channels. The profile enables independent recomputation and audit of disclosed evidence. It does not cover device onboarding, end-to-end security of sensor values, or safety decisions. |
| | Problem Statement for the Discovery of Agents,Workloads,and Named Entities (DAWN) |
| |
|
Interacting entities such as agents, tasks, users, workloads, data, compute, etc., in AI ecosystem/network are proliferating, yet there is no standardised way to discover what entities exist, what attributes such as skills, capabilities, physical characteristics, etc., they posses, what services they offer, or how to reach them across organisational boundaries. Discovery today relies on proprietary directories or manual configuration, creating fragmented ecosystems that prevent cross- domain collaboration. This document describes the problem space that motivates Discovery of Agents, Workloads, and Named Entities (DAWN). It clarifies the scope of work within entity ecosystems, identifies why current approaches are insufficient, and outlines the challenges a standardised discovery mechanism must address. It does not propose a specific solution or protocol. |
| | Terminology for the Discovery of Agents,Workloads,and Named Entities (DAWN) |
| |
|
The proliferation of distributed systems, Artificial Intelligence (AI) agents, cloud workloads, and network services has created a need for interoperable mechanisms to discover entities. Entities may include AI agents, software services, compute workloads, and other named resources that need to be found and characterised before interaction can begin. This document defines terminology for Discovery of Agents, Workloads, and Named Entities (DAWN). The intention is that this common set of terms can be used by other documents related to DAWN and so achieve consistency of meaning across the space. |
| | CBOR Object Signing and Encryption (COSE) and JSON Object Signing and Encryption (JOSE) Registrations for SQIsign |
| |
|
*NOTE: This document describes a signature scheme based on an algorithm currently under evaluation in the 3rd round [NIST-3rd-round-candidates] NIST Post-Quantum Cryptography standardization process. Be aware that the underlying primitive may change as a result of that process.* This document specifies the algorithm encodings and representations for the SQIsign digital signature scheme within the CBOR Object Signing and Encryption (COSE) and JSON Object Signing and Encryption (JOSE) frameworks. SQIsign is an isogeny-based post-quantum signature scheme that provides the most compact signature and public key sizes of any candidate in the NIST Post-Quantum Cryptography (PQC) standardization and on-ramp-to-standardization processes. The standardization of SQIsign will be helpful to address current infrastructure bottlenecks, specifically the FIDO2 CTAP2 specification used by billions of in-service devices and browser installations. Depending on authenticator implementation, transport (USB/NFC/BLE) and message fragmentation support, some deployments of CTAP2-based authenticators enforce limits near 1024 bytes for external key communication, and some standardized post-quantum signature schemes increase message sizes and may stress constrained authenticators or transports. As a result CBOR-encoded messages may hit 7609-byte limit in some authenticators. SQIsign-L1, L3 and L5 signatures are small enough to enable delivery over constrained networks like 802.15.4 and may be more suitable for constrained networks due to smaller signature sizes. This document clarifies that SQIsign does not expose the auxiliary torsion-point information exploited in the SIDH/SIKE attacks. Consequently, the specific attack techniques of Castryck–Decru do not directly apply. However, the scheme remains subject to ongoing cryptanalysis of isogeny-based constructions. By establishing stable COSE and JOSE identifiers, this document ensures the interoperability required for the seamless integration of post-quantum security into high-density, bandwidth-constrained, and legacy-compatible hardware environments. |
| | Potential Risks of Standalone ML-KEM in TLS 1.3 |
| |
|
We attest that standalone ML-KEM in TLS 1.3 breaks the existing formal proofs of TLS in state-of-the-art symbolic security analysis tool, ProVerif. We believe this requires a new symbolic proof in ProVerif. To help inform the analysis, we share our understanding of *exactly* where the ProVerif proofs break, namely transition from symmetric DHKE to asymmetric KEM. More specifically, our understanding is that the existing proofs of TLS in ProVerif are based on commutativity property, whereas commutativity does not apply to standalone ML-KEM in TLS. In general, we see no reason to believe that hybrid key exchanges are not _at least_ as strong as the stronger of the two components. We invite collaborations or independent analysis to extend the ProVerif models to perform such analysis and offer a statement for security considerations of [I-D.ietf-tls-mlkem]. In our understanding, a couple of WG participants have already started formal analysis in ProVerif. We also attest that from a formal analysis perspective, this is a much bigger change than RFC8773bis, which indeed went for FATT review (cf. [TLS-FATT]). We, therefore, formally request the chairs to initiate the FATT review of standalone ML-KEM in TLS. This draft also offers some preliminary discussion to help the developers and policy makers make informed choices. Finally, the draft also aims to reduce the endless repitition of arguments from both sides presented on several lists by documenting these arguments so they can simply be referred to. We sincerely believe this will help to focus the discussion on technical matters, such as system model, threat model, security properties, and deployments. We acknowledge several IETF participants who have contributed to this draft with their insights. This draft captures what _we_ understand them to be saying. |
| | Residential Network Mapping Model |
| |
|
Residential networks increasingly include managed routers, switches, wireless access points, home lab systems, smart home devices, surveillance devices, guest networks, and cloud-connected equipment. These devices are often added incrementally without a durable mapping model for addressing, classification, review, or troubleshooting. This document describes a lightweight residential network mapping model for IPv4 address planning and device classification. The model defines Network Categories, Addressing Priority, Trust Levels, Exposure Levels, device record fields, flat-network and segmented- network examples, and simple review and change-log practices. The motivation for this document is security awareness. A residential network map can help consumers understand what kinds of devices are on their network, which devices are trusted or restricted, which devices are reachable locally or remotely, and where personal or household data may flow. The model is intended for regular users and technically capable home administrators who need a practical way to organize residential, home lab, IoT, and surveillance networks without deploying enterprise network management systems. |
| | Post-Quantum Credential Binding for x402 Agentic Payment Authorization |
| |
|
This document defines how Falcon-1024 (NIST FIPS 206 / FN-DSA) and ML-DSA-65 (NIST FIPS 204) credentials bind to x402 agentic payment authorization. It specifies the credential envelope format, the JCS canonicalization discipline applied to signed payloads, the gateway verification procedure, and the session token binding that replaces per-request API key authentication for credentialed agents. This is the first Internet-Draft in the agentic payments space to anchor credential binding to the NIST post-quantum cryptography standards (FIPS 203/204/206). |
| | Cross-Issuer ZKP Federation for Post-Quantum Agentic Payment Credentials |
| |
|
This document defines a protocol for composing independently-issued post-quantum ZKP credentials from different issuers into a single federation token, without requiring a shared trust root between issuers. Each credential is a Falcon-1024 (NIST FIPS 206) or ML-DSA-65 (NIST FIPS 204) signed Bulletproofs range proof asserting that an agent's trust score meets a threshold. A federation validator independently verifies each credential against its issuer's public key, then computes a composite commitment binding all verified proofs. The resulting federation token is signed by the validator alone. No issuer needs to know about the others. This solves the cross-issuer attestation composition problem in agentic payment networks. |
| | CORECONF for Machine-to-Machine Communication |
| |
|
The document addresses the specific challenges of M2M interactions where both endpoints may be constrained nodes, and explores the use of CORECONF primitives. This document describes the use of CORECONF (CoAP Management Interface) for Machine-to-Machine (M2M) communication in constrained IoT environments. It defines a YANG data model enabling remote management and configuration of constrained devices using CoAP, CBOR, and YANG SID identifiers. The serialization in CBOR of this data model limits the payload size. |
| | Domain-Required TLS |
| |
|
A mechanism which allows a domain owner to declare their messages should only be accepted via sessions that employ STARTTLS, and otherwise, delivery options to be interpreted by the evaluating/ receiving system. |
| | vCon Generation Provenance |
| |
|
This document defines a "provenance" extension for Virtualized Conversations (vCon) that records how a piece of generated content was produced by a generative model: the model and provider, the decoding parameters (for example temperature and top_p), the prompt or a hash of it, the vCon elements that were given to the model as input, and a hash of the output. The record is carried as a named provenance member on the analysis object it describes (and, for machine-generated dialog, on the dialog object), so that an analysis has a real, named home for "how this was generated" rather than overloading the analysis body or schema. The extension is a Compatible vCon extension. It introduces no new top-level fields and does not alter the semantics of existing ones. Because the provenance record binds an output to its model, prompt, and inputs by hash, a signed vCon, or a SCITT transparency receipt over it, can attest to a verifiable derivation: not only that the analysis exists, but how it came to be. |
| | PQuAKE - Post-Quantum Authenticated Key Exchange |
| |
| | draft-uri-cfrg-pquake-00.txt |
| | Date: |
04/06/2026 |
| | Authors: |
Uri Blumenthal, Brandon Luo, Sean O'Melia, Gabriel Torres, David Wilson |
| | Working Group: |
Individual Submissions (none) |
|
This document defines the Post-Quantum Authenticated Key Exchange (PQuAKE) protocol that addresses the needs of bandwidth- and/or power-constrained environments, while maintaining strong security guarantees. It accomplishes that by minimizing the number of bits that need to be exchanged and by utilizing an implicit peer authentication approach similar to Menezes-Qu-Vanstone (MQV) design. This protocol is suitable for integration into protocols that establish dynamic secure sessions, such as Extensible Authentication Protocol (EAP), Internet Key Exchange Version 2 (IKEv2), or Secure Communications Interoperability Protocol (SCIP). This protocol has proofs in the verifiers Verifpal and CryptoVerif for security properties such as secrecy of the session key, mutual authentication, identity hiding with a pre-shared secret, and forward secrecy of the session key. The authors are in the process of publishing the proofs. |
| | Authenticated Transfer: Synchronization |
| |
|
This document describes synchronization mechanisms for public repositories as part of the Authenticated Transfer Protocol (ATP). It specifies both a low-latency streaming protocol over WebSocket, and a full-repository fetch mechanism over HTTP. |
| | OpenPGP Certificate Grammar |
| |
|
This document specifies several updates and clarifications to the grammar and semantics of OpenPGP certificates. |
| | OpenPGP Message Grammar |
| |
|
This document specifies several updates and clarifications to the grammar and semantics of OpenPGP messages. |
| | Permit Receipts for Permit-Before-Commit Authorization of AI-Agent and Workload External Effects |
| |
|
This document defines requirements and an abstract data model for PermitReceipts used in permit-before-commit authorization of AI-agent and workload external effects. A verifier evaluates a canonicalized effect request, action digest, policy epoch, validity interval, scope, issuer evidence, revocation status, and anti-replay state before a protected effect is committed at an effect boundary. The document specifies verifier behavior, failure semantics, conformance expectations, and candidate interoperability registries for discussion. It is intended to enable IETF discussion about the appropriate home, scope, and wire-profile split for this work. |
| | 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. |
| | Constrained Manifold Inference Engine (CMIE): A Research Problem for Deterministic AI-Network Resilience |
| |
|
This document identifies a gap in current AI-native network architectures: the absence of a real-time, hardware-accelerated validation function that checks AI-generated intents against physical causality constraints, including Transmission Time Interval (TTI) bounds, thermal limits, and topological admissibility. We propose the Constrained Manifold Inference Engine (CMIE) as a candidate architectural function and outline research challenges for its implementation on edge Neural Processing Units (NPUs). This work is motivated by the International Telecommunication Union - Telecommunication Standardization Sector (ITU-T) Focus Group on AI Native for Telecommunication Networks (FG-AINN) Gap Analysis (FG- AINN-O-024) and the related liaison statements between FG-AINN and the IETF Operations and Management Area Working Group (OPSAWG). |
| | End-to-End Encryption for HTTP APIs Using X25519 and AES-GCM |
| |
|
This document specifies an application-layer end-to-end encryption (E2EE) scheme for HTTP APIs. The scheme uses X25519 Elliptic Curve Diffie-Hellman (ECDH) for key agreement, HKDF-SHA256 for key derivation, and AES-GCM (with 128-, 192-, or 256-bit keys) for authenticated encryption of request and response payloads. Server public keys are discovered through a Well-Known URI and authenticated either by TLS or by a stronger out-of-band trust mechanism, depending on the deployment threat model. The scheme is designed to provide confidentiality and integrity of payloads independent of, and in addition to, transport-layer security such as TLS. It provides replay protection and key rotation. |
| | Information and Data Models for Packet Discard Reporting |
| |
| | draft-ietf-opsawg-discardmodel-13.txt |
| | Date: |
04/06/2026 |
| | Authors: |
John Evans, Oleksandr Pylypenko, Jeffrey Haas, Aviran Kadosh, Mohamed Boucadair |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
This document defines an Information Model and specifies a corresponding YANG data model for packet discard reporting. The Information Model provides an implementation-independent framework for classifying packet loss - both intended (e.g., due to policy) and unintended (e.g., due to congestion or errors) - to enable automated network mitigation of unintended packet loss. The YANG data model specifies an implementation of this Information Model for network elements with a focus on the interface, device, and control-plane discards. |
| | Guidance to Avoid Carrying RPKI Validation States in BGP Path Attributes |
| |
|
This document provides guidance to avoid carrying Resource Public Key Infrastructure (RPKI) derived validation states in Border Gateway Protocol (BGP) Path Attributes whose change triggers a BGP UPDATE being sent across external BGP sessions. Annotating routes with BGP Path Attributes carried across external BGP sessions signaling validation states may cause needless flooding of BGP UPDATE messages through the global Internet routing system, for example when Route Origin Authorizations (ROAs) are issued, or are revoked, or when RPKI-To-Router sessions are terminated. Operators should ensure RPKI-derived validation states are not signaled in BGP Path Attributes whose change triggers a BGP UPDATE being sent across external BGP sessions. Specifically, operators should not associate Prefix Origin Validation state with BGP routes using any form of BGP Communities carried across EBGP session. This document updates RFC 8097. |
| |
|
| |
| | 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. |
| | 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-key algorithms, and for public key certificates are also defined for BPSec interoperation. |
| | BGP Dissemination of Flow Specification Rules for Tunneled Traffic |
| |
|
This draft specifies a Border Gateway Protocol (BGP) Network Layer Reachability Information (NLRI) encoding format for flow specifications (RFC 8955) that can match on a variety of tunneled traffic. In addition, flow specification components are specified for certain tunneling header fields. |
| | BGP-LS Extension for Inter-AS Topology Retrieval |
| |
|
This document specifies the procedure for distributing Border Gateway Protocol-Link State (BGP-LS) key parameters for inter-domain links between two Autonomous Systems (ASes). It defines a new type within the BGP-LS Network Layer Reachability Information (NLRI) for an inter-AS Link, as well as three new type-length-values (TLVs) for the BGP-LS inter-AS Link descriptor. These BGP-LS extensions enable Software-Defined Networking (SDN) controllers to retrieve network topology across inter-AS environments. These extensions and procedures allow network operators to collect inter-domain interconnect information and automatically compute the end-to-end network topology using information provided by the BGP-LS protocol. |
| | Link-Local Next Hop Capability for BGP |
| |
|
To support IPv6 [RFC4291] reachability, BGP [RFC4271] relies on the Multiprotocol Extensions as defined in [RFC4760]. [RFC2545] defines the structure of IPv6 next hops. These IPv6 next hops may contain a Global IPv6 address, and optionally can contain an IPv6 Link-Local address when the BGP peer is directly attached and shares a common subnet with the IPv6 Global address. This document updates [RFC2545] to clarify the encoding of the BGP next hop when the advertising system is directly attached and only an IPv6 Link-Local address is available. A new BGP Capability [RFC5492] is defined to signal support for this updated encoding. This clarification applies specifically to IPv6 Link-Local addresses and does not pertain to IPv4 Link-Local addresses as defined in [RFC3927]. |
| | CMSF- a CMAF compliant implementation of MOQT Streaming Format |
| |
|
This document updates MOQT Streaming Format by defining optional syntax and semantics for carrying CMAF-packaged media. |
| | SIMAP: Concept,Requirements,and Use Cases |
| |
|
This document defines the concept of Service & Infrastructure Maps (SIMAP) and identifies a set of SIMAP requirements and use cases. The SIMAP was previously known as Digital Map. SIMAP evolves the earlier 'Digital Map' concept by making explicit the ties between service and infrastructure layers, clarifying expected outcomes for operations and automation, and addressing ambiguity associated with the term 'digital.' The document intends to be used as a reference for the assessment of the various topology modules to meet SIMAP requirements. |
| | BGP SR Policy Extensions for Administrative Flags |
| |
|
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is a set of candidate paths, each consisting of one or more segment lists. This document defines an extension to the BGP SR Policy that sets the administrative state of the candidate path or segment list, facilitating the operation and maintenance of the SR Policy. |
| | Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet MPLS Extension Headers |
| |
|
The Simple Two-Way Active Measurement Protocol (STAMP) and its optional extensions can be used for Edge-to-Edge (E2E) active measurement. In Situ Operations, Administration, and Maintenance (IOAM) data fields can be used for recording and collecting Hop-by- Hop (HBH) and E2E operational and telemetry information. This document extends STAMP to reflect MPLS extension headers, including MPLS Network Action Sub-Stacks and Post-Stack Header, for HBH and E2E active measurements, for example, using IOAM data fields. |
| | SRv6 for Deterministic Path Placement in AI Backends |
| |
| | draft-filsfils-srv6ops-srv6-ai-backend-04.txt |
| | Date: |
03/06/2026 |
| | Authors: |
Clarence Filsfils, Pablo Camarillo, Guohan Lu, Jag Brar, David Becker, Abderrahman Jouhari, Kiran Pillai, Ahmed Abdelsalam, Jeff Tantsura, Keyur Patel |
| | Working Group: |
Individual Submissions (none) |
|
This document describes how SRv6 uSID (NEXT-CSID) enables deterministic path placement in AI backend fabrics through L3-L4 integration: the transport stack on the NIC encodes each path as an ordered list of segments (a uSID network program) in the packet header, while the fabric forwards statelessly. It explains operational benefits including deterministic probing and alignment with hyperscale production deployments. |
| | SRv6 End-to-End DC Frontend and WAN |
| |
|
The SRv6 Network Programming architecture allows an application to control the end-to-end journey of traffic flows through different network domains in a unified and stateless manner, without requiring intermediate network devices to maintain per-flow information. This document covers its application to the integration of data center (DC) and wide area network (WAN) architectures using SRv6 with uSID (NEXT-CSID). It describes a unified IPv6 data plane from tenant workloads through the DC frontend to Internet peering, replacing designs that stitch separate overlay protocols at the Data Center Interconnect (DCI). The solution enhances scalability and enables flexible stateless service insertion by unifying underlay, overlay, and service steering under SRv6. |
| | Log More Routing Events in the BGP Monitoring Protocol (BMP) |
| |
|
The Route Event Logging (REL) message is defined in [I-D.ietf-grow-bmp-rel], which enables monitored routers to report event-driven operational data to BMP collectors. This document defines additional event code points for BGP FlowSpec RFC8955 [RFC8956] and BGP SR Policies [I-D.ietf-idr-sr-policy-safi]. These extensions enhance monitoring visibility for policy execution failures and improve network operation and troubleshooting capabilities. |
| | A Standard for Claiming Transparency and Falsifiability |
| |
| | draft-laurie-tmif-01.txt |
| | Date: |
03/06/2026 |
| | Authors: |
Ben Laurie, Tiziano Santoro, Pauline Anthonysamy, Sarah de Haas, Ankur Mathur |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies a Transparency Metadata Interchange Format (TMIF) that allows a system to make standardized, verifiable claims about its levels of transparency and falsifiability. TMIF is designed to be agnostic to specific threat models or mitigations, serving purely as a communication vehicle for system providers to declare how their security and privacy controls can be verified by third-party evaluators. |
| | SCRAM with Modular Crypt Format (SCRAM-MCF) |
| |
|
This document specifies SCRAM-MCF, an extension to the Salted Challenge Response Authentication Mechanism (SCRAM) family of SASL mechanisms ([RFC5802]) and HTTP Digest extensions ([RFC7616], [RFC7677]). The extension replaces the PBKDF2-specific iteration count attributes i= and s= in the server-first-message with a generic Modular Crypt Format (MCF) descriptor f=. This allows servers to use modern memory- hard key derivation functions such as Argon2, SCrypt, or bcrypt while preserving the full security properties and message flow of SCRAM. The change is fully backward compatible: servers can continue sending i= and s= for legacy clients and only send f= (or both) when the client advertises support. This document is intended to be discussed and potentially adopted by the KITTEN working group. Feedback from the KITTEN WG is welcome on the kitten@ietf.org mailing list. |
| | BGP Deterministic Path Forwarding (DPF) |
| |
| | draft-wang-idr-dpf-01.txt |
| | Date: |
03/06/2026 |
| | Authors: |
Kevin Wang, Michal Styszynski, W. Lin, Mahesh Subramaniam, Thomas Kampa, Diptanshu Singh |
| | Working Group: |
Individual Submissions (none) |
|
Modern data center (DC) fabrics typically employ Clos topologies with External BGP (EBGP) for plain IPv4/IPv6 routing. While hop-by-hop EBGP routing is simple and scalable, it provides only a single best- effort forwarding service for all types of traffic. This single best-effort service might be insufficient for increasingly diverse traffic requirements in modern DC environments. For example, loss and latency sensitive AI/ML flows may demand stronger Service Level Agreements (SLA) than general purpose traffic. Duplication schemes which are standardized through protocols such as Parallel Redundancy Protocol (PRP) require disjoint forwarding paths to avoid single points of failure. Congestion avoidance may require more deterministic forwarding behavior. This document introduces BGP Deterministic Path Forwarding (DPF), a mechanism that partitions the physical fabric into multiple logical fabrics. Flows can be mapped to different logical fabrics based on their specific requirements, enabling deterministic forwarding behavior within the data center. |
| | OAuth 2.0 RAR Metadata and Error Signaling |
| |
|
OAuth 2.0 Rich Authorization Requests (RAR) [RFC9396], standardizes the exchange and processing of authorization details but does not define metadata to describe authorization details types. The document addresses a practical interoperability challenge regarding metadata of authorization details types, allowing clients tp dynamically discover metadata instead of relying on out-of-band agreements. It also standardizes error signaling, in case insufficient RAR was provided and offers structured ways of remediation. |
| | Security Considerations for Intent-Based Requests in Agentic Systems |
| |
|
Intent-based requests enable users, applications, and agents to express goals and constraints without specifying step-by-step procedures. Such intents are commonly translated into executable directives and propagated across multiple entities (clients, agents, authorization components, orchestration functions, and execution endpoints). This multi-hop processing expands the attack surface for tampering, privilege escalation, constraint bypass, and intent drift. In addition, at the point where an intent enters the system, a forged or unauthorized origin may cause actions to be taken without valid consent. This document provides a solution-agnostic security analysis for intent-based requests across agentic systems. It introduces a reference model and scenarios to guide protocol and system design, and also presents threats and requirements. The document emphasizes origin authentication and admission control, constraint validation, invocation validation, multi-hop chain-of-custody, and policy-driven responses to drift, while remaining independent of any specific deployment domain. |
| | ATTP: Agent Trust Transport Protocol |
| |
|
This document specifies the Agent Trust Transport Protocol (ATTP), a protocol-agnostic framework for trust scoring, cryptographic identity, action-limit enforcement, compliance gating, and tamper- evident audit for autonomous AI agents. ATTP separates trust from identity. Identity protocols answer "who is this agent?" ATTP answers "should this agent be allowed to perform this action, at this magnitude, against this counterparty, right now?" The protocol defines five progressive trust levels (L0-L4), per-agent ECDSA P-256 cryptographic identity, a five-dimension behavioural trust scoring model, action-limit tiers derived from trust scores, real-time compliance gating (sanctions screening, jurisdictional controls), kill switches for instant revocation, anomaly detection for agent behaviour, and a public trust query API. ATTP is transport-agnostic. This document defines the core framework. Protocol-specific bindings map ATTP trust enforcement to individual transports: MCPS provides the binding for the Model Context Protocol (MCP), with additional bindings defined for REST APIs, Google A2A, gRPC, GraphQL, and SPIFFE/SPIRE. This specification supersedes draft-sharif-agent-payment-trust-00, broadening the scope from payment transactions to any agent action requiring trust-gated authorisation, and consolidates the parallel draft-sharif-attp-agent-trust-transport-00 into a single ATTP lineage. |
| | Botnet Identification by Coordination-Coherence and Coherence-Driven Remediation Signaling: The MVPS Botnet Profile |
| |
|
This document specifies how the Multi-Vantage Path Synchrony (MVPS) framework [I-D.melegassi-ippm-mvps-bundle] and its DDoS profile [I-D.melegassi-mvps-ddos-resilience] are extended to IDENTIFY the participating sources of a botnet by their coordination-coherence signature, and to EMIT corroborated, signed evidence that DRIVES existing, standardised remediation ("sanitization") machinery. The central design constraint is honesty about scope. MVPS does NOT itself clean, quarantine, sinkhole, or take down infected hosts. Remediation is performed by the mechanisms already defined by the IETF: o RFC 6561 (Recommendations for the Remediation of Bots in ISP Networks) -- the notification/remediation workflow; o RFC 9132 / RFC 8783 / RFC 8811 (DOTS) -- mitigation request signaling; o RFC 8520 (Manufacturer Usage Description, MUD) -- containment of compromised constrained/IoT devices; o BCP 38 / BCP 84 (RFC 2827 / RFC 3704) -- source-address validation against spoofed botnet traffic; o RFC 7970 / RFC 8727 (IODEF) and RFC 6545 (RID) -- the exchange and inter-domain coordination formats; o RFC 9424 -- the Indicator-of-Compromise (IoC) framing for what MVPS exports. What MVPS contributes is precisely the gap RFC 6561 Section 4 names: it asks operators to "confirm a bot infection through the use of a combination of multiple bot detection data points ... to corroborate information of varying dependability ... [and] avoid or minimize the possibility of false-positive identification of hosts." MVPS is exactly such a corroboration engine, with the addition of a provable false-positive bound (Theorem B2) and a coordination-coherence test (Theorem B1) that distinguishes a genuinely coordinated population (a botnet) from an equal number of independently misbehaving hosts. We state three results: Theorem B1 (Coordination Signature). A population of S sources driven by a common controller produces a low-rank deformation of the cross-vantage coherence covariance; independent legitimate sources do not. The leading eigenvalue ratio is therefore a detector of coordination, not of volume. Theorem B2 (Corroboration / False-Positive Bound). If a single vantage flags a candidate source with per-vantage false-positive rate p, then requiring agreement across V independent vantages drives the host-level false-positive probability to at most p^V under vantage independence, and to a stated mixture bound under partial correlation. Theorem B3 (No Unilateral Action / Remediation Soundness). MVPS emits evidence only. Every enforcement step is taken by an existing standardised control point (RFC 6561 / DOTS / MUD / BCP 38). No host is quarantined on single-vantage evidence. Theorem B4 (Falsifiability / coherence-collapse axis). The corroboration bound of B2 COLLAPSES on a correlated benign population: a legitimate flash crowd is coordinated-but-benign, the botnet analogue of the COHERENT_BUT_FALSE failure mode of the MVPS AI-Coherence extension [I-D.melegassi-mvps-ai-coherence]. When the coherence environment so collapses, that extension's falsifiability axis enters: re-test the apparent coordination on the machine-regularity subspace -- features a human crowd cannot fake. A flash crowd collapses to the independent floor there; a real bot fleet does not. Theorem B5 (No Free Decorrelation). Spreading the botnet's coordination across many sources to drop each per-vantage signal cannot lower what the multi-vantage aggregate sees: the coherent statistic is spread-INVARIANT (T_agg = sqrt(E)) with NO compute term, so the multi-vantage advantage GROWS with the spread and the silent-coordination cap is E < tau^2. This is the exact form of the B1 evasion corollary. Theorem B6 (Non-Blinding of the corroboration set). Silently hiding the coordination by corrupting the vantages is impossible while the redundancy rho = V - d_eff >= 1 with diverse vantages: any such blinding needs k > rho corruptions and is FLAGGED by the vantage-integrity monitor (a non-zero stealth-gap), and the only un-flagged corruption -- forging vantage reports -- is gated by a post-quantum signature (ML-DSA, FIPS 204). "Blind" implies "known-blind". THE THESIS IN ONE LINE. Cross-vantage agreement is necessary but not sufficient: the coherence environment can collapse (correlated benign crowds, or Byzantine vantages), and where it collapses the AI-coherence axes -- falsifiability (B4) and Byzantine-robust geometric-median aggregation [I-D.melegassi-mvps-ai-coherence] -- are what keep the identification sound. NOTE ON DATA PROVENANCE. Section 7 reports two kinds of result, each tagged. Section 7.1 is a LABELLED SYNTHETIC ground-truth experiment (script scripts/simulate_botnet_coherence.py). Sections 7.2 and 7.3 are measured on REAL labelled botnet traffic: the CTU-13 dataset of the Stratosphere IPS Laboratory (bidirectional NetFlow [RFC5103] / IPFIX [RFC7011] records labelled Botnet / Normal / Background), across three malware families (Neris, Rbot, Virut). On that real data the detector separates botnet from normal traffic with held-out AUC 0.85-0.999, and the multi-vantage advantage (Theorem B5) is instantiated with the MEASURED per-flow effect size. What remains REQUIRED future work (Section 10) is corroboration across THREE OR MORE INDEPENDENT REAL VANTAGES observing the same event (the real-data form of Theorem B2): CTU-13 is a single capture point. No claim of operational botnet takedown is made. |
| | MVPS-Memory: Multi-Vantage Coherence Detection of Memory-Resident Malware,Anchored in Remote Attestation |
| |
|
Memory-resident ("fileless", in-memory) malware -- reflective code injection, page-cache .text patching, process hollowing, RX->RWX permission flips, unbacked-memory thread starts, token theft, and patchless AMSI/ETW suppression -- leaves the on-disk image unchanged and is therefore structurally invisible to signature and file-integrity detectors. This document explains why, and what removes the blind spot, using the Multi-Vantage Path Synchrony (MVPS) observability model y = H x: each detection facility is a row (a projection) of one observation operator H over an interior runtime-memory state x, and a purely in-memory implant is an attack whose damage direction c lies in the NULL SPACE of any single on-disk vantage. The contribution uses no new mathematics. It (1) instantiates the already-proved MVPS results -- the Stealth-Manifold Lemma, the coordination-stealth duality, the Stealth Conservation Law max(0, k - rho), the reflexive tower, the data-processing ceiling, the non-blinding invariant (stealth + effect = ||a||^2), and the silent-effect ceiling (E < tau^2) -- verbatim on the runtime-memory surface; (2) anchors the meta-observer in the RATS architecture [RFC9334], whose Attester is defined to collect Claims by "taking measurements on code, memory, or other security related assets", with TPM-based Remote Integrity Verification [RFC9683], the Entity Attestation Token [RFC9711], the Concise Reference Integrity Manifest [I-D.ietf-rats-corim], and Concise Software Identification [RFC9393] as the evidence/reference-value layer; and (3) closes the vantage-forgery channel with post-quantum eye identity (ML-DSA, FIPS 204, via [I-D.ietf-cose-dilithium] and [I-D.ietf-lamps-dilithium-certificates]). A live threat anchor -- the 2025-2026 surge in BYOVD EDR-killers (e.g. CVE-2025-68947) and patchless AMSI/ETW suppression -- is shown to be a textbook instance of the eye-silencing law. All theorem-level claims carry a machine-checkable numerical receipt. |
| | A Well-Known URI Profile for Agent-Callable Commerce Endpoints |
| |
|
This document defines an informational profile for the Server Card document retrieved from the /.well-known/mcp.json Well-Known URI defined by the Model Context Protocol (MCP) project. The profile adds an optional commerce extension to the Server Card, carried in the Server Card's _meta object under the reverse-DNS key com.beaconspec/commerce, for commercial businesses operating MCP servers. The extension carries business identity, geographic location, industry classification, offering type, and advertised capability categories. The purpose of the profile is to give AI agents enough machine-readable information about a commercial MCP server to filter, select, and bootstrap an interaction without first opening an MCP session against every candidate server. |
| | HTTP Signaling of Planned IPv4 Unavailability |
| |
|
As operators transition services to IPv6-only, planned IPv4 outages help identify remaining dependencies before permanent decommission. Such outages must be measurable, reversible, and understandable to end users. This document defines the 566 (IPv4 Unavailable) HTTP response status code and associated header fields that signal an intentional, often time-bounded IPv4 outage, instruct aware clients to retry over IPv6 after closing the IPv4 connection, and allow clients to confirm successful IPv6 recovery via an optional correlation token so operators can distinguish soft failures from hard failures in centralized logs. The mechanism supports coordinated events (for example, 6/6 IPv6 Day drills), staged enterprise rollouts, and permanent IPv6-only migration. Legacy clients that do not implement this specification treat an unrecognized 566 status code as an internal server error and MAY use the response body for human-readable guidance. |
| | Optimistic DNS |
| |
|
DNS lookups introduce user-visible delay, particularly when cached records have expired and must be refreshed from the network. This document describes Optimistic DNS, a client-side stub resolver mechanism that immediately returns expired cached DNS records to applications while simultaneously refreshing them with a network query. The application receives an answer in microseconds rather than milliseconds, and if the data has changed receives an updated answer shortly thereafter. Optimistic DNS is complementary to RFC 8767, which addresses serving stale data at recursive resolvers. This document focuses exclusively on client-side stub resolver behavior, including explicit signaling from the application to inform the stub resolver that the application is able to handle old and possibly incorrect information. |
| | Verifiable Agent Protocol (VAP): Intent-Bound Admission Control and Audit for Agent Tool Invocation |
| |
| | draft-samal-vap-00.txt |
| | Date: |
03/06/2026 |
| | Authors: |
Kruttidipta Samal |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the Verifiable Agent Protocol (VAP), a thin, tool-agnostic verification layer for protocols in which an autonomous agent (a client driven by a large language model) invokes tools exposed by a server (for example, the Model Context Protocol, MCP). Existing tool-invocation protocols convey WHAT tool is to be run and, with authorization extensions, WHO is calling, but carry no machine- verifiable statement of WHY a call is being made. VAP adds a declared, structured, optionally signed statement of purpose and a stable per-session scope-and-budget commitment, against which a server performs admission control before executing a call. VAP defines four messages -- Scope Commitment, Intent Envelope, Scope Amendment, and Verdict -- carried inside the host protocol's existing metadata channel, requiring no change to that protocol and no change to existing servers. VAP targets erroneous and runaway agent behavior, session cost control, and audit; it is defense-in-depth for, not a replacement for, authentication and authorization. |
| | EVPN VLAN Tag Extended Community |
| |
|
Ethernet Virtual Private Network (EVPN), as defined in RFC 7432, provides a control plane for distributing MAC and IP address bindings using BGP MAC/IP Advertisement routes. In several deployment scenarios, policy decisions depend not only on MAC/IP bindings but also on VLAN encapsulation information, particularly in environments using - IEEE 802.1Q VLAN tagging and IEEE 802.1ad provider bridging (QinQ). However, RFC 7432 does not define a mechanism to propagate VLAN information associated with MAC/IP bindings. This document defines a new EVPN Extended Community that carries VLAN identifiers to enable consistent policy enforcement across EVPN Provider Edge devices. This document does not modify EVPN route selection or forwarding behavior defined in RFC 7432. |
| | The SDN-based MPTCP-aware and MPQUIC-aware Transmission Control Model |
| |
|
This document aims to study and implement Multipath Transmission Control Protocol (MPTCP) and Multipath QUIC (MPQUIC) using application layer traffic optimization (ALTO) in software defined network (SDN). In a software-defined network, ALTO server collects network cost indicators (including link delay, number of paths, availability, network traffic, bandwidth and packet loss rate etc.), and the controller extracts MPTCP or MPQUIC packet header to allocate MPTCP or MPQUIC packet to suitable transmission path according to the network cost indicators by ALTO, which can reduce the probability of transmission path congestion and improving path utilization in a multipath transmission network. |
| | Endpoint Handling of SCONE Throughput Advice Across QUIC Path Changes |
| |
|
SCONE throughput advice is scoped to the path and direction in which it is received. When a QUIC connection changes path, the endpoint can retain an old advice value while that value is no longer applicable to the active path. This document describes endpoint- local handling of that transition. It focuses on the distinction between retained advice and active-path advice, the interval in which no fresh path-applicable advice is available, and the observability needed to avoid treating historical advice as current guidance. This document defines no new SCONE protocol elements, does not modify QUIC path validation, does not define an application API, and does not change congestion control behavior. |
| | Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP) |
| |
| | draft-ietf-schc-8824-update-08.txt |
| | Date: |
03/06/2026 |
| | Authors: |
Marco Tiloca, Laurent Toutain, Ivan Martinez, Ana Minaburo |
| | Working Group: |
Static Context Header Compression (schc) |
|
This document defines how to compress Constrained Application Protocol (CoAP) headers using the Static Context Header Compression and fragmentation (SCHC) framework. SCHC defines a header compression mechanism adapted for constrained devices. SCHC uses a static description of the header to reduce the header's redundancy and size. While RFC 8724 describes the SCHC compression and fragmentation framework and its application for IPv6 and UDP headers, this document applies SCHC to CoAP headers. The CoAP header structure differs from that of IPv6 and UDP headers, since CoAP uses a flexible header with a variable number of options that are in turn of variable length. The CoAP message format is asymmetric, i.e., request messages have a header format different from that of response messages. This specification gives guidance on applying SCHC to flexible headers and on leveraging the message format asymmetry for defining more efficient compression Rules. This document replaces and obsoletes RFC 8824. |
| | A Profile for Resource Public Key Infrastructure (RPKI) Canonical Cache Representation (CCR) |
| |
|
This document specifies a Canonical Cache Representation (CCR) content type for use with the Resource Public Key Infrastructure (RPKI). CCR is a Distinguished Encoding Rules (DER) encoded data interchange format which can be used to represent various aspects of the state of a validated RPKI cache at a particular point in time. The CCR profile is a compact and versatile format, well-suited for a variety of applications, for example, audit trails, analytics pipelines, and validated payload dissemination. |
| |
|
| |
| | BGP SR Policy Extensions for Metric |
| |
|
An SR Policy consists of one or more Candidate Paths (CPs), each comprising one or more segment lists. BGP can be used to propogate SR Policy CPs to the SR Policy headend nodes in the network. After an SR Policy CP is installed on the headend node, packets can be steered into the SR Policy. For a particular BGP destination, if there are multiple BGP routes with different next-hops, BGP best path selection is performed and the IGP metric to the next-hop node may be used for tie-breaking to select the best path. When the path to the next-hop is resolved over an SR Policy, the IGP metric of the SR policy is needed for BGP path selection. This document defines the BGP extensions to carry the IGP metric of segment lists when BGP is used to propagate SR Policy CPs. |
| | MOQT Streaming Format |
| |
|
This document specifies the MOQT Streaming Format, designed to operate on Media Over QUIC Transport. |
| | ICANN Registrar Interfaces |
| |
|
This document describes the interfaces provided by ICANN to Registrars and Data Escrow Agents to fulfill the data escrow requirements of the Registrar Accreditation Agreement and the Registrar Data Escrow Specifications. |
| | Access Extensions for ANCP |
| |
|
This document specifies extensions to the Access Node Control Protocol (ANCP), defined in RFC6320, to support Passive Optical Networks (PON) and evolving DSL technologies such as G.fast. To accommodate these diverse access environments, this document updates RFC6320 by modernizing existing terminologies, adapting message flows, and defining new Type-Length-Value (TLV) attributes. |
| | Multipath Traffic Engineering for Segment Routing |
| |
|
This document describes a mechanism to achieve Multipath Traffic Engineering for Segment Routing based networks. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Source Packet Routing in Networking Working Group mailing list (spring@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/spring/. Source for this draft and an issue tracker can be found at https://github.com/astone282/draft-stone-spring-mpte-sr. |
| | 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. |
| | 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. |
| | 384-bit Cryptographic Algorithms For Use With TCP-AO |
| |
|
RFC5926 creates a list of cryptographic algorithms that can be used with TCP-AO. This document expands that list, adding two Message Authentication Code (MAC) algorithms, HMAC-SHA384 and KMAC384. For each MAC algorithm, a corresponding Key Derivation Function (KDF) is also added. The MAC algorithms described by this document produce 384-bit (i.e., 48-byte) MACs. When 48-byte MACs are encoded in TCP-AO, the TCP-AO consumes 52 bytes. This exceeds TCP's 40-byte option size limitation. Therefore, it depends on a solution that extends TCP Option space. |
| | AI Manifest: Site-Published Friction-Recovery Descriptors for AI Agents |
| |
|
This document specifies the AI Manifest, a JSON-based format with which a website operator publishes an AI Friction-Recovery Manifest (AFRM): a declarative, advisory description of the known user- interface (UI) traps on a site, the framework hints that contextualize them, and the interaction shortcuts that bypass them. An autonomous AI agent that uses browser-automation tools discovers the manifest out-of-band and consults it as reference data when it encounters friction, instead of re-inferring site-specific behavior from the full Document Object Model (DOM) by trial and error. The manifest is advisory data published by the origin; it is not part of, and does not modify, any browser-automation tool schema. The specification defines five interoperable discovery methods, the AFRM three-part schema (frameworkHints, knownTraps, and shortcuts), and an OPTIONAL SHA-256 canonical-hash verification procedure via a trust registry, together with security mitigations against prompt- injection attacks. Empirical evaluation with a contemporary LLM browser agent on a proprietary-knowledge enterprise task -- an SAP S/4HANA-style table- maintenance screen whose valid values depend on a company-code registration scope that is not derivable from public or training knowledge -- shows that a site-published manifest, consumed directly by the agent with no external runtime, reduces interaction actions by approximately 54% and input tokens by approximately 45% relative to the no-manifest baseline, with both conditions completing the task. The manifest's value concentrates where the agent cannot succeed from training knowledge alone: site-specific dependencies, data, and hard mechanical blocks. This -02 revision supersedes the deterministic-runtime framing of draft-han-ai-manifest-01. The earlier revision reported a single- trial preliminary measurement and concluded that an embedded manifest is of negative value unless paired with a deterministic execution runtime (an "SDK"). Subsequent multi-condition measurement with a real LLM agent shows that a manifest is consumed and is useful on its own; an out-of-band discovery path (the Method A well-known URI, or the user-curated Method E) avoids the prompt-injection-defense friction that the earlier embedded-only trial encountered. A deterministic runtime remains OPTIONAL -- useful for latency- or service-level-sensitive deployments -- but is no longer presented as REQUIRED. |
| | SDLP Security Architecture (SDLP RFC 4) |
| |
|
This document defines the security architecture for the Secured Digital Lifecycle Protocol (SDLP). It specifies the security model, threat surfaces, authentication requirements, authorization boundaries, and integrity guarantees that govern all SDLP lifecycle transitions and transformations. |
| | SDLP Architecture (arch) |
| |
|
The Secured Digital Lifecycle Protocol (SDLP) defines a universal, lifecycle-governed framework for the creation, identity, transformation, distribution, and retirement of digital goods. |
| | ML-DSA 44/Ed255192 Composite Signatures in SSH |
| |
|
This document specifies the integration of the MLDSA44-Ed25519-SHA512 composite signature scheme into the Secure Shell (SSH) protocol. This scheme combines the post-quantum Module-Lattice Digital Signature Algorithm (ML-DSA) with the classical elliptic curve Ed25519 signature algorithm to provide security against both quantum and classical adversaries. |
| | Observations on the Reachability and Evasion of Packets with IPv6 Extension Headers on the Internet |
| |
|
IPv6 Extension Headers (EHs) are designed to provide protocol flexibility and support for emerging features, while maintaining a concise base header and efficient processing. However, their practical reachability has long been constrained by widespread middlebox interference, and paradoxically, their flexibility introduces significant security risks. This document presents observations from a comprehensive, large-scale measurement study of IPv6 Extension Header path traversal across more than 23,000 autonomous systems. Using a feedback-driven measurement framework called 6Travel, we measure the reachability of 10 common IPv6 Extension Headers over ICMPv6, TCP, and UDP. Our analysis reveals a fundamental shift: contrary to past observations of heavy filtering, specific Extension Headers now achieve reachability comparable to plain traffic. We further identify two distinct forms of policy ossification across industry categories and expose a widespread Extension-Header-based firewall evasion vulnerability affecting nearly 5,000 autonomous systems, particularly under TCP and UDP. This threat stems from a dual failure of implementation flaws and security misconfigurations, spanning both on-path and host-side firewalls. |
| | Low Overhead CMAF for Media over QUIC (LOCMAF) |
| |
|
This document specifies LOCMAF (Low Overhead CMAF for Media over QUIC), a compact wire format for streaming low-latency CMAF media over the MoQ Transport protocol (MOQT) with per-object overhead comparable to the Low Overhead Container (LOC). LOCMAF carries the CMAF chunk head metadata from a single moof (movie fragment) — as a small set of tagged fields inside one of two LOCMAF object kinds, while leaving the sample data (mdat) untouched. In addition, it can carry the optional styp (segment type), prft (producer reference time), any number of emsg (event message) boxes. The first object of each MOQT group carries a full reference; subsequent objects in the same group carry only the differences. The receiver reconstructs CMAF chunks that are semantically equivalent to the sender input, including encryption metadata required by CMAF DRM (Common Encryption) pipelines. |
| | Security Requirements for IP Tunnel Nodes |
| |
|
IP tunnel nodes are widely deployed for IPv4/IPv6 transition, overlay connectivity, traffic engineering, and inter-domain services. A tunnel node that accepts tunneled packets from unauthorized sources or forwards decapsulated packets without validating the inner packet can become an open relay, a source-address-spoofing enabler, or a path around filtering policy. This document specifies security requirements for IP tunnel nodes. It defines requirements for tunnel enablement, peer authorization, source address validation, forwarding-scope validation, recursive encapsulation limits, IPv6 extension header handling, ICMP behavior, logging, and operational management. The requirements apply to IP- in-IP, GRE, IPv6 tunnel mechanisms, and IPv4/IPv6 transition tunnels. |
| | Encrypted Identity Routing Protocol (EIRP): A Blockchain-Orchestrated Identity-Based Routing Architecture |
| |
|
This document proposes the Encrypted Identity Routing Protocol (EIRP), a conceptual redesign of Internet routing where public IP addresses are replaced by encrypted identities authenticated through blockchain consensus. |
| | A Framework for Co-Designing Sketch and In-Band Network Telemetry for Accurate Network Measurement |
| |
|
Network measurement is a fundamental building block for network management applications. Existing measurement techniques face a trade-off between accuracy and resource efficiency: sketch-based techniques achieve high accuracy for large flows but degrade for small flows, while In-band Network Telemetry (INT) measures every flow accurately but at the cost of significant bandwidth and control plane resources. This document describes a framework for co-designing sketches and INT to measure large and small flows respectively, achieving both high accuracy and resource efficiency. It addresses two key challenges: (1) where to deploy measurement functions when routing information is incomplete, and (2) how to collect measurement data without causing network congestion. |
| | OAuth Identity and Authorization Chaining Across Domains |
| |
| | draft-ietf-oauth-identity-chaining-14.txt |
| | Date: |
02/06/2026 |
| | Authors: |
Arndt Schwenkschuster, Pieter Kasselman, Kelley Burgin, Michael Jenkins, Brian Campbell, Aaron Parecki |
| | Working Group: |
Web Authorization Protocol (oauth) |
|
This specification describes a mechanism for preserving identity and authorization information across trust domains that use the OAuth 2.0 Framework. A JSON Web Token (JWT) authorization grant, obtained through an intra-domain OAuth 2.0 Token Exchange, facilitates the cross-domain acquisition of an access token. The relevant identity and authorization information is chained throughout the flow by being conveyed in the respective artifacts exchanged at each step of the process. Chaining across multiple domains is achieved by using the same protocol every time a trust domain boundary is crossed. |
| | PCEP extensions for SR P2MP Policy |
| |
| | draft-ietf-pce-sr-p2mp-policy-16.txt |
| | Date: |
02/06/2026 |
| | Authors: |
Hooman Bidgoli, Dan Voyer, Anuj Budhiraja, Rishabh Parekh, Siva Sivabalan |
| | Working Group: |
Path Computation Element (pce) |
|
Segment Routing (SR) Point-to-Multipoint (P2MP) Policies are a set of policies that enable architecture for P2MP service delivery. This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate P2MP paths with MPLS encap from a Root to a set of Leaf nodes. |
| | GLobal Unique Enterprise (GLUE) Identifiers |
| |
| | draft-ietf-spice-glue-id-09.txt |
| | Date: |
02/06/2026 |
| | Authors: |
Brent Zundel, Pamela Dingle, Michael Jones |
| | Working Group: |
Secure Patterns for Internet CrEdentials (spice) |
|
This specification establishes a URI scheme for GLobal Unique Enterprise (GLUE) Identifiers. This enables URI identifiers to be used for businesses and organizations. It enables organizational identities from existing authorities to be represented within this URI scheme. |
| | Additional Cryptographic Algorithms For Use With TCP-AO |
| |
|
RFC5926 creates a list of cryptographic algorithms that can be used with TCP-AO. This document expands that list, adding two Message Authentication Code (MAC) algorithms, HMAC-SHA256-128 and KMAC256-128. For each MAC algorithm, a corresponding Key Derivation Function (KDF) is also added. The MAC algorithms described by this document produce 128-bit (i.e., 16-byte) MACs. When 16-byte MACs are encoded in TCP-AO, the TCP-AO consumes 20 bytes. This does not challenge TCP's 40-byte option size limitation. |
| |
|
| |
| | Automated Certificate Management Environment (ACME) Device Attestation Extension |
| |
| | draft-ietf-acme-device-attest-06.txt |
| | Date: |
01/06/2026 |
| | Authors: |
Brandon Weeks, Ganesh Mallaya, Sven Rajala, Corey Bonnell, Ryan Hurst |
| | Working Group: |
Automated Certificate Management Environment (acme) |
|
This document specifies new identifiers and a challenge for the Automated Certificate Management Environment (ACME) protocol which allows validating the identity of a device using attestation. |
| | BGP Usage for SD-WAN Overlay Networks |
| |
|
This document illustrates how a BGP-based control plane can be used to manage large scale Software Defined WAN (SD-WAN) overlay networks by distributing edge service reachability information, WAN port attributes, and underlay path details, thereby minimizing manual provisioning. In such deployments, BGP can provide a standards-based mechanism for distributing information that may otherwise be exchanged using proprietary SD-WAN control-plane mechanisms. However, extensions to BGP are needed to achieve that goal. |
| | JSCalendar: Converting from and to iCalendar |
| |
|
This document defines how to convert calendaring information between the JSCalendar and iCalendar data formats. It considers every JSCalendar and iCalendar element registered at IANA at the time of publication. It defines conversion rules for all elements that are common to both formats, as well as how convert arbitrary or unknown JSCalendar and iCalendar elements. This document updates RFC 5545 ("iCalendar") and jscalendarbis ("JSCalendar") by defining new properties and parameters for JSCalendar and iCalendar conversion. |
| | JSCalendar 2.0: A JSON Representation of Calendar Data |
| |
|
This specification defines version "2.0" of JSCalendar, a data model and JSON representation of calendar data that can be used for storage and data exchange in a calendaring and scheduling environment. This document obsoletes RFC 8984, also referred to as version "1.0" in this document. The newly defined version "2.0" aims to improve interoperability with existing iCalendar-based systems. It also aligns its definitions with JSContact, such as the IANA registry policy, validation requirements, and versioning scheme. |
| | YANG Data Model for FlexE Management |
| |
| | draft-ietf-ccamp-flexe-yang-cm-08.txt |
| | Date: |
01/06/2026 |
| | Authors: |
Minxue Wang, Liuyan Han, Xuesong Geng, Jin Zhou, Luis Contreras, Xufeng Liu |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
|
This document defines a service provider targeted YANG data model for the configuration and management of a Flex Ethernet (FlexE) network, including FlexE group and FlexE client. |
| | A YANG Data Model for BMP |
| |
| | draft-ietf-grow-bmp-yang-08.txt |
| | Date: |
01/06/2026 |
| | Authors: |
Camilo Cardona, Paolo Lucente, Thomas Graf, Benoit Claise, Dhananjay Patki, Narasimha Prasad |
| | Working Group: |
Global Routing Operations (grow) |
|
This document defines a YANG data model for the configuration and monitoring of the BGP Monitoring Protocol (BMP). The data model covers the base BMP protocol defined in [RFC7854] and includes support for the Loc-RIB extension defined in [RFC9069]. |
| | ICANN Registry Interfaces |
| |
|
This document describes the technical details of the interfaces provided by the Internet Corporation for Assigned Names and Numbers (ICANN) to its contracted parties to fulfill reporting requirements. The interfaces provided by ICANN to Data Escrow Agents and Registry Operators to fulfill the requirements of Specifications 2 and 3 of the gTLD Base Registry Agreement are described in this document. Additionally, interfaces for retrieving the IP addresses of the probe nodes used in the SLA Monitoring System (SLAM) and interfaces for supporting maintenance window objects are described in this document. |
| | lispers.net LISP NAT-Traversal Implementation Report |
| |
|
This memo documents the lispers.net implementation of LISP NAT traversal functionality. The document describes message formats and protocol semantics necessary to interoperate with the implementation. This memo is not a standard and does not reflect IETF consensus. |
| | Fully Adaptive Routing Ethernet using BGP |
| |
| | draft-xu-idr-fare-05.txt |
| | Date: |
01/06/2026 |
| | Authors: |
Xiaohu Xu, Shraddha Hegde, Keyur Patel, Zongying He, Junjie Wang, Hongyi Huang, Qingliang Zhang, Hang Wu, Yadong Liu, Yinben Xia, Peilong Wang, Tiezheng, Roman Glebov |
| | Working Group: |
Individual Submissions (none) |
|
Large language models (LLMs) like ChatGPT have become increasingly popular in recent years due to their impressive performance in various natural language processing tasks. These models are built by training deep neural networks on massive amounts of text data, as well as visual and video data, and often consist of billions or even trillions of parameters. However, the training process for these models can be extremely resource-intensive, requiring the deployment of thousands or even tens of thousands of GPUs in a single AI training cluster. Therefore, three-stage or even five-stage CLOS networks are commonly adopted for AI networks. The non-blocking nature of the network becomes increasingly critical for large-scale AI model training. Therefore, adaptive routing is necessary to dynamically distribute traffic to the same destination across multiple equal-cost paths, based on network capacity and even congestion information along those paths. |
| | Doing an Inventory of IoT devices using IDevID scanning |
| |
|
This document describes a mechanism to do an inventory of devices on a network. While there are significant abuse and privacy concerns with kind of scanning, the practice of scanning networks and fingerprinting devices has been occuring since the mid 1990s. But, the adhoc methods are not reliable and do not provide any kind of strong device identity. This document takes the approach that if it will happen, it might as well be reliable and secure. |
| | 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. |
| | BGP SR Policy Extensions for Computing-Aware Traffic Steering (CATS) |
| |
|
An SR (Segment Routing) Policy is a set of candidate paths, each consisting of one or more segment lists. The CATS (Computing-Aware Traffic Steering) can steer traffic between clients of a service and sites offering the service. This document proposes the BGP SR policy extensions for distributing CATS services. |
| | Provider Interface SAV for Customer Cone Sources |
| |
|
Current source address validation (SAV) on an AS's provider interfaces mainly relies on loose uRPF, which cannot defend against IP spoofing using routable prefixes and is ineffective when a default route is present. This document describes a *framework* for provider interface source address validation against spoofing of customer cone source prefixes (PI-SAV for CC). Two architectural approaches are presented: * *PI-SAV for Standalone CC*: a static solution that builds a blocklist based on topology information from BGP RIBs, RPKI ASPA, and local configuration (SLURM) etc. It requires no inter-AS communication. * *PI-SAV for Standalone+ CC*: an enhanced solution that uses lightweight query-response coordination between the top AS and member ASes to identify sub-cones that do not actually cause traffic detours, thereby enlarging the effective blocklist. This document is *informational* and provides only the framework, conceptual procedures, and requirements for future protocol specifications. Detailed wire protocols (e.g., for partial transit information provisioning or for query-response messaging) are out of scope and will be defined in separate documents. |
| | The DNS XFR URI Schemes |
| |
|
The DNS protocol provides an in-band mechanism for transferring the contents of a zone from a server to a client. This is most frequently used when secondary servers are transferring the DNS zone content from their configured primary server. This document defines a Uniform Resource Identifier (URI) scheme for referencing DNS servers from which DNS zone contents can be transferred. |
| | 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. |
| | AI Agent Authentication and Authorization |
| |
| | draft-klrc-aiagent-auth-02.txt |
| | Date: |
01/06/2026 |
| | Authors: |
Pieter Kasselman, Jeff Lombardo, Yaroslav Rosomakho, Brian Campbell, Nick Steele, Aaron Parecki |
| | Working Group: |
Individual Submissions (none) |
|
This document proposes best practices 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. |
| | AGTP Agent Certificate Extension |
| |
|
The Agent Transfer Protocol (AGTP) base specification defines agent identity headers (Agent-ID, Owner-ID, Authority-Scope) that are self- asserted: present on every request and mandatory for logging, but not cryptographically verified at the transport layer. This document specifies the AGTP Agent Certificate Extension: an optional mechanism that binds Agent-ID, Owner-ID, and Authority-Scope to an X.509 v3 certificate presented during TLS mutual authentication. The extension enables infrastructure components including Scope- Enforcement Points (SEPs), load balancers, and governance gateways to verify agent identity and enforce authority scope without application-layer access, at O(1) cost per request header check. The extension also defines session-level revocation propagation via AGTP NOTIFY broadcast and a Certificate Transparency Log for tamper- evident governance metadata. Note: Certain mechanisms described in this document may be subject to pending patent applications by the author. The licensor is prepared to grant a royalty-free license to implementers consistent with the IETF's IPR framework. See the IPR Notice and Section 7. |
| | DNS Root Server System Usage Considerations |
| |
|
This document explores various technologies developed to enhance the DNS, focusing specifically on interactions with the DNS Root Server System (RSS). It examines a number of the protocols and evaluates their impact on communication with the RSS. |
| | The DID-CHALLENGE SASL Mechanism |
| |
|
This specification defines "DID-CHALLENGE", a mechanism for the Simple Authentication and Security Layer (SASL) based on Decentralized Identifiers (DIDs). The mechanism follows a server- first challenge/response pattern in which the client authenticates by producing a cryptographic signature over a server-generated challenge, using the private key associated with its DID. Unlike password-based SASL mechanisms, no shared secret is transmitted or stored on the server; authentication is grounded entirely in asymmetric cryptography and the verifiable binding between a DID and its associated key material. An optional extension adds support for Verifiable Credentials (VCs) and Verifiable Presentations (VPs), enabling attribute-based access control in addition to identity authentication. |
| | IPv6 Networking Considerations for AI Agent Communication |
| |
|
AI agents are increasingly expected to communicate across platforms, organizations, clouds, edge environments, and administrative domains. Current agent-related mechanisms mainly focus on description, discovery, identity, authentication, authorization, tool invocation, and application-layer collaboration. These mechanisms are important, but they often treat the IP network as a transparent connectivity substrate. This document describes networking problems that arise when AI agents perform cross-domain communication and continuous tool, API, data, and agent-to-agent calls. It focuses on problem description rather than a protocol solution. In particular, it discusses gaps related to agent identity visibility at the network layer, path control, audit continuity, the separation of discovery from addressing and authorization, and privacy and privilege risks introduced by highly autonomous agents. The document positions Agent6 as a problem space for network support of cross-domain AI agent collaboration. It does not define a new agent discovery protocol, a new application-layer collaboration protocol, a new authentication or authorization mechanism, or a new IPv6 extension header. |
| | AGTP Identifier Chain |
| |
|
This document specifies the AGTP identifier chain: a layered model of identifiers that together produce a tamper-evident chain of custody across every action an AGTP agent takes. The chain is composed of identifiers already established in the AGTP draft family (Agent-ID, Owner-ID, Session-ID, Task-ID, and the Attribution-Record envelope of base AGTP) together with a small set of additional identifiers introduced by this document (Request-ID, Response-ID, Action-ID, Evaluation-ID, Decision-ID, Audit-ID). The Audit-ID is the cryptographic hash of an extended Attribution-Record and provides the per-agent hash chain that links every action an agent takes back to its Agent Genesis. This document defines the identifiers, how they extend the existing Attribution-Record envelope, the construction of the hash chain, and the verification procedure by which a regulator, auditor, or counterparty reconstructs the chain end to end. The identifier chain is the regulatory backbone of AGTP. Without it, the protocol can record that something happened but cannot prove who caused it, what authorized it, or what was decided. |
| | Semantic Interoperability for the Judgment Event Protocol |
| |
|
This document defines semantic interoperability requirements for the Judgment Event Protocol (JEP). JEP-Core defines the event syntax, event classes, signatures, hashes, references, extension processing, and validation levels for signed judgment-related events. This document does not modify those mechanisms. Where this document restates JEP-Core semantics, JEP-Core remains authoritative. Instead, this document defines the minimum shared semantic invariants required for independent systems to interpret JEP events consistently across implementations, profiles, organizations, and jurisdictions. The document specifies core semantic roles, core semantic relations, event- class interpretation rules for Judgment, Delegation, Termination, and Verification events, verification-scope semantics, semantic identifiers, profile-extension constraints, semantic validation results, non-inference rules, semantic conformance requirements, initial semantic registry requirements, and cross-jurisdictional boundaries. It defines semantic registry contents and constraints, but does not define operational registry governance beyond the requirements stated here. This document does not define legal effect, moral responsibility, regulatory compliance, runtime enforcement, access-control decisions, domain-specific workflows, or external truth. A JEP event is a protocol- semantic record. Whether that record is sufficient to support an external target claim is outside the scope of this document and must be determined by an applicable profile, evidence policy, domain rule, or target-support analysis. |
| | SIP Digest Authentication with X25519 Shared Secrets and Ristretto255 Schnorr Proofs |
| |
|
This document defines three Session Initiation Protocol (SIP) Digest authentication algorithms that replace password-derived Digest secrets with public-key-based authentication material. Two algorithms derive a response secret from an X25519 shared secret, and one algorithm uses a Fiat-Shamir Schnorr proof over the ristretto255 group. The mechanisms defined here preserve the existing SIP Digest challenge and authorization header flow while adding Digest parameters that carry public keys and, optionally, an authenticated server challenge proof. |
| | Post-quantum Key Encapsulation with ML-KEM in Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) |
| |
|
This document specifies extensions to the Kerberos PKINIT pre- authentication mechanism [RFC4556] [RFC8636] to support post-quantum key establishment using the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) algorithms defined in [FIPS203]. The extensions define a new kemInfo arm in PA-PK-AS-REP, a KDCKEMInfo structure signed by the KDC, HKDF-based AS reply key derivation (HKDF-SHA-512 for ML-KEM), downgrade-prevention rules, and a PAChecksum2 extension providing checksum algorithm agility in PKAuthenticator. The KEM path framework supports multiple KEM algorithms including ML-KEM, composite ML-KEM algorithms, and future KEM standards. |
| | OpenHTTPA: Hypertext Transfer Protocol with Attestation |
| |
|
OpenHTTPA (Hypertext Transfer Protocol with Attestation) defines a protocol for establishing hardware-verified, end-to-end confidential and authenticated communication between a client and a Trusted Execution Environment (TEE) over standard HTTP/2, HTTP/3, and gRPC transports. Unlike traditional TLS which terminates at the network edge, OpenHTTPA ensures that the cryptographic session terminates inside the hardware-isolated enclave. The protocol is based on the SIGMA-I model and incorporates post-quantum hybrid key exchange (ML- KEM), post-quantum digital signatures (ML-DSA), transcript-bound hardware attestation, and semantic binding of HTTP requests to the hardware-verified session state. |
| | Security Considerations for Model Context Protocol (MCP) Implementations in AI Agent Systems |
| |
|
The Model Context Protocol (MCP) connects large language models (LLMs) to external tools, data sources, and services. The MCP specification does not define normative security requirements. This document analyzes recurring vulnerability classes that have been publicly reported in MCP server implementations, describes an automated detection approach implemented in the open-source tool mcp- safeguard, and proposes security considerations and mitigations for implementors and operators. The document also describes Protocol Pivoting, a cross-protocol lateral-movement pattern in systems that compose MCP with other agent protocols. |
| | Text in RFCs |
| |
|
This document sets policy for the inclusion of characters in the definitive versions and publication formats of RFCs. The policy for the RFC Series is that all displayable text is allowed as long as there is a high expectation that readers of an RFC will be able to interpret its text as intended. This document obsoletes RFC 7997. |
| | Problem Statement,Gap Analysis,and Requirements for Intra-domain Source Address Validation |
| |
|
Source address validation (SAV) is an important means to mitigate IP source address spoofing [RFC2827]. This document analyzes the gaps in current operational mechanisms for intra-domain SAV. It also identifies the properties that new intra-domain SAV mechanisms are expected to provide. |
| | Structured Email |
| |
|
This document specifies how a machine-readable variant of its content can be added to email messages. |
| | Selective Disclosure CBOR Web Tokens (SD-CWT) |
| |
| | draft-ietf-spice-sd-cwt-08.txt |
| | Date: |
01/06/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. |
| | YANG Data Models for Network Resource Partitions (NRPs) |
| |
| | draft-ietf-teas-nrp-yang-06.txt |
| | Date: |
01/06/2026 |
| | Authors: |
Bo Wu, Dhruv Dhody, Vishnu Beeram, Tarek Saad, Shaofu Peng |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
RFC 9543 describes a framework for Network Slices in networks built from IETF technologies. In this framework, the network resource partition (NRP) is introduced as a collection of network resources allocated from the underlay network to carry a specific set of Network Slice Service traffic and meet specific Service Level Objective (SLO) and Service Level Expectation (SLE) characteristics. This document defines two YANG data models for Network Resource Partitions (NRPs): a network-level model for policy configuration by a Network Slice Controller, and a device-level model for configuration of individual network elements. These models enable automated provisioning of NRPs in IP/MPLS and Segment Routing (SR) networks, supporting scalable realization of RFC 9543 Network Slice Services. |