Summary

  • Revision 01 of draft-dong-sidrops-rpki-rtr-moa-pdu, posted on 9 September 2026, adds rules for split full and subset withdrawals, cache refresh and expiry, and serial-number changes. It is an active individual Internet-Draft, not a SIDROPS Working Group document, an IETF standard or a deployed system.
  • The draft says the order and fallback between MOA validation and IPv6 ROA validation belong in an expected companion specification. A minimum two-plane outcome matrix should make that decision explicit without turning local routing policy into a central command.

Imagine that one signed MOA authorizes an IPv6 mapping prefix for three IPv4 prefixes. A cache may fit the first two into one transport message and the third into another. Later, the holder withdraws only the first and third. The withdrawal messages do not have to reproduce the old partition. The router has to compute their union, remove exactly those two authorizations and retain the second.

That small state transition is the most important addition in revision 01 of the proposed IPv6 Mapping Prefix PDU. The draft now knows how a one-to-many authorization can be divided for transport without making its packet boundaries part of the authority itself. It also knows that authority learned from an unreachable cache cannot live forever.

The previous revision did not contain these rules. The official comparison shows added canonical ordering, split-withdrawal treatment, a lifecycle section and a new scope boundary for validation. The change is operationally substantive even though the document remains short.

Its procedural state needs equal precision. The Datatracker record and document API classify it as an active individual submission. There is no IETF stream, responsible Area Director, shepherd or intended standards level. The history records Guozhen Dong's revision on 9 September; the submission entry supplies the document date and authorship. sidrops in the filename identifies the intended discussion area. It does not transfer the status of the separate SIDROPS Working Group MOA profile to this PDU draft.

Five states must not be compressed into one authorization

The architecture is easiest to govern when its objects remain separate.

First, an address holder creates a signed MOA. The current MOA profile describes one IPv6 mapping prefix authorized to originate mappings for one or more IPv4 prefixes. If the holder wants several IPv6 mapping prefixes to map the same IPv4 set, it issues several MOAs. The object is therefore an authorization with a defined subject and scope, not a route and not a forwarding result.

Second, relying-party software validates that object. The profile imports the signed-object checks in RFC 6488 and adds a MOA-specific test: every IPv4 prefix must fall within the IP resources in the embedded end-entity certificate. The profile is explicit that the RPKI supplies authorization, not personal authentication or non-repudiation.

Third, a cache derives an IPv6 Mapping Prefix PDU from a validated object. Revision 01 makes the cache responsible for parsing the MOA and for presenting the prefix set in canonical order. The message is a transport projection of validated repository data. Authentication or integrity on the cache-to-router session does not turn the projection back into the signed object.

Fourth, a router installs the received mapping authorization in its local Mapping Origin Validation database. That local entry carries the cache session's current state. RFC 8210, which revision 01 uses as its baseline, says a Serial Number is a logical version of one cache. Serials are not commensurate between caches or protocol versions and need not survive a reset. Protocol version, Session ID and Serial Number together tell the router whether update state can be compared; none of the three independently proves the holder's intent.

Fifth, the router observes a 4map6 BGP announcement and makes a local decision. The current 4map6 draft describes a Mapping rule Database, checks whether the advertised IPv6 mapping prefix is reachable and then installs or updates local state. That is still distinct from the MOA object, the cache PDU and the eventual forwarding behavior.

A conventional ROA is another object, not an interchangeable name. RFC 9582 profiles authorization for an autonomous system to originate routes for address prefixes. The proposed MOA authorizes an IPv6 mapping prefix to originate mappings for IPv4 prefixes. Similar cryptographic plumbing does not erase the difference in the action being authorized.

Revision 01 makes withdrawal independent of packaging

The draft permits a cache to split a large IPv4 set across multiple PDUs. Without a rule for later removal, a router could be forced to remember an arbitrary historical packet layout. Revision 01 avoids that dependency.

For a complete withdrawal, a cache may send one PDU containing all formerly announced prefixes or several PDUs corresponding to the earlier subsets. For a partial withdrawal, one or more PDUs must collectively contain exactly the prefixes being removed and no others. The router treats the union as withdrawn and does not require the number of withdrawal messages to equal the number of announcement messages.

