The shortage of IPv4 addresses has accelerated the move toward IPv6. With roughly 4.3 billion possible addresses (32 bits), IPv4 can no longer meet the needs of modern connected devices. IPv6, by contrast, uses 128 bits—roughly 340 sextillion addresses—providing virtually unlimited capacity for growth.

Over the past few decades, several methods have been developed to ease the transition from IPv4 to IPv6. The most widespread is Dual Stack, which allows each device to run both protocols at the same time. Other approaches, such as 6to4, 6rd, ISATAP, Teredo, NAT-PT, and NAPT-PT, also appeared along the way. Many of these, however, are now obsolete—for example, NAT-PT was officially deprecated in RFC 4966, and 6to4 relies on special prefixes now considered historical (RFC 7526).

Despite all these tools, many organizations have yet to complete their transition to IPv6, mainly because of the operational complexity involved in maintaining Dual Stack networks. This model requires managing two systems in parallel—routes, policies, and security for both IPv4 and IPv6—which drives up operating costs. The IETF also notes that Dual Stack networks don’t actually solve the IPv4 shortage, since they still rely on the same IPv4 resources as IPv4-only networks.

In practice, the prolonged use of Dual Stack often acts as a kind of crutch that hides underlying issues. When IPv6 encounters an error, connections typically fall back to IPv4, allowing the problem to go unnoticed. On top of that, running thousands of devices in dual-stack mode—for example, 5,000 stations with both IPv4 and IPv6—comes at a significant cost, both in IPv4 address usage and administrative overhead.

Obsolete Transition Methods

Today, organizations rarely use the older IPv6 transition techniques. Among the obsolete ones are automatic tunneling mechanisms such as 6to4 (network 2002::/16, now classified as historical in RFC 7526), 6rd (Rapid IPv6 deployment over IPv4), Teredo (a UDP tunnel designed to traverse NAT), and ISATAP (IPv6 over IPv4 within LANs). These approaches were originally conceived as temporary solutions but have since been phased out due to their complexity and security issues. Likewise, traditional translation methods such as NAT-PT and NAPT-PT (IPv6↔IPv4 translation) are no longer recommended, as they have also been officially discontinued.

Why Wasn’t Dual Stack the Final Answer?

The Dual Stack approach—where hosts operate with both IPv4 and IPv6 simultaneously—remains common as a temporary solution. It allows organizations to test IPv6 safely, since any connection failure simply falls back to IPv4. However, it doesn’t solve the problem of address exhaustion: every dual-stack device still uses an IPv4 address and depends on IPv4 routes and services (such as DNS and DHCPv4), maintaining pressure on the legacy infrastructure. Separating networks or SSIDs by protocol only adds to the complexity. For instance, in wireless environments, having one SSID for IPv6-only and another for Dual Stack can overcrowd the available channels. In short, while Dual Stack eases the transition, it also increases operational costs and long-term complexity.

“IPv6-Mostly” Networks: A New Approach

To overcome these challenges, the concept of IPv6-Mostly Networks has emerged. According to RFC 8925 (Section 1.2), an IPv6-mostly network provides NAT64 (and optionally DNS64) services along with IPv4 connectivity, allowing IPv6-only, IPv4-only, and dual-stack hosts to coexist on the same segment. In other words, the network delivers IPv4 on demand: devices that can operate without IPv4 use IPv6 exclusively, while those that still need it continue to receive IPv4 addresses. This idea originated in large-scale networks—such as Google’s infrastructure and major industry conferences—where even private address space (RFC 1918) became scarce under Dual Stack deployments. The technical community now embraces a simple principle: be IPv6-only wherever possible, and Dual Stack-only where necessary.

The core mechanism behind IPv6-Mostly networks is the use of DHCPv4 Option 108, as defined in RFC 8925. Through this option, a DHCPv4 client indicates that it prefers to operate in IPv6-only mode. If the DHCP server supports Option 108, it recognizes that the device doesn’t require IPv4 and simply doesn’t assign it an IPv4 address. The client still performs the standard DHCP DORA process, but once the server returns Option 108 (IPv6-only preferred), the client skips the request step for an IPv4 address and therefore never receives an IPv4 ACK. Put simply: the client tells the DHCPv4 server—using Option 108—“I can work without IPv4.” The server then stops the process and frees up the IPv4 address. In this way, every IPv6-only device releases an IPv4 address back into the available pool.

How Does an IPv6-Mostly Network Work in Practice?

