IPv6-mostly: how networks retire IPv4

Running both protocols side by side does not retire either of them. It removes the pressure to. That is the whole difficulty with dual-stack: it was designed as a bridge, it works extremely well, and because it works there is never a week when anything forces the older half to end.

Start with what two protocols cost when both are permanent. There are two addressing plans to design and document. There are two sets of firewall rules that are supposed to express the same policy, written in different syntax by different people at different times, and drifting apart quietly from the day they are deployed. There are two families of DNS record to keep truthful. There are two paths for every flow, so every capacity model, every monitoring view and every on-call runbook has a version for each. And every incident now opens with a question that did not exist before: which family failed, and for whom.

The IPv4 half also carries costs the IPv6 half does not. Addresses are scarce, so they are shared, which means NAT and the state table from the previous module, with its capacity limits, its timers and its logging obligations. Every host that keeps a lease keeps a slice of a pool somebody has to manage. None of that spend buys a new capability. It buys the continued existence of the thing you were supposed to be leaving.

One worry deserves removing before it shapes the plan, because it usually does. Giving up IPv4 on a segment does not give up protection. The previous module settled the general case: NAT is address sharing, unsolicited traffic is dropped for want of a state-table entry rather than by any policy somebody wrote, and RFC 4787 specifies that behaviour without claiming it protects anything. What matters for this decision is the consequence. A host that gives up its IPv4 lease keeps a global IPv6 address behind a stateful firewall, so its default-deny behaviour becomes a rule that can be read, audited and changed rather than an accident of address arithmetic. The security question moves from the addressing plan to the firewall policy, which is where somebody can actually answer it.

A ratchet is what has been missing, and the reason it is hard is the segment. Most segments contain at least one device that will never speak anything but IPv4, so switching a whole segment off is not available. The mechanism that follows works at the granularity that is actually achievable: one host at a time, with its neighbour on the same wire untouched.

An IPv6-mostly segment is one where IPv6-only and IPv4-capable devices sit on the same wire at the same time. It is not an IPv6-only network, which would require every device on it to have been dealt with first. It is not dual-stack either, because on a dual-stack segment every device holds an IPv4 address whether it needs one or not. It is the middle arrangement that lets the IPv4 population shrink device by device.

The swimlane above shows the three populations that result, and the important detail is that they differ only in what happened at DHCP. Host A signalled that it can work without IPv4, was not given a lease, and now holds a global IPv6 address and nothing else. Host B either cannot make that signal or was not configured to, so it kept both addresses and runs as a dual-stack host. Host C has no IPv6 stack at all, holds an IPv4 lease, and is the reason the IPv4 pool on that segment stays switched on. All three work. Only one of them has reduced anything.

The signal is DHCPv4 option 108, specified in RFC 8925, and the useful way to read it is as a polite question rather than a command. The client asks for an IPv4 address in the ordinary way and attaches a statement about itself: I am able to operate without one. The server decides. If the segment is ready, meaning translation is available and IPv6 is properly configured, it withholds the IPv4 lease for a stated period and the client runs IPv6-only until that period ends, at which point the exchange happens again.

Three properties of that exchange are what make a rollout survivable. The claim comes from the host, so a device that cannot cope never makes it and is never affected. The decision belongs to the network, so the change is made in one place per segment rather than on thousands of endpoints. And the withholding is timed, so the arrangement expires and renegotiates instead of becoming a permanent state that nobody remembers configuring. Reversing the whole thing is one DHCP setting and one lease cycle, which is a materially different risk conversation from a migration that has to be unwound host by host.

Status matters here and the course is deliberate about it. The operational guidance for running these segments is draft-ietf-v6ops-6mops, an Internet-Draft, and it must be cited as a draft. The mechanisms it describes are not drafts: option 108 is RFC 8925, NAT64 is RFC 6146, DNS64 is RFC 6147 and 464XLAT is RFC 6877. Guidance that is still being written is a normal condition for a practice that is still spreading. It says something about how settled the operational advice is, and nothing about whether the mechanisms are finished.

