Summary

  • draft-ietf-v6ops-framework-md-ipv6only-underlay-28 proposes stateless IPv4/IPv6 conversion at the edges of a cooperating multi-AS IPv6-only underlay, driven by distributed address-mapping rules.
  • Stateless conversion eliminates per-flow translation tables, not the shared control state: rule origin, Conversion Type, MR-DB version, recursive mapping-prefix reachability, source policy, withdrawal and default-egress routing remain separate facts.
  • A safe operating receipt must join the agreement, authenticated rule, per-PE import state, IPv6 route, conversion observation, egress IPv4 view, return path and application result.

An IPv4 prefix is withdrawn at noon. PE-A removes the specific mapping rule immediately. PE-B still holds yesterday's version. PE-C has never learned the specific rule and sends the traffic through 0.0.0.0/0 to a default egress. None of the three devices maintains a per-flow translation table. All three can therefore be described, accurately but misleadingly, as “stateless”. They are not making the same decision.

That is the useful tension in revision 28 of the multi-domain IPv6-only framework. Its Datatracker page, history and current document record identify an active V6OPS Working Group draft posted on 28 September 2026. It is intended as Informational, is in IESG Evaluation and remains work in progress. It offers operator guidance and requirements, not a finished distribution protocol, implementation or deployment result.

The proposed setting is deliberately bounded. Several IPv6-only autonomous systems cooperate to carry residual IPv4 traffic. Translation happens once at the ingress PE and once at the egress PE; core P routers forward IPv6. The mapping between an IPv4 block and an egress mapping prefix, Pref6(PE), tells the ingress where to send an IPv4-embedded IPv6 packet. A Conversion Type says whether the egress supports translation, encapsulation or both.

The framework calls this a limited domain. RFC 8799 gives that model a vocabulary, but the label does not establish the domain's trust. Revision 28 assumes participating operators already possess bilateral agreements, coordinated prefix allocation, common ICMP filtering rules and trusted ingress PEs. Those are prerequisites, not outputs. Mapping prefixes are meant to remain inside the participating boundary, with ingress and egress filters preventing leakage.

This matters because the packet does not carry the agreement. A well-formed IPv4-embedded IPv6 address follows RFC 6052. Correct header and ICMP conversion follows RFC 7915. Neither construction says who was authorised to bind the IPv4 block to that prefix, whether every importing PE accepted the latest rule, or whether the mapping prefix still reaches its claimed egress.

Revision 28 therefore creates an authority chain. A PE may originate a specific mapping rule only for a directly connected customer block, local pool or aggregate for which it is the authoritative or aggregating egress. It must not generate specific mappings for external transit routes. A future distribution mechanism must preserve the rule's fields, scope it at administrative boundaries, authenticate the origin and let receiving PEs reject a binding outside the origin's authorised IPv4 scope.

Origin authentication is necessary but narrower than ownership. It proves which authorised participant asserted a rule under one mechanism. It does not prove that the participant still controls the IPv4 block, that its Conversion Type matches running code, that every receiver imported the announcement, or that recursive routing reaches the same egress. A defensible receipt retains the signed assertion and the local import-policy verdict rather than collapsing both into “the route is trusted”.

Each ingress performs a longest-prefix match in its local mapping-rule database, the MR-DB. Multiple candidates are reduced to one best rule by the underlying routing process. Multipath and anycast egress are outside the framework. The chosen prefix is then used to construct the IPv6 destination; the ingress's own prefix helps construct the source. Core routers forward the resulting IPv6 packet to the egress.

This is where “stateless” does real work and also invites a category error. The PE need not remember a session for every translated flow. But it still holds mapping rules, route state, import policy, source-prefix authority and counters. Removing per-flow memory changes the exhaustion surface; it does not erase control-state consistency. A device can avoid NAT session-table pressure and still exhaust CPU, buffers, bandwidth or MR-DB lookup capacity under hostile traffic.

The design's most consequential rule is recursive. Pref6(PE) must resolve through the IPv6 routing system to the PE that originated it. If reachability is lost, the mapping must be withdrawn or deactivated; traffic must not continue on the stale rule. A green MR-DB therefore does not prove a usable forwarding object. Operators need both the mapping receipt and the route-resolution receipt, observed at the ingress that will act.

The draft recommends versions or timestamps on rules, MR-DB summary exchange, change notifications, per-rule packet counters and management access. These are ingredients for evidence, not one global transaction. A summary can show equal rule sets while one PE's FIB points elsewhere. A counter can show use of a rule without proving the remote egress converted the packet. A withdrawal notification can leave a packet in a configured grace period while another node has already selected the default.

The default is not merely a convenience. When no specific mapping exists, 0.0.0.0/0: Pref6(PE) directs traffic to a designated egress. That can preserve reachability during incomplete distribution, but it turns absence of evidence into an active forwarding decision. High default-rule counters may indicate resilience—or a silent consistency defect. Capacity and security risk concentrate on the same node.

Revision 28 accordingly says a default rule must not cross an administrative boundary without an explicit bilateral agreement. It also identifies a loop that ordinary dashboards can miss. After conversion at the default egress, the restored IPv4 packet contains no marker that it already crossed the framework. If the egress's IPv4 best path returns toward another participating PE, the packet can be mapped again. TTL and hop limit eventually end the cycle; they do not prevent wasted capacity or service failure. The default egress needs a complete IPv4 view for what it attracts and a rule that prevents re-entry.

Source validation is another independent decision. The egress should accept an embedded source only when its IPv6 prefix belongs to an authorised ingress, the embedded IPv4 source agrees with that ingress's rule or policy, and the packet arrived from the expected participating network. BCP 38, RFC 2827 supplies the anti-spoofing principle. Passing the check shows conformance to the deployed predicate; it does not prove the sender's business entitlement or the destination's success.

Control state is only half the path. Translation adds header overhead; fragments can add more. Cross-domain MTU differences and independent ICMP filtering can produce a PMTUD black hole. RFC 6791 helps translate the source of an ICMP error, but it cannot force another operator to pass that error. An MR-DB and IPv6 route can both look correct while large IPv4 flows repeatedly disappear.

The draft positions itself against real boundaries in earlier work. RFC 6992 describes routing for IPv4-embedded IPv6 packets in a single-AS OSPFv3 setting. RFC 8950 carries IPv4 NLRI with an IPv6 next hop but does not define this framework's mapping-prefix uniqueness, boundary filtering or default egress. RFC 5565 addresses an IPv6 transit mesh but documents multi-AS limits. RFC 8585 and RFC 9313 bound access-side IPv4-as-a-Service requirements and trade-offs; they do not create a multi-provider MR-DB.

The operating receipt should therefore preserve at least eight joins: the agreement and participating boundary; authorised IPv4 blocks and Pref6 allocation; authenticated rule and import verdict; rule version in each relevant MR-DB; recursive IPv6 route to the originating egress; source validation and conversion counters; withdrawal/default behavior and egress IPv4 non-re-entry; then return-path and application evidence. Each join answers a different question.

This follows Heng Lu's reality-layer distinction: an agreement, authenticated announcement, installed rule, recursive route, translated packet and service result are not interchangeable. Minimum Initial Specification explains why a common mechanism should standardise the smallest verifiable contract while leaving future local choices open. Running-Code Primacy places operational authority with observed rule versions, routes, counters, errors and outcomes—not with the elegance of a stateless diagram.

Sources