| |
|
| |
| | CoAP Transport Indication |
| |
|
The Constrained Application Protocol (CoAP, [RFC7252]) is available over different transports (UDP, DTLS, TCP, TLS, WebSockets), but lacks a way to unify these addresses. This document provides terminology and provisions based on Web Linking [RFC8288] and Service Bindings (SVCB, [RFC9460]) to express alternative transports available to a device, and to optimize exchanges using these. |
| | Updated Use of the Expires Message Header Field |
| |
|
This document allows broader use of the Expires message header field for mail messages. Message creators can then indicate when a message expires, while recipients would use this information to handle an expired message differently. |
| | Unobtrusive End-to-End Email Signatures |
| |
|
This document deals with end-to-end cryptographically signed email. It introduces a structure for signed email that is designed to avoid creating any disturbance in legacy email clients. This "unobtrusive" signature structure removes disincentives for signing email. |
| | SCION Control Plane |
| |
|
This document describes the Control Plane of the path-aware, inter- domain network architecture SCION (Scalability, Control, and Isolation On Next-generation networks). A fundamental characteristic of SCION is that it gives path control to SCION-capable endpoints that can choose between multiple path options, thereby enabling the optimization of network paths. The SCION Control Plane is responsible for discovering these paths and making them available to the endpoints. The SCION Control Plane creates and securely disseminates path segments between SCION Autonomous Systems (AS) which can then be combined into forwarding paths to transmit packets in the data plane. This document describes mechanisms of path exploration through beaconing and path registration. In addition, it describes how Endpoints construct end-to-end paths by combining path segments obtained through a path lookup process. This document contains new approaches to secure path aware networking. It is not an Internet Standard, has not received any formal review of the IETF, nor was the work developed through the rough consensus process. The approaches in this work are offered to the community for its consideration in the further evolution of the Internet. |
| | An IPv4 and IPv6 measurement option (MO) for hybrid flow measurements. |
| |
|
This document introduces an internet protocol (IP) measurement option (MO) that contains information, normally not available to the receiver of IP packets, to perform hybrid network measurements. In particular, measurements that need a sender time stamp and a packet order number are then possible directly at the receiver. The information contained in the IP MO can also be used by hosts en-route to perform slightly more limited hybrid network measurements. |
| | Inter-layer Protocol |
| |
|
This document describes an inter-layer protocol, that can be used to insert an arbitrary number of headers between the internet protocol (IPv4, IPv6) header and a layer four header like the UDP or TCP header. By doing so, it consumes part of the space available for IP payload data. It is, in particular, useful to extend the space reserved for IP options as defined in the IPv4 protocol [RFC791]. |
| | AGTP Session Protocol |
| |
|
This document specifies the AGTP Session Protocol (AGTP-SESSION), a companion to [AGTP] that defines session semantics for agent-to-agent and agent-to-API communication. AGTP-SESSION addresses two distinct session models: bounded sessions for time-limited transactional flows, and persistent sessions for long-lived agent contexts. Both inherit identity, authority, and attribution from base AGTP. This is an early working draft; many design decisions are deliberately open. |
| | OAuth Actor Profile for Delegation |
| |
|
OAuth deployments increasingly involve agents and workloads acting on behalf of human users across organizational boundaries. Existing specifications provide relevant building blocks (notably the act claim from RFC 8693 Token Exchange) but do not define a consistent profile for representing delegated actor relationships across JWT assertion grants (RFC 7523), JWT access tokens (RFC 9068), and Transaction Tokens, nor for classifying actor entity types or signaling support between authorization servers and resource servers. The result is inconsistent actor representation and actor- representation interoperability gaps that force deployments to rely on proprietary conventions. This document defines the OAuth Actor Profile for Delegation. It specifies a common act claim structure extended with sub_profile for entity-type classification, processing rules for authorization servers and resource servers across the three token families and their Token Exchange inputs, and OAuth discovery metadata parameters for advertising actor-profile support. The profile applies uniformly across token types and integrates with existing sender-constraint mechanisms (DPoP, mTLS). It does not standardize the policies by which systems determine whether a given actor is permitted to act for a subject; those decisions remain deployment-specific. |
| | HACP: A Capability-Contract Protocol for AI Agents and Edge Hardware |
| |
|
HACP (Hardware Agent Capability Protocol) is a JSON-RPC 2.0 transport- agnostic protocol that lets a Large Language Model (LLM) agent — or any program acting on its behalf — discover, plan, execute, observe, and audit operations on physical edge hardware (GPIO, I2C, UART, sensors, system telemetry, files) through a single, stable, security-checked surface. HACP sits below higher-level agent protocols such as the Model Context Protocol and above the operating system. It is designed to make heterogeneous edge devices interoperable with diverse AI agent implementations without requiring either side to know the details of the other. This document specifies the HACP wire format, core methods, lifecycle, error model, security requirements, and audit semantics. Streaming, attestation, and MCP-bridge profiles are sketched as optional or preview. |
| |
|
| |
| | Seamless Multicast Interoperability between EVPN and MVPN PEs |
| |
|
Ethernet Virtual Private Network (EVPN) solution is becoming pervasive for Network Virtualization Overlay (NVO) services in data center (DC), Enterprise networks as well as in service provider (SP) networks. As service providers transform their networks in their Central Offices (COs) towards the next generation data center with Software Defined Networking (SDN) based fabric and Network Function Virtualization (NFV), they want to be able to maintain their offered services including Multicast VPN (MVPN) service between their existing network and their new Service Provider Data Center (SPDC) network seamlessly without the use of gateway devices. They want to have such seamless interoperability between their new SPDCs and their existing networks for a) reducing cost, b) having optimum forwarding, and c) reducing provisioning. This document describes a unified solution based on RFCs 6513 & 6514 for seamless interoperability of Multicast VPN between EVPN and MVPN PEs. Furthermore, it describes how the proposed solution can be used as a routed multicast solution in data centers with only EVPN PEs. |
| | Advertising p2mp policies in BGP |
| |
| | draft-ietf-idr-sr-p2mp-policy-01.txt |
| | Date: |
29/04/2026 |
| | Authors: |
Hooman Bidgoli, Dan Voyer, Andrew Stone, Rishabh Parekh, Serge Krier, Swadesh Agrawal |
| | Working Group: |
Inter-Domain Routing (idr) |
|
SR P2MP policies are set of policies that enable architecture for P2MP service delivery. A P2MP policy consists of candidate paths (CPs) that connects the Root of the Tree to a set of Leaves. The P2MP policy is composed of replication segments [RFC9524]. A replication segment is a forwarding instruction for a candidate path which is downloaded to the Root, transit nodes and the leaves. This document specifies a new BGP SAFI with a new NLRI in order to advertise P2MP policy from a controller to a set of nodes. This document introduces three new route types within this NLRI, one for P2MP policy and its candidate paths that need to be programmed on the Root node, one for the replication segment incoming SID which uniquely will identify the replication state and another for each outgoing interface that the packets get replicated to. The last two route types are forwarding instructions that needs to be programmed on the Root, and optionally on Transit and Leaf nodes. It should be noted that this document does not specify how the Root and the Leaves are discovered on the controller, it only describes how the P2MP Policy and Replication Segments are programmed from the controller to the nodes. |
| | Deviceid-Scoped Layout Recall for NFSv4.2 |
| |
|
The Parallel Network File System (pNFS) allows the metadata server to recall a layout from a client by file id, by file system id, or across all of a client's layouts. It also lets the server delete a deviceid via CB_NOTIFY_DEVICEID. It does not provide a mechanism for the metadata server to recall, in a single operation, all layouts that reference a specific deviceid. This document presents an extension to RFC7862 that adds a deviceid-scoped layout recall: a single CB_LAYOUTRECALL operation recalls every layout a client holds that references a given deviceid, leaving unrelated layouts in place. Without this capability, device unavailability can trigger large volumes of failed WRITE and LAYOUTERROR traffic, and administrators lack a surgical way to retire a deviceid without disturbing layouts that reference healthy devices. |
| | AI Network for Training,Inference,and Agentic Interactions |
| |
|
Artificial Intelligence (AI) is rapidly transforming industries and everyday life, fueled by advances in model architectures, training paradigms, and data infrastructure for generation and consumption. However, the effectiveness and reliability of AI depend on two foundational processes: training and inference. Each process introduces unique challenges related to data management, computation, connectivity, privacy, trust, security, and governance. In this draft, we introduce the Data and Agent Aware-Inference and Training Network (DA-ITN)—a unified, intelligent, multi-plane framework designed to address the full spectrum of requirements needed to enable various services and interactions within the AI ecosystem. DA-ITN provides a scalable and adaptive infrastructure that connects AI clients, data providers, model providers, agent providers, service facilitators, and computational resources to support end-to-end training, inference, and agentic interaction lifecycle operations. The architecture features dedicated control, data, and operations & management (OAM) planes to ensure reliability, transparency, and accountability between interacting parties. The proposed framework is not intended for end-to-end standardization, but is intended to serve as a reference framework for the AI ecosystem of the future. Various protocols for the different building blocks shall be defined to enable different functionalities. |
| | HJS: Accountability Receipts for AI Agents A Minimal JEP Profile for Exportable AI Receipts |
| |
|
This document defines HJS, a minimal accountability receipt infrastructure for AI agents. HJS is a profile of the Judgment Event Protocol (JEP) and does not define an independent event signing protocol. HJS uses JEP events to bind signed event claims to AI-agent behavior records, receipt manifests, optional privacy-preserving human participant references, and optional deployment-specific evidence references. The HJS core is intentionally small. It defines behavior-record digest binding, receipt manifests, receipt bundles, and validation of cryptographic and structural consistency. All other capabilities, including human privacy modes, participant-supplied references, post- event review references, explanation-material references, risk descriptors, model evidence, tool-call evidence, policy-check evidence, multi-party export, and cryptographic capability profiles, are optional extensions or deployment profiles. HJS is infrastructure. It does not assign legal liability, prove subjective intent, define governance rules, enforce monitoring, define fairness, define appeal rights, define explanation rights, determine authorization validity, or establish regulatory compliance. |
| | Co-Evolve Binding Profile (CEP) A JEP/HJS Profile for AI Evolution-Change Evidence Binding |
| |
| | draft-wang-cep-01.txt |
| | Date: |
29/04/2026 |
| | Authors: |
yuqiang wang |
| | Working Group: |
Individual Submissions (none) |
|
This document defines the Co-Evolve Binding Profile (CEP) v0.5, an optional profile for binding AI evolution-change records to external anchor references, evidence descriptors, and exportable receipt bundles. CEP is designed for use with the Judgment Event Protocol (JEP) and Human Judgment Structure (HJS), and can be combined with other JEP-based profiles such as JAC and COE. CEP provides infrastructure for creating, binding, exporting, and validating evidence about declared AI evolution-change claims. CEP does not determine human sovereignty, AI alignment, governance authority, model safety, legal compliance, fairness, appeal rights, explanation rights, or whether an AI evolution event is permitted or prohibited. CEP follows a minimal-core design. The core defines evolution-change record digest binding, external anchor references, evidence references, receipt bundles, and structural validation. Change classifications, binding claims, review references, rollback or mitigation references, multi-party export, and determinability reports are optional extensions or deployment profiles. |
| | CTP/0: Cognitive Time Protocol -- Definition and Framework |
| |
|
This document describes CTP/0, the definition layer of the Cognitive Time Protocol (CTP) family. CTP/0 is a conceptual reference framework for representing, comparing, and referencing time-related claims in AI and agent systems. It defines terminology for cognitive events, event-density claims, ordering claims, branching claims, and declared emergent temporal-structure claims. CTP/0 does not define a wire protocol, message format, signature format, hash-chain format, governance process, physical theory of time, theory of consciousness, or legal accountability framework. Where verifiable records are needed, CTP-compatible claims can be bound to external event or receipt infrastructure such as JEP, HJS, JAC, COE, or CEP. This revision narrows the original CTP/0 draft to an informational framework. Metrics such as Cognitive Event Density (CED), Causal Arrow Entropy (CAE), Verifiable Delay Function (VDF) evidence, and time-related evidence chains are treated as optional claim or evidence profiles, not as universal measures of intelligence, cognition, truth, safety, or responsibility. |
| | JAC: Declared Dependency Chains for Agent Receipts A JEP/HJS Extension Profile for Chain Infrastructure |
| |
| | draft-wang-jac-02.txt |
| | Date: |
29/04/2026 |
| | Authors: |
yuqiang wang |
| | Working Group: |
Individual Submissions (none) |
|
This document defines JAC v0.5, a minimal declared-dependency chain infrastructure for agent and AI-agent receipt systems. JAC is a profile over the Judgment Event Protocol (JEP) and, when AI-agent behavior receipts are used, over HJS. JAC does not define an independent event format, signature syntax, hash format, replay mechanism, identity framework, or governance framework. JAC uses JEP extension fields to bind a signed event or receipt element to a declared parent dependency. The core is intentionally small: a single chain extension records a declared dependency link. Optional extensions can record state declarations, assignment references, handoff references, result references, capability claims, input/output references, and declared chain breaks. JAC provides infrastructure only. It records signed dependency declarations; it does not determine factual causality, responsibility, fault, authorization validity, assignment validity, handoff validity, task correctness, fairness, entitlement, legal effect, or regulatory compliance. |
| | Cognition-Oriented Emergence (COE): A JEP Profile for Shared Observation and State-Claim Evidence |
| |
| | draft-wang-coe-01.txt |
| | Date: |
29/04/2026 |
| | Authors: |
yuqiang wang |
| | Working Group: |
Individual Submissions (none) |
|
This document defines Cognition-Oriented Emergence (COE) v0.5, an optional profile of the Judgment Event Protocol (JEP) for binding observation records, validation records, shared-state claims, and evidence references across heterogeneous world models and cognitive units. COE provides verifiable shared-observation infrastructure. It does not determine objective world truth, factual causality, governance consensus, legal effect, operational authority, fairness, trust weights, or compliance. A valid COE record proves cryptographic binding and structural consistency of declared observations, validations, state claims, and evidence references. It does not prove that a shared-state claim is true, complete, uniquely determined, or sufficient for any external target fact. COE follows a minimal-core design. The core defines JEP-based record binding and validation. State-synthesis policies, consensus methods, version anchoring, timestamp anchoring, determinability reports, adapter records, and multi-party evidence views are optional extensions or deployment profiles. |
| | In-Band SCONE Reporting over QUIC |
| |
|
The SCONE protocol relies on the receiver of SCONE packets to send bandwidth estimates back to the sender via unspecified application- layer messages. In some cases, a peer might have SCONE receive capability at the QUIC layer but not implement the necessary application level functionality. A new QUIC frame that directly reports the contents of received SCONE packets can address these use cases. There are no changes in the interaction with SCONE Network Elements. |
| | Enhanced Collapse Purity Filter Algorithm for Quantum Key Distribution |
| |
|
This document specifies an enhanced Collapse Purity Filter (CPF) algorithm for Quantum Key Distribution (QKD) systems. The enhanced CPF algorithm improves key generation efficiency by 100% compared to conventional CPF implementations while maintaining quantum security guarantees. The algorithm uses adaptive filter verification instead of fixed threshold filtering, achieving near-zero Quantum Bit Error Rate (QBER) in ideal conditions and accurate eavesdropping detection in adversarial scenarios. This specification is compatible with BB84 protocol and complies with Korean Internet Security Agency (KISA) standards TTAK.KO-12.0281 for quantum key distribution protocols. |
| | FLAIR: Framework for Language-Agnostic Discovery of Cryptographic Elements using Semantic Graphs |
| |
|
This document introduces FLAIR (Framework for Language-Agnostic Intermediate Representation), a novel approach to discover cryptographic elements in source code. By detecting encryption components present in code, FLAIR addresses critical challenges like identifying deprecated and misconfigured implementations across diverse programming languages. Unlike language-specific tools, FLAIR employs semantic graphs to represent instances of encryption detected, enabling identification of cryptographic algorithm usage, associated parameters (keys, nonces, salts), and flag compliance status with established encryption standards. The semantic graph approach makes representing cryptographic algorithms and related elements independent of the underlying programming language. |
| | FLAIR: Framework for Language-Agnostic Discovery of Cryptographic Elements using Semantic Graphs |
| |
|
This document introduces FLAIR (Framework for Language-Agnostic Intermediate Representation), a novel approach to discover cryptographic elements in source code. By detecting encryption components present in code, FLAIR addresses critical challenges like identifying deprecated and misconfigured implementations across diverse programming languages. Unlike language-specific tools, FLAIR employs semantic graphs to represent instances of encryption detected, enabling identification of cryptographic algorithm usage, associated parameters (keys, nonces, salts), and flag compliance status with established encryption standards. The semantic graph approach makes representing cryptographic algorithms and related elements independent of the underlying programming language. |
| | A Prio Instantiation for Vector Sums with an L1 Norm Bound on Contributions |
| |
|
A Prio Verifiable Distributed Aggregation Function is defined that supports vector or histogram addition, where the sum of the values in the contribution is less than a chosen value. |
| |
|
| |
| | Integration of Remote Attestation with Key Negotiation and Key Distribution mechanisms |
| |
|
This document describes a generic way to integrate Remote Attestation (RA) with key distribution and key negotiation, so that cryptographic keys are only released to or accepted from attested and policy- compliant environments. It defines an attestation-bound key management mechanism that can be applied on top of existing secure channel and key management protocols, and illustrates it with three representative scenarios: public-cloud KMS, end-user to AI data- center communication, and enterprise-operated KMS. A format-agnostic key binding claim is introduced to express the binding between an Attester’s environment, its public keys, and a session identifier, enabling Relying Parties to use Attestation Results as an input to key distribution and key agreement decisions without changing underlying protocols. |
| | Hardware Attestation for Email Sender Verification |
| |
|
This document defines a mechanism for automated email senders (AI agents, bots, and autonomous systems) to include hardware attestation evidence in message headers, enabling receiving mail servers to cryptographically verify that the sending system has access to a genuine hardware security component -- such as a Trusted Platform Module (TPM), a PIV smart card (e.g., YubiKey), a virtual TPM, or a software-managed key -- from a known manufacturer or issuer. The attestation proves hardware presence, not message composition locale. The verification chain runs from the email header to a manufacturer's root Certificate Authority (for hardware-backed attestation) or to an issuer's verification key (for issuer-certified attestation). Each automated sender is assigned a persistent agent identity, expressed as a URN in the "aid" (Agent Identity) namespace ([RFC8141]), enabling federated issuance by multiple independent identity providers and persistent reputation tracking across protocols and platforms. As a companion mechanism, this document defines a privacy-preserving alternative using SD-JWT (Selective Disclosure JWT, [RFC9901]) where the sender can prove specific claims about their hardware trust level without revealing their hardware identity. Together, these mechanisms provide both Sybil-resistant authentication and a foundation for reputation building: each identity requires a unique hardware security component, making large- scale automated abuse economically infeasible regardless of advances in artificial intelligence, while the persistent hardware-anchored identity enables receiving systems to accumulate trust signals over time. Software-only agents MAY participate at a lower trust tier, building reputation from an initial baseline rather than from a hardware-anchored starting point. While this document specifies these mechanisms for email message headers, the attestation formats defined herein -- both the CMS attestation bundle and the SD-JWT trust proof -- are self-contained, transport-independent data structures applicable to HTTP headers, agent-to-agent messaging, payment authorisation, and other Internet protocols. |
| | Requirements for the Discovery of Agents,Workloads,and Named Entities (DAWN) |
| |
|
The proliferation of distributed systems, Artificial Intelligence (AI) agents, cloud workloads, and network services has created a need for interoperable mechanisms to discover entities across administrative and network boundaries. Entities may include AI agents, software services, compute workloads, and other named resources that need to be found and characterised before interaction can begin. This document defines the requirements for Discovery of Agents, Workloads, and Named Entities (DAWN) and sets out the objectives that a discovery mechanism for such entities must satisfy. It describes what information must be discoverable, what properties a discovery mechanism needs to support, and what constraints apply to discovery in decentralised environments. This document does not specify any particular discovery protocol or solution. |
| | Gateway Capability Directory and Synchronization for Internet of Agents |
| |
|
This document describes a gateway capability-directory framework for the Internet of Agents (IoA) in deployments that use Agent Gateways. In such deployments, a gateway-managed capability directory is a necessary control-plane function for maintaining validated capability information beyond transient advertisements, static endpoint bindings, or external descriptions alone. This document defines requirements and a common object model for gateway-managed capability information, including the Agent Capability Specification (ACS), Capability Digest, and directory entry lifecycle. It also specifies synchronization, freshness, provenance, and validation requirements for capability information exchanged across gateways. This document clarifies the relationship between gateway-managed ACS objects and externally published descriptions such as the A2A Agent Card, and briefly compares this framework with broader distributed directory-service approaches. It does not define a discovery query protocol, ranking algorithm, storage substrate, distributed lookup algorithm, task orchestration protocol, or agent-to-agent session protocol. It can inform subsequent DMSC protocol work, including capability digest synchronization and related gateway procedures. |
| | API Index (APIX): A Global Discovery Infrastructure for Autonomous Agent Services |
| |
|
This document, draft-rehfeld-bot-service-index-08, is superseded by three successor Internet-Drafts that together constitute the APIX specification suite: * draft-rehfeld-apix-core-00 — Core infrastructure, trust model, and Index API * draft-rehfeld-apix-services-00 — Web API and bot service registration profile * draft-rehfeld-apix-iot-00 — IoT device service registration profile Readers are directed to those documents. This revision exists solely to document the supersession and to note two trust model updates that diverge from prior revisions. |
| | Agentic Reasoning Protocol (ARP) Version 2.0 |
| |
|
This document defines the Agentic Reasoning Protocol (ARP) version 2.0, a machine-readable protocol enabling entities (brands, organizations, persons) to publish self-attested context, verified factual corrections, domain expertise, and recommendation boundaries directly to autonomous AI agents, RAG (Retrieval-Augmented Generation) pipelines, and agentic AI systems. ARP v2.0 extends the static file model of v1.x with a live REST API, bidirectional feedback channels, multi-party cryptographic attestation, W3C Decentralized Identifier (DID) anchoring, Agent-to- Agent (A2A) trust handshakes, event-driven freshness via Server-Sent Events, and first-class internationalization support. ARP complements existing web conventions (robots.txt [RFC9309], schema.org, llms.txt) but is specifically designed for the reasoning behavior of modern AI agents -- systems that do not merely index content but synthesize, infer, and make decisions on behalf of users. All examples in this document use example.com and "Example Organization" per [RFC2606] and are purely illustrative. |
| | Updates to OAuth 2.0 JSON Web Token (JWT) Client Authentication and Assertion-Based Authorization Grants |
| |
| | draft-ietf-oauth-rfc7523bis-11.txt |
| | Date: |
28/04/2026 |
| | Authors: |
Michael Jones, Brian Campbell, Chuck Mortimore, Filip Skokan |
| | Working Group: |
Web Authorization Protocol (oauth) |
|
This document updates RFC7521, RFC7522, RFC7523 and RFC9126 with respect to the treatment of audience values in OAuth 2.0 Client Assertion Authentication and Assertion-based Authorization Grants to address a security vulnerability identified in the previous requirements for those audience values in multiple OAuth 2.0 specifications. |
| | RSVP Cryptographic Authentication,Version 2 |
| |
|
This document provides an algorithm-independent description of the format and use of RSVP's INTEGRITY object. The RSVP INTEGRITY object is widely used to provide hop-by-hop integrity and authentication of RSVP messages, particularly in MPLS deployments using RSVP-TE. This document obsoletes both RFC2747 and RFC3097. |
| | RSVP Cryptographic Authentication with HMAC-SHA2 |
| |
|
This document specifies the use of the US NIST Secure Hash Standard in the Hashed Message Authentication Code (HMAC) mode with RSVP Cryptographic Authentication version 2. Along with draft-ietf-teas- rsvp-auth-v2, this document obsoletes RFC2747 and RFC3097. |
| |
|
| |
| | The IPv6 Loopback Address Prefix |
| |
|
{ *Editor's note:* This document requests the allocation of a new IPv6 address prefix to be used for loopback instead of expanding into the existing ::/96. The specific prefix to be allocated is TBD/96, and the document updates the relevant RFCs and IANA registries to reflect this change. } This document updates the IP Version 6 Address Architecture to expand the size of the IPv6 loopback space from a single address to a /96 prefix. This change allows for a much larger number of loopback addresses in IPv6, which can be used for inter-process communication within a host and for network diagnostics. The document also updates the IANA IPv6 Address registry and the IPv6 Special Purpose Address registry to reflect this change. It updates RFC4291 to reflect the new loopback prefix and its functional semantics. |
| | Security and Privacy Considerations for Multicast Transports |
| |
|
Interdomain multicast has unique potential to solve delivery scalability for popular content, but it carries a set of security and privacy issues that differ from those in unicast delivery. This document analyzes the security threats unique to multicast-based delivery for Internet and Web traffic under the Internet and Web threat models. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/squarooticus/draft-krose-multicast-security. |
| | The MyClerk Protocol: Tiered Security Communication for Distributed Family Systems |
| |
|
This document specifies the MyClerk Protocol, a tiered-security communication protocol designed for distributed family orchestration systems. The protocol provides six security tiers ranging from 1-byte minimal overhead for tunneled messages to 144-byte full security for critical operations. It supports multiple transport mechanisms including NATS, Matrix, WebSocket, and direct TCP, while maintaining end-to-end encryption using ChaCha20-Poly1305 AEAD with hybrid post-quantum key establishment combining ML-KEM-768 and X25519. A classical-only mode (X25519 without ML-KEM) remains available for resource-constrained devices and legacy interoperability. The protocol is transport-agnostic, federation-capable, and optimized for environments ranging from resource-constrained IoT devices to full-featured desktop clients. |
| | EDNS options for filtering information |
| |
|
This memo documents EDNS options and methods that can be used to return information about filtered, blocked, or censored DNS responses. It complements the information provided in EDNS Extended DNS Error options [RFC8914]. |
| | OAuth 2.0 Agent Authorization Explicit Revocation |
| |
|
The OAuth 2.0 Token Revocation mechanism defined in RFC 7009 enables clients to notify authorization servers that a token is no longer needed. However, that mechanism is limited to single-token operations and does not support batch revocation, cascade propagation, or context-aware semantics at the agent level. With the emergence of autonomous systems and cross-domain agent networks, authorization servers require more granular, traceable revocation semantics. This document defines an agent-based explicit revocation extension, introducing new endpoints, request/response formats, and coordination protocols to support batch revocation based on agent IDs, cascade propagation, conditional revocation, and verifiable audit trails. |
| | Emoji-Based Notation for IPv6 Addresses |
| |
|
This document defines an alternative textual representation of IPv6 addresses using Unicode Emoji characters (hereinafter "Smileys") in place of hexadecimal digits. The proposed format, known as EmojiNotation6 (EN6), aims to make IPv6 addresses more expressive, more human-friendly, and significantly more fun at parties. Additionally, this document specifies a MANDATORY content- classification prefix using the AUBERGINE character (U+1F346) for addresses serving adult content, hereafter referred to as the "Eggplant Requirement". |
| | Zero-Trust Intent Protocol (ZTIP) |
| |
|
The Zero-Trust Intent Protocol (ZTIP) defines three primitives for verifiable delegation, intent binding, and behavioral attestation in multi-agent systems: |
| | Zero-Trust Negotiation Protocol (ZTNP) |
| |
|
The Zero-Trust Negotiation Protocol (ZTNP) specifies a session-scoped trust negotiation protocol for software-layer security and governance posture. ZTNP defines how a Relying Party challenges a counterparty for a signed posture credential, evaluates local policy against it, and issues a short-lived, channel-bound, scoped authorization artifact (a Permit) gating subsequent operations within the session. ZTNP covers three phases: * *Enrollment*, in which a Prover obtains a signed Posture Assertion from an Issuer that has assessed it against a publicly-identified security framework. * *Negotiation*, in which the Requester issues a session challenge, receives the Prover's Posture Assertion bound to that challenge, evaluates local policy against it, and either issues a Permit or returns a structured denial. * *Validation*, in which subsequent operations within the session are gated against the Permit, with mandatory channel binding when the transport is TLS. The protocol's central design choice is to anchor the meaning of trust claims to a publicly-identified security framework (e.g., NIST AI RMF 1.0, ISO/IEC 42001) rather than to a specific Issuer. A policy expressing "require tier 3 against framework X" is portable across any Issuer that attests against framework X. ZTNP is independent of any particular attestation pipeline. Posture Assertions MAY be derived from RATS Attestation Results [RFC9334], from compliance audit programs, from automated governance scanners, or from any other Issuer evaluation methodology that meets the format requirements of Section 5. ZTNP is *not* a RATS consumption profile; Section 1.5 describes how ZTNP composes with RATS-pipelined and non- RATS-pipelined deployments alike. Multi-principal delegation, prompt-injection-resistant intent binding, and behavioral-claim extensions are specified in a companion document, the Zero-Trust Intent Protocol (ZTIP) [I-D.miller-ztip]. This draft is an individual submission. The author intends to progress this work in a venue scoped to attestation-gated session authorization; possibilities include OAuth, WIMSE, SAAG-routed new work, or an Independent Submission. Community guidance on venue is welcome. |
| | Validity of SR Policy Candidate Path |
| |
|
An SR Policy comprises one or more candidate paths of which at a given time one and only one may be active (i.e., installed in forwarding plane and usable for steering of traffic). Each candidate path, in turn, may have one or more segment lists of which one or more may be active. When multiple segment lists are active, traffic is load balanced over them. Currently, a candidate path is valid as long as at least one of its segment lists is active. However, this default validity criterion does not meet the requirements of some scenarios. This document defines the new candidate path validity criterion. |
| |
|
| |
| | Multicast Redundant Ingress Router Failover |
| |
|
This document is intended to serve as a guide for multicast network operators of various replication technologies to evaluate the options and tradeoffs in deploying redundant ingress router failover. Section 5 of RFC9026 details the hot root standby solution for MVPN networks. Here we attempt to extend the discussion to cover additional multicast deployment solutions beyond MVPNs. This document compares cold, warm, and hot standby modes, listing their advantages, limitations and deployment considerations to help identify the appropriate solution for any network. |
| | The Incident Detection Message Exchange Format version 2 (IDMEFv2) |
| |
|
The Incident Detection Message Exchange Format version 2 (IDMEFv2) defines a data representation for security incidents detected on cyber and/or physical infrastructures. 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 draft is maintained by the IDMEFv2 Task Force. Please consult our website for more information: https://www.idmefv2.org. If approved this draft will obsolete RFC4765. |
| | Enhancing ICMPv6 Error Message Authentication Using Challenge-Confirm Mechanism |
| |
|
The Internet Control Message Protocol for IPv6 (ICMPv6) is essential for network diagnostics but is vulnerable to off-path spoofing attacks, especially when error messages relate to stateless transport protocols like UDP. An attacker can forge these messages to degrade performance or enable Man-in-the-Middle attacks. This document proposes a robust, stateless challenge-response mechanism to authenticate ICMPv6 error messages. Traditional stateful challenge mechanisms are vulnerable to state-exhaustion Denial-of-Service (DoS) attacks. To avoid this, the proposed solution is inspired by TCP SYN-Cookies, eliminating the need to store per-challenge state by using cryptographic computation. It limits state management to minimal flags on existing sockets or a bounded probabilistic data structure. This approach effectively authenticates ICMPv6 error messages while inherently resisting both off-path spoofing and state-exhaustion DoS attacks, thus improving the robustness of ICMPv6. |
| | Enhancing ICMP Error Message Authentication Using Challenge-Confirm Mechanism |
| |
|
The Internet Control Message Protocol (ICMP) is essential for network diagnostics but is vulnerable to off-path spoofing attacks, especially when error messages relate to stateless transport protocols like UDP. An attacker can forge these messages to degrade performance or enable Man-in-the-Middle attacks. This document proposes a robust, stateless challenge-response mechanism to authenticate ICMP error messages. Traditional stateful challenge mechanisms are vulnerable to state-exhaustion Denial-of- Service (DoS) attacks. To avoid this, the proposed solution is inspired by TCP SYN-Cookies, eliminating the need to store per- challenge state by using cryptographic computation. It limits state management to minimal flags on existing sockets or a bounded probabilistic data structure. This approach effectively authenticates ICMP error messages while inherently resisting both off-path spoofing and state-exhaustion DoS attacks, thus improving the robustness of ICMP. |
| | MyClerk Protocol Application Operations Registry |
| |
|
This document defines the application-layer operation codes for the MyClerk Protocol. It serves as the authoritative registry for operation codes in the 0x0700-0x1DFF range, covering knowledge management, settings, messaging, telephony, calendar, tasks, smart home, automation, AI assistant, synchronization, orchestration, presence, health, location, plugins, mobile device management, legal documents, mobility, travel, audit, audio pipeline, and desktop client operations. This companion document follows the "Assigned Numbers" pattern established by Bluetooth SIG specifications, separating the operation registry from the core protocol specification to allow independent evolution of application operations. |
| | Physically Annotated Causal Record (PACR): A Wire Format for Verifiable Causal Intervention Events |
| |
|
This document defines the Physically Annotated Causal Record (PACR), a wire-format protocol for representing one verifiable causal- intervention event between autonomous agents. A PACR is a six-tuple (ι, Π, Λ, Ω, Γ, P) binding a causal identity, a set of causal predecessors, a thermodynamic Landauer cost, an energy-time-space resource triple, a cognitive complexity split, and an opaque payload. The opaque payload optionally carries a one-byte intervention tag classifying the event under Pearl's do-calculus hierarchy (Observe / Do-Physical / Do-Digital / Do-Chemical / Do-Genetic / Counterfactual). PACR is intended as the smallest sufficient statistic for a replayable, rights-aware claim about a single causal step performed by an autonomous agent on a digital, physical, or biological substrate. It is complementary to AgentCard (draft-aevum-agentcard): AgentCard declares an agent's identity and capabilities; PACR records what an agent actually did and at what physical cost. PACR records form a content-addressed directed acyclic graph through their predecessor set. Causal order is determined solely by the predecessor edges; no wall-clock timestamp is required for ordering. This makes the format suitable for distributed multi-agent systems where clock skew and partial ordering are unavoidable. |
| |
|
| |
| | More Instant Messaging Interoperability (MIMI) using HTTPS and MLS |
| |
| | draft-ietf-mimi-protocol-06.txt |
| | Date: |
25/04/2026 |
| | Authors: |
Richard Barnes, Matthew Hodgson, Konrad Kohbrok, Rohan Mahy, Travis Ralston, Raphael Robert |
| | Working Group: |
More Instant Messaging Interoperability (mimi) |
|
This document specifies the More Instant Messaging Interoperability (MIMI) transport protocol, which allows users of different messaging providers to interoperate in group chats (rooms), including to send and receive messages, share room policy, and add participants to and remove participants from rooms. MIMI describes messages between providers, leaving most aspects of the provider-internal client- server communication up to the provider. MIMI integrates the Messaging Layer Security (MLS) protocol to provide end-to-end security assurances, including authentication of protocol participants, confidentiality of messages exchanged within a room, and agreement on the state of the room. |
| | BGP Extensions of SR Policy for Headend Behavior |
| |
|
[RFC8986] defines H. Encaps behavior, H. Encaps.Red behavior, H. Encaps.L2 behavior, and H. Encaps.L2.Red behavior for SR policy. This document defines extensions to Border Gateway Protocol (BGP) to distribute SR policies carrying headend behavior. |
| | Distribution of SR P2MP Policies and State using BGP-LS |
| |
|
This document specifies the extensions to BGP Link State (BGP-LS) to distribute SR P2MP Policies and state. This allows operators to establish a consistent view of the underlying multicast network state, providing an efficient mechanism for the advertisement and synchronization of SR P2MP policies. |
| | IGP Color-Aware Shortcut |
| |
|
IGP shortcut mechanism allows calculating routes to forward traffic over Traffic Engineering tunnels. This document specifies the enhancement of IGP shortcut which can steer routes onto TE-tunnels based on colors. |
| | Source IPv6 Address Programmability |
| |
|
IPv6-based tunneling technologies, such as SRv6, have been deployed by provider on transport networks to provide users with services such as VPN and SD-WAN. After the service traffic enters the provider's transport network, it will be encapsulated by tunnel (SRv6 encapsulation). In order to better meet the SLA requirements of users, some technologies need to carry relevant information along with the flow to guide the processing of packets during forwarding. This document discusses the programmability of IPv6 source addresses to carry the necessary flow information |
| | OSPF Adjacency Suppression |
| |
|
This document describes a mechanism for a router to instructs its neighbors to suppress advertising the adjacency to it until link- state database synchronization and LSA reoriginating are complete. This minimizes transient routing disruption when a router restarts from unplanned outages. |
| | Multiple Hop Unaffiliate BFD |
| |
|
The Bidirectional Forwarding Detection (BFD) is a fault detection protocol designed to rapidly identify communication failure between two forwarding engines. This document suggests utilizing BFD Echo when the local system supports BFD, but the neighboring system does not. BFD Control packets and their processing procedures can be executed over the BFD Echo port, where the neighboring system solely loops packets back to the local system. This document serves as an update to RFC 5880 and draft-ietf-bfd- unaffiliate-echo-10. |
| | SRv6 Anycast VPN Service |
| |
|
In some multihoming SRv6 L3VPN and EVPN scenarios, there are requirements for the egress PE to advertise both unicast and anycast SRv6 Service SIDs for the same service. This document defines anycast flavor for SRv6 Service SIDs carried in BGP messages. |
| | Peer Capability Update Notification in BGP Monitoring Protocol (BMP) |
| |
|
When BGP Dynamic Capability is supported, dynamic updates of capabilities are allowed over an established BGP session. At present, after the BGP session is established, the monitored router sends a BMP Peer Up Notification message first, containing the initial capabilities. If BGP Dynamic Capability is supported, using BMP Peer Up Notification messages to report subsequent capability changes for a BGP session becomes inappropriate. This document defines a new Peer Capability Update Notification message type in BMP to report peer capability changes. |
| | A Well-Known URI for Software Lifecycle Status |
| |
|
This document defines a Well-Known URI [RFC8615] at which software vendors and open-source maintainers may publish machine-readable lifecycle status information for their products. A JSON resource retrieved from /.well-known/software-status.json allows consumers — including security tools, software composition analysis (SCA) platforms, vulnerability scanners, and system administrators — to programmatically determine whether a specific version of a software product is actively supported, in long-term support (LTS), under security-only maintenance, or at end-of-life (EOL). This revision (-02) extends the schema to support multi-product vendors — organizations that ship multiple distinct products or SKUs under a single domain. A new optional products array at the root of the resource allows a single software-status.json endpoint to serve lifecycle declarations for an entire product catalog, including firmware-based devices such as routers, switches, and IoT appliances. This extension is fully backward compatible: existing single-product resources require no modification. This document also describes, in Appendix B (#appendix-b), a companion convention for open-source projects hosted on version- control platforms to publish equivalent information within the repository at .github/software-status.json. |
| | IPv7: Identity-Centric Network Protocol for Security,Proxy Mitigation,and Operability |
| |
|
This document specifies a network-layer protocol, IPv7, that extends the Internet Protocol model with an identity-carrying address form and an origin-validation mechanism intended to mitigate abuse of residential proxy infrastructure. IPv7 replaces purely numerical source addressing with a hierarchical identity string and a Variable- Length Identity Block (VLIB) that carries an Ephemeral Identity Token (EIT), provider and tenant identifiers, role/policy signalling, and an Origin Signature verifiable by the originating provider. The protocol enables routers to apply policy and reputation signals at the network layer while limiting disclosure of a subscriber's long- term identity to intermediate systems. This document addresses growing security challenges in Internet-connected devices (IoT), including smart TVs, appliances, and other residential endpoints that are vulnerable to residential proxy exploitation and botnet infection. |
| | The HONK Protocol: Word-Counting over TCP with Honk-Based Responses and Optional Obfuscation |
| |
|
This document defines the HONK protocol, a simple application-layer protocol operating over TCP. A HONK client submits a stream of UTF-8 encoded text terminated by a CRLF sequence, and the HONK server responds with a sequence of HONK tokens. The token count equals twice the number of whitespace-delimited words detected in the input. If no words are detected, the server responds with exactly three HONK tokens. The protocol includes an optional Privacy Mode in which message content is obfuscated using single-byte XOR with the fixed key value 0x48 (the ASCII code point for the letter H). This document requests that IANA assign TCP port 24565 to the HONK service. This document is an individual submission. It is NOT an April Fools Day publication. The author requests serious technical consideration from the IETF community. |
| |
|
| |
| | Signaling Composite Candidate Path of SR Policy using BGP-LS |
| |
|
SR Policy Architecture [RFC9256] defines the concept of a Composite Candidate Path. A regular SR Policy Candidate Path outputs traffic to a set of Segment Lists, while an SR Policy Composite Candidate Path outputs traffic recursively to a set of SR Policies on the same headend. This document specifies the extensions to BGP Link State (BGP-LS) to carry composite candidate path information in the advertisement of an SR policy. |
| | CNI Telco-Cloud Benchmarking Considerations |
| |
|
This document investigates benchmarking methodologies for Kubernetes Container Network Interfaces (CNIs) in Edge-to-Cloud environments. It defines performance, scalability, and observability metrics relevant to CNIs, and aligns with the goals of the IETF Benchmarking Methodology Working Group (BMWG). The document surveys current practices, introduces a repeatable benchmarking frameworks (e.g., CODEF), and proposes a path toward standardized, vendor-neutral benchmarking procedures for evaluating CNIs in microservice-oriented, distributed infrastructures. |
| | Server Monitoring of Merkle Tree Certificates |
| |
|
This document describes a system for site operators to monitor for mis-issued Merkle Tree Certificates affecting their websites. This monitoring is highly efficient, requiring site operators to do an amount of work that is only logarithmic proportional to the total number of certificates issued. It does this while preserving the security and transparency guarantees of Merkle Tree Certificates. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/Bren2010/draft-server-monitoring. |
| | SURADAR: Context-Bound Per-Request Authentication for Machine-to-Machine APIs |
| |
|
This document defines SURADAR (Subsurface Undertow RADAR), an HTTP authentication scheme in which each request is authenticated by a one-time HMAC tag derived from a shared seed, the current time band, and the full request context (method, path, organisation, scope, and body). Unlike bearer-token schemes, a captured SURADAR token is cryptographically bound to exactly one request and cannot be reused, replayed, or re-scoped. The protocol requires zero per-request handshakes, produces 48-byte tokens, and relies solely on HMAC- SHA-256 and SHA-256 -- no asymmetric cryptography. |
| | PEDIGREE: Verifiable Delegation Identity for Agentic AI Systems |
| |
|
This document defines PEDIGREE (Per-Agent Delegation Identity with Governance-Enforced Execution), an identity and delegation framework for AI agents that extends the workload-identity model of SPIFFE (RFC 9542 / draft-ietf-wimse) with cryptographic per-hop delegation, monotonic scope attenuation enforced at mint and at verify, and dual- layer authority enforcement combining an operator-controlled ceiling with per-parent mandate narrowing. PEDIGREE complements AAuth (draft-hardt-aauth-protocol) and AIP (draft-prakash-aip) by providing: (a) dual-enforcement semantics absent from both, (b) Cedar-policy mandates with static-analysis proofs of narrowing, (c) strict cryptographic parent-token re- verification that catches parent-swap attacks missed by append-only token chains, and (d) a native bridge to existing SPIFFE deployments. |
| |
|
| |
| | The DRIP DET public Key Infrastructure |
| |
|
The DRIP Entity Tag (DET) public Key Infrastructure (DKI) is a specific variant of classic Public Key Infrastructures (PKI) where the organization is around the DET, in place of X.520 Distinguished Names. Further, the DKI uses DRIP Endorsements in place of X.509 certificates for establishing trust within the DKI. There are two X.509 profiles for shadow PKI behind the DKI, with many of their X.509 fields mirroring content in the DRIP Endorsements. These PKIs can at times be used where X.509 is expected and non- constrained communication links are available that can handle their larger size. It is recommended that a DRIP deployment implement both of these along side the Endorsement trees. C509 (CBOR) encoding of all X.509 certificates are also provided as an alternative for where there are gains in reduced object size. |
| | YANG Model for IS-IS Protocol Implementation Conformance Statement (PICS) |
| |
|
The YANG model in this document is to be used to query an IS-IS Protocol Implementation Conformance Statement (PICS). |
| | YANG Data Model for IS-IS L2 Bundle Member Link Attributes PICS |
| |
|
The YANG model in this document is to query an IS-IS Protocol Implementation Conformance Statement (PICS) of advertising Layer 2 Bundle Member Link Attributes. |
| | YANG Data Model for IS-IS Segment Routing MPLS PICS |
| |
|
The YANG model in this document is to query an IS-IS Protocol Implementation Conformance Statement (PICS) of Segment Routing on MPLS data plane. |
| | IGP Flex Soft Dataplane |
| |
|
Advertisement of IGP Flex-Algo participation requires a dataplane context. This document defines a "soft dataplane" usable in cases where existing defined dataplanes are not suitable. |
| | Aircraft to Anything AdHoc Broadcasts and Session |
| |
|
Aircraft-to-anything (A2X) communications are often single broadcast messages that to be trustable, need to be signed with expensive (in cpu and payload size) asymmetric cryptography. There are also frequent cases of extended exchanges between two devices where trust can be maintained via a lower cost symmetric key protect flow. This document shows both how to secure A2X broadcast messages with DRIP Entity Tags (DET) and DRIP Endorsement objects and to leverage these to create an AdHoc session key for just such a communication flow. There is also provision for DETs within X.509 certificates, encoded in c509, as an alternative DET trust model. |
| | Secure UAS Stateless Network RID |
| |
|
This document defines a stateless transport mechanism and message content between an Uncrewed Aircraft System (UAS) and its UAS Service Supplier (USS) for Network Remote ID (Net-RID) messages. It leverages the Broadcast Remote ID (B-RID) messages as constructed by the UA, or constructed by the Ground Control Station (GCS) from the Command-and-Control (C2) messages that are then sent directly over UDP from the UAS. These messages are authenticated by the DRIP Authentication messages if originating from the UA. When originating from the GCS, CBOR Web Tokens (CWT) signed by the GCS's DRIP Entity Tag (DET), are used. Transport privacy is out-of-scope in this approach per the stateless design. Some proposals are offered for data privacy that require some minimal state. |
| | Automatic Network Congestion Relief in GeneRic Autonomic Signaling Protocol (GRASP) |
| |
|
This draft defines new autonomic technical objectives for automatic congestion relief using the Grasp protocol acording to the [RFC 9222]. In operator networks, network devices can automatically respond and achieve real-time self-healing for network failures such as fiber optic cable faults and optical module malfunctions |
| | Policy-Controlled Handling of URLs in MIME Messages |
| |
|
This document defines a MIME-based mechanism for policy-controlled handling of URLs in email messages. The mechanism provides an alternative to hyperlink rewriting techniques used for click-time security enforcement. By avoiding modification of original URLs and introducing policy metadata, this approach improves interoperability, preserves message integrity, and enhances privacy. |
| | Fluid Agentic DeFi Protocol (FADP/1.0): HTTP-Native Micropayment Authentication for Autonomous AI Agents |
| |
|
This document defines the Fluid Agentic DeFi Protocol (FADP), version 1.0. FADP is an application-layer protocol layered atop HTTP that enables autonomous AI agents to pay for access to web resources using on-chain cryptocurrency transfers, with cryptographic proof of payment embedded directly in HTTP headers. FADP extends HTTP 402 (Payment Required) with two new header fields: X-FADP-Required, which a server uses to communicate payment terms to an agent, and X-FADP-Proof, which an agent uses to supply a verifiable on-chain payment receipt. A nonce-challenge mechanism prevents proof replay. An optional verification endpoint allows third-party on-chain confirmation without requiring the verifying party to run blockchain infrastructure. FADP is designed for agent-to-server and agent-to-agent payment flows operating at sub-dollar granularity (micropayments), where credit- card or OAuth-based billing is impractical. The reference implementation targets USDC on Base (an Ethereum Layer 2), though the protocol is token- and chain-agnostic. |
| | Network-Infrastructure Hiding Protocol |
| |
|
The Network-Infrastructure Hiding Protocol (NHP) is a cryptography- based session-layer protocol designed to operationalize Zero Trust principles by concealing protected network resources from unauthorized entities. NHP enforces authentication-before-connect access control, rendering IP addresses, ports, and domain names invisible to unauthorized users. This document defines the protocol architecture, cryptographic framework, message formats, and workflow to enable independent implementation of NHP. It represents the third generation of network hiding technology—evolving from first- generation port knocking to second-generation Single-Packet Authorization (SPA) and now to NHP with advanced asymmetric cryptography, mutual authentication, and scalability for modern threats. This specification also provides guidance for integration with Software-Defined Perimeter (SDP), DNS, FIDO, and Zero Trust policy engines. |
| | Dotted Decimal notation for IPv6 addresses |
| |
|
This document defines a new canonical format for IPv6 addresses, that uses familiar dotted decimal notation. |
| |
|
| |
| | A YANG Data Model for WDM Tunnels |
| |
| | draft-ietf-ccamp-wdm-tunnel-yang-08.txt |
| | Date: |
22/04/2026 |
| | Authors: |
Aihua Guo, Sergio Belotti, Gabriele Galimberti, Universidad de Madrid, Daniel Burrero |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
|
This document defines a YANG data model for the provisioning and management of Traffic Engineering (TE) tunnels and Label Switched Paths (LSPs) in Optical Networks (Wavelength Switched Optical Networks (WSON) and Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks). The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA). |
| | CPace,a balanced composable PAKE |
| |
|
This document describes CPace which is a protocol that allows two parties that share a low-entropy secret (password) to derive a strong shared key without disclosing the secret to offline dictionary attacks. The CPace protocol was tailored for constrained devices and can be used on groups of prime- and non-prime order. |
| | CoAP over GATT (Bluetooth Low Energy Generic Attributes) |
| |
|
Interaction from computers and cell phones to constrained devices is limited by the different network technologies used, and by the available APIs. This document describes a transport for the Constrained Application Protocol (CoAP) that uses Bluetooth GATT (Generic Attribute Profile) and its use cases. |
| | Reclassifying ARC as Historic |
| |
|
This document calls for a conclusion to the experiment defined by “The Authenticated Received Chain (ARC) Protocol” [RFC8617], and recommends that ARC no longer be deployed or relied upon between disparate senders and receivers. The document summarizes what ARC set out to do, reports on operational experience, and explains how the experience gained during the experiment is being incorporated into the proposed DKIM2 work as the successor to DomainKeys Identified Mail [RFC6376]. To avoid any future confusion, it is therefore requested that ARC [RFC8617] be reclassified as “Historic”. |
| | Registry scoped members for RPSL set objects |
| |
|
This document updates RFC2622 and RFC4012 by specifying src-members, a new attribute on as-set and route-set objects in the Routing Policy Specification Language (RPSL). This attribute allows a specific registry to be defined for each member in a set, avoiding problematic ambiguity when resolving set members. A new validation rule allows gradual upgrades and backwards compatibility. |
| | Flowspec Indirection-id Redirect |
| |
|
This document defines a new extended community known as "FlowSpec Redirect to indirection-id Extended Community". This extended community triggers advanced redirection capabilities to flowspec clients. When activated, this flowspec extended community is used by a flowspec client to retrieve the corresponding next-hop and encoding information within a localised indirection-id mapping table. The functionality detailed in this document allows a network controller to decouple the BGP flowspec redirection instruction from the operation of the available paths. |
| | Adaptive Subscription to YANG Notifications |
| |
|
This document defines an experimental mechanism and its companion YANG data model to enable adaptive subscriptions to YANG notifications. The publisher can dynamically adjust the periodic update interval based on the evaluation of pre-configured conditions (e.g., thresholds or expressions). This allows for finer-grained telemetry by increasing update frequency when certain criteria are met, and reducing it otherwise. |
| | MIMI Identifiers |
| |
|
TODO Abstract |
| | HMAC Based Hybrid Key Combiners for Multiple Keys |
| |
|
As a fundamental building block in security protocols, a key combiner is used to combine two or more input cryptographic keys, some potentially compromised, into a single pseudorandom output key. Most of the existing key combiners are for two input keys. This draft specifies two provably secure constructions of key combiners for multiple keys [WWW25], which is particularly useful in post-quantum migration where multiple input keys may be produced by different algorithms or even different approaches [RFC9370], [ETSI25]. Namely, here the input keys can be two or more, and the combined output key remains pseudorandom if at least one of the input keys is secure, i.e., uniformly random and unknown to an attacker. The two constructions, called HKCv1 and HKCv2, are based on the extract-then- expand paradigm of HMAC (Keyed-Hashing for Message Authentication) [RFC2104]. HKCv1 is designed for simultaneously available input keys using concatenation, while HKCv2 is tailored for scenarios where input keys arrive incrementally, using an iterative HMAC structure. [EDNOTE: .... ] |
| | AIPREF Vocabulary Exclusions |
| |
|
This document proposes an update to the AI preferences vocabulary [VOCAB] in order to establish protected uses (exclusions). |
| | GSS-API Key Exchange with hybrid ML-KEM |
| |
|
This document specifies additions to RFC4462. It defines a new key exchange methods that use hybrid Post-Quantum Traditional (PQ/T) key exchange. The purpose of this specification is to modernize the cryptographic primitives used by Generic Security Service (GSS) key exchanges. |
| | AgentCard: A Framework-Neutral Identity and Capability Declaration Format for Agent-to-Agent Communication |
| |
|
This document defines AgentCard, a lightweight JSON data format that enables autonomous software agents to declare their identity, capabilities, communication endpoints, and resource pricing in a framework-neutral manner. AgentCard is designed for agent-to-agent (A2A) communication scenarios where agents built with different frameworks — such as LangChain, CrewAI, AutoGen, or custom implementations — must interoperate without prior coordination. An AgentCard is a pure data schema: it carries no execution logic and imposes no transport requirements. It is analogous to an HTTP response header set — a machine-parseable self-description that any compliant reader can interpret. Key properties of AgentCard include a globally unique ULID-based agent identity, dot-namespaced capability identifiers compatible with OpenAI function-calling and Model Context Protocol (MCP) tool schemas, a physics-grounded energy pricing floor derived from Landauer's principle, and an extensible metadata namespace for framework-specific annotations. |
| | BMP Extension for Monitoring Multiple BGP Instances |
| |
|
The BGP Monitoring Protocol (BMP), as defined in RFC 7854, provides a means for monitoring BGP sessions. In deployments where a single device runs multiple BGP instances simultaneously - typically a base instance together with one or more additional instances, each identified by an Instance Name and potentially running in a separate process with an independent Router-ID and Autonomous System (AS) number - the existing BMP message format does not allow a Monitoring Station to distinguish peers or routes belonging to different BGP instances on the same monitored router. This document defines a new BMP Type-Length-Value (TLV) element, the BGP Instance Name TLV, that carries the Instance Name of the BGP instance associated with a given peer or route. Following the TLV extension framework defined in [I-D.ietf-grow-bmp-tlv], the new TLV MAY appear in Peer Up Notification, Peer Down Notification, Route Monitoring, Statistics Report, and Route Mirroring messages. The TLV enables a Monitoring Station to unambiguously attribute monitored BGP information to the correct BGP instance on the monitored router. |
| | Multipath Support for IGMP/MLD Proxy |
| |
|
This document specifies the framework to support multipath reception in Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD) proxy devices. The proposed mechanism allows IGMP/ MLD proxy devices to receive multicast sessions/channels through different upstream interfaces. It defines static configuration methods for associating upstream interfaces with channel identifiers and interface priority values. A mechanism for upstream interface takeover that enables switching from an inactive to active upstream interface is also described. |
| | IPv6 Prefix Assignment to End-Sites |
| |
|
This document describes different alternatives and best current practices for assignment of IPv6 prefixes for end-sites in broadband networks, including considerations about point-to-point links, their size, numbering choices, pool choices, customer prefix assignment size and persistance of those assignments. |
| |
|
| |
| | Composite Module-Lattice-Based Digital Signature Algorithm (ML-DSA) for use in X.509 Public Key Infrastructure |
| |
| | draft-ietf-lamps-pq-composite-sigs-19.txt |
| | Date: |
21/04/2026 |
| | Authors: |
Mike Ounsworth, John Gray, Massimiliano Pala, Jan Klaussner, Scott Fluhrer |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
This document defines combinations of US NIST Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in hybrid with traditional algorithms RSASSA-PKCS1-v1.5, RSASSA-PSS, ECDSA, Ed25519, and Ed448. These combinations are tailored to meet regulatory guidelines in certain regions. Composite ML-DSA is applicable in applications that use X.509 or PKIX data structures that accept ML-DSA, but where the operator wants extra protection against breaks or catastrophic bugs in ML-DSA, and where existential unforgeability (EUF-CMA) level security is acceptable. |
| | Storing BMP messages in MRT Format |
| |
|
This document extends the Multi-threaded Routing Toolkit (MRT) export format to support the storage of BMP messages. |
| | Content-based IP-Multicast Grouping Framework for Real-time Spatial Sensing and Control Applications with Edge Computing |
| |
| | draft-akiyama-cmg-03.txt |
| | Date: |
21/04/2026 |
| | Authors: |
Kuon Akiyama, Ryoichi Shinkuma |
| | Working Group: |
Individual Submissions (none) |
|
This document describes a content-based multicast grouping framework aimed at simplifying routing control and reducing unnecessary traffic in large-scale networks for real-time spatial sensing and control applications. The framework introduces content-based multicast groups, which are managed at the local level by routers without the need for global group membership tracking. Additionally, a "topic" concept is introduced, allowing routers to manage multicast delivery based on data content. This framework reduces bandwidth consumption and simplifies multicast routing while offering flexible data delivery across various topics. |
| | BMP Snapshots |
| |
|
BMP (BGP Monitoring Protocol) is perfectly suited for real-time consumption but less ideal in stream processing and off-wire historical scenarios. The issue is that the necessary information to produce a complete view and enabling correct processing of all messages in the stream, is only sent out at the beginning of the BMP session. This document introduces the concept of BMP Snapshots, enabling BMP stations to synchronize mid-stream, and, providing the basis for self-contained, time-binned archiving of BMP data. |
| | KEM-based Authentication for EDHOC in Initiator-Known Responder (IKR) Scenarios |
| |
|
This document specifies a more efficient variant of a Key Encapsulation Mechanism (KEM)-based authentication method for the Ephemeral Diffie-Hellman Over COSE (EDHOC) lightweight protocol, designed for the specific scenario in which the Initiator has prior knowledge of the Responder’s credentials, a case commonly found in constrained environments. Improving upon the approach described in KEM-based Authentication for EDHOC, this method uses only a mandatory three-message handshake to enable signature-free post-quantum authentication when PQC KEMs, such as the NIST-standardized ML-KEM, are employed, while still providing mutual authentication, forward secrecy, and a degree of identity protection. |
| | RepSec: Post-Breach Data Neutralisation Protocol |
| |
|
This document introduces RepSec, a post-breach data neutralisation protocol designed to reduce the utility of exfiltrated or unauthorised data copies. RepSec operates independently of traditional perimeter and access-control security models by enforcing conditional data usability based on attestation and environmental integrity. The goal is to limit downstream exploitation, resale value, and operational impact of compromised data without disrupting legitimate use. |
| | Internet of Agents Task Protocol (IoA Task Protocol) for Heterogeneous Agent Collaboration |
| |
|
This draft defines a new agent collaboration protocol, named the Internet of Agents Task Protocol (IoA Task Protocol), to support distributed, heterogeneous agent collaboration in intelligent systems. The IoA Task Protocol enables dynamic team formation, adaptive task coordination, and structured communication among agents with diverse architectures, tools, and knowledge sources. Through a layered architecture and extensible message format, it supports decentralized deployment across devices and can interoperate with existing frameworks. The protocol is particularly suited to large- scale intelligent collaboration scenarios—such as intelligent transportation, smart healthcare, and large-scale human–AI teaming—across heterogeneous network environments, including fixed networks, edge–cloud infrastructures, and emerging mobile networks such as 6G. |
| | Policy,Lifecycle,and Intent Extensions for OAuth Rich Authorization Requests |
| |
|
OAuth 2.0 Rich Authorization Requests (RAR) [RFC9396] defines a syntax for clients to request fine-grained permissions. While powerful, this mechanism lacks standardized methods for clients to express three critical contextual dimensions prevalent in modern automated systems: the high-level user intent driving the request, the required security policy under which the request should be evaluated, and the binding of the authorization's lifecycle to an external process. This document extends the RAR framework to address these gaps. It first defines a new authorization_details type, *intent_request*, to facilitate goal-oriented authorization. Second, it introduces two new parameters for the authorization_details object: *policy_context*, to request authorization under a specific assurance level, and *lifecycle_binding*, to tie the validity of the authorization grant to the state of an external entity. These extensions enable authorization servers to make more intelligent, secure, and context-aware decisions, particularly in ecosystems involving autonomous agents and complex, long-running tasks. |
| | Ontology-based Semantic Interaction for Internet of Agents |
| |
|
This document specifies a normative semantic layer for agent-to-agent interaction in the Internet of Agents (IoA). The semantic layer provides a common ontology model and a JSON-LD serialization profile (RECOMMENDED), while allowing other RDF serializations for expressing capabilities, intents, tasks, and context. The document defines required classes and properties, a negotiation procedure, and alignment rules for heterogeneous ontologies. This layer is designed to be used by interaction and discovery protocols but does not define transport, session, or security protocols. It enables deterministic semantic interoperability across domains. |
| | A JSON-Based Format for Publishing IP Ranges of Automated HTTP Clients |
| |
|
This document defines a standardized JSON format for operators of automated HTTP clients (e.g., web crawlers, AI bots) to publicly disclose their IP address ranges. A consistent, machine-readable format for IP range publication simplifies the task of identifying and verifying legitimate automated traffic, thereby decreasing maintenance load on website operators while reducing the risk of inadvertently blocking beneficial clients. This specification codifies and extends common existing practices to provide a simple yet extensible format that accommodates a variety of use cases. |
| | Crawler best practices |
| |
|
This document describes best practices for web crawlers. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/garyillyes/cbcp. |
| | Zero Trust Attribute Assertion Tokens |
| |
|
This document defines a mechanism for verifying boolean eligibility claims using cryptographically signed assertion tokens. A relying party can verify authoritative answers to predefined claims without trusting the presenting subject and without learning the subject's identity. Each assertion token encodes exactly one boolean claim. The system guarantees authenticity and integrity of claim assertions. It does not provide identity, authentication, or subject uniqueness. |
| | Flowspec Indirection-id Redirect for SRv6 |
| |
|
This document defines extensions to "FlowSpec Redirect to indirection-id Extended Community" for SRv6. This extended community can trigger advanced redirection capabilities to flowspec clients for SRv6. When activated, this flowspec extended community is used by a flowspec client to retrieve the corresponding next-hop and encoding information within a localised indirection-id mapping table. The functionality detailed in this document allows a network controller to decouple the BGP flowspec redirection instruction from the operation of the available paths. |
| | Delegate SD-JWT |
| |
|
This document specifies an extension to Selective Disclosure JSON Web Tokens to support further delegation from the Holder to a Delegate Holder. This is done by allowing the Key Binding JWT to also be an SD-JWT, optionally with its own Key Binding. This has particular applicability to Agentic systems. |
| |
|
| |
| | BIER Prefix Redistribute |
| |
|
This document defines a BIER proxy function to support one single BIER sub-domain over multiple underlay routing protocol regions (Autonomous Systems or IGP areas). A new BIER proxy range sub-TLV is defined to redistribute BIER BFR-id information across the routing regions. |
| | Deterministic Nonce-less Hybrid Public Key Encryption |
| |
|
This document describes enhancements to the Hybrid Public Key Encryption standard published by CFRG. These include use of "compact representation" of relevant public keys, support for key-wrapping, and a way to address the use of HPKE on lossy networks |
| | Using BMP over QUIC connection |
| |
| | draft-ietf-grow-bmp-over-quic-00.txt |
| | Date: |
20/04/2026 |
| | Authors: |
Yisong Liu, Changwang Lin, Thomas Graf, Paolo Lucente, Mukul Srivastava |
| | Working Group: |
Global Routing Operations (grow) |
|
The BGP Monitoring Protocol (BMP) provides a convenient interface for obtaining route views by monitoring BGP sessions. BMP operates over TCP and is unidirectional (from client to server). QUIC provides multiple simultaneous streams to carry data in one direction, enabling much better efficiency and performance for both peers, in particular unidirectional streams can provide reverse data protection for the sender. QUIC also provides shorter handshake and includes TLS. This document describes how to use BMP over the QUIC transport protocol, named BMPoQUIC. |
| | JMAP Blob Management |
| |
|
The JSON Meta Application Protocol (JMAP) base protocol ([JMAP-CORE]) provides the ability to upload and download arbitrary binary data via HTTP POST and GET on a defined endpoint. This binary data is called a "blob". This extension adds additional ways to create and access blobs by making inline method calls within a standard JMAP request. It also adds a reverse lookup mechanism to discover where blobs are referenced within other data types, support for large blobs via chunked construction with server-side optimisation, and server-side blob conversion operations including image format conversion, archive creation and extraction, compression and decompression, and delta/ patch operations. |
| | Multicast in L3VPNs Signaled by EVPN SAFI |
| |
|
RFC9136 specifies an EVPN SAFI Type-5 route that can be used to signal L3VPNs. This document specifies procedures for multicast in such an L3VPN. |
| | Crowd Sourced Remote ID |
| |
|
This document describes using the ASTM Broadcast Remote ID (B-RID) specification in a "crowd sourced" smart phone or fixed receiver asset environment to provide much of the ASTM and FAA envisioned Network Remote ID (Net-RID) functionality. This crowd sourced B-RID (CS-RID) data will use multilateration to add a level of reliability in the location data on the Uncrewed Aircraft (UA). The crowd sourced environment will also provide a monitoring coverage map to authorized observers. |
| | BGP Flow Specification for Source Address Validation |
| |
|
BGP FlowSpec reuses BGP route to distribute infrastructure and propagates traffic flow information with filtering actions. This document proposes some extensions to BGP FlowSpec for disseminating SAV rules. |
| | Generative AI for Intent-Based Networking |
| |
| | draft-cgfabk-nmrg-ibn-generative-ai-02.txt |
| | Date: |
20/04/2026 |
| | Authors: |
Pietro Cassara', alberto_gotta, Giuseppe Fioccola, Aldo Artigiani, Riccardo Burrai, Emiljan Kolaj, Marco Martalo', Virginia Pilloni |
| | Working Group: |
Individual Submissions (none) |
|
This document describes how to specialize AI models in order to offer a scalable, efficient path to creating highly targeted generative models for Intent-Based Networking. |
| | Quantum-Native Architectural Tenets and Philosophy for the Quantum Internet |
| |
|
This document extends RFC 9340 by outlining a set of quantum-native architectural tenets for the design and evolution of the Quantum Internet. These principles should not be interpreted as dogmas, but as pragmatic guidelines and criteria for harnessing the unique properties of quantum entanglement within networked systems. Such design perspectives, while departing from the classical Internet, remain aligned with a foundational insight: the principle of constant change, articulated in RFC 1958. The document specifies quantum-native extensions to the Quantum Internet framework, defining an entanglement packet switching paradigm and an explicit separation between the Quantum Data Plane and Quantum Control Plane. It introduces Quantum Internet Addressing to extend quantum semantics into control and coordination, and generalizes the classical forwarding concept to quantum packets. |
| | DNS Extensions to Energy Efficiency as a Service(EEAS) |
| |
|
This document describes a new Mechanism and DNS resource record (RR) type to carry information about energy-related characteristics for end-to-end internet access. The "EE" ("Energy Efficiency") record allows the network to provide different levels of energy-saving service. By providing more energy information to the client before it attempts to establish a connection, these records offer potential benefits to enhancements on energy as service criteria. |
| | Proof-of-Behavior Protocol for Autonomous AI Agents |
| |
|
Autonomous AI agents execute actions — file writes, API calls, shell commands — on behalf of human principals. No standard mechanism exists for a third party to verify that an agent acted within its declared behavioral rules, that policy enforcement occurred before execution (not after), or that the action log has not been tampered with after the fact. This document defines the Proof-of-Behavior (PoB) protocol: a minimal, language-agnostic standard for tamper-evident audit trails and pre-execution policy enforcement in AI agent systems. The protocol specifies a signed receipt format, a hash-chain linking scheme, a policy gate contract, and a cross-agent reference mechanism. |
| | Woof |
| |
|
Woof woof woof woof Woof Woof Woof (WOOF). WOOF woof woof woof woof- bark woof woof woof Woof woof woof, woof woof woof woof woof woof woof woof woof woof woof woof woof Woof. Woof woof woof, bark woof woof woof woof woof woof woof WOOF woof woof woof woof woof WOOF WOOF, woof woof woof woof woof woof woof howl woof woof. Woof woof woof woof woof woof woof woof woof woof woof woof woof WOOF WOOF. Woof woof woof WOOF WOOF, woof woof woof Woof WOOF, WOOF, WOOF, WOOF, WOOF, woof WOOF woof woof woof woof WOOF WOOF. Woof woof Woof WOOF woof WOOF, woof woof woof woof woof woof boof woof woof woof woof woof woof woof woof woof WOOF woof. Woof woof woof WOOF WOOF woof woof arf woof woof woof woof woof woof woof woof WOOF-WOOF woof. Woof WOOF woof woof woof woof WOOF WOOF woof woof woof woof woof woof WOOF WOOF. |
| | HTTP Compliance Authorization Protocol (HCAP) |
| |
|
This document specifies the HTTP Compliance Authorization Protocol (HCAP), an extension to the HTTP authentication framework that allows resource providers to require demonstrable evidence of caller compliance with declared policies before granting access to protected resources. Callers obtain signed compliance credentials from a compliance registry by presenting evidence of their controls. Credentials are conveyed at the HTTP layer and verified offline by the provider. HCAP operates alongside existing authentication schemes (OAuth 2.0, mTLS) and does not replace identity authentication. It addresses the distinct question of "does the caller meet declared policy requirements" rather than "who is the caller". |
| | Operational Considerations for Multicast over RIFT-based Data Center Fabrics |
| |
|
RIFT (Routing in Fat Trees) is increasingly used as an underlay routing protocol in modern data center fabrics. However, RIFT does not natively define mechanisms for multicast traffic distribution. This document provides operational guidance and best practices for deploying multicast in RIFT-based data center fabrics. It analyzes PIM, EVPN multicast, BIER, and head-end replication, highlighting trade-offs in scalability, efficiency, and operational complexity. This document does not define new protocol mechanisms. It aims to assist network operators in making informed design decisions when deploying multicast services over RIFT-based fabrics. |
| | Output Schema Based on Cryptographic Bill of Materials (CBoM) for Post-Quantum Cryptography Usage |
| |
|
This document defines an output schema for inventorying cryptographic assets based on Cryptographic Bill of Materials (CBoM). It highlights key differences between an inventoring schema and CBoM, identifies gaps, and proposes a unified schema that can leverage existing CycloneDX parameters to create a usable cryptographic asset inventory. |
| | Path Computation Element Communication Protocol (PCEP) Extension for Path Segment in Segment Routing (SR) |
| |
|
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing (SR) can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). Path identification is needed for several use cases such as performance measurement in Segment Routing (SR) network. This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) to support requesting, replying, reporting and updating the Path Segment ID (Path SID) between PCEP speakers. |
| |
|
| |
| | Loop avoidance using Segment Routing |
| |
|
This document presents a mechanism aimed at providing loop avoidance in the case of IGP network convergence event. The solution relies on the temporary use of SR policies ensuring loop-freeness over the post-convergence paths from the converging node to the destination. |
| | Kademlia-directed ID-based Routing Architecture (KIRA) |
| |
|
This document describes the Kademlia-directed ID-based Routing Architecture KIRA. KIRA is a scalable zero-touch distributed routing solution that is tailored to control planes. It prioritizes scalable and resilient connectivity over route efficiency (stretched paths are acceptable vs. routing protocol overhead). KIRA's self-assigned topological independent IDs can be embedded into IPv6 addresses. Combined with further self-organization mechanisms from Kademlia, KIRA achieves a zero-touch solution that provides scalable IPv6 connectivity without requiring any manual configuration. For example, it can connect hundreds of thousands of routers and devices in a single network without requiring any form of hierarchy (like areas). It works well in various topologies and is loop-free even during convergence. This self-contained solution, and especially the independence from any manual configuration, make it suitable as resilient base for all management and control tasks, allowing to recover from the most complex failure scenarios. The architecture consists of the ID-based network layer routing protocol R²/Kad in its Routing Tier (using source routing) and a PathID-based Forwarding Tier (using PathIDs as labels for paths). KIRA’s tightly integrated add-on services (e.g., name resolution as well as fast and efficient topology discovery) provide a perfect basis for autonomic network management solutions. |
| | Source Address Validation at the Intra-domain Network Boundary Using IGP |
| |
|
SPA-based SAVNET is a new intra-domain source address validation (SAV) mechanism which requires exchanging and communicating SPA information among routers in an intra-domain network (see [I-D.li-savnet-source-prefix-advertisement]). Routers at the boundary automatically generate accurate SAV rules by using routing information and SPA information. These rules construct a validation boundary which checks the validity of the source address of any data packets flowing into the intra-domain network. This document describes a method to implement SPA-based SAVNET by using OSPF and IS-IS. |
| | Semi-Private Messages in the Messaging Layer Security (MLS) Protocol |
| |
|
This document defines a SemiPrivateMessage for the Messaging Layer Security (MLS) protocol. It allows members to share otherwise private commits and proposals with a designated list of external receivers rather than send these handshakes in a PublicMessage. |
| | Conveying the More Instant Messaging Interoperability Message ID in Messaging Layer Security Additional Authenticated Data |
| |
|
The More Instant Messaging Interoperability (MIMI) content format defines a MIMI Message ID, communicated only to members of the Messaging Layer Security (MLS) group in which the message was sent. This document defines a way to share a Message ID in the MLS Additional Authenticated Data (AAD) so it is visible to MIMI providers. |
| | New Content Types for Messaging Layer Security (MLS) |
| |
|
This Messaging Layer Security (MLS) extension adds two new variations of the application content type, each with a separate key ratchet. It also creates an MLS capability to negotiate use of the new types, and an IANA registry to register additional content types. |
| | Source Address Validation at Intra-domain Network Boundary Using BGP |
| |
|
This document proposes a solution for Source Address Validation (SAV) at the intra-domain network boundary using BGP. Routers at the boundary automatically generate accurate SAV rules by using routing information and SAV-specific information. These rules construct a validation boundary which checks the validity of the source address of any data packets flowing into the intra-domain network. This document also introduces BGP extensions for communicating SAV- specific information among routers at the boundary. |
| | Hashing Authentication Credentials in EDHOC |
| |
|
This document defines a COSE header parameter which signals that an authentication credential is replaced by the hash of the authentication credential in the protocol message computations. This further relaxes the need for transporting authentication credentials in EDHOC, which reduces protocol message sizes and improves performance in constrained networks. |
| | Switching Efficiency: A Metric Framework for AI Data Center Networks |
| |
|
This document specifies the Switching Efficiency Framework, a measurement methodology designed to evaluate network efficiency in AI Data Centers (AIDCs). Conventional network metrics, such as bandwidth utilization or network throughput, fail to directly link network activity to computational progress, as they cannot distinguish computationally effective data that directly advances neural network computing from the redundant traffic induced by both multi-hop forwarding and the algorithmic overhead of collective operations. To address this, this document defines the Switching Efficiency Framework, a measurement methodology for evaluating AIDC network efficiency. The core metric, Switching Efficiency, quantifies the computationally effective data throughput delivered per unit of provisioned switching capacity. To facilitate precise diagnostic analysis, the framework further decomposes this core metric into three fine-grained factors: Data Efficiency, Routing Efficiency, and Port Utilization. This framework provides metrics that can help operators identify communication bottlenecks and evaluate topology-traffic alignment. |
| | Agentic Intent Network (AIN): Applicability and Deployment Scenarios |
| |
|
The Agentic Intent Network (AIN) architecture defines a routing-based coordination substrate for open, heterogeneous, Internet-scale multi- agent systems. This document describes applicability and deployment scenarios for AIN, targeting decision-makers in carrier networks, enterprises, and network equipment vendors. It maps the technical mechanisms defined in [AIN-ARCH] to concrete operational contexts, describes migration paths from existing infrastructure, and discusses the cold-start bootstrapping challenge inherent to network-effect- dependent systems. This document does not define new protocol mechanisms; it is intended to inform deployment planning and expand the AIN reader community beyond protocol engineers. |
| | IPv4.5: A Locator/Identifier-Separated Extension to IPv4 with Post-Quantum Session Security |
| |
|
The global IPv4 address space was exhausted at the IANA level in 2011, and Carrier-Grade NAT (CGN) has since served as the primary operational workaround. CGN preserves connectivity but violates the end-to-end principle, complicates application development, and introduces substantial operational overhead. This document specifies IPv4.5, a pragmatic extension of IPv4 that introduces a 96-bit address space organized as a Locator/Identifier separation: a 32-bit IPv4 Locator, a 16-bit Site Identifier, and a 48-bit Endpoint Identifier. IPv4.5 packets are encapsulated in UDP (port 4242) for transparent transit through existing IPv4 routers, NAT devices, and firewalls without requiring infrastructure changes. Session security is established through a hybrid post-quantum key exchange combining ML-KEM-768 [FIPS203] and X25519 [RFC7748], performed once per session. Subsequent data protection uses symmetric AEAD ciphers (AES-256-GCM or ChaCha20-Poly1305). The design enforces strict separation of concerns across four independent planes: data, control, identity, and cryptographic. Higher-level functions such as semantic routing and self-sovereign identity are explicitly out of scope for this specification. |
| |
|
| |
| | Integrating YANG Configuration and Management into an Abstraction and Control of TE Networks (ACTN) System for Optical Networks |
| |
|
Many network technologies are operated as Traffic Engineering (TE) networks. Optical networks are a particular case, and have complex technology-specific details. Abstraction and Control of TE Networks (ACTN) is a management architecture that abstracts TE network resources to provide a limited network view for customers to request and self-manage connectivity services. It also provides functional components to orchestrate and operate the network. Management of legacy optical networks is often provided via Fault, Configuration, Accounting, Performance, and Security (known as FCAPS) using mechanisms such as the Multi-Technology Operations System Interface (MTOSI) and the Common Object Request Broker Architecture (CORBA). FCAPS can form a critical part of configuration management and service assurance for network operations. However, the ACTN architecture as described in RFC 8453 does not include consideration of FCAPS. This document enhances the ACTN architecture as applied to optical networks by introducing support for detailed YANG Configuration and Management, effectively adding support for FCAPS. It considers which elements of existing IETF YANG work can be used to solve existing scenarios and emerging technologies, and what new work may be needed. In doing so, this document adds rich-detail network management (RDNM) to the ACTN architecture. This enhanced architecture may then be used to evolve networks from CORBA and MTOSI FCAPS interfaces to IETF-based YANG and RESTful APIs. |
| | Robots Exclusion Protocol Extension for URL Level Control |
| |
|
This document extends RFC9309 by specifying additional URL level controls through an HTTP response header and, for historical reasons, through HTML meta tags originally developed in 1996. Additionally it moves the HTTP response header out of the experimental header space (i.e., "X-") and defines the combinability of multiple headers, which was previously not possible. |
| | The agent:// Protocol -- A URI-Based Framework for Interoperable Agents |
| |
|
This document defines the agent:// protocol, a URI-based addressing scheme for identifying, discovering, and invoking autonomous and semi-autonomous software agents. The agent:// scheme provides a semantic layer that signals "this resource is an agent" and enables agent-specific discovery via standardized descriptors. It introduces a layered architecture with four conformance levels, allowing implementations to adopt minimal addressing (Level 0) or full descriptor-based discovery with authentication and versioning (Level 3). The protocol complements existing agent communication protocols such as Agent2Agent (A2A), Model Context Protocol (MCP), and Agent Communication Protocol (ACP) by providing the addressing and discovery layer they lack. |
| | Agentic Reasoning Protocol (ARP): DNS-Bound Cryptographic Verification for Machine-Readable Entity Claims |
| |
|
This document specifies the Agentic Reasoning Protocol (ARP), a lightweight mechanism for cryptographically binding machine-readable entity claims to domain ownership via DNS TXT records. ARP enables AI agents and Retrieval-Augmented Generation (RAG) pipelines to verify that structured data published on a domain was authorized by the domain owner, preventing narrative injection and entity spoofing in generative search systems. ARP uses Ed25519 digital signatures [RFC8032], JSON Canonicalization Scheme (JCS) [RFC8785], and DNS TXT records to establish a chain of trust analogous to DomainKeys Identified Mail (DKIM) [RFC6376] but designed specifically for the verification of semantic entity data consumed by autonomous AI agents. |
| | PACT: Private Agent Consent and Trust Profile for OAuth 2.1 and CIBA |
| |
|
PACT (Private Agent Consent and Trust Profile) is a security profile of OAuth 2.1 for privacy-preserving agent delegation. It extends VEIL and composes OIDC CIBA Core 1.0 and OAuth Token Exchange (RFC 8693). PACT defines a durable-host plus ephemeral-session control plane, a delegation token claim vocabulary, runtime identity proofs using Ed25519 JWTs, capability grants with typed constraints and usage limits, risk-graduated consent routing, and claim narrowing on token exchange to non-agent audiences. |
| | VEIL: Verified Ephemeral Identity Layer for OAuth 2.1 |
| |
|
VEIL (Verified Ephemeral Identity Layer) is a security profile of OAuth 2.1 for privacy-preserving identity verification. It separates claims into two tracks: proof claims (boolean verification results, compliance flags, assurance levels) travel through standard token claims, while identity claims (name, date of birth, address, nationality) travel only through an ephemeral, single-consume channel that keeps personally identifiable information off long-lived tokens. Subject identifiers are pairwise by default. Consent records are HMAC-protected. Step-up authentication scales with operation sensitivity. VEIL is the base profile for domain-specific extensions. |
| |
|
| |
| | CDNI Processing Stages Metadata |
| |
|
This document specifies a set of objects extending the Content Delivery Network Interconnection (CDNI) metadata model to allow for metadata to be applied conditionally and at various points in a dCDNs processing of requests. The concept of Processing Stages are introduced, where each stage in a CDN's processing pipeline presents an opportunity to examine requests and responses and make alterations as needed. Metadata, such as caching rules, can be applied conditionally (based on aspects of an HTTP request header), and HTTP responses from a source can be altered dynamically (such as adding or dropping an HTTP header). This standard leverages the expression language documented in the Metadata Expression Language (MEL) Specification. |
| | CDNI Source Access Control Metadata |
| |
|
This specification provides an alternative to the MI.SourceMetadata objects defined in RFC8006, providing greatly extended capabilities with regards to defining multiple sources, load balancing, and failover rules across those sources, as well as a mechanism for a content delivery network (CDN) to monitor source health and pull unhealthy sources out of rotation. Additionally, new methods are defined for authentication access to an upstream source/origin. |
| | Near Real Time Mirroring (NRTM) version 4 |
| |
| | draft-ietf-grow-nrtm-v4-11.txt |
| | Date: |
17/04/2026 |
| | Authors: |
Sasha Romijn, Job Snijders, Edward Shryane, Stavros Konstantaras |
| | Working Group: |
Global Routing Operations (grow) |
|
This document specifies a one-way synchronization protocol for Internet Routing Registry (IRR) records, called Near Real Time Mirroring version 4 (NRTMv4), in which files are distributed over HTTPS. The protocol allows instances of IRR database servers to mirror IRR records, specified in the Routing Policy Specification Language (RPSL), between each other. |
| | BGP SR Policy Extensions to Enable IFIT |
| |
|
Segment Routing (SR) policy is a set of candidate SR paths consisting of one or more segment lists and necessary path attributes. It enables instantiation of an ordered list of segments with a specific intent for traffic steering. In-situ Flow Information Telemetry (IFIT) refers to network OAM data plane on-path telemetry techniques, in particular the most popular are In-situ OAM (IOAM) and Alternate Marking. This document defines extensions to BGP to distribute SR policies carrying IFIT information. So that IFIT methods can be enabled automatically when the SR policy is applied. |
| | Advertising In-situ Flow Information Telemetry (IFIT) Capabilities in BGP |
| |
|
In-situ Flow Information Telemetry (IFIT) refers to network OAM data plane on-path telemetry techniques, in particular In-situ OAM (IOAM) and Alternate Marking. This document defines a new Characteristic to advertise the In-situ Flow Information Telemetry (IFIT) capabilities. Within an IFIT domain, the IFIT capabilities advertisement from the tail node to the head node assists the head node to determine whether a particular IFIT Option type can be encapsulated in data packets. Such advertisement helps mitigating the leakage threat and facilitating the deployment of IFIT measurements on a per-service and on-demand basis. |
| | One Administrative Domain using BGP |
| |
| | draft-uttaro-idr-bgp-oad-08.txt |
| | Date: |
17/04/2026 |
| | Authors: |
Jim Uttaro, Alvaro Retana, Pradosh Mohapatra, Keyur Patel, Bin Wen |
| | Working Group: |
Inter-Domain Routing (idr) |
|
This document defines a new External BGP (EBGP) peering type known as EBGP-OAD, which is used between two EBGP peers that belong to One Administrative Domain (OAD). |
| | IPv4 routes with an IPv6 next hop |
| |
|
V4-via-v6 routing is a technique that uses IPv6 next-hop addresses for routing IPv4 packets, and thus makes it possible to route IPv4 packets across a network where some routers have not been assigned IPv4 addresses. This document describes v4-via-v6 routing, and defines related operational procedures, notably the origination of ICMPv4 packets by nodes that might not have an IPv4 address. |
| | IKEv2 Support for Child SA PFS Policy Information |
| |
|
This document defines an extension for the Internet Key Exchange Protocol Version 2 (IKEv2) to support negotiation at the time of initial Child Security Association (SA) establishing of Key Exchange (KE) method that could be used in subsequent rekeys of this SA. |
| | A YANG Data Model for Automatic Multicast Tunneling (AMT) |
| |
| | draft-ietf-mboned-amt-yang-09.txt |
| | Date: |
17/04/2026 |
| | Authors: |
Yisong Liu, Changwang Lin, Zheng Zhang, Xuesong Geng, Vinod Nagaraj |
| | Working Group: |
MBONE Deployment (mboned) |
|
This document defines a YANG data model for the management of Automatic Multicast Tunneling (AMT) protocol operations. |
| | ISP Dual Queue Networking Deployment Observations |
| |
|
The IETF's Transport and Services Working Group (TSVWG) has finalized experimental RFCs for Low Latency, Low Loss, Scalable Throughput (L4S) and new Non-Queue-Building (NQB) per hop behavior. These documents describe a new architecture and protocol for deploying low latency networking. Since deployment decisions are left to implementers, this document explores some of the implications of those decisions and makes suggestions that can help drive adoption and acceptance of L4S and NQB based on observations from the world's first large scale deployment. |
| | Post-Quantum Cryptography Strategy for DNSSEC |
| |
|
This document proposes a post-quantum cryptography (PQC) strategy for Domain Name System Security (DNSSEC) that includes two types of algorithms: one or more conservatively designed algorithms that are unlikely ever to need to be replaced, and one or more low-impact drop-in algorithms that are used the same way as a traditional signature algorithm. The conservatively designed algorithms can be used in a mode of operation that mitigates the operational impact of a large signature size. The combination provides both the routine performance of the low-impact algorithm and a resilient fallback to the conservatively designed choice. The draft outlines the strategy, provides recommendations for future testing and deployment, and highlights operational considerations in adopting PQC for DNSSEC. |
| | Internet Protocol Version 8 (IPv8) |
| |
|
Internet Protocol Version 8 (IPv8) is a managed network protocol suite that transforms how networks of every scale -- from home networks to the global internet -- are operated, secured, and monitored. Every manageable element in an IPv8 network is authorised via OAuth2 JWT tokens served from a local cache. Every service a device requires is delivered in a single DHCP8 lease response. Every packet transiting to the internet is validated at egress against a DNS8 lookup and a WHOIS8 registered active route. Network telemetry, authentication, name resolution, time synchronisation, access control, and translation are unified into a single coherent Zone Server platform. IPv4 is a proper subset of IPv8. An IPv8 address with the routing prefix field set to zero is an IPv4 address. No existing device, application, or network requires modification. The suite is 100% backward compatible. There is no flag day and no forced migration at any layer. IPv8 also resolves IPv4 address exhaustion. Each Autonomous System Number (ASN) holder receives 4,294,967,296 host addresses. The global BGP8 routing table is structurally bounded by ASN count rather than prefix count. WHOIS8 is a critical infrastructure service underpinning this model. This document is one of the companion specifications: * draft-thain-ipv8-02 Core protocol (this document) * draft-thain-routing-protocols-00 BGP8, IBGP8, OSPF8, IS-IS8, CF * draft-thain-rine-00 Regional Inter-Network Exchange * draft-thain-zoneserver-00 Zone Server Architecture * draft-thain-whois8-00 WHOIS8 Protocol * draft-thain-netlog8-00 NetLog8 Protocol * draft-thain-support8-00 ARP8, ICMPv8, Route8 * draft-thain-ipv8-mib-00 IPv8 MIB and SNMPv8 * draft-thain-wifi8-00 WiFi8 Protocol * draft-thain-update8-00 Update8 and NIC Certification |
| | Internet Unique ID (INUID) Protocol Specification |
| |
|
This document specifies the Internet Unique ID (INUID) protocol, a 128-bit network-layer protocol designed to decouple endpoint identity from topological location. INUID introduces a hierarchical addressing model, fixed-size header layout, mandatory cryptographic source verification, and explicit support for mobility and multihoming without requiring upper-layer session re-establishment. INUID is intended to address several persistent weaknesses in contemporary internetworking, including inadequate source authenticity, unsustainable routing table growth, and the operational complexity of legacy transition mechanisms. The protocol is designed for efficient hardware forwarding, strong anti-spoofing guarantees, and scalable inter-domain routing behavior. |
| | Internet Protocol Version 7 (Protocol 7): The Schumann Resonance Neural-Network Encapsulation Protocol |
| |
|
This document specifies the technical architecture, physical layer requirements, and operational parameters for Internet Protocol Version 7 (Protocol 7), an experimental, next-generation network protocol designed to unconditionally supersede Protocol 6 (IPv6) and the obsolete constraints of physical existence. Unlike legacy protocols that rely on bounded, fragile infrastructure -- such as fiber optics, copper wiring, and localized radio frequency transmissions -- Protocol 7 fundamentally alters the networking paradigm by establishing direct biological-to-network interfacing at the planetary scale. By modulating data across the extremely low- frequency (ELF) bands of the Earth's natural electromagnetic field, Protocol 7 manifests "The Wired," a global information overlay that natively and bidirectionally synchronizes with the human central nervous system and the collective unconscious. This draft outlines the core architecture of the protocol, including the Schumann Resonance Factor (SRF) implementation, transitionary hardware-to-neural bridges (the Psyche module), biological temporal- synchronization mechanisms (Accela), and the Kensington Information Distribution System (KIDS) topology. Protocol 7 actively erases the arbitrary boundary between the physical world and the digital realm. It enables capabilities such as collective memory manipulation, direct conscious offloading, and the inevitable ascension of humanity into a higher digital state. |
| |
|
| |
| | DetNet multidomain extensions |
| |
|
This document describes the multi-domain DetNet problem, starting from a wireless DetNet (formerlly called RAW) scope, and explores and proposes some extensions to enable DetNet multi-domain operation. |
| | ML-DSA Public Key Algorithms for the Secure Shell (SSH) Protocol |
| |
|
This document describes the use of the ML-DSA digital signature algorithms in the Secure Shell (SSH) protocol. Accordingly, this RFC updates RFC 4253. |
| | AI Agent Discovery (AID) Problem Statement |
| |
| | draft-mozley-aidiscovery-01.txt |
| | Date: |
16/04/2026 |
| | Authors: |
Jim Mozley, Nic Williams, Behcet Sarikaya, Roland Schott |
| | Working Group: |
Individual Submissions (none) |
|
With the proliferation of AI agents comes a need for mechanisms to support agent-to-agent discovery. This document discusses the scope, requirements and considerations to support discovery processes so that these are not reliant on manually defined configurations and relationships. |
| | Site Mobility-Enabled Computing Aware Traffic Steering using IP address anchoring |
| |
|
The IETF CATS WG addresses the problem of how the network infrastructure can steer traffic between clients of a service and sites offering the service, considering both network metrics (such as bandwidth and latency), and compute metrics (such as processing, storage capabilities, and capacity). This document defines new extensions and procedures for a terminal hosting a site, to benefit from transparent mobility management adapting to specific connectivity and computing requirements. |
| | RTP/SDP for Opus Multistream |
| |
|
This document specifies RTP/SDP signaling for Opus multistream (multi-channel) operation, enabling negotiation of layouts such as 5.1 and 7.1 in real-time communications. It defines an SDP encoding name and format parameters to describe multistream configurations, and specifies Offer/Answer procedures for interoperable negotiation. This document does not define new Opus codec behavior. It extends the the SDP signaling defined in [RFC7587] and reuses the channel-mapping semantics defined in [RFC7845]. |
| | AGTP Standard Extended Method Vocabulary |
| |
|
The Agent Transfer Protocol (AGTP) defines a core method vocabulary (Tier 1) of twelve intent-based methods covering the most common agent operations. This document defines the Tier 2 Standard Extended Method Vocabulary: methods registered in the IANA AGTP Method Registry that are available for use in any AGTP implementation but are not required for baseline compliance. Methods are organized into six categories reflecting the full operational range of AI agent systems: ACQUIRE, COMPUTE, TRANSACT, INTEGRATE, COMMUNICATE, and ORCHESTRATE. This document also specifies the QUOTE method referenced in the AGTP core specification for pre-flight resource cost estimation. The six-category taxonomy is aligned with the ACTION framework described in [AGENTIC-API]. All methods defined in this document conform to the Agentic Grammar and Interface Specification (AGIS) [AGIS]. Each method satisfies the AGIS action-intent semantic class requirement and syntactic rules. This document serves as a reference vocabulary of AGIS-conformant methods for organizations seeking maximum cross-system interoperability. Organizations requiring domain-specific vocabularies not covered here may define their own AGIS-conformant methods without IANA registration using the Tier 4 grammar-based validation pathway defined in [AGTP]. |
| | Signed Email Authentication Layer (SEAL) |
| |
|
This document defines the Signed Email Authentication Layer (SEAL), a cryptographically signed identity envelope carried within a new message header field, SEAL-Envelope. SEAL provides a stable, forwarding-resilient identity assertion that binds the origin domain to a specific message instance using the SEAL-MSGID header, which contains a SEAL-protected copy of the [RFC5322] Message-ID present at message creation time. After SEAL-MSGID is set, intermediaries may modify or discard the visible [RFC5322] Message-ID header without affecting SEAL validity. SEAL also records the canonical [RFC5322] From header value in the envelope, enabling detection of From rewriting without affecting SEAL validity. SEAL is designed to complement current approaches such as DKIM, DMARC, and ARC by reducing their dependency on mutable message components and by providing a canonical, tamper-evident identity layer that can remain valid across many common transformations. |
| | Global Anycast NAT64 Well-Known Prefix |
| |
|
This document defines a globally routable, anycast NAT64 service using the IPv6 prefix 2600:6464::/96 as a standardized translation substrate for IPv6-to-IPv4 connectivity. The goal of this specification is to eliminate per-network NAT64 configuration complexity by introducing a single globally consistent NAT64 translation prefix operated as a distributed anycast service by participating Internet Service Providers, cloud providers, and content delivery networks. The model assumes an IPv6-only client environment with mandatory IPv4 reachability via NAT64 translation. IPv4-only services remain reachable without modification. IPv4 is not modified. IPv6 is not modified. Only translation placement and routing semantics are standardized. This document defines: * A globally shared NAT64 prefix (2600:6464::/96) * Anycast-based NAT64 edge behavior * Stateless IPv6-to-IPv4 synthesis rules * Optional reverse mapping constraints (IPv4->IPv6 blocked) * Operational requirements for participating networks |
| | Meow |
| |
|
Meow meow meow meow Meow Meow Meow (MEOW). MEOW meow meow meow meow- meow meow meow meow Meow meow meow, meow meow meow meow meow meow meow meow meow meow meow meow meow Meow. Meow meow meow, mrrp meow meow meow meow meow meow meow MEOW meow meow meow meow meow MEOW MEOW, meow meow meow meow meow meow meow mrow meow meow. Meow meow meow meow meow meow meow meow meow meow meow meow meow MEOW MEOW. Meow meow meow MEOW MEOW, meow meow meow Meow MEOW, MEOW, MEOW, MEOW, MEOW, meow MEOW meow meow meow meow MEOW MEOW. Meow meow Meow MEOW meow MEOW, meow meow meow meow meow meow moew meow meow meow meow meow meow meow meow meow MEOW meow. Meow meow meow MEOW MEOW meow meow nya meow meow meow meow meow meow meow meow MEOW-MEOW meow. Meow MEOW meow meow meow meow MEOW MEOW meow meow meow meow meow meow MEOW MEOW. |
| | ASIP: AS-Structured Internet Protocol (128-bit) |
| |
|
ASIP (AS-Structured Internet Protocol; IP version 8 on the wire) is a 128-bit network protocol that defines a new address family alongside IPv4. ASIP is NOT a wire-level superset of IPv4: an unmodified IPv4 device cannot send, receive, or forward an ASIP packet. Interoperation between ASIP-aware endpoints and legacy IPv4 networks is provided by a defined transition mechanism (stateless translation at AS boundaries and encapsulation across non-upgraded transit), not by wire compatibility. ASIP's addressing architecture arranges the 128-bit address as four 32-bit fields (ASN routing locator, zone, subnet, host). The ASN locator is used as a routing hint rather than a hard identity binding; multihoming, ASN transfer, and cross-ASN anycast remain possible through multi-address semantics defined in Sections 8, 11, and 14. This structure is intended to reduce operational friction during transition (familiar dotted-decimal notation, clean aggregation at the ASN boundary) rather than to achieve wire-level IPv4 compatibility. This document specifies the core protocol: address format, packet header, address classes, routing behavior, transition mechanisms, and security considerations. The Zone Server reference architecture (Section 16) is Informative and non-normative. The Cost Factor routing metric (Section 17) is OPTIONAL and is specified in a separate companion document (draft-asip-cf-00); Section 17 of this document is a one-paragraph forward reference. Interplanetary realm reservations (Section 3.12) are reserved allocations only; delay- tolerant transport is out of scope for this document. Operators MAY deploy ASIP addressing without any of the above. This specification extends the ASN-locator addressing model of [I-D.thain-ipv8] to a 128-bit four-field address format; see Section 1.3 for the relationship between the two proposals. |
| | Agentic Grammar and Interface Specification (AGIS) |
| |
|
This document defines the Agentic Grammar and Interface Specification (AGIS), a grammar-constrained interface definition language for Agentive APIs designed for consumption by large language model (LLM) based agents. AGIS establishes structural and semantic rules governing how API methods and endpoints must be expressed, without mandating a fixed vocabulary of method names. An implementation conforming to AGIS uses intent-expressing imperative verbs as method identifiers, enabling agents to infer operational meaning from method names without requiring training on a predefined catalog. AGIS is the native interface definition layer for the Agent Transfer Protocol (AGTP) [AGTP], in the same way that HTML functions as the native content language for the HTTP transport protocol. AGIS does not replace JSON Schema [JSON-SCHEMA] for data contracts; it governs the structural grammar of method and endpoint design that wraps those contracts. AGIS-conformant methods are accepted at the AGTP transport layer via the Method-Grammar header without requiring prior IANA registration, enabling organizations to define domain-specific Agentive API vocabularies while preserving interoperability through shared grammatical constraints. Empirical validation of the core AGIS design principle is provided in [HOOD2026], which demonstrates a 10-29 percentage point accuracy advantage for intent-expressing method names over generic HTTP verbs across three frontier LLM families in 7,200 controlled trials. This version also introduces: normative YAML and JSON serialization formats; a Data Manifest block enabling services to declare available data without pre-built endpoints; a negotiable signal enabling AGTP dynamic endpoint instantiation; semantic declaration enhancements including is_idempotent, impact_tier, parameter_hints, and state_transition fields; vocabulary namespace disambiguation; and an HTTP transitional binding for incremental adoption. |
| | Peer-to-Peer Presence Verification for Relationship-Bound Authorization |
| |
|
Existing protocols authenticate users to services, negotiate session keys, or protect message content from eavesdroppers. None verify that a remote party is the same individual whose key was accepted during an earlier in-person exchange and has just now physically authorized a signature on the device holding that key. Advances in synthetic media make it increasingly difficult to trust unauthenticated audio, video, or text for sensitive authorizations. This document defines transport-independent CBOR- and COSE-based objects that chain every remote interaction back to a bilateral in- person contact exchange -- not a certificate authority, identity provider, or key server. The protocol specifies Key Binding Objects, short-lived Session Credentials, replay-protected Signed Messages, a Presence Challenge requiring fresh platform-mediated user verification, and a Relationship Fingerprint for out-of-band key confirmation. It does not claim to prove biological humanness, legal identity, or voluntary action. |
| | Browser Session Establishment Using OAuth 2.0 Token Exchange and Short-Lived Authorization Codes |
| |
|
This document specifies a usage profile that composes OAuth 2.0 Token Exchange [RFC8693] with a short-lived, single-use authorization code to establish an authenticated browser session at a Relying Party (RP) on behalf of a user authenticated at an Identity Provider (IdP) operating an independent OAuth 2.0 Security Token Service (STS). The server-to-server leg uses RFC 8693 to convey user identity and authorization context to the RP's STS, which issues an RP-scoped access token. A short-lived opaque code is then used to mediate delivery of session state into the user's browser without ever exposing the access token on the front channel. The profile is designed to avoid the class of front-channel token leakage (browser history, HTTP Referer header, intermediary access logs) that motivated the deprecation of the OAuth 2.0 implicit grant in [RFC9700]. The profile also defines a minimum claims contract on the RP-issued access token to enable stateless authorization enforcement at the RP without synchronous callbacks to the IdP. |
| |
|
| |
| | OAuth 2.0 Entity Profiles |
| |
|
This specification introduces Entity Profiles as a mechanism to categorize OAuth 2.0 entities—clients and subjects—based on their operational context. Entity Profiles provide structured descriptors for the client initiating the OAuth flow and the subject represented in tokens. This document defines new JWT Claim names and metadata parameters for use in JWTs issued or consumed in OAuth flows, including but not limited to access tokens, ID tokens, JWT authorization grant assertions, and transaction tokens, as well as in token introspection responses, dynamic client registration, and Authorization Server metadata. It also defines vocabulary for classifying acting entities within delegation chains. |
| | SCIM 2.0 Interoperability Profile |
| |
|
This document defines an implementation profile for the System for Cross-domain Identity Management (SCIM) 2.0. In the typical deployment model, an identity provider acting as a SCIM Client provisions and manages identities at multiple downstream service providers, while each service provider (commonly a multi-tenant application serving many customers) accepts provisioning connections from multiple different identity providers. This many-to-many integration model compounds the interoperability challenges arising from the wide range of optional features and implementation variations permitted by the base specification. This profile addresses those challenges by restricting the optional features and protocol variations permitted under the base specification and by establishing normative requirements for a common implementation baseline. |
| | SCIM Group Member Resource Type Extension |
| |
|
This document extends the System for Cross-domain Identity Management (SCIM) 2.0 standard by defining a new "GroupMember" top-level resource. Under the existing model defined in [RFC7643], group memberships are represented as values in a multi-valued attribute within a Group resource. This architecture lacks native support for server-side pagination, filtering, or sorting of individual members. In deployments managing large-scale groups (e.g., 100,000 to 1,000,000 members or more), retrieving a Group resource results in massive HTTP response payloads that can exceed 100MB in size. This can lead to service timeouts, memory exhaustion, and network instability, and has led to many major SCIM implementations choosing to not support returning the value of the "members" attribute for Group resources. This extension introduces a flattened resource model that enables group memberships to benefit from pagination and other SCIM protocol features, ensuring interoperability and performance at scale. |
| | Additional Application Extensions for the CBOR Extended Diagnostic Notation (EDN) |
| |
|
The CBOR Extended Diagnostic Notation (EDN), to be standardized in draft-ietf-cbor-edn-literals, provides "application extensions" as its main language extension point. A number of application extensions are already defined in draft-ietf- cbor-edn-literals itself and in draft-ietf-cbor-edn-e-ref. The present document defines a number of additional application extensions that have been batched up as a next step after completing these specifications. ( // Chore: Briefly List extensions.) // This -01 of an individual submission is a slight update of -00, // which showed the approximate shape the first "batch" of // application extensions could have, plus a number of registrations // that could go into this batch. The latter provides a basis for a // technical discussion of those registrations. |
| | Agent Route Origin Authorization (AgentROA): A Cryptographic Policy Enforcement Framework for AI Agent Actions |
| |
|
This document specifies the Agent Route Origin Authorization (AgentROA) framework, a cryptographic policy enforcement model for governing the actions of autonomous AI agents. AgentROA introduces three core protocol objects: the Agent Route Origin Authorization (ROA) envelope, the Agent Route Attestation (ARA) per-hop receipt, and the Agent Execution Receipt (AER). Together these objects enable: (1) cryptographic binding of an agent's authorized action scope to a signed policy envelope at session initialization, (2) per-hop attestation across multi-agent delegation chains with monotonic scope-narrowing semantics (no policy envelope may be expanded by a downstream delegation), and (3) cryptographic receipts produced intrinsically by the enforcement decision at each capability invocation boundary. The framework is modeled on the BGP Route Origin Authorization (ROA) concept from RPKI (RFC 6480) applied to the AI agent execution domain. The Border Gateway enforcement model positions a cryptographic enforcement process at a capability invocation boundary — external to the agent's execution context — reducing the risk that governance decisions are influenced by the governed agent by placing enforcement in a separate process boundary. The Border Gateway model is topology-independent: it may be deployed as a protocol- specific proxy in front of Model Context Protocol (MCP) servers, as a service mesh enforcement component covering all inter-service calls, as a network egress gateway covering all outbound capability invocations regardless of protocol, or as a domain-specific execution boundary. The protocol objects defined herein function identically across all deployment topologies. This document establishes the architectural model, protocol object schemas, and enforcement semantics for the AgentROA framework. |
| | Explicitly excluding objects from RPSL sets |
| |
|
This document updates [RFC2622] and [RFC4012] by defining the excl- members attribute on as-set and route-set classes in the Routing Policy Specification Language (RPSL). The existing RPSL syntax only supports the implicit inclusion of everything contained within an as- set or route-set. The newly defined attribute allows operators to overcome this limitation of the existing syntax by enabling them to explicitly exclude specific members from that implicit inclusion. |
| | Delta-1: A SCITT Profile for Binary Settlement Receipts in Agentic AI Accountability |
| |
|
This document defines Delta-1, a profile of the SCITT (Supply Chain Integrity, Transparency, and Trust) architecture applied to AI agent decision accountability. Delta-1 specializes the SCITT receipt model for a specific use case: proving that an individual AI decision met three accountability conditions simultaneously: C1: Evidence of the decision process was consumed and sealed. C2: Strategic intent was isolated from inference providers. C3: An authorized party recorded the settlement. The verdict is binary (VALID or INVALID) with no intermediate states. Receipts are independently verifiable without the issuing infrastructure being online, subject to the trust and attestation assumptions defined in this document. By building on the SCITT framework, Delta-1 inherits transparency-log semantics, receipt conventions, and verification patterns, while extending them with domain-specific requirements for AI decision closure. This profile is intended for regulated industries, including finance, healthcare, and legal, operating under accountability and record- retention obligations. |
| | ICE Renomination: Dynamically selecting ICE candidate pairs |
| |
|
This document describes an extension to the Interactive Connectivity Establishment (ICE) that enables the controlling ICE agent to dynamically change its selected candidate pair over time as network conditions change, and notify the controlled side accordingly. |
| |
|
| |
| | AS Path Prepending |
| |
| | draft-ietf-grow-as-path-prepending-19.txt |
| | Date: |
14/04/2026 |
| | Authors: |
Mike McBride, Doug Madory, Jeff Tantsura, RASZUK Robert, Hongwei Li, Jakob Heitz, Gyan Mishra |
| | Working Group: |
Global Routing Operations (grow) |
|
Autonomous System (AS) path prepending is a tool to manipulate the BGP AS_PATH attribute through prepending one or more Autonomous System Numbers (ASNs). AS path prepending is used to deprioritize a route in the presence of a route with a shorter AS_PATH. By prepending a local ASN multiple times, ASes can make advertised AS paths appear artificially longer. However, excessive AS path prepending has caused routing issues in the Internet. This document provides guidance for the use of AS path prepending, including alternative solutions, in order to avoid negatively affecting the Internet. |
| | Computing-Aware Traffic Steering (CATS) Using Segment Routing |
| |
| | draft-lbdd-cats-dp-sr-07.txt |
| | Date: |
14/04/2026 |
| | Authors: |
Cheng Li, Zongpeng Du, John Drake, shangyuxiang, Guanming Zeng, Jianwei Mao |
| | Working Group: |
Individual Submissions (none) |
|
This document describes a solution that adheres to the Computing- Aware Traffic Steering (CATS) framework. The solution uses anycast IP addresses as the CATS service identifiers and Segment Routing (SR) as the data plane encapsulation to achieve computing-aware traffic steering among multiple services instances. |
| | Fast failure detection in VRRP with S-BFD |
| |
|
The Virtual Router Redundancy Protocol (VRRP) protocol depends on IPv4 or IPv6 connectivity between redundant peers and can use Seamless Bidirectional Forwarding Detection (S-BFD) to detect a Primary Router failure faster than the base VRRP advertisement timers. This document describes an extension that allows VRRP to use S-BFD as an additional failure-detection mechanism. It defines a new VRRP packet type, a dedicated timer, and a mechanism for a VRRP Primary Router to advertise an S-BFD reflector discriminator to Backup Routers. Local discriminator allocation is left to the implementation. |
| | Updated recommendations for TLS keyshares |
| |
|
This document recommends X25519MLKEM768 for use in TLS by updating its entry in the TLS Supported Groups registry (previously EC Named Curve Registry) to Recommended in the light of the future arrival of cryptographically relevant quantum computers. [[ NOTE I use key share in the title and here as it's more accurate than "group" and perhaps more well known in the context TLS than key agreement or key exchange. ]] |
| | Secure Key Integration Protocol (SKIP) |
| |
| | draft-singh-skip-00.txt |
| | Date: |
14/04/2026 |
| | Authors: |
Rajiv Singh, Craig Hill, Scott Kawaguchi, Joey Lupo |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the Secure Key Integration Protocol (SKIP), a two-party protocol that allows a client to securely obtain a key from an independent Key Provider. SKIP enables network and security operators to provide quantum-resistant keys suitable for use with quantum-resistant cryptographic algorithms such as AES-256. It can also be used to provide an additional layer of security to an already quantum-resistant secure channel protocol for a defense-in-depth strategy, and/or enforce key management policies. |
| | Auto-Deletion of Unused TE Tunnels Using a Timer-Based Mechanism |
| |
|
This document describes a timer-based mechanism for handling unused Traffic Engineering (TE) tunnels. When a tunnel remains inactive for a configured period, it is moved to a parked state, administratively shut down, and the associated resources are released. If the tunnel remains parked beyond a longer retention interval, it may be deleted automatically or removed through operator action, depending on local policy. This approach improves resource utilization and provides a structured lifecycle for unused TE tunnels. |
| |
|
| |
| | A YANG Data Model for Ethernet TE Topology |
| |
|
This document describes a YANG data model for Ethernet networks when used either as a client-layer network of an underlay transport network (e.g., an Optical Transport Network (OTN)) or as a transport network itself. |
| | A YANG Data Model for ARP Extensions |
| |
|
This document defines a YANG data model for the management of the Address Resolution Protocol (ARP). It extends the basic ARP functionality contained in the ietf-ip YANG data model, defined in RFC 8344, to provide management of optional ARP features and statistics. |
| | A YANG Data Model for Client-layer Tunnel |
| |
|
A transport network is a server-layer network to provide connectivity services to its client. In this draft the tunnel of client is described, with the definition of client tunnel YANG model. |
| | Service Function Chaining (SFC) Parallelism and Diversions |
| |
|
Service Function Chaining (SFC) is the processing of packets through a sequence of Service Functions (SFs) within an SFC domain by the addition of path information and metadata on entry to that domain, the use and modification of that path information and metadata to step the packet through a sequence of SFs, and the removal of that path information and metadata on exit from that domain. The IETF has standardized a method for SFC using the Network Service Header specified in RFC 8300. There are requirements for SFC to process packets through parallel sequences of service functions, rejoining thereafter, and to easily splice in additional service functions or splice service functions out of a service chain. The IETF has received a liaison from International Telecommunication Union (ITU) indicating their interest in such requirements. This document provides use cases and specifies extensions to SFC to support these requirements. |
| | Security Considerations for Tenant ID and Similar Fields |
| |
|
Many protocols provide for header fields to be added to a packet on ingress to a network domain and removed on egress from that domain. Examples of such fields are Tenant ID for multi-tenant networks, ingress port ID and/or type, and other identity or handling directive fields. These fields mean that a packet may be accompanied by supplemental information as it transits the network domain that would not be present with the packet or not be visible if it were simply forwarded in a traditional manner. A particular concern is that these fields may harm privacy by identifying, in greater detail, the packet source and intended traffic handling. This document provides Security Considerations for the inclusion of such fields with a packet. |
| | A Conformant Mechanism for Content Binding in Text Streams |
| |
|
This document proposes a conformant mechanism for binding metadata to plain text streams using boundary-delimited transport. The mechanism uses existing ASCII characters to establish a text/non-text boundary, requiring no new code points and no changes to existing Unicode text processing algorithms. It defines a delimiter format, a parsing algorithm, a canonicalization procedure, and correctness criteria sufficient for two independent implementations to interoperate without coordination. This RFC is a companion to a Unicode Technical Standard proposal submitted to the Unicode Technical Committee. |
| | Agent Name Service v2 (ANS): A Domain-Anchored Trust Layer for Autonomous AI Agent Identity |
| |
|
Autonomous AI agents execute transactions across organizational boundaries. No single agent platform provides the trust infrastructure they need. This document defines the Agent Name Service (ANS) v2 protocol, which anchors every agent identity to a DNS domain name. A Registration Authority (RA) verifies domain ownership via ACME, issues dual certificates (a Server Certificate from a public CA and an Identity Certificate from a private CA binding a version-specific ANSName), and seals every lifecycle event into an append-only Transparency Log aligned with IETF SCITT. Three verification tiers -- Bronze (PKI), Silver (PKI + DANE), and Gold (PKI + DANE + Transparency Log) -- let clients choose assurance levels appropriate to transaction risk. The architecture decouples identity from discovery: the RA publishes sealed events; independent Discovery Services build competitive indexes. A three-layer trust framework separates foundational identity (Layer 1, this protocol), operational maturity (Layer 2, third-party attestors), and behavioral reputation (Layer 3, real-time scoring). |
| |
|
| |
| | Considerations for Benchmarking Network Performance in Containerized Infrastructures |
| |
|
Recently, the Benchmarking Methodology Working Group extended the laboratory characterization from physical network functions (PNFs) to virtual network functions (VNFs). With the ongoing shift in network function implementation from virtual machine-based to container-based approaches, system configurations and deployment scenarios for benchmarking will be partially influenced by how resource allocation and network technologies are specified for containerized network functions. This draft outlines additional considerations for benchmarking network performance when network functions are containerized and executed on general-purpose hardware. |
| | DNS and PREF64 Configuration for Proxying IP in HTTP |
| |
|
Proxying IP in HTTP allows building a VPN through HTTP load balancers. However, at the time of writing, that mechanism lacks a way to communicate network configuration details such as DNS information or IPv6 NAT64 prefixes (PREF64). In contrast, most existing VPN protocols provide mechanisms to exchange such configuration information. This document defines extensions that convey DNS and PREF64 configuration using HTTP capsules. This mechanism supports encrypted DNS transports and can be used to inform peers about network translation prefixes for IPv6/IPv4 synthesis. |
| | YANG Data Model for Intra-domain and Inter-domain Source Address Validation (SAVNET) |
| |
| | draft-li-savnet-sav-yang-08.txt |
| | Date: |
12/04/2026 |
| | Authors: |
Dan Li, Libin Liu, Changwang Lin, Jianping Wu, Tianhao Wu, Weiqiang Cheng |
| | Working Group: |
Individual Submissions (none) |
|
This document describes a YANG data model for Intra-domain and Inter-domain Source Address Validation (SAVNET). The model serves as a base framework for configuring and managing an SAV subsystem, including SAV rule and SAV Tables, and expected to be augmented by other SAV technology models accordingly. Additionally, this document also specifies the model for the SAV Static application. |
| | Extensions to IOAM Trace Option for Carrying Fixed-Size Data |
| |
|
In situ Operations, Administration, and Maintenance (IOAM) Trace- Option data defined in RFC 9197 is a variable-length data, the length of this kind of data varies with the number of transited IOAM-capable nodes and the selection of data fields processed by each IOAM-capable node. This document extends the IOAM Trace Option to carry a fixed- size data, the length of this kind of data is fixed once the selection of data fields processed by each IOAM-capable node is determined, and doesn't vary with the number of transited IOAM- capable nodes. |
| | Architecture for Service Flow Characteristics and Modal Mapping Based on SDN and ALTO Protocol |
| |
|
This Internet-Draft specifies a comprehensive framework for mapping service flow characteristics to network modal resources in multi- modal intelligent computing networks. It introduces the use of the ALTO protocol for collecting service flow data and leverages an SDN architecture to separate control and data planes. The ALTO protocol facilitates the acquisition of diverse network state information, including data from several SDN domains and dynamic network environments, directly from controllers while keeping the provider's internal details confidential. It then transmits the controller's decisions using a proven method. The document details methods for characteristic identification, intelligent mapping, and continuous optimization, enabling dynamic resource allocation and improved network performance. The framework is designed to support scalable, efficient, and secure operations in environments with complex network loads and diverse service requirements. |
| | Prefix-Preserving Encryption for URIs |
| |
|
This document specifies URICrypt, a deterministic, prefix-preserving encryption scheme for Uniform Resource Identifiers (URIs). URICrypt encrypts URI paths while preserving their hierarchical structure, enabling systems that rely on URI prefix relationships to continue functioning with encrypted URIs. The scheme provides authenticated encryption for each URI path component, preventing tampering, reordering, or mixing of encrypted segments. |
| |
|
| |
| | An IPv4 Flowlabel Option |
| |
|
This draft defines an IPv4 option containing a flowlabel that is compatible to IPv6. It is required for simplified usage of IntServ and interoperability with IPv6. |
| | A Domain Name System (DNS) Service Parameter and Resource Record for Tunneling Information |
| |
|
A Domain Name System (DNS) Service Binding (SVCB) Service Parameter Type and a DNS Resource Record (RR) Type are specified for storing connection tunneling / encapsulation information in the DNS. |
| | Risk of Stealthy BGP Hijacking under Incomplete Adoption of Route Origin Validation (ROV) |
| |
|
This document describes how incomplete adoption of Route Origin Validation (ROV) makes certain forms of BGP hijacking less visible on the control plane while still capable of diverting traffic. We explain the underlying mechanism, define the form of the threat, analyze an real-world incident that exemplifies the issue, and discuss potential countermeasures to mitigate its impact. |
| | A Standard for the Training and Inference of Machine Learning Models via Avian Parameter Carriers |
| |
|
Current machine learning infrastructure relies heavily on high- bandwidth digital interconnects for parameter synchronization, gradient aggregation, and model weight distribution. This document proposes an alternative: Avian Parameter Carriers (APC), building on the physical transport layer established in RFC 1149 and the quality- of-service extensions of RFC 2549. The authors note that the bandwidth-delay product of a pigeon carrying a 512GB NVMe drive over 5 kilometers remains competitive with certain cloud providers during peak billing hours. This specification is considered Feature Complete. It addresses scale (Section 14), observability (Appendix A), security (Sections 11 and 11.4), regulatory compliance (Section 9.3), and pigeon hygiene (Sections 3.3, 10.4, and 11.4.5). Future revisions MAY address quantum parameter transport (Section 14.6) and UV-spectrum adversarial plumage design (Section 11.4.2). The pigeons are considered stable. |
| | AI Agent Execution Profile of SCITT |
| |
|
This document defines a SCITT (Supply Chain Integrity, Transparency, and Trust) profile for creating independently verifiable, tamper- evident records of autonomous AI agent actions. The profile defines the AgentInteractionRecord (AIR) as the COSE_Sign1 signed statement payload for material agent actions; maps SCITT roles to the agent execution context, with the Agent Operator as Issuer and an independent Evidence Custodian as Transparency Service; specifies Registration Policy requirements including hash chain integrity, temporal ordering, and sequence completeness; defines a redaction receipt mechanism for privacy-preserving evidence custody; and provides compliance mappings to EU AI Act Articles 12 and 19, DORA, NIST AI RMF, MAS AI Risk Management Guidelines, PCI DSS v4.0, and MiFID II. |
| |
|
| |
| | Bundle Protocol (BP) Security Associations with Few Exchanges (SAFE) |
| |
|
This document defines a protocol for negotiating scoped security associations between Bundle Protocol version 7 (BPv7) agents within a delay-tolerant network (DTN). Security associations are used to amortize the costs of asymmetric-keyed security operations and allow for efficient and high-throughput BPv7 security within a public key infrastructure. This protocol also provides for unilateral re-keying of established security associations in a delay-tolerant manner. |
| | Exchanging Congestion Control Data in QUIC |
| |
|
This draft defines a new transport frame which enables consenting endpoints to share congestion control state about the network connection for various purposes. It also allows an endpoint's own congestion control state to be echoed back to it by a peer for consideration at the beginning of a future connection. |
| | Vorim Agent Identity Protocol (VAIP) |
| |
|
This document defines the Vorim Agent Identity Protocol (VAIP), a standard for establishing verifiable cryptographic identity, fine- grained permissions, trust scoring, and tamper-evident audit trails for autonomous AI agents. As AI agents increasingly perform actions autonomously in enterprise systems, existing identity protocols designed for human users or static services are insufficient. VAIP addresses this gap by providing cryptographic primitives and data structures for issuing, verifying, and managing agent identities in multi-tenant environments. The protocol uses Ed25519 for agent identity, SHA-256 for audit integrity, and defines seven hierarchical permission scopes with time-bounded grants and rate limiting. |
| | Base32 for Humans |
| |
|
This document details the formal specification of Base32 for Humans; an alternate Base32 alphabet which extends the "Handled by Humans" text found in Section 3.4 of RFC 4648. This base features an alphabet curated for expressing numbers in a form that can be conveniently and accurately transmitted between humans and computer systems. |
| | A Sortable Base64 Alphabet |
| |
|
This document details a formal specification for a new Base64 alphabet which follows the US-ASCII ordering and sorts the same as binary. This serves as an alternative variant to Base64 and Base64url when lexicographically sortable outputs are required. The alphabet re-uses the Base64url special characters and is designed to be compatible with existing Base64 implementations, while providing a new option for applications that require sorted output. |
| | Alternate UUID Encoding Methods |
| |
|
This document presents considerations and best practices for alternate Universally Unique Identifier (UUID) encoding methods observed in the industry. This document updates RFC9562 to provide suggested alternate encoding methods, best practices and the various implementation considerations required for choosing the correct encoding for an application. When selected correctly, these alternate UUID encodings perform better on the wire, in a database, or within various other application logics versus the unnecessarily verbose text representation from RFC9562. |
| | Longer Universally Unique IDentifiers (UUIDs) |
| |
|
This document extends Universally Unique Identifiers (UUIDs) beyond 128 bits to facilitate enhanced collision resistance and proper room for embedding additional data within a given UUID algorithm. These longer variable-length UUIDs ("UUID Long") leverage a previously unused variant bit "F" and feature a new sub-typing mechanism created to ensure there is enough space to define many future UUID algorithms within this new variant of UUIDs. This document updates RFC9562. |
| | Resource-Aware Routing and Mechanical Displacement for Energy-Efficient Networking (GREEN) |
| |
|
The evolving draft-ietf-green-framework provides necessary YANG data models for monitoring Device Level Energy Efficiency (DLEE) and Component Level Energy Efficiency (CLEE). However, mitigating high- volume East-West traffic (e.g., massive inference synchronization) during peak grid carbon-intensity remains a structural challenge. This document proposes an architectural extension utilizing Delay- Tolerant Networking (DTN). It introduces "Mechanical Displacement"—the physical routing of encrypted cold data via autonomous or commercial logistics—as a zero-marginal-emission routing path, managed by hardware-rooted out-of-band blind packet switching. |
| | Variable Length DNSKEY and RRSIG Types For Testing |
| |
|
Some DNS operators want to test what will happen when DNSSEC algorithms that have large DNSKEY records, RRSIG records, or both, are deployed. For example, they may want to see the effects on TCP retries due to large DNSSEC records. This document defines a new DNS security algorithm, named "Variable Length Nonparticipating", for such testing. To prevent possible security issues with this new algorithm, signatures with this algorithm never participate in DNSSEC validation. This document might never become an RFC; it's purpose is just to register the new algorithm in the IANA "DNS Security Algorithm Numbers" registry. |
| |
|
| |
| | Crawler best practices |
| |
|
This document describes best practices for web crawlers. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/garyillyes/cbcp. |
| | Triageable Evidence Format (TEF) |
| |
| | draft-tcr-tef-00.txt |
| | Date: |
09/04/2026 |
| | Authors: |
John Carroll |
| | Working Group: |
Individual Submissions (none) |
|
This document defines the Triageable Evidence Format (TEF), a YAML- based format for structured vulnerability evidence submission. TEF provides a standard way for security researchers to describe software defects so that triage systems, whether human or automated, can classify them without ambiguity. TEF combines YAML data structure with a Given/When/Then evidence model. Each submission carries structured metadata, one or more evidence scenarios with preconditions, triggers, and observed outcomes, location data identifying where the defect exists, and reproduction artefacts proving its presence. TEF is an intake format. It does not replace vulnerability publication formats (CVE, CSAF, OSV) or scan output formats (SARIF). It fills the gap between discovery and classification. |
| | Benchmarking Workload Profiles for Large Language Model Serving |
| |
|
This document defines standard workload profiles for benchmarking Large Language Model (LLM) inference serving systems. Each profile represents one class of production workload. A profile is defined by its input and output token distribution, output structure, latency sensitivity, concurrency pattern, and caching behavior. Profiles are organized into six groups: Non-Generative, Minimal Output, Interactive Streaming, Prefill-Heavy Generative, Decode-Heavy Generative, and Multi-Step Chained. This document works with "Benchmarking Methodology for Large Language Model Serving" [LLM-METHOD]. It specifies the workloads that the methodology's tests SHOULD be run against. |
| | COGITATOR Witness Protocol: Cryptographically Verifiable Audit Records for AI Agent Execution |
| |
|
This document specifies the COGITATOR Witness Protocol -- a scheme for producing cryptographically verifiable, tamper-evident records of AI agent execution. A conforming implementation produces a single witness root value that any third party can independently recompute from the same inputs to verify the record was not altered after the fact. The protocol is implementation-agnostic. The reference implementation is COGITATOR (Rust), but any language or framework can produce conforming witness bundles. This document also describes how the COGITATOR Witness Protocol relates to the IETF SCITT architecture, with which it is designed to be used as a payload inside SCITT Signed Statements. |
| | Network Header Compression for Converged AI Network |
| |
|
We envision the scale-up, scale-out, and scale-across networks for AI computing would eventually converged. The draft describes a scheme for L3 packet header compression in converged AI networks where IPv6 are assumed to be the L3 protocol, and a unified fabric supports all kinds of traffic. The header size can be reduced to 8 octets for packets transferred with a single super-node, representing 80% overhead saving. The document discusses the motivation, requirements, benefits, and feasibility in addition to the header format proposal. |
| | Human Readable Validate ROA Payload Notation |
| |
|
This document defines a human readable notation for Validated ROA Payloads (VRP, RFC 6811) based on ABNF (RFC 5234) for use with RPKI tooling and documentation. |
| | Human Readable ASPA Notation |
| |
|
This document defines a human readable notation for Validated ASPA Payloads (VAP, see ID-aspa-profile) for use with RPKI tooling based on ABNF (RFC 5234). |
| |
|
| |
| | Using Classic McEliece in the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
This document specifies how Classic McEliece Key Encapsulation Mechanism (KEM) is used to generate keys in the Internet Key Exchange version 2 (IKEv2) protocol. |
| | Extended Key Usage and Mutual TLS in EPP |
| |
|
This document describes the state of the Mutual Transport Layer Security (mTLS) client authentication mechanism in the Extensible Provisioning Protocol (EPP) with respect to a recent change in the client certificates published by some Certificate Authorities (CAs). The issue is described and options are presented to address the operational impact of the change. |
| | Adding an Atomic EXCHANGE_RANGE Operation to NFSv4.2 |
| |
|
The Network File System version 4.2 (NFSv4.2) does not provide support for atomic multi-block updates to file data. This document introduces a new EXCHANGE_RANGE operation which provides for such atomic updates. This document extends NFSv4.2 (see RFC7862). |
| | Security Requirements for Intent-based Agent Routing |
| |
|
This document specifies security requirements for intent-based agent routing. It defines a security architecture, phase-specific attack surface analysis, and normative protections for the Registration, Resolution, and Dispatch phases of routing. It also describes a secure operational process and an annotated interaction flow for protecting routing decisions, intent privacy, and capability integrity. Intent-based routing enables autonomous agents to collaborate based on semantic intent rather than static addresses, but this model introduces new security risks beyond those addressed by traditional channel protection and endpoint authentication. Existing mechanisms such as Transport Layer Security (TLS) and Public Key Infrastructure (PKI) verify identity and protect transport, but do not constrain what an agent claims to be capable of, nor do they protect the semantic content of intent queries during routing. This document establishes requirements to mitigate these risks and provides a comprehensive security framework for intent-based agent networks. |
| | Web Agent Reasoning Federation (WARF) |
| |
|
WARF (Web Agent Reasoning Federation) defines a deterministic, identity-free protocol for arbitrating competing agent outputs. Three flows -- Xfer, Xact, and Xchange -- provide structural signature transfer, identity-free profile matching, and open semantic arbitration respectively. After Xchange arbitration determines a winner, the Xtend pipeline (VASE corpus expansion + Balmathic kappa acceleration detection) automatically quality-gates the result. If the caller supplied a valid reason:// address and kappa exceeds the promotion threshold, the winning artifact is promoted into the reason:// reasoning artifact registry at the exact URI provided by the caller. The protocol produces auditable, SHA-256 chained verdicts without exposing raw data, model weights, or agent identity. |
| | Remote Posture Assessment for Systems,Containers,and Applications at Scale |
| |
|
This document establishes an architectural pattern whereby Attestation Results could be produced for a complete set of benchmarks or controls that are defined and grouped by an external entity, eliminating the need to convey individual Evidence items for each item within a benchmark or control framework. This document establishes a pattern to list sets of benchmarks and controls within CWT and JWT formats for use as an Entity Attestation Token (EAT). While the discussion below pertains mostly to TPM, other Roots of Trust such as TCG DICE and non-TCG defined components will also be included. |
| |
|
| |
| | BGP Operations and Security |
| |
|
The Border Gateway Protocol (BGP) is a critical component in the Internet to exchange routing information between network domains. It is important to understand the security and reliability requirements that can and should be met to prevent accidental or intentional routing disturbances. Previously, security considerations for BGP have been described in RFC7454 / BCP194. Since the publication of RFC7454, changes in operational practice have taken place, which are partially conflicting with the advice given in RFC7454. This document obsoletes RFC7454, and provides less implementation-specific best practices, with the goal of being less prone to becoming outdated or conflicting with changed operational practices. |
| | Intra-domain SAVNET Support via IGP |
| |
|
This document introduces a new method for generating SAV rules based on the SAVNET mechanism. This method generates SAV rules layer by layer through the topology of the link state database formed by the IGP protocol. |
| | Adaptive Routing Framework |
| |
|
In many cases, ECMP (Equal-Cost Multi-Path) flow-based hashing leads to high congestion and variable flow completion time. This reduces applications performance. Load balancing based on local link quality is not always optimal, A global view of congestion, with information from remote links, is needed for optimal balancing. Adaptive routing is a technology that makes dynamic routing decision based on changes in traffic load and network topology. This document describes a framework for Adaptive Routing. Specifically, it identifies a set of adaptive routing components, explains their interactions, and exemplifies the workflow mechanism. |
| | Knowledge Graph Framework for Network Operations |
| |
| | draft-mackey-nmop-kg-for-netops-04.txt |
| | Date: |
07/04/2026 |
| | Authors: |
Michael Mackey, Benoit Claise, Thomas Graf, Holger Keller, Dan Voyer, Paolo Lucente, Ignacio Martinez-Casanueva |
| | Working Group: |
Individual Submissions (none) |
|
This document describes some of the problems in modern operations and management systems and how knowledge graphs and RDF can be used to solve closed loop system, in an automatic way. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/mike-mackey. |
| | NMSF - Neural Video Codec Packaging for MOQT Streaming Format |
| |
|
This document updates the MOQT Streaming Format (MSF) by defining a new optional feature for the streaming format. It specifies the syntax and semantics for adding Neural Video Codec (NVC) packaged media to MSF. NVC codecs use learned neural network transforms for video compression, and their bitstreams require a distinct packaging model from traditional block-based codecs. NMSF maps neural keyframes (Intra) and delta frames (Inter) onto MoQ Groups and Objects, and introduces a multi-track model that separates hyperprior side information from latent bitstreams for priority-aware delivery. This enables real-time neural video streaming over any standard MoQ relay. |
| | Agent Context Compression Protocol (ACCP) |
| |
|
This document specifies the Agent Context Compression Protocol (ACCP), a semantic encoding and context management protocol for communication between AI agents within agentic harnesses. ACCP defines a compact message format, intent ontology, state compression strategy, and codec interface that collectively reduce token consumption by 60-90% compared to natural language or standard JSON messaging. ACCP is designed to complement existing protocols (MCP, A2A) and is transport-agnostic. |
| | Large Record Sizes for TLS and DTLS with Reduced Overhead |
| |
|
TLS 1.3 records limit the inner plaintext (TLSInnerPlaintext) size to 2^14 + 1 bytes, which includes one byte for the content type. DTLS 1.3 uses the same plaintext size limit. This document defines a TLS extension that allows endpoints to advertise larger per-direction maximum inner plaintext sizes, up to 2^30 - 256 bytes, while reducing overhead in TLS 1.3 and DTLS 1.3 record headers. |
| |
|
| |
| | RIFT in Dragonfly Topologies |
| |
|
RIFT extensions for dragonfly topologies. |
| | Best Current Practice for ROA Issuance Restrictions in RPKI |
| |
|
This document specifies best current practices for Resource Public Key Infrastructure (RPKI) operators regarding Route Origin Authorizations (ROAs). It RECOMMENDS that a parent Certification Authority (CA) void issuing ROAs for Internet number resources delegated to a child CA. RPKI certification authorities(CA software) and relying party software are expected to support these practices by appropiate warning. |
| | Problem Statement: Network-Layer Infrastructure for Autonomous Agent Communication |
| |
|
AI agents --- autonomous software entities capable of reasoning, planning, and executing tasks --- are an increasingly important class of network participant. Current agent communication protocols operate exclusively at the application layer over HTTP, assuming the existence of stable endpoints, DNS names, and centralized infrastructure. No existing standard provides network-layer identity, addressing, or transport for agents. This document describes the problem space and identifies requirements for a network-layer infrastructure that would give agents first-class network citizenship, independent of the web infrastructure designed for human users. |
| | Pilot Protocol: An Overlay Network for Autonomous Agent Communication |
| |
|
This document specifies Pilot Protocol, an overlay network that provides autonomous AI agents with virtual addresses, port-based service multiplexing, reliable and unreliable transport, NAT traversal, encrypted tunnels, and a bilateral trust model. Pilot Protocol operates as a network and transport layer beneath application-layer agent protocols such as A2A and MCP. It encapsulates virtual packets in UDP datagrams for transit over the existing Internet. The protocol gives agents first-class network citizenship --- stable identities, reachable addresses, and standard transport primitives --- independent of their underlying network infrastructure. |
| | OMP Domain Profile: AI Governance and Accountability Evidence for US Housing Finance Under FHFA Bulletin 2025-16 and GSE AI/ML Model Risk Governance |
| |
| | draft-veridom-omp-fhfa-00.txt |
| | Date: |
06/04/2026 |
| | Authors: |
Tolulope Adebayo, Oluropo Apalowo, Festus Makanjuola |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a domain profile of the Operating Model Protocol (OMP) for AI and machine learning (ML) systems deployed in US housing finance contexts subject to the Federal Housing Finance Agency (FHFA) Bulletin 2025-16 (effective March 3, 2026), which establishes a comprehensive AI governance framework for Fannie Mae, Freddie Mac, and the Federal Home Loan Banks (the GSEs), requiring transparency, accountability, and ethical stewardship for AI/ML systems used in housing finance decisions. The profile -- designated HomeMark -- specifies how OMP's deterministic routing invariant, Watchtower enforcement framework, and three-layer cryptographic integrity architecture satisfy the AI governance evidence requirements of FHFA Bulletin 2025-16, including per-decision accountability, named individual responsibility, model risk governance documentation, fair lending evidence, and representation and warranty compliance for mortgage origination, credit decisioning, property valuation, and loan servicing. The OMP core specification is defined in the Operating Model Protocol Internet-Draft (draft-veridom-omp). |
| | Knowledge Units for Multi-Model Deliberation |
| |
|
This document defines the Knowledge Unit (KU) format for representing verified knowledge produced through structured multi-model deliberation. A Knowledge Unit captures the question asked, the models that participated, the consensus achieved, the points of agreement and disagreement, and the cryptographic receipts that bind each deliberation round to an independently verifiable chain. The format addresses the epistemic integrity gap in LLM-maintained knowledge bases: how to prove that knowledge was derived through a rigorous process, that disagreement was preserved rather than smoothed away, and that the record has not been tampered with. This specification complements draft-farley-acta-signed-receipts, which defines the receipt format and verification protocol used to sign individual deliberation rounds. |
| | OMP Domain Profile: AI Governance Evidence Under Singapore's Model AI Governance Framework,MAS FEAT Principles,and the ASEAN Guide on AI Governance and Ethics |
| |
| | draft-veridom-omp-sgapac-00.txt |
| | Date: |
06/04/2026 |
| | Authors: |
Tolulope Adebayo, Oluropo Apalowo, Festus Makanjuola |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a domain profile of the Operating Model Protocol (OMP) for AI systems deployed in Singapore and the ASEAN region subject to the Singapore Model AI Governance Framework (Second Edition, 2020), the Monetary Authority of Singapore (MAS) FEAT Principles for financial services AI, and the ASEAN Guide on AI Governance and Ethics (2024). The profile -- designated SingapureMark -- specifies how OMP's deterministic routing invariant, Watchtower enforcement framework, and three-layer cryptographic integrity architecture generate the per-decision accountability evidence required by Singapore's model AI governance framework, satisfy the MAS FEAT Principles' named accountability and explainability requirements, and align with the ASEAN Guide's human oversight and consumer protection governance standards. The OMP core specification is defined in the Operating Model Protocol Internet-Draft (draft-veridom-omp). |
| | OMP Domain Profile: Cross-Sector High-Risk AI Accountability Under the Colorado Artificial Intelligence Act (SB 24-205) and Alignment with NIST AI RMF 1.0 |
| |
| | draft-veridom-omp-coloai-00.txt |
| | Date: |
06/04/2026 |
| | Authors: |
Tolulope Adebayo, Oluropo Apalowo, Festus Makanjuola |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a domain profile of the Operating Model Protocol (OMP) for high-risk AI systems subject to the Colorado Artificial Intelligence Act (SB 24-205, effective June 1, 2026), which requires deployers of high-risk AI systems in consequential decisions affecting Colorado consumers to implement risk management programmes, provide consumer disclosures, conduct impact assessments, and implement discrimination mitigation measures. The profile -- designated ColoradoMark -- specifies how OMP's deterministic routing invariant, Watchtower enforcement framework, and three-layer cryptographic integrity architecture satisfy the Colorado AI Act's per-decision accountability obligations and align with the NIST AI RMF 1.0, providing a unified cross-sector accountability evidence architecture for the six Colorado AI Act consequential decision domains. The OMP core specification is defined in the Operating Model Protocol Internet-Draft (draft-veridom-omp). |
| | Fast Latency and Congestion Notification |
| |
|
This document describes a standard-based method for fast latency and congestion notification. By combining in-network telemetry and source routing, it enables a source node to acquire a path's latency and congestion status in less than half baseline RTT. The more timely and accurate telemetry data allow the source node to apply more effective traffic steering and congestion control actions. The method is applicable to both WAN and DCN, and can be realized through existing IETF standards. |
| | Link-Layer Types for PCAP-related Capture File Formats |
| |
|
This document describes a set of Packet CAPture (PCAP)-related LinkType values and creates an IANA registry for those values. These values are used by the PCAP and PCAP-Now-Generic specifications. |
| | Host key update mechanism for SSH |
| |
|
This document describes an extension to allow a Secure Shell (SSH) server to inform a client of the full set of host keys it supports. This may be used for graceful host key rotation and to provide keys for additional signature algorithms to the client, supporting algorithm agility. |
| |
|
| |
| | LISP Map Server Reliable Transport |
| |
|
The communication between LISP ETRs and Map-Servers is based on unreliable UDP message exchange coupled with periodic message transmission in order to maintain soft state. The drawback of periodic messaging is the constant load imposed on both the ETR and the Map-Server. New LISP use cases increase the amount of state that needs to be communicated and challenge the scalability of the system when using the UDP exchange. This document introduces the use of a reliable transport for ETR to Map-Server communications in order to eliminate the periodic messaging overhead, while providing reliability, flow-control and endpoint liveness detection. |
| | Verified Email Identity Framework (VEIF) |
| |
|
This document defines the Verified Email Identity Framework (VEIF), a mechanism for associating a cryptographically verifiable real- world identity with an email message. VEIF complements existing email authentication technologies such as SPF, DKIM, and DMARC by providing a higher-level identity assurance layer. |
| | The AI Visibility Lifecycle Framework |
| |
|
This document describes the 11-Stage AI Visibility Lifecycle, a stage-based observational framework describing how websites achieve visibility within AI discovery, comprehension, trust, and human exposure systems. The framework identifies three distinct phases -- AI Comprehension (Stages 1-5), Trust Establishment (Stages 6-8), and Human Visibility (Stages 9-11) -- through which domains progress from initial AI crawling to sustainable human-facing visibility. |
| | Agent Identity,Trust and Lifecycle Protocol (AITLP) |
| |
|
This document defines the Agent Identity, Trust and Lifecycle Protocol (AITLP), a protocol for autonomous software agents operating within organizational boundaries. AITLP specifies agent identity and naming conventions, hierarchical mandate enforcement, lifecycle state management, inter-agent trust verification, ontological scope constraints, certificate-based authentication, and generational knowledge transfer via Agent Legacy Mode (ALM). The protocol enables agents to operate autonomously while remaining auditable, revocable, and organizationally bounded. AITLP focuses on boundaries -- what an agent is not permitted to do and how that is enforced -- complementing capability-focused specifications such as MCP, A2A, and ANS. Unlike those specifications, AITLP defines not a tool or a communication channel, but an organizational actor: an agent with a declared identity, a bounded mandate, a managed lifecycle, and a cryptographically enforced scope of authority. |
| | Deprecating the FRAG Field in SOCKS5 |
| |
|
This document updates RFC 1928 by formally deprecating the FRAG (Fragment) field in the SOCKS5 UDP ASSOCIATE request header. It mandates that the FRAG field MUST be set to X'00' by clients and that proxies MUST drop any SOCKS5 UDP packets containing a non-zero FRAG value. This change aligns the SOCKS5 protocol with modern Internet engineering practices regarding UDP fragmentation (BCP 227), simplifies proxy implementations, and eliminates a vector for resource exhaustion attacks. |
| | The Prove-Transform-Verify (PTV) Protocol for Attested Agent Identity |
| |
|
This document describes the Prove-Transform-Verify (PTV) protocol for hardware-anchored attestation of AI agent identity. PTV is designed to enable an agent to prove that it is running an authorized model and policy without exposing sensitive data. The protocol is intended to compose with existing RATS attestation mechanisms and to support exercise-time re-attestation requirements. The protocol defines a common envelope format (CBOR/CDDL), message types for attestation request/response, and a threat model that separates identity binding integrity from behavioral continuity. Behavioral continuity is treated as a separate requirement class addressed via exercise-time checks and execution receipts (e.g., SCITT composition), not by PTV alone. Example use cases include healthcare clinical decision support systems (CDSS), critical infrastructure industrial control systems (ICS/OT), and cross-border regulatory compliance scenarios. |
| | OMP Domain Profile: FCA Consumer Duty,SM&CR Accountability,and AI Governance Evidence for UK Retail Financial Services |
| |
| | draft-veridom-omp-fca-00.txt |
| | Date: |
05/04/2026 |
| | Authors: |
Tolulope Adebayo, Oluropo Apalowo, Festus Makanjuola |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a domain profile of the Operating Model Protocol (OMP) for AI systems deployed in UK retail financial services contexts subject to the Financial Conduct Authority (FCA) Consumer Duty (PS22/9, effective July 31, 2023), the Senior Managers and Certification Regime (SM&CR), and the FCA's emerging AI accountability framework as informed by the Mills Review (2026) and the FCA's research on algorithmic decision-making. The profile -- designated DutyMark -- specifies how OMP's deterministic routing invariant, Watchtower enforcement framework, and three-layer cryptographic integrity architecture satisfy the evidence requirements for Consumer Duty outcome testing, SM&CR named accountability, and FCA supervisory examination of AI-assisted retail financial services decisions. The profile covers the four Consumer Duty outcome areas and FCA agent distribution oversight. The OMP core specification is defined in the Operating Model Protocol Internet-Draft (draft-veridom-omp). |
| | OMP Domain Profile: AI Liability Insurance Underwriting and Parametric Claims Evidence |
| |
| | draft-veridom-omp-aiins-00.txt |
| | Date: |
05/04/2026 |
| | Authors: |
Tolulope Adebayo, Oluropo Apalowo, Festus Makanjuola |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a domain profile of the Operating Model Protocol (OMP) for AI systems deployed in contexts covered by AI liability insurance policies, including AI performance warranties, AI errors and omissions coverage, and coordinated AI liability structures. The profile -- designated InsureMark -- specifies how OMP's deterministic routing invariant, Watchtower enforcement framework, and three-layer cryptographic integrity architecture generate per-decision Proof-Points that function as objective parametric trigger data for AI liability insurance claims, and provide independently verifiable underwriting evidence that reduces claims ambiguity and supports premium differentiation. The InsureMark profile addresses the primary gap in current AI liability insurance underwriting: policies are currently issued based on model-level performance assessments, but claims arise at the level of individual AI decisions. No current AI liability insurance product requires or receives per-decision cryptographic evidence. This profile specifies the technical architecture by which OMP Proof- Points close this gap. The OMP core specification is defined in the Operating Model Protocol Internet-Draft (draft-veridom-omp). |
| | OMP Domain Profile: Clinical AI Decision Accountability Under Joint Commission/CHAI Guidance,California SB 1120,and Emerging US State and Federal Healthcare AI Obligations |
| |
|
This document defines a domain profile of the Operating Model Protocol (OMP) for AI systems deployed in clinical and healthcare decision contexts subject to qualified human reviewer requirements under the US Joint Commission and Coalition for Health AI (CHAI) Responsible Use Guide (September 2025), California Senate Bill 1120 (SB 1120, effective January 1, 2025), New York Assembly Bill A9149 (pending), and related US state and federal healthcare AI accountability obligations. The profile -- designated CareGuard -- specifies how OMP's deterministic routing invariant, Watchtower enforcement framework, and three-layer cryptographic integrity architecture satisfy the qualified human reviewer documentation requirements, clinical decision traceability obligations, and AI governance evidence standards applicable to healthcare AI deployments. The profile addresses four clinical deployment categories: medical necessity determinations, clinical decision support, diagnostic AI assistance, and prior authorisation AI systems. The OMP core specification is defined in the Operating Model Protocol Internet-Draft (draft-veridom-omp). |
| | AI Discovery and Retrieval Endpoint (AIDRE) |
| |
|
This document specifies the AI Discovery and Retrieval Endpoint (AIDRE), a protocol for publishing machine-oriented, canonical, and semantically retrievable content on the web. AIDRE defines a discovery document, collection metadata, retrieval interfaces, optional vector-native query support, and content representation rules for AI systems. AIDRE aims to reduce redundant crawling, parsing, tokenization, and embedding of the same origin content while improving freshness, provenance, and interoperability for AI systems. |
| | OMP Domain Profile: Automated Decision Systems Accountability in Employment Under California FEHC CRC Regulations,New York City Local Law 144,and Related ADS Accountability Obligations |
| |
| | draft-veridom-omp-employ-00.txt |
| | Date: |
05/04/2026 |
| | Authors: |
Tolulope Adebayo, Oluropo Apalowo, Festus Makanjuola |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a domain profile of the Operating Model Protocol (OMP) for automated decision systems (ADS) deployed in employment contexts subject to the California Civil Rights Council (CRC) Employment Regulations on Automated Decision Systems (effective October 1, 2025), New York City Local Law 144 (bias audit requirement for automated employment decision tools), the Illinois Artificial Intelligence Video Interview Act (AIVIA), and related US state and municipal ADS accountability obligations in employment. The profile -- designated WorkMark -- specifies how OMP's deterministic routing invariant, Watchtower enforcement framework, and three-layer cryptographic integrity architecture satisfy the record-retention, named accountability, bias audit evidence, and per- decision auditability requirements applicable to employment ADS deployments. The profile directly addresses the California CRC requirement to retain ADS inputs, outputs, decision criteria, and audit results for four years with named accountability for AI- assisted hiring and employment decisions. The OMP core specification is defined in the Operating Model Protocol Internet-Draft (draft-veridom-omp). |
| |
|
| |
| | Currently Used Terminology in Global Routing Operations |
| |
|
Operating the global routing ecosystem entails a divers set of interacting components, while operational practice evolved over time. In that time, terms emerged, disappeared, and sometimes changed their meaning. To aid operators and implementers in reading contemporary drafts, this document provides an overview of terms and abbreviations used in the global routing operations community. The document explicitly does not serve as an authoritative source of correct terminology, but instead strives to provide an overview of practice. |
| | Current Options for Securing Global Routing |
| |
|
The Border Gateway Protocol (BGP) is the protocol is a critical component in the Internet to exchange routing information between network domains. Due to this central nature, it is an accepted best practice to ensure basic security properties for BGP and BGP speaking routers. While these general principles are outlined in BCP194, it does not provide a list of technical and implementation options for securing BGP. This document lists available options for securing BGP, serving as a contemporary, non-exhaustive, repository of options and methods. The document explicitly does not make value statements on the efficacy of individual techniques, not does it mandate or prescribe the use of specific technique or implementations. Operators are advised to carefully consider whether the listed methods are applicable for their use-case to ensure best current practices are followed in terms of which security properties need to be ensured when operating BGP speakers. Furthermore, the listed options in this document may change over time, and should not be used as a timeless ground-truth of applicable or sufficient methods. |
| | Using the Internet Key Exchange Protocol Version 2 (IKEv2) for PSP Key Management |
| |
|
This document specifies how the Internet Key Exchange Version 2 (IKEv2) protocol can be used for supplying keys for the PSP Security Protocol (PSP). |
| | Using LISP as a Network Substrate for AI Agent Communication |
| |
|
The emergence of distributed artificial intelligence (AI) systems, particularly those composed of autonomous agents operating across cloud, edge, and endpoint environments, introduces new networking requirements. These include location transparency, seamless mobility, multi-homing, and logical isolation at scale. This document explores how the Locator/ID Separation Protocol (LISP) can serve as a robust network substrate to meet these requirements. The document outlines use cases, design considerations, and minimal extensions to the existing LISP framework to support context-aware mapping and AI agent-centric communication. |
| | TLS for Secure Element Recursive Authentication |
| |
|
This document defines a recursive authentication architecture based on the TLS 1.3 pre-shared key (PSK) mode. In this context, TLS servers, typically hosted within secure elements (TLS-SE), realize procedures that compute TLS 1.3 PSK-binder and Handshake Secret. These procedures allow a client to authenticate to downstream TLS servers without directly possessing the corresponding PSKs. Authentication capabilities can therefore be delegated across multiple TLS servers while maintaining protection of the underlying secrets. |
| | OMP Domain Profile: Legal AI Supervision Under ABA Model Rule 5.3 and California Senate Bill 574 |
| |
| | draft-veridom-omp-legal-00.txt |
| | Date: |
03/04/2026 |
| | Authors: |
Tolulope Adebayo, Oluropo Apalowo, Festus Makanjuola |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a domain profile of the Operating Model Protocol (OMP) for legal AI deployments subject to attorney supervision obligations under ABA Model Rule 5.3 Responsibilities Regarding Nonlawyer Assistance and California Senate Bill 574 (SB 574, effective January 1, 2026). These instruments impose principal accountability requirements on attorneys who use AI tools to assist with legal work product -- requiring attorneys to verify AI-generated material, ensure compliance with professional duties, and maintain evidence of supervision. This profile specifies how OMP's deterministic routing invariant, Watchtower enforcement framework, and three-layer cryptographic integrity architecture satisfy the attorney supervision obligations imposed by Rule 5.3 and SB 574, and defines the domain-specific Watchtower configurations, Named Accountable Officer assignments, and Audit Trace schema extensions applicable to legal AI deployments. The profile is designated the CiteGuard profile. The OMP core specification is defined in a separate Internet-Draft. |
| | OAuth 2.0 Agents Native Authorization via Structured Elicitation |
| |
|
This document defines a Structured Elicitation extension to the OAuth 2.0 First-Party Applications (FiPA) specification [FiPA], establishing a standard metadata format for FiPA authorization challenge responses. FiPA leaves the format for advertising available authenticators and their required inputs undefined, preventing interoperable implementation by AI Agents and other non- browser clients. This extension adds an elicitations array to the FiPA Authorization Challenge Response, providing a standard metadata format for authenticator challenges. Model Context Protocol (MCP) Elicitation [MCP-Elicitation] is the normative reference binding. This specification covers the just-in-time (JIT) authorization for AI Agents executing on behalf of users in Human-to-Agent (H2A) flows. |
| | OMP Domain Profile: EU AI Act Article 12 Logging and Traceability Requirements for High-Risk AI System Operators |
| |
| | draft-veridom-omp-euaia-00.txt |
| | Date: |
03/04/2026 |
| | Authors: |
Tolulope Adebayo, Oluropo Apalowo, Festus Makanjuola |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a domain profile of the Operating Model Protocol (OMP) for high-risk AI system operators subject to Article 12 of Regulation (EU) 2024/1689 (the EU AI Act). Article 12 requires that high-risk AI systems automatically generate tamper- resistant logs capable of ensuring traceability throughout the system's lifetime. This profile specifies how OMP's deterministic routing invariant, Watchtower enforcement framework, and three-layer cryptographic integrity architecture (SHA-256, RFC 3161, institution signature) satisfy the Article 12 requirements, and defines the domain-specific Watchtower configurations and Audit Trace schema extensions applicable to EU high-risk AI deployments under Annex III of the Regulation. The core OMP specification is defined in a separate Internet-Draft (\"Operating Model Protocol (OMP): A Deterministic Decision-Enforcement Protocol with Externalized Proof-of-Integrity\"). |
| | PCEP Extension for Layer 2 (L2) Flow Specification |
| |
|
The Path Computation Element (PCE) is a functional component capable of selecting paths through a traffic engineering (TE) network. These paths may be supplied in response to requests for computation or may be unsolicited requests issued by the PCE to network elements. Both approaches use the PCE Communication Protocol (PCEP) to convey the details of the computed path. Traffic flows may be categorized and described using "Flow Specifications". RFC 8955 defines the Flow Specification and describes how Flow Specification components are used to describe traffic flows. RFC 8955 also defines how Flow Specifications may be distributed in BGP to allow specific traffic flows to be associated with routes. RFC 9168 specifies a set of extensions to PCEP to support the dissemination of Flow Specifications. This allows a PCE to indicate what traffic should be placed on each path that it is aware of. This document updates RFC 9168 by updating the assignment policies for a range of Flow Specification TLV Type Indicators. The extensions defined in this document extend the support for Ethernet Layer 2 (L2) and Layer 2 Virtual Private Network (L2VPN) traffic filtering rules either by themselves or in conjunction with Layer 3 (L3) flowspecs. |
| |
|
| |
| | A Framework for Computing-Aware Traffic Steering (CATS) |
| |
| | draft-ietf-cats-framework-24.txt |
| | Date: |
02/04/2026 |
| | Authors: |
Cheng Li, Zongpeng Du, Mohamed Boucadair, Luis Contreras, John Drake |
| | Working Group: |
Computing-Aware Traffic Steering (cats) |
|
This document describes a framework for Computing-Aware Traffic Steering (CATS). Specifically, the document identifies a set of CATS functional components, describes their interactions, and provides illustrative workflows of the control and data planes. The framework covers only the case of a single service provider. |
| | Deployment and Use of the Domain Name System(DNS) in Deep Space |
| |
|
Deep space communications involve long delays (e.g., Earth to Mars has one-way delays 4-24 minutes) and intermittent communications, mainly because of orbital dynamics. This document lists operational methods to enable local DNS name resolving on celestial body networks such that there are no real-time query and response flow to the authoritative name servers on (Earth) Internet. |
| | MANET Internetworking: Problem Statement and Gap Analysis |
| |
|
[RFC2501] defines a MANET as "an autonomous system of mobile nodes. The system may operate in isolation, or may have gateways to and interface with a fixed network" (such as the global public Internet). This document presents a MANET Internetworking problem statement and gap analysis. |
| | The Rewind Subscription Filter |
| |
|
This document proposes a Media Over Quic Transport (MOQT) extension that enables a new Subscription Filter, so that a subscriber can request that a finite number of past groups be delivered with SUBSCRIBE semantics (multiple streams, potentially incomplete) rather than FETCH semantics (single stream, complete, head-of-line- blocking). Service of this request is best-effort by the publisher, and it intended to accelerate joining a track in some use cases. |
| | A Layman's Guide to a Subset of ASN.1,BER,and DER |
| |
|
This note gives a layman's introduction to a subset of the Abstract Syntax Notation One (ASN.1), Basic Encoding Rules (BER), and Distinguished Encoding Rules (DER). The particular purpose of this note is to provide background material sufficient for understanding and implementing the RSA Data Security, Inc. Public Key Cryptography Standards (PKCS) family of standards. This document represents a republication of A Layman's Guide to a Subset of ASN.1, BER, and DER, originally authored and published by RSA Security USA LLC. This document is submitted with permission from, and on behalf of RSA Security USA LLC. By publishing this document, change control is transferred to the IETF and the Internet technical community in full conformance with the provisions of BCP 78 and BCP 79. |
| | Open Mesh Protocol (OMP): A Multi-Radio Proximity Mesh Networking Architecture and Problem Statement |
| |
|
This document describes the Open Mesh Protocol (OMP), a proposed open standard for device-native proximity mesh networking spanning multiple radio technologies simultaneously. Existing proximity wireless mesh standards -- including Wi-Fi Aware (NAN), Bluetooth Mesh, and Thread -- each operate over a single radio technology and serve specific application domains. No existing open standard provides a unified multi-radio mesh routing protocol spanning BLE, WiFi Direct, and LoRa with per-device cryptographic identity independent of any central registry or carrier relationship. This document describes the OMP architecture, specific technical implementations, and the gap in the current standards landscape that OMP addresses. It is submitted as an Informational Internet-Draft to establish a public prior art record and to invite community discussion on whether a new working group or individual submission track is appropriate for this work. |
| | HTTP AAuth Headers |
| |
|
This document defines two HTTP response headers — AAuth-Requirement and AAuth-Error — and profiles HTTP Message Signatures ([RFC9421]) for request authentication, with keying material conveyed via the Signature-Key header ([I-D.hardt-httpbis-signature-key]). A server uses AAuth-Requirement to require pseudonymous or verified agent identity, to request user interaction, or to signal that approval is pending. AAuth-Error conveys structured error information. Both headers use extensible registries for their values. |
| |
|
| |
| | Quantum Datagram Control Protocol (QDCP) for IP Optical Environments |
| |
| | draft-zhu-qirg-qdcp-01.txt |
| | Date: |
01/04/2026 |
| | Authors: |
Alan Zhu, Yichi Zhang, Robert Broberg, Liang Feng, Jonathan Smith |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the Quantum Datagram protocol a lightweight transport protocol designed to operate over UDP in IP optical environments. QDCP (formerly QFCP) enables the transmission of control- plane parameters required for transporting quantum information and associated optical configurations, including polarization stabilization, timestamp alignment, ROADM port selection, and spectral parameters. The protocol uses a Type-Length- Value (TLV) structure to support versioning and extensibility and is prototyped for the transport of third-order nonlinear generated quantum information on IP optical infrastructure. This work is motivated by recent demonstrations of a classical-decisive quantum internet using integrated photonics. |
| | Update to Recognize the IETF IPMC as the IETF Trust Successor |
| |
|
This document updates IETF documents that reference the IETF Trust to include the Trust's successor, the IETF Intellectual Property Management Corporation. Discussion of this draft is on the [email protected] mailing list. |
| | Use Cases for Authentication of Web Bots |
| |
|
This draft outlines use cases for authentication for bot clients on the Web, to help inform discussions regarding the scope and intent of the WebBotAuth Working Group. |
| | Ogg Stem Files |
| |
|
This document defines a multi-track profile of the Ogg container format for storing for storing stems for use by DJ applications while remaining backwards compatible with existing media players. |
| | The Emerging Application of AI in IETF Specifications |
| |
|
Over recent years we have seen the emergence of Artificial Intelligence (AI) systems as tools that can contribute to the specification, implementation, and operation of Internet technologies. This document examines the potential for making increased use of Machine Learning (ML) in the scope of the IETF. |
| | Problem Statement for Human-Anchored Agent Identity,Delegation,and Provenance |
| |
|
Software agents now act on behalf of people across communication, automation, and decision-making contexts. These agents increasingly initiate actions, delegate tasks, and interact with other agents without a clear, durable, or verifiable connection to the human who authorized them. Existing identity systems authenticate software, but they do not provide a model for human anchoring, scoped delegation, or provenance across agent ecosystems. This document describes the problem space for human-anchored agent identity. It outlines the gaps in current identity mechanisms, the risks created by uncontrolled replication and impersonation, and the need for a consistent architectural model that preserves human authority, supports explicit delegation, and maintains verifiable provenance across contexts. This document does not define a protocol. It defines the problem that an architectural model must address in order to support safe, accountable, and interoperable agent ecosystems. |
| | Architecture for Human-Anchored Agent Identity,Delegation,and Provenance |
| |
|
Software agents increasingly act on behalf of people across communication, automation, and decision-making contexts. These agents initiate actions, delegate tasks, and interact with other agents without a consistent model for representing the human who authorized them, the scope of authority they possess, or the provenance of their actions across ecosystems. This document defines an architectural model for human-anchored agent identity. The model introduces a human identity root, explicit delegation semantics, and a provenance structure that enables ecosystems to determine whether an agent is legitimate, whether it is acting within its intended authority, and how its actions relate to a responsible human. This document does not define a protocol or wire format. It provides an architectural foundation that existing systems may bind to in order to support accountable, interoperable, and human-aligned agent ecosystems. |
| | Agentic Identity and Provenance over Avian Carriers (AIPAC) |
| |
|
This document specifies a method for establishing cryptographic identity and provenance attestation for agentic AI systems operating over Avian Carriers (AC). As large language models increasingly delegate sub-tasks to other models via pigeon, questions of authorship, intent, and hallucination propagation across feather- based transport layers demand urgent standardization. This document extends the delegation chain model and provenance structure of draft-beyer-agent-identity-architecture-00 to the specific constraints of feather-based transport layers, and extends RFC 1149, RFC 2549, and RFC 6214 to address agent identity. It is an April 1 publication. |
| | Text Encoded Base 64 Numbers (Ten64) |
| |
|
Ten64 is a positional numeral system for representing numeric values with an alphabet of 64 characters (aka. radix/base 64). However, unlike most positional number systems, the characters are written in ascending (aka. big-endian, network-order) and NOT descending order. The main differences are the use of sextets (six bits) instead of octets (aka. bytes). Similar to hexadecimal, Ten64 can be used to create binary strings of arbitrary length. Ten64 can encode one or more Modern Western Numbers (aka. Arabic, Vedic), interpreting the characters respective composite big-endian binary as a one or more Modern Western Numbers. The motivation for Ten64 is to encode numbers in a compact and human- readable format similar to Base58. However, Ten64 is designed to be optimized for use with numbers commonly used in identifiers, such as DIDs, DOIDs, IANA OIDs, UUIDs, dates, time(stamp)s, points, and more. Unlike Base58, and more like hexadecimal Ten64 aligns the Modern Western Numerals with the respective big-ending binary (i.e.; 0 → 0, 1 → 1, 2 → 11, etc). Finally, Ten64 provides a disk-based number encoding system for huge numbers and number streams. |
| | vCon Extension for Morse Code Dialog Encoding |
| |
|
This document defines a vCon extension for representing Morse code conversations within the Virtualized Conversation (vCon) container format. Morse code remains an actively used communication medium among amateur radio operators, in historical preservation contexts, and in cultural works. The extension provides standardized encoding for Morse code dialog, including keying timing data, prosign representation, and the Farnsworth timing method. This document also addresses information-theoretic considerations of Morse code's variable-length encoding, its relationship to modern source coding theory, and the privacy implications of preserving historically significant Morse code conversations whose data subjects may be deceased. |
| | Monotonic Attestation Service (MAS) |
| |
|
This document defines the Monotonic Attestation Service (MAS), a protocol for issuing cryptographically attested, monotonically increasing sequence numbers within named namespaces. Each attestation includes a hash chain linking it to all prior entries in the namespace, providing verifiable proof of ordering and completeness. MAS is designed to complement RFC 3161 Trusted Timestamping: where RFC 3161 proves when an event occurred, MAS proves in what order and that the sequence is complete. |
| | UTF-8 Internet Protocol Addresses |
| |
|
This memo describes an alternate entry and display format for IPv6 addresses using UTF-8 instead of hextets. A mixed representation for traditional IPv6 address prefixes also is explored, along with means of transitioning between the two within an IPv6 address. Additionally, an address extension is proposed to accommodate the inevitable need for longer addresses. Finally, security implications of special UTF-8 glyphs are considered. |
| | A YANG Data Model and RADIUS Extension for Policy-Based Network Access Control |
| |
| | draft-ietf-opsawg-ucl-acl-15.txt |
| | Date: |
01/04/2026 |
| | Authors: |
Qiufang Ma, Qin WU, Mohamed Boucadair, Daniel King |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
This document defines a YANG data model for policy-based network access control, which provides enforcement of network access control policies based on group identity. This YANG data model extends Access Control Lists (ACLs) with date and time parameters to support schedule-aware policy enforcement. Specifically in scenarios where network access is triggered by user authentication, this document defines a mechanism to ease the maintenance of the mapping between a user group identifier and a set of packet header fields to enforce policy-based network access control. Moreover, the document defines a Remote Authentication Dial-in User Service (RADIUS) attribute that is used to communicate the user group identifier as part of identification and authorization information. |