Host A's route to a server that exists only on IPv4 was drawn in the swimlane as a single arrow labelled through NAT64. That arrow is doing a lot of work. Two separate mechanisms sit behind it, they fail in different ways, and between them they leave one gap that the rest of the module exists to close.

NAT64, specified in RFC 6146, is the translator that lets an IPv6-only client reach an IPv4-only server. DNS64, specified in RFC 6147, is what makes the client aim at it without the client knowing anything unusual is happening. Neither is much use alone, which is why they are almost always deployed together.

Follow one connection. The host has an IPv6 address and no IPv4 address. It asks its recursive resolver for a name in the ordinary way. The name has only an IPv4 address published for it, so an honest answer would be no usable address at all. The resolver, running DNS64, instead synthesises an IPv6 answer by embedding that IPv4 address inside a known IPv6 prefix, and that prefix is routed to the translator. The client receives what looks like a perfectly normal IPv6 address and opens a perfectly normal IPv6 connection to it.

The translator does the other half. Packets addressed inside its prefix arrive at the network edge, and it recognises the embedded IPv4 destination, rewrites the packet into IPv4, and sends it on using an address and port from its own pool. It records the mapping so the reply can be turned back into IPv6 and delivered to the host that started the exchange. If that description feels familiar, it should: this is the state-keeping translator from the previous module, with an address family change added to the address rewrite. It inherits the same properties. State means capacity limits. Mappings expire on timers. Return traffic depends on an entry that was created by outbound traffic, so nothing unsolicited arrives from the IPv4 side. The operational questions are the ones you already know how to ask.

Now the gap, and it follows directly from how the pair works. DNS64 only helps when there is a lookup. An application that connects to a literal IPv4 address never asks the resolver anything, so nothing is synthesised, the packet it builds has an IPv4 destination, and the host has no IPv4 stack to send it with. Literals are everywhere in real estates: an address hard-coded in a configuration file, a management tool pointed at an appliance by number, a licence server written down during an installation years ago, a device that hands out its own address inside a payload. The second version of the same gap is the application that insists on an IPv4 socket even where a name exists, which is common in older software and in anything that bundles its own network layer.

There is one mercy in this, and it is worth noticing because it inverts the problem Section 17.1 described. A dual-stack host hides a broken address family behind a short delay, so the fault is invisible for months. A host that has given up its IPv4 lease has no second family to fall back on, so a dependency on a literal address fails immediately, completely, and in one named application on one named host. That is a fault somebody reports on the first afternoon with the evidence attached, which is a far better position to plan around than a fault nobody can see.

Both failures have the same shape. An application produced an IPv4 packet, and on an IPv6-only host there was nowhere for it to go. That framing points straight at the fix, because the packet does not need the network to be different. It needs somewhere to be translated before it ever reaches the wire.

464XLAT, specified in RFC 6877, puts a second translator on the host itself. The CLATpresents a local IPv4 address to applications, so software that wants IPv4 finds IPv4 and asks no questions. On the way out it rewrites each packet into IPv6 without keeping per-flow state, because the translation is a fixed one-to-one mapping rather than a pool being shared. The network's NAT64 then does the stateful half at the edge, exactly as in the previous section. Two translations, IPv4 to IPv6 to IPv4, which is where the name comes from.

The chain below is worth reading left to right once with a literal address in mind. The application builds an IPv4 packet aimed at an address it read from a configuration file. The CLAT turns it into IPv6 inside the host. It crosses the access network as ordinary IPv6 traffic, which is the only thing that network carries. The NAT64 at the edge turns it back into IPv4. The server sees an ordinary IPv4 client and answers one. Nothing in the application changed, and nothing in the server changed.

Which operating systems ship a CLAT is not trivia. It is the fact that decides which segments you can move and in what order. Android, macOS and iOS have shipped CLAT for a long time, which is why a mobile network can run IPv6-only without its customers noticing and why a segment full of phones and Macs is the easiest place to start. Windows announced expansion beyond cellular connections, so a Windows laptop estate is the one where you check what versions you actually run before you promise anything. Fedora and NetworkManager gained an eBPF-based CLAT in July 2026, which brings mainstream Linux desktops into the same position and is recent enough that a fleet built last year may not have it.

That reframes the question people usually ask. Will this break my users is not answerable in general. What does this segment run, and does that software ship a CLAT, is an inventory question with a real answer, and answering it is most of the work of planning a rollout.

Two limits keep the picture honest. 464XLAT is designed for traffic where a client reaches a server, not for IPv4 peer-to-peer connections between two hosts that both expect to be reachable, so an application built on inbound IPv4 connections is a genuine exception rather than a configuration problem. And a device with no CLAT and no way to install one, which is most instruments, cameras and appliances, is not rescued by any of this. That device keeps IPv4, and the segment it lives on keeps IPv4 with it.

So the translation story ends in a sorting rule rather than a universal fix. Hosts that run a CLAT can be offered option 108; hosts that cannot run one decide what their segment has to keep. That makes the rollout an inventory problem rather than a design problem, and the last section turns it into a plan: an order to work through, and a measurement attached to each step in it.

Order segments by what you know about the devices on them, not by which part of the estate you would most enjoy modernising. The mechanisms are settled; the risk lives entirely in your inventory.

The segments that go first share three properties. Their device population is modern, self-updating and reasonably well known, which in most organisations means staff laptop and mobile wireless, guest wireless, and in a university the student segments. Nothing on them is load-bearing for a process that cannot pause. And the change is reversible in one place, because option 108 is offered by the DHCP server and withdrawing the offer restores the previous behaviour at the next lease cycle. Start where a mistake costs a lease renewal.

The segments that stay dual-stack are the ones with a device nobody can change. A laboratory instrument with a vendor-signed image, a camera fleet, a badge reader, a building management controller: no CLAT can be installed on any of them, and no amount of network design makes an IPv4-only device speak IPv6. That is lane C in the swimlane, and it is a legitimate resting place rather than a failure. The mistake is letting one such device on one segment set the addressing policy for the whole organisation.

Before option 108 is offered anywhere, three things have to be true on that segment. IPv6 has to work properly on its own merits, meaning addressing, DNS, firewall policy and monitoring are all in place and tested, because a host that has given up IPv4 has nothing to fall back to. NAT64 and DNS64 have to be reachable and sized for the population, since every IPv6-only host now depends on that translator for a large share of the internet. And the IPv4 pool has to stay for the hosts that keep it, which means the rollout reduces demand on the pool rather than removing the pool.

Evidence that it worked is where most transition plans are weakest, so decide the measurements before the change. The primary number is leases you stopped issuing: how many hosts on that segment offered option 108 and were answered, against the size of the population. Track the active IPv4 lease count over time, because that is the pool pressure the whole exercise exists to reduce. Watch the translator: NAT64 session counts, error counters and anything resembling pool exhaustion tell you whether the bridge is carrying the load you moved onto it. Read the help desk queue for that segment specifically, and go looking for the failure this module predicts, which is an application pointed at a literal address on a host without a CLAT.

One piece of negative evidence deserves stating outright, because it is the most common self-deception in these rollouts. A dual-stack host on an IPv6-mostly segment proves nothing. It kept its IPv4 address, so it never exercised translation and never tested the path you are relying on. Testing on the host that did not change is a way of confirming that nothing changed.

Finally, keep national and global figures in their proper place. Measurement literacymeans attaching a source, a method and a date to every number, and then asking what population it describes. India above 70 percent IPv6 capability, measured by APNIC Labs, tells you that this transition is finishable at national scale. Google measuring 50.10 percent of its worldwide users on IPv6 on 28 March 2026 tells you the internet crossed halfway on one large provider's population. Neither tells you anything at all about the printer on your third floor. Public measurements settle the argument about whether to move. Your own segment measurements are the only thing that settles whether you have.