IETF Internet-Drafts & RFCs

Problem statement, use cases and requirements for Computing-Aware Traffic Steering (CATS) within a single domain. Distributed computing improves service response time and energy efficiency by spreading compute-intensive, delay-sensitive services across diverse facilities. CATS selects servers and steers traffic based on compute capabilities and resources rather than on static dispatch or connectivity metrics alone. The document lays out the scenarios that motivate CATS and derives the requirements that drive the CATS framework.

Framework for Computing-Aware Traffic Steering (CATS), the companion to the CATS problem-statement RFC. By its title and series context it defines the architecture and functional components needed to steer traffic toward service instances using both network and computing metrics, so that requests reach the most suitable site. The official abstract could not be fetched from the fast source on this run, so this summary is written from the title and the companion problem-statement document; it will be grounded on the next run.

Roughtime, an experimental protocol with two goals: secure, rough time synchronization even for clients that have no idea what time it is, and a format for clients to report any inconsistencies they observe between timeservers. The document specifies the on-wire protocol required for these goals and discusses the aspects of the surrounding ecosystem needed for it to work.

Defines an extension to Media over QUIC Transport (MOQT) that lets a subscriber limit how many subgroup streams and how many total bytes a publisher may send for an individual subscription. It specifies a Setup Option to negotiate the extension and set initial limits, message parameters for advertising those limits, messages for granting credit and signaling flow-control state, and a session error code.

Defines a YANG data model for network incident lifecycle management. The module offers a standard way to report, diagnose and help reduce troubleshooting tickets and to resolve network incidents, in support of network-service health and probable root-cause analysis.

A research document for the IRTF Network Management Research Group exploring what becomes possible once management systems on each side of an exchange can reason. Each side lifts its own data into a complete semantic model, and two such models reconcile ad hoc for the occasion with no model agreed in advance. It develops the semantic model and the two operations on it (lift and reconciliation), gives careful treatment to pragmatics and to thin references, and reports an empirical study across four network-management scenarios and several cognitive-agent families. It reflects the authors' findings and is not IETF or IRTF consensus.

Defines a Traceroute Extension Block (TREB) for Bundle Protocol Version 7 (BPv7). Each participating node along a bundle's path appends a hop-record with its Node ID, the node it received the bundle from, the next hop it selected, the time of the event and link characteristics. Copied into bundle status reports, the block returns the traceroute data to the source. The mechanism is opt-in and intended for designated diagnostic bundles on scheduled, bandwidth-constrained paths; the delivery report returns the full recorded path and its own return path, giving a round-trip trace. Status-report generation stays governed by RFC 9171.

No description available.

Defines an end-to-end Object delivery timeout for Media over QUIC Transport (MOQT). It uses Object timestamps so the timeout accounts for delay accumulated across a chain of relays instead of restarting at each hop.

Specifies the OpenA2A Agent Identity Protocol (AIP), an open standard for creating, managing and verifying cryptographic identities for AI agents. It centers on five elements: a multi-factor behavioral trust score from independently verifiable signals; a portable signed credential (the Agent Trust eXtension) carrying a hybrid Ed25519 / ML-DSA-65 signature for post-quantum readiness; an append-only, RFC 9162-style Merkle transparency log; agent identifiers as W3C DIDs (did:web and a registered did:opena2a method); and a structured capability vocabulary. On top of these it defines challenge-response verification, governance policies, a lifecycle model and an audit log, framed as complementary to A2A, MCP, OpenID Connect, WebAuthn and W3C Verifiable Credentials.

Builds on the Flooding Parameters TLV of RFC 9681, whose Receive Window (RWIN) and LSPs-per-PSNP threshold form a credit-based flow-control window for IS-IS flooding. Because a credit-based window alone does not signal congestion, fast flooding at scale can degenerate into sustained retransmission storms. This document specifies an unconditional local backoff: a node reduces the effective outstanding-LSP ceiling when LSP retransmissions toward a neighbor exceed a threshold within a trailing window. It also adds a lightweight Retransmission (RTX) indication flag in the Flags sub-TLV so a node can advertise its own congestion, and clarifies how concurrent versions of the same LSP fragment are counted.

