As IPv6 adoption advances, network architectures operating predominantly over IPv6 are beginning to emerge. In this context, mechanisms such as Option 108 (IPv6-Only Preferred) defined in RFC 8925, Pref64 discovery in Router Advertisements (RFC 8781), and the 464XLAT model, widely used in mobile networks, have gained greater operational relevance.
In practice, however, confusion persists between two distinct concepts: IPv6-mostly and IPv6-only. This article discusses this conceptual difference, analyzes the role of these mechanisms, and presents practical implications observed in various operating systems and network environments.
The Road Towards IPv6-Only Networks
In the opening sequence of Star Trek, space is described as the final frontier, a world that remains to be explored, where new discoveries redefine the limits of knowledge.
(Free access, no subscription required)
In many ways, the evolution of IP networks is currently going through a similar time. After decades of coexistence between IPv4 and IPv6, the Internet is approaching a new frontier: the moment when IPv6-only architectures cease to be mere experiments or isolated deployments and start to represent a viable operational model across different environments.
The concept of IPv6-mostly networks emerged in this scenario, introduced by RFC 8925, along with mechanisms such as Option 108, which allows signaling to clients the preference for IPv6. At the same time, mechanisms such as NAT64, CLAT, and the 464XLAT model make it possible to access IPv4 resources from IPv6-mostly networks.
IPv6-Mostly Versus IPv6-Only
An IPv6-only network has a clear architectural feature: the host receives exclusively IPv6 addressing and does not have native IPv4 connectivity. When an application needs to access resources that still use IPv4, this communication takes place through translation mechanisms.
In many ways, the evolution of IP networks is currently going through a similar time. After decades of coexistence between IPv4 and IPv6, the Internet is approaching a new frontier: the moment when IPv6-only architectures cease to be mere experiments or isolated deployments and start to represent a viable operational model across different environments.
The concept of IPv6-mostly networks emerged in this scenario, introduced by RFC 8925, along with mechanisms such as Option 108, which allows signaling to clients the preference for IPv6. At the same time, mechanisms such as NAT64, CLAT, and the 464XLAT model make it possible to access IPv4 resources from IPv6-mostly networks.
IPv6-Mostly Versus IPv6-Only
An IPv6-only network has a clear architectural feature: the host receives exclusively IPv6 addressing and does not have native IPv4 connectivity. When an application needs to access resources that still use IPv4, this communication takes place through translation mechanisms.
The most common model for this scenario is 464XLAT (RFC 6877). In this model, there are two main components:
CLAT (Customer-side Translator) in the host
PLAT (Provider-side Translator) or NAT64 in the network infrastructure
CLAT converts IPv4 traffic originated by applications into IPv6 traffic, which is then translated to IPv4 by NAT64.
The concept of IPv6-mostly, introduced by RFC 8925, has a different nature. It does not eliminate IPv4 from the network nor modify its fundamental architecture. Instead, it defines a preference policy that encourages operating systems and applications to use IPv6 whenever possible.
Thus, an IPv6-mostly network remains essentially dual-stack, albeit with policies that favor the use of IPv6.
Option 108 and the Preference for IPv6
Option 108, defined in RFC 8925, allows a DHCPv4 server to inform clients that the network prefers them to operate in IPv6-only mode for a specified period of time.
However, this option is not mandatory. The RFC does not state that the client must reject IPv4 or that DHCPv4 must be interrupted.
In practice, it simply signals a preference, the interpretation of which depends on the operating system implementation.
Figure 1: Screenshot of the DHCP flow illustrating the interruption of the DORA process following the Option 108 signal, highlighting the client’s decision not to continue with obtaining an IPv4 address.
Pref64 and Automatic NAT64 Discovery
Another important component in IPv6-only networks is Pref64, defined in RFC 8781. This mechanism allows hosts to automatically discover which IPv6 prefix is being used by the network to perform NAT64 translation. The announcement is made through Router Advertisements, allowing the host to create IPv6 addresses from IPv4 addresses. This process is essential to allow applications to reach IPv4 destinations on IPv6-only networks.
Operating System Behavior
How devices behave in relation to these mechanisms varies among different operating systems.
Mobile platforms such as Android, iOS, and recent versions of macOS have native support for CLAT, allowing devices to operate transparently in IPv6-only environments.
Figure 2: CLAT interface in macOS showing the IPv4 address 192.0.0.2 associated with the local translator.
A recent development with potentially significant impact is the emerging support for CLAT in Windows 11. Test versions of the operating system have already included this functionality. The consolidation of this support could represent an important advance in the adoption of IPv6-only architectures in corporate and university networks.
Figure 3: CLAT interface in a Windows 11 Insider Preview environment
In Linux systems, particularly in distributions such as Ubuntu or Debian, automatic CLAT support is still not widely implemented. In this context, the translator can be activated manually with tools such as clatd or jool.
Figure 4: Execution of clatd in a Linux environment demonstrating the manual creation of the CLAT interface.
A Growing Movement Among Universities
At Universidade Estadual de Campinas (UNICAMP), IPv6 adoption has evolved significantly over the past few years. Currently, utilization levels in the university’s network already exceed 75% of IPv6 traffic, reflecting an environment where the protocol has ceased to be merely an experimental technology and now plays a predominant role in network connectivity.
As part of this evolution, a pilot project was launched in 2026 to adopt the IPv6-mostly model in the university’s wireless networks. The goal is to encourage the preferential use of IPv6 by connected devices while maintaining compatibility with services that still depend on IPv4.
This type of initiative also reflects a trend observed at international technical events, where discussions around IPv6-mostly and IPv6-only networks have gained prominence. Experiments and operational reports related to this model have been presented, for example, at APRICOT 2024, APNIC 57, and LACNIC 44, highlighting the growing interest within the technical community in exploring architectures that reduce dependence on IPv4.
This trend has also been observed in other academic institutions. For example, at RIUTEC 2025Santiago Aggio presented an experimental laboratory focused on studying IPv6-mostly environments, exploring the use of NAT64 and other translation mechanisms to enable connectivity with resources that still depend on IPv4.
Initiatives like these demonstrate that universities play an important role in experimenting and validating new network architectures, contributing both to the technical evolution of the Internet and to the training of professionals capable of operating infrastructures predominantly based on IPv6.
Final Considerations
The distinction between IPv6-mostly and IPv6-only is more than conceptual. It defines the operational model of next-generation networks.
Mechanisms such as Option 108, Pref64, NAT64, and CLAT show that the infrastructure required for IPv6-only architectures is already widely available.
As operating systems continue to expand their support for these technologies, especially with the evolution of CLAT support on widely used platforms such as Windows, IPv6-only networks are becoming increasingly viable in various operating environments.
