Summary

  • The current V6OPS draft defines IPv6-Only by actual native use inside a stated scope, not by installed protocol support and not by the condition of an entire network.
  • IPv4 can still be carried over IPv6, supplied as IPv4-as-a-Service, translated by NAT64 or CLAT, exposed through an upstream, or retained in a separate control or management plane without contradicting a bounded IPv6-only claim.
  • A credible transition record should bind every label to its scope, observation, surviving dependencies, exceptions, owner and supersession condition before anyone treats it as evidence of retirement.

One sentence, several networks

“We are IPv6-only” is the sort of sentence that can survive a slide deck long after its operational meaning has dissolved. It may mean that a mobile access link no longer carries native IPv4. It may mean that compute nodes on one data-centre LAN have only IPv6 addresses. It may mean that a particular service accepts IPv6 while a reverse proxy handles IPv4 clients. It may mean that a customer device has temporarily declined a DHCPv4 address. Each statement can be accurate. None establishes, without more, that the network has retired IPv4.

That distinction is the useful centre of the active V6OPS working-group draft IPv6-Only and IPv6-Mostly Terminology Definitions. Revision 02 was posted on 11 September 2026, and the I-D announcement identifies it as a V6OPS work item. The Datatracker currently places it in Working Group Last Call. It is still a working document, not an RFC or proof that the IETF has adopted every sentence as final consensus. Its history and the 01-to-02 comparison matter precisely because the terminology is still being refined.

The draft's strongest move is not to declare a universal end state. It refuses to let the noun “network” conceal the object being described. Its current text says the label concerns actual use within a given scope rather than protocol support installed on a node. A device may support both IPv4 and IPv6 while a particular link natively forwards only IPv6. IPv4 packets may still cross that link by being translated or encapsulated over IPv6. The link can therefore be IPv6-only in the draft's terminology while the service experienced by a user still reaches IPv4 destinations.

This is not semantic indulgence. It is a map of who operates which dependency. A transport label answers one question: what is native here? A retirement claim answers a much larger set: where has IPv4 configuration been removed, which applications no longer require it, which translation services remain, who can restore it, what external destinations still depend on it, and what happens when the bridge fails? Treating the first answer as the second produces a false assurance without anyone needing to make a literally false statement.

Native is not absent

Revision 02 defines IPv6-Only in a scope as a condition in which only IPv6 is native. IPv4 is not configured or managed in that scope, but it may still be transported over IPv6. The draft reserves IPv6-Only-Strict for the stronger condition in which IPv4 is neither native nor transported, encapsulated or translated over IPv6 in that scope.

The added word “strict” carries a great deal of institutional honesty. It exposes a distinction that public transition narratives often blur: removing a native protocol from one layer is not the same as removing the function that protocol still serves. An operator can reduce address consumption and simplify an access network while retaining a deliberate compatibility service. That is real progress. It simply is not the same event as the disappearance of the dependency.

The mechanisms make the boundary concrete. RFC 6877 defines 464XLAT, combining translation functions so IPv4 applications or networks can communicate across IPv6-only access. RFC 6146 defines stateful NAT64 from IPv6 clients to IPv4 servers, while RFC 6147 defines DNS64 synthesis that can help those clients discover translated destinations. RFC 8585 specifies customer-edge requirements for IPv4-as-a-Service transition mechanisms. These are not embarrassing leftovers. They are engineering choices that relocate the compatibility function.

Relocation changes the control surface. Native IPv4 on every access link distributes one set of costs and failure modes. NAT64, DNS64, CLAT or another IPv4aaS arrangement concentrates different ones: translator capacity, prefix discovery, logging, application compatibility, fault isolation and supplier responsibility. A governance record that says only “IPv6-only” hides the change in accountability that made the transition possible.

The data-centre case is equally revealing. RFC 7755 describes SIIT-DC, allowing IPv6-only data-centre nodes to serve IPv4 clients through border relays. It is reasonable to call the internal server network IPv6-only. It is not reasonable to infer that inbound IPv4 demand, relay capacity, address mappings or the operating responsibility for the border function have ceased to exist. The protocol was removed from one interior scope and deliberately preserved at an edge.

The scope is part of the fact

The draft lists access links, segments, hosts, services, control planes, data planes, APIs and management paths because each can carry a different protocol condition. Its examples include an IPv6-only access link feeding a dual-stack customer edge and LAN; an IPv6-only segment behind a dual-stack access link; dual-stack upstreams serving IPv6-only compute nodes; and a mobile device whose packet-data context is IPv6-only while applications and tethered clients see dual-stack connectivity through CLAT and NAT64.

Remove those nouns and the labels collide. “IPv6-only access” and “IPv6-only enterprise” do not make claims of equal breadth. “IPv6-only data plane” does not answer whether routing control, authentication, telemetry, orchestration or out-of-band recovery still uses IPv4. “IPv6-only API” does not answer which protocol the service uses internally. Even a technically careful status can become misleading when a dashboard drops the qualifying scope on its way to an executive report.