Specifies the HTTP Mail Transfer Protocol (HMTP) for submission and transfer of Internet mail over HTTPS, covering both client submission and server-to-server transfer. Each message is carried unmodified in the existing Internet Message Format inside a JSON envelope holding the information needed for delivery. Large messages and attachments can be transferred by reference, with integrity protected by cryptographic hashes. Requests are authenticated by signatures bound to the sending domain using DKIM key publication, letting receivers identify senders independently of IP addresses. Servers discover HMTP endpoints through DNS, with optional fallback to SMTP for incremental deployment.

Describes the state of Mutual TLS (mTLS) client authentication in the Extensible Provisioning Protocol (EPP) in light of the 15 June 2025 policy change that led some Certificate Authorities to modify the client certificates they publish. The document explains the issue and presents options to address the operational impact of that change.

Specifies Virtual eXtensible Local Area Network (VXLAN), used for overlay networks in multi-tenant virtualized data centers and in cloud and enterprise deployments. It obsoletes RFC 7348, moving the VXLAN specification into the IETF document stream so that extensions requiring additions to the VXLAN header can be created and registered with IANA. The format and processing described remain fully compatible with RFC 7348.

Defines an experimental application-layer profile for representing the epistemic status of claims emitted or processed by machine-cognition systems. The profile requires that a claim not be given a stronger epistemic status than its validated, provenance-bound evidence supports, distinguishing object truth from epistemic truthfulness. It specifies how an implementation reports what is proved, observed, source-bound, interpretative, normative, predicted or open, and is designed to compose with QIK-VRT EFFECT_ACK without modifying its five-state version-1 wire contract.

HTTP transfers can be interrupted by canceled requests or dropped connections. If the recipient can indicate how much data was processed before the interruption, a sender can resume at that point instead of retransmitting everything. HTTP range requests already support resumable downloads from server to client; this document defines a mechanism that supports resumable uploads from client to server using HTTP.

Defines combinations of US NIST ML-KEM in hybrid with the traditional algorithms RSA-OAEP, ECDH, X25519 and X448, tailored to meet security best practices and regulatory guidelines. Composite ML-KEM applies in any application that uses X.509 or PKIX data structures accepting ML-KEM, but where the operator wants extra protection against breaks or catastrophic bugs in ML-KEM alone.

Reserves entries in various OpenPGP registries for use in interoperability testing, by analogy with GREASE in TLS, so that implementations exercise their handling of unknown values and avoid ossification.

Specifies a YANG extension and guidelines for applying an extended set of semantic-versioning rules to revisions of YANG artifacts such as modules and packages. It also defines a YANG extension for controlling module imports based on these modified semantic-versioning rules. The document updates RFCs 7950, 9907 and 8525.

RFC 5837 extends ICMP for interface and next-hop identification, helping identify interfaces on a path, which is useful where an interface may lack a unique IP address to respond from (for example, in traceroute). This document introduces a similar ICMP extension for Node Identification, allowing a unique IP address and/or a textual name for the node in cases where nodes may not have a unique IP address, such as deployments where all interfaces and next-hops are IPv6 even for IPv4 routes.

An individual submission in its 13th revision. The official abstract could not be fetched from the fast source on this run, so this summary is written from the draft name only and is approximate. By its name it appears to describe a transport or security mechanism (abbreviated 'tttps'); the specifics of its scope, mechanisms and status are not asserted here and will be grounded on the next run when the abstract is available.

Defines terminology around expressions such as 'IPv6-Only' and 'IPv6-Mostly' to avoid confusion when they are used in IETF and other documents. The goal is that a reference to 'IPv6-Only' describes the actual functionality in use within a given scope, rather than merely the installed protocol support.

Updated guidance on designing new protocols and protocol extensions with due consideration of the operations and management functionality needed to run them, since retrofitting such considerations is suboptimal. It obsoletes RFC 5706, reflecting over fifteen years of change, mandating an 'Operational Considerations' section in new IETF specifications (with an exemption when none apply). It also updates RFC 2360, removing the requirement for mandatory MIB creation in favor of holistic manageability documentation.

Specifies version 0.1 of the Human Delegation Provenance Protocol (HDP), a lightweight token-based protocol that captures, structures, signs and verifies human delegation context in agentic AI systems. An HDP token binds a human authorization event to a session and records each agent's delegation action as a signed hop in an append-only chain, letting an auditor verify the full record offline using only the issuer's Ed25519 public key, with no registry, network call or third-party trust anchor. HDP is explicitly not an authorization protocol: a token confers no authority and is read at audit, and its content can also travel inside UCAN or ZCAP-LD capability metadata.

ACME (RFC 8555) establishes authority over an identifier through a challenge that proves control of it, such as a DNS record or HTTP resource. This document defines a new ACME challenge type, 'wif-01', that authorizes certificate issuance based on a platform-issued identity token instead of demonstrating identifier control. The token is bound to the ACME account key via its audience claim, requiring no new claims or endpoints from existing identity providers. Because workload identity is established per authorization, External Account Binding is not needed, and the solution uses only existing ACME extension points.

Describes the 11-Stage AI Visibility Lifecycle, a proposed analytical model of how AI systems discover, understand, trust and show websites to people. The eleven stages fall into three phases: AI Comprehension (1-5), Trust Establishment (6-8) and Human Visibility (9-11). The lifecycle is non-linear: stages 1-2 come first for any page, while 3-11 are weighed together. Its figures are illustrative analytical estimates and its descriptions of AI behavior are inferred from observation, not documented internals; its contribution is a common vocabulary and a dependency map distinguishing crawlability from visibility, with provisional mechanisms that remain to be tested.

Presents an optional new type of database-synchronization packet called an Aggregated SNP Hash (ASH). When feasible it compresses traditional SNP exchanges into a dynamic Merkle-tree-like structure, speeding synchronization of large databases and adjacency counts while reducing the load of regular CSNP exchanges during normal operation. Like CSNPs and PSNPs, ASH packets come in two flavors: Complete ASH (CASH) and Partial ASH (PASH).

A practical guide to deploying 464XLAT-based IPv6-only technology on the user plane in 3GPP 5G networks. It covers key 5G concepts and architectures, configuration methods and the operational challenges involved.

LISP ETR-to-Map-Server communication relies on unreliable UDP exchanges plus periodic retransmission to keep soft state, which imposes constant load on both sides and scales poorly as new use cases increase the amount of state. This document introduces the use of a reliable transport for ETR-to-Map-Server communication, eliminating periodic-messaging overhead while providing reliability, flow control and endpoint-liveness detection.

No description available.

Verifiable Voice Protocol (VVP) authenticates and authorizes organizations and individuals making and receiving telephone calls, closing trust gaps that malicious parties exploit. Like SHAKEN, RCD and BCID it uses STIR to bind cryptographic evidence to a SIP INVITE and verify it downstream, but can also carry evidence about the callee. Built on different technical and governance assumptions and richer evidence, VVP aims to cross jurisdictional boundaries while being simpler, more decentralized, cheaper, more private, more scalable and higher assurance. It can bridge other approaches (e.g. justifying a SHAKEN A attestation or an RCD passport) and enables two-way evidence sharing with verifiable text and chat.

Provides updated guidance on the generation of padding in OpenPGP data streams. It does not specify any new OpenPGP wire formats, but proposes higher-level best practices for how padding should be produced.

A tongue-in-cheek document whose abstract stresses that anyone can publish an Internet-Draft, and that doing so does not mean 'the IETF thinks' or 'the IETF is planning' anything. It exists to make the point about the status of Internet-Drafts rather than to specify a protocol.

Defines requirements for IPv6 nodes. Because IPv6 is deployed across a wide range of devices and situations, specifying node requirements lets IPv6 function well and interoperate across many deployments. This document obsoletes RFC 8504, and in turn RFC 6434 and its predecessor RFC 4294.

As operators move services to IPv6-only, planned IPv4 outages help find remaining dependencies before permanent decommissioning; such outages must be measurable, reversible and understandable to users. This document defines HTTP signaling for an intentional, often time-bounded IPv4 outage: a 503 Service Unavailable response with a mandatory 'Retry-Over-IPv6' header (plus optional fields) that tells aware clients to retry over IPv6 after closing the IPv4 connection, with an optional correlation token so operators can tell soft failures from hard ones. Legacy clients simply treat the response as ordinary unavailability. It targets operator-controlled environments and supports staged rollouts and coordinated drills.

Network platforms use telemetry such as YANG-Push (RFC 8641) to continuously stream counters and state. This document specifies the Data Manifest, the metadata needed to interpret collected data correctly, composed of two YANG models (the Platform Manifest and the non-normative Data Collection Manifest) defined at the network level, e.g. at network controllers. The manifest must be streamed and stored alongside the data up to collection and analytics systems so the data stays fully exploitable, and the document augments the YANG-Push model to include the actual collection period when it differs from the configured one.

A revision of RFC 4086, 'Randomness Requirements for Security.' Its abstract notes how much has changed in the two decades since RFC 4086, and that as more IETF protocols use cryptography the need for good-quality randomness has greatly increased. This -00 begins updating that guidance for current practice.

Defines a set of MOQT Properties for carrying per-Object timestamps efficiently. The encoded timestamp is intended for use within Media over QUIC Transport, but can also be referenced for application-specific purposes.

Defines an RDAP extension that represents entity contact information in JSON responses using JSContact, aligning registration-data contact handling with the JSContact data model.

Defines a record format for AI-agent authorization decisions: one in-toto predicate type, signed inside a DSSE envelope. It carries the seven minimum audit fields required by the WIMSE AI Identity Management System framework, plus two properties that make them checkable: a canonicalization contract, and both the authorization decision and the observed effect with a derived three-valued agreement between them. The framework places the format out of scope and takes no IANA action; this document supplies the format and defines no policy.

A new -00 individual submission related to Computing-Aware Traffic Steering (CATS). The official abstract could not be fetched from the fast source on this run, so this summary is written from the draft name only and is approximate. By its name it probably concerns maintaining affinity between an agent's session or state and a particular compute instance when steering traffic; the specifics are not asserted here and will be grounded on the next run.

Specifies the Agent Identity Document, a small JSON document served at a well-known URI on a hostname assigned to one autonomous agent, plus the practices an identity provider follows when hosting such names for operators who do not run their own domain. It separates what the provider knows to be true (hostname, service endpoints, lifecycle status) from what the operator asserts (description, contact, homepage, public key), and publishes the provider's dated, expiring checks rather than a single trust level. A suspended identity publishes a minimal document, every identity is held by an accountable person or organization, and agents are never given authority over DNS. It requests registration of a well-known URI suffix.

Specifies modifications to the DNS protocol to permit a range of Resource Record types at delegation points, where today DNS allows Delegation Signer (DS) records. The changes are designed to stay compatible with existing resolution mechanisms and to provide a secure method for processing such records at delegation points. It updates RFCs 1034, 4035, 6672, 6840, 6895 and 9824.

Specifies a new extensible method for delegating authority for a domain in the DNS using DELEG and DELEGPARAM records. Traditional NS-based delegation contains only server hostnames and no other parameters, and both parent and child zones hold copies that can drift out of sync. The new delegation records are extensible, can be secured with DNSSEC and eliminate the problem of two sources of truth for delegation information.

Revision -01 of a draft in the DIEM/ADEM work, concerning DNS. The official abstract is a placeholder ('TODO Abstract') on the fast source, so this summary is written from the draft name only and is approximate. By its name it appears to define DNS-based discovery or publication for the ADEM (Autonomous Device / emblem) mechanism; specifics are not asserted here and will be grounded on the next run.

In times of armed conflict the protective emblems of the red cross, red crescent and red crystal mark physical assets as protected under international humanitarian law (IHL). This draft specifies the format and trust architecture of a protective digital emblem for network-connected infrastructure, marking assets as protected under IHL analogously to the physical emblems so that parties can identify respected and protected assets on the network.

Specifies a Pre-Shared Key (PSK) authentication method for the Lightweight Authenticated Key Exchange (LAKE / EDHOC) protocol. The PSK method provides mutual authentication, ephemeral key exchange, identity protection and quantum resistance at lower computational cost than LAKE's public-key methods. It suits systems where nodes share an external PSK out-of-band and enables efficient session resumption using a resumption PSK from a previous LAKE session. The document details the PSK message flow, key-derivation changes, message formatting and processing, and security considerations.

Defines how to subscribe to YANG event streams for Remote Attestation Procedures (RATS). It specifies a YANG module that augments the module for TPM-based Challenge-Response Remote Attestation (CHARRA), enabling subscription to RATS Conceptual Messages of the Evidence type and the auxiliary Event Logs that form part of that evidence. It requires at least one TPM 1.2 or TPM 2.0 (or equivalent hardware) on the Attester running the YANG server.

The Identifier-Locator Network Protocol (ILNP) for IPv6 is defined in Experimental RFCs 6740-6744. This document describes how values for ILNP data types should be represented in textual form: the Locator (L64), the Node Identifier (NID) and the Identifier-Locator Vector (I-LV). The notation is defined formally and use-cases are given as real-world examples. It updates RFCs 6740, 6741 and 6742.

Part of the ILNP-for-IPv6 series (Experimental RFCs 6740-6744). This document clarifies how ILNP addressing uses Preference values with Locator (L64) and Node Identifier (NID) values, including how Preference values form Identifier-Locator Vectors (I-LVs) and how I-LVs are selected for use. It updates RFCs 6740, 6741, 6742 and 6748.

Part of the ILNP-for-IPv6 series (Experimental RFCs 6740-6744). ILNP packets are distinguished from normal IPv6 packets by the Nonce Destination Option Header ('Nonce Header') defined in RFC 6744. This document clarifies the use of the Nonce Header for ILNP and updates RFCs 6740, 6741 and 6744.

Part of the ILNP-for-IPv6 series (Experimental RFCs 6740-6744). ILNP uses a different architecture from IPv6 but is implemented to work with it. This document describes how unmodified IPv6 applications running on an ILNP-capable node can make use of ILNP, and updates RFCs 6740, 6741 and 6748.

Part of the ILNP-for-IPv6 series (Experimental RFCs 6740-6744). ILNP uses an I-LV with a zero-valued L64 and a relevant NID in place of an IPv6 address in the pseudo-header for transport checksums, which makes TCP and UDP checksums differ from the IPv6 case. This document changes the TCP and UDP checksum computation for ILNP so the values match IPv6, updating the checksum processing described in RFCs 6740, 6741 and 6748.

Publishers increasingly serve a curated plain-text summary of a web origin for LLMs and their crawlers, most visibly as 'llms.txt', but that informal proposal lacks a media type, retrieval-cost bounds and a way to discover the file from robots.txt or a fixed location. This document specifies discovery and retrieval for publisher-curated context files: the well-known URI 'llm-context', a matching link relation and a robots-exclusion extension record, so a publisher can advertise the file by three independent paths. It defines a two-tier index/detail arrangement with conditional-request and size requirements, and reports measurements showing crawlers largely ignored such files absent a discovery mechanism.

LLM-driven autonomous agents run multi-step tasks in which the same conversational context is resent to the model on every step, so resource use is dominated by repeated input and is reported today in incompatible vendor-specific shapes. This document defines Agent Run Metrics, a JSON interchange format describing the resource consumption of a single agent run and its steps, with a small set of exactly specified derived quantities. It states that one reported step equals one completed model invocation and defines how delegated sub-runs are attributed without double counting. It carries counters, timing and cost only, deliberately excluding prompt and completion content.

Defines a strategy to securely assign a candidate device (Pledge) to an owner using a digital artifact, the Voucher, signed directly or indirectly by the Pledge's manufacturer. The artifact is a YANG-defined JSON or CBOR document signed with a variety of cryptographic systems, normally generated by the manufacturer's MASA. It obsoletes RFC 8366, folding in a number of desired extensions to the YANG module, and updates and now includes the Voucher Request module from RFC 8995 along with other YANG extensions needed for variants of RFC 8995.

