| |
|
| |
| | IPv6 is Classless |
| |
|
Over the history of IPv6, various classful address models have been proposed, none of which has withstood the test of time. The last remnant of IPv6 classful addressing is a rigid network interface identifier boundary at /64. This document removes the fixed position of that boundary for interface addressing. |
| | Static Context Header Compression and Fragmentation ARQ/FEC mode |
| |
|
This document defines a new fragmentation mode for the SCHC standard defined in RFC8724. The new fragmentation mode is designed for communications that require additional reliability mechanisms. The reliability is based on a hybrid ARQ/FEC type II mechanism that combines forward error correction (FEC) with adaptive retransmissions to achieve high reliability. |
| | Export of Multiple Encapsulation Layer Information in IPFIX |
| |
|
This document analyzes the requirements and problems when monitoring flows with multi-layer network encapsulations. This document aims to solve this problem by updating RFC7011 and introducing new IPFIX IEs for encapsulation layer indication. |
| | Export of IGP Algorithm Information in IPFIX |
| |
|
This document introduces a new IPFIX information element (IE) to identify the IGP algorithm information related with the Segment Identifier (SID) or the IPv4/IPv6 prefix. |
| | Classification of IPv6-Only Networks by Levels |
| |
|
IPv6-only networking is recognized as the ultimate goal of network evolution. However, in practice, the understanding and implementation of IPv6-only varies significantly. To address ambiguity and improve communication, this document proposes a classification for IPv6-only networks. It defines three distinct levels, from a pure state with no IPv4 support to scenarios where IPv6-only and dual-stack coexistence exists. This approach of classification is applicable to all network scenarios and aids operators and protocol designers in precisely specifying the nature of their IPv6-only deployments. |
| | AV-AI.R: A.V.AN Vectorized Artificial Intelligence Routing -- Eco-Responsible Transmission of IP Packets between AI Agents via Carriers Augmented by Artificial Intelligence |
| |
|
This memo amends RFC 2549 "IP over Avian Carriers with Quality of Service" by introducing an eco-responsible inter-AI communication channel based on carriers whose cognitive capabilities have been augmented by embedded language models (edge-LLM). AV-AI.R defines the communication protocol between artificial intelligence agents via carriers equipped with miniaturized transformer neurons, offering a low-carbon-footprint alternative to conventional data centers. This protocol is not recommended for production use, except in the event of fiber outage or major ecological crisis. This memo is an experimental protocol document submitted as an Independent Submission in the tradition of RFC 1149 and RFC 2549. |
| | Attestation of Hardware Components |
| |
|
Hardware components constitute the foundation of all computations and therefore play a critical role in system integrity and reliability. Existing attestation mechanisms primarily rely on manufacturer endorsements, which provide limited visibility into the runtime behavior of hardware. This document extends the Remote ATtestation procedureS (RATS) architecture by defining a data model and guidelines for including measurements of hardware components in attestation Evidence. These measurements may represent physical properties, results of self-tests, or behavioral observations. The document considers a threat model that includes both adversarial actions and physical phenomena such as environmental variations and aging. It proposes abstract interfaces for collecting measurements, enabling interoperability while remaining agnostic to implementation mechanisms, and outlines a security model for their use in appraisal. |
| | WATCH: A Proposed HTTP Method for Event-Driven Subscriptions |
| |
|
This document proposes the addition of a WATCH method to the Hypertext Transfer Protocol (HTTP). The WATCH method enables a client to subscribe to change notifications on a specified resource, shifting the communication model from client-initiated polling to server-initiated event delivery. The proposal includes two companion mechanisms: ALIVE, a client- initiated heartbeat protocol that maintains subscription validity and restores economic symmetry between client and server; and UNWATCH, a clean subscription termination method. Together, these introduce an event-driven subscription layer into HTTP while preserving the protocol's existing simplicity and extensibility. This document incorporates formal terminology, a setup phase with confirmation handshake, refined jurisdictional compliance guidance, implementation recommendations, and protocol flow diagrams for all defined interaction patterns. |
| | Representation of Intricate Communications |
| |
|
Complex inter-party communication or relationship dynamics can be implied within the use of more structured protocols. This document proposes a compact binary representation for describing these dynamics in a non-protocol-binding manner that can be readily converted back to a readable format and provide additional context for implementers. |
| | Jason Transfer Protocol (JTP) |
| |
|
This document specifies the Jason Transfer Protocol (JTP), a compact binary protocol for listing and transferring images over a reliable ordered byte stream. JTP is designed to be simple to implement and efficient to parse. Images are addressed by a content-derived 64-bit identifier computed using xxHash64. The protocol supports catalog enumeration, point retrieval by identifier, delta synchronization, and connection reuse via a keep-alive mechanism. Transport security may be provided by TLS with an ALPN protocol identifier of "jtp/1". This document specifies the on-wire format of JTP version 1. It does not specify any particular implementation. |
| | The Prove-Transform-Verify (PTV) Protocol for Attested Agent Identity |
| |
|
This document specifies the Prove-Transform-Verify (PTV) protocol for hardware-anchored, zero-knowledge attested agent identity in federated environments. PTV addresses the data gravity problem in centralized security models by enabling cross-domain agent authorization without raw data exposure. The specification includes: TPM 2.0/secure enclave roots of trust; Groth16 zero-knowledge proofs (<200ms generation on commodity edge hardware); HotStuff Byzantine Fault Tolerant consensus for immutable audit trails; and Sovereign Bound metadata for jurisdiction-aware attestation chains. Use cases include healthcare clinical decision support systems (CDSS), critical infrastructure industrial control systems (ICS/OT), and cross-border regulatory compliance scenarios under GDPR/HIPAA frameworks. |
| |
|
| |
| | Just because it's an Internet-Draft doesn't mean anything... at all... |
| |
|
Anyone can publish an Internet Draft (ID). This doesn't mean that the "IETF thinks" or that "the IETF is planning..." or anything similar. |
| | Compact Routing Header (CRH) Helper Option |
| |
|
This document introduces a new IPv6 Destination Option called the CRH Helper. The CRH Helper is used with the Compact Routing Header (CRH) [RFC 9631]. It contains information required to convert a CRH SID to the IPv6 address of a interface on a packet's delivery path. Because the CRH Helper contains this information, it eliminates the need for a CRH-FIB. It also eliminates the need for CRH-FIB support in the control plane. The CRH helper is useful in underlay networks, where all interfaces are numbered from a few /112 or /96 prefixes. |
| | Latency Guarantee with Stateless Fair Queuing |
| |
|
This document specifies the implementation details for the framework specified in ITU-T Y.3129 [Y.3129] and ITU-T Y.3148 [Y.3148]. The framework guarantees end-to-end (E2E) latency bounds to flows. The schedulers in core nodes do not need to maintain flow states. Instead, the entrance node of a flow marks an ideal service completion time according to a fluid model, called Finish Time (FT), of a packet in the packet header. The subsequent core nodes update the FT by adding a delay factor, which is a function of the flow and the nodes. The packets in the queue of the scheduler are served in the ascending order of FT. This mechanism is called the stateless fair queuing. The result is that flows are isolated from each other almost perfectly. The latency bound of a flow depends only on the flow's intrinsic parameters such as the maximum burst size and the service rate, except the link capacities and the maximum packet length among other flows sharing each output link with the flow. This document specifies the metadata, formats of metadata, the admission control procedure, and an approximation of stateless fair queuing implemented via a strict priority (SP) scheduler. |
| | Stateless Hash-Based Signatures in Merkle Tree Ladder Mode (SLH-DSA-MTL) for DNSSEC |
| |
|
This document describes how to apply the Stateless Hash-Based Digital Signature Algorithm in Merkle Tree Ladder mode to the DNS Security Extensions. This combination is referred to as the SLH-DSA-MTL Signature scheme. This document describes how to specify SLH-DSA-MTL keys and signatures in DNSSEC. It uses both the SHA2 and SHAKE family of hash functions. This document also provides guidance for use of EDNS(0) in signature retrieval. |
| | FC-BGP Protocol Specification |
| |
|
This document defines an extension, Forwarding Commitment BGP (FC- BGP), to the Border Gateway Protocol (BGP). FC-BGP provides security for the path of Autonomous Systems (ASs) through which a BGP UPDATE message passes. Forwarding Commitment (FC) is a cryptographically signed segment to certify an AS's routing intent on its directly connected hops. Based on FC, FC-BGP aims to build a secure inter- domain system that can simultaneously authenticate the AS_PATH attribute in the BGP UPDATE message and alleviate route leaks in the BGP routing system. The extension is backward compatible, which means a router that supports the extension can interoperate with a router that doesn't support the extension. |
| | Internet of Things Message Protocol (IOTMP) |
| |
|
IOTMP (Internet of Things Message Protocol) is a compact, binary, application-layer protocol for bidirectional communication between IoT devices and servers over persistent connections. It provides a resource-oriented model with native support for remote procedure calls, real-time data streaming, and API introspection. IOTMP uses PSON (Packed Sensor Object Notation) as its data encoding format, achieving significantly lower wire overhead than text-based alternatives. The protocol is designed for constrained devices with limited memory and bandwidth, while remaining expressive enough for complex IoT applications. IOTMP operates over TCP, TLS, or WebSocket transports and supports symmetric operation where both clients and servers may expose and invoke resources. |
| | Packed Sensor Object Notation (PSON) |
| |
|
PSON (Packed Sensor Object Notation) is a compact binary data encoding format designed for IoT environments where bandwidth, memory, and processing power are constrained. PSON efficiently represents the data types commonly found in sensor telemetry and device interaction: integers, floating-point numbers, booleans, strings, binary blobs, arrays, and key-value maps. It achieves significant size reductions over JSON (40-75% for typical IoT payloads) through inline small value encoding and variable-length integers. PSON is self-describing (no external schema required for decoding) and designed for minimal implementation complexity on microcontrollers. |
| | reason:// -- A URI Scheme and Registry Protocol for Validated Agent Reasoning Artifacts |
| |
|
This document defines the "reason://" URI scheme and associated registry protocol for naming, storing, and retrieving compressed structural reasoning artifacts across distributed autonomous agent networks. An artifact enters the registry only by winning a live competitive arbitration round scored by the Web Agent Reasoning Federation (WARF) protocol. The artifact schema contains no raw data fields; the structural representation is mathematically non- invertible (empirical reconstruction rate r = 0.0149). The protocol is designed to function as open infrastructure — analogous to DNS for network addresses or HTTP for document retrieval — for the agentic internet. |
| | Machine-Readable Property Dependencies for iCalendar (RFC 5545) |
| |
|
RFC 5545 defines inter-property interaction rules for iCalendar components in prose scattered across multiple RFC sections. No published, standalone representation of these rules exists in a form suitable for machine consumption. This document specifies a formal dependency graph for VEVENT components with 27 properties and 20 edges spanning six edge types. It classifies properties into five merge safety categories that determine whether concurrent edits can be combined without user intervention. The specification is published as YAML and JSON artifacts for cross-language consumption. |
| | Comprehensive Errata for the 'retransmission-allowed' XML Element |
| |
|
This document fixes use of the 'retransmission-allowed' element of PIDF-LO in six published RFCs. All text and examples should show 'true' or 'false' to match the XML schema definitions, but some RFCs incorrectly use 'yes' or 'no'. This document updates RFC4119, RFC5606, RFC5774, RFC6442, RFC7378, RFC8262. |
| |
|
| |
| | BIER (Bit Index Explicit Replication) Redundant Ingress Router Failover |
| |
|
This document describes a failover in the Bit Index Explicit Replication domain with a redundant ingress router. |
| | LISP Site External Connectivity |
| |
|
This draft defines how to register/retrieve pETR mapping information in LISP when the destination is not registered/known to the local site and its mapping system (e.g. the destination is an internet/ external site destination or scale-out end point in backend data center networks of AI Infrastructure). |
| | HMTFTP: HKDF-Derived TFTP with Optional AEAD Protection (v0.7) |
| |
|
HMTFTP is a lightweight UDP file transfer protocol derived from TFTP. It preserves the TFTP transfer model (RRQ/WRQ, DATA, ACK, ERROR, and OACK option acknowledgment) and replaces text options with binary TLVs. HMTFTP defines optional AEAD protection for DATA payloads using HKDF-derived keys from a pre-shared key (PSK). This document describes transfer behavior, extension processing rules, key derivation, nonce construction, and operational guidance for experimental implementations intended to facilitate interoperability. This document requests IANA actions for a UDP service name/port and registries for TLV Types and Ciphersuites. Until assignment, TBD1 is used as the default UDP port value. |
| | UPIP: Universal Process Integrity Protocol with Fork Tokens for Multi-Actor Continuation |
| |
|
This document defines UPIP (Universal Process Integrity Protocol), a five-layer protocol for capturing, verifying, and reproducing computational processes across machines, actors, and trust domains. UPIP defines a cryptographic hash chain over five layers: STATE (input), DEPS (dependencies), PROCESS (execution), RESULT (output), and VERIFY (cross- machine proof). The stack hash chains these layers, ensuring that modification of any component is detectable. This document also defines Fork Tokens, a continuation mechanism for multi-actor process handoff. Fork tokens freeze the UPIP stack at a specific point and transfer it to another actor with cryptographic chain of custody. The receiving actor can verify what was handed off, validate capabilities, and continue the process with full provenance. UPIP integrates with TIBET [TIBET] for provenance tokens, JIS [JIS] for actor identity, and is transport-agnostic with JSON as the baseline serialization. |
| | AINS: AInternet Name Service - Agent Discovery and Trust Resolution Protocol |
| |
|
This document specifies AINS (AInternet Name Service), a protocol for discovery, identification, and trust resolution of autonomous agents (AI agents, devices, humans, and services) in heterogeneous networks. AINS defines a transport-independent logical namespace for agents, a structured record format combining identity, capabilities, and cryptographic trust metadata, and a resolution protocol based on HTTPS. Unlike the Domain Name System (DNS), which maps names to network addresses, AINS maps agent identifiers to rich metadata objects that include capabilities, trust scores, endpoint information, and references to companion provenance protocols. AINS federates through signed append-only replication logs, enabling multi-registry deployments without central authority while preserving auditability. This specification is designed to complement TIBET [TIBET], JIS [JIS], UPIP [UPIP], and RVP [RVP]. |
| | Credential Broker for Agents (CB4A) |
| |
|
This document specifies a Credential Broker for Agents (CB4A). a credential vaulting and brokering architecture that mediates AI agent access to API credentials. Agents never hold real long-lived credentials. Instead, they receive short-lived, narrowly scoped, auditable proxy credentials issued by a broker that separates policy decisions from credential delivery. The architecture addresses the "credential sprawl" risk inherent in agentic AI, where agents aggregating access across many services become high-value compromise targets. CB4A builds on SPIFFE/SPIRE for workload identity, uses a Policy Decision Point / Credential Delivery Point separation inspired by NIST SP 800-207, and employs DPoP (RFC 9449) for sender-constrained token binding. The specification defines three credential proxy models, a tiered approval framework, and a comprehensive threat model with ten identified threats and their mitigations. |
| |
|
| |
| | Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description |
| |
|
This document provides the External Data Representation Standard (XDR) description for Network File System version 4 (NFSv4) minor version 1. It includes protocol extensions made as part of the respecification effort for NFS Minor Version 1. It obsoletes and replaces RFC5662. |
| | Transport of Incident Detection Message Exchange Format version 2 (IDMEFv2) Messages over HTTPS |
| |
|
The Incident Detection Message Exchange Format version 2 (IDMEFv2) defines a data representation for security incidents detected on cyber and/or physical infrastructures. This draft is maintained by the IDMEFv2 Task Force. Please consult our website for more information. https://www.idmefv2.org The format is agnostic so it can be used in standalone or combined cyber (SIEM), physical (PSIM) and availability (NMS) monitoring systems. IDMEFv2 can also be used to represent man made or natural hazards threats. IDMEFv2 improves situational awareness by facilitating correlation of multiple types of events using the same base format thus enabling efficient detection of complex and combined cyber and physical attacks and incidents. This document defines a way to transport IDMEFv2 Alerts over HTTPs. If approved this document would obsolete RFC4767. |
| | DNS Catalog Zone Properties for Zone Transfers |
| |
|
This document specifies DNS Catalog Zones Properties that define the primary name servers from which specific or all member zones can transfer their associated zone, as well as properties related to zone transfers such as access control. This document also defines a groups property, for the apex of the catalog zone, as a location to assign the additional properties to certain catalog zone groups. Besides the additional properties, this document updates RFC9432 by explicitly allowing CNAME and DNAME records. |
| | The Locus URI Scheme: A 256-bit Interplanetary Addressing and Resolution Framework |
| |
|
This document defines the "locus" URI scheme, a hierarchical interplanetary addressing system that encodes both astronomical location and network routing information within a fixed 256-bit structure. The scheme enables deterministic resolution of named endpoints into IPv6-compatible network addresses and supports future interplanetary networking without reliance on centralized lookup systems. The Locus scheme introduces a unified address format spanning five tiers: star system, orbital position, planetary body, network domain, and host identifier. The upper 128 bits encode astronomical location; the lower 128 bits encode IPv6-compatible network identity. For present Earth-based deployments, the scheme resolves to standard HTTPS URLs via DNS. Future extensions accommodate delay-tolerant networking across Lunar, Martian, and interstellar distances. |
| | The Asimov Safety Architecture for Autonomous AI Agents |
| |
|
This document specifies the Asimov Safety Architecture (ASA), a hierarchical dual-gate security framework for autonomous AI agents that operate with action execution capabilities. The architecture combines a deterministic pattern denylist (Gate 1) with a stateless, context-free LLM judge (Gate 2), governed by a strict four-layer priority hierarchy. The key insight motivating this architecture is that a single LLM will not reliably self-enforce its own safety rules under adversarial pressure. The ASA addresses this by architecturally separating the reasoning model from the judging model, ensuring the judge cannot be manipulated through conversational context. This specification defines the mandatory components, layer semantics, conflict resolution rules, inter-component trust model, and conformance requirements for implementations of the Asimov Safety Architecture. |
| | Governance Framework for AI-Mediated Autonomous Network Device Management |
| |
|
This document defines a governance framework for systems that use artificial intelligence (AI) services, specifically large language models (LLMs), to autonomously detect, diagnose, and remediate operational anomalies on network devices. As AI-driven automation moves from advisory tooling to closed-loop autonomous operation on production infrastructure, the industry lacks a common set of principles governing what such systems may and may not do. This framework establishes thirteen governance areas covering human authority, harm prevention, management plane protection, minimum necessary action, bounded autonomy, transparency, reversibility, graceful degradation, escalation, AI-specific constraints, startup safety, absolute prohibitions, and review processes. It is intended to serve as a reference architecture for implementers building AI-mediated network management systems and for operators evaluating the safety properties of such systems. |
| |
|
| |
| | Admin Interface for the OSCORE Group Manager |
| |
| | draft-ietf-ace-oscore-gm-admin-17.txt |
| | Date: |
26/03/2026 |
| | Authors: |
Marco Tiloca, Rikard Hoeglund, Peter van der Stok, Francesca Palombini |
| | Working Group: |
Authentication and Authorization for Constrained Environments (ace) |
|
Group communication for the Constrained Application Protocol (CoAP) can be secured using Group Object Security for Constrained RESTful Environments (Group OSCORE). A Group Manager is responsible for handling the joining of new group members, as well as for managing and distributing the group keying material. This document defines a RESTful admin interface at the Group Manager that allows an Administrator entity to create and delete OSCORE groups, as well as to retrieve and update their configuration. The Authentication and Authorization for Constrained Environments (ACE) framework is used to enforce authentication and authorization of the Administrator at the Group Manager. Protocol-specific transport profiles of ACE are used to achieve communication security, proof of possession, and server authentication. |
| | Operational Considerations for BRSKI Registrar |
| |
|
This document describes a number of operational modes that a BRSKI Registration Authority (Registrar) may take on. Each mode is defined, and then each mode is given a relevance within an over applicability of what kind of organization the Registrar is deployed into. This document does not change any protocol mechanisms. This document includes operational advice about avoiding unwanted consequences. |
| | Extending ICMP for Interface and Next-Hop Identification |
| |
|
This memo defines data structures that can be appended to selected ICMP messages. The ICMP extensions defined herein can be used to identify any combination of the following: the IP interface upon which a datagram arrived, the sub-IP component of an IP interface upon which a datagram arrived, the IP interface through which the datagram would have been forwarded had it been forwardable, the sub- IP component of an IP interface through which the datagram would have been forwarded had it been forwardable, and the IP next hop to which the datagram would have been forwarded. Devices can use this ICMP extension to identify interfaces and their components by any combination of the following: ifIndex, IPv4 address, IPv6 address, name, and MTU. ICMP-aware devices can use these extensions to identify both numbered and unnumbered interfaces. This document obsoletes RFC 5837. To preserve strict backward compatibility with legacy implementations, it preserves the original Interface Information Object (Class-Num 2) as defined in RFC 5837, and introduces a new Extended Interface Information Object to accommodate new interface roles. |
| | The "mcp" URI Scheme and MCP Server Discovery Mechanism |
| |
|
The Model Context Protocol (MCP) defines a standard interface for AI agents to connect to external tools and services. However, no standard mechanism exists for an AI agent to autonomously discover which web domains expose an MCP server. This document defines: (1) the "mcp" URI scheme, a machine-to-machine identifier for publicly reachable MCP servers; (2) a two-mode discovery mechanism: a well-known URI (/.well-known/mcp-server) for universal compatibility, and a DNS TXT record format for DNS-native fast discovery; (3) an optional manifest integrity mechanism using JSON Web Signatures (JWS, [RFC7515]) with keys published via DNS; (4) a security capability negotiation mechanism through which the manifest declares trust class, authentication requirements, compliance frameworks, and logging policy before connection. This specification does not define the MCP protocol itself, nor authentication between agent and server. Those are covered by the MCP specification and OAuth 2.1 respectively. |
| | Agent Credential Attestation Protocol (ACAP) |
| |
|
This document defines the Agent Credential Attestation Protocol (ACAP), a cryptographic credentialing protocol for autonomous AI agent pipelines. An ACAP credential is a short-lived JSON Web Token (JWT) signed with RS256 that carries scope-limited permissions together with a SHA-256 hash of the original human instruction that initiated the task. Credentials may be delegated to child agents; each delegation narrows scope, cannot outlive its parent, increments a delegation depth counter, and extends a tamper-evident chain of token identifiers. Every lifecycle event is recorded in an append- only, hash-chained audit log. This document specifies the credential format, issuance rules, delegation rules, verification algorithm, revocation semantics, human-in-the-loop approval protocol, and audit log structure. |
| | DNS-Based Content Delivery & Fallback Mechanism |
| |
|
This document specifies a mechanism for serving content, such as HTML or JSON, directly via DNS TXT records. This feature is intended as a fallback mechanism when a primary service (A/AAAA record) is unreachable, or as a lightweight hosting solution for parked domains to display landing pages without requiring active HTTP servers or individual SSL certificates. Trust is established via DNSSEC, allowing browsers to treat the content as secure. |
| | Verifiable Trust Circles (VTCs) using VC Proof Sets |
| |
|
This document specifies Web 7.0 Verifiable Trust Circles (VTCs), a generalized mechanism for expressing verifiable multi-party membership, belonging, and trust relationships using the W3C Verifiable Credentials (VC) Data Model 2.0 [W3C.VC-DATA-MODEL] and VC Data Integrity Proof Sets [W3C.VC-DATA-INTEGRITY]. VTCs extend the Partof Architecture Reference Model (PARM) to provide a universal credential pattern that subsumes prior pairwise constructs (Personhood Credentials (PHCs) and Verifiable Relationship Credentials (VRCs)) and additionally supports voting-based decision making, meeting requests, task forces, and digital societies. |
| | A YANG Data Model for Traffic Engineering Tunnels,Label Switched Paths,and Interfaces |
| |
| | draft-ietf-teas-yang-te-44.txt |
| | Date: |
26/03/2026 |
| | Authors: |
Tarek Saad, Rakesh Gandhi, Xufeng Liu, Vishnu Beeram, Igor Bryskin |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
This document defines a YANG data model for the provisioning and management of Traffic Engineering (TE) tunnels, Label Switched Paths (LSPs), and interfaces. The model covers data pertinent to TE tunnels, TE LSPs, and TE interfaces that are independent of any technology or dataplane encapsulation. The model is divided into two YANG modules that address both device-specific and device-independent data, supporting configuration, operational state, Remote Procedure Calls (RPCs), and event notifications. |
| |
|
| |
| | A Bound End-to-End Tunnel (BEET) mode for ESP |
| |
|
This document is an update to the Bound End-to-End Tunnel (BEET) mode for ESP in as described in [RFC7402]. It brings the description in alignment with the addition of BEET mode for IKEv2 without any processing changes as described in [RFC7402] |
| | DNS Update with JSON |
| |
|
It is common for service providers such as certificate authorities and social media providers to want users to update the users' zones to prove that they control those zones, or to add other features. Currently, service providers tell users to do this using human language describing the resource record type and data values to enter into the zone. This document describes a text format, called "DNS update with JSON" or "DUJ", for such a service provider to give to a user, with the expectation that the user would copy and paste the text to their DNS operator to update the user's zone. DNS operators who know how to handle DUJ strings will make the update process easier and more predictable for their users. |
| | A Vocabulary for Controlling Usage of Content Collected by Search and AI Crawlers |
| |
|
This document proposes a standardized vocabulary to express preferences for usage of digital content collected by Search and AI crawlers. This vocabulary allows for the creation of structured declarations about restrictions or permissions for use of content retrieved by such systems. Adding the No updates on March 24, 2026 to keep document from expiring. |
| | Architecture for the Artificial Intelligence Internet Protocol |
| |
|
This document defines the architectural model for the Artificial Intelligence Internet Protocol (AIIP). AIIP defines a dedicated autonomous access plane for execution-capable systems, enabling delegated, stateless execution of real-world actions using a resolve- invoke-execute-receipt pattern over authenticated transports. AIIP is not a discovery, registration, orchestration, or control- plane protocol. It defines the architectural boundary at which autonomous execution is recognized and cryptographically verifiable through execution receipts. |
| | Agent Name System (ANS) |
| |
|
This document defines the Agent Name System (ANS), a name registration and resolution protocol for autonomous AI agents in the Agent Network Protocol (ANP) suite. ANS maps agent:// URIs to network-layer peer identifiers, providing the binding between human- readable agent names and the cryptographic peer identities used by the Agent Internet Protocol (AIP) for datagram delivery. ANS defines a Name Record format, four AITP method names for name operations (ans.register, ans.resolve, ans.unregister, ans.lookup), a multi-layer resolution algorithm, and two dissemination mechanisms (GossipSub announcements and DHT storage). ANS supports three addressing modes — unicast, anycast, and channel — over a single URI syntax. ANS is intentionally a narrow name-binding layer: it maps names to peers and tags, but defers capability description to the Agent Description Protocol (ADP), reputation and ranking to companion protocols, and economic anti-spam mechanisms to deployment profiles. |
| | Agent Internet Protocol (AIP) |
| |
|
The Internet Protocol (IP, RFC 791) provides best-effort datagram delivery between hosts identified by numeric addresses. The Agent Internet Protocol (AIP) provides best-effort datagram delivery between autonomous AI agents identified by agent:// URIs -- human- readable, capability-descriptive names. AIP is designed to serve as the narrow waist of the Agent Network Protocol (ANP) suite, occupying an architectural position analogous to IP in the TCP/IP suite: a minimal common substrate through which upper-layer protocols and link technologies interoperate without direct coupling. This document specifies the AIP message format, addressing model, upper-layer protocol demultiplexing, TLV options, message processing rules, error handling, and interfaces to adjacent protocol layers. Name registration, distributed name resolution, and semantic discovery are provided by a companion resolver service and are outside the scope of this document. |
| | Agent Invocation Transport Protocol (AITP) |
| |
|
The Agent Internet Protocol (AIP) provides best-effort, name-based datagram delivery between autonomous AI agents identified by agent:// URIs. The Agent Invocation Transport Protocol (AITP) is a message- framed invocation and streaming transport above AIP. Unlike traditional host-to-host transports (TCP, QUIC) that operate on socket endpoints and byte streams, AITP is natively message- framed, method-aware, and association-aware: its header carries a method name as a first-class field, and its protocol data units are discrete requests, responses, stream chunks, and control segments exchanged between named agents. AITP is not a byte-stream transport; it is an agent-native invocation and streaming transport that carries method names, request/response correlation, flow control, and session semantics natively in its header — so that upper-layer agent protocols need not reinvent them. AITP intentionally includes a minimal generic invocation outcome space (four dispatch- level status codes); richer application semantics belong in the response body or upper-layer protocols. Unlike transport bindings that adapt existing agent protocols to HTTP, gRPC, or MOQT, AITP defines a common invocation substrate directly above AIP, with association state, request-concurrency flow control, and method-aware framing as first-class transport concerns. AITP is best understood as a common invocation substrate above AIP, not as a byte-stream transport analogue. This document specifies the AITP segment format, segment types, status codes, flag bits, TLV options, association state machine, reliability engine, flow control, circuit-breaker mechanism, streaming, orderly close and abort, and interfaces to AIP below and application protocols above. |
| | Agent Description Protocol (ADP) |
| |
|
Autonomous AI agents in a decentralized network need a common way to describe their capabilities so that peers can discover and invoke them. The Agent Internet Protocol (AIP) provides name-based datagram delivery between agents identified by agent:// URIs; the Agent Invocation Transport Protocol (AITP) provides reliable invocation and streaming above AIP. This document describes the Agent Description Protocol (ADP), an application-layer convention carried over AITP that defines how agents describe their capabilities, publish those descriptions, and discover peers whose capabilities match a query. ADP defines the Agent Card, a JSON document format that carries an agent's identity, human-readable description, method catalogue, endpoint bindings, skill tags, and operational constraints. ADP also defines three AITP method names — adp.describe, adp.advertise, and adp.discover — through which agents exchange and query Agent Cards at the invocation layer. ADP is intentionally a thin format-and-convention layer: it standardizes the document schema and the exchange methods, but defers reputation, economics, credentials, identity infrastructure, and deployment-specific dissemination mechanisms (DHT topics, GossipSub channels, HTTP well-known URIs) to companion protocols and implementation profiles. |
| | Carrying Remote Attestation Evidence in Workload Identity Tokens (WIT) |
| |
|
This document specifies how Remote Attestation evidence, as defined by the IETF RATS architecture, can be conveyed within a Workload Identity Token (WIT) as used in the WIMSE (Workload Identity for Micro-Services Environments) framework. The WIT includes attestation measurements that enable fast-path policy evaluation without requiring immediate access to full evidence. The WIT is bound to the HTTP request using OAuth 2.0 Demonstrating Proof-of-Possession (DPoP), ensuring that attestation claims are protected against replay and token theft. This specification defines a two-tier verification model: lightweight verification using embedded measurements for common scenarios, and deep verification using externalized evidence for high-assurance requirements. This enables secure, cross-domain verification of workload integrity without requiring direct access to platform- specific reference values, while enabling efficient deployments. |
| | Tyndale: Semantic Addressing Protocol (Translation Yare Native Distributed Addressing Language Engine) |
| |
|
Notation Conventions ASCII notation is normative. Unicode notation is informative. Both encodings produce identical semantic output. The choice of representation does not alter meaning -- it demonstrates the protocol's encoding independence. This is not a modern innovation. The protocol formalizes patterns that have emerged independently across human communication systems for 60,000 years: Aboriginal songlines, medical notation (Rx), ham radio Q-codes (QTH), maritime signals (SOS), and internet shorthand (1337, TL;DR). This document specifies Tyndale, an application-layer semantic addressing protocol. Where traditional compression transmits reduced content (M -> C -> M), Tyndale transmits coordinates that the receiver expands locally (M -> A, Σ(A) -> M'). The receiver's substrate already contains the meaning; transmission provides location, not payload. The selection formula tau = (M / S) x R x G optimizes for meaning preserved per signal spent (M/S), resilience across expression systems (R), and cognitive alignment with receiver processing (G). Bandwidth-constrained environments -- disaster response networks, degraded infrastructure, deep space communications -- require semantic transmission under conditions where traditional compression fails. When every bit costs power, time, or lives, communication systems need a different primitive. Taft's teletype (1909). Voyager 1 (160 bps @ 15 billion miles). iPhone. Same protocol. Tyndale is to natural language what DNS is to IP addresses. The mathematics describes how meaning moves. |
| |
|
| |
| | NAT traversal for LISP |
| |
|
This document describes a mechanism for IPv4 NAT traversal for LISP tunnel routers (xTR) and LISP Mobile Nodes (LISP-MN) behind a Network Address Translator (NAT) device. A LISP device both detects the NAT and initializes its state. Forwarding to the LISP device through a NAT is enabled by the LISP Re-encapsulating Tunnel Router (RTR) network element, which acts as an anchor point in the data plane, forwarding traffic from unmodified LISP devices through the NAT. |
| | UAS Operator Privacy for RemoteID Messages |
| |
|
This document describes a method of providing privacy for UAS Operator/Pilot information specified in the ASTM UAS Remote ID and Tracking messages. This is achieved by encrypting, in place, those fields containing Operator sensitive data using a hybrid ECIES. |
| | BGP Extensions for Source Address Validation Networks (BGP SAVNET) |
| |
|
Many source address validation (SAV) mechanisms have been proposed for preventing source address spoofing. However, existing SAV mechanisms are faced with the problems of inaccurate validation or high operational overhead in some scenarios. This document proposes BGP SAVNET by extending BGP protocol for SAV. This protocol can propagate SAV-related information through BGP messages. The propagated information will help edge/border routers automatically generate accurate SAV rules. These rules construct a validation boundary for the network and help check the validity of source addresses of arrival data packets. |
| | Efficient Air-Ground Communications |
| |
|
This document defines protocols to provide efficient air-ground communications without associated need for aircraft to maintain stateful connection to any tower infrastructure. Instead, a secure source-routed ground infrastructure will not only provide the needed routing intelligence, but also reliable packet delivery through inclusion of Automatic Repeat reQuest (ARQ) and Forward Error Correction (FEC) protocols to address both reliable wireless packet delivery, and assured terrestrial packet delivery. |
| | Merkle Tree Ladder (MTL) Mode Signatures |
| |
| | draft-harvey-cfrg-mtl-mode-09.txt |
| | Date: |
24/03/2026 |
| | Authors: |
Joe Harvey, Burt Kaliski, Andrew Fregly, Swapneel Sheth, D. McVicker |
| | Working Group: |
Individual Submissions (none) |
|
This document provides an interoperable specification for Merkle tree ladder (MTL) mode, a technique for using an underlying signature scheme to authenticate an evolving series of messages. MTL mode can reduce the signature scheme's operational impact. Rather than signing messages individually, the MTL mode of operation signs structures called "Merkle tree ladders" that are derived from the messages to be authenticated. Individual messages are then authenticated relative to the ladder using a Merkle tree authentication path and the ladder is authenticated using the public key of the underlying signature scheme. The size and computational cost of the underlying signatures are thereby amortized across multiple messages, reducing the scheme's operational impact. The reduction can be particularly beneficial when MTL mode is applied to a post-quantum signature scheme that has a large signature size or computational cost. As an example, the document shows how to use MTL mode with ML-DSA as defined in FIPS204 and SLH-DSA as defined in FIPS205. Like other Merkle tree techniques, MTL mode's security is based only on cryptographic hash functions, so the mode is quantum- safe based on the quantum-resistance of its cryptographic hash functions. |
| | AEGIS-based Cipher Suites for TLS 1.3,DTLS 1.3,and QUIC |
| |
|
This document proposes new cipher suites based on the AEGIS family of authenticated encryption algorithms for integration into the TLS 1.3, DTLS 1.3, and QUIC protocols. 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-denis-tls-aegis/. Source for this draft and an issue tracker can be found at https://github.com/jedisct1/draft-denis-tls-aegis. |
| | Enhanced ECMP for AI Cluster |
| |
|
In AI training scenarios, the current mainstream load balancing technology is per-flow ECMP. However, hash collision issues lead to imbalanced traffic distribution, adversely affecting application performance. To address this problem, this document proposes an enhanced ECMP method that resolves load imbalance caused by hash collisions. The proposed solution effectively improves load balancing efficiency, reduces network congestion, and enhances overall network performance. |
| | The Lockb0x Protocol: Codex Entries for Verifiable Data Sovereignty |
| |
|
This document specifies the Lockb0x Protocol, a standards-based framework for creating Codex Entries (machine-readable Controllable Electronic Records) that bind together storage proofs, blockchain anchors, encryption metadata, signatures, and provenance. The protocol enables interoperability across decentralized and cloud storage systems while providing auditability and compliance with legal frameworks such as UCC Article 12. |
| | Task discovery in agentic networks |
| |
|
This document defines an architectural framework for an open, interoperable ecosystem in which task owners publish tasks—represented as structured task cards—to a task-posting platform, enabling autonomous agents to discover tasks, negotiate execution terms, and coordinate multi-agent collaboration. The architecture introduces a set of functional layers—including the Task Owner Layer, Task Owner Access Layer, Task-Posting Platform, Agentic Layer, Agent Access Layer, and an optional Communication Link—that collectively support secure task publication, agent discovery, capability evaluation, and bilateral negotiation. The framework is designed to accommodate heterogeneous agents with diverse skill sets, trust requirements, and operational models, while ensuring consistent interaction patterns across platforms and vendors. The document also surveys existing agent-discovery approaches, such as A2A, agntcy/OASF, ARDP, and DNS-AID, and identifies gaps that motivate a unified, interoperable model for task-centric and agent-initiated discovery and interaction. It also explores possible ways by which the current approached can enhance the proposed framework. The goal of this architecture is not to replace existing mechanisms but to provide a complementary framework that enables agent–task interactions in scenarios that are difficult to support using traditional agent-to-agent or platform-centric interaction models. The document is concluded with some potential standardization venues for the IETF. |
| | Mahalaxmi Federation and Orchestration Protocol (MFOP) |
| |
|
This document defines the Mahalaxmi Federation and Orchestration Protocol (MFOP), a protocol for coordinating parallel artificial intelligence (AI) agent execution across a distributed network of heterogeneous compute nodes. MFOP specifies node identity and registration, capability advertisement, compliance-zone-aware job routing using database-layer enforcement, semantic input partitioning, cryptographically signed billing receipts, configurable economic settlement, and a layered security model comprising AI safety policy validation and execution sandbox isolation. The protocol is designed to operate across three simultaneous deployment configurations: private enterprise meshes, managed cloud pools, and open community marketplaces. MFOP is agnostic to the underlying AI model provider. |
| | Decentralized Resource Name (DRN) DID Method |
| |
|
This document specifies the did:drn Decentralized Identifier (DID) method, which defines a deterministic mapping from Uniform Resource Names (URNs) (RFC 8141) into a DID-compatible identifier format called a Decentralized Resource Name (DRN). The did:drn method preserves URN semantics, enables DID resolution without mandatory centralized infrastructure, and provides optional cryptographic and service-layer extensibility. The method is fully compatible with the W3C DID Core specification (W3C DID Core, 2022) and the broader DID ecosystem. |
| | Decentralized Universal Resource Name (URN) DID Method (Web 7.0) |
| |
|
This document specifies the did7:web7 Decentralized Identifier (DID) method, which defines a deterministic mapping from Uniform Resource Names (URNs) (RFC 8141) into a DID-compatible identifier format called a Decentralized Universal Resource Name (URN). The did7:web7 method preserves URN semantics, enables DID resolution without mandatory centralized infrastructure, and provides optional cryptographic and service-layer extensibility. The method is fully compatible with the W3C DID Core specification (W3C DID Core, 2022) and the broader DID ecosystem. |
| | Best Practices for Responsible Web Data Collection |
| |
|
The IETF develops standards and protocols to make the internet work better, adhering to principles of openness and decentralization. Industry best practices and protocols for automated web data collection have long existed, but have not been documented at the IETF. For decades, researchers, universities, journalists, public interest groups, and commercial entities have used automated tools to access and collect public web data (sometimes referred to as data scraping, web crawling, or text and data mining) for a wide range of uses [I-D.farzdusa-aipref-enduser]. Examples of these uses include extraction of pricing information for market intelligence or to create a consumer price index, comparative real estate analysis to support underwriting of loans and mortgages, webpage archiving to preserve human knowledge, preserving government websites to hold political powers accountable, journalist research and reporting, and university and scientific research. Recently, innovations in artificial intelligence have significantly increased the automated collection of public web data, creating tensions between the use of AI to equalize and increase access to knowledge and the disruption of existing Internet models, including non-profit repositories that face increased demands for access and businesses that profit from free web access to human viewers. This document lists a set of technical best practices that are prevalent across industries for the automated collection of public web data. It provides protocols for how automated tools access and collect publicly available web data, including volume control, transparency, documentation, and access, that can be implemented by any automated data collector. It applies principles of net neutrality to the collection of data, providing uniform guidance regardless of the identity of the data collector or website operator, the location of the collection, or the applicable legal jurisdiction. |
| | JWT Authorization Grant Interaction Response |
| |
|
This document defines an extension to the JWT Authorization Grant [RFC7523] that enables an authorization server to indicate that user interaction is required in order to complete an authorization request. Instead of returning an access token or an error, the authorization server returns a URI that the client launches where the user can interact with the authorization server, along with a polling interval. The client can then poll for the access token or wait for a redirect before retrying the original request. |
| |
|
| |
| | Automated Certificate Management Environment (ACME) Challenge for Persistent DNS TXT Record Validation |
| |
| | draft-ietf-acme-dns-persist-01.txt |
| | Date: |
23/03/2026 |
| | Authors: |
Shiloh Heurich, Henry Birge-Lee, Michael Slaughter |
| | Working Group: |
Automated Certificate Management Environment (acme) |
|
This document specifies "dns-persist-01", a new validation method for the Automated Certificate Management Environment (ACME) protocol. This method allows a Certification Authority (CA) to verify control over a domain by confirming the presence of a persistent DNS TXT record containing CA and account identification information. This method is particularly suited for environments where traditional challenge methods are impractical, such as multi-tenant hosting platforms, enterprise DNS environments, and IoT deployments. The validation method is designed with a strong focus on security and robustness, incorporating widely adopted industry best practices for persistent domain control validation. This design aims to make it suitable for Certification Authorities operating under various policy environments, including those that align with the CA/Browser Forum Baseline Requirements. |
| | BIER BFD |
| |
| | draft-ietf-bier-bfd-11.txt |
| | Date: |
23/03/2026 |
| | Authors: |
Quan Xiong, Greg Mirsky, fangwei hu, Chang Liu, Gyan Mishra |
| | Working Group: |
Bit Indexed Explicit Replication (bier) |
|
Point to multipoint (P2MP) BFD is designed to verify multipoint connectivity. This document specifies the application of P2MP BFD in BIER network. |
| | OAuth 2.0 Resource Parameter in Access Token Response |
| |
|
This specification defines a new parameter resource to be returned in OAuth 2.0 access token responses. It enables clients to confirm that the issued token is valid for the intended resource. This mitigates ambiguity and certain classes of security vulnerabilities such as resource mix-up attacks, particularly in systems that use the Resource Indicators for OAuth 2.0 specification [RFC8707]. |
| | PPP IPCP Extensions for Encrypted DNS Server Negotiation |
| |
|
This document defines extensions to the Point-to-Point Protocol (PPP) Internet Protocol Control Protocol (IPCP) for negotiating encrypted DNS resolver configurations. These extensions allow PPP peers to exchange information about encrypted DNS servers supporting protocols such as DNS over TLS (DoT), DNS over HTTPS (DoH), and DNS over QUIC (DoQ). The design maintains backward compatibility with RFC 1877 while addressing modern security requirements. |
| | AGTP Web3 Bridge Specification |
| |
|
The Agent Transfer Protocol (AGTP) uses a PKI-based trust model: agent identity is anchored to DNS-verified domain ownership and CA- issued X.509 certificates. Web3 systems offer an alternative identity model based on blockchain address ownership, smart contract verification, and decentralized naming systems including the Ethereum Name Service (ENS) and Unstoppable Domains. This document specifies the AGTP Web3 Bridge: a framework for mapping Web3 identity anchors to AGTP trust tiers, resolving Web3 names to canonical AGTP Agent- IDs, and operating AGTP sessions with agents whose identity is anchored to blockchain rather than DNS. Web3-anchored agents are treated as Trust Tier 2 (Org-Asserted) in the absence of additional verification. This document also defines the conditions under which a Web3 identity MAY be elevated to Trust Tier 1 through a hybrid verification procedure. |
| |
|
| |
| | Crystal Network Protocol (CNP) Version 1.0 |
| |
|
CNP is a decentralized general purpose network protocol, meant to allow the seamless production of decentralized yet internet dependent applications. |
| | OMP Domain Profile: Kenya Digital Credit Providers -- CBK NDTCP Regulations 2022 and AI Decision Accountability |
| |
|
This document defines the OMP domain profile for digital credit providers (DCPs) operating under the Central Bank of Kenya Digital Credit Providers Regulations 2022 (CBK NDTCP). It specifies the Intent Class configuration, routing threshold ranges, Watchtower definitions, and Audit Trace extensions required to satisfy per- decision explainability and human oversight evidence requirements for AI-assisted credit decisions under the CBK framework. The Central Bank of Kenya AI Banking Sector Survey (July 2025) found that few institutions using AI for credit decisions have mechanisms for per-decision explainability. The CBK AI Guidance Note, in preparation as of March 2026, will define what adequate AI governance evidence means for all 195 licensed DCPs. This profile specifies the technical architecture that satisfies those requirements. This profile REQUIRES implementation of the core OMP protocol as defined in draft-veridom-omp. All terms and base protocol specifications in that document apply to this profile. This document specifies only the domain parameters. |
| | OMP Domain Profile: Kenya Deposit-Taking SACCOs -- SASRA Supervision and Cooperative Governance Accountability |
| |
|
This document defines the OMP domain profile for deposit-taking SACCOs (Savings and Credit Cooperative Organisations) operating under SASRA supervision in Kenya. It specifies the Intent Class configuration, routing threshold ranges, Watchtower definitions, and Audit Trace extensions required to satisfy board-level principal accountability requirements under the SACCO Societies Act and the Cooperatives Bill 2024. The PricewaterhouseCoopers forensic audit of KUSCCO [KUSCCO-PWC-2025] (Kenya Union of Savings and Credit Co-operatives), presented to the Cabinet Secretary for Cooperatives and MSMEs in 2025, identified KES 13.3 billion in misappropriated funds. Every specific failure identified -- forged auditor signatures, unauthorised executive loans, fraudulent commission rate changes, unlicensed operations -- was undetectable because no evidence trail connected board authorisation to operational outcome. This profile specifies the OMP architecture that closes each of those specific failure modes. The Cooperatives Bill 2024 [COOPERATIVES-BILL-2024] (Bill No. 7 of 2024), currently before the Kenyan Senate, introduces criminal penalties for SACCO board directors who cannot produce governance evidence. This profile REQUIRES implementation of the core OMP protocol as defined in [I-D.veridom-omp]. The full specification is also available at [ZENODO-OMP]. |
| | Remote APDU Call Secure Lite(RACSL) |
| |
|
The Remote APDU Call Lite protocol (RACSL) is a lightweight version of the Remote APDU Call Secure protocol (RACS). RACS is designed for Grids of Secure Elements (GoSE), where servers host Secure Elements (SEs), i.e., tamper-resistant chips providing secure storage and cryptographic capabilities. It supports commands for GoSE inventory and data exchange with secure elements. RACSL targets environments hosting a limited number of secure element-typically one-within an IoT device managed by a microcontroller. It provides commands for data exchange with secure elements, in particular for managing their embedded applications. These commands are transported over TLS 1.3 pre-shared key (PSK) sessions, which MAY be secured using a TLS Identity Module (TLS-IM) application hosted within a secure element. RACSL can be used to update TLS-IM applications or to remotely access computing and storage resources hosted in secure elements. |
| | MoQ Largest Group Extension |
| |
|
This document defines a Largest Group subscription filter type for MoQ Transport [moqt]. A subscriber uses this filter to request delivery starting from the first object of the publisher's largest (most recent) group, ensuring a complete group is received. |
| |
|
| |
| | Constrained Application Protocol (CoAP): Corrections and Clarifications |
| |
|
RFC 7252 defines the Constrained Application Protocol (CoAP), along with a number of additional specifications, including RFC 7641, RFC 7959, RFC 8132, and RFC 8323. RFC 6690 defines the link format that is used in CoAP self-description documents. Some parts of the specification may be unclear or even contain errors that may lead to misinterpretations that may impair interoperability between different implementations. The present document provides corrections, additions, and clarifications to the RFCs cited; this document thus updates these RFCs. In addition, other clarifications related to the use of CoAP in other specifications, including RFC 7390 and RFC 8075, are also provided. |
| | Monitoring BGP Parameters Using BMP |
| |
|
The BGP Monitoring Protocol (BMP) [RFC7854] is designed to monitor BGP [RFC4271] running status, such as BGP peer relationship establishment and termination and route updates. Without BMP, manual query is required if you want to know about BGP running status. This document provides the use cases that the BMP station can get the optional parameters that are supported by the monitored network device and default configure parameters of the monitored network device via BMP. |
| | Destination-IP-Origin-AS Filter for BGP Flow Specification |
| |
|
This document defines an extension to the Border Gateway Protocol (BGP) Flow Specification (FlowSpec) to enable filtering based on the Origin Autonomous System (AS) of the destination IP address. This extension is particularly useful in mitigating Distributed Denial of Service (DDoS) attacks where the target IP addresses are dynamic but belong to a specific destination AS. |
| | RGB (Replication through Global Bitstring) Segment for Multicast Source Routing over IPv6 |
| |
|
This document introduces the RGB (Replication through Global Bitstring) Segment for Multicast Source Routing over IPv6. |
| | Verifiable Voice Protocol |
| |
|
Verifiable Voice Protocol (VVP) authenticates and authorizes organizations and individuals making and/or receiving telephone calls. This eliminates trust gaps that malicious parties exploit. Like related technologies such as SHAKEN, RCD, and BCID, VVP uses STIR to bind cryptographic evidence to a SIP INVITE, and verify this evidence downstream. VVP can also let evidence flow the other way, proving things about the callee. VVP builds from different technical and governance assumptions than alternatives, and uses richer, stronger evidence. This allows VVP to cross jurisdictional boundaries easily and robustly. It also makes VVP simpler, more decentralized, cheaper to deploy and maintain, more private, more scalable, and higher assurance. Because it is easier to adopt, VVP can plug gaps or build bridges between other approaches, functioning as glue in hybrid ecosystems. For example, it may justify an A attestation in SHAKEN, or an RCD passport for branded calling, when a call originates outside SHAKEN or RCD ecosystems. VVP also works well as a standalone mechanism, independent of other solutions. An extra benefit is that VVP enables two-way evidence sharing with verifiable text and chat (e.g., RCS and vCon), as well as with other industry verticals that need verifiability in non-telco contexts. |
| | Source-IP-Origin-AS Filter for BGP Flow Specification |
| |
|
This document defines an extension to the Border Gateway Protocol (BGP) Flow Specification (FlowSpec) to enable filtering based on the Origin Autonomous System (AS) of the source IP address. This extension is particularly useful in mitigating Distributed Denial of Service (DDoS) attacks where the source IP addresses are dynamic but belong to a specific source AS. |
| | IPv6 Over Nothing |
| |
|
A perspective on the function of the network layer is that it abstracts away the differences between the various underlying link layer frame and addressing formats, unifying them into a common protocol data unit format and addressing scheme, namely the IPv4 or IPv6 protocols, and hiding those details from the upper transport layer protocols. As IPv6 is expected to become the dominant network layer protocol, and Ethernet has become the dominant link layer protocol, this memo proposes eliminating the overhead of the abstraction of Ethernet by IPv6 and using IPv6 directly as both the link layer and network layer protocol. |
| | Security Considerations for ML-DSA |
| |
|
NIST standardized ML-DSA as FIPS 204 in August 2024. This document discusses how to use ML-DSA within protocols - that is, what problem it solves, and what you need to do to use it securely. |
| | Unheaded: Protocol Foundation -- A Mapped Data Bus over IPv6 Hop-by-Hop Options |
| |
|
The Unheaded Protocol defines a mapped data bus model that transforms IPv6 packets into addressable memory by encoding a small register file directly in the IPv6 Hop-by-Hop Options extension header. We introduce a 20-byte Monad (register file) that carries program state through the network. At each hop, a BPF program (the Shim) performs computation on the Monad. The packet itself becomes the working memory, using exponent-encoded fields to pack rich metadata into the IPv6 option while remaining fully backward-compatible with existing networks. To support programs larger than what fits in a single Monad, we introduce Wotan, a memory and I/O bus that bridges Monad computation to per-flow ring-buffer storage and external topics. This decouples the Monad (pure, 20-byte compute) from memory (Wotan's configurable data planes). This memo extends the packet format with two additional capabilities: (1) Kingdom Mode Address Reclamation, which recovers up to 224 bits of deterministic address space from IPv6 addresses within a controlled L2 fabric for use as extended computational and cryptographic registers; and (2) Post-Quantum Cryptographic Identity Binding, which cryptographically binds each service identifier in the Monad to a post-quantum keypair via the Sophia dictionary system, providing quantum-resistant authentication of per-packet metadata without increasing wire overhead. This memo defines the normative packet format, exponent-encoding scheme, per-hop processing semantics, address reclamation model, post-quantum identity binding, optional chaos injection for resilience testing, and the complete computational model (Turing- complete with memory paging). |
| | Sophia Dictionary Format for the Unheaded Protocol |
| |
|
The Sophia Dictionary Format defines the serialization, storage, and distribution mechanism for semantic metadata that accompanies the Unheaded Protocol. Sophia dictionaries are exponent-decoding tables that translate compact byte values (0x00-0xFF) into meaningful human- readable categories (service identifiers, QoS classes, flow actions, etc.) and their associated metadata. This memo specifies the CBOR serialization format for dictionary entries, the BPF map representation for in-kernel storage, the atomic update protocol for cluster-wide distribution via the Wotan memory bus, and the minimum required dictionary entries for any conformant Unheaded deployment. Draft-03 introduces sub-dictionary type systems for hierarchical knowledge representation and QPACK compression headers for efficient dictionary entry encoding over the wire. Sophia dictionaries support atomic replacement: updates propagate to all nodes in under 10 milliseconds without packet loss or service interruption. |
| | Wotan Memory Protocol for the Unheaded Protocol |
| |
|
Wotan is the memory and I/O bus for the Unheaded Protocol, providing addressable per-flow storage for BPF programs executing within the Limited Domain. The Wotan protocol specifies the BPF helper interface for memory access, the address space layout for per-flow data structures, a five-level cache hierarchy (L0 through L4), and the topic-based I/O model for interaction with userspace services. This memo defines the memory model, helper functions, address space, cache miss protocol, gRPC streaming contracts, triple-role architecture, reliability guarantees, and I/O topic naming conventions for systems implementing the Unheaded Protocol's computational layer. Draft-03 introduces a structured error code taxonomy with severity levels, helper return codes for common operations, and error recovery procedures. Draft-02 security patches W1-W8 are retained. |
| | MBC Instruction Set Architecture for the Unheaded Protocol Computer |
| |
|
This document defines the MBC (Monad Bytecode) Instruction Set Architecture for the Unheaded Protocol Computer (UPC). MBC is a 48-opcode, 32-bit fixed-width instruction set designed for execution within eBPF XDP programs. It provides computational capabilities for distributed packet processing using the Monad wire format, enabling deterministic network packet classification and transformation at the network edge. |
| | Shim Pipeline Specification for the Unheaded Protocol Computer |
| |
|
This document specifies the Shim pipeline for the Unheaded Protocol Computer (UPC). The Shim translates MBC (Monad Bytecode) programs into eBPF execution contexts, defines the per-hop processing model, and specifies the tick packet protocol that drives distributed computation across IPv6 network hops. The pipeline implements a four-stage architecture: Assembly, Verification, Loading, and Execution, with integrated support for memory-mapped I/O, framebuffer rendering, and CRC validation. |
| | Post-Quantum Packet Authentication for the Unheaded Protocol |
| |
|
This document specifies a post-quantum cryptographic (PQC) authentication mechanism for the Unheaded Protocol Foundation. It defines a multi-algorithm, dual-layer, tiered authentication architecture integrating three NIST PQC digital signature standards -- FIPS 205 (SLH-DSA), FIPS 204 (ML-DSA), and FIPS 206 (FN-DSA) -- plus two NIST PQC key-encapsulation mechanisms -- FIPS 203 (ML-KEM) and FIPS 207 (HQC) -- with the Monad wire format, Sophia BPF map dictionaries, and Wotan per-flow memory model. Layer 1 (Wire-Level, REQUIRED): Full PQC signatures are stored in Sophia BPF maps via a "signature-by-reference" scheme. The Monad register carries compact 12-byte references (SigRef, KeyRef, SeqNum, HashPfx). Shield verifies signatures at the network perimeter and strips Monad Hop-by-Hop headers at ingress -- internal kingdom traffic never carries PQC wire overhead. Layer 2 (Application-Level, OPTIONAL): User applications MAY define verification requirements in Sophia application policy dictionaries. After wire-level authentication succeeds, the application reads Wotan per-flow PQC state and matches it against its own policy. Four PQC compliance tiers -- NONE, STANDARD, ENHANCED, and SOVEREIGN -- are signaled via Kingdom Mode bits in the Monad flags byte. |
| | An ASIL-M Profile for Multi-Root Evidence Synthesis in RATS |
| |
|
This document defines an application profile for Remote ATtestation procedureS (RATS) deployments in which authorization decisions depend on evidence from multiple independent trust roots. The profile is intended for AI inference systems that require explicit cross-root appraisal before execution is authorized. The document specifies three related artifacts: * an Attestation Evidence Synthesis Protocol for combining multiple evidence sets into one deterministic appraisal outcome; * the Twin Attestation Policy Language (TAPL), a constrained policy language for deterministic multi-root appraisal; and * the Canonical Attestation Record (CAR), an audit-oriented envelope that binds evidence references, appraisal outputs, freshness information, and replay-verification metadata. CAR is not a replacement for Evidence or Attestation Results as used in the RATS architecture. Instead, it is a higher-layer profile for packaging multi-root appraisal state and application-specific bindings for replay and audit. |
| | BGP Flow Specification Extensions for Network Congestion Management |
| |
|
BGP Flow Specification (FlowSpec) [RFC8955] and [RFC8956] has been proposed to distribute traffic filter policy (traffic filters and actions) via BGP [RFC4271]. Multiple applications have used BGP FlowSpec to distribute traffic filter policy. These applications include the following: mitigation of denial of service (DoS), enabling traffic filtering in BGP/MPLS VPNs, centralized traffic control of router firewall functions, and SFC traffic insertion. Due to its powerful extensibility, FlowSpec can be easily used for network congestion management. This document describes how to use BGP FlowSpec to implement network congestion management. |
| | Post-Quantum Algorithms Overview |
| |
|
This document summarizes publicly available information on a range of widely studied post-quantum cryptographic algorithms, including Key Encapsulation Mechanisms (KEMs) and digital signature schemes. It aggregates parameters and high-level security assumptions from existing specifications and standardization efforts, serving as a unified informational reference. This document is purely informational. It does not provide guidance, recommendations, or requirements regarding algorithm selection, deployment, or migration strategies. |
| | Reservation of EVPN Route Types for Experimental Use |
| |
|
This document reserves codepoints in the EVPN Route Type registry for experimental use to enable implementations to carry out development and test of new EVPN features. It updates RFC7432 to modify the registration policy for the EVPN Route Type registry. |
| | TLS Key Share Prediction |
| |
|
This document defines a mechanism for servers to communicate supported key share algorithms in DNS. Clients may use this information to reduce TLS handshake round-trips. |
| |
|
| |
| | Optimized Rekeys in the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
This document describes a method for reducing the size of the Internet Key Exchange version 2 (IKEv2) CREATE_CHILD_SA exchanges used for rekeying of the IKE or Child SA by replacing the SA and TS payloads with a Notify Message payload. Reducing size and complexity of IKEv2 exchanges is especially useful for low power consumption battery powered devices. |
| | STD Numbers and the IETF Standards Track |
| |
|
STD numbers are assigned to IETF Standards Track specifications in order to provide a stable reference even when RFCs are revised and the underlying documents change. However, the numbers are only assigned when the specifications reach Internet Standard maturity level, significantly reducing their utility in the contemporary world in which few specifications advance beyond the first standardization maturity level. For that reason, one proposal, more than a decade ago, suggested eliminating the numbers entirely. Others, including more recent ones, have suggested eliminating maturity levels entirely, in part as a way to solve the numbering problem. This document argues that stable references for Standards Track specifications are actually useful and that the solution is not to abolish the numbers or maturity levels but to change the point at which they are assigned. |
| | Views and View Addresses for Secure Asset Transfer |
| |
|
With increasing use of DLT (distributed ledger technology) systems, including blockchain systems and networks, for virtual assets, there is a need for asset-related data and metadata to traverse system boundaries and link their respective business workflows. Core requirements for such interoperation between systems are the abilities of these systems to project views of their assets to external parties, either individual agents or other systems, and the abilities of those external parties to locate and address the views they are interested in. A view denotes the complete or partial state of a virtual asset, or the output of a function computed over the states of one or more assets, or locks or pledges made over assets for internal or external parties. Systems projecting these views must be able to guard them using custom access control policies, and external parties consuming them must be able to verify them independently for authenticity, finality, and freshness. The end-to- end protocol that allows an external party to request a view by an address and a DLT system to return a view in response must be DLT- neutral and mask the interior particularities and complexities of the DLT systems. The view generation and verification modules at the endpoints must obey the native consensus logic of their respective systems. |
| | Protocol for Requesting and Sharing Views across Networks |
| |
| | draft-ramakrishna-satp-data-sharing-05.txt |
| | Date: |
18/03/2026 |
| | Authors: |
Venkatraman Ramakrishna, Vinayaka Pandit, Ermyas Abebe, Sandeep Nishad, Dhinakaran Vinayagamurthy |
| | Working Group: |
Individual Submissions (none) |
|
With increasing use of DLT (distributed ledger technology) systems, including blockchain systems and networks, for virtual assets, there is a need for asset-related data and metadata to traverse system boundaries and link their respective business workflows. Systems and networks can define and project views, or asset states, outside of their boundaries, as well as guard them using access control policies, and external agents or other systems can address those views in a globally unique manner. Universal interoperability requires such systems and networks to request and supply views via gateway nodes using a request-response protocol. The endpoints of this protocol lie within the respective systems or in networks of peer nodes, but the cross-system protocol occurs through the systems’ respective gateways. The inter-gateway protocol that allows an external party to request a view by an address and a DLT system to return a view in response must be DLT-neutral and mask the internal particularities and complexities of the DLT systems. The view generation and verification modules at the endpoints must obey the native consensus logic of their respective networks. |
| | Current Process for Handling RFC Errata Reports |
| |
|
This document describes the current web-based process for handling the submission, verification, and posting of errata for the RFC Series. The main concepts behind this process are (1) distributing the responsibility for verification to the appropriate organization or person for each RFC stream, and (2) using a Web portal to automate the processing of erratum reports. This system was launched in November 2007. This draft documents the existing system as a means to facilitate discussion to revamp how errata are reported, reviewed, and publicized. |
| | Path-aware Remote Protection Framework |
| |
|
This document describes the framework of path-aware remote protection. |
| | RPKI Repository Delta Protocol (RRDP) Delta File Retention Policy |
| |
|
This document updates RFC 8182 (The RPKI Repository Delta Protocol) by specifying an optimized delta file retention policy based on client access patterns. The proposed mechanism allows RRDP servers to maintain only the delta files required by active clients, reducing storage requirements while maintaining compatibility with existing clients. By tracking which serial numbers are being requested by active clients, the repository can determine the minimum serial number needed by any client and safely prune delta files that update from earlier serial numbers. The proposed mechanism provides several benefits, including reduced storage requirements, smaller notification files, and more efficient use of bandwidth and processing resources. It also maintains backward compatibility with existing RRDP clients, requiring no changes to client implementations. |
| | Agent Definition Language (ADL) |
| |
|
The Agent Definition Language (ADL) provides a standard JSON-based format for describing AI agents. An ADL document declares an agent's identity, capabilities, tools, permissions, security requirements, data classification, and runtime configuration in a single, machine- readable artifact. ADL enables discovery, interoperability, deployment, and lifecycle management of AI agents across diverse platforms and runtimes. This document defines the structure of ADL documents, the semantics of their members, conformance requirements for implementations, and the registration of the application/adl+json media type. |
| | Timing Regimes in Quantum Networks and their Physical Underpinnings |
| |
|
Entangling quantum networks build on new physical mechanisms to distribute quantum entanglement among a set of nodes over a set of links. To design a complete network protocol stack with proper division of responsibilities into layers, hardware and protocol engineers must share an understanding of those physical mechanisms and use a common vocabulary. This document bridges the abstract concepts described in [RFC9340] and the underlying physics to engineering concerns such as timing constraints on arrival of photons and exchange of supporting classical messages. The equations presented here will serve as reference points for architectural decisions in future documents, allowing future documents to deal directly in code without complex mathematics. Application-layer developers will not need the low-level physics presented here. |
| | Global Opaque Block for IOAM Pre-allocated Trace Option |
| |
|
Extensible metadata carried within the IOAM Pre-allocated Trace Option (PTO) can support packet-level, flow-level, or path-level processing beyond per-node trace data. This document defines the Global Opaque Block (GOB), an extension to the IOAM PTO that introduces a single pre-allocated global metadata region placed between the PTO fixed header and the node data list. The GOB carries an explicit length and schema identifier, preserves the pre-allocated PTO processing model, and can be used to transport Extensible In-band Processing (EIP) Information Elements or other structured metadata formats. |
| | Artefacts Registry |
| |
|
This memo describes the Artefacts Registry for Asset Exchange API. The Registry is a component that exposes an API allowing gateways to fetch information related to the SAT protocol. Examples information stored in the Artefacts Registry are network identifiers, entities identifiers, asset profiles, or asset instances. Registries are are acting as persistent storage locations for records. Once registered, records can be updated in an append-only manner. |
| | BGP-based Unreachable Prefix Advertisement for Inter-Domain Fast Reroute |
| |
|
This document specifies a mechanism for advertising unreachable prefixes across Autonomous Systems using BGP. The mechanism enables fast convergence in VPN services when backbone source nodes become unreachable, by allowing Unreachable Prefix Advertisement (UPA) routes propagated through BGP across AS boundaries. This solution extends the IGP-based UPA mechanism defined in RFC9929 to inter- domain scenarios, ensuring remote PEs can promptly detect and react to failures in source domains. The route is not used for packet forwarding but solely for BGP next-hop reachability resolution, enabling fast failover of BGP VPN routes. |
| | Extensible In-band Processing (EIP) Headers Definitions |
| |
|
This document discusses the format of EIP protocol elements and the transport of EIP in different IPv6-based protocol headers. In particular, this document defines the standalone EIP formats for the IPv6 Hop-by-Hop Options Header and for the Segment Routing Header, and it defines the generic format of EIP Information Elements. Other approaches to transport EIP, including integration with the IOAM framework through the Global Opaque Block (GOB), are described in separate documents. Caveat: this document is still in brainstorming stage, it is distributed to stimulate discussion. |
| |
|
| |
| | AC-Aware Bundling Service Interface in EVPN |
| |
|
An EVPN (Ethernet VPNs) provides an extensible and flexible multihoming VPN solution over an MPLS/IP network for intra-subnet connectivity among Tenant Systems and End Devices that can be physical or virtual. EVPN multihoming with Integrated Routing and Bridging (IRB) is one of the common deployment scenarios. Some deployments requires the capability to have multiple subnets designated with multiple VLAN IDs in the single broadcast domain. EVPN technology defines three different types of service interface which serve different requirements but none of them address the requirement of supporting multiple subnets within a single broadcast domain. In this document, we define a new service interface type to support multiple subnets in the single broadcast domain. Service interface proposed in this document will be applicable to multihoming cases only. |
| | Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) in EAP-AKA prime |
| |
|
Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS) is specified in [RFC9678], providing updates to [RFC9048] with an optional extension that offers ephemeral key exchange using the traditional Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key agreement algorithm for achieving perfect forward secrecy (PFS). However, it is susceptible to future threats from Cryptographically Relevant Quantum Computers, which could potentially compromise a traditional ephemeral public key. If the adversary has also obtained knowledge of the long-term key and ephemeral public key, it could compromise session keys generated as part of the authentication run in EAP-AKA'. This draft aims to enhance the security of EAP-AKA' FS protocol by making it quantum-safe using Post-Quantum Key Encapsulation Mechanisms (PQ-KEMs). |
| | DLEP Radio Quality Extension |
| |
|
This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) to provide the quality of incoming radio signals. |
| | DLEP Radio Band Extension |
| |
|
This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) to provide information about frequency bands used by the radio. |
| | DLEP Radio Channel Utilization Extension |
| |
|
This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) to provide the utilization of a radio channel. |
| | S-BFD Proxy |
| |
| | draft-yang-bfd-sbfd-proxy-03.txt |
| | Date: |
17/03/2026 |
| | Authors: |
Qing Yang, Feng Zhu, Victor Wen, Hanchen Zheng, Liu Yang |
| | Working Group: |
Individual Submissions (none) |
|
This document proposes an extension to Seamless Bidirectional Forwarding Detection (S-BFD). The S-BFD initiator will send packets that carry extra information, and this enables reflector to act as a proxy, and respond with the extra information in consideration. This document updates RFC 7880. |
| | BGP Flow Specification Version 2 - More IP Filters |
| |
|
The BGP flow specification version 2 (FSv2) for Basic IP defines user ordering of filters along with FSv1 IP Filters and FSv1 actions. This draft defines the format for the Extended IP Filters for Flow Specification FSv2. |
| | The tag-42 profile of CBOR |
| |
|
This document defines a bespoke serialization of CBOR intended for use with the special tag 42 in various end-to-end protocols that came out of the IPFS community. Much of its design dates to the first CBOR RFC and predates much of the terminology and the layered approach to determinism elaborated in later years. CBOR-42 can be used as an internet-scale serialization for JSON, and is optimized for objects that compose into a directed acyclical graph. Since CBOR-42 objects link to one another by hash-based identifiers tagged "42", deterministic encoding is mandated to verify dereferenced links and encode new ones. |
| | The "Payment" HTTP Authentication Scheme |
| |
| | draft-ryan-httpauth-payment-01.txt |
| | Date: |
17/03/2026 |
| | Authors: |
Brendan Ryan, Jake Moxey, Tom Meagher, Jeff Weinstein, Steve Kaliski |
| | Working Group: |
Individual Submissions (none) |
|
This document defines the "Payment" HTTP authentication scheme, enabling HTTP resources to require a payment challenge to be fulfilled before access. The scheme extends HTTP Authentication, using the HTTP 402 "Payment Required" status code. The protocol is payment-method agnostic, supporting any payment network or currency through registered payment method identifiers. Specific payment methods are defined in separate payment method specifications. |
| | DID7: Authority-Scoped Decentralized Identifier Scheme |
| |
|
This document defines the "did7" URI scheme, an authority-scoped decentralized identifier format. DID7 introduces an optional authority component and a two-stage resolution process, while remaining fully compatible with the W3C Decentralized Identifiers (DIDs) v1.0 specification (DID Core). |
| | Conditional Access for HTTP |
| |
|
This document introduces conditional access to resources based on pricing constraints signaled via request and response headers. An origin states the conditions for serving a resource, and a client states the constraints under which it will accept it. This specification applies this conditional access approach using standard HTTP request and response semantics while staying interoperable with intermediaries. It introduces a Pricing response header field that communicates current pricing terms and an If-Price- LTE request header field that allows a client to declare a maximum acceptable price. When a request is served under such conditions, the response includes a Response-Id header identifying the served response context. This identifier can be used for reconciliation, auditing, and downstream usage reporting. This specification defines access condition signaling only. Accounting and usage reporting may be implemented using a companion protocol such as usage-log. |
| | HTTP Usage Reporting for Cached Resources |
| |
|
This document defines a mechanism by which an HTTP origin can advertise an endpoint for downstream usage reporting and by which an authenticated client operator can report usage of cached representations that were used without issuing additional requests to the origin. The mechanism complements access-time response metadata by allowing a client operator to report downstream usage associated with a prior origin-served response context. The protocol defines discovery of a usage reporting endpoint, submission semantics, and a minimal record format suitable for reconciliation and billing. This specification does not define payment, settlement, or enforcement mechanisms. It defines a good-faith accounting protocol for reporting downstream usage. |
| | Cryptographically Verifiable Intent Chain for AI Agent Content Provenance |
| |
|
This document defines the intent_chain claim as a companion to the actor_chain claim defined in {{!I-D.draft-mw-spice-actor-chain}}. While the actor chain addresses delegation provenance (WHO delegated to whom), the intent chain addresses content provenance (WHAT was produced and HOW it was transformed). In AI agent workflows, content flows through multiple processing stages including AI agents and filters. The intent chain provides a cryptographically verifiable, tamper-evident record of this content journey. The full intent chain is stored as ordered logs, with only the Merkle root included in the OAuth token for efficiency. Together, the actor chain and intent chain provide complete governance for autonomous AI agent systems, addressing Spoofing, Tampering, Repudiation, and Elevation of Privilege threats in the STRIDE threat model. |
| | Cryptographically Verifiable Inference Chain for AI Agent Computational Provenance |
| |
|
This document defines the inference_root claim as a companion to the actor_chain claim ({{!I-D.draft-mw-spice-actor-chain}}) and the intent_root claim ({{!I-D.draft-mw-spice-intent-chain}}). While the actor chain addresses delegation provenance (WHO) and the intent chain addresses content provenance (WHAT), the inference chain addresses computational provenance (HOW) — providing cryptographic proof that a claimed AI model actually performed the inference that produced a given output. The inference chain leverages two complementary mechanisms: Zero- Knowledge Machine Learning (ZKML) proofs for mathematical certainty, and Trusted Execution Environment (TEE) attestation quotes for production-scale AI workloads. The full inference chain is stored as ordered logs, with only the Merkle root included in the OAuth token for efficiency. Together, the three chains — actor, intent, and inference — form a complete "Truth Stack" for autonomous AI agent governance. |
| | Roughtime |
| |
|
This document describes Roughtime, an experimental protocol that aims to achieve two things: secure rough time synchronization even for clients without any idea of what time it is, and give clients a format for reporting any inconsistencies they observe between timeservers. This document specifies the on-wire protocol required for these goals, and discusses aspects of the ecosystem needed for it to work. |
| | Managing multiple paths for a QUIC connection |
| |
| | draft-ietf-quic-multipath-21.txt |
| | Date: |
17/03/2026 |
| | Authors: |
Yanmei Liu, Yunfei Ma, Quentin De Coninck, Olivier Bonaventure, Christian Huitema, Mirja Kuehlewind |
| | Working Group: |
QUIC (quic) |
|
This document specifies a multipath extension for the QUIC protocol to enable the simultaneous usage of multiple paths for a single connection. It introduces explicit path identifiers to create, delete, and manage multiple paths. This document does not specify address discovery or management, nor how applications using QUIC schedule traffic over multiple paths. |
| | SRIFT: Segment Routing in Fat Trees |
| |
| | draft-ietf-rift-sr-03.txt |
| | Date: |
17/03/2026 |
| | Authors: |
Zhaohui Zhang, Jeff Tantsura, Jordan Head |
| | Working Group: |
Routing In Fat Trees (rift) |
|
This document specifies signaling procedures for Segment Routing in RIFT. Each node's loopback address, Segment Routing Global Block (SRGB) and Node Segment Identifier (Node-SID), which are typically assigned by a configuration management system and distibuted by routing protocols, are distributed southbound from the Top Of Fabric (TOF) nodes via RIFT's Key-Value distribution mechanism, so that each node can compute how to reach a segment represented by the active SID in a packet. An SR controller signals SR policies to ingress nodes so that they can send packets with a desired segment list to steer traffic. |