IPv6-mostly makes IPv6 the normal mode of operation while keeping IPv4 available only for devices that still need it.
Capable devices can operate without a native IPv4 address.
IPv6-only devices can still reach IPv4-only services.
Legacy devices can still receive IPv4 when necessary.
IPv6-mostly is designed as a gradual step between traditional dual stack and a completely IPv6-only network.
The easiest way to understand IPv6-mostly is to compare it with traditional dual stack.
In a normal dual-stack network, almost every device receives both:
This happens even when the device could operate perfectly well without native IPv4.
IPv6-mostly changes that model.
Devices that can work without IPv4 are allowed to remain IPv6-only. Devices that genuinely need IPv4 can still receive it.
Both types of devices may exist on the same Wi-Fi network, VLAN or LAN.
The names can be confusing because an individual device in an IPv6-mostly network may actually be operating in IPv6-only mode.
The difference is the architecture of the network.
| Model | What happens to IPv4? |
|---|---|
| Dual stack | Most devices receive both IPv4 and IPv6. |
| IPv6-mostly | IPv4 remains available, but only devices that need it receive it. |
| IPv6-only | Native IPv4 is not provided to devices on that network. |
IPv6-mostly does not remove IPv4 from the network. It stops assigning IPv4 unnecessarily.
One of the most important characteristics of IPv6-mostly is that different types of devices can share the same network segment.
The device can operate without a native IPv4 address.
It uses IPv6 and NAT64 or 464XLAT when reaching IPv4-only destinations.
The device supports IPv6, but some application or operating-system dependency still requires native IPv4.
It receives both IPv6 and IPv4.
A legacy device may not support IPv6 adequately.
The network can continue providing IPv4 connectivity to that device.
One of the mechanisms that makes IPv6-mostly practical is DHCPv4 Option 108.
Its official name is:
The idea is surprisingly simple.
A capable device connects to the network and starts the normal process of discovering whether IPv4 service is available.
The device indicates that it understands the IPv6-Only Preferred option.
If the DHCP server also supports this mechanism, it can tell the client:
You do not need to consume an IPv4 address.
The client then continues using IPv6 without completing an ordinary IPv4 address assignment.
Another device on the same network that still requires IPv4 can continue through the normal DHCP process and receive an IPv4 address.
Declining an IPv4 address would not be very useful if the device could no longer reach IPv4-only websites and services.
This is why an IPv6-mostly network provides NAT64.
NAT64 allows an IPv6-only device to communicate with an IPv4-only server.
From the client's perspective, the access network remains IPv6.
IPv4 exists only where compatibility requires it.
For NAT64 to work, the device needs to know which IPv6 prefix represents destinations reachable through the NAT64 translator.
This is commonly called the PREF64 or NAT64 prefix.
Modern networks can advertise this information directly in IPv6 Router Advertisements.
Advertising PREF64 directly reduces the need for a device to discover the NAT64 prefix indirectly.
DNS64 can also help IPv6-only devices reach IPv4-only services.
When a destination has an IPv4 A record but no IPv6 AAAA record, DNS64 can synthesize an IPv6 answer.
DNS64 is therefore one possible part of an IPv6-mostly deployment.
Modern designs may also provide PREF64 directly to capable hosts so the operating system can perform address synthesis locally.
Some applications still assume that IPv4 exists locally.
They may use an IPv4 address directly, request an IPv4 socket, or contain other IPv4-specific assumptions.
In these cases, DNS64 alone may not be enough.
464XLAT provides an IPv4 compatibility layer on an IPv6-only device.
This means the application can still behave as though IPv4 exists, even though the access network is carrying IPv6.
An IPv6-mostly network can therefore provide several mechanisms simultaneously.
| Mechanism | Purpose |
|---|---|
| IPv6 | Primary network protocol. |
| DHCP Option 108 | Allows capable devices to avoid receiving IPv4. |
| NAT64 | Allows IPv6-only devices to reach IPv4-only destinations. |
| PREF64 | Tells capable hosts which IPv6 prefix represents NAT64 destinations. |
| DNS64 | Can synthesize IPv6 DNS answers for IPv4-only services. |
| 464XLAT | Supports applications that still expect IPv4. |
| Native IPv4 | Remains available to devices that genuinely require it. |
| Feature | Dual stack | IPv6-mostly | IPv6-only |
|---|---|---|---|
| Native IPv6 | Yes | Yes | Yes |
| Native IPv4 for every normal host | Usually | No | No |
| Native IPv4 available when required | Yes | Yes | No |
| IPv6-only clients possible | Unusual | Yes | All clients |
| NAT64 | Optional | Important | Typically required for IPv4 Internet access |
| IPv4 address conservation | Limited | Significant | Maximum at the access layer |
This is perhaps the most important reason IPv6-mostly exists.
In a controlled environment, such as a new data center, it may be possible to ensure that every system operates correctly without native IPv4.
A public Wi-Fi network, enterprise LAN or university campus is different.
The operator may have little control over the devices that connect.
Some may be completely ready for IPv6-only operation.
Others may contain:
A strict IPv6-only network could break those devices.
Consider a Wi-Fi network with 10,000 devices.
In a conventional dual-stack deployment, the operator may need IPv4 space for all 10,000 devices.
But suppose 8,000 of those devices can operate successfully in IPv6-only mode.
The exact savings depend on the device population, but the principle is simple:
Do not assign a scarce IPv4 address to a device that does not need one.
IPv4 exhaustion makes this architecture particularly relevant for regions where obtaining additional IPv4 space is difficult or expensive.
Instead of continuing to expand IPv4 infrastructure indefinitely, operators can make IPv6 the normal access technology and preserve IPv4 for the systems that still require it.
This is one reason IPv6-mostly has become an important topic in discussions within the Latin American Internet community.
It provides a realistic intermediate stage between:
IPv6-mostly also provides a useful way to discover hidden IPv4 dependencies.
An operator can begin with a normal dual-stack environment and gradually allow compatible clients to operate IPv6-only.
Traditional dual stack
IPv6-mostly
IPv6-only when practical
Devices that fail during Stage 2 reveal applications or systems that still depend on native IPv4.
Those dependencies can then be corrected without disrupting every user at once.
Dual stack can sometimes hide IPv6 problems.
Modern clients often try both IPv6 and IPv4 and use whichever path succeeds quickly.
If IPv6 is broken, the application may silently fall back to IPv4.
An IPv6-only client does not have that native IPv4 escape route.
IPv6 routing, DNS, Router Advertisements, MTU handling and security policy therefore need to work correctly.
This can initially expose operational problems that were already present but hidden by dual stack.
IPv6-mostly is not simply a DHCP configuration change.
Operators should verify several parts of the network.
NAT64 prefix discovery becomes an important operational detail.
One traditional method uses DNS64.
But a device may use a manually configured public, corporate or VPN-provided DNS resolver instead of the resolver supplied by the local network.
Depending on the implementation, this can interfere with discovery of the local NAT64 prefix.
For this reason, advertising PREF64 directly through IPv6 Router Advertisements can make the architecture less dependent on DNS64 for discovery.
NAT64 performs translation. PREF64 tells the client which prefix to use. DNS64 can synthesize IPv6 DNS answers.
It is easy to look at IPv6-mostly and think that it simply means deploying NAT64.
NAT64 is an important component, but the architectural idea is broader.
The defining policy is:
NAT64, PREF64, DNS64, CLAT and Option 108 are mechanisms that help make that policy practical.
Imagine a university Wi-Fi network called:
A modern phone connects.
It supports IPv6-only operation, NAT64 and the IPv6-Only Preferred mechanism.
Ten seconds later, an older device connects to exactly the same Wi-Fi.
It cannot operate correctly without native IPv4.
The network operator does not need separate Wi-Fi networks for the two devices.
That is the practical power of IPv6-mostly.
IPv6-mostly does not remove the role of DNS security.
Most applications still use DNS before establishing Internet connections.
Protective DNS and RPZ filtering can therefore continue blocking malicious domains before either native IPv6 or NAT64 communication begins.
IPv6-mostly should not be viewed as the final goal of the IPv6 transition.
It is better understood as a practical way to reduce dependence on IPv4 while compatibility is still necessary.
As operating systems, applications and infrastructure become increasingly IPv6-capable, fewer devices should require native IPv4.
The difference between IPv6-only and IPv6-mostly is easier to understand when looking at the network rather than an individual device.
IPv6-only means the host has no native IPv4. IPv6-mostly means the network allows capable hosts to operate that way while still supplying IPv4 to hosts that need it.
In other words:
This makes it possible to reduce IPv4 consumption incrementally without requiring every device and every application to become IPv6-only at the same moment.
The IPv6-mostly operational guidance document is currently an IETF Internet-Draft, so its details may continue to evolve before publication.
An IPv6-mostly network allows IPv6-only and IPv4-enabled devices to coexist on the same network. Devices that can operate without native IPv4 remain IPv6-only, while IPv4 is provided to devices that still require it.
In an IPv6-only network, devices do not receive native IPv4 connectivity. In an IPv6-mostly network, capable devices may operate IPv6-only while other devices on the same network can still receive IPv4.
DHCP Option 108 is called IPv6-Only Preferred. It allows a capable client and DHCP server to agree that the client does not need to obtain an IPv4 address.
Yes. IPv4 remains available at the network level for devices that require it. The objective is to stop assigning IPv4 to devices that do not need it.
The network provides NAT64, together with mechanisms such as PREF64, DNS64 or 464XLAT.
No. Traditional dual stack generally gives a host both IPv4 and IPv6. IPv6-mostly keeps IPv4 available but assigns it only when it is needed.
No. IPv6-mostly is primarily an incremental transition strategy that allows operators to move more devices into IPv6-only mode while maintaining compatibility for legacy systems.