This is good minimum design. Authority belongs to the tuple of mapping prefix and IPv4 prefix set, not to the segmentation chosen for one transmission. Repacketization does not create a new grant, and failure to replay the original segmentation does not preserve an obsolete one.

The lifecycle addition closes a different hole. On Refresh expiry, the router sends a Reset Query and should continue using installed MOA data while waiting. On Retry, it tries again. Once the Expire timer elapses without a successful refresh, it must remove all MOA data and stop making MOA-based MOV decisions until the cache connection is restored. A MOA data change must increment the cache serial so stale or out-of-sync state can be detected.

Expiry is not a withdrawal. A withdrawal is a change delivered by the cache about specified authorizations. Expiry is the router's response to a failure to refresh the cache's whole current view within a bounded time. Nor does either event prove that a corresponding BGP mapping route left every RIB or FIB, that traffic changed path, or that packet delivery recovered. Each is evidence at one layer.

The decisive fork remains outside the document

The profile explains why MOA alone is not enough. Even when the IPv4 holder validly authorizes an IPv6 mapping prefix, a third party could originate the underlying IPv6 prefix. The profile therefore recommends IPv6 ROA validation. The new PDU draft repeats the dependency and then says that the detailed interaction between MOA and IPv6 ROA validation—including validation order and fallback behavior—is outside its scope and belongs in a MOA verification specification expected to accompany the profile.

At the research cutoff, searches of the public Datatracker for MOA document names and Mapping Origin titles found the profile, the PDU proposal and meeting material, but no current document bearing that stated verification function. That is a bounded observation about the public record, not proof that implementers have no private logic or that no later draft will appear.

The missing branch matters because the two planes can disagree. What should a router do when the MOA is valid but the IPv6 ROA result is Invalid? What if the IPv6 result is NotFound? Does one failure block installation, merely lower preference, leave the mapping unevaluated or invoke an operator rule? If cached MOA data is still inside its Expire interval but the IPv6 route changes, which observation time governs? When the cache reconnects, what must be retested before the mapping returns?

These are not questions a Serial Number can answer. A serial says which cache state is newer within one comparable session. It does not rank two authorization systems, supply the reason for an IPv6 validation result, or choose a network's forwarding policy. Exact withdrawal solves deletion; it does not supply precedence.

The controlled-environment premise makes restraint more important, not less. The 4map6 draft says its approach initially targets one operator or a small group of cooperating operators, where parties can resolve accidents collaboratively. It also says broader use would need a dedicated authentication mechanism defined elsewhere. A local agreement can fill a policy gap for one deployment, but its outcome must not be silently presented as a protocol-wide rule.

Publish the two-plane outcome matrix

The minimum missing artifact is a two-plane validation outcome matrix. It can live in a companion specification or an explicit operator profile; it does not need to enlarge the PDU.

Each row should name the MOA object result and reason, the cache endpoint, protocol version, Session ID, Serial Number and observation time, and the IPv6 ROA result for the mapping prefix. It should then state the required evaluation order; whether one result blocks, degrades or leaves the other unevaluated; the local mapping state retained or removed; the operator-policy version; the action taken; and the evidence required for restoration.

The matrix should cover at least a valid MOA paired with Valid, Invalid and NotFound IPv6 results; an invalid or expired MOA; cache data that is stale but still inside the Expire interval; cache data beyond expiry; partial and complete withdrawal; a cache reset; and post-reconnection resynchronization. NotFound must not be smuggled into Valid, and not evaluated must not be reported as a successful test.

This proposal follows the restraint of Heng Lu's Minimum Initial Specification: standardize the smallest interoperation boundary and leave operators room to choose within it. Running Code Primary supplies the companion discipline: keep the operational evidence that shows which rule actually ran. The matrix is my editorial proposal, not language adopted by the IETF or required by the drafts.

Revision 01 has made the authorization's exit path much clearer. It should be credited for that. The next specification should make the decision fork equally visible—before different implementations turn the same signed inputs into incompatible invisible policy.

Sources