When a device connects to an IPv6-Mostly network, it configures its stack according to its own capabilities. IPv4-only devices behave as they always have, obtaining an IPv4 address through DHCPv4. Dual-stack devices (those that can’t yet operate in IPv6-only mode) receive an IPv6 address—via SLAAC or DHCPv6—and also get an IPv4 address from DHCPv4. In contrast, IPv6-capable devices—such as modern smartphones and PCs—include Option 108 in their DHCPv4 request and are configured only with IPv6 addresses.

To enable IPv6-only clients to communicate with IPv4 servers, the network provides NAT64 (and optionally DNS64). NAT64, defined in RFC 6146, translates traffic between IPv6 and IPv4, allowing IPv6-only hosts to access IPv4 resources. For example, when an IPv6-only device  tries to ping an IPv4 address such as 8.8.8.8, the traffic is directed through the NAT64 gateway, which assigns it a hidden private IPv4 address (via 464XLAT) and then translates it into real IPv4 traffic. Thanks to this process, traditional IPv4 applications continue to work transparently for users. In an IPv6-Mostly network, devices without IPv4 coexist smoothly with those that still use it, relying on NAT64, DNS64, and 464XLAT for full interoperability.

RFC8925 to shut down IPv4 + Host IPv6 communicating with a native IPv4 service

Advantages of an IPv6-Mostly Network

The IPv6-Mostly model brings several operational benefits. First, it dramatically reduces the consumption of IPv4 addresses. By assigning IPv4 only to devices that truly need it, IPv4 subnets can be much smaller. According to the IETF, in real-world scenarios—such as Wi-Fi networks at large conferences—around 60 to 70 percent of devices have operated in IPv6-only mode. This enables smaller IPv4 subnets, freeing up address space and easing pressure on IPv4 infrastructure resources.

Network operation also becomes simpler and more scalable. There’s no need to maintain duplicate VLANs, SSIDs, or bridging setups to separate IPv4 and IPv6 traffic—both types of hosts can coexist on the same segment.  The IETF’s 6mops document explains that this avoids duplicating wireless SSIDs (which can congest the spectrum) and eliminates the need to create separate VLAN subnets for different device types. Managing a single unified environment is far easier: there’s no need to route IPv4 traffic between specific segments or educate end users about which network they should connect to.

Another key advantage is controlled transition. By using Option 108, network administrators can gradually migrate devices to IPv6-only operation. For instance, they can start with smaller networks or with devices that already offer full IPv6 support, while keeping the rest on Dual  Stack. This incremental rollout gradually curbs IPv4 usage where it is no longer required.

Finally, IPv6 troubleshooting becomes more effective. In traditional Dual Stack networks, when a service fails over IPv6, traffic usually falls back to IPv4 without users noticing—delaying the detection of IPv6 issues. In an IPv6-Mostly setup, however, IPv6-only clients are required to use IPv6, exposing any incompatibilities immediately. This makes problems in the new stack easier to identify.

In summary, the IPv6-Mostly approach allows networks to keep one foot in each world—operating on demand. Devices that are fully capable of IPv6 enjoy all its benefits without the overhead of IPv4, while services or devices that still depend on IPv4 continue to function seamlessly through NAT64/DNS64. The result is a lighter, more efficient network that’s easier and less costly to maintain.

Conclusion

Instead of maintaining dual configurations for every device, IPv6-Mostly networks combine the best of both worlds. They leverage the vast capacity of IPv6 for most traffic, and only “bring out” IPv4 when it’s strictly necessary. This lightens infrastructure, delays IPv4 exhaustion, and facilitates the global transition to IPv6. With standard tools like DHCPv4 Option 108 (RFC 8925) and NAT64/DNS64 services, organizations can adopt IPv6 gradually and cost-effectively. In short, IPv6-Mostly networks show that moving toward IPv6 doesn’t have to be expensive or complex: it’s simply about using the right tools to let the network prefer IPv6 wherever possible,  simplifying management and creating more room for the future.

References

– Experimental IPv6-only network at APRICOT 2024 | Network Startup Resource Center

https://nsrc.org/blog/apricot-ipv6-only

– book6: A Collaborative IPv6 Book

https://ipv6textbook.com/files/ipv6textbook.pdf

– IPv6 Mostly Network

https://blog.lacnic.net/redes-ipv6-mostly/

– IPv6-Only Preferred Option for DHCPv4

https://datatracker.ietf.org/doc/html/rfc8925

– IPv6 transition mechanism – Wikipedia

https://en.wikipedia.org/wiki/IPv6_transition_mechanism

– IPv6-Mostly Networks: Deployment and Operations Considerations

https://www.ietf.org/archive/id/draft-ietf-v6ops-6mops-00.html

– draft-ietf-v6ops-6mops-02

https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-6mops-02