Summary

  • Revision 28 of a v6ops working draft addresses withdrawal, rule visibility and the boundary around a default mapping rule. The default itself was already in revision 27.
  • Removing a specific rule for new conversions can expose a 0.0.0.0/0: Pref6(PE) fallback; the destination of the next packet depends on what remains configured.
  • A fallback across an administrative boundary requires an explicit bilateral agreement, while the egress needs a complete IPv4 forwarding view that does not send recovered packets back into the framework.

The packet that still moves

The proposed multi-domain underlay carries residual IPv4 traffic through a limited IPv6-only network. An ingress provider edge selects an address-mapping rule and translates at the edge; the underlay then forwards without a per-flow conversion gateway in its path. One operator or cooperating operators may form the domain. The draft expressly does not offer this mechanism to the open Internet. Prefix coordination, common ICMP filtering, trusted ingress edges and existing bilateral arrangements are preconditions, not guarantees created by the document.

That distinction becomes visible during a withdrawal. A specific IPv4 block may have been mapped to a particular IPv6 prefix and egress. If its rule is withdrawn, revision 28 recommends removing it immediately for new conversions, with a configurable, seconds-scale grace period possible for packets already in flight. The next new packet does not inherit the old route by moral right. If a default mapping is configured, it can take over. Otherwise the draft calls for a drop and an ICMP or ICMPv6 error. A change log saying “rule removed” is therefore insufficient to explain actual forwarding: the remaining table and default configuration matter.

The draft's 0.0.0.0/0: Pref6(PE) rule is a catch-all for IPv4 destinations lacking a more specific mapping. It can preserve service in a narrow domain, but also concentrate traffic at a less suitable egress, produce congestion and enlarge a hijack target. This was not invented in revision 28. Revision 27 already set out the fallback and its risks. The new revision gives much more explicit treatment to manageability, withdrawal and loop prevention. Treating an old fallback as a newly standardised rescue protocol would misstate both the history and the status of the text.

Who can choose the other exit?

Revision 28 says a default rule must not be advertised across an administrative boundary without an explicit bilateral agreement. This is narrower than saying that any cooperating autonomous systems have a permanent mutual right to absorb one another's unmatched traffic. An agreement needs to identify which domain and prefix scope it covers, which provider edge may receive the traffic and how a change is authorised. The draft does not supply a public registry or a standardised agreement record.

It also keeps protocol extensions for rule distribution outside the framework, while requiring a suitable mechanism to preserve rule fields, support scope and filtering, authenticate origin and reject unauthorised bindings.

Imagine operator A withdrawing the specific rule for an IPv4 block while operator B's provider edge remains configured as A's default. A may see packets leaving its ingress; B may see them arrive. Neither observation alone proves that B is still authorised for that block, has capacity for the residual flow or can deliver it onward. A bilateral agreement is a control over this fallback, not a caption attached to successful forwarding. It must be checked against the exact rule and the current configuration on both sides. Conversely, a local control record cannot unilaterally bind a peer.

The participating operators must each be able to confirm the scope they accepted.

The route back into the machine

The draft's loop warning is more precise than a generic warning about routing instability. At the default egress, translation restores an IPv4 packet with no marker saying it already crossed the IPv6-only framework. If that egress's best IPv4 route points toward another participating provider edge, the packet can be mapped again. Repetition can consume capacity and produce a loop even if the traffic appeared to survive the original rule withdrawal. An IPv4 TTL or IPv6 hop limit eventually bounds the damage; it does not make the forwarding choice correct.

Revision 28 therefore says the default egress must have a complete IPv4 forwarding view for traffic it attracts and must not resolve the destination back into a framework-reentering path. Monitoring, rate limits and ACLs are also relevant to the catch-all rule. A credible pre-change test would sample affected destinations, inspect the egress's real best routes and prove where translated traffic leaves the participating domain. A post-change test would compare counters and errors with the expected path. Neither the draft nor its Datatracker page reports a live failure or a deployed implementation that has passed such a test.

What a bounded change record would show

The draft recommends version or timestamp information for mapping rules, MR-DB consistency summaries, change notifications, per-rule counters and management access. These are useful pieces of a proof, not evidence that the proof already exists in every network.

Daniel Kade's editorial proposal is a small bilateral withdrawal-and-fallback record: the withdrawn prefix and rule version, both operators' accepted scope, the remaining mapping snapshots, the chosen default egress, a forwarding-view and no-reentry result, the handling of in-flight packets, observed default-rule counters and ICMP errors, named change owners and a rollback trigger. It is not an IETF-defined packet field, mandatory form or claim that a particular operator uses such a record.

This record would separate three events that are easy to collapse. First, one mapping stops being eligible for new conversion. Second, another mapping or a drop policy determines what happens next. Third, a cross-domain egress carries the traffic only if its authority and route are still valid. A successful packet delivery can support the third observation, but it cannot replace the first two proofs. A quiet counter may simply indicate that no relevant traffic arrived. A full counter may indicate fallback use without establishing permission. The most important evidence is the join between rule state, agreement scope and actual route outcome.

The text remains an active v6ops Internet-Draft intended as Informational, at IESG Evaluation AD Followup when checked, with unresolved DISCUSS positions. It is guidance and requirements from an operator perspective, not an approved RFC, a completed protocol specification or evidence that any two operators have signed the required agreement. The governance lesson is nevertheless immediate: when a default exit keeps packets moving after a rule disappears, continuity is a new decision to be explained, not a self-validating safety signal.

Sources