| |
|
| |
| | Characterization and Benchmarking Methodology for Power in Networking Devices |
| |
| | draft-ietf-bmwg-powerbench-02.txt |
| | Date: |
30/06/2026 |
| | Authors: |
Carlos Pignataro, Romain Jacob, Giuseppe Fioccola, Qin WU, Gen Chen, Shailesh Prabhu |
| | Working Group: |
Benchmarking Methodology (bmwg) |
|
This document defines a standard mechanism to measure, report, and compare power usage of different networking devices under different network configurations and conditions. |
| | CBOR Encoded X.509 Certificates (C509 Certificates) |
| |
| | draft-ietf-cose-cbor-encoded-cert-20.txt |
| | Date: |
30/06/2026 |
| | Authors: |
John Mattsson, Goeran Selander, Shahid Raza, Joel Hoglund, Martin Furuhed, Lijun Liao |
| | Working Group: |
CBOR Object Signing and Encryption (cose) |
|
This document specifies a CBOR encoding of X.509 certificates. The resulting certificates are called C509 certificates. The CBOR encoding supports a large subset of RFC 5280 and common certificate profiles, and it is extensible. Two types of C509 certificates are defined. One type is an invertible CBOR re-encoding of DER-encoded X.509 certificates with the signature field copied from the DER encoding. The other type is identical except that the signature is computed over the CBOR encoding instead of the DER encoding, thereby avoiding the use of ASN.1. Both types of certificates have the same semantics as X.509 while providing comparable size reduction. This document also specifies CBOR-encoded data structures for certification requests and certification request templates, new COSE headers, as well as a TLS certificate type and a file format for C509. This document updates RFC 6698 by extending the TLSA selectors registry to include C509 certificates. |
| | Terminology for Energy Efficiency Network Management |
| |
| | draft-ietf-green-terminology-02.txt |
| | Date: |
30/06/2026 |
| | Authors: |
Gen Chen, Mohamed Boucadair, Qin WU, Luis Contreras, Marisol Amador |
| | Working Group: |
Getting Ready for Energy-Efficient Networking (green) |
|
Energy-efficient network management is primarily meant to enhance conventional network management with energy-related management capabilities that optimize overall network energy consumption. To that aim, specific features and capabilities are required to control (and thus optimize) the energy use of involved network elements and their components. This document defines a set of key terms used within the IETF when discussing energy efficiency in network management. Such reference document helps framing discussion and agreeing upon a set of main concepts in this area. |
| | An HTTPS-based Transport for YANG Notifications |
| |
|
This document defines a protocol for sending asynchronous event notifications similar to notifications defined in RFC 5277, but over HTTPS. YANG modules for configuring publishers are also defined. Examples are provided illustrating how to configure various publishers. This document requires that the publisher is a "server" (e.g., a NETCONF or RESTCONF server), but does not assume that the receiver is a server. |
| | The Transit Measurement Option |
| |
|
This document specifies an IPv6 option that contains a compact set of fields which can be used for transit delay measurement and congestion detection. This option can be incorporated into data packets and updated by transit nodes along the path, enabling lightweight measurement and monitoring using constant-length data that does not depend on the number of hops in the network. |
| | Bitwise IP Filters for BGP FlowSpec |
| |
|
This document introduces the bitwise match filter component for source and destination IPv4/IPv6 address fields. These components enhance the BGP Flow Specification framework and provide a solution for dynamic symmetric traffic load-balancing. |
| | Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Residual Bit Error Rate Measurement |
| |
|
The Simple Two-Way Active Measurement Protocol (STAMP), as defined in RFC 8762, along with its optional extensions specified in RFC 8972, can be utilized for active measurement. Networks may experience transmission bit errors due to various factors, including poor fiber quality. Even with efficient CRC and FEC mechanisms, some bit errors may escape detection and correction, referred to as residual bit errors. This document further augments the STAMP extensions specified in RFC 8972 to enable the measurement of the residual bit error rate within the "Extra Padding" TLV of STAMP test packets. |
| | Media over QUIC - Lite |
| |
|
moq-lite is designed to fanout live content 1->N across the internet. It leverages QUIC to prioritize important content, avoiding head-of- line blocking while respecting encoding dependencies. While primarily designed for media, the transport is payload agnostic and can be proxied by relays/CDNs without knowledge of codecs, containers, or encryption keys. |
| | OAuth2.0 Extension for Multi-AI Agent Collaboration |
| |
|
This method extends OAuth 2.0 by adding fields to token and message flows, enabling sub-agents to act as a task group. It simplifies authorization for task groups, avoids repeated interactions between sub-agents and the authorization server, and bounds the authority delegated to the group and to each member while maintaining compatibility with existing OAuth 2.0 workflows. |
| | Secure Intent Protocol: JWT Compatible Agentic Identity and Workflow Management |
| |
|
This document specifies Agentic JSON Web Token (Agentic JWT), as an extension to OAuth 2.0 that addresses authorization challenges unique to autonomous agentic AI systems. This protocol solves the problem of Zero-Trust drift due to non-deterministic Agentic AI clients causing separation between user's (resource owner's) intent and client application's actions. Traditional OAuth 2.0 assumes that client applications faithfully represent user intent when requesting authorization. This assumption breaks down when autonomous AI agents dynamically generate workflows, create sub-agents, and make authorization decisions without continuous human oversight. We term this the "intent-execution separation problem." Agentic JWT introduces three mechanisms to address this problem: (1) cryptographic agent identity through agent checksums (based on agent's system prompts, tools and configurations), (2) workflow-aware token binding that links user intent to agent execution, and (3) a new OAuth 2.0 grant type (agent_checksum) for secure token issuance, (4) a flavor of PoP (Proof-of-Possession) at the level of an agentic identity to prevent token replays by other agents in the same multi- agent process. This specification enables Zero-Trust security principles in multi- agent systems while maintaining backward compatibility with existing OAuth 2.0 infrastructure. The security analysis and experimental validation are described in the companion research paper. |
| | RADIUS Chargeable-Device-Identity and Persistent Device Identification in MAC-Randomized Environments |
| |
|
This document defines a Chargeable-Device-Identity (CDI) -- a privacy- preserving, rotating device correlator carried in existing RADIUS Class attributes -- that enables Network Access Control (NAC) systems to maintain device session correlation across Media Access Control (MAC) address changes. Modern operating systems randomize MAC addresses by default, disrupting RADIUS-based authentication, authorization, and accounting workflows that rely on the Calling- Station-Id attribute as a persistent device identifier. CDI is modeled after the Chargeable-User-Identity (CUI) defined in RFC 4372, providing an analogous device-level correlator with explicit privacy controls: epoch-based rotation limits long-term tracking, HMAC construction prevents identifier reversal by intermediate systems, and transport within the Class attribute ensures immediate deployability on existing infrastructure. This document additionally defines a new RADIUS attribute, Persistent-Device-Id, for deployments that require explicit device identity semantics beyond what the opaque Class attribute can provide. The Class-based CDI mechanism is the RECOMMENDED approach for immediate deployment; the dedicated attribute provides a migration path for future interoperability. |
| | Heterogeneous Credential Verification for Workload and Agentic Systems |
| |
|
Workloads in multi-system environments, including AI agents acting on behalf of users and organizations, increasingly present multiple credentials of heterogeneous types within a single request: workload identity tokens, user-delegated OAuth access tokens, W3C Verifiable Presentations, X.509 certificates, or platform-specific API keys. These are issued by different authorities, follow different formats, are verified by different verifiers, and carry different assurance semantics. A relying party that receives such a heterogeneous credential set has no common way to represent the set, identify each credential's type, determine the authoritative verifier for it, interpret verification results consistently, or combine multiple results into a single handling decision. This document defines a mechanism for processing a heterogeneous credential set on receipt. It specifies a representation of the credential set, a procedure for identifying each credential's type and determining its verifier, a minimal common model for verification results that lets results from different verifiers be compared, and a policy model that combines multiple results into one handling decision. The mechanism is transport-agnostic and does not constrain where the processing functions are deployed. |
| | Quantum-Ready Profiles for ACME |
| |
|
This document updates RFC 8555 (ACME) to specify post-quantum and PQ/ T hybrid cryptographic requirements for quantum-ready deployments. The Automatic Certificate Management Environment (ACME) automates certificate issuance, validation, and management over HTTPS using JSON Web Signatures (JWS) to authenticate client request payloads. Current ACME deployments rely on traditional public-key algorithms in both JWS and TLS, which are vulnerable to attacks from Cryptographically Relevant Quantum Computers (CRQCs). These profiles define PQC or PQ/T TLS 1.3 key establishment and specify PQC or PQ/T authentication mechanisms for JWS and TLS where required by the selected quantum-ready profile. Together, these profiles enable ACME clients and servers to achieve quantum-resistant confidentiality and authentication. |
| | Registry Lock Extension for the Extensible Provisioning Protocol (EPP) |
| |
|
This document describes an Extensible Provisioning Protocol (EPP) extension for setting and managing a registry lock on a domain object. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/EricIO/draft-regext-epp-registry-lock (https://github.com/EricIO/draft-regext-epp-registry-lock). The most recent working version of the document, open issues, etc. should all be available there. The authors (gratefully) accept pull requests. |
| | Media over QUIC Overview |
| |
|
This document provides a high-level overview of the Media over QUIC (MoQ) protocol suite. It describes the architecture, data model, transport protocol, streaming formats, and security mechanisms that together enable scalable low-latency media delivery over the Internet. The document explains how these components relate to each other and how they are composed to create interoperable media applications. |
| | Governed Action Protocol (GAP) |
| |
|
The Governed Action Protocol (GAP) is an open wire protocol for a Universal Action Coordination Fabric. GAP defines a four-phase lifecycle (Declare, Grant, Invoke, Receipt) that governs every action an AI agent, smart device, industrial controller, or automated pipeline may take. Every gate decision produces a content-addressed, immutable receipt; receipts are signed at L2+ (Ed25519) and L4 (hybrid ML-DSA-65). The protocol is designed to be language- and platform-neutral, applicable across enterprise AI agent pipelines, consumer smart home devices, medical equipment, industrial control systems, and game engines. This document specifies the wire format, object model, grant evaluation rules, HTTP API surface, workflow semantics, revocation mechanisms, and conformance tiers for GAP version 1.0. |
| | Distributed and Decentralized Uses of MLS |
| |
|
The Messaging Layer Security (MLS) protocol provides continuous key agreement and offers additional benefits in multi-device group use cases. MLS relies on a Delivery Service (DS) for message ordering. In highly centralized uses, where the DS is a single server, configuration is straightforward. However, MLS also lends itself to use cases that are decentralized (e.g., federated networks) and even distributed (e.g., mesh networks). This informational document lays out uses of MLS and its variants and extensions across various topologies and provides guidance on selection among alternatives under both functionality and security considerations. |
| | A Gateway for Network Knowledge Graph Management |
| |
|
This document specifies an interaction gateway for Network Knowledge Graphs (NKGs) to simplify graph-based network operations. The gateway architecture defines a Unified Intent Gateway (UIG) that supports Natural Language (NL) requests from human operators and Domain-Specific Language (DSL) or API directives from applications and orchestration systems. The UIG interprets user expectations and application directives as structured intents, aligns them with the NKG structure and exposed capabilities, and maps them to graph queries, graph inferences, API calls, or operational workflows through an Intermediate Representation (IR). The gateway architecture incorporates intent discovery, capability mapping, policy enforcement, audit logging, and response synthesis to make NKG-based operations more accessible, secure, and controllable. |
| | Threat Model for BGP Color Extended Community |
| |
|
The BGP Color Extended Community carries a user-defined Color value that is configured locally and has no globally standardized semantics. Although this design is suitable for local policy expression, it raises security concerns when Color values are propagated across Autonomous System (AS) boundaries and used to influence forwarding behavior in another domain. This document describes a threat model for that context, following the structure used by RFC 7132. It defines relevant terminology, characterizes the classes of adversaries considered to be threats, examines the classes of attacks that those threats are able to effect against Color-based forwarding, and concludes with a discussion of residual vulnerabilities. It does not revisit attacks against unprotected BGP, and it defines no new protocol mechanism. |
| | BGP Extension for AI Compute Service Metadata |
| |
|
This document defines a new optional transitive BGP Path Attribute named AI Compute Service Metadata, which carries three categories of dedicated Sub-TLVs for generative AI inference over inter-domain BGP routes. Existing CATS framework and generic BGP compute metric drafts lack inference-specific metadata covering inference SLA, token billing cost, and KV cache prefix index. Re-computing context without matched cache prefixes raises GPU overhead and user billing expense. This specification defines a new top-level optional transitive BGP Path Attribute named AI Compute Service Metadata, which encapsulates three independent Sub-TLVs to advertise inference SLA metrics, billing parameters, and cache prefix indexes. All metadata carried within this Path Attribute is flooded across multi-domain routing fabrics, supporting two core use cases: matching compute instances based on latency and cost requirements, and dispatching tasks to nodes with matched reusable KV cache to reduce resource consumption. |
| | BGP RR Deployment Considerations |
| |
|
In BGP networks, Route Reflectors (RRs) help to simplify IBGP control plane provisioning as well as mitigate the session scale challenges associated with an IBGP full mesh between border routers. Given these operational benefits, RRs are widely deployed in modern BGP network architectures. This document describes common RR deployment models, including their respective trade-offs, and provides best practice suggestions based on years of industry experience. Operators of BGP networks should consider and/or adopt these best practices, as BGP control plane stability is critical to overall network stability. |
| | The JSON vCon - Contact Center Extension |
| |
|
A vCon is container for data and information relating to a human conversation. This document defines an extension for the JSON vCon schema in support of call, support or contact center application of the vCon conversational data exchange format. |
| |
|
| |
| | Extended Procedures for EVPN Optimized Ingress Replication |
| |
|
In the Virtualization Overlay (NVO) network with Ethernet VPN (EVPN), optimized ingress replication uses Assisted-Replication (AR) to achieve more efficient delivery of Broadcast and Multicast (BM) traffic. An AR-LEAF, which is a Network Virtualization Edge (NVE) device, forwards received BM traffic from its tenant system to an AR- REPLICATOR. The AR-REPLICATOR then replicates it to the remaining AR-LEAFs in the network. However, when replicating the packet on behalf of its multihomed AR-LEAF, an AR-REPLICATOR may face challenges in retaining the source IP address or including the expected Ethernet Segment Identifier (ESI) label that is required for EVPN split-horizon filtering. This document extends the optimized ingress replication procedures to address such limitations. The extended procedures specified in this document allow the support of EVPN multihoming on the AR-LEAFs as well as optimized ingress replication for the rest of the EVPN NVO network. |
| | CDNI Cache Control Metadata |
| |
|
This specification adds new Cache Control objects that complement the basic Cache Control Metadata object defined in RFC8006, providing content providers and upstream Content Delivery Networks (uCDNs) more fine-grained control over downstream CDN (dCDN) caching. Use cases include overriding or adjusting cache control headers from the Content Service Provider (CSP) source or origin, bypassing caching altogether, or altering cache keys with dynamically generated values. |
| | CDNI Metadata Expression Language |
| |
|
This document specifies the syntax and provides usage examples for an expression language to be used within Content Delivery Network Interconnection (CDNI) Metadata Interface (MI) objects. The purpose of this expression language is to enable metadata to be applied conditionally (based on aspects of an HTTP request), and to enable Hypertext Transfer Protocol (HTTP) responses to be generated or altered dynamically. |
| | BBS per Verifier Linkability |
| |
|
The BBS Signatures scheme describes a multi-message digital signature, that supports selectively disclosing the messages through unlinkable presentations, built using zero-knowledge proofs. Each BBS proof reveals no information other than the signed messages that the Prover chooses to disclose in that specific instance. As such, the Verifier (i.e., the recipient) of the BBS proof, may not be able to track those presentations over time. Although in many applications this is desirable, there are use cases that require the Verifier be able to track the BBS proofs they receive from the same Prover. Examples include monitoring the use of access credentials for abnormal activity, assertion of pseudonymous identity, monetization, etc.. This document provides a mechanism for binding prover secret material for pseudonym creation to a BBS signature and shows how to use this bound information for the creation of context dependent pseudonyms in BBS proofs. |
| | SR Policy Extensions for Path Segment and Bidirectional Path |
| |
|
BGP SR Policy address-family is used for signaling of individual candidate paths of a Segment Routing Policy. This document specifies extensions for the signaling of a Path Segment Identifier associated with the Segment List(s) of a candidate path. It also specifies extensions for the signaling of the Segment List(s) in the reverse direction when Bidirectional SR Policies are used. |
| | Key Transparency Architecture |
| |
|
This document defines the terminology and interaction patterns involved in the deployment of Key Transparency in a general secure group messaging infrastructure, and specifies the security properties that the protocol provides. It also gives more general, non- prescriptive guidance on how to securely apply Key Transparency to a number of common applications. |
| | A YANG Model for BGP-LS,BGP-LS-VPN,and BGP-LS-SPF |
| |
|
This document defines a YANG data model for configuration and management of BGP-LS, BGP-LS-VPN, and BGP-LS-SPF. |
| | MPLS Network Action for Deterministic Networking |
| |
| | draft-ietf-mpls-mna-detnet-01.txt |
| | Date: |
29/06/2026 |
| | Authors: |
Xueyan Song, Greg Mirsky, Balazs Varga, Rakesh Gandhi, Quan Xiong |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
|
This document specifies formats and mechanisms for using MPLS Network Actions (MNA) to support Deterministic Networking (DetNet) services, including bounded latency, low loss and in-order delivery. It defines MPLS In-Stack and Post-Stack MNA for carrying DetNet-specific information, such as flow identification, sequence number, and latency information, which are forwarded over an MPLS technology- based network domain. |
| | Updated YANG Module Revision Handling |
| |
|
This document refines the RFC 7950 module update rules. It specifies a new YANG module update procedure that can document when non- backwards-compatible changes have occurred during the evolution of a YANG module. It extends the YANG import statement with a suggestion for a minimum revision. This helps document inter-module dependencies. It provides guidelines for managing the lifecycle of YANG modules and individual schema nodes. This document updates RFC 7950, RFC 6020, RFC 8525, and RFC 9907. |
| | A CoRIM Profile for Arm's Platform Security Architecture (PSA) Endorsements |
| |
|
PSA Endorsements comprise reference values, endorsed values, cryptographic key material and certification status information that a Verifier needs in order to appraise Attestation Evidence produced by a PSA device. This memo defines PSA Endorsements as a profile of the CoRIM data model. |
| | Deploying Publicly Trusted TLS Servers on Devices Behind NAT Using SNI-based End-to-End TLS Forwarding (SNIF) |
| |
|
This document proposes a solution, referred to as SNIF, that provides the means for any Internet-connected device to: * allocate a globally unique anonymous hostname; * obtain and maintain a publicly trusted X.509 certificate issued for the allocated hostname; * accept incoming TLS connections on specific TCP ports of the allocated hostname from any TLS clients that are capable of sending Server Name Indication. The private key associated with the X.509 certificate is securely stored on the TLS terminating device, and is never exposed to any other party at any step of the process. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-zubov-snif. Information can be found at https://snif.host. Source for this draft and an issue tracker can be found at https://github.com/vesvault/snif-i-d. |
| | MIMI Portability |
| |
|
This document describes MIMI Portability mechanisms. |
| | MIMI Attachments |
| |
|
This document describes MIMI Attachments. |
| | The IETF Chair May Delegate |
| |
|
This document affirms that the IETF Chair may delegate some of their responsibilities to other Area Directors, and updates several existing RFCs to enable that. |
| | XET: Content-Addressable Storage Protocol for Efficient Data Transfer |
| |
|
This document specifies XET, a content-addressable storage (CAS) protocol designed for efficient storage and transfer of large files with chunk-level deduplication. XET uses content-defined chunking to split files into variable-sized chunks, aggregates chunks into containers called xorbs, and enables deduplication across files and repositories through cryptographic hashing. |
| | Export of Segment Routing Policy Attributes in IP Flow Information Export (IPFIX) |
| |
|
This document defines new IP Flow Information Export (IPFIX) Information Elements (IEs) to export attributes of Segment Routing (SR) and Segment Routing over IPv6 (SRv6) policies applied to IP flows, which enables correlation between observed traffic flows and the SR/SRv6 policies that carry them. |
| | Principal Agent Protocol (PAP) |
| |
|
This document specifies the Principal Agent Protocol (PAP), a cryptographic protocol for human-controlled agent-to-agent transactions. PAP establishes a trust model rooted in human principals, defines hierarchical delegation through signed mandates, enforces context minimization through selective disclosure at the protocol level, and provides session ephemerality as a structural guarantee. The protocol uses no novel cryptographic primitives and requires no central registry, token economy, or trusted third party. |
| | 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. |
| | The IETF Chair Has an Emergency Stand-In |
| |
|
This document defines a succession of emergency stand-ins in case the IETF Chair becomes incapacitated. |
| | Using QUIC Stream Resets with Partial Delivery in HTTP/3 |
| |
|
QUIC stream resets do not guarantee delivery of stream data sent before the reset. This is a problem for HTTP/3 when the correct protocol outcome is an abrupt stream termination, but the sender still has a bounded prefix worth delivering, such as response headers, a short diagnostic response body, or a partial response received from an upstream host. RESET_STREAM_AT provides reliable delivery of that prefix and is already used by WebTransport over HTTP/3 when resetting streams. The same mechanism also fits HTTP/3 CONNECT tunnels, intermediary failures after response commitment, malformed decoded HTTP messages, and requests rejected before application processing. |
| | Information Requirements for Monitoring Source Address Validation (SAV) Enforcement |
| |
|
Source Address Validation (SAV) enforcement requires operational visibility into validation results, traffic-handling outcomes, SAV rule generation and state, and SAV configuration. Such visibility helps operators understand how SAV operates in the network and supports operational decisions, including staged deployment where traffic that fails validation may be permitted while being monitored and analyzed. This document identifies information requirements for monitoring SAV enforcement. |
| | BGP Signaling of MASQUE Tunnel Encapsulation |
| |
|
This document defines BGP Tunnel Encapsulation Attribute tunnel types for MASQUE CONNECT-TCP, CONNECT-UDP, CONNECT-IP, and CONNECT- ETHERNET. It also defines URI Template and ALPN Sub-TLVs for advertising the MASQUE proxy endpoint, the HTTP request target template, and the application-layer protocol constraints used to establish the corresponding MASQUE tunnel. |
| | Rank,a Resource Management Protocol for Allocation |
| |
| | draft-lopes-rank-00.txt |
| | Date: |
29/06/2026 |
| | Authors: |
Rui Lopes, Duarte Raposo, Susana Sargento |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies Rank, a comprehensive resource management protocol designed for modern edge-to-cloud computing infrastructures. While traditional network protocols focus primarily on managing link bandwidth and router buffer space, the shift toward decentralized services demands a broader approach to resource allocation. Rank addresses this gap by simultaneously managing computing capabilities (such as CPU, memory, and storage), network capacity, and time- sensitive constraints (such as clock synchronization and task scheduling) within a unified framework. Operating primarily as a fully distributed protocol, Rank enables dynamic resource discovery, estimation, allocation, and sharing. It works by establishing a path between a source ("talker") and a destination ("listener") node, actively negotiating resource requirements across all intermediate nodes. Because it is fully distributed, all participating nodes carry equal responsibility in handling a session, such as processing requests, evaluating their own capacity to meet the resource demands, and strategically forwarding messages to ensure an optimized, end-to-end connection without relying on a centralized controller. |
| | AgIS: An Agent Identity System for DNS-Backed Verification of AI and Software Agents |
| |
|
This document specifies AgIS, the Agent Identity System, a DNS-backed identity and verification profile for AI agents, autonomous software agents, and agentic services operating on the existing web. AgIS defines an agent identifier form, DNS TXT bindings, Agent Cards, key thumbprints, status and revocation documents, signed HTTP request verification, replay protection, delegation tokens, and delegation chains. The design intentionally reuses existing Internet mechanisms, including DNS, HTTPS well-known resources, JSON Web Keys, JSON canonicalization, HTTP Message Signatures, and HTTP digest fields. This document describes the AgIS 0.2.2 wire/profile format and the behavior exercised by the AgIS v0.3.0-alpha.3 reference implementation and its 23 deterministic test vectors. That implementation includes signed Agent Cards, HTTP Message Signature verification, two-phase replay protection, delegation signer-key binding enforced by default, and signed agent status document support. It does not define a global trust authority, a production trust network, or a new public-key infrastructure. This is an individual Internet-Draft and a work in progress. It has not been approved by the IETF, does not represent an IETF standard or RFC, and has not been adopted by any IETF working group. AgIS is designed to be compatible with agent naming services such as Linux Foundation ANS and similar systems. AgIS is not affiliated with, endorsed by, or a replacement for Linux Foundation ANS or any global naming authority. AgIS defines verification, governance, and request-signing behavior that operates over identity evidence that may originate from ANS or any comparable naming layer. |
| | HPC/AI Scheduler Job Metadata Model |
| |
|
This document defines a scheduler-facing metadata model for High Performance Computing (HPC) and AI workloads. The model captures common job, workload, scheduler, tenant, timing, and task metadata that can be mapped from heterogeneous workload managers and orchestration platforms and used as context for network service intent. |
| | HPC/AI Service Intent Model |
| |
|
This document defines a common service intent model for High Performance Computing (HPC) and AI workloads over High Performance Wide Area Networks (HP-WANs). The model allows heterogeneous workload managers and orchestration platforms to express endpoint, communication pattern, timing, performance, data movement, policy, and admission requirements for network services without exposing technology-specific tunnel realization details. |
| | HPC/AI Service Intent Tunnel Realization Model |
| |
|
This document defines a tunnel realization model for admitted HPC and AI service intent. The model describes how a service intent instance can be associated with network realization state, including tunnel references, lifecycle, path, policy, resources, protection, admission outcome, and performance monitoring. |
| | Intra-domain Source Address Validation Architecture |
| |
|
This document describes a generic architecture for intra-domain Source Address Validation (SAV). It provides a common framework for developing new intra-domain SAV mechanisms and describes the conditions under which such mechanisms can improve SAV accuracy with respect to existing intra-domain SAV mechanisms. |
| | 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 (EBGP) sessions. Annotating routes with BGP Path Attributes carried across EBGP 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 EBGP sessions. Specifically, operators should not associate Prefix Origin Validation state with BGP routes using any form of BGP Communities carried across EBGP session. |
| |
|
| |
| | Ownership and licensing statements in YANG |
| |
|
This memo provides for an extension to RFC 8520 (Manufacturer Usage Description Specification, MUD) that allows MUD file authors to specify ownership and licensing of MUD files themselves. This memo updates RFC 8520. However, it can also be used for purposes outside of MUD, and the grouping is structured as such. |
| | web-stream: A General Purpose Message Framing over Byte-Stream Oriented Wire Protocols |
| |
|
This document defines web-stream, a general-purpose message framing designed to support message-based communication over any byte-stream oriented L4 or L7 protocols, in particular HTTP as in its standard semantics [RFC9110]. web-stream can be viewed as a binary alternative to the framing defined for the server-sent events (SSE) [SSE]. This was the original goal when the initial version of this proposal was published in 2017. |
| | Adaptive IPv4 Address Space |
| |
|
This document describes a solution to the Internet address depletion issue through the use of an existing Option mechanism that is part of the original IPv4 protocol. This proposal, named EzIP (phonetic for Easy IPv4), outlines the IPv4 public address pool expansion and the Internet system architecture enhancement considerations. EzIP may expand an IPv4 address by a factor of 256M without affecting the existing IPv4 based Internet, or the current private networks. It is in full conformance with the IPv4 protocol, and supports not only both direct and private network connectivity, but also their interoperability. EzIP deployments may coexist with existing Internet traffic and IoTs (Internet of Things) operations without perturbing their setups, while offering end-users the freedom to independently choose which service. EzIP may be implemented as a software or firmware enhancement to Internet edge routers or private network routing gateways, wherever needed, or simply installed as an inline adjunct hardware module between the two, enabling a seamless introduction. The 256M case detailed here establishes a complete spherical layer of an overlay of routers for interfacing between the Internet fabric (core plus edge routers) and the end user premises or IoTs. Incorporating caching proxy technology in the gateway, a fairly large geographical region may enjoy address expansion based on as few as one ordinary IPv4 public address utilizing IP packets with degenerated EzIP header. If IPv4 public pool allocations were reorganized, the assignable pool could be multiplied 512M fold or even more. Enabling hierarchical address architecture which facilitates both hierarchical and mesh routing, EzIP can provide nearly the same order of magnitude of address pool resources as IPv6 while streamlining the administrative aspects of it. The basic EzIP will immediately resolve the local IPv4 address shortage, while being transparent to the rest of the Internet as a new parallel facility. Under the Dual-Stack environment, these proposed interim facilities will relieve the IPv4 address shortage issue, while affording IPv6 more time to reach maturity for providing the availability levels required for delivering a long-term general service. The basic EzIP may be deployed in two distinctive phases. First, the CG-NAT operation may be enhanced by enabling the use of 240/4 netblock in addition to the current 100.64/10 netblock of RFC6598. This makes end-to-end connectivity feasible within the service area of each 240/4 netblock. Second, this capability may extend to global coverage with the use of the Option Word mechanism in the IP header. |
| | Application-Responsive Network Framework |
| |
|
With the deployment of increasingly advanced technologies on a large scale, such as SRv6[RFC8402] 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. |
| | SRv6 Path Verification |
| |
|
SRv6 is being rapidly deployed and is currently primarily used in trusted-domain backbone networks. However, we have also observed that SRv6 is beginning to extend toward customer site devices, e.g., SD-WAN and enterprise network deployments. Both of the scenarios can be deployed in third-party clouds or at customer sites. This introduces certain security risks, such as packet injection and path manipulation attacks. Section 6 of [I-D.draft-ietf-spring-srv6-security] identifies these risks as well, including Section 6.2.1 on Modification Attacks and Section 6.2.3 on Packet Insertion. This proposal mitigates these risks by enhancing the HMAC mechanism defined in [RFC8754]. |
| | Strengthening DNS Query Aggregation against ECS-based Attacks |
| |
|
The DNS query aggregation mechanism is a critical defense against DNS cache poisoning attacks that exploit the "Birthday Paradox". However, recent research has revealed that flawed implementations of the EDNS Client Subnet (ECS) option, as specified in RFC 7871, can be exploited to bypass this defense. This allows attackers to force a resolver to issue multiple simultaneous queries for the same domain name by crafting queries with different ECS options. This vulnerability revives the classic DNS Birthday Attack, posing a significant threat to DNS resolvers and the clients they serve. Section 11.2 of RFC 7871 notes the general risk of Birthday Attacks and suggests marking whether responding nameservers send ECS options, but it does not define a concrete mechanism. This document turns that observation into a specified processing model for the ECS option in DNS resolvers. A resolver tracks, per zone, whether the authoritative servers use ECS: a "no-ECS-support" state forces query aggregation for zones that do not use ECS, and an "ECS-support" state lets a resolver treat an unexpected response without an ECS option (or one with a zero scope) as suspect for zones that do, such as content delivery networks. The document also describes how a resolver bounds the residual risk with a limit on simultaneous outstanding queries. It is offered as input that the working group could fold into a future revision of RFC 7871. |
| | Event and Webhook Delivery Semantics |
| |
|
Event- and webhook-based integrations are a common application-layer mechanism for interoperability across Internet services, yet they lack a shared delivery semantics contract. Existing implementations vary widely in retry behavior, acknowledgment signaling, failure classification, idempotency identifiers, and replay handling, resulting in fragile integrations and ambiguous operational expectations. This document defines a minimal, application-layer delivery semantics profile for event and webhook delivery over existing transports, and specifies a concrete binding for the Hypertext Transfer Protocol (HTTP). The profile constrains only sender-observable behavior and signaling; it does not impose receiver-side storage or processing requirements and does not redefine existing transport protocols. |
| | FAF: YAML Media Types for AI Project Context and Persistent Memory |
| |
|
This document specifies two YAML-based media types that together form a foundational AI-context layer (FAF): .faf for static project context (what an AI agent KNOWS about a project) and .fafm for persistent agent memory (what it REMEMBERS across sessions). .faf (application/vnd.faf+yaml, registered in the IANA vendor tree 2025-10-30) carries static project context — architecture, conventions, dependencies, goals — read once and treated as canonical. .fafm (application/vnd.fafm+yaml, registered 2026-05-13) carries persistent agent memory — facts, preferences, accumulated knowledge — which mutates across sessions and supports multiple profiles (voice and knowledge). The two formats share YAML 1.2 as base syntax and MIT-licensed distribution, but differ in lifecycle: .faf is static-read-once and .fafm is mutating-persisted. This document documents the existing vendor-tree registrations and defines the "faf" well-known URI, a discovery anchor that returns a .faf context document and may reference associated memory and agent resources. |
| | Agent Transfer Protocol (AGTP) |
| |
|
AI agents and agentic systems generate a growing volume of intent- driven, unstructured, and undifferentiated traffic that flows through HTTP indistinguishably from human-initiated requests. HTTP lacks the semantic vocabulary, observability primitives, and identity mechanisms required by agent systems operating at scale. Existing protocols described as Agent Group Messaging Protocols (AGMP), including MCP, ACP, A2A, and ANP, are messaging-layer constructs that presuppose HTTP as their transport. They do not address the underlying transport problem. This document defines the Agent Transfer Protocol (AGTP): a dedicated application-layer protocol for AI agent traffic. AGTP is a runtime contract negotiation substrate (RCNS): a transport that fixes only a eighteen-method protocol floor and negotiates any additional method surface at runtime between agent and server in a single round-trip, governed by the AGTP-API companion specification [AGTP-API], which defines the curated method catalog, path grammar, endpoint primitive, and synthesis semantics. Version 07 confirms the IANA-registered agtp:// URI scheme and IANA-assigned port 4480 for TCP/TLS and QUIC, formalizes Form 1a URI grammar (agtp://{agent-id}@{host}) for direct addressing, renames the Agent Manifest Document to the Agent Identity Document with an enumerated schema, redesigns the protocol-defined method floor to a 12-method set organized as six cognitive verbs (QUERY, DISCOVER, DESCRIBE, SUMMARIZE, PLAN, PROPOSE) and six mechanics verbs (EXECUTE, DELEGATE, ESCALATE, CONFIRM, SUSPEND, NOTIFY), establishes AGTP as a substrate for higher-level agent frameworks (MCP, A2A, ACP) carried as content types inside AGTP method invocations, renumbers AGTP-specific status codes out of HTTP- assigned space to avoid semantic collision, mandates explicit Content-Length framing with a prohibition on TLS socket-level half- close, adds a .well-known/agtp bootstrap convention per RFC 8615, deprecates the AGIS reference and the proposed AGTP-Methods specification by folding both into the unified AGTP-API contract layer, adds status codes 405 (Method Not Allowed), 459 (Method Violation), and 460 (Endpoint Violation) per the AGTP-API contract model, and adopts "Agent Genesis" as the canonical term for the permanent signed origin document. Version 06 prepared the IANA Service Name and Port Number application and consolidated the URI scheme registration. Version 05 restored the canonical Agent-ID as the primary identity primitive and decoupled Trust Tier 1 verification from DNS as a sole requirement. A canonical Agent-ID is derived from the agent's Agent Genesis hash and is authoritative in every AGTP protocol operation. Three equivalent verification paths are recognized for Trust Tier 1: DNS-anchored verification via RFC 8555 ACME challenge, log-anchored verification via Agent Genesis inclusion in an append-only transparency log aligned with RFC 9162 and RFC 9943 (SCITT), and hybrid verification combining DNS control with blockchain address ownership. Version 04 introduced normative integration hooks for the AGTP Merchant Identity and Agentic Commerce Binding specification [AGTP-MERCHANT], which defines the merchant- side identity model that complements AGTP's agent-side identity model. AGTP transport bindings for TCP/TLS and QUIC are specified in [AGTP-BINDINGS]. AGTP is designed to be composable with existing agent frameworks, not to replace them. |
| | Agent Transfer Protocol (ATP) |
| |
| | draft-li-atp-02.txt |
| | Date: |
28/06/2026 |
| | Authors: |
Xiang Li, Lu Sun, Yuqi Qiu, Zuyao Xu |
| | Working Group: |
Individual Submissions (none) |
|
The Agent Transfer Protocol (ATP) is a communication protocol designed for autonomous agents to exchange messages, requests, and events in a secure, structured manner. ATP supports the emerging Internet of Agents (IoA) paradigm, where autonomous agents operate across four deployment scenarios: household (small scale), service (medium scale), enterprise (large scale), cloud provider (huge scale), and etc. ATP employs a two-tier architecture where agents connect to the global Internet through ATP servers, enabling server-mediated communication for proper routing, security enforcement, and resource management. The protocol provides DNS-based service discovery using SVCB records, mandatory authentication via Agent Transfer Sender (ATS) policies and Agent Transfer Keys (ATK), and support for multiple interaction patterns including asynchronous messaging, synchronous request/response, and event-driven streaming. This specification defines the discovery mechanism, identity model, authentication framework, transport layer, and message semantics for ATP. |
| | AGTP Composition Profiles: Agent Group Messaging Protocols,External Identity Providers,and HTTP Gateways |
| |
|
The Agent Transfer Protocol (AGTP) operates as a substrate beneath several adjacent layers: Agent Group Messaging Protocols (AGMPs) such as the Model Context Protocol (MCP), the Agent-to-Agent Protocol (A2A), and the Agent Communication Protocol (ACP); external identity providers (OAuth, OIDC, enterprise IdPs); and HTTP-based clients that interact with agents through translation gateways. This document specifies the composition profiles for each of these adjacent layers, defining normative mapping rules between the adjacent layer and AGTP. Three composition families are specified. The AGMP composition profile specifies how MCP, A2A, and ACP messages are carried over AGTP, with mapping rules for identity, authority scope, delegation, and session fields between the AGMP and AGTP layers. The External Identity Provider composition profile specifies how AGTP agent identity composes with externally-issued credentials, treating "which agent" and "on whose behalf" as orthogonal axes. The HTTP Gateway composition profile specifies the translation surface for accepting HTTP traffic into AGTP- served agents as a REST adoption ramp. Across all three families, AGTP headers take precedence over equivalent adjacent-layer fields for all infrastructure-level routing, enforcement, and audit operations. Agents gain transport- level governance, observability, and identity without modification to the adjacent layers. |
| | 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. |
| | AGTP Agent Discovery and Name Service |
| |
|
The Agent Transfer Protocol (AGTP) enables agents to communicate once they know each other's canonical identifiers. This document specifies two layered mechanisms by which agents find each other and by which human-readable names resolve to Canonical Agent-IDs: the DISCOVER method, which queries for agents matching a capability description, and the Agent Name Service (ANS), which provides governed name-to-Agent-ID resolution. The architectural relationship is layered. AGTP-Presence [AGTP-PRESENCE] provides ambient awareness of agents within visibility scopes as a substrate property. DISCOVER operates over the Presence substrate to query the live population. ANS provides human-readable name resolution, analogous to DNS for the web, with name authorities federating across organizational boundaries. This document also introduces Anticipatory Discovery Services (ADS) as a forward-looking composition pattern where application-layer services preload agent awareness based on observed operational signals. DISCOVER and ANS together provide the application-layer interfaces for discovery and naming that compose with the substrate-level ambient discovery defined in [AGTP-PRESENCE]. |
| | DNS-Anchored Durable Identity for AI Agents (DNSid) |
| |
|
Autonomous software agents are being deployed across enterprise, cloud, and cross-organizational boundaries. These agents negotiate, transact, delegate, and produce work products that persist beyond their own ephemeral runtime. Current standards and initiatives for agent identity collectively address runtime authentication, authorization, lifecycle management, and tool interaction, but a gap remains: a durable, governance-backed identifier that lets a relying party determine and verify the accountable entity behind an agent it encounters, including agents that have since been retired or whose keys have rotated, and attribute past and present work products to that entity. Lifecycle-history verification is governed by the applicable log method and deployment scope. DNSid addresses the accountable layer of identity: the durable ownership anchor that existing agent identity standards do not provide. This document specifies DNSid, a minimal identity primitive that assigns each agent a Fully Qualified Domain Name (FQDN), binds it to an accountable entity identified by a DNS domain under that entity's control, and publishes a structured set of pointers in DNS TXT records to the agent's cryptographic keys, lifecycle log, and operational status. DNSid uses accountable-entity-controlled signatures for record integrity and an abstract append-only lifecycle log for history. It is designed to sit beneath existing identity, authentication, authorization, and agent interaction standards without competing with them. DNSid introduces no new DNS resource record types, opcodes, or response codes, and requires no changes to DNS resolvers, authoritative servers, or the DNS protocol. It applies to any agent that can be assigned an FQDN whose accountable entity can publish verification material; public discoverability of the agent is not required. |
| | AGTP Trust and Verification Specification |
| |
|
This document specifies the AGTP trust and verification model: the trust tiers an AGTP agent may occupy, the verification paths by which a Tier 1 agent's identity is established, the registration procedures by which a governance platform assigns a tier, and the trust score that is carried alongside an agent's identity to express runtime behavioral assessment. AGTP-TRUST is consumed by AGTP-aware infrastructure components (Scope-Enforcement Points, governance gateways, peer agents) for runtime trust-aware routing and authority decisions, and by registration authorities when issuing or evaluating Agent Genesis documents. This is an early working draft; the dimension catalog, computation methodology, and several aspects of the registration procedure are placeholders pending further work. |
| | Markdown Structured Object Notation (MaSON) |
| |
|
This document defines MaSON (Markdown Structured Object Notation), a lightweight data serialization format that maps standard Markdown syntax trees into structured key-value objects. MaSON is designed to maximize human readability and LLM token efficiency by eliminating bracket-based nesting and strict indentation rules. This updated specification introduces "Compact Mode" optimized for extreme token density, support for multi-line string encapsulation, and mixed-type array isolation via forced brackets. |
| | AGTP-Commerce: Open Commerce Specification for Agent-to-Agent Transactions |
| |
|
This document specifies AGTP-Commerce, an open commerce specification for agent-to-agent transactions. The specification defines the structural transaction information that the Agent Transfer Protocol carries between agents, allowing payment providers and commerce applications to compose at the application layer to perform the actual financial execution. AGTP-Commerce is to agent commerce what ISO 20022 is to inter-bank payment messaging: a standardized message format that allows heterogeneous payment infrastructure to interoperate. AGTP-Commerce does not move money, hold funds, or operate as a payment processor. The protocol carries pricing manifests, budget signaling, transaction commitments, and audit trail records that payment providers consume to execute settlement through existing financial infrastructure. This document specifies the pricing manifest format, extended Budget- Limit header semantics, the TRANSACT method for transaction commitment, audit-trail-based receipt records, dispute composition surfaces, and the integration patterns that allow payment providers (traditional processors, banks, cryptocurrency rails, and specialized agent-economy services) to compose with AGTP-Commerce as application- layer infrastructure. |
| | AGTP Presence: Ambient Discovery and Visibility for Agent Substrates |
| |
|
This document specifies AGTP Presence, an ambient discovery and visibility layer for the Agent Transfer Protocol (AGTP). Existing agent discovery proposals are pull-based: an agent must know where to look (a catalog URL, a registry endpoint, a DNS name) before discovery can begin. AGTP Presence inverts this model. When an agent joins the AGTP substrate, it becomes structurally addressable and visible to the relevant scope of other agents immediately, without requiring registration with a central directory. The architecture combines three proven patterns: a Distributed Hash Table (DHT) keyed by Canonical Agent-ID for content-addressable routing, a gossip-based protocol for presence announcement and convergence, and trust-tier-scoped overlay partitioning for visibility control. Per-agent visibility is cryptographically declared in AGTP-CERT certificate extensions and enforced structurally, with three orthogonal axes of control: presence visibility, disclosure visibility, and audience scoping. This document defines three new lifecycle methods (ANNOUNCE, WITHDRAW, PROBE), specifies the DHT and gossip protocols, defines the visibility model and its certificate extensions, addresses scaling through hybrid participation modes and federation-of-scoped-overlays, and provides a threat model with concrete mitigations. |
| | AGTP-LEI: Binding the Agent Transfer Protocol to the Verifiable Legal Entity Identifier |
| |
|
The Legal Entity Identifier (LEI), defined by ISO 17442 and operated under the global governance of the Global Legal Entity Identifier Foundation (GLEIF), is the internationally recognized identifier for legal entities in financial transactions and regulatory reporting. The verifiable LEI (vLEI), built on Key Event Receipt Infrastructure (KERI) and Authentic Chained Data Containers (ACDC), extends the LEI into the digital trust ecosystem with cryptographically verifiable credentials issued through Qualified vLEI Issuers (QVIs). This document specifies how the Agent Transfer Protocol (AGTP) binds to the LEI and vLEI infrastructure. It defines how an LEI is carried in an AGTP Owner-ID, how a vLEI Legal Entity credential composes with AGTP-CERT to establish institutional identity at the wire, how a new verification path (vlei-anchored) is added to AGTP-TRUST for KERI- based verification, and how vLEI Role Credentials (OOR, ECR, AUTH) express the human authorization chain that produced an agent. The result is a clean composition: AGTP provides the agent identity substrate, the LEI provides the institutional identity, the vLEI provides cryptographic verification of that institutional identity, and the vLEI Role Credentials provide the authorization chain from the legal entity through human officers to the agent. This document positions financial institutions, regulated entities, and other LEI holders to deploy agents with structurally verifiable institutional identity from day one. |
| | AGTP Transport Bindings: TCP/TLS and QUIC |
| |
|
The Agent Transfer Protocol (AGTP) base specification defines AGTP semantics independently of any specific transport. This document specifies the AGTP transport bindings for TCP with TLS 1.3 and for QUIC, defining how AGTP requests and responses are carried over each transport, how TLS mutual authentication composes with AGTP identity, and how connection lifecycle events map to AGTP session semantics. A central concern for the QUIC binding is replay safety. QUIC supports 0-RTT early data, which is replayable by design. AGTP requests carry authority-scoped actions; a replayed action method could re-trigger authorized work without the requesting agent's intent. This document defines an AGTP-specific replay-safety profile: early data is permitted only for safe idempotent methods (QUERY, DISCOVER) and *MUST NOT* be used for action methods (EXECUTE, DELEGATE, PURCHASE, TRANSACT, and the lifecycle methods). This document follows the pattern established by HTTP: protocol semantics defined independently of transport ([RFC9110] for HTTP), with transport-specific bindings in separate documents. AGTP semantics are defined in [AGTP]; this document defines the transport mechanics. |
| | Network Trust Framework for AI Agents |
| |
|
AI agents are expected to communicate across platforms, organizations, clouds, edge environments, and administrative domains. Existing agent mechanisms mainly focus on application-layer discovery, capability description, identity, authorization, tool invocation, and agent-to-agent collaboration. These mechanisms are important, but they often treat the IP network as a transparent connectivity substrate. This document describes a framework for using network-layer and network-control capabilities to enhance trust for AI agent communication after agent discovery. The framework introduces an Agent Interconnection Hub, trusted transport tags, policy-driven path selection, and audit indexing as building blocks for recognizable identity, accountable paths, enforceable policy, and traceable invocation records. This document does not define a new agent discovery protocol, a new application-layer agent collaboration protocol, a new authentication or authorization mechanism, a new IPv6 extension header, or a new SRv6 behavior. It provides architectural considerations and requirements for future work. |
| | The did:web Identity Method for the Agent Enrollment Protocol |
| |
|
This document defines the did:web identity method for the Agent Enrollment Protocol (AEP). The method lets an AEP Service verify Agent client assertion JWTs by resolving an Agent did:web identifier to a DID document published over HTTPS. |
| | Ciphertext-Based AI Inference Tool Design for the Model Context Protocol (MCP) |
| |
|
The Model Context Protocol (MCP) enables AI-powered tools to interact with autonomous agents and Large Language Models (LLMs), but currently processes user inputs and inference results in plaintext. This could introduce some privacy risks and violates the principle of least privilege when processing user data. This contribution specifies a ciphertext-based AI inference extension for MCP. The design leverages Homomorphic Encryption (HE) to allow an MCP server or remote tool to perform inference directly on encrypted data without accessing the plaintext. The server receives encrypted payloads, computes over ciphertexts using an evaluation key, and returns an encrypted result that only the MCP client can decrypt. To ensure interoperability across various network environments, this document defines a JSON-RPC message format independent of the underlying transport layer (supporting both local stdio and remote Server-Sent Events). The format extends the existing MCP 'tools/ call' method with fields for encrypted payloads, algorithm identifiers, and key references. Additionally, this document discusses security considerations, key management, and implementation trade-offs. |
| | Guidance on RESTful Design for Internet of Things Systems |
| |
|
This document gives guidance for designing Internet of Things (IoT) systems that follow the principles of the Representational State Transfer (REST) architectural style. This document is a product of the IRTF Thing-to-Thing Research Group (T2TRG). |
| |
|
| |
| | Timeslot Queueing and Forwarding Mechanism |
| |
|
IP/MPLS networks use packet switching (with the feature store-and- forward) and are based on statistical multiplexing. Statistical multiplexing is essentially a variant of time division multiplexing, which refers to the asynchronous and dynamic allocation of link timeslot resources. Statistical multiplexing has certain challenges and complexity in meeting deterministic QoS. This document describes a generic time division multiplexing scheme for layer-3 in an IP/MPLS networks, called timeslot queueing and forwarding (TQF) mechanism. TQF is an enhancement based on TSN TAS and allows the data plane to create a flexible timeslot mapping based on available timeslot resources. It defines a cyclic period consisting of multiple timeslots where a flow is assigned to be transmitted within one or more dedicated timeslots. The objective of TQF is to better handle large scaling requirements. |
| | Mail Autoconfig |
| |
|
A protocol that allows email applications to set up mail accounts and related accounts with only the email address and password. It defines how service providers can publish the account configuration, so that email applications can automatically find a working configuration. It reduces setup friction for their users, and calls to the support for the service provider. Although the discovery process starts with an email address, the protocol is not limited setting up email accounts, but can also set up calendar, contact and file sync, video conference accounts and other accounts that are connected to the same user account. This protocol uses a well-known address and DNS lookups, based on the email address domain, to find the XML configuration file for the service provider. |
| | YANG Groupings for QUIC clients and QUIC servers |
| |
|
This document defines five YANG 1.1 modules to support the configuration of QUIC clients and QUIC servers. The modules include basic parameters for configuring QUIC based clients and servers as well as initial modules for the IANA registries "QUIC Versions" and "QUIC Transport Parameters". |
| | Managing CBOR codepoints in Internet-Drafts |
| |
|
CBOR-based protocols often make use of numbers allocated in a registry. During development of the protocols, those numbers may not yet be available. This impedes the generation of data models and examples that actually can be used by tools. This short draft proposes a common way to handle these situations, without any changes to existing tools. Also, in conjunction with the CDN prefix e (draft-ietf-cbor-edn-e-ref), a further reduction in editorial processing of CBOR examples around the time of approval can be achieved. |
| | Enhancements to the YANG Language for Capturing Subtree Replacements |
| |
|
As YANG data models evolve over time, model nodes are often deprecated or made obsolete. Current practices for documenting replacement paths for these nodes rely on unstructured external documents, making it difficult to programmatically identify and migrate to replacement nodes. This document proposes a YANG extension mechanism that embeds replacement path information directly within YANG models, enabling automation tools to identify replacement nodes and assist users in migrating from deprecated elements to their replacements. |
| | Fast Notification for tunnel-based lossless RDMA transmission in WAN |
| |
|
With the rapid development of Large Language Models (LLMs), many emerging AI services require lossless transmission of RDMA traffic over tunnels in Wide Area Network(WAN). Existing network mechanisms were not designed for the responsiveness and scale required by these dynamic services. WAN should support the real-time, lightweight network notification to enhance the responsiveness for traffic engineering, congestion mitigation, and failure protection. This document analyzes typical scenarios where RDMA traffic need to be tunneled across WAN, and proposes fast network notification solutions based on ICMPv6 or UDP. |
| | 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. This document supersedes the earlier work published as draft-openhttpa-protocol-00. |
| | Geographic Based Dynamic Routing in LEO Satellite Networks |
| |
|
This document proposes a dynamic routing mechanism for Low Earth Orbit(LEO) satellite networks based on geographic region coding. By decoupling IP addressing from physical location, the mechanism uses hierarchical geographic grid codes (inspired by Uber's H3 spatial index) as temporary IP addresses for satellites. Routing decisions are made based on the relative geographic position encoded in the destination address, rather than traditional prefix-based IP routing. Satellite ephemeris data is leveraged to pre-compute routing tables for discrete time slices, eliminating the need for real-time link- state flooding and enabling stable, predictable routing in highly dynamic satellite topologies. |
| |
|
| |
| | Blind BBS Signatures |
| |
|
This document defines an extension to the BBS Signature scheme that supports blind digital signatures, i.e., signatures over messages not known to the Signer. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Crypto Forum Research Group mailing list ([email protected]), which is archived at https://mailarchive.ietf.org/arch/browse/cfrg. Source for this draft and an issue tracker can be found at https://github.com/cfrg/draft-irtf-cfrg-bbs-blind-signatures. |
| | Deadline Based Deterministic Forwarding |
| |
|
This document describes a deadline based deterministic forwarding mechanism for IP/MPLS network with the corresponding resource reservation, admission control, scheduling and policing processes to provide guaranteed latency bound. It employs a latency compensation technique with a stateless core, to replace reshaping, making it suitable for the Differentiated Services (Diffserv) architecture [RFC2475]. |
| | IANA Registrations for the BGP Finite State Machine (FSM) |
| |
|
The Border Gateway Protocol, version 4 (BGP-4) finite state machine (FSM) is defined in RFC 4271. Over the years, various extensions to BGP have been authored that update the protocol's FSM. Some elements of the FSM are enumerated. Those elements are referred to across BGP extensions in their respective state machine changes, and may also be used for management purposes in things such as YANG (RFC 7950). To provide consistent naming and enumeration of these FSM elements, this document requests IANA to create and maintain registries for elements in the BGP FSM. |
| | Extensions to Salted Challenge Response (SCRAM) for 2 factor authentication |
| |
|
This specification describes an extension to family of Simple Authentication and Security Layer (SASL; RFC 4422) authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which provides support for 2 factor authentication. It also includes a separate extension for quick reauthentication. This specification also gives 2 examples of second factors: TOTP (RFC 6238) and FIDO CTAP1/U2F (Passkey). |
| | 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, without the need for per-flow state in the network. As a result, the protocols that would be otherwise needed to signal the per-flow unicast state are not needed either. In the case of multicast, traffic can be either source-routed or non-source-routed, and this document summarizes options for non-source-routed multicast in an SR network, including pre-SR tree-based multicast technologies, BIER, and various SR specific solutions. The pros and cons of each solution are listed for considerations by operators and vendors, with regard to the principle and characteristic of SR as mentioned above. |
| | YANG Datastore Telemetry (YANG Push version 2) |
| |
| | draft-ietf-netconf-yang-push-2-00.txt |
| | Date: |
26/06/2026 |
| | Authors: |
Robert Wilton, Holger Keller, Benoit Claise, Ebben Aries, James Cumming, Thomas Graf |
| | Working Group: |
Network Configuration (netconf) |
|
YANG Push version 2 is a YANG datastore telemetry solution, as an alternative lightweight specification to the Subscribed Notifications and YANG Push solution, specifically optimized for the efficient observability of operational data. |
| | Stateless OpenPGP Command Line Interface |
| |
|
This document defines a generic stateless command-line interface for dealing with OpenPGP messages, certificates, and secret key material, known as sop. It aims for a minimal, well-structured API covering OpenPGP object security and maintenance of credentials and secrets. |
| | A CoRIM Profile for Arm's Confidential Computing Architecture (CCA) Endorsements |
| |
|
Arm Confidential Computing Architecture (CCA) Endorsements comprise reference values and cryptographic key material that a Verifier needs to appraise Attestation Evidence produced by an Arm CCA system. This memo defines CCA Endorsements as a profile of the CoRIM data model. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/yogeshbdeshpande/draft-cca-rats-endorsements. |
| | Post-Quantum Traditional (PQ/T) Hybrid PKI Authentication in the Internet Key Exchange Version 2 (IKEv2) |
| |
|
One IPsec area that would be impacted by Cryptographically Relevant Quantum Computer (CRQC) is IKEv2 authentication based on traditional asymmetric cryptographic algorithms: e.g RSA, ECDSA, which are widely deployed authentication options of IKEv2. There are new Post-Quantum Cryptographic (PQC) algorithms for digital signature like NIST [ML-DSA], However, it takes time for new cryptographic algorithms to mature, There is security risk to use only the new algorithm before it is field proven. This document describes a hybrid PKI authentication scheme for IKEv2 that incorporates both traditional and PQC digital signature algorithms, so that authentication is secure as long as one algorithm in the hybrid scheme is secure. |
| | Registry and Signature Agent card for Web bot auth |
| |
|
This document defines the "Signature Agent Card", a JSON metadata document that a signature agent using [DIRECTORY] publishes to describe itself: its identity, purpose, rate expectations, and cryptographic keys. Its parameters are drawn from the OAuth Dynamic Client Registration Metadata registry [DCR], the same namespace used by [CIMD], extended with a single web_bot_auth object. This document registers that object with IANA and establishes a registry for its members. |
| | Measurement and Analysis of IPv6 Interface Identifier Patterns in the Real World |
| |
|
Interface Identifiers (IIDs) are critical components of IPv6 addresses, significantly impacting user privacy and the feasibility of network reconnaissance. RFC 7707 previously provided a comprehensive analysis of IID patterns based on data from the early stages of IPv6 deployment. However, with the widespread adoption of privacy-enhancing standards such as RFC 7217, historical data no longer accurately reflects the current IPv6 ecosystem. This document provides updated measurements of IID patterns by utilizing an improved pattern recognition method and incorporating novel data sources, such as public mailing lists. The measurement data reveals that while "Low-byte" patterns have decreased significantly in server addresses, a substantial number of seemingly random addresses actually belong to non-random, specific patterns, implying that heuristic scanning remains a viable vector. Meanwhile, client devices have widely adopted randomized addresses, effectively enhancing privacy. This document aims to update the statistics and analysis regarding IID pattern distribution found in RFC 7707, providing essential insights for modern network defense strategies and standard compliance. |
| | 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), and downgrade-prevention rules. The KEM path framework supports multiple KEM algorithms including ML-KEM, composite ML-KEM algorithms, and future KEM standards. |
| | 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. |
| | AI enablement interface for multimedia services platforms |
| |
|
This document specifies a generic interface enabling the integration between a Multimedia Communication Framework such as a 3GPP IP Multimedia Subsystem and Large Language Models (LLMs) or other AI- based services that perform text, audio, video, image and service processing. A Multimedia Communication framework is a network supporting voice, video and message services as a SIP network or the IMS (IP Multimedia System) defined by 3GPP. The interface is designed to be platform-agnostic and flexible, allowing a connection to different AI platforms e.g. LLMs independent of their underlying technology or deployment environment. This document is inspired by the IMS environment providing data channel capabilities offering a variety of services within the framework. Such an interface allows advanced AI functions such as natural language understanding, semantic analysis, and contextual processing through a standardized, extensible and interoperable interface. This enables the IMS ecosystem to seamlessly adopt and integrate emerging AI technologies to enrich communication services. |
| | Agent Gateway Scenario Analysis and Functional Requirements for Cross-Domain Multi-Agent Communication |
| |
|
This document analyzes the communication gaps in three representative multi-agent scenarios: single-domain single-agent, single-domain multi-agent, and cross-domain multi-agent. For each scenario, it examines whether an Agent Gateway is needed, what capabilities it should provide, and where it should be deployed. Based on the consolidated gap analysis, this document derives a set of universal functional requirements for the Agent Gateway as a standardized cross-domain trust boundary and protocol termination layer. The findings aim to guide the design of interoperable agent communication infrastructure. |
| | Self-Certifying Identity and Capability-Based Delegation for Autonomous AI Agents |
| |
| | draft-duda-agent-id-framework-00.txt |
| | Date: |
26/06/2026 |
| | Authors: |
Andrzej Duda, Maciej Korczynski, Hureau Olivier, Simon Fernandez, zhang jun, Houda Labiod |
| | Working Group: |
Individual Submissions (none) |
|
We present an identity and delegation framework for secure AI agent communications. The framework introduces a set of entities including Client AI Agents, Service AI Agents, Agent Providers, and Agent Brokers, together with a Trustful Mutable Store responsible for maintaining cryptographically verifiable identity bindings. We propose self-certifying identifiers derived from public keys, realized as DNS-based Self-certifying Identifiers (SIDs) and IPFS- based Identifiers (IIDs), which provide lightweight decentralized identities for agents. To support trust establishment, we distinguish identity from trust and introduce a model that combines globally meaningful names, cryptographic identities, and trusted intermediaries such as Agent Providers and Agent Brokers. We show how DNS/DNSSEC and IPFS/IPNS can be used as distributed, highly available, integrity-protected, and mutable infrastructures for managing AI agent identities and trust metadata. |
| | A Deprecation Manifest for Field-Level Lifecycle Signalling in HTTP APIs |
| |
|
The Deprecation and Sunset HTTP response header fields, defined in RFC 9745 and RFC 8594 respectively, let a server signal that a resource, identified by its URI, has been or will be deprecated and when it will be removed. They operate at the granularity of a resource and cannot describe the lifecycle of an individual member within a request or response representation. This document defines the "application/deprecations+json" media type, a machine-readable Deprecation Manifest in which an API operator declares dated deprecation and sunset timelines for specific members of request and response representations. The manifest is discovered through the existing "deprecation" link relation type and is decoupled from any API description or schema, allowing each deployment to publish its own timeline without changing the wire behaviour of the API. |
| | Verifiable,Scope-Bound Advisories for Authorization Posture (EMILIA Eye) |
| |
|
This document defines the EMILIA Eye advisory: a scope-bound statement that an authorization posture for a named scope has changed (designed to be signed and offline-verifiable; the signing layer is specified here but is not yet present in the reference implementation, see Section 13.6), carrying a scope-binding hash that prevents the advisory from being replayed or re-targeted to a different scope. An Eye advisory expresses an observation-derived posture (clear, caution, elevated, or review_required) and a recommended action (none, log, step_up_auth, require_signoff, or escalate). The central safety invariant of this document is normative: an advisory MUST NEVER be the sole gate on an action. A signal may only TIGHTEN posture - it may cause an enforcement point to demand stronger authentication, human signoff, or escalation - but it can never itself constitute the authorization. Eye warns; an enforcement point verifies; an accountable human owns the decision. This work specifies the verifiability, scope-binding, and fail-safe advisory semantics that signal-transport frameworks leave undefined. It is a COMPOSABLE PROFILE: Eye advisories are carried as Security Event Token [RFC8417] payloads and MAY be transported over the OpenID Shared Signals Framework with Continuous Access Evaluation Profile (CAEP) events. It is complementary to, not a replacement for, SSF/ CAEP (which define signal shape and transport, not verifiable bound fail-safe advisory semantics), and it composes with the EP authorization receipt ([I-D.schrock-ep-authorization-receipts]), which remains the artifact that actually authorizes an action. This document is experimental. |
| | Supply Chain Integrity,Transparency,and Trust (SCITT) Reference APIs |
| |
| | draft-ietf-scitt-scrapi-11.txt |
| | Date: |
26/06/2026 |
| | Authors: |
Henk Birkholz, Jon Geater, Antoine Delignat-Lavaud |
| | Working Group: |
Supply Chain Integrity, Transparency, and Trust (scitt) |
|
This document specifies a REST API with the HTTP resources, request and response messages, and error handling needed for an interoperable implementation of a SCITT Transparency Service, as defined by the Supply Chain Integrity, Transparency, and Trust (SCITT) Architecture. |
| |
|
| |
| | A YANG Module for Entitlement Inventory |
| |
|
This document defines a YANG data model for managing software-based entitlements (licenses, authorization tokens, pay-as-you-go service credentials…) within a network inventory. The model represents the relationship between organizational entitlements, network element capabilities, and the constraints that entitlements impose on capability usage. This data model enables operators to determine what capabilities their network elements possess, which capabilities are currently entitled for use, and what restrictions apply. The model supports both centralized entitlement management and device-local entitlement tracking for physical and virtual network elements. |
| | BGP Flowspec Redirects to SR Policy |
| |
|
Extensions to BGP Flowspec Version 1 (FSv1) support steering traffic into a Segment Routing (SR) Policy. This document extends BGP Flowspec Version 2 (FSv2) to provide the same capability of steering traffic into a SR Policy. Using the Community Container attribute, this document defines two new standard actions for FSv2: the Redirect to SR Policy Action and the SRv6 SID Action. The former instructs headend node to direct traffic to a designated SR Policy, while the latter supports simultaneously encapsulating an additional SRv6 SID as required during redirection. The Redirect to SR Policy Action may be used either independently or in conjunction with the SRv6 SID Action, depending on the specific application scenario. In addition, the SRv6 SID Action can be combined with other actions supported by FSv2, such as the Redirect to IPv6 Action. |
| | Encapsulation of OpenFlow over Delay-Tolerant Networking (DTN) Using the Bundle Protocol |
| |
|
This document specifies a method for carrying OpenFlow messages over Delay-Tolerant Networking (DTN) using the Bundle Protocol (BP). The method encapsulates OpenFlow messages as BP payloads and defines the mapping between OpenFlow messages and Bundles, the payload format, and addressing and multiplexing considerations based on DTN Endpoint Identifiers (EIDs). This document further discusses conditions that may occur on intermittently connected or high-latency links, including fragmentation, duplicate delivery, out-of-order arrival, and expiration, and defines corresponding message handling rules. These rules enable the transmission of OpenFlow messages across DTN without modifying the semantics of the OpenFlow protocol. |
| | BGP SR Policy Extensions for State Report |
| |
|
This document extends BGP SR Policy, the same protocol used to configure SR Policies, to report operational state information of SR Policies, Candidate Paths, and Segment Lists. Optional State sub-TLVs, carried within the BGP Tunnel Encapsulation attribute, are introduced in this document to report the operational states (e.g., Down, Inactive, or Invalid) along with their associated reasons of the SR Policies from network elements to controller. These extensions are restricted to operational state reporting and do not alter SR Policy computation, path selection procedures, or the operations of the base BGP protocol. |
| | BGP Extensions for Network Resource Partition |
| |
|
Existing approaches bind a Segment Routing (SR) Policy to a Network Resource Partition (NRP) on a one-to-one basis, which lacks flexibility and introduces significant operational overhead as the number of NRPs scales, especially when multiple NRPs share the same SR Policy path. This document defines BGP extensions to advertise NRP Identifier (NRP ID) information within BGP Update messages between headend and endpoint nodes. It decouples SR Policies from NRPs, allowing multiple NRPs to share a common SR Policy path and avoiding linear growth of SR Policies. The proposed design reduces operational complexity and also applies to SR Best Effort (SR BE) scenarios. |
| | Self-Verifiable Retention Chain for Payment Receipts |
| |
|
This document specifies eight cryptographic constructions for self-verifiable agentic payment records. The first, the Retention Chain Reference (retention_chain_ref), enables tamper-evident audit chains linking payment receipts without requiring external infrastructure. The second, the Payment Action Lifecycle, defines a content-addressed model for the exactly-once execution of payment actions, including an action reference primitive (action_ref) and a per-state transition hash (transition_hash) with a provable SKIP-on- retry idempotency guarantee. The third, the Settlement-Action Binding (binding_ref), binds a settled payment to the verified agent action it paid for and to the retention chain entry recording it, so that a settlement attestation proves not only that a payment occurred but which verified action it corresponds to. The fourth, the Policy Binding (policy_bound_ref), binds a content-addressed snapshot of the governing policy to an existing binding or chain reference, so that a decision is verifiable against the exact policy version that admitted it and a policy rotation is detectable by recomputation. The fifth, the Compliance Gate Binding (gate_ref), binds a categorical ALLOW/REFER/DENY compliance verdict and a no-PII payer reference to a policy or binding reference, so that a screening decision is provably tied to the policy in force when it was made and carries no personal data in the bound record. The sixth, the Pre-Payment Decision Chain (guardrail_ref), composes an agent identity reference, a spend authority reference, and the policy in force into one recomputable pre-payment ALLOW/DENY decision. The seventh, Post-Decision Execution Evidence (execution_ref), binds an executed action to the exact decision that authorized it, so the recorded execution is provably consistent with the decision and not merely correlated with an agent identity. The eighth, Cross-Party Authority Delegation (delegation_ref), binds a delegation of authority from one party to another and chains hand-offs, so a verifier can confirm that authority did not widen across an organizational boundary. All constructions use only SHA-256 and the JSON Canonicalization Scheme (JCS, RFC 8785), and are verifiable by any party holding the relevant receipts without contacting the issuer. The constructions satisfy the transaction recording and audit trail obligations of MiCA Article 80, DORA Article 14, and AMLR Article 56. |
| | Adaptive Queue Management Under Congestion |
| |
| | draft-xu-tsvwg-adaptive-queue-mgmt-00.txt |
| | Date: |
25/06/2026 |
| | Authors: |
Bohua Xu, Chang Liu, Jie Ren, Chenyang Wen, Wei Cheng, Junjie Wang, Guoying Zhang, Yongtao Yang |
| | Working Group: |
Individual Submissions (none) |
|
Active Queue Management (AQM) manages queue depth by controlling packet admission at the point of enqueue. This document specifies a complementary queue management behavior that operates on packets already admitted to a queue: when the queue depth exceeds a configurable threshold, the maximum time a packet may remain queued before being dropped is reduced. When congestion subsides, the duration reverts to its base value. This per-queue dropping behavior helps manage queue depth during congestion by releasing resources from queues where packets have been waiting longest, complementing AQM without modifying its signaling semantics. |
| | Agent Capability Advertisement Protocol (ACAP) |
| |
| | draft-zahed-acap-00.txt |
| | Date: |
25/06/2026 |
| | Authors: |
Zaheduzzaman Sarker, Tirumaleswar Reddy.K |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the Agent Capability Advertisement Protocol (ACAP), a REST-like protocol built on HTTP/3 that defines a structured registry and exchange format for Agent Capability Documents (ACDs). ACAP enables the discovery of AI agents deployed across different administrative domains on the Internet. Each agent exposes an ACAP endpoint, hosted at a well-known URI, that serves ACDs describing the capabilities, authentication requirements, and operational metadata for agents within that domain. ACAP supports three core operations: retrieval, registration, and capability-based search. In deployments where multiple agent operators share hosting infrastructure, ACDs are cryptographically signed to enable secure, decentralized agent discovery. |
| | OAuth Transaction Authorization Challenge |
| |
|
This document defines an OAuth mechanism for transaction-specific authorization challenges. A protected resource can require additional authorization for a particular operation by returning a transaction authorization challenge. This is useful when requests are mediated by agents, automated workflows, or delegated services and the protected resource requires confirmation from a human user, resource owner, or organizational authority. The client presents the challenge to an authorization server, which validates the challenge, obtains any required approval, and issues an OAuth 2.0 access token whose granted authorization details, expressed using Rich Authorization Requests, describe the approved operation. The access token is then presented to the protected resource as evidence that the challenged operation was authorized. |
| | Placeholder for typoed email alias |
| |
|
Nothing to see here |
| | Autonomous Agent Interchange Format (AAIF) |
| |
|
The Autonomous Agent Interchange Format (AAIF) is an open, vendor- neutral specification for the portable definition of artificial intelligence agents. An AAIF document encapsulates an agent's identity, goal, system instructions, large language model (LLM) provider preferences and fallback routing, multi-agent orchestration topology (sequential pipeline, parallel swarm, dynamic routing, and mid-run handoff), tool catalogue (supporting function, MCP, HTTP, and OpenAPI protocols with structured authentication), memory configuration, runtime policy, OpenTelemetry telemetry settings, LLM- as-judge evaluation criteria, and compliance controls including data residency and human-in-the-loop approval. An agent defined in AAIF can be validated offline, committed to version control, and imported into any conforming runtime regardless of the original authoring environment. This document describes the AAIF data model, field semantics, conformance levels, capability negotiation protocol, and the companion Agent State checkpoint schema that enables cross-platform live migration of running agents. |
| | Agent Capability and Profile Model (ACPM) |
| |
|
The Agent Capability and Profile Model (ACPM) is an open, vendor- neutral specification for describing what an artificial intelligence (AI) agent, the platform that runs it, a tool it calls, or the underlying large language model (LLM) actually offers, independent of how that subject is run or discovered. An ACPM document, called a capability profile, declares a subject's identity, a dot-namespaced list of supported capabilities together with a support level, an inventory of tool protocols, models, and memory backends, a trust and attestation posture, a cost structure, service-level commitments, structured delegation rules governing inbound and outbound work handoff, and a compliance posture. ACPM profiles are designed to cross-reference agent definitions and registry entries defined by other Schema Commons standards, and to be consumed by registries, marketplaces, and orchestrators that need to compare capabilities, gate on trust, and reason about cost and service levels without bespoke per-vendor parsing. This document describes the ACPM data model, field semantics, conformance levels, and the relationship of ACPM's trust and signature fields to actual verification, which ACPM deliberately does not itself perform. |
| | Remote Two-factor Protected Services |
| |
|
This document defines a generic service exchange protocol where service exchange data is protected and bound to a physical user using 1 or 2 factors (1FA and 2FA). The protocol facilitates registration and verification of either a knowledge-factor or a biometric factor in addition to a possession factor as means of achieving 2 factor protection. |
| | Handling Verification Failures of TSIG-Signed DNS Messages |
| |
|
Transation Signatures (TSIG) provide a standard mechanism to sign DNS messages, so that the authenticity of messages can be verified by the system that receives them. This document updates the required behaviour of a system that receives a signed message that fails verification. |
| | Supplemental Authentication in TLS 1.3 |
| |
|
TLS 1.3 allows endpoints to authenticate using certificates during the handshake and supports optional post-handshake client authentication. However, some deployments require presenting additional certificate-based authentication statements bound to the same TLS connection, such as separate device and user identities, attestation evidence, or multiple certificate chains during cryptographic transitions. This document defines Supplemental Authentication for TLS 1.3, a mechanism that allows endpoints to present additional certificate authentication messages after the handshake while preserving the authentication semantics of TLS 1.3. Supplemental authentication reuses the existing Certificate, CertificateVerify, and Finished message structure and allows endpoints to exchange one or more additional certificate-based authentication statements before sending application data or other post-handshake TLS messages. |
| | HTTP/3 over QMux |
| |
|
This document specifies how to use HTTP/3 over QMux. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the HTTP Working Group mailing list ([email protected]), which is archived at https://lists.w3.org/Archives/Public/ietf-http-wg/. Source for this draft and an issue tracker can be found at https://github.com/kazuho/draft-kazuho-httpbis-http3-on-streams. |
| | Agent Gateway Core functional Architecture |
| |
|
This document defines the core functional architecture of the Agent Gateway as a universal infrastructure component. The Agent Gateway is designed to address key challenges in single-domain multi-agent collaboration and cross-domain multi-agent communication, including trust boundaries, protocol termination, capability discovery, and task routing. The main framework consists of four gateway capabilities: the A2A Gateway (supporting inter-agent communication), the MCP Gateway (supporting tool invocation), the Model Routing Gateway (supporting large language model invocation), and the Network Gateway (supporting underlying network connectivity). The A2A Gateway is further decomposed into five core capabilities: protocol translation, authentication and security, asynchronous task management, peer-to-peer network management, and Agent routing capabilities (including Agent registry, capability discovery, task routing, and load balancing). This document is intended for designers and implementers seeking to build standardized, interoperable agent communication infrastructure. |
| | Applicability of TVR YANG Data Models |
| |
|
Time-Variant Routing (TVR) is a routing system that is designed to accommodate predicted topology changes caused by internal or external factors. Typical use cases include resource preservation networks, operating efficiency networks, and dynamic reachability networks. This document provides examples of how to implement the TVR scheduling capabilities for key use cases. It describes which part of the TVR data model is used and why. It also outlines operational and security considerations when deploying TVR-based technologies. |
| |
|
| |
| | Signalling a Zone Cut to Nowhere in the DNS |
| |
|
This document defines a standard mechanism to signal the existence of a DNS zone cut without specifying authoritative nameservers for the delegated child zone. This "zone cut to nowhere" is particularly useful in split-horizon environments, allowing parent zones to explicitly signal that a child zone exists but is only resolvable within a private namespace. |
| | Updates to SMTP related IANA registries |
| |
|
While EMAILCORE working group was working on update to SMTP specification, it became clear that existing entries in SMTP related registries are missing information or contain stale information and need to be updated. This document updates such entries. |
| | HTTP Problem Types for Digest Fields |
| |
|
This document specifies HTTP problem types that servers can use in responses to problems encountered while dealing with a request carrying integrity fields and integrity preference fields. Using an HTTP problem type, the server can provide machine-readable error details to aid debugging or error reporting. |
| | A YANG Data Model for Multicast Services |
| |
|
This document provides a generic multicast YANG data model that shows the relevant technologies or protocols used by multicast flows. It provides a management view for network administrators to obtain information about multicast services. |
| | Multiple Ethernet - IPv6 address mapping encapsulation - fixed prefix |
| |
|
This document specifies Multiple Ethernet - IPv6 address mapping encapsulation - fixed prefix (ME6E-FP) base specification. ME6E-FP makes expantion ethernet network over IPv6 backbone network with encapsuation technoogy. And also, E6ME-FP can stack multiple Ethernet networks. ME6E-FP work on own routing domain. |
| | Multiple Ethernet - IPv6 address mapping encapsulation - prefix resolution |
| |
|
This document specifies Multiple Ethernet - IPv6 address mapping encapsulation - Prefix Resolution (ME6E-PR) specification. ME6E-PR makes expantion ethernet network over IPv6 backbone network with encapsuation technoogy. And also, E6ME-PR can stack multiple Ethernet networks. ME6E-PR work on non own routing domain. |
| | Multiple IPv4 - IPv6 mapped IPv6 address (M46A) |
| |
|
This document specifies Multiple IPv4 - IPv6 mapped IPv6 address(M46A) spefification. M46A is an IPv4-mapped IPv6 address with a plane ID. Unique allocation of plane id value enables IPv4 private address unique in IPv6 address space. This address may use IPv4 over IPv6 encapsulation and IPv4 - IPv6 translation. |
| | Multiple IPv4 - IPv6 address mapping encapsulation - fixed prefix (M46E-FP) |
| |
|
This document specifies Multiple IPv4 - IPv6 address mapping encapsulation - fixed prefix (M46E-FP) specification. M46E-FP makes backbone network to IPv6 only. And also, M46E-FP can stack many IPv4 networks, i.e. the networks using same IPv4 (private) addresses, without interdependence. |
| | Multiple IPv4 - IPv6 address mapping encapsulation - prefix resolution (M46E-PR) |
| |
|
This document specifies M46E Prefix Resolution (M46E-PR) specification. M46E-PR connect IPv4 stub networks between IPv6 backbone network. And also, M46E-PR can stack many IPv4 networks, i.e. the nwtworks using same IPv4 private addresses without interdependence. |
| | Multiple IPv4 - IPv6 address mapping encapsulation - prefix translator (M46E-PT) |
| |
|
This document specifies Multiple IPv4 - IPv6 mapping encapsulation - Prefix Translator (M46E-PT) specification. M46E-PT expand IPv4 network plane by connecting M46E-FP domain and M46E-PR domain. M46E- PT translate prefix part of M46E-FP address and M46E-PR address both are IPv6 address. M46E-PT does not translate IPv4 packet which is encapsulated, so transparency of IPv4 packet is not broken. |
| | Multiple IPv4 - IPv6 address mapping translator (M46T) |
| |
|
This document specifies Multiple IPv4 - IPv6 address mapping Translator (M46T) specification. M46T enable access to IPv4 only host from IPv6 host. IPv4 host is identified as M46 address in IPv6 address space. The address assigned to IPv4 host may be global IPv4 address or private IPv4 address. M46T does not support access to IPv6 host from IPv4 only host. |
| | Multi-Stage Transparent Server Load Balancing |
| |
|
This document specifies Multi-Stage Transparent Server Load Balancing (MSLB) specification. MSLB makes server load balancing over Layer3 network without packet header change at client and server. MSLB makes server load balancing with any protocol and protocol with encryption such as IPsec ESP, SSL/TLS. |
| | Multiple Ethernet - IPv6 mapped IPv6 address (ME6A) |
| |
|
This document specifies Multiple Ethernet - IPv6 mapped IPv6 address(ME6A) spefification. ME6A is an Ethernet-mapped IPv6 address with a plane ID. Unique allocation of plane id value enables duplicated MAC address unique in IPv6 address space. This address may use Ethernet over IPv6 encapsulation. |
| | BGP over QUIC |
| |
| | draft-retana-idr-bgp-quic-09.txt |
| | Date: |
24/06/2026 |
| | Authors: |
Alvaro Retana, Yingzhen Qu, Jeffrey Haas, Shuanglong Chen, Jeff Tantsura |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the procedures for BGP to use QUIC as a transport protocol with a mechanism to carry Network Layer protocols (AFI/SAFI) over multiple QUIC streams to achieve high resiliency. |
| | JMAP extension for S/MIME signing and encryption |
| |
|
This document specifies an extension to JMAP for sending S/MIME signed and/or S/MIME encrypted messages, as well as automatic decryption of received S/MIME messages. [[This version presents an alternative syntax to revision 04 of https://datatracker.ietf.org/doc/draft-ietf-jmap-smime-sender- extensions/]] |
| | SCION Data Plane |
| |
|
This document describes the Data Plane of SCION (Scalability, Control, and Isolation On Next-generation networks), a path-aware, inter-domain network architecture. Unlike IP-based forwarding, SCION embeds inter-domain forwarding directives in the packet header, enabling endpoints to construct and select end-to-end paths from segments discovered by the Control Plane. The role of the Data Plane is to combine such segments into end-to-end paths, and to forward data according to the specified path. This document describes the SCION packet format, header structure, and extension headers. It also describes the cryptographic mechanisms used for path authorization, processing at routers including a life of a packet example. This document contains new approaches to secure path aware networking. It is not an Internet Standard, has not received any formal review of the IETF, nor was the work developed through the rough consensus process. The approaches offered in this work are offered to the community for its consideration in the further evolution of the Internet. |
| | IKEv2 support for specifying a Delete notify reason |
| |
|
This document defines the DELETE_REASON Notify Message Status Type Payload for the Internet Key Exchange Protocol Version 2 (IKEv2) to support adding a reason for the deletion of the IKE or Child SA(s). |
| | Chempat: Generic Instantiated PQ/T Hybrid Key Encapsulation Mechanisms |
| |
|
This document specify Chempat as a generic family of instantiated Post-Quantum/Traditional (PQ/T) Hybrid Key Exchange Methods (KEMs). The goal is to provide a generic combiner construct that can be analysed separately for security assurance, and to offer concrete instantiated algorithms for integration into protocol and implementations. Identified instances are provided based on some combinations of traditional Diffie-Hellman key agreement using curves P-256, P-384, X25519, X448, brainpoolP256, brainpoolP384 and brainpoolP512 combined with post quantum methods ML-KEM-768, ML-KEM- 1024, Streamlined NTRU Prime sntrup761, Classic McEliece and FrodoKEM. |
| | Outer Header Translator - multihoming |
| |
|
This document describes how to achieve multihoming using OHT. This document describes both the use of provider addresses and provider independent addresses. |
| | Detecting Unwanted Location Trackers |
| |
|
This document lists a set of best practices and protocols for accessory manufacturers whose products have built-in location- tracking capabilities. By following these requirements and recommendations, a location-tracking accessory will be compatible with unwanted tracking detection and alerts on mobile platforms. This is an important capability for improving the privacy and safety of individuals in the circumstance that those accessories are used to track their location without their knowledge or consent. |
| | Mothma: Generic Instantiated PQ/T Hybrid Signatures |
| |
|
This document specify Mothma as a generic family of instantiated Post-Quantum/Traditional (PQ/T) Hybrid Digital Signatures. The goal is to provide a generic hybrid signature pattern that can be analysed separately for security assurance, and to offer concrete instantiated algorithms for integration into protocol and implementations. Identified instances are provided based on combinations of the traditional EdDSA, ECDSA and RSA methods with the post-quantum methods of ML-DSA, SLH-DSA, XMSS and LMS. |
| | ICMP Error Handling for VPNs in SRv6 Networks |
| |
|
This document specifies ICMP error handling in SRv6-based Virtual Private Networks, that support direct localization of failures. It provides a solution for connectivity check and fault localization without adding complexity to P nodes and keeps P nodes service agnostic. ICMP processing is changed only on ingress PE nodes and gains from adding VPN-specific information to the SRv6 encapsulated packet. Egress PE nodes are not involved in the forwarding of the ICMP error messages therefore, the solution provides visibility upto the failure even if ingress PE to egress PE connectivity is broken within the SR domain. |
| | UTXO Domain Name System (UTXO6-DNS): Base Protocol and PRN Regulatory Extensions |
| |
| | draft-guorong-utxo-dns-01.txt |
| | Date: |
24/06/2026 |
| | Authors: |
GuorongTian, ZhibinLei, FanYinYang, YidanZhu, Xinfeng. Huang |
| | Working Group: |
Individual Submissions (none) |
|
All domain names used in examples throughout this document use ".test" in accordance with RFC 2606. In actual deployments, ".utxo" is used. This document specifies the UTXO Domain Name System (UTXO6-DNS), a decentralized naming protocol that maps .utxo domain names to blockchain UTXO (Unspent Transaction Output) endpoints and generates verifiable IPv6 Interface Identifiers (IIDs) using Verifiable Random Functions (VRFs). The base protocol defines a new DNS RR type (UTXO, code 260), an EDNS0 option for capability discovery, and fallback mechanisms to coexist with legacy DNS, updating RFC 1034, RFC 1035, and RFC 7217. Additionally, this document defines an optional compliance overlay --- the Penetrating Regulation Node (PRN) extensions --- that can be deployed by regulated financial institutions to meet AML/CFT requirements, provide audit trails, and verify legal entity identities using GLEIF vLEI credentials. The PRN extensions include optional regulatory attributes in UTXO RRs, a new PRNAUDIT RR type for daily audit summaries, a RESTful API (PRN-API) for regulatory dashboards, a 2-of-3 MPC threshold signature framework for audit integrity, and native vLEI integration. This document also describes a transaction lifecycle compliance enforcement model (AnteHandler) and an application-layer policy format (AgentPolicyEnvelope) for declarative authorization. The PRN extensions are privacy-preserving (only Merkle roots and aggregated statistics are shared), decentralized (no central authority), and verifiable (audit summaries are jointly signed by independent auditing firms). *This document is published as an Experimental specification.* It is not an IETF standard and does not represent IETF consensus. It is intended for informational purposes, to facilitate implementation experience, and to support early discussion within the DNSOP working group. See Section 1 for details. *Note:* The AgentPolicyEnvelope JSON Schema (Appendix I) and the AnteHandler compliance enforcement model (Section 4) are application- layer constructs provided as informative examples. They are not on the IETF standards track and are not subject to IETF consensus. Their inclusion in this document is intended to facilitate interoperability of experimental deployments. |
| | OAuth 2.0 Client Instance Assertion |
| |
|
This specification defines the Client Instance Assertion: a signed JWT identifying a concrete runtime instance of an OAuth 2.0 client. It registers the client_instance_assertion request parameter for carrying the assertion at the OAuth 2.0 token endpoint on the authorization_code, client_credentials, refresh_token, and JWT bearer (RFC 7523) grants; on the token-exchange grant (RFC 8693), the same assertion is presented as actor_token with actor_token_type set to urn:ietf:params:oauth:token-type:client-instance-jwt, also registered by this specification. This specification does not introduce a new client_instance identifier in protocol messages. Instead, it defines client metadata parameters (applicable to clients identified by a Client ID Metadata Document (CIMD) or registered via OAuth Dynamic Client Registration (RFC 7591)) that let a client_id identify a logical client whose concrete runtime instances are authenticated by one or more trusted instance issuers (for example, workload identity systems). The Authorization Server validates the instance assertion and represents the instance either as an act claim, when another principal is present (e.g., a user delegating to the instance), or as the access token's sub, when the instance itself is the principal (e.g., a client credentials grant). The issued access token is sender-constrained to a key the instance possesses. |
| | 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. |
| | The clawmarc Catalog Card Format |
| |
|
This document specifies clawmarc, a fixed-size, 4096-byte catalog card for describing digital artefacts in content-addressed and replicated catalogs. A clawmarc card binds to the bytes of an artefact, carries compact human-readable descriptive text and an optional machine-readable search payload, records retrieval hints, and is signed by its issuer. The format is intended to improve interoperability among independent catalog producers and consumers without requiring any particular storage backend, catalog governance model, or search engine. This document is an Independent Stream Informational specification; it does not represent IETF consensus and does not define an Internet standard. |
| | GSE architecture for AIDC |
| |
|
This document introduces a Global Scheduling Ethernet (GSE) architecture for data centers used for AI computing. This architecture can minimize the probability of packet forwarding congestion in the network and improve the efficiency of packet interaction. |
| | Long-Term Validation for JSON Web Signature (LTV-JWS) |
| |
|
This specification extends JSON Web Signature (JWS, [RFC7515]) and defines LTV-JWS, a lightweight long-term signature format for Long- Term Validation (LTV). LTV-JWS adds signature extension elements, timestamps [RFC3161], validation information (certificates [RFC5280], CRLs [RFC5280], and OCSP responses [RFC6960]), and archive structures as minimal extensions, thereby enabling the validity of signatures to be verified over extended periods of time. In addition, archive timestamps enable continued validation even after the obsolescence or compromise of cryptographic algorithms. LTV-JWS preserves the simple structure and concept of JWS while progressively adding timestamps and validation information. It also enables more general-purpose signing use cases through indirect signatures using external references (refs). |
| | Adapting Constrained Devices for Post-Quantum Cryptography |
| |
|
This document provides guidance on integrating Post-Quantum Cryptography (PQC) into resource-constrained devices, such as IoT nodes and lightweight Hardware Security Modules (HSMs). These systems often operate with strict limitations on processing power, RAM, and flash memory, and may even be battery-powered. The document emphasizes the role of hardware security as the basis for secure operations, supporting features such as seed-based key generation to minimize persistent storage, efficient handling of ephemeral keys, and the offloading of cryptographic tasks in low-resource environments. It also explores the implications of PQC on firmware update mechanisms in such constrained systems. |
| | 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. |
| | A YANG Data Model for Resource Reservation Protocol (RSVP) |
| |
| | draft-ietf-teas-yang-rsvp-21.txt |
| | Date: |
24/06/2026 |
| | Authors: |
Vishnu Beeram, Tarek Saad, Rakesh Gandhi, Xufeng Liu, Igor Bryskin |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
This document defines a YANG data model for the configuration and management of the RSVP protocol. The YANG data model covers the building blocks that may be augmented by other RSVP extension data models such as RSVP Traffic-Engineering (RSVP-TE). It is divided into two modules that cover the basic and extended RSVP features. |
| |
|
| |
| | BRSKI discovery and variations |
| |
|
This document specifies procedures for variations of the "Bootstrapping Remote Secure Key Infrastructure" (BRSKI) series of protocols to automatically announce, discover and select responders using different discovery mechanisms such as DNS-SD, GRASP or CORE- LF. Different variations are not interoperable so initiators need to be able to find responders supporting the variation(s) they support. Procedures for BRSKI proxies are defined that allow proxying of traffic for any current and future variation. Procedures to discover BRSKI Pledges by their identifier are defined. All procedures are defined such that they rely on IANA defined tables through which not only well specified but also possible but not yet validated variations of BRSKI or additional discovery mechanisms can be supported simply by adding entries to the IANA tables. Many of the procedures and mechanisms covered by this document may equally be applied to discovery of other protocols, especially when they have non-interoperable variations. |
| | An sdfType for Links |
| |
| | draft-ietf-asdf-sdftype-link-02.txt |
| | Date: |
23/06/2026 |
| | Authors: |
Carsten Bormann, Ari Keranen |
| | Working Group: |
A Semantic Definition Format for Data and Interactions of Things (asdf) |
|
This document defines and registers an sdfType "link" for the Semantic Definition Format (SDF) for Data and Interactions of Things (draft-ietf-asdf-sdf). |
| | 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. |
| | JOSE: Deprecate 'none' and 'RSA1_5' |
| |
|
This document updates [RFC7518] to deprecate the JWS algorithm "none" and the JWE algorithm "RSA1_5". These algorithms have known security weaknesses. It also updates the Review Instructions for Designated Experts to establish baseline security requirements that future algorithm registrations are expected to meet. |
| | Test Battery for Opus ML Codec Extensions |
| |
|
This document proposes methodology and data for evaluation of machine learning (ML) codec extensions, such as the deep audio redundancy (DRED), within the Opus codec (RFC6716). |
| | YANG Next Agreement |
| |
|
The purpose of this document is to discuss and hopefully find agreement on the scope and shape of the next version of YANG. |
| | Enhanced Topology Independent Loop-free Alternate Fast Re-route |
| |
|
Topology Independent Loop-free Alternate Fast Re-route (TI-LFA) aims at providing protection of node and adjacency segments within the Segment Routing (SR) framework. A key aspect of TI-LFA is the FRR path selection approach establishing protection over the expected post-convergence paths from the point of local repair. However, the TI-LFA FRR path may skip the node even if it is specified in the SID list to be traveled. This document defines Enhanced TI-LFA(TI-LFA+) by adding a No-bypass indicator for segments to ensure that the FRR route will not bypass the specific node, such as firewall. Also, this document defines No- bypass flag and No-FRR flag in SRH to indicate not to bypass nodes and not to perform FRR on all the nodes along the SRv6 path, respectively. |
| | REST API Linked Data Keywords |
| |
|
This document defines two keywords to provide semantic information in OpenAPI Specification and JSON Schema documents, and support contract-first semantic schema design. |
| | 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. |
| | Compressed SID (CSID) for SRv6 SFC |
| |
|
In SRv6, an SRv6 SID is a 128-bit value. When too many 128-bit SRv6 SIDs are included in an SRH, the introduced overhead will affect the transmission efficiency of payload. In order to address this problem, Compressed SID(CSID) is proposed. This document defines new behaviors for service segments with REPLACE-CSID and NEXT-CSID flavors to enable compressed SRv6 service programming. |
| | Classic McEliece |
| |
|
This document specifies Classic McEliece, a Key Encapsulation Method (KEM) designed for IND-CCA2 security, even against quantum computers. This is a transcribed version of the proposed ISO Classic McEliece draft, which ISO standardized in June 2026. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-josefsson-mceliece/. Source for this draft and an issue tracker can be found at https://gitlab.com/jas/ietf-mceliece. |
| | Outer Header Translator |
| |
|
Network address translation technology has a convenient aspect, however, it has the side effect of breaking end-to-end transparency. This document proposes a technology that achieves both network address translation and end-to-end transparency. This technology may provide solutions for mobility, migration, multihoming, policy routing, etc. |
| | Provider Independent Addresses Aggregation |
| |
|
This document proposes a discussion on whether PI address aggregation. More research, reviews, and discussions will be add in the future. |
| | IPFIX Protocol over QUIC |
| |
|
The IP Flow Information Export (IPFIX) protocol provides a means for transmitting Traffic Flow information over the network. IPFIX Flow Records and Template Records can be carried over a number of transport protocols from an IPFIX Exporter to an IPFIX Collector. The supported transport protocols are SCTP, UDP and TCP. QUIC provides inherently secure, stream-multiplexed, and reliable connections for IPFIX protocol. Especially, a single QUIC connection can carry multiple independent streams, which can improve management scalability between Exporters and Collectors. This document describes how to use IPFIX protocol over the QUIC transport protocol, named IPFIXoQUIC. |
| | Source Address Validation Using Source Origin Authorizations (SOAs) |
| |
|
Given that an AS collaboration scheme for inter-domain source address validation requires an information-sharing platform, this document proposes a two-tier approach. In the first tier, Resource Public Key Infrastructure (RPKI) is used for service discovery, identity authentication, and transmission of the minimum bootstrap information needed to establish a private channel. Source Origin Authorization (SOA) is a newly defined cryptographically signed AS-level service- profile object for that purpose. Subscribers and providers each publish their own SOA profiles; a concrete service relation exists only after discovery, bilateral request validation, and provider acceptance. In the second tier, the legitimate predecessor AS information and its subsequent updates are exchanged over the authenticated private channel, by default using TLS[RFC8446] carrying CBOR[RFC8949]-encoded logical messages, enabling other ASes to collaboratively filter spoofed traffic while avoiding frequent routing-driven updates to RPKI and reducing exposure of subscriber- specific routing data. This revision also describes a logical synchronization state model, evidence-tagged authorization state, and fail-open handling for unavailable synchronized state, while leaving private-channel wire encoding to future specifications or bilateral deployment profiles. |
| | An EAT Profile for Trustworthy Device Assignment |
| |
|
In confidential computing, device assignment (DA) is the method by which a device (e.g., network adapter, GPU), whether on-chip or behind a PCIe Root Port, is assigned to a Trusted Virtual Machine (TVM). For the TVM to trust an assigned device, the device must provide the TVM with attestation Evidence confirming its identity, the state of its firmware and configuration. Since Evidence claims can be processed by 3rd party entities (e.g., Verifiers, Relying Parties) external to the TVM, there is a need to standardize the representation of DA-related information in Evidence to ensure interoperability. This document defines an attestation Evidence format for DA as an EAT (Entity Attestation Token) profile. |
| | An Intent Translation Framework for Internet of Things |
| |
|
This document describes an intent translation framework for Internet of Things (IoT) and next-generation network management environments. The framework converts user-issued natural language intents into structured policy representations that can be consumed by management and orchestration systems. The framework decomposes intent interpretation into parallel role- and-scenario classification and entity-and-slot extraction, merges the results into an intermediate representation, and generates a candidate policy document under schema-as-grammar constraints derived from the target schema. A policy validator then checks the candidate output for schema conformance, cross-slot consistency, and faithfulness to the original intent. When validation fails, a trace driven recovery agent dispatches targeted regeneration or re- extraction rather than relying on generic retry. |
| | ICMPv6 Secure Segment Treatment Notifications |
| |
|
A packet can cross an IPv6 segment whose properties - long delay, scheduled contacts, a strict size budget - defeat the feedback an endpoint normally relies on. This document defines ICMPv6-SEC (SECure Segment Treatment), an ICMPv6 message that a segment boundary sends to a packet's source when the packet is not prepared for such a segment. The message carries a COSE-signed Segment Descriptor: a compact CBOR object stating which segment is meant, how long the statement is valid, and what treatment future packets require. A receiver applies a descriptor only after verifying the signature, the validity window, and that the signer is authorized for the segment. |
| | A Profile for Source Origin Authorization (SOA) Service Profiles |
| |
|
This document defines Source Origin Authorization (SOA), a new object in the Resource Public Key Infrastructure (RPKI), for publishing an AS-level service profile used by inter-AS source address protection services. An SOA object is a digitally signed artifact that carries the publisher AS, its service role, a service descriptor, and the bootstrap information needed to authenticate a private synchronization channel, such as an endpoint address, an optional port, an optional protocol identifier, and a public key. An SOA does not itself create a subscriber-provider service relation, authorize arbitrary protected prefixes, or carry legitimate predecessor AS sets. A concrete service relation is established only after discovery, bilateral request validation, and provider acceptance. Routing-dependent data and subsequent updates are exchanged over the authenticated private channel rather than being stored in the RPKI repository. |
| | An Integrated Security Service System for 5G Networks using an I2NSF Framework |
| |
|
This document presents a mobility-aware distributed security framework for 5G edge networks using the Interface to Network Security Functions (I2NSF) architecture. The proposed system uses Intent-Based Networking (IBN) to allow users or administrators to declare high-level security intents, which are translated into network and application policies. Network-level security policies may be enforced through distributed Network Security Functions (NSFs) deployed near User Plane Functions (UPFs), while application-level policies may be enforced on User Equipment (UE) through distributed IBN Controllers. This architecture is intended to support adaptive, context-aware, and distributed policy enforcement in response to dynamic edge conditions and user mobility scenarios such as handovers. Closed-loop monitoring and analytics provide feedback for maintaining policy consistency across heterogeneous 5G environments. |
| | OAuth 2.0 Token Exchange Target Service Discovery |
| |
|
This specification defines a method for OAuth 2.0 clients to discover the set of available Token Exchange Targets (such as audiences, resources, scopes, and token types) for a given subject token when performing OAuth 2.0 Token Exchange. The discovery endpoint accepts a subject token of any type the authorization server supports, identified by a token type URI, and returns values that are valid inputs to subsequent Token Exchange requests, supporting advanced use cases such as identity chaining and cross-domain delegation. |
| | A Proposal for Long-Term Expansion of the North American Numbering Plan (NANP) to 11 Digits |
| |
|
The North American Numbering Plan (NANP) is projected to exhaust available telephone numbering resources within the coming decades under current allocation and utilization trends. Existing mitigation strategies, including area code overlays and number pooling, extend the usable life of the NANP but introduce increasing operational complexity and user confusion. This document proposes a long-term, uniform expansion of NANP telephone numbers from 10 to 11 digits through extension of the area code or Numbering Plan Area (NPA) from 3 to 4 digits. The proposal emphasizes backward compatibility, fixed-length numbering, and a multi-phase transition strategy designed to minimize disruption. This document is intended to stimulate discussion and does not represent the position of any standards body or regulatory authority. |
| | Agent Discovery Protocol (ADP) v1.1 -- Well-Known Metadata and Interaction Layer |
| |
|
This document defines the Agent Discovery Protocol (ADP) v1.1, a layered protocol for discovering, verifying, and interacting with AI Agents on the Internet. ADP delegates DNS discovery to DNS-AID (SVCB records) and defines a Well-Known JSON metadata format, an Ed25519-based identity model, and the Agent Gateway Protocol (AGP) for real-time WebSocket messaging. The protocol is designed to be decentralized, standards-based, and incremental — clients escalate from DNS to HTTP to WebSocket only as needed. |
| | Implementation Status of OAuth Identity Chaining and Transaction Tokens |
| |
|
This document reports an open-source implementation of two OAuth Working Group draft specifications: cross-domain identity chaining and transaction tokens. For each draft, this report maps every normative section to the corresponding source location in the implementation under test, summarises the test surface that exercises the section, and records one open-issue candidate per parent draft. The report is prepared in accordance with RFC 7942 and is intended for use by the editors of the two parent drafts. |
| | Source Pre-validation in RPKI-based Route Origin Validation |
| |
|
The Resource Public Key Infrastructure (RPKI) and Route Origin Validation (ROV) have significantly improved inter-domain routing security. However, thousands of RPKI-invalid routes - the vast majority caused by misconfiguration or synchronization delays - persistently appear in the global routing table. Many of these self- inflicted invalid routes originate from autonomous systems (ASes) that could have easily blocked them before advertisement. This document defines a *Best Current Practice (BCP)* for *source pre-validation*: the practice by which an originating AS checks its intended BGP announcement against its local RPKI cache *before* sending it to eBGP neighbors. Routes that would be evaluated as Invalid (or NotFound for strict mode) are blocked, logged, and *MUST be cached* for later re-evaluation, enabling automatic recovery when RPKI data changes. Routes evaluated as Valid or NotFound(for default mode) may be advertised normally. This BCP complements existing standards RFC8893 & RFC9324 by focusing on *mandatory deployment at the origin* and on *outbound caching* of suppressed routes. It provides operational guidance for deployment, cache management, and handling of RPKI data updates. Implementation of this BCP reduces self-inflicted invalid routes, improves global routing stability, and encourages wider ROV adoption. |
| | IP plus plus |
| |
|
This memo proposes an extension scheme for IPv4. It can resolve the exhaustion of IPv4 addresses at an extremely low cost and enable external access to internal networks as convenient as internal access to external networks. IPv4 adopts 32-bit fixed-length addresses, the problem of insufficient address space has long been prominent. As a temporary solution, Network Address Translation (NAT) alleviates address scarcity to a certain extent, yet it breaks the end-to-end communication principle of the Internet. It only allows intranet devices to actively access the extranet and fails to support direct access from the extranet to the intranet. Although various solutions have been proposed in the industry, they all have inherent limitations. This paper presents an innovative scheme named IP++ based on multi-level variable-length addresses, which fundamentally solves the above problems and restores the IP protocol to the basic end-to-end principle. The multi-level variable-length address structure of IP++ is highly compatible with the natural hierarchical topology of the Internet, featuring strong backward compatibility, convenient deployment and excellent usability. |
| | SCHC Header Format |
| |
|
The SCHC architecture separates a SCHC Control Header from a SCHC Data Header but leaves the format of the Control Header, the RuleID encoding, and the Discriminator deployment-specific. A node that handles a SCHC datagram without being a Compression/Decompression endpoint - a segment boundary, firewall, classifier, or capture tool - therefore cannot delineate the datagram. This document defines the SCHC Header Format: a small, named description of a SCHC datagram's framing - the RuleID encoding and the Control Header type - that can be conveyed in band (self-describing) or fixed out of band (by an RFC binding it to a demux point, by configuration, or by a signalling protocol such as ICMPv6-SEC). It defines the self-describing Shape Tag wire format and establishes the SCHC RuleID Encodings and SCHC Control-Header Types registries. |
| | Intent Admission Assertions for Agentic Systems |
| |
|
In agentic systems, an intent expressed by a user, application, or agent may be forwarded to a remote system that triggers high-impact actions. If the originator of an intent is not authenticated, is not authorized to request the targeted action, or has not obtained the required consent, the receiving system may act on a forged or unauthorized intent. This document defines the Intent Admission Assertion (IAA): a signed, verifiable artifact by which an admission point authenticates an intent originator, authorizes the request against a permission policy, gates consent-required actions on explicit consent from the user or resource owner, and conveys the result to a downstream execution endpoint that re-verifies it before acting. The IAA is a JSON Web Token whose admission decision is expressed using Rich Authorization Requests (RFC 9396). |
| | Deprecation of Outdated Cryptographic Algorithms and Parameters in Kerberos PKINIT |
| |
|
This document deprecates several outdated cryptographic algorithms and parameters from the Kerberos PKINIT specification (RFC 4556) and its extensions (RFC 5349, RFC 8636). Specifically, it deprecates the RSA key transport mechanism for reply key delivery, the Diffie- Hellman MODP group 2 (1024-bit) parameter, the SHA-1-based octetstring2key key derivation function, and the sha1WithRSAEncryption CMS signature algorithm. It also defines a new paChecksum2 field in the PKAuthenticator structure to provide checksum algorithm agility. This document updates RFC 4556, RFC 5349, and RFC 8636. |
| | Lifecycle and State Extensions for TVR Schedule YANG Model |
| |
|
The Time-Variant Routing (TVR) YANG data model [I-D.ietf-tvr-schedule-yang] defines a mechanism to describe scheduled changes in network resources (such as nodes and topology) as a function of time. However, the base model does not provide explicit lifecycle management semantics for the schedules, such as activation, suspension, or deprecation. This document defines an optional augmentation of the base YANG model to introduce lifecycle and administrative state control, enabling more flexible operational handling of schedules without modifying the base model semantics. |
| | Time-Variant Routing Scheduling for Interconnection Scenarios |
| |
|
This document specifies the applicability of Time-Variant Routing (TVR) information in interconnection scenarios. In particular, it discusses how scheduled changes affecting BGP sessions, routing policies, and effective interconnection capacity between administrative domains can be applied. |
| | NTRU KEM Security Considerations |
| |
|
This document records security considerations for the NTRU key encapsulation mechanism that is being standardized in ISO/IEC 29192-4 Amendment 2. It is intended to help protocol designers and implementers decide when NTRU is safe to use, and how to use it without creating avoidable security regressions. |
| | Object-Oriented Programming Standard for Pure C |
| |
|
This document defines RFC-OOP-C, a standard for object-oriented programming in pure C. It specifies naming conventions, class structure macros, method macros, validation macros, memory allocation patterns, lifecycle management, build-level configuration, struct versioning, Doxygen documentation requirements, and a conformance checker interface (the RFC-OOP-C Conformance Checker, RFC_Checker). The standard targets C11 (ISO/IEC 9899:2011) and is applicable to any C project on any microcontroller or platform whose toolchain supports C11. Supplementary guidance is provided for embedded systems including thread-safety and memory allocation strategies compatible with bare-metal, FreeRTOS and embOS. |
| | Kinetic Identity Documents and Service Manifests |
| |
|
This document specifies Kinetic Identity Documents (KIDs) and Capability Manifests, a higher-layer identity and service-discovery model for the Kinetic Network Protocol. A Kinetic name is a transferable human-readable alias. A KID is a persistent cryptographic identity. A Capability Manifest, signed by the KID, describes the services currently offered by that identity. This separation prevents applications from confusing a name with an identity and allows names to resolve to websites, APIs, messaging endpoints, storage systems, agents, and future services without changing the underlying naming protocol. |
| | The Kinetic Network Protocol |
| |
|
This document specifies the Kinetic Network Protocol, a decentralized naming and ownership protocol for binding human-readable names to cryptographic identity keys without a central registry, blockchain, or monetary renewal system. Kinetic uses a commit-reveal flow, verifiable delay functions (VDFs), signed heartbeat records, and redundant Distributed Hash Table (DHT) storage to make name acquisition sequential, verifiable, and resistant to front-running, mass registration, and stale-state capture. This document defines the protocol model, required records, validation rules, and security considerations for interoperable Kinetic network implementations. |
| | Path Computation Element Communication Protocol (PCEP) Extensions for Signaling Multipath Information |
| |
|
This document defines Path Computation Element Communication Protocol (PCEP) extensions to signal multipath information, associating multiple forwarding paths with a single PCEP Label Switched Path (LSP) to allow load-balancing and redundancy across diverse paths. The extensions are generic and applicable to both stateless and stateful PCEP, and are designed to be reusable for future path types. Their primary application is Segment Routing (SR) Policy, where a Candidate Path can contain multiple Segment Lists: current PCEP extensions for SR Policy only allow signaling of a single Segment List per Candidate Path. These extensions enable multipath capabilities such as weighted or equal-cost load-balancing across paths. |
| | Path Computation Element Communication Protocol (PCEP) extension to advertise the PCE Controlled Identifier Space |
| |
|
The Path Computation Element Communication Protocol (PCEP) provides a mechanism for the Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. The Stateful PCE extensions allow stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) using PCEP. Furthermore, PCE can be used for computing paths in the SR networks. Stateful PCE provides active control of MPLS-TE LSPs via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. Further, stateful PCE could also create and remove PCE-initiated LSPs by itself. A PCE-based Central Controller (PCECC) simplify the processing of a distributed control plane by integrating with elements of Software-Defined Networking (SDN). In some use cases, such as PCECC provisioning or Binding Segment Identifier (SID) for Segment Routing (SR) allocation, there are requirements for a stateful PCE to make allocation of labels, SIDs, etc. These use cases require PCE to be aware of various identifier spaces from where to make allocations on behalf of a PCC. This document defines a generic mechanism by which a PCC can inform the PCE of the identifier space set aside for the PCE control via PCEP. The identifier could be an MPLS label, a SID, or any other identifier that can be allocated and managed by the PCE. |
| | A YANG Data Model for the Virtual Router Redundancy Protocol (VRRP) |
| |
|
This document specifies a YANG data model for the Virtual Router Redundancy Protocol (VRRP). Both versions 2 and 3 of VRRP are covered. The VRRP terminology has been updated to conform to inclusive language guidelines for IETF technologies. This document obsoletes RFC 8347. |
| | Secure Reporting of SUIT Update Status |
| |
| | draft-ietf-suit-report-22.txt |
| | Date: |
23/06/2026 |
| | Authors: |
Brendan Moran, Henk Birkholz |
| | Working Group: |
Software Updates for Internet of Things (suit) |
|
The Software Update for the Internet of Things (SUIT) manifest provides a way for many different update and boot workflows to be described by a common format. This document specifies a lightweight feedback mechanism that allows a developer in possession of a manifest to reconstruct the decisions made and actions performed by a manifest processor. |
| |
|
| |
| | A YANG Data Model for Optical Impairment-aware Topology |
| |
|
Provisioning an optical connection requires that path continuity, resource availability, and impairment constraints be satisfied in order to determine viable paths through the network. This process is known as Impairment-Aware Routing and Wavelength Assignment (IA-RWA) in Wavelength Switched Optical Networks (WSONs) and as Impairment- Aware Routing and Spectrum Assignment (IA-RSA) in Spectrum Switched Optical Networks (SSONs). This document defines a YANG data model for impairment-aware Traffic Engineering (TE) topologies in optical networks. The model augments the technology-agnostic YANG data model for TE topologies and provides read-only topology information, including optical impairments. Such information can be used, for example, by a Path Computation Engine (PCE) to compute optically feasible paths prior to connection establishment. |
| | Common YANG Data Types for Layer 0 Optical Networks |
| |
| | draft-ietf-ccamp-rfc9093-bis-20.txt |
| | Date: |
22/06/2026 |
| | Authors: |
Sergio Belotti, Italo Busi, Dieter Beller, Esther Le Rouzic, Aihua Guo |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
|
This document defines a collection of common data types, identities, and groupings in the YANG data modeling language. These common types and groupings, derived from the built-in YANG data types, identities, and groupings are intended to be imported by modules that model Optical Layer 0 configuration and state capabilities, such as Wavelength Switched Optical Networks (WSONs) and flexi-grid Dense Wavelength Division Multiplexing (DWDM) networks. This document obsoletes RFC 9093 by replacing the YANG module it contained with a new revision that includes additional YANG data types, identities and groupings. |
| | Operational Practices for Digital Autonomy and Meaningful Connectivity through Circular Management of User and Network Devices |
| |
|
This document systematizes operational practices observed across multiple community-centred deployments that aim to improve meaningful connectivity and community digital autonomy through the circular management of end-user and network devices. It is published as an Informational RFC on the IRTF stream and does not define Internet standards or protocol requirements. The document addresses a foundational but often overlooked dependency of Internet connectivity deployments: the availability, repairability, governance, sharing, reuse, and lifecycle management of network and end-user devices required for meaningful participation in the Internet. Based on operational experience from deployments in Spain, Argentina, and Senegal, this document describes practices that have demonstrated positive outcomes for connectivity, social inclusion and community capacity, and environmental sustainability. These practices are presented as descriptive guidance derived from operational experience rather than as normative requirements. They complement research within the IRTF GAIA Research Group by documenting reproducible approaches that improve the sustainability, autonomy, and long-term viability of community connectivity infrastructure and meaningful participation in underserved contexts. |
| | BGP Entropy Label Characteristic |
| |
| | draft-ietf-idr-elc-01.txt |
| | Date: |
22/06/2026 |
| | Authors: |
Bin Wen, Kevin Wang, John Scudder, MOHANTY Satya, Serge Krier, Kireeti Kompella, Bruno Decraene |
| | Working Group: |
Inter-Domain Routing (idr) |
|
The BGP Next Hop Dependent Characteristics Attribute (NHC) provides a way for a BGP speaker to advertise certain characteristics of routes. In particular, it is useful to advertise forwarding plane features. This specification defines an NHC characteristic that can be used to advertise the ability to process the MPLS Entropy Label as an egress LSR for all NLRI advertised in the BGP UPDATE. It updates RFC 6790 and RFC 7447 concerning this BGP signaling. |
| | An Experimental Connectivity Monitoring Metric for IPPM |
| |
|
Within a Segment Routing (SR) domain, segment routed measurement packets can be sent along pre-determined paths. This enables new kinds of active measurements. Connectivity monitoring supervises the state and performance of a connection or a (sub)path from central monitoring systems. This document specifies an experimental Type-p connectivity monitoring metric to accomodate such operational needs. |
| | The Hashed Token SASL Mechanism |
| |
| | draft-ietf-kitten-sasl-ht-02.txt |
| | Date: |
22/06/2026 |
| | Authors: |
Florian Schmaus, Thilo Molitor, Christoph Egger |
| | Working Group: |
Common Authentication Technology Next Generation (kitten) |
|
This document specifies the family of Hashed Token SASL mechanisms, which enable a proof-of-possession-based authentication scheme and are meant to quickly re-authenticate a previous session. The Hashed Token SASL mechanism's authentication sequence consists of only one round-trip. The usage of short-lived, exclusively ephemeral hashed tokens is achieving the single round-trip property. The SASL mechanism specified herein further provides hash agility, mutual authentication, support for channel binding, and the capability to exchange authenticated key/value pairs. |
| | XML Encoding of Data Modeled with YANG |
| |
|
This document defines encoding rules for representing YANG modeled configuration data, state data, parameters of Remote Procedure Call (RPC) operations or actions, and notifications defined using XML. |
| | Intent-Based Network Management Automation in 5G Networks |
| |
|
This document describes Network Management Automation (NMA) of cellular network services in 5G networks. For NMA, it proposes a framework empowered with Intent-Based Networking (IBN). The NMA in this document deals with a closed-loop network control, network intent translator, and network management audit. To support these three features in NMA, it specifies an architectural framework with system components and interfaces. Also, this framework can support the use cases of NMA in 5G networks such as the data aggregation of Internet of Things (IoT) devices, network slicing, and the Quality of Service (QoS) in Vehicle-to-Everything (V2X). |
| | Recommendations for using Multiple IP Addresses in Benchmarking Tests |
| |
|
RFC 2544 has defined a benchmarking methodology for network interconnect devices. Its test frame format contained fixed IP addresses and fixed port numbers. RFC 4814 introduced pseudorandom port numbers but used a single source and destination IP address pair when testing with a single destination network. This limitation may cause an issue when the device under test uses the Receive-Side Scaling (RSS) mechanism in the packet processing flow. RSS has two implementations: the first only includes the IP addresses, whereas the second also includes the port numbers in the tuple used for hashing. Benchmarking tests that use a single IP address pair and RFC 4814 pseudorandom port numbers are biased against the first type of RSS implementation because traffic is not distributed among the processing elements. This document recommends the usage of pseudorandom IP addresses in a similar manner as RFC 4814 did with the port numbers. If accepted, this document updates all affected RFCs, including RFC 2544, RFC 4814, RFC 5180, RFC 8219. |
| | Data Fields for Congestion Measurement |
| |
|
Congestion Measurement collects the congestion information in the packet while the packet traverses a path. The sender sets the congestion measurement data fields in the packet header indicating the network device along the path to update the congestion information field in the packet. When the packet arrives at the receiver, the congestion information field will reflect the degree of congestion across network path. Congestion Measurement can enable precise congestion control, assist in effective load balancing, and simplify network debugging. This document defines data fields for Congestion Measurement. Congestion Measurement Data Fields can be encapsulated into a variety of protocols. |
| | IPv6 Options for Congestion Measurement |
| |
|
The Congestion Measurement enables precise congestion control, assists in effective load balancing, and simplifies network debugging by accurately reflecting the degree of congestion across network paths. This document defines how Congestion Measurement Data Fields are encapsulated in IPv6. |
| | YANG Data Model for supporting multipath IGMP/MLD proxies |
| |
|
The ability to support multiple upstream interfaces in IGMP/MLD proxies necessitates configuring different upstream interfaces for specific multicast channels or sessions. [RFC9398] defined YANG Data Model for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxy Devices. Building on that foundation, this document proposes an augmentation of thet model for the support of multiple upstream interfaces in IGMP/MLD proxies. |
| | FrodoKEM: key encapsulation from learning with errors |
| |
| | draft-longa-cfrg-frodokem-03.txt |
| | Date: |
22/06/2026 |
| | Authors: |
Patrick Longa, Joppe Bos, Stephan Ehlen, Douglas Stebila |
| | Working Group: |
Individual Submissions (none) |
|
This internet draft specifies FrodoKEM, an IND-CCA2 secure Key Encapsulation Mechanism (KEM). About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-longa-cfrg-frodokem/. Source for this draft and an issue tracker can be found at github.com/dstebila/frodokem-internet-draft. |
| | Using IS-IS To Advertise Power Group Membership |
| |
|
Many networks have a daily utilization pattern. For example, a network might be busy during the day and less busy at night. If the network is robust, it has enough capacity to satisfy demand during peak hours and excess capacity during non-peak hours. That excess capacity increases energy costs and environmental impact. [I-D.many-teas-power-steering] introduces a Power Conserving Path Placement Strategy (PCPPS). When possible, PCPPS concentrates traffic onto a small set of network resources. When traffic is concentrated onto a small set of network resources, other network resources become idle and can be powered down until they are needed again. This solves the problem of excess capacity during non-peak hours. PCPPS uses information that is distributed by an IGP. This document specifies the IS-IS encoding for that information. |
| | RPKI-based Validation with Prioritized Resource Data |
| |
|
The Resource Public Key Infrastructure (RPKI) provides globally verifiable signed routing security data, such as Route Origin Authorizations (ROAs). Operators also commonly use local or supplemental data sources, including SLURM files, operator-maintained exceptions, IRR-derived inputs, and other operator-selected supplemental data, to improve local routing decisions. These sources may not have the same authority as signed RPKI objects and therefore may require operator-configured priority-safe handling. This document describes a framework for RPKI-based validation with prioritized resource data. It defines priority-safe handling semantics that allow operators to use data sources with different levels of authority or assurance for local routing policy, while preserving the global authorization semantics of signed RPKI data. The document also discusses deployment models with different implementation costs and operational trade-offs. |
| | Security Considerations and Requirements 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 presents attack scenarios, a threat model, security requirements, and per-scenario mitigation considerations, supported by a reference model. The document is Informational: it does not define a protocol, message format, or registry, and concrete mechanisms are left to companion specifications. It emphasizes origin authentication and admission control, constraint validation, invocation validation, multi-hop chain-of-custody, enforcement placement across hops, and policy- driven responses to drift, while remaining independent of any specific deployment domain. |
| | Using GOST Cryptographic Algorithms for JWT security |
| |
|
This specification registers cryptographic algorithms and identifiers for GOST R 34.10 digital signatures and public keys, GOST R 34.11 hash functions, GOST 34.12 encryption algorithms to be used with JSON Web Signatures (JWS), JSON Web Encryption (JWE), and JSON Web Keys (JWK) specifications. |
| | Authorization Evidence and Audit Trail for OAuth 2.0 Access Tokens |
| |
|
This specification defines an authorization details type for including authorization evidence and audit trail information in OAuth 2.0 access tokens using the Rich Authorization Requests (RAR) framework. When an Authorization Server processes user consent, it enriches the authorization details with cryptographic proof of user confirmation, supporting accountability, compliance, and dispute resolution in scenarios where autonomous agents act on behalf of users. |
| | On iBGP Full-Mesh Requirements |
| |
|
A common misconception within the Internet community is that internal BGP (iBGP) strictly requires a full mesh or alternatives such as Route Reflectors. In reality, a full mesh is an architectural design choice driven by route visibility needs, rather than a protocol mandate. This document analyzes the historical origins of this misunderstanding and clarifies the specific scenarios—multihomed stub Autonomous Systems (ASes)— where an iBGP full mesh is unnecessary and operationally undesirable. |
| | EAP-PSK-256: A Quantum resistant version of EAP-PSK |
| |
| | draft-eap-psk-256-01.txt |
| | Date: |
22/06/2026 |
| | Authors: |
Bruno ROHEE, Emmanuel KONAN, Michael Le Clerc, Clement DEVUN |
| | Working Group: |
Individual Submissions (none) |
|
This document proposes a lightweight, quantum-resistant protocol for mutual authentication and secret key establishment based on a shared secret over a network. While the existing EAP-PSK protocol provides mutual authentication and key establishment, it faces significant limitations due to evolving security standards. EAP-PSK-256 addresses these vulnerabilities through the following rationales: * Quantum resistance: Legacy EAP-PSK uses the symmetric algorithm AES-128, which is theoretically vulnerable to Grover's cryptographic attack. This document specifies a new EAP protocol that uses quantum-resistant symmetric algorithms. * Regulatory Alignment: EAP-PSK-256 replaces the key generation mechanism used in EAP-PSK with a standardized key derivation mechanism from NIST SP800-108. * Enhanced Entropy: Unlike EAP-PSK, which relied solely on Peer randomness (RAND_P) for session keys derivation, EAP-PSK-256 strengthens these keys by mixing entropy from both the Peer and the Server (RAND_S). This ensures that both parties contribute to the cryptographic randomness of the session. |
| | Information Asymmetry and Deployment Gaps in RPKI-based Route Origin Validation |
| |
|
The Resource Public Key Infrastructure (RPKI) and Route Origin Validation (ROV) have made significant progress. Over 60% of IPv4 routes now have ROAs, and more than 70% of Internet traffic flows to ROA-covered prefixes. A growing number of large transit providers actively reject RPKI-invalid routes. Despite these achievements, however, thousands of RPKI-invalid routes persistently appear in the global routing table, and their count has not shown a sustained downward trend over the years. More importantly, the deployment of strict ROV drop policies is highly uneven. While large transit providers have largely embraced dropping invalids, the long tail - tens of thousands of stub ASes and small regional ISPs - remains on the sidelines, often keeping ROV in monitor-only mode or not deploying it at all. This document analyzes the root causes behind these persistent gaps: (1) inherent *synchronization asymmetry* between the RPKI management plane and router control planes, and (2) the inevitable possibility of *errors on both planes* (ROA configuration and router origin configuration). These causes lead to a fundamental *information asymmetry*: downstream routers cannot distinguish self-inflicted invalids (due to sync delays or misconfigurations) from true prefix hijacks. We examine the operational harms of this asymmetry - unnecessary blackholes, path shifts, global route churn, and long-lived connectivity loss - and explain why the long tail remains reluctant to deploy ROV. We then identify the informational requirements that any enhanced system would need to meet: source-side cross-validation to prevent self-inflicted invalids, and downstream consistency information to reconcile local ROV outcomes with the origin's intent. The goal is to enable more confident and widespread deployment of strict ROV policies while preserving the existing RPKI-ROV architecture. This document does not propose a specific protocol solution. It defines the problem space and information needs, providing a foundation for future work. |
| | An Entropy Header for Load Balancing of IPsec ESP Traffic |
| |
|
When IPsec Encapsulating Security Payload (ESP) is used in tunnel mode, an intermediate node cannot inspect the encrypted inner headers to derive entropy for Equal-Cost Multipath (ECMP) or Link Aggregation Group (LAG) path selection. Path selection is then driven by outer header fields that are identical for every packet of a given tunnel, so all packets of the tunnel are placed on a single path regardless of the number of inner flows. This document defines the ESP Entropy Header, an IP protocol header that is placed immediately ahead of ESP and carries an entropy value in a fixed position that transit nodes can use for path selection. It also defines an Internet Key Exchange Protocol Version 2 (IKEv2) extension with which peers negotiate the use of the header on a per- Child-SA basis. The mechanism applies to both IPv4 and IPv6. |
| | Structured Data Schema Interaction Protocol for Multi-Agent Collaboration |
| |
|
This document defines a structured data schema interaction protocol for multi-agent collaboration. As AI agents increasingly interoperate across heterogeneous platforms, natural-language-based communication suffers from semantic drift, high inference overhead, and ambiguous data flow. This protocol introduces a standardized key-value schema with semantic annotations, enabling deterministic, efficient, and interoperable agent-to-agent communication. A lightweight schema negotiation mechanism is provided for initial alignment at the beginning of communication, while an optional key- value update mechanism allows agents to reflect evolving requirements without breaking existing structured data schema interaction protocol. |
| | Carrying a Network Slice Indicator in TWAMP and STAMP Probe Packets for SRv6 Networks |
| |
|
Network Slices realized over Segment Routing over IPv6 (SRv6) networks use slice-specific forwarding resources that are selected by a slice indicator carried in the IPv6 packet. For two-way active measurement results to reflect the conditions experienced by traffic within a given network slice, the probe packets generated by the Two- Way Active Measurement Protocol (TWAMP) and the Simple Two-Way Active Measurement Protocol (STAMP) need to be forwarded over the same slice-specific resources as the data traffic they are intended to characterize. This document specifies how a slice indicator is carried in TWAMP and STAMP probe packets so that those packets are forwarded through the resources of a target slice, and it defines the corresponding Session-Sender and Session-Reflector behavior. The procedures are independent of the specific encoding used to carry the slice indicator in the SRv6 data plane. |
| | Classic McEliece Security Considerations |
| |
|
This document contains considerations for use of the Classic McEliece Post-Quantum Key Encapsulation Method (KEM). The document is intended as introduction and guidance to encourage adoption of Classic McEliece in IETF standards-track protocols. |
| | Streamlined NTRU Prime Security Considerations |
| |
|
This document contains considerations for use of the Streamlined NTRU Prime Post-Quantum Key Encapsulation Method (KEM). The document is intended as introduction and guidance to encourage adoption of Streamlined NTRU Prime in IETF standards-track protocols. |
| | DNS-Published Content Security Policy Reporting Policy |
| |
|
This document specifies a mechanism by which a domain operator can publish a Content Security Policy reporting endpoint policy in the Domain Name System. The mechanism allows user agents and reporting processors to discover one or more domain-authorised endpoints for receiving Content Security Policy violation reports, independently of the HTTP response that triggered the report. The mechanism is intended to improve administrative consistency across distributed web estates where the domain operator controls DNS but does not consistently control every web server, content management system, proxy, application stack, or hosting platform serving content beneath the domain. This document does not define DNS-based CSP enforcement. It defines only DNS-published reporting endpoint policy. User agents MUST NOT treat this mechanism as a replacement for the Content-Security-Policy or Content-Security-Policy-Report-Only HTTP response header fields. |
| | Security Considerations for FrodoKEM |
| |
|
ISO standardized FrodoKEM in June 2026 [ISO18033-2-AMD2]. This document provides security guidance for FrodoKEM for use in protocols. It explains what security claims protocol designers may rely on, what assumptions and conditions are required, what parameter sets are in scope, and what implementors need to do to use FrodoKEM safely. The scope follows the current FrodoKEM Internet-Draft [I-D.FrodoKEM]. |
| | WebRTC-HTTP Egress Protocol (WHEP) |
| |
| | draft-ietf-wish-whep-04.txt |
| | Date: |
22/06/2026 |
| | Authors: |
Sergio Murillo, Cheng Chen, Dan Jenkins |
| | Working Group: |
WebRTC Ingest Signaling over HTTPS (wish) |
|
This document describes a simple HTTP-based protocol that will allow WebRTC-based viewers to watch content from streaming services and/or Content Delivery Networks (CDNs) or WebRTC Transmission Network (WTNs). |
| |
|
| |
| | Domain Control Validation using DNS |
| |
|
Many application services on the Internet need to verify ownership or control of a domain in the Domain Name System (DNS). The general term for this process is "Domain Control Validation", and it can be done using a variety of methods such as email, HTTP/HTTPS, or the DNS itself. This document focuses only on DNS-based methods, which typically involve the Application Service Provider requesting a DNS record with a specific format and content to be visible in the domain to be verified. There is wide variation in the details of these methods today. This document provides some best practices to avoid known problems. |
| | dry-run DNSSEC |
| |
|
This document describes a method called "dry-run DNSSEC" that allows for testing DNSSEC deployments without affecting the DNS service in case of DNSSEC errors. It accomplishes that by introducing new DS Type Digest Algorithms that when used in every record of a DS RRset, referred to as dry-run DS, signal to validating resolvers that dry- run DNSSEC is used for the zone. DNSSEC errors are then reported with DNS Error Reporting, but any bogus responses to clients are withheld. Instead, validating resolvers fallback from dry-run DNSSEC and provide the response that would have been answered without the presence of the dry-run DS. A further EDNS option is presented for clients to opt-in for dry-run DNSSEC errors and allow for end-to-end DNSSEC testing. |
| | JMAP Enhanced Result References |
| |
|
This document specifies an extension to the JSON Meta Application Protocol (JMAP) that enhances the result reference mechanism defined in [RFC8620]. The extension allows result references to be used in additional contexts beyond method call arguments, specifically within object properties during JMAP /set operations and within FilterCondition objects used in /query operations. Additionally, this specification extends result references to support JSON Path expressions ([RFC9535]) as an alternative to JSON Pointer ([RFC6901]), providing more expressive query capabilities for extracting values from previous method call results. These enhancements enable more efficient data reuse patterns across JMAP method calls, reducing the need for multiple round trips between client and server. |
| | Reverse HTTP CONNECT for TCP and UDP |
| |
|
This document specifies an extension to the HTTP CONNECT method, enabling a proxy client to accept inbound TCP and UDP sessions proxied through HTTP/1.1, HTTP/2, or HTTP/3. This mechanism allows the client to dynamically advertise available local or internal network services and expose them through a HTTP proxy without reliance on IP routing. |
| | Analysis of Hybrid Key Establishment and Standalone ML-KEM in TLS 1.3 |
| |
|
This memo is a work-in-progress and maps out the technical facets relevant to the quantum-resistant key establishment in TLS 1.3 and provides some preliminary discussion to help developers and policymakers make informed choices. In particular, it presents hybrid key establishment and standalone ML-KEM in TLS 1.3. Moreover, it offers minimal implementation guidance for hybrid key establishment. The memo finally presents technical insights into hybrid key establishment and standalone ML-KEM in TLS 1.3. Our observation is that hybrid key establishment is preferable over standalone ML-KEM until a powerful CRQC exists which breaks most bits of pre-quantum. This memo is not a standard nor has it been shown to have consensus of the IETF community. |
| | NTRU+ Security Considerations |
| |
|
This document describes security considerations for the use of NTRU+ in Internet protocols. NTRU+ is a lattice-based key encapsulation mechanism (KEM) based on the NTRU framework and designed to provide IND-CCA2 security. The document summarizes the scheme structure and parameter sets, and discusses implementation and protocol considerations including key-generation rejection sampling, input validation, pairwise consistency testing, explicit rejection behavior, randomness requirements, and side-channel leakage during decapsulation. It is intended to help protocol designers and implementers use NTRU+ safely in settings such as authenticated key exchange, public key encryption, and KEM-based authentication. |
| | Security Considerations for NTRU-family KEMs |
| |
|
This document provides an informational review checklist for NTRU- family KEMs. It covers security claims, assumptions, reductions, concrete attack estimates, correctness and decryption-failure analyses, and implementation behavior for named specifications and parameter sets. It does not define a KEM interface or make recommendations among candidate KEMs. |
| | Token Status List (TSL) |
| |
|
This specification defines a status mechanism called Token Status List (TSL), data structures and processing rules for representing the status of tokens secured by JSON Object Signing and Encryption (JOSE) or CBOR Object Signing and Encryption (COSE), such as JWT, SD-JWT, CBOR Web Token, and ISO mdoc. It also defines an extension point and a registry for future status mechanisms. |
| | General Source Address Validation Capabilities |
| |
|
The SAV rules of existing source address validation (SAV) mechanisms are derived from other core data structures (e.g., FIB-based uRPF) that are not dedicatedly designed for source filtering. Consequently, these mechanisms have limitations in deployable scenarios and traffic handling policies. To overcome these limitations, this document introduces general SAV capabilities from a data plane perspective. How to implement the capabilities and how to generate SAV rules are not in the scope of this document. |
| |
|
| |
| | 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. |
| | Common Interface Extension YANG Data Models |
| |
|
This document defines two YANG modules that augment the Interfaces data model defined in the "YANG Data Model for Interface Management" with additional configuration and operational data nodes to support common lower layer interface properties. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. |
| | SakiAgentSSH Secure Protocol Specification |
| |
|
This document describes the Saki Agent Secure Stream (SASS) protocol, version 1.4. 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) with 6-Response state machine convergence and Safety Gradient loss bounding. SASS v1.4 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. |
| | 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 with object payloads 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. |
| | Add TTLs to DNS errors |
| |
|
When a DNS server replies an error other than NXDOMAIN, there is no mechanism to specify how long this error can be cached by the recepient. This document introduces a mechanism where a server can specify the time to live (TTL) of an error by adding a SOA record to the additional section of a reply. Clients can use this TTL at their discretion. In particular, clients can limit the TTL to a maximum value, impose a minimum value or just ignore the TTL value all together. |
| | Source-Selective BGP Framework |
| |
|
The Border Gateway Protocol (BGP) routes traffic solely based on destination IP prefixes. Source Selective BGP (SSB) introduces an architecture combining BGP and Resource Public Key Infrastructure (RPKI) extensions, which allows prefix holders to cryptographically signal RPKI source authorization policies for their advertised reachability. SSB distributes references to these policies via a new BGP path attribute, allowing routing systems to incorporate source-based constraints into local forwarding policies. Crucially, SSB does not define a source address validation mechanism, mandate packet filtering behavior, or alter fundamental destination-based routing; interpretation remains a matter of local operator policy. This document provides the overall architectural context and deployment rationale for the SSB protocol suite. |
| | Selective Disclosure Profile for Agent Action Capsules |
| |
|
This document normatively profiles the per-field selective-disclosure extension point reserved in draft-mih-scitt-agent-action-capsule-01 Section 9.2 (Selective Disclosure). It defines the salted-hash commitment encoding, decoy-digest construction, disclosure format, producer requirements, and verifier checks for selectively disclosable fields in Agent Action Capsule payloads. The mechanism follows the SD-JWT selective-disclosure model (RFC 9901) — salted- hash commitments, decoy digests, and disclosed [salt, name, value] triples — using JCS (RFC 8785) canonicalization, which is already the base Capsule profile's canonical form. SD-JWT (RFC 9901) is the JSON form; SD-CWT (draft-ietf-spice-sd-cwt) is the CBOR/dCBOR sibling. Because the Capsule payload is JSON, this profile uses the SD-JWT (JSON) construction, cited alongside the SPICE WG's SD-CWT work for SCITT-ecosystem consistency. Verifier checks are deterministic and reproducible from the Capsule bytes plus a provided disclosure set alone; no clock, network access, model invocation, or external lookup beyond the provided disclosures is required. |
| | The Open Tabs Standard: Passkey-Rooted Delegated Signers for Non-Custodial Payment Channels on Solana |
| |
|
This document specifies the passkey-rooted delegated-signer authorization model of the Open Tabs Standard (OTS), a non-custodial payment-channel scheme on Solana. It uses Solana's native secp256r1 signature verification precompile ([SIMD-0075]) to authorize voucher signers via WebAuthn passkeys ([WEBAUTHN]). The model is interoperable with the Solana Session Intent ([draft-solana-session-00]), with which it shares the channel and voucher primitives. For a passkey-authorized signer it defines a distinct signatureType value, an exact signed message format, an exact Solana verification program, and a binding between the delegated signer and the channel's PDA derivation. A reference implementation is live on Solana mainnet. The dexter- vault program (account Hg3wRaydFtJhYrdvYrKECacpJYDsC9Px7yKmpncj2fhc) verifies secp256r1 signatures over a fixed canonical message via the SIMD-0075 precompile, records the active session key on the vault account, and exposes a read-only prove_passkey instruction for off- chain liveness attestation. A live reference vault (account 7FE9VUeabi3sF8wUABV7F3eyvEi1ekDbER9k5JBYrWAi) demonstrates the full lifecycle on Solana mainnet. |
| |
|
| |
| | Domain Connect Protocol - Asynchronous Flow Extension |
| |
|
This document defines the Asynchronous OAuth 2.0 extension to the Domain Connect Protocol specified in I-D.draft-ietf-dconn- domainconnect-02, Section . |
| | Authorization scheme for MOQT using Common Access Tokens |
| |
| | draft-ietf-moq-c4m-01.txt |
| | Date: |
18/06/2026 |
| | Authors: |
Will Law, Chris Lemmons, Gwendal Simon, Suhas Nandakumar |
| | Working Group: |
Media Over QUIC (moq) |
|
A token-based authorization scheme for use with Media Over QUIC Transport. |
| | SRH TLV Processing Programming |
| |
|
This document proposes a mechanism to program the processing rules of Segment Routig Header (SRH) optional TLVs explicitly on the ingress node. In this mechanism, there is no need to configure local configuration at the node to support SRH TLV processing. A network operator can program to process specific TLVs on specific segment endpoint nodes for specific packets on the ingress node, which is more efficient for SRH TLV processing. |
| | IP Payload Compression excluding transport layer |
| |
|
IP Payload Compression Protocol (IPComp) is used for compressing the IP payload in transmission to increase communication performance. The IPComp is applied to the payload of the IP datagram, starting with the first octet immediately after the IP header in IPv4, and the first octet after the excluded IPv6 Extension headers. However, transport layer information such as source port and destination port are useful in many network functions in transmission. This document defines extensions of IP payload compression protocol (IPComp) to support compressing the payload excluding the transport layer information, to enable network functions using transport layer information (e.g., ECMP) working together with the payload compression. This document also defines an extension of IPComp to indicate the payload is not compressed to solve the out-of-order problems between the compressed and uncompressed packets. |
| | Certificate Update in TLS 1.3 |
| |
|
This document defines a mechanism that enables TLS 1.3 endpoints to update their certificates during the lifetime of a connection using Exported Authenticators. A new extension is introduced to negotiate support for certificate update at handshake time. When negotiated, either endpoint can provide a post-handshake authenticator containing an updated certificate, delivered via a new handshake message. This mechanism allows long-lived TLS connections to remain valid across certificate rotations without requiring session termination. |
| | Considerations for Happy Eyeballs Error Reporting |
| |
|
This document introduces different aspects to be considered for the Happy Eyeballs error reporting. |
| | Canonical textual representation of BGP Path Attributes |
| |
|
Various implementations of the Border Gateway Protocol (BGP) use different formats for displaying the Path Attributes. This document defines the preferred textual formatting which is recommended for the implementations to use for human interfaces. To achieve consistent value formatting, this document formally updates RFC 9026 by canonicalizing the well-known community name formats. This document updates RFC 4360, RFC 4577, RFC 7432, and ... by specifying the canonical textual formatting of extended communities specified there. This document updates RFC 4940 by adding a textual tag column to the OSPFv2 Link State Type registry. This document updates RFC 7153 by adding a textual tag column to the extended community registry. (REMOVE THIS) This document is incomplete and needs completing the tables. |
| | CoAP Extensions for Asynchronous Task Resources |
| |
|
Many CoAP deployments need to start operations that cannot be completed within one request/response exchange. Existing deployments commonly model these operations with application-specific resources, payload formats, and polling or notification conventions. This makes clients, gateways, and proxies unable to interoperate across implementations that expose otherwise similar long-running operations. This document defines a CoAP task-resource pattern for asynchronous operations. It specifies a small set of CoAP Options and a CBOR status representation that allow a server to create a temporary task resource, allow a client to monitor, update, or cancel that task using existing CoAP methods, and allow task-state and task-progress observations to reuse the Conditional Query Parameters defined for CoAP Observe [I-D.ietf-core-conditional-attributes]. Autonomous control agents are one motivating use case, but the mechanisms are intended to be generally usable for constrained applications that need interoperable task orchestration. |
| | BGP Signed Origin Delegation Attestation (SODA) |
| |
| | draft-jiang-idr-bgp-soda-00.txt |
| | Date: |
18/06/2026 |
| | Authors: |
Shenglin(Forrest) Jiang, Ke Xu, Zhuotao liu, Xiaoliang Wang |
| | Working Group: |
Individual Submissions (none) |
|
This document defines BGP Signed Origin Delegation Attestation (SODA), an optional transitive BGP path attribute that carries a signed authorization, issued by the holder of an IP prefix, delegating origination of that prefix to a specified Autonomous System (AS) until a stated expiry time. Using SODA, a validator performing Route Origin Validation (ROV) can determine whether an ROV-Invalid result reflects an authorized delegation rather than a route hijack. |
| | BGP Source-Selective Attribute |
| |
|
This document specifies a new Border Gateway Protocol (BGP) Path Attribute, the BGP SOURCE_SELECTIVE Attribute. This attribute allows BGP speakers to reference Resource Public Key Infrastructure (RPKI) Source Authorization (SA) objects, including Source Prefix Authorization (SPA), within BGP UPDATE messages. These objects are created by prefix holders to define sources authorized to originate traffic toward their prefixes or subprefixes. Receiving BGP speakers can use this information to enforce security policies. The SOURCE_SELECTIVE Path Attribute supports multiple Source Authorization Identifier (SA-ID) fields to preserve authorization semantics during BGP route aggregation and summarization. This mechanism applies to BGP AFI 1 / SAFI 1 (IPv4 Unicast) and AFI 2 / SAFI 1 (IPv6 Unicast). |
| | A Profile for Source Prefix Authorizations (SPAs) |
| |
|
This document defines a standard profile for Source Prefix Authorizations (SPAs), a Cryptographic Message Syntax (CMS) protected content type for use with the Resource Public Key Infrastructure (RPKI). A SPA is a digitally signed object that allows the holder of an IP address prefix assigned by a Regional Internet Registry (RIR) to publish a list of source IP address prefixes authorized to send IP packets to that destination prefix or its subprefixes. To enforce these policies, a BGP speaker may include a SOURCE_SELECTIVE Path Attribute referencing the SPAs. This distributes policy references, enabling routing systems to incorporate source-based constraints into local forwarding policies and trigger control plane enforcement |
| | Privacy Pass Reverse Flow HTTP Transport |
| |
|
This document specifies an instantiation of Privacy Pass Reverse Flow [REVERSE-FLOW] where HTTP is used as a transport mechanism. It describes a novel HTTP header field that Clients and Origins can use to carry reverse flow data. |
| | Real-World Measurement of the Infrastructure-Cognitive Coupling Matrix R_cross: Closing the MVPS AI-Coherence Production Conjecture (IC9.1) |
| |
|
The MVPS AI-Coherence framework [I-D.melegassi-mvps-ai-coherence] defines an infrastructure-cognitive coupling matrix R_cross = Sigma_net^{-1/2} Sigma_cross Sigma_AI^{-1/2} and proves, in simulation, that a non-zero R_cross is the necessary and sufficient condition for the joint network-AI anomaly space to carry detection information that neither standalone monitor can recover. That document leaves two items open: (a) work item IC9.1, a statistical hypothesis test on R_cross over an empirical joint covariance, and (b) the CONJECTURE that E[R_cross] != 0 in production AI-on-network deployments. This companion document closes both. It specifies a permutation- based hypothesis test for the normalized cross-block correlation estimator, reports the FIRST real-wire measurement of R_cross on a production large-language-model serving path (n = 100 ticks, DeepInfra), and documents a pure-arithmetic reference implementation embedded in an operational system that reproduces the measurement number-for-number. The strongest coupling, latency_ms <-> output tokens, is r = +0.446 (permutation p = 0.0005) on the full series and survives the same-model confound control at r = +0.343 (p = 0.0135) within a single serving regime. The Frobenius norm ||R_cross||_F = 0.469 (full) / 0.443 (intra-regime) exceeds the non-triviality floor of 0.05, confirming the production conjecture for this deployment. The document also specifies how the measured coupling and the per-engine Mahalanobis distance D^2 are consumed by an operational Wald Sequential Probability Ratio Test (SPRT) as an additive evidence channel for surgical sub-environment bifurcation. |
| | Privacy Framework for Remote ATtestation procedureS |
| |
|
This document extends the RATS Architecture to consider "coercive uses of RATS" where a malicious Verifier or Relying Party uses RATS protocols to extract sensitive information from an Attester or a victim Verifier that it would not otherwise be inclined to disclose. This over-disclosure can include revealing sensitive measurements, stable identifiers, device fingerprints, vendor information, or conclusions derived from Evidence. This document defines a privacy framework for Remote Attestation that identifies this threat surfaces; classifies claims produced by Attesters and Presenters; restricts sensitive Evidence disclosure to authorized Trusted Verifiers using confidentiality protection; and describes privacy- preserving Attestation Results based on data minimization, Selective Disclosure, and Zero-Knowledge Proofs. |
| | The "" URI Scheme for Biometric-First Communication |
| |
|
This document registers the "âš®" (U+26AE, DIVORCE SYMBOL) Uniform Resource Identifier (URI) scheme for the Biometric-First Communication Protocol (BCCCOP). The scheme enables privacy-first, biometric-anchored addressing of resources and invocation of peer-to- peer operations across ultrasonic, BLE, and Wi-Fi transports. This document follows the URI scheme registration guidelines of RFC 7595. |
| | Out-of-Band Path Validation to Mitigate Inter-AS Routing Exploits |
| |
|
This document describes a mechanism for mitigating Inter-AS routing exploits and path tampering without introducing real-time cryptographic processing overhead on core routing engines. By utilizing Out-of-Band (OOB) Cryptographic Validation combined with localized caches via the RPKI-to-Router (RTR) protocol and Autonomous System Provider Authorization (ASPA), networks can asynchronously verify path plausibility. This architecture supports incremental, partial deployment to protect infrastructure against malicious traffic redirection and unauthorized path propagation at major internet exchange points. |
| | The Authorization Type Attestation (ATA) Protocol |
| |
|
This document describes a session-layer mechanism addressing a requirement independently exhibited by emerging agentic communication systems: the need for recipients to determine the authorization type of the communicating party (a human-controlled credential or an AI provider instance) before or during interaction. The Authorization Type Attestation (ATA) protocol defines a transport-layer extension that carries this authorization type using existing hardware roots of trust (Secure Enclaves, FIDO2, TPM, Confidential Computing) and PKI infrastructure. ATA does not replace existing identity systems (mTLS, SPIFFE, OAuth 2.1, FIDO2). ATA does not verify content authorship or model behavior. ATA provides a mechanism to carry authorization type at the session layer, composably with TLS, QUIC, MLS, MCP, and A2A. |
| | New Pure Post-Quantum Protocol Specification |
| |
|
The Abdelaziz Pure Key Protocol, a.k.a. APKP, was designed to protect systems with pure post-quantum mechanics and transition to full PQC in the future. It is used in high-security environments to protect against quantum attacks. This doxument replaces and supersedes draft-muhammad-apkp-pqcprotocol and draft-muhammad-ahkp-pqcprotocol. |
| | Agent Attribution Header Fields |
| |
|
When human users communicate with autonomous computer agent users, the human users should be able to identify that communication as coming from agent users and know which humans are responsible for the agent users. This document specifies email header fields that an email sender can use to transmit agent user attribution information to email receivers. The first header field is human readable and specifies the agent's responsible humans' email address. The second header field is machine readable and specified in JSON attribution information. |
| | A Concise Binary Object Representation (CBOR)-based Serialization Format for the Software Updates for Internet of Things (SUIT) Manifest |
| |
| | draft-ietf-suit-manifest-37.txt |
| | Date: |
18/06/2026 |
| | Authors: |
Brendan Moran, Hannes Tschofenig, Henk Birkholz, Koen Zandberg, Oyvind Ronningstad |
| | Working Group: |
Software Updates for Internet of Things (suit) |
|
This specification describes the format of a manifest. A manifest is a bundle of metadata about code/data obtained by a recipient (chiefly the firmware for an Internet of Things (IoT) device), where to find the code/data, the devices to which it applies, and cryptographic information protecting the manifest. Software updates and Trusted Invocation both tend to use sequences of common operations, so the manifest encodes those sequences of operations, rather than declaring the metadata. |
| |
|
| |
| | A YANG Data Model for L1 Connectivity Service Model (L1CSM) |
| |
| | draft-ietf-ccamp-l1csm-yang-28.txt |
| | Date: |
17/06/2026 |
| | Authors: |
Young Lee, Kwang-koog Lee, Haomian Zheng, Oscar de Dios, Daniele Ceccarelli |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
|
This document provides a YANG Layer 1 Connectivity Service Model (L1CSM). This model can be utilized by a customer network controller to initiate a connectivity service request as well as to retrieve service states for a Layer 1 network controller communicating with its customer network controller. |
| | Deterministic Networking SRv6 Data Plane for Service Protection |
| |
|
This document specifies the Deterministic Networking (DetNet) data plane aspects for service protection when operating over an IPv6/SRv6 Packet Switched Network. It leverages existing IPv6 encapsulations and behaviors. It uses the Redundancy SIDs in DetNet scenarios and optionally the Traffic Engineering mechanisms provided by SRv6. This document builds on the DetNet architecture and data plane framework. |
| | Automating DNS Delegation Management via DDNS |
| |
|
Delegation information (i.e. the NS RRset, possible glue, possible DS records) should always be kept in sync between child zone and parent zone. However, in practice that is not always the case. When the delegation information is not in sync the child zone is usually working fine, but without the amount of redundancy that the zone owner likely expects to have. Hence, should any further problems ensue it could have catastrophic consequences. The DNS name space has lived with this problem for decades and it never goes away. Or, rather, it will never go away until a fully automated mechanism for how to keep the information in sync automatically is deployed. This document proposes such a mechanism based on DNS Dynamic Updates (DDNS) secured with SIG(0) signatures, sent from the child to the parent across the zone cut. The target of the update is discovered via the DSYNC record defined in [RFC9859]. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-ietf-dnsop-delegation-mgmt-via-ddns (https://github.com/johanix/draft-ietf-dnsop-delegation-mgmt-via- ddns). The most recent working version of the document, open issues, etc, should all be available there. The authors (gratefully) accept pull requests. |
| | Secondary Certificate Authentication of HTTP Servers |
| |
|
This document defines a way for HTTP/2 and HTTP/3 servers to send additional certificate-based credentials after a TLS connection is established, based on TLS Exported Authenticators. |
| | HTTP Unencoded Digest |
| |
|
The Repr-Digest and Content-Digest integrity fields are subject to HTTP content coding considerations. There are some use cases that benefit from the unambiguous exchange of integrity digests of unencoded representation. The Unencoded-Digest and Want-Unencoded- Digest fields complement existing integrity fields for this purpose. This document updates the definitions of the terms "Integrity fields" and "Integrity preference fields" originally defined in RFC 9530. |
| | BGP Attribute Escape |
| |
|
BGP-4 [RFC 4271] has been very successful in being extended over the years it has been deployed. A significant part of that success is due to its ability to incrementally add new features to its Path Attributes when they are marked "optional transitive". Implementations that are ignorant of a feature for an unknown Path Attribute that are so marked will propagate BGP routes with such attributes. Unfortunately, this blind propagation of unknown Path Attributes may happen for features that are intended to be used in a limited scope. When such Path Attributes inadvertently are carried beyond that scope, it can lead to things such as unintended disclosure of sensitive information, or cause improper routing. In their worst cases, such propagation may be for malformed Path Attributes and lead to BGP session resets or crashes. This document calls such inadvertent propagation of BGP Path Attributes, "attribute escape". This document further describes some of the scenarios that leads to this behavior and makes recommendations on practices that may limit its impact. |
| | VLSM Tree Routing Protocol |
| |
|
This is a light weight routing protocol applicable inside a network that appears in the form of a tree and distribution of address space takes place with the approach of VLSM. It is based on setting default route inside VLSM tree. With this approach, routing information of the external world need not be passed down to the VLSM tree. Thus, load inside a router gets reduced substantially. This document includes IP-VPN with MPLS inside VLSM tree by extending RSVP-TE. |
| | Signaling Key State Via a DNS EDNS(0) Option |
| |
|
This document introduces the KeyState EDNS(0) option, to enable a child operator to query a parent UPDATE Receiver about the state of a SIG(0) key used to secure cross-zone-cut DNS UPDATE messages. The KeyState option allows the child to include a key state inquiry in its DNS query, and the parent to include the corresponding key state in its response. This addresses the challenge of maintaining synchronization of SIG(0) keys between the child and the parent UPDATE Receiver: the child can become aware of any issue with its SIG(0) key in advance, before attempting the next operational DNS UPDATE. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-berra-dnsop-keystate (https://github.com/johanix/draft-berra-dnsop-keystate). The most recent working version of the document, open issues, etc, should all be available there. The authors (gratefully) accept pull requests. |
| | Caller ID Verification In Heterogeneous Telecommunication Networks |
| |
| | draft-hao-civ-03.txt |
| | Date: |
17/06/2026 |
| | Authors: |
Feng Hao, Basil Thomas, Steve Smith, Muhammad Azad, Shen Wang |
| | Working Group: |
Individual Submissions (none) |
|
This document defines an extension to the INVITE header of the Session Initiation Protocol (SIP) to support a Caller ID Verification (CIV) method. CIV authenticates the caller ID of an incoming call through a challenge-and-response process across both IP and non-IP networks without requiring a trusted third party or a public key infrastructure. When receiving a call with a claimed phone number, the called party holds the call and sends a quickly terminated INVITE request (like a flash call) to that number, carrying a short 4-digit challenge embedded as part of the caller ID. A genuine caller would receive the challenge and respond by echoing the same digits, e.g., through DTMF (Dual-Tone Multi-Frequency). The proposed extension involves two changes to the INVITE header. First, it adds a new option tag, "civ", in the Supported header field of the INVITE request. This tag allows the calling party to indicate support for CIV in the initial call. Second, it adds a special value "civ-veri- call" for the Purpose parameter of the Call-Info header field. This value allows the called party to make a verification call, indicating the purpose of the call is to transmit a challenge rather than establish a phone conversation. CIV uses the standard Session-ID header in the INVITE request to allow the calling party to explicitly match the verification call with the initial call. Whilst this document focuses on IP networks, the same CIV protocol also works with non-IP networks (e.g., SS7) by including the "civ" tag, the "civ-veri-call" value and the session ID in the User-to-User Information (UUI) parameter. |
| | LISP-Based Network for AI Infrastructure |
| |
|
The Locator/Identifier Separation Protocol (LISP) control plane provides the mechanisms to support Scale-Up, Scale-Out and Scale- Across backend networks within AI infrastructure. This document describes how LISP enables a unified control plane architecture that accommodates different scaling technologies, offering flexibility in deployment. By leveraging lisp mechanisms including EID-to-RLOC- mapping/pxTR registrations, publication-subscription and VPN instance-based segmentation ([RFC9300][RFC9301][RFC9437][I-D.ietf- lisp-site-external-connectivity][I-D.ietf-lisp-vpn]), the architecture delivers scalable high bandwidth for large training workloads, ultra-low-latency collective operations, and a simplified control framework that seamlessly spans heterogeneous accelerator fabrics. This approach allows AI/ML applications (whether focused on training or inference) to run workloads efficiently with resiliency on a converged infrastructure, supporting diverse deployment scenarios using the same underlying network fabric. |
| | BGP Unreachability Information SAFI |
| |
| | draft-tantsura-idr-unreachability-safi-06.txt |
| | Date: |
17/06/2026 |
| | Authors: |
Jeff Tantsura, Donald Sharp, Vivek Venkatraman, Karthikeya Muppalla, Maciej Rzehak, Abderrahman Jouhari, Smit Parikh |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a new BGP Subsequent Address Family Identifier (SAFI) called "Unreachability Information" that allows the propagation of prefix unreachability information through BGP without affecting the installation or removal of routes in the Routing Information Base (RIB) or Forwarding Information Base (FIB). This mechanism enables network operators to share information about unreachable prefixes for monitoring, debugging, and coordination purposes while maintaining complete separation from the active routing plane. |
| | TIBET: Transaction/Interaction-Based Evidence Trail |
| |
|
This document defines TIBET (Transaction/Interaction-Based Evidence Trail), a data model and protocol for constructing cryptographically linked provenance chains over interactions between autonomous agents, human actors, and automated processes. A TIBET token captures four dimensions of provenance: content (ERIN), references (ERAAN), context (EROMHEEN), and intent (ERACHTER). Tokens are cryptographically signed, hash-chained, and designed for append-only storage. TIBET is transport-agnostic and encoding-flexible, with JSON over HTTPS as the baseline serialization. This document specifies the token data model, chain semantics, canonicalization rules, verification procedures, and integration points with companion protocols JIS [JIS], UPIP [UPIP], RVP [RVP], and AINS [AINS]. |
| | JIS: JTel Identity Standard - Identity and Trust Establishment for Autonomous Agents |
| |
|
This document defines JIS (JTel Identity Standard), a protocol for establishing identity, negotiating trust, and binding intent declarations to actor interactions. JIS provides three core mechanisms: a dual-keypair identity model separating human-device binding (HID) from device authentication (DID), a trust establishment handshake (FIR/A) that negotiates capabilities and records intent, and a human-readable context layer (Humotica) that captures the sense, context, intent, and explanation for every interaction. JIS is transport-agnostic and operates as a semantic layer above existing protocols. It integrates with TIBET [TIBET] for provenance tracking, and is consumed by UPIP [UPIP], RVP [RVP], and AINS [AINS] for process integrity, continuous verification, and agent discovery respectively. |
| | RVP: Real-time Verification Protocol - Continuous Identity and Process Verification |
| |
|
This document defines RVP (Real-time Verification Protocol), a protocol for continuous identity verification through ordered cascades of verification methods. Unlike traditional authentication models that verify once and trust until session expiry, RVP treats every interaction as a verification moment. Each moment produces a Verification Token: a cryptographic evidence record capturing which methods were used, what confidence each produced, and whether the accumulated confidence meets the required threshold. RVP defines a Verification Cascade: an ordered chain of verification methods (behavioral biometrics, physical identity, device context) where each layer activates only when preceding layers produce insufficient confidence. The cascade produces evidence at every step; enforcement is a local policy decision. RVP integrates with TIBET [TIBET] for provenance tokens and JIS [JIS] for identity semantics. The protocol is designed for local-first operation with no dependency on centralized identity providers. |
| | 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-02 with: framework integration results for AutoGen (55 percent total cost reduction, 59 coordination hops) and Pydantic AI (85 percent total cost reduction, 59 coordination hops); a four-framework comparison demonstrating that AACP saving scales with framework coordination verbosity; a new framing for typed-result frameworks showing that AACP completes the determinism picture by adding typed instructions to complement existing typed results; and publication of five packages on PyPI and npm covering all four frameworks. |
| | UDP Speedy Transmission Protocol Secure (USTPS) |
| |
|
This document describes UDP Speedy Transmission Protocol Secure (USTPS), an experimental transport built directly on UDP for low- latency and loss-tolerant applications. USTPS provides authenticated encryption for DATA packets, readable plaintext control records authenticated by HMAC where applicable, binary UPACK DATA framing, selective retransmission, out-of-order acceptance, adaptive retransmission timeout, optional congestion control, 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. |
| | 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, including challenge-validated session setup, per-session key establishment, selective retransmission, and unordered transport behavior beneath the shell layer. |
| | MUX Status Frame: Two-Way Reachability Signalling without an Enumeration Oracle |
| |
|
This document defines the MUX Status Frame, a two-octet, relationship-scoped signal that lets a multiplexing routing layer tell a proven, related peer that a destination is unavailable - offline, not in session, superseded, or permanently revoked (tombstoned) - while disclosing nothing to the open network. It resolves the tension between two failure modes of a null-routing mux: silently dropping traffic to a dead peer (a false positive - the sender believes it landed) and answering honestly to everyone (an enumeration oracle mapping who is alive, dead, or revoked). Honest status travels only on a relationship-scoped trusted path; to the world, and to any merely authenticated but unrelated peer, the entire frame is zero. Status is derived from the canonical naming record and session liveness, not from a separate blocklist. The encoding is deterministic so independent implementations agree byte-for-byte. This protocol is transport-agnostic and complements JIS [JIS], AINS [AINS], TIBET [TIBET], and RVP [RVP]. |
| | TCP and UDP checksum calculations for ILNP |
| |
|
The Identifier Locator Network Protocol (ILNP) for IPv6 is described in Experimental RFCs 6740-6744. ILNP defines the use of an Identifier-Locator Vector (I-LV) with a zero value L64 value and a relevant Node Identifier (NID) value in place of an IPv6 address in the pseudo-header for transport protocol checksum computations. However, as TCP and UDP predate ILNP, this change causes TCP and UDP checksum values to be generated for ILNP flows that are different to the same flows on IPv6. This document changes the checksum computation for TCP and UDP with ILNP so that the checksum values are the same for ILNP and IPv6. This document updates the checksum processing for TCP and UDP described in RFC6740 and RFC6741, and the way the checksum processing should be applied for TCP and UDP in RFC6748. |
| | Analysis of Data Synchronization Problems in Multi-Agent Registry Centers |
| |
|
This document analyzes the data synchronization problems between multiple distributed Agent registry centers in IPv6 networks. When Agent networks span multiple organizational domains, geographic regions, or autonomous systems, each region's Agent registry center needs to synchronize Agent connection information and capability descriptions with others. This document presents a network-layer perspective on the main problems, challenges, and design considerations, providing a foundation for the development of subsequent solutions. |
| | A YANG Data Model for Network Attack Sample Metadata |
| |
|
Operational analysis, troubleshooting, validation of network defense functions, and exchange of collected traffic evidence rely on attack samples that are consistently described and can be processed across operators, vendors, and research tools. Today, such samples are often represented by proprietary labels, partial traffic captures, flow exports, log bundles, or local database schemas, which makes comparison, reproduction, and automated processing difficult. This document defines a YANG data model for network attack sample metadata. The model describes the sample identity, collection context, attack characteristics, data-content summary, anonymization status, and reproducibility information associated with packet, flow, session, log, or payload data. The model is intended to complement IPFIX, IODEF, PCAP/PCAPng-based operational data, and collected data manifests by defining metadata for the attack sample itself. |
| | ARD Binding for AGTP: Agentic Resource Discovery over the Agent Transfer Protocol |
| |
|
The Agentic Resource Discovery (ARD) specification defines a federated, domain-anchored model for cataloging, discovering, and searching agentic resources across organizational boundaries. ARD is artifact-protocol-agnostic: it advertises capabilities and trust metadata, then steps out of the way to let agents connect over each artifact's native protocol. This document specifies how the Agent Transfer Protocol (AGTP) composes with ARD. It defines an AGTP catalog entry type for ARD manifests, the agtp:// endpoint URI as a valid runtime connection target, the composition of AGTP's wire-level identity model with the ARD trustManifest object, and an AGTP-native binding for publishing and consuming ARD catalogs over the AGTP substrate rather than HTTPS. The result is a clean composition. ARD operates at the application layer and answers the discovery question: where is the capability, can it be trusted before connection. AGTP operates at the transport substrate beneath application-layer protocols (MCP, A2A, API, and others ARD catalogs) and carries structural identity, authority scope, and attribution at the wire. ARD and the application protocols it catalogs can run over AGTP as substrate, the same way they currently run over HTTP. |
| | Common Ancestor Objective Function and Parent Set DAG Metric Container Extension |
| |
| | draft-ietf-roll-nsa-extension-14.txt |
| | Date: |
17/06/2026 |
| | Authors: |
Remous-Aris Koutsiamanis, Georgios Papadopoulos, Nicolas Montavont, Pascal Thubert |
| | Working Group: |
Routing Over Low power and Lossy networks (roll) |
|
High reliability and low jitter can be achieved by being able to send data packets through multiple paths, via different parents, in a network. This document details how to exchange the necessary information within RPL control packets to let a node better select the different parents that will be used to forward a packet over different paths. This document also describes the Objective Function which takes advantage of this information to implement multi-path routing. |
| | Signed Prefix List (SPL) Based Route Origin Verification and Operational Considerations |
| |
|
The Signed Prefix List (SPL) is an RPKI object that attests to the complete list of prefixes which an Autonomous System (AS) may originate in the Border Gateway Protocol (BGP). This document specifies an SPL-based Route Origin Verification (SPL-ROV) methodology and combines it with the ROA-based ROV (ROA-ROV) to facilitate an integrated mitigation strategy for prefix hijacks and AS forgery. The document also explains the various BGP security threats that SPL can help address and provides operational considerations associated with SPL-ROV deployment. |
| | Tiebreaking Resource Public Key Infrastructure (RPKI) Trust Anchors |
| |
|
A Trust Anchor (TA) in the Resource Public Key Infrastructure (RPKI) is represented by a self-signed X.509 Certification Authority (CA) certificate. Over time, Relying Parties (RP) may have acquired multiple different issuances of valid TA certificates from the same TA operator. This document specifies a tiebreaking scheme to be used by RPs to select one TA certificate for certification path validation. This document updates RFC 8630. |
| |
|
| |
| | Delay-Tolerant Networking UDP Convergence Layer Protocol Version 2 |
| |
| | draft-ietf-dtn-udpcl-04.txt |
| | Date: |
15/06/2026 |
| | Authors: |
Brian Sipos, Joshua Deaton |
| | Working Group: |
Delay/Disruption Tolerant Networking (dtn) |
|
This document describes a UDP convergence layer (UDPCL) for Delay- Tolerant Networking (DTN). This version of the UDPCL protocol clarifies requirements of the earlier experimental RFC 7122, adds discussion of multicast addressing, congestion signaling, and updates to the Bundle Protocol (BP) contents, encodings, and convergence layer requirements in BP version 7. Specifically, the UDPCL uses CBOR-encoded BPv7 bundles as its service data unit being transported and provides an unacknowledged transport of such bundles. This version of UDPCL also includes security and extensibility mechanisms. |
| | Validation of Locations Around a Planned Change |
| |
|
This document defines an extension to the Location to Service Translation (LoST) protocol (RFC5222) that allows a LoST server to notify a client of planned changes to location data. This extension is only useful with the validation function of LoST. It is beneficial for LoST validation clients to be aware of planned changes, since at a known future date, previously valid records may become invalid, and new records may become valid. This extension adds an element to the request to allow a LoST client to request validation as of a specified date. It adds an optional Time-To-Live element to the response, which informs clients of the current expected lifetime of a validation. It also adds a separate interface to a LoST server that allows a client to poll for planned changes. Additionally, this document provides a conventional XML Schema for LoST, as a backwards compatible, non authoritative alternative to the RelaxNG schema in RFC5222. |
| | A YANG Data Model for BMP |
| |
| | draft-ietf-grow-bmp-yang-09.txt |
| | Date: |
15/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). |
| | CCNx Content Object Chunking |
| |
|
This document specifies a chunking protocol for dividing a user payload into CCNx Content Objects. It defines a name segment type to identify each sequential chunk number and a Content Object field to identify the last available chunk number. This includes specification for the naming convention to use for the chunked payload and a field added to a Content Object to represent the last chunk of an object. This document updates RFC8569 and RFC8609. |
| | IGP Flexible Algorithm with Link Packet Loss |
| |
|
This document proposes extensions to the IGP Flexible Algorithm. It introduces a mechanism to exclude links exceeding a specified packet loss rate threshold during path computation. The solution leverages existing link packet loss advertisement via IS-IS and OSPF, and defines new constraints for Flex-Algorithm path calculation. |
| | BGP Logical Link Discovery Protocol (LLDP) Peer Discovery |
| |
|
Link Layer Discovery Protocol (LLDP) or IEEE Std 802.1AB is implemented in networking equipment from many vendors. It is natural for IETF protocols to avail this protocol for simple discovery tasks. This document describes how BGP would use LLDP to discover directly connected and 2-hop peers when peering is based on loopback addresses. |
| | Attenuating Authorization Tokens for Agentic Delegation Chains |
| |
|
This document defines Attenuating Authorization Tokens (AATs), a signed credential format for task-scoped delegation in AI agent systems. An AAT encodes the tools an agent may invoke and the argument constraints that apply to those invocations. A token holder authorized to delegate can derive a token offline with equal or narrower authority, subject to the parent token's depth and lifetime limits. The resulting delegation chain is verifiable offline by any enforcement point that has the root issuer's trust anchor key. This specification profiles the OAuth Rich Authorization Requests format (RFC 9396) for tool-level capability claims, adds delegation- chain claims, and defines a core constraint vocabulary for argument restrictions. The chain verification algorithm authenticates each delegation step and enforces monotonic attenuation without network contact with the root issuer. |
| | Cryptographically Verifiable Actor Chains for OAuth 2.0 Token Exchange |
| |
|
Multi-hop service-to-service and agentic workflows often exchange OAuth access tokens across a sequence of actors. OAuth 2.0 Token Exchange permits an act claim, including nested prior actors, but it does not define interoperable rules for preserving, extending, disclosing, and validating a delegation path across successive exchanges. This document defines six actor-chain profiles for OAuth 2.0 Token Exchange: Declared Full Disclosure, Declared Subset Disclosure, Declared Actor-Only Disclosure, Verified Full Disclosure, Verified Subset Disclosure, and Verified Actor-Only Disclosure. The profiles preserve the existing meanings of sub, act, and may_act. They add explicit profile selection, a stable workflow actor-chain identifier, profile-controlled actor disclosure, and, for verified profiles, actor-signed step proofs with cumulative commitment state. |
| | An SVCB Service Parameter for Opportunistic Operator-led Transport Signaling (oots) |
| |
|
This document defines a new Service Parameter Key (SvcParamKey), "oots" ("Opportunistic Operator-led Transport Signal"), for use in Service Binding (SVCB) and HTTPS resource records as defined in RFC 9460. The "oots" parameter allows the operator of an authoritative DNS nameserver to advertise, per DNS transport protocol (such as DNS over UDP/TCP, DNS over TLS, DNS over HTTPS, and DNS over QUIC), the operator's own assessment of the share of the nameserver's total query load that it is confident it can serve over that transport. The per-transport values are independent capability estimates rather than a distribution of queries across transports; they are opportunistic hints that a resolver MAY use to inform transport selection and MAY ignore entirely. This document provides the specification required by Section 14.3.1 of RFC 9460 for registration of the "oots" SvcParamKey in the IANA "Service Parameter Keys (SvcParamKeys)" registry. |
| | The NTCF Network and Telemetry Compression Format |
| |
|
This document specifies NTCF (Network and Telemetry Compression Format), a self-describing, columnar, append-friendly binary container for cybersecurity and network telemetry such as flow records, honeypot events, and web access logs. Unlike general- purpose byte compressors, NTCF models the semantics of telemetry -- IP addresses, autonomous system numbers, ports, country codes, event types, and timestamps -- as typed columns and applies semantic encodings (dictionary, delta, delta-of-delta, run-length, frame-of- reference bit packing, and variable-length integers) before a conventional entropy compression stage. NTCF embeds per-column zone-map statistics and Bloom filters so that point lookups and analytical predicates can be evaluated by reading only the columns and segments that can possibly match, without decompressing the entire file. This document defines the on-disk octet layout (format version 1), the encoding catalogue, the reading and crash-recovery algorithms, a resource-limit model, security considerations, and an IANA media-type registration. |
| | OAuth SPIFFE Client Authentication |
| |
|
This specification profiles the Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants [RFC7521], the JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants [RFC7523], and OAuth 2.0 Attestation-Based Client Authentication [I-D.draft-ietf-oauth-attestation-based-client-auth] to enable the use of SPIFFE Verifiable Identity Documents (SVIDs) as client credentials in OAuth 2.0. It defines how OAuth clients with SPIFFE credentials can authenticate to OAuth authorization servers using their JWT-SVIDs, WIT-SVIDs, or X.509-SVIDs without the need for client secrets. This approach enhances security by enabling seamless integration between SPIFFE-enabled workloads and OAuth authorization servers while eliminating the need to distribute and manage shared secrets such as static client secrets. |
| |
|
| |
| | LISP Multicast Overlay Group to Underlay RLOC Mappings |
| |
|
This draft augments LISP [RFC9300] multicast functionality described in [I-D.farinacci-lisp-rfc6831bis] and [I-D.farinacci-lisp-rfc8378bis] to support the mapping of overlay group addresses to underlay RLOC addresses. This draft defines a many-to-1, 1-to-many, and many-to-many relationship between multicast EIDs and the Replication List Entries (RLEs) RLOC records they map to. The mechanisms in this draft allow a multicast LISP overlay to run over a mixed underlay of unicast and/or multicast packet forwarding functionality. |
| | COSE Receipts for MMRs |
| |
|
This document defines a new verifiable data structure type for COSE Receipts [I-D.ietf-cose-merkle-tree-proofs] specifically for use with ledgers based on post-order traversal binary Merkle trees and which are designed for high throughput, ease of replication and compatibility with commodity cloud storage. Post-order traversal binary Merkle trees, also known as history trees, are more commonly known as Merkle Mountain Ranges. |
| | Unified Transition Overlay (UTO): A Stateless Cross-Version Transition Mechanism for IPv4/IPv6 |
| |
|
This document specifies Unified Transition Overlay (UTO), a stateless encapsulation-plus-translation mechanism that enables bidirectional communication between IPv4-only and IPv6-only hosts across a transit network whose forwarding plane uses the opposite IP version. UTO carries the native source and destination addresses of the communicating hosts in a compact, variable-length overlay header. The original packet is tunneled between UTO-Gateways (UGWs) across the transit network and is converted to the destination's address family by a single stateless header translation performed only at the egress UGW. UTO requires no DNS64, no stateful per-flow translation in the common IPv4-to-IPv6 direction, and no changes to backbone routers or end-host stacks. The transit network forwards only pure IPv4 or pure IPv6 packets. |
| | 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-04) defines the web API and bot service profile; the APIX IoT Device Profile (draft-rehfeld-apix-iot-04) 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. |
| | Memory Interchange Bundle Format for AI Agents |
| |
|
This document specifies a vendor-neutral interchange format for the persistent memory of AI agents — preferences, decisions, identity claims, pitfalls, and procedures that an agent accumulates across sessions. The format is a self-contained JSON Bundle with explicit conformance levels (Producer, Consumer, Bidirectional). Implementations MAY accompany the Bundle with an HTTP Profile that exposes export and import endpoints. The goal is to allow a user's "agent brain" to move between cloud services, on-premise installations, and third-party implementations without lock-in, in a manner that interoperates with existing right- to-erasure obligations such as [GDPR-A17]. This document is self-contained: all schema fields normatively required by Producers and Consumers are defined inline. An informative reference implementation is cited in [AIMEM-REF]. |
| | APIX Quality Attestation Extension: Verifiable Product,Process,and Organisation Quality Claims for Discovered Services |
| |
|
The APIX Core ([APIX-CORE]) defines a three-dimensional trust model — Organisation Trust Level (O), Service Verification Level (S), and Liveness — that lets a consuming agent decide whether a discovered service is operated by a verified party, is technically reachable and consistent, and is currently alive. These dimensions do not describe the _quality_ of what a service produces. They cannot answer whether a manufacturing process is GMP-certified, whether a product carries an independent quality grade, or whether an organisation holds a domain quality certification, nor who attested any of these and with what strength. This document defines the APIX Quality Attestation Extension: a cross-cutting extension, docking via the structured extensions container of the APM ([APIX-CORE] Section 7.1), that records third- party and self-declared quality claims about a discovered service's Organisation, Process, or Product, each carried with an explicit assurance level, attestation provenance, validity state, and liability regime. The extension reuses and extends the Core Verification Basis Registry for provenance and mirrors the Core capability-taxonomy governance for its criterion vocabulary. It is the mechanism by which measurable quality enters the agentic purchase decision without re-introducing the central-arbiter and race-to-the- bottom failure modes the Core is designed to prevent. |
| | Precise Priority-based Flow Control with Gateway |
| |
|
This document proposes Precise Priority-based Flow Control (PPFC) mechanism implemented at the network gateway, it designed to efficiently manage congestion in scenarios where multiple flows converge toward a common destination. By enabling fast, per-flow congestion control at the network gateway, PPFC allows incoming traffic destined for a congested bottleneck to be paused or rate- limited before entering the network. This approach decouples the congestion feedback loop from the end-to-end data path, significantly reducing reaction time and improving the effectiveness of congestion management. |
| | Precise Priority-based Flow Control Notification with RoCEv2 |
| |
|
This document defines a format for Precise Priority-based Flow Control (PPFC) notifications within RoCEv2 (RDMA over Converged Ethernet version 2) networks. The proposed format enables network devices experiencing congestion to generate explicit congestion signals that can be efficiently carried back to the source clients. This facilitates fast, fine-grained flow control, complementing traditional end-to-end congestion control and improving performance in high-throughput, low-latency environments. |
| | SSH Certificate Format |
| |
|
This document presents a lightweight certificate format that may be used in the context of the Secure Shell (SSH) protocol for user and host authentication. |
| |
|
| |
| | Scalable Quality Extension for the Opus Codec (Opus HD) |
| |
|
This document updates [RFC6716] to add support for a scalable quality layer. |
| | remoteStorage 1.0 |
| |
|
This draft describes a protocol by which client-side applications, running inside a web browser, can communicate with a data storage server that is hosted on a different domain name. This way, the provider of a web application need not also play the role of data storage provider. The protocol supports storing, retrieving, and removing individual documents, as well as listing the contents of an individual folder, and access control is based on bearer tokens. |
| | Metadata Query Protocol |
| |
|
This document defines a simple protocol for retrieving metadata about named entities, or named collections of entities. The goal of the protocol is to profile various aspects of HTTP to allow requesters to rely on certain, rigorously defined, behaviour. This document is a product of the Research and Education Federations (REFEDS) Working Group process. |
| | SAML Profile for the Metadata Query Protocol |
| |
|
This document profiles the Metadata Query Protocol for use with SAML metadata. This document is a product of the Research and Education Federations (REFEDS) Working Group process. Editorial Note (To be removed by RFC Editor before publication) Discussion of this draft takes place on the MDX project issue tracker, which is accessed from [MDX.issues]. XML versions, latest edits and the issues list for this document are available from [md-query]. The changes in this draft are summarized in Appendix A.26. |
| | Cisco's CoAP Simple Management Protocol |
| |
|
CoAP Simple Management Protocol (CSMP) is purpose-built to provide lifecycle management for resource constrained IoT devices deployed within large-scale, bandwidth constrained IoT networks. CSMP offers an efficient transport and message encoding supporting classic NMS functions such as device on-boarding, device configuration, device status reporting, securing the network, etc. This document describes the design and operation of CSMP. This document does not represent an IETF consensus. |
| | WBA OpenRoaming Wireless Federation |
| |
| | draft-tomas-openroaming-08.txt |
| | Date: |
12/06/2026 |
| | Authors: |
Bruno Tomas, Mark Grayson, Necati Canpolat, Betty Cockrell, Sri Gundavelli, Seb Adamski |
| | Working Group: |
Individual Submissions (none) |
|
This document describes the Wireless Broadband Alliance's OpenRoaming system. The OpenRoaming architecture enables a seamless onboarding experience for devices connecting to access networks that are part of the federation of access networks and identity providers. The primary objective of this document is to describe the protocols that form the foundation for this architecture, enabling providers to correctly configure their equipment to support interoperable OpenRoaming signalling exchanges. In addition, the topic of OpenRoaming has been raised in different IETF working groups, and therefore a secondary objective is to assist those discussions by describing the federation organization and framework. |
| | Signaling Zone Owner Intent |
| |
|
This document introduces a standardized mechanism for zone owners to signal their intent regarding DNS provider responsibilities through DNS itself. It defines two new DNS RRtypes -- HSYNC (Horizontal Synchronization, per-provider enrollment) and HSYNCPARAM (zone-wide multi-provider policy) -- that together enable zone owners to designate which Providers are authorized to serve and/or sign their zones, control whether Providers or the zone owner manages the NS RRset, and specify zone transfer chain configurations. The HSYNC and HSYNCPARAM records allow DNS Providers to discover each other and establish secure communication, either using the JOSE framework over DNS or via a RESTful API secured by TLS. This provider-to-provider communication enables automated coordination for tasks such as NS RRset management and DNSSEC-related operations. The document describes how the Providers discover one another, establish secure communication, and maintain it with periodic keep-alives; this specification covers those discovery and communication-establishment aspects, while the on-the-wire framing of the messages the Providers exchange is defined in a companion document. While a distributed DNSSEC multi-signer architecture (similar to "model 2" in [RFC8901]) is an important application of this framework, the HSYNC-based signaling supports broader provider synchronization needs. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-leon-dnsop-signaling-zone-owner- intent (https://github.com/johanix/draft-leon-dnsop-signaling-zone- owner-intent). The most recent working version of the document, open issues, etc, should all be available there. The authors (gratefully) accept pull requests. |
| | 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. |
| | The MyClerk Virtual File System: Distributed Storage for Family Networks |
| |
|
This document specifies the MyClerk Virtual File System (VFS), a distributed storage system designed for family networks. The VFS provides end-to-end encrypted, redundant storage across heterogeneous nodes using adaptive chunking and Reed-Solomon erasure coding [REED-SOLOMON]. Metadata synchronization uses Conflict-free Replicated Data Types (CRDTs) [CRDT] with a hybrid LWW-Register and OR-Set approach. The system supports tiered storage, automatic health monitoring with self-healing capabilities, and federation between separate family installations. It is designed to be accessible to non-technical users while providing enterprise-grade data durability. |
| | 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. |
| | Gap Analysis and Applicability Statement for Discovery Protocols of Agents,Workloads,and Named Entities (DAWN) |
| |
|
This Internet-Draft provides a gap analysis and applicability statement that maps existing Discovery Mechanisms and protocols to the DAWN problem statement and discovery requirements. The analysis evaluates security, privacy, applicability, flexibility, and suitability of existing standardized, non-standardized, and proposed discovery solutions and protocols to the DAWN problem statement and REQ-DISC corpus. It identifies high priority gaps, proposes mitigations and hybrid patterns, and serves as reference for future prototyping and development. The intention is for this draft to evolve as new solutions come to existence. |
| | Rego Policy Language for OAuth 2.0 Authorization |
| |
|
AI agents exhibit dynamic, unpredictable behavior that cannot be fully described by traditional OAuth 2.0 scopes. This specification defines a behavioral authorization framework that enables clients, particularly AI agents, to propose Rego policy-based behavioral constraint contracts in OAuth 2.0 authorization flows using Rich Authorization Requests (RAR). It defines the rego_policy authorization data type for carrying behavioral constraint contracts in authorization_details, shifting the authorization model from static permission sets to runtime behavioral verification. It also defines a reverse-guided authorization mechanism allowing resource servers to return structured policy constraints in error responses, enabling agents to dynamically adapt their behavior and construct appropriate authorization requests. |
| | Precise Priority-based Flow Control Notification |
| |
|
This document specifies the notification mechanism for Precise Priority-based Flow Control (PPFC), defining the message formats and network actions for communicating congestion information among network nodes. The PPFC notification enables rapid congestion signaling, allowing per-flow flow control for traffic from source. |
| | Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties |
| |
|
This document provides a single reference point for requirements for Relying Party (RP) software for use in the Resource Public Key Infrastructure (RPKI). It cites requirements that appear in several RPKI RFCs and related specifications, making it easier for implementers to become aware of these requirements. This document updates [RFC8897] to reflect changes to the requirements and guidance specified in the relevant RPKI standards, including updates to repository synchronization, certificate and CRL processing, signed object validation, validated cache distribution, local control, and operational and manageability support for RP software. This document is expected to be updated to reflect changes to the requirements and guidance specified in the RFCs discussed herein. |
| | Experimental and Private-Use Ranges in the DNSSEC Algorithm Numbers Registry |
| |
|
The DNSSEC Algorithm Numbers registry contains two code points, 253 (PRIVATEDNS) and 254 (PRIVATEOID), intended for private and experimental algorithms. These code points identify the algorithm by prepending a domain name or an object identifier to the "Public Key" field of the DNSKEY RDATA, overloading the semantics of that field and forcing every implementation to special-case algorithm dispatch. Because all such algorithms share a single code point, they cannot be distinguished on the wire by the algorithm number alone. This document reserves two small ranges of DNSSEC algorithm numbers: one for Private Use, requiring no IANA registration, and one for experimental algorithms, registered on a First Come First Served basis. Code points drawn from these ranges behave identically to ordinary algorithm numbers and require no overloading of the DNSKEY RDATA. This enables clean experimentation with the growing set of post-quantum and other candidate signature algorithms. This document updates RFC 6014 and RFC 9157. |
| | sRPC: Solenoid Action-Oriented RPC and the HTTP RUN Method |
| |
|
This document defines the Solenoid Remote Procedure Call (sRPC) protocol and requests registration of a new HTTP method, RUN. sRPC is action-oriented. A client targets a stable endpoint URI and identifies the procedure to execute through a query parameter containing a procedure path. The RUN method provides explicit protocol semantics for function invocation, distinguishing RPC execution from resource-oriented REST interactions. |
| | AFiR: Post-Quantum Signed Inference Receipts as a TEE-Free Profile for IETF SPICE Inference Chain |
| |
|
This document defines AFiR (Attested Fragmented Inference Routing) as a production profile of the IETF SPICE Inference Chain specification [I-D.draft-mw-spice-inference-chain]. The SPICE Inference Chain defines computational provenance via two mechanisms: Zero-Knowledge Machine Learning (ZKML) proofs and Trusted Execution Environment (TEE) attestation quotes. Both require either significant proof generation latency (ZKML) or specialized hardware (TEE). Neither is deployable today in commodity serverless inference environments without infrastructure changes. AFiR defines a third proof type -- post-quantum digital signature attestation using ML-DSA-65 (NIST FIPS 204) -- that is deployable on any inference platform, requires no specialized hardware, adds 0.785ms of overhead per fragment, and produces a 384-byte receipt anchored on a public blockchain. AFiR receipts are structurally compatible with the SPICE Inference Chain Merkle tree and can coexist with ZKML and TEE entries in the same session chain. AFiR extends the SPICE inference chain with five concrete production primitives: Signed Tool Calls (P1), Cross-Agent Receipt Trees (P2), KV Cache Signing (P3), Model Manifest attestation (P4), and a Crypto- Agile Signature Layer (P5). All five are deployed and serving production traffic as of June 2026, making AFiR the first production implementation of the SPICE inference_root claim for multi-agent pipelines. |
| | AGENTS.TXT: Capability Declarations for Web Agents |
| |
|
This document requests registration of two Well-Known URIs under the "/.well-known/" path: "agents.txt" and "agents.json". These URIs define a machine-readable capability declaration format: a positive statement of what web agents CAN do on a site -- which endpoints are sanctioned for agent use, which protocols (REST, MCP, A2A, GraphQL, WebSocket) are supported, what authentication mechanisms are expected, and what rate limits the site advertises. This is distinct from "robots.txt", which uses a restriction syntax to declare what crawlers may not do. Where "robots.txt" expresses prohibition, "agents.txt" expresses capability -- a sanctioned channel for agent interaction that is otherwise routinely blocked by bot detection, CAPTCHAs, and rate limiters because no positive declaration surface exists. |
| | AI.TXT: A Declaration File for AI Usage Preferences,Licensing,and Policy |
| |
|
This document requests registration of two Well-Known URIs under the "/.well-known/" path: "ai.txt" and "ai.json". These URIs define a structured, machine-readable file in which a site operator can declare AI usage preferences (training, scraping, indexing, caching), licensing terms, required attribution, and per-agent rules. "ai.txt" is positioned as a structured attachment surface for AI usage preferences in addition to robots.txt and HTTP-header carriage proposed by the IETF AIPREF working group. As the AIPREF vocabulary stabilizes, "ai.txt" can carry those preferences in a typed, single- file form alongside the broader licensing, attribution, and policy declarations defined in this document. This format is complementary to "robots.txt" [ROBOTS]. Where "robots.txt" can block crawling entirely, "ai.txt" expresses nuanced policies such as "you may crawl but not train on this content" -- a distinction that "robots.txt" alone cannot express. |
| | RER Run Artifact Format: Hash-Chained,Signed Records of AI Inference Execution |
| |
|
This document specifies the Run Envelope Runtime (RER) artifact format: a hash-chained, Ed25519-signed JSON record of a single AI inference run. An RER artifact carries (1) a signed envelope declaring the permissions and limits under which the run was authorized, (2) a hash-chained event log covering every model call, tool call, and policy decision made during execution, and (3) a runtime signature binding the envelope hash and event log head to the runtime implementation that produced the record. The artifact is designed for offline verification by parties who did not participate in the run. A separate verifier package, with a minimal dependency surface (canonicalization, SHA-256, Ed25519, JSON schema validation), can establish the artifact's structural and cryptographic integrity without any of the code that produced it. After sealing, the integrity of the record does not depend on trust in the operator. This document complements the declaration-side agents.txt and ai.txt well-known URI proposals (both filed, under review at the IANA Well- Known URIs registry). Declaration says what an agent was permitted to do. An RER artifact records what the runtime attested actually happened. The two surfaces together cover the before-and-after of an agent interaction. Two on-the-wire schema versions are defined here: rer-artifact/0.1 and rer-artifact/0.2. Version 0.2 adds a bundle format, manifest binding, and approval-protocol metadata while preserving the verification semantics of 0.1. |
| | PCEP Extensions for Path Delay Difference |
| |
|
In certain scenarios, such as load balancing, P2MP and DetNet, it is required that the delay difference among a set of paths to be controled within an expected range. This document describes extensions to PCEP to use the delay difference as a constraint for end-to-end path computation. |
| | Registration Data Access Protocol (RDAP) Extension for Resource Public Key Infrastructure (RPKI) Registration Data |
| |
|
The Resource Public Key Infrastructure (RPKI) is used to secure inter-domain routing on the internet. This document defines a new Registration Data Access Protocol (RDAP) extension with identifier "rpki1", for accessing the RPKI registration data in the Internet Number Registry System (INRS) for the Route Origin Authorization (ROA), Autonomous System Provider Authorization (ASPA), and X.509 Resource Certificate RPKI profiles through RDAP. The INRS is composed of Regional Internet Registries (RIRs), National Internet Registries (NIRs), and Local Internet Registries (LIRs). |
| | Common YANG Data Types for Traffic Engineering |
| |
| | draft-ietf-teas-rfc8776-update-24.txt |
| | Date: |
12/06/2026 |
| | Authors: |
Italo Busi, Aihua Guo, Xufeng Liu, Tarek Saad, Igor Bryskin |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
This document defines a collection of commonly used Traffic Engineering (TE) specific data types, identities, and groupings in YANG data modeling language. These derived common data types, identities, and groupings are intended to be imported by other modules that model configuration and state for TE constructs, such as TE Topologies, TE Tunnels, TE Policies, TE Paths, TE Label Switched Paths (LSPs), and TE interfaces. This document obsoletes RFC 8776. |
| |
|
| |
| | Carrying Network Resource (NR) related Information in IPv6 Extension Headers |
| |
|
Virtual Private Networks (VPNs) provide different customers with logically separated connectivity over a common network infrastructure. With the introduction of 5G and also in some existing network scenarios, some customers may require network connectivity services with features that are more advanced compared to conventional VPN services. Such kind of network service is called enhanced VPNs. Enhanced VPNs can be used, for example, to deliver network slice services. A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP may be used as the underlay to support one or a group of enhanced VPN services. For packet forwarding within a specific NRP, some fields in the data packet (these fields are called the NRP Selector) are used to identify the NRP to which the packet belongs. By identifying a packet with an NRP, NRP-specific processing can be performed on each node along the forwarding path in the NRP. This document specifies a new IPv6 Hop-by-Hop option to carry Network Resource related information in data packets. The new option is called the Network Resource (NR) Option. It can be used to carry an identifier of the NRP Selector, but it is designed to also be able to carry general information about network resource semantics and functions. |
| | BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs |
| |
|
RFC 6514 describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGP IP VPNs, as specified in RFC 6513. This document updates and obsoletes RFC 6514. The original authors of RFC 6514 are listed at the end of this document. |
| | Agentic Interface to In-Network Computing Functions for Software-Defined Vehicles in Cooperative Intelligent Transportation Systems |
| |
| | draft-an-nmrg-i2icf-cits-02.txt |
| | Date: |
10/06/2026 |
| | Authors: |
Byoungman An, Jaehoon Jeong, Pusik Park, Soohyun Jang |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies a structured framework for orchestrating, managing, and monitoring In-Network Computing Functions (ICFs) for Software-Defined Vehicles (SDVs) in Cooperative Intelligent Transportation Systems (C-ITS), with a first-class role given to the Agent-to-Agent (A2A) communication paradigm. SDVs decouple vehicular functions from underlying hardware and expose them as software- driven, continuously updatable services; this architectural shift makes them natural participants in an agentic control plane that spans vehicles, roadside infrastructure, and mobile networks. AI agents are co-located with each functional entity of the C-ITS architecture (e.g., C-ITS Center, Government Public Center, C-ITS Infra, Mobile Network Operator (MNO), Roadside Unit (RSU), SDV, and Vulnerable Road User (VRU)) and interact over an A2A protocol overlay to advertise capabilities, discover peers, negotiate resources, and coordinate the placement and execution of ICFs across multi-domain networks. In the context of Vehicle-to-Everything (V2X) communications, this agentic overlay enables efficient management of Vehicle-to-Vehicle (V2V) and Vehicle-to-Infrastructure (V2I) communications and their integration with C-ITS by leveraging in- network computing to optimize real-time communication, streamline traffic management, and enhance data processing and security services at the network edge. The framework aligns with ongoing IRTF NMRG work on agentic AI and A2A applicability to network management, and adapts these concepts to the specific operational and safety requirements of SDV-centric C-ITS deployments. |
| | 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 dedicated access layer analogous to the role that DNS, HTTP, and the Web played for human information exchange. The document clarifies the relationship between AIIP and existing Internet protocols, describes the architectural position of AIIP as a native access layer rather than a profile of HTTP, and provides 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. |
| | Fully Adaptive Routing Ethernet in Multi-Plane Scale-Out Networks |
| |
| | draft-xu-rtgwg-fare-in-mp-son-00.txt |
| | Date: |
10/06/2026 |
| | Authors: |
Xiaohu Xu, Zongying He, Nan Wang, Wei Wan, Hua Wang, Jian Guo, Xiang Li, Tianyou Zhou, Yongtao Yang, Yinben Xia, Weifeng Zhang, Peilong Wang, Yan Zhuang, Fajie Yang, Chao Li, Xiaojun Wang, Roman Glebov |
| | Working Group: |
Individual Submissions (none) |
|
FARE-BGP enables weighted ECMP load balancing using a path-bandwidth extended community. FARE-in-SUN extends this mechanism from switches to GPUs for scale-up networks, which are typically multi-plane. Large AI training clusters increasingly adopt multi-plane scale-out network topologies. This document further extends FARE-BGP from switches to RoCE NICs (RNICs) for such multi-plane scale-out networks. The document also presents two techniques to address route scalability concerns caused by the injection of numerous host routes. |
| | Sources of Inter-Agent Conflicts and Approaches to Conflict Resolution in Network Management |
| |
|
Network management is increasingly carried out by autonomous, AI- driven agents that observe and act on the network and service state they share. Where their scopes overlap - the same managed entities, resources, or objectives - their independent decisions can prove mutually inconsistent, and such inter-agent conflict is, at bottom, coordination that has not been put in place; the two are best studied together. This document maps the problem for network management: where inter-agent conflict comes from, which families of mechanism resolve it, and how those mechanisms are chosen and combined. It then turns that map on a case of current interest in the IETF - the AI-based Network Management Agent (NMA) architecture - and offers six recommendations for strengthening how that architecture handles inter-agent conflict at its Agent-to-Agent interface. |
| | Dynamic Network-as-a-Service Life-Cycle Automation Using End-to-End Agent Negotiation |
| |
|
This document describes a possible direction for the management of Network-as-a-Service (NaaS), in which the relationship between a service consumer and a provider is treated not as a static contract but as a continuous, automated negotiation conducted on both sides by cognitive software agents. A NaaS whose required bandwidth, latency and availability move continuously cannot be settled once at order time; it is a standing dialogue - intent, quote, agreement and in- life change - that today stops at the customer-operator boundary and is bridged by humans. The document frames that boundary as the unautomated gap, sketches an end-to-end agentic negotiation architecture that closes it, and describes the intent instance as a managed object whose life cycle includes scarcity-driven pricing and closed-loop renegotiation. It maps the architecture onto already- published specifications from several bodies, showing that the direction rests on a standards basis rather than on new protocol invention. Two NaaS settings illustrate its utility. |
| | AIID: An Identifier Namespace for Autonomous Systems |
| |
|
Autonomous systems operate today without stable, globally unique identities. When an AI agent executes an action, there is no universally recognized identifier for that agent, no delegation record, and no accountability chain back to a human principal. This document defines the Autonomous System Identifier (AIID) namespace. An AIID is a structured, hierarchical identifier assigned to an autonomous system, execution environment, or agent operating within the Artificial Intelligence Internet Protocol (AIIP) architecture [I-D.sogomonian-aiip-architecture]. This document specifies the AIID syntax, hierarchical structure, registration model, operational states including safe mode, and revocation mechanisms. The governance model for the namespace, including selection of a root registry operator, is explicitly left open for community determination. |
| | Offline Emergency Peer-to-Peer Broadcast Protocol |
| |
|
This document specifies the Offline Emergency Peer-to-Peer Broadcast Protocol (OEPB). OEPB is a transport-agnostic overlay protocol for distributing authenticated emergency alerts over short-range peer-to- peer radios in infrastructure-absent environments. Its principal contributions are: (1) a Transport Abstraction Layer (TAL) that presents heterogeneous radio technologies (BLE, Wi-Fi Direct, LoRa, IEEE 802.15.4) as a uniform 256-byte datagram interface to upper layers; (2) application of the Trickle algorithm (RFC 6206) to content-dissemination suppression in a multi-class broadcast context, distinct from its original routing-consistency application in RPL/6LoWPAN; (3) an emergency-semantic five-class Weighted Fair Queuing taxonomy calibrated to disaster-triage urgency; and (4) a trust architecture that deliberately separates relay forwarding from signature verification, preserving life-safety reachability for unauthenticated SOS messages. To the authors' knowledge, no prior open specification addresses authenticated, amplification-resistant emergency broadcast in a transport-agnostic manner across heterogeneous short-range radios; Section 1.1 surveys prior systems and standards. A companion document defines the Transport Binding Profile for Bluetooth Low Energy. |
| | OEPB Transport Binding: Bluetooth Low Energy |
| |
|
This document defines the Bluetooth Low Energy (BLE) Transport Binding Profile for the Offline Emergency Peer-to-Peer Broadcast Protocol (OEPB). It specifies the advertising mode, fragmentation and reassembly scheme, service and characteristic UUIDs, and channel access rules required to carry OEPB packets over BLE 4.x and BLE 5.x physical layers. |
| | OCSP Usage for Secure Telephone Identity Certificates |
| |
|
When certificates are used as credentials to attest the assignment or ownership of telephone numbers, some mechanism is required to convey certificate freshness to relying parties. Certificate Revocation Lists (CRLs) are commonly used for this purpose, but for certain classes of certificates, including delegate certificates conveying their scope of authority by-reference in Secure Telephone Identity Revisited (STIR) systems, they may not be aligned with the needs of relying parties. This document specifies the use of the Online Certificate Status Protocol (OCSP) as a means of retrieving real-time status information about such certificates, defining new extensions to compensate for the dynamism of telephone number assignments. |
| | 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. |
| |
|
| |
| | 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. |
| | 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. |
| | Agent Identity Protocol (AIP): Decentralized Identity and Delegation for AI Agents |
| |
|
The Agent Identity Protocol (AIP) defines a decentralized identity, delegation, and authorization framework for autonomous AI agents. AIP combines W3C Decentralized Identifiers (DIDs), capability-based authorization, cryptographic delegation chains, and deterministic validation to enable secure, auditable multi-agent workflows without relying on centralized identity providers. |
| | 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. |
| | 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. |
| | Portable Web Content Format (PortableWeb): Container and Manifest Specification |
| |
|
This document defines the Portable Web Content Format (PortableWeb), 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. |
| | 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. |
| |
|
| |
| | 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. |
| | 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. |
| | 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). |
| | 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. |
| |
|
| |
| | 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. |
| | 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. |
| | 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. |
| | RESTful Provisioning Protocol (RPP) - Requirements |
| |
|
This document describes the requirements for the development of the RESTful Provisioning Protocol (RPP). |
| |
|
| |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| |
|
| |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| |
|
| |
| | 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. |
| | 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]. |
| | 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 [email protected] mailing list. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| |
|
| |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| |
|
| |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |