IETF Internet-Drafts & RFCs — Daily Digest

Run 2026-09-12 (UTC) · Window: 2026-09-10 → 2026-09-12 (last 48h) · All working groups (100% coverage)
41 drafts 0 RFCs 41/41 drafts with official abstract Published at https://ietf-drafts-ok.pages.dev

Newly published RFCs

No RFCs were published in this window. The ietf-announce archive shows no RFC-publication announcements in the 48h window. The most recent one, RFC 10039 (“Interconnecting EVPN and IPVPN Domains”), is dated 2026-09-09, just outside the window.

Drafts

2026-09-11

draft-chen-sidrops-sispi-06 Individual rev -06 abstract
A Profile of Signed SAVNET-Peering Information (SiSPI) Object for Deploying Inter-domain SAVNET

Defines a “Signed SAVNET-Peering Information” (SiSPI) object, a CMS-protected content type carried inside the RPKI. A SiSPI object is a digitally signed attestation for a single Autonomous System that participates in inter-domain SAVNET. A valid object confirms that the holder of the listed AS number has published its participation in inter-domain source address validation and its willingness to establish SAVNET peering relationships. It gives inter-domain SAVNET a verifiable, RPKI-anchored basis for discovering which ASes have opted in.

Attestation-Bound Execution Finality for GPU, AI Accelerator, DPU, SmartNIC, and Confidential-Computing Infrastructure

Argues that remote attestation can prove a CPU, GPU, accelerator, DPU or SmartNIC runs expected firmware and configuration, but says nothing about the operations that environment later emits. It proposes an architecture where consequential operations begin as non-effective Candidate Acts; an Execution-Finality Validator weighs their arguments together with the platform's Attestation Result, workload identity and policy, then issues an act-bound, single-use Execution Handle. A Finality Sink verifies the handle at the non-bypassable boundary where the act gains external effect, blocking swap, mutation or replay. It needs no silicon, microcode or firmware changes and ships a software-only reference implementation not yet run on vendor confidential-computing hardware.

Attestation-Bound Execution Finality for GPU, AI Accelerator, DPU, SmartNIC, and Confidential-Computing Infrastructure

Argues that remote attestation can prove a CPU, GPU, accelerator, DPU or SmartNIC runs expected firmware and configuration, but says nothing about the operations that environment later emits. It proposes an architecture where consequential operations begin as non-effective Candidate Acts; an Execution-Finality Validator weighs their arguments together with the platform's Attestation Result, workload identity and policy, then issues an act-bound, single-use Execution Handle. A Finality Sink verifies the handle at the non-bypassable boundary where the act gains external effect, blocking swap, mutation or replay. It needs no silicon, microcode or firmware changes and ships a software-only reference implementation not yet run on vendor confidential-computing hardware.

draft-nir-ipsecme-big-payload-08 Individual rev -08 abstract
A Larger Internet Key Exchange version 2 (IKEv2) Payload

IKEv2 messages are built from payloads, each limited to 64KB by a two-byte length field. That is usually enough, but several payloads may need to be larger. This document updates RFC 7296 by defining an extension that allows larger IKEv2 payloads, removing the 64KB ceiling where implementations require it.

draft-ietf-tls-tlsflags-18 WG TLS rev -18 abstract
A Flags Extension for TLS 1.3

Many proposed TLS extensions carry no information beyond a one-bit “feature supported” signal, yet each costs four octets on the wire. This document defines a flags extension for TLS 1.3 that packs such boolean indications at an average marginal cost of about one bit each, providing as many flag extensions as needed at 4 octets plus the position of the last set bit divided by 8. It reduces handshake overhead for the growing set of signal-only extensions.

draft-abinabraham-vrrp-unicast-03 Individual rev -03 abstract
Unicast Support for the Virtual Router Redundancy Protocol (VRRP)

VRRPv3 (RFC 9568) assumes multicast operation on a shared LAN, but some deployments need the first-hop redundancy function yet cannot use multicast for advertisements. This document updates RFC 9568 with an optional configured unicast mode in which VRRPv3 advertisements are sent to configured peer addresses instead of the VRRP multicast group. The packet format, state machine, protocol number, virtual IP semantics and Virtual Router MAC behaviour all remain unchanged from RFC 9568.

draft-pinto-agent-authz-contestability-01 Individual rev -01 abstract
Contestability Bindings for Authorized Agent Actions

Authorization artifacts and receipts can prove that a permission existed and was exercised, but they do not tell an affected party where an authorized agent action can be contested, which procedure applies, or who chose the forum. This document defines a transport-independent Contestability Binding that commits an authorization to a versioned Contestation Parameters Object naming the forum, submission mechanism, standing policy, procedure, time bounds and selection evidence. A deterministic verifier validates the binding and classifies forum-selection provenance as unilateral, multiparty, externally selected or indeterminate. It makes contestation parameters identifiable and resistant to post-action substitution, without deciding standing, resolving a dispute or establishing legal enforceability.

2026-09-10

draft-mcgraw-httpapi-agent-budget-04 Individual rev -04 abstract
The Delegation HTTP Authentication Scheme for Request-Bound Authority

Delegated software agents increasingly issue HTTP requests that spend, consume, disclose or actuate on behalf of a principal, yet existing HTTP auth only shows that a requester holds a credential. This document defines the “Delegation” HTTP authentication scheme, response semantics for delegated-authority challenges using existing status codes and Problem Details, the Delegation-Proof field, and a COSE/CBOR proof-carriage model for request-bound authority. The initial Budget profile proves bounded authority to spend or consume metered units; the scheme is algorithm-agile with ML-DSA-65 as baseline. It adds a mandatory preflight flow so large proofs need not be multiplexed with request bodies, and keeps the HTTP mechanism separable from the Budget profile.

draft-ietf-nvo3-rfc7348bis-07 WG NVO3 rev -07 abstract
Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks

Specifies VXLAN, an overlay that carries virtualized Layer 2 networks over a Layer 3 underlay for multi-tenant virtualized data centers, cloud providers and enterprises. This revision obsoletes RFC 7348 and moves the VXLAN specification into the IETF document stream, enabling standardized extensions that add to the VXLAN header and register them with IANA. The format and processing described remain fully compatible with the deployed protocol in RFC 7348.

draft-chuang-dkim2-sender-policy-00 Individual new -00 abstract
DKIM2 Sender Policy

Updates DMARC (RFC 9989) for DKIM2. Because DKIM2 verification supports MTA relay forwarding with message modifications across multiple MTAs, this document extends DMARC to cover those scenarios. It generalizes and separates the enforcement policy from the constraint-validation policies that DMARC ties to RFC 5322 From alignment, and provides a way for MTAs to declare DKIM2 support through the DMARC DNS policy record, helping protect DKIM2 against downgrade attacks.

A YANG Data Model for Passive Network Inventory

Presents a YANG data model for tracking and managing passive network inventory — the non-powered physical plant such as cabling and passive components. The model augments the base network inventory model, extending inventory management to elements that the active equipment models do not cover.

draft-ietf-acme-rats-02 WG ACME rev -02 abstract
Automated Certificate Management Environment (ACME) Remote Attestation Identifier and Challenge Type

Describes an approach in which an ACME server can challenge an ACME client to provide Evidence, Endorsements or an Attestation Result following the RATS framework, in any format supported by the Conceptual Message Wrapper (CMW). The server can optionally request specific claims it wants attestation for. This ties certificate issuance to verifiable remote-attestation state about the requesting client.

Transaction Token Authorization Grant Profile for OAuth Identity and Authorization Chaining

Defines a profile of OAuth Identity and Authorization Chaining Across Domains that uses a Transaction Token (Txn-Token) as the subject token in a Token Exchange request to obtain a JWT Authorization Grant for crossing a trust boundary. A Txn-Token is scoped to a single trust domain and represents the full authorization context of an in-progress transaction, whether started by a user API call, an internal event or an automated workload. The profile shows how a service can present its Txn-Token to obtain a grant that carries context across the boundary and lets a partner service receive an access token without exposing internal credentials or token formats.

draft-ietf-nfsv4-uncacheable-files-13 WG NFSV4 rev -13 abstract
Adding an Uncacheable File Data Attribute to NFSv4.2

NFSv4.2 clients cache file data client-side to improve performance, but there is no standardized way for a server or administrator to indicate that particular file data must not be cached for performance or correctness reasons. This document introduces a new file-data caching attribute for NFSv4.2; files marked with it are meant to be accessed with client-side data caching suppressed, supporting workloads that need predictable data visibility. It extends NFSv4.2.

draft-ietf-netconf-quic-call-home-01 WG NETCONF rev -01 abstract
NETCONF Call Home and RESTCONF Call Home Using QUIC

Extends NETCONF Call Home and RESTCONF Call Home (RFC 8071) to run over the QUIC transport (RFC 9000). Call Home lets a managed device initiate the management connection to a NETCONF or RESTCONF client; this short specification defines how that pattern operates on top of QUIC.

draft-bruhns-securitytxt-product-security-00 Individual new -00 abstract
Product Security Fields for security.txt

Registers two new fields for the security.txt format of RFC 9116: “Product-Security” and “Product-Security-Policy”. They let an organisation publish a dedicated contact and disclosure policy for vulnerabilities in the products it manufactures, distinct from the contact for its own web presence and infrastructure. Both fields are optional and fully backward compatible with existing security.txt parsers.

draft-zehavi-oauth-authz-req-del-chain-01 Individual rev -01 abstract
OAuth Authorization Request Delegation Chain

Brokered OAuth redirect authorization requests place intermediary authorization servers between a downstream client and the upstream server that gets user consent and issues tokens, creating risk because the upstream server sees only the immediate client. This document defines an OAuth 2.0 profile that carries a verifiable, signed authorization-request delegation chain as a RAR authorization_details object. Each node is a JSON object signed by an attesting authorization server via detached JWS, attesting its validated client and hash-linked to the previous node, letting the upstream server validate the integrity of the visible delegation path and apply policy before issuing tokens.

draft-ietf-netconf-quic-call-home-00 WG NETCONF new -00 abstract
NETCONF Call Home and RESTCONF Call Home Using QUIC

Extends NETCONF Call Home and RESTCONF Call Home (RFC 8071) to run over the QUIC transport (RFC 9000). Call Home lets a managed device initiate the management connection to a NETCONF or RESTCONF client; this short specification defines how that pattern operates on top of QUIC.

draft-ietf-mpls-stamp-pw-21 WG MPLS rev -21 abstract
Encapsulation of Simple Two-Way Active Measurement Protocol for LSPs and Pseudowires in MPLS Networks

Specifies how to encapsulate STAMP (RFC 8762) and its optional extensions (RFC 8972) in MPLS networks, for point-to-point LSPs and single-segment pseudowires, with or without an IP/UDP header, so test packets follow the same forwarding and ECMP behaviour as the measured data traffic. It defines two new MPLS Generic Associated Channel (G-ACh) types and updates RFC 8762 and RFC 8972 to let STAMP run without an IP/UDP header over MPLS, with the resulting changes to handling of the STAMP session identifier, IPv4 TTL / IPv6 Hop Limit and TLV extensions. It targets deployment within a single administrative domain.

draft-iplir-protocol-10 Individual rev -10 abstract
IPlir Network Layer Security Protocol

Specifies the IPlir network-layer security protocol, describing how it provides a set of security services for traffic over public and corporate networks that use the TCP/IP stack. By its abstract it is a network-layer security mechanism; the document sets out the services offered and how they apply to IP traffic.

draft-ietf-tiptop-quic-profile-00 WG TIPTOP new -00 abstract
QUIC Profile for Deep Space

Deep-space communications involve very long one-way delays (Earth-to-Mars is roughly 4–20 minutes) and often intermittent links, so QUIC's default transport parameters, tuned for the terrestrial Internet, are unsuitable. This document defines a QUIC profile for deep space: how to estimate and set transport parameters, advice to mission operators and application developers on configuring QUIC for the deep-space case, and guidance to QUIC stack developers on exposing the required parameters through their APIs.

draft-ietf-v6ops-6mops-10 WG V6OPS rev -10 abstract
IPv6-mostly Networks: Deployment and Operations Considerations

Describes an “IPv6-mostly network” deployment scenario, where IPv6-only and IPv4-enabled endpoints coexist on the same segment, VLAN or SSID. The approach enables a smooth, incremental transition from dual-stack toward IPv6-only by letting IPv6-capable devices stay IPv6-only while the network seamlessly supplies IPv4 to the endpoints that still need it, covering the deployment and operational considerations involved.

draft-traviss-evil-byte-00 Individual new -00 abstract
The Evil Byte: A Security Octet for the IPv4 and IPv6 Headers

A tongue-in-cheek (April-1st-style) document that obsoletes RFC 3514's single “evil bit”, arguing that senders cannot be relied upon to set it and that one bit cannot capture the range of Evil on today's Internet. It replaces the evil bit with an eight-bit “Evil Rating” carried in every IPv4 and IPv6 packet, computed not by the sender but by a Morality-Inspecting Trusted Middleman from the sender's AS, protocols, content, name and time of day. Servers reject evil clients, clients discard evil servers' responses, and each AS's Evil is continuously re-estimated by an Elo system run by a central Evil Rating Authority — including carriage over avian carriers.

draft-arsentev-agent-run-metrics-00 Individual new -00 abstract
Agent Run Metrics: A JSON Interchange Format for Resource Accounting of Language-Model Agent Runs

Defines Agent Run Metrics, a JSON interchange format describing the resource consumption of a single language-model agent run and its individual steps, plus a small set of exactly specified derived quantities. It notes that agent runs re-send the same context on every step, so cost is dominated by repeated input, and today is reported in incompatible vendor-specific shapes. The format states normatively that one reported step equals one completed model invocation, and defines how delegated sub-run consumption is attributed without double-counting. It carries only counters, timing and cost — deliberately excluding prompt and completion content — and registers a media type plus IANA registries for extensible enumerations.

draft-dnoveck-nfsv4-security-16 Individual rev -16 abstract
Security for the NFSv4 Protocols

Describes the core security features of the NFSv4 family of protocols across all minor versions, including the use of RPC-provided security on a per-connection basis. Authorization aspects tied to Access Control Lists are deferred to a separate document. The current revision is intended largely to drive working-group discussion of existing NFSv4 security issues and to frame how to address them; once published as RFCs, this document and the ACL companion would update and supersede the security descriptions in existing minor-version specifications such as RFC 7530 and RFC 8881.

draft-claise-green-capability-discovery-01 Individual rev -01 abstract
A YANG Data Model for Power State Capability Discovery

Defines a YANG data model that augments the system-capabilities model of RFC 9196 so a network element can advertise, per hardware component, the set of power states it supports along with a static characterization of each: expected and maximum power drawn, and time to enter and exit. It complements the operational GREEN Power and Energy model, which reports current state and measured power but not which states exist or their costs. Anchored to the RFC 8348 hardware inventory and reusing GREEN power-state identities, and being static, it can be supplied as YANG instance data (RFC 9195) so an Energy Management System learns a platform's power-state capabilities before the equipment is deployed or even powered on.

draft-das-purpose-execution-finality-02 Individual rev -02 abstract
Data-Purpose Laundering Prevention: Execution-Finality for Preventing Cross-Domain Data Reuse

Targets “data-purpose laundering”: data or capability granted for one stated purpose being consumed for another because nothing in the protocol path could refuse it or record what was actually authorized. It argues that today's common control — a self-asserted purpose string in a token or API field — is evidence of intent, not proof of authority, and fails when the requester lies. The architecture makes an undeclared or purpose-switched use detectable and refusable at the point of use and produces verifiable evidence of what was authorized, so later liability can be argued from evidence. It accepts a bounded evaluation latency as a deliberate “seat belt” trade-off, and ships a runnable reference implementation.

draft-kay-dawn-use-cases-01 Individual rev -01 abstract
Use Cases and Applicability for Discovery of Agents With Names (DAWN)

Describes use cases and applicability for Discovery of Agents With Names (DAWN). It illustrates how clients discover AI resources and obtain the minimum information needed for subsequent interaction — within a local network, within an organisation, or between cooperating organisations that share trust relationships. The document explicitly does not define a discovery protocol, a registration procedure, a selection algorithm or an agent-to-agent communication protocol; it scopes the problem rather than solving it.

draft-ietf-mailmaint-smtputf8-syntax-05 WG MAILMAINT rev -05 abstract
SMTPUTF8 Email Addresses

RFC 6532 extends internet email to allow UTF-8 in many contexts. This document slightly restricts the set of allowed addresses in header fields and thereby simplifies their use. It is one of a two-document pair: this one gives globally applicable, straightforward implementation rules, while a companion offers more sophisticated rules accommodating regional usage patterns and describes addresses readable and shareable within specific communities and locales.

draft-besleaga-sustainability-wellknown-06 Individual rev -06 abstract
The 'sustainability-data' Well-Known URI

Defines the “sustainability-data” well-known URI, a uniform out-of-band convention for web servers and digital services to publish aggregated environmental-impact, energy-consumption and carbon-footprint metrics for a declared reporting subject — typically the publishing origin itself. Each origin publishes a single cacheable JSON document, described by formal schemas and discoverable at a fixed location without prior arrangement, so disclosures can be located, validated and ingested automatically. Publication is voluntary and the metrics are self-asserted claims linked to the publisher's methodology and supporting evidence.

draft-das-rats-frontier-model-extraction-04 Individual rev -04 abstract
An Execution-Finality Architecture for Controlling Release and Limiting Unauthorized Extraction and Distillation of Sensitive Frontier AI Model Information

Proposes a hardware-rooted defense against IP theft of frontier AI models, meant for deployment by model creators themselves rather than for everyday use. It protects high-priority, dual-use Sensitive Model Information — probabilities, embeddings, cached intermediate state, hidden representations, activations and metadata — whose repeated unauthorized release can ease model reconstruction, imitation or distillation. Sensitive information may be computed while staying a non-effective Candidate Release; external release occurs only after release-specific validation, checks on rollback-resistant extraction state, atomic consumption of bounded authority and verification at a Finality Sink. It does not claim universal prevention nor restrict ordinary model output, and RATS can attest that the expected controls are present.

draft-das-agentic-execution-finality-02 Individual rev -02 abstract
Tool Selection Is Not Execution: Finality for Agentic Tool Dispatch in High-Risk AI Systems

Addresses high-risk agentic AI where existing controls — allowlists, OAuth tokens, sandboxes and safety filters — decide whether an agent may reach a tool, but not whether a specific call with particular arguments should execute now. That gap exposes systems to prompt injection, poisoned retrieval, malicious tool responses and unauthorized delegation. The document specifies a dispatch-time verification gate: a model-generated call stays a non-binding Candidate Act; a Protected Enforcement Domain binds agent, tool, arguments, purpose, destination, instruction source and policy state, then issues scoped single-use authority; a Tool-Dispatch Finality Sink verifies and consumes it immediately before execution. It applies across support, coding, payments, clinical, security and browser-automation agents, with a reference implementation.

draft-das-protocols-enterprise-ai-01 Individual rev -01 abstract
Architecting Resilience for High-Risk Enterprise AI: Preventing Data Reconstruction, Exfiltration, and Unauthorized Consequence (DAS Protocols)

Presents the DAS Protocols enterprise-AI architecture for high-risk, mission-critical deployments (not consumer use), arguing that a compromised enterprise AI server can become a continuously updated reconstruction engine correlating records, defects, finances and communications into exfiltrable intelligence. It introduces Execution–Consequence Decoupling via three pillars: Decomposition of Authority across independent identity, content, relationship and cryptographic vaults; Mandatory Mediation of every consequence-bearing Candidate Output; and Technical Non-Completability so computation can finish without completing external consequence. Reconstruction is governed by a non-bearer Reconstruction Authorization Object bound to attested context, and outputs are sealed until re-verified, so compromise of the compute plane cannot auto-escalate into unrestricted reconstruction. It supplies JSON Schemas for the core objects.

draft-das-eu-ai-act-execution-enforcement-02 Individual rev -02 abstract
Technical Enforcement of the EU AI Act and Global AI Laws for High-Risk AI Systems Without Relying on Paper Policies

Argues that paper-based AI-governance regimes — the EU AI Act plus comparable laws in South Korea, Japan, China, Texas, Colorado, Brazil and Canada — can describe what an operation should do but cannot make a machine technically incapable of doing otherwise at machine speed. It describes an execution-finality architecture that turns an already-decided governance requirement into a machine-verifiable precondition: a consequential AI operation is held as a Candidate Act in a Non-Effective State until a Protected Enforcement Domain validates the machine-readable constraints (identity, operation, target, oversight state, transparency, policy epoch, revocation), after which a Finality Sink re-verifies before effect; absent or stale authority defaults to no effect. Jurisdiction-specific profiles feed the same mechanism, and it explicitly does not make legal determinations. A public reference implementation accompanies it.

draft-das-eu-ai-act-execution-enforcement-01 Individual rev -01 abstract
Technical Enforcement of the EU AI Act and Global AI Laws for High-Risk AI Systems Without Relying on Paper Policies

Argues that paper-based AI-governance regimes — the EU AI Act plus comparable laws in South Korea, Japan, China, Texas, Colorado, Brazil and Canada — can describe what an operation should do but cannot make a machine technically incapable of doing otherwise at machine speed. It describes an execution-finality architecture that turns an already-decided governance requirement into a machine-verifiable precondition: a consequential AI operation is held as a Candidate Act in a Non-Effective State until a Protected Enforcement Domain validates the machine-readable constraints (identity, operation, target, oversight state, transparency, policy epoch, revocation), after which a Finality Sink re-verifies before effect; absent or stale authority defaults to no effect. Jurisdiction-specific profiles feed the same mechanism, and it explicitly does not make legal determinations. A public reference implementation accompanies it.

A SCITT Profile for Physical-Site Engagement Receipts

Defines a SCITT profile for Physical-Site Engagement Receipts (PSER): tamper-evident, signed, offline-verifiable records that a specific autonomous or human-directed physical engagement occurred at a real-world site under a defined operating envelope. Each receipt is a SCITT Signed Statement encoded as a COSE single-signer message with a JCS-canonicalized JSON payload covering Site, Operator/Actor, Engagement Window and Envelope, TEE Attestation Evidence, and an Adapter Write-In. It makes a deliberately narrow, checkable claim — that the engagement happened and its evidence was TEE-sealed — not that it was safe or wise, and uses a three-party trust model (Site Owner, TEE silicon vendor, Issuer) that implementations must not collapse into one custodian.

draft-das-digital-sovereignty-finality-02 Individual rev -02 abstract
Digital Sovereignty Without Data Localisation by Separating the Compute Plane from the Authority Plane

Tackles the problem that when data leaves its originating jurisdiction, control can follow the physical location of compute, moving practical authority over data and operations abroad. It proposes separating the Compute Plane from the Authority Plane: computation may remain globally distributed, but a cross-jurisdiction operation is a Candidate Act held Non-Effective until policy, identity, purpose, destination, jurisdiction, runtime and revocation predicates are validated, producing a scoped Finality Authority verified at a Finality Sink before any external effect. Missing, stale, revoked or mismatched authority means no protected effect. This gives digital sovereignty without mandatory data localisation — compute anywhere while authority over sensitive external effects stays independently governed — without prescribing which jurisdiction's law prevails.

The Missing Protocol Layer for the Agentic Internet: Computation Is Not Authority

Frames execution finality as a missing protocol layer for the agentic Internet, observing that TLS authenticates the channel, OAuth proves a valid grant, HTTPS proves origin identity and EMV proves a transaction-specific cryptogram — but none answers whether a specific act, from this model or agent, at this moment, is authorized to become externally effective. It treats machine-generated operations as non-effective candidates until a Protected Enforcement Domain validates act-specific authority (purpose, destination, jurisdiction, freshness, revocation, policy epoch, runtime integrity), then issues narrowly scoped non-bearer Execution Handles bound to specific Finality Sinks. Its falsifiable central claim: computation does not itself confer authority for consequence, and current Internet layers lack that structural separation.

draft-tempobono-protectchain-00 Individual new -00 abstract
ProtectChain: An Anchored Permissioned Ledger for Proof of Anteriority of Authored Works

Specifies ProtectChain, a permissioned, hash-chained and cryptographically signed ledger that produces verifiable evidence a digital work existed no later than a given time under an authorship claim by an identified account. The ledger records only cryptographic digests and pseudonymous identifiers — the work itself never enters it — and because all initial authorities may be run by one organization, every block is also anchored to independent public time references so the date bound does not rest on the operator's word. The document is explicit about limits: an anchor shows data existed no later than an instant; it does not prove the exact creation time, nor authorship or originality.

A YANG Data Model for Passive Network Inventory

Presents a YANG data model for tracking and managing passive network inventory — the non-powered physical plant such as cabling and passive components. The model augments the base network inventory model, extending inventory management to elements that the active equipment models do not cover.

draft-dong-sidrops-rpki-rtr-moa-pdu-01 Individual rev -01 abstract
IPv6 Mapping Prefix PDU for the RPKI-Router Protocol

Defines a new PDU type for the RPKI-to-Router protocol to convey Mapping Origin Authorization (MOA) information from RPKI caches to routers. The new “IPv6 Mapping Prefix” PDU carries the authorization mapping between one or more IPv4 prefixes and their corresponding authorized IPv6 mapping prefix. This lets routers perform Mapping Origin Validation (MOV) for IPv4-to-IPv6 address-mapping announcements in IPv6-only underlay networks.