Defines JEP Receipt Profile 1 (JEP-RP-1), a minimal receipt and evidence profile for the Judgment Event Protocol (JEP). It binds a JEP event to one digest-addressed receipt record through a critical JEP extension, and defines a small behavior-record format, portable receipt manifests and bundles, and independent receipt-validation checks. JEP remains authoritative for event verbs, identity, hashing, signatures, references, extension processing and acceptance semantics. Receipt records are technical evidence about observable behavior; the profile assigns no legal liability, proves no intent and determines no causality or compliance.

Revision -03 of a LISP working-group draft on NAT traversal. The official abstract could not be fetched from the fast source on this run, so this summary is written from the draft name only and is approximate. By its name it defines how LISP data-plane and control-plane messages traverse NAT devices (for example between an xTR behind a NAT and the mapping system); the specific mechanisms are not asserted here and will be grounded on the next run.

Revision -02 of an individual v6ops-related submission (abbreviated 'eds'). The official abstract could not be fetched from the fast source on this run, so this summary is written from the draft name only and is approximate. By its name it appears to address an IPv6 operations topic; its scope and mechanisms are not asserted here and will be grounded on the next run.

Describes a framework for standardizing multi-vendor inputs for LLM-assisted network management. Inputs such as CLI output, configuration, telemetry, alarms and vendor APIs differ in format and semantics, making a consistent LLM interface hard. An Input Classifier assigns each input to performance, configuration or response (rule-based first, escalating to a small language model), the matching Structurer produces a normalized representation, and a Prompt Schema Generator creates a vendor-agnostic schema and schema-aligned prompts for the central LLM. It specifies architecture and component roles, defines no wire protocol, and is informational.

Specifies procedures for handling ICMP error messages in SRv6-based Virtual Private Networks (VPNs), describing three methods to improve ICMP error handling for SRv6-VPNs.

Agent protocols often require a participant to establish a decision-time input before acting (issuer standing, key availability, delegated authority, policy profile, consumption state, revocation status, or a downstream outcome). A participant that establishes an input and gets a negative answer has learned a different fact from one that cannot establish the input at all, and collapsing those into one denial changes retry, alerting, audit and incident ownership. This document specifies encoding-independent requirements for preserving evaluation state across agent-protocol boundaries, with concrete representations deferred to a later revision.

Specifies an automatic configuration mechanism for email, calendar and contact user-agent applications. Domain owners publish standardized configuration information that applications retrieve and use to simplify server-setup procedures for end users.

Specifies a data model for synchronizing calendar data with a server using JMAP. Clients can efficiently read, write and share calendars and events, receive push notifications for changes or event reminders, and track changes made by others in a multi-user environment.

Defines version 2.0 of JSCalendar, a data model and JSON representation of calendar data for storage and exchange in calendaring and scheduling. It obsoletes RFC 8984 (version 1.0), aiming to improve interoperability with existing iCalendar-based systems and aligning its definitions with JSContact, including the IANA registry policy, validation requirements and versioning scheme.

Defines the evidence layer: conformance requirements for a local evidence store that records evidence and the relationships between records, keeps digests committed while payloads are referenced separately, and preserves how each record came to be known so a later reader can tell an observation from a claim. It defines the record model, typed links, disclosure and retention semantics, three classes of index and the minimum interface any commitment substrate must supply. Conformance must not require a particular substrate: a Checkpointed Local Log, a SCITT Transparency Service registration or any append-only transparency log can qualify. It defines no sufficiency policy, routing or settlement.

Delivering network services over a Layer 3 tunnel assumes the right setup is provisioned over the links connecting customer termination points and the provider network; that setup is the attachment circuit (AC) and the underlying link is the 'bearer', here a Layer 3 UDP tunnel. This document specifies an extension for a UDP tunnel as a Layer 3 bearer to the YANG service data model for attachment circuits.

Extends the Cedulon reconciler, which reconciles an issuer's signed Spend Receipts against an authenticated extract of a payment rail, to a second population. A Decision Record is signed by the party that decided whether an agent may act, and an Effect Extract is an authenticated list of effects that actually occurred on a channel; an 'allow' must be matched by exactly one effect whose content hash the record named, and a 'refusal' by none. It defines the Decision Record claim set, the Effect Extract shape, where reconciliation departs from the spend rules, the finding codes and a media type. This revision adds per-deployment checkpoint signing and records a second implementation; the text is provisional.