This suggests a simple rule: the scope is not metadata attached to the fact. It is part of the fact. A statement with the scope removed is a different statement, and usually a stronger one.

The rule also protects comparisons. Suppose two operators both report that they have reached “IPv6-only.” One means native IPv6 on residential access with centrally provided NAT64. The other means a laboratory segment in which no IPv4 packet can be carried at all. Ranking them on a single maturity ladder would erase both their different objectives and their different residual risks. A scope-aware record lets each transition be evaluated against its own chosen boundary rather than a centrally imposed finish line.

That approach follows the V6OPS charter, which treats deployment guidance as contextual operational work and explicitly includes different environments. It also fits Heng Lu's argument in Minimum Initial Specification, Localized Future Decision, Voluntary Adoption: the shared layer should remain small enough for local actors to make and revise consequential choices. A precise vocabulary supports that decentralization. It does not replace the local evidence needed to know what was actually chosen.

IPv6-mostly is an allocation rule

The draft defines IPv6-mostly as a dual-stack scope with NAT64 and DHCPv4 option 108, optionally with DNS64, that can host IPv4-only, dual-stack and IPv6-only clients together. IPv4 becomes available on demand rather than by default. That is not a percentage. It is a rule for allocating a scarce compatibility resource according to host capability and configuration.

RFC 8925 makes the interaction explicit. A capable DHCPv4 client asks for option 108. If the network returns a valid value, the client can forgo the offered IPv4 address and stop DHCPv4 configuration for the stated interval or until a new network-attachment event. Capability is per interface. The same host can behave differently on another link, and an IPv4-requiring host must not make the request.

This matters for governance because neither the option nor a low count of assigned IPv4 addresses proves a permanent end state. The signal records a bounded willingness under current conditions. The timer is reversible. A changed attachment can reopen the decision. A segment may continue supporting legacy devices. A NAT64 service may remain essential even when most hosts no longer hold an IPv4 address.

Counting IPv4 leases can be useful, but it measures allocation, not every dependency. Counting native IPv4 packets measures another layer. Inventorying translators measures another. Testing whether required destinations remain reachable measures an outcome. No single number can carry all four meanings without an explicit claim model.

A scope-and-dependency register

The appropriate evidence object is modest. It need not expose topology, customer identities, addresses, configuration secrets or traffic volumes. It should preserve enough structure to stop a true narrow claim from becoming a false broad one.

For each transition label, an operator could record:

  1. the exact subject: service, interface class, access link, VLAN, application cohort, data plane, control plane, management path or whole network;
  2. the label and vocabulary version used, including whether the claim is IPv6-only, IPv6-mostly, dual-stack or IPv6-only-strict;
  3. the native forwarding condition and the observation method that supports it;
  4. the time window or configuration release for which the observation holds;
  5. remaining IPv4 transport, translation, encapsulation, addressing or external-reachability dependencies;
  6. NAT64, DNS64, CLAT, SIIT-DC, proxy or other compatibility functions on which the stated outcome depends;
  7. named exceptions, including legacy hosts, control systems, vendor tools and out-of-band recovery;
  8. the owner of each remaining dependency and the owner authorized to change the label;
  9. the expected failure and rollback path;
  10. the evidence that would justify the next label, plus the date and authority for superseding this record.

Call it a scope-and-dependency register, not a certificate. The difference is important. A certificate invites readers to assume a completed universal condition. A register preserves a series of bounded, revisable decisions. It can show progress without manufacturing finality.

The register should also retain disagreement. Engineering, security, product and finance teams may assign different significance to the same residual IPv4 function. One group may see NAT64 as a stable service; another may treat it as a concentration risk; a third may value the IPv4 addresses released. The record need not settle that disagreement centrally. It should make the underlying facts and accountable owners visible enough that each actor can reason from the same operational boundary.

That is the practical force of The Policy Mirror: policy claims should reflect the systems and incentives that actually operate, rather than substituting a declared label for reality. “IPv6-only” is most trustworthy when it remains small—an exact description of one chosen scope. It becomes fragile when used as institutional decoration for a transition whose dependencies have merely moved.

What the evidence does not show

Nothing in the current draft establishes that a named operator has misstated its deployment. The document does not audit a production network. It does not prove the prevalence, performance or economics of any transition mechanism. Its Working Group Last Call state does not make it a final RFC, and an eventual informational publication would still not certify conformance by any organization.

Nor does this analysis argue that every remaining IPv4 path should be removed immediately. Translation can be the mechanism that makes local IPv6 deployment possible without excluding users or applications. The accountable question is not whether a compatibility bridge exists. It is whether the institution knows where it exists, who owns it, what outcome it enables and what claim can honestly be made while it remains.

An IPv6-only link can be a substantial achievement. It is also only a link. Keeping both truths in the same record is how technical progress becomes governable evidence.

Sources