Don’t Get Your Wires Crossed: Appropriate Use Cases for IPv6-Only vs. IPv6-Mostly

By Jordi Palet Martínez – CEO/CTO of The IPv6 Company

A Matter of Terminology

IETF terminology is often not clearly and explicitly defined, leading to confusion and uses of terms not originally intended by the standards. That inappropriate use can even affect the quality of service offered to the user.

Terms like IPv6-only and IPv6-mostly are a clear example of this. Despite the complexity of reaching a consensus on definitions, v6ops is finally making progress with the draft-ietf-v6ops-ipv6-only Working Group document.

The most important thing to keep in mind is that correct use of these terms requires specifying a scope of application.

For example, saying that a network is IPv6-only is probably incorrect. This would imply that IPv4 is neither configured nor used anywhere in the network, which is not a common scenario today (services, applications, and internal or external content would not be accessible using IPv6-only). If instead we say “IPv6-only Access network,” we make it clear that the part of the network in which only IPv6 is natively configured (layer 2) is the access network. Therefore, in the CPE LANs, there can be a dual stack, just like in the rest of the operator’s network.

IPv6-only+IPv4aaS

Using 464XLAT — one of the five IPv6-only + IPv4aaS (IPv4 as a Service) transition mechanisms — is the most common scenario today in mobile access networks, and it is a growing trend in residential access networks. It allows the WAN portion to be IPv6-only while maintaining dual-stack functionality on the user network, preventing any device or application from ceasing to function. Relevant documents include: RFC6877, RFC8585, RFC8683, RFC9313, draft-ietf-v6ops-rfc6146-bis, and draft-ietf-v6ops-rfc7084bis.

All five mechanisms, and especially 464XLAT (the only one supported in mobile networks), have a clear use case: unmanaged networks. Users of these networks do not need to perform special configurations, regardless of whether the customer-premises equipment (CPE) on their home networks or tethering networks (i.e., when the mobile phone becomes a router to provide access to other devices) use IPv4, IPv6, or both. The CPE incorporates a stateless NAT46 mechanism (CLAT or equivalent) to facilitate communication between IPv4 and IPv6 without local communication traffic having to leave the local network or be translated.

In recent years, IPv6 deployment has progressed globally, especially in mobile and residential networks. Statistics from Akamai, APNIC, Facebook, and Google, among others, now indicate IPv6 exceeding 50 percent of traffic. This figure doesn’t even include the rapidly growing traffic from China (which has IPv6-only legal obligations for ISPs); adding that in would likely place the total global IPv6 traffic closer to 70-75 percent. However, while major content providers have deployed IPv6-only data centers, organizations (both public and private) generally have low levels of IPv6 adoption.

IPv6-Mostly

Therefore, the IETF has taken steps to facilitate deployment in managed networks (i.e., corporate networks) with mechanisms to achieve the “IPv6-mostly” model (draft-ietf-v6ops-6mops).

IPv6-mostly, compared to the dual-stack model in corporate networks, has several objectives:

• Reduce the consumption of private IPv4 addresses and DHCPv4 resources.
• Avoid masking IPv6 problems (due to HappyEyeballs’ fallback to IPv4), facilitating the debugging of IPv6 errors.
• Enable a gradual, host-by-host transition to IPv6-only, eliminating the need for dedicated IPv6-only segments and simplifying operations, thus increasing scalability.
• Discover and prevent incompatibilities in a future IPv6-only environment.
• Reduce NAT4 usage.

IPv6-mostly is based on the premise of RFC8925: Using a new DHCPv4 option (108), a dual-stack host can signal that it does not need to use IPv4 on its interface. The goal is to avoid deploying dedicated IPv6-only network segments while allowing the host to behave as such on a dual-stack segment, provided the network administrator deems it appropriate for that segment. To achieve this, the DHCPv4 server configuration on that segment must be enabled with support for option 108, enabling granular control over which hosts can disable IPv4.

However, disabling IPv4 on a host means it will not be able to access IPv4-only destinations. Therefore, the network administrator should only enable option 108 if they have implemented support for stateful NAT64 (PLAT in 464XLAT terminology).

If support for literal IPv4 addresses, applications lacking IPv6 support, and similar situations are also required, hosts supporting option 108 must also incorporate CLAT. In fact, CLAT (draft-ietf-v6ops-claton) support in desktop operating systems has been progressively implemented since the publication of RFC8925, first in macOS and Linux, and more recently in Windows 11 (as a public preview).

Mobile operating systems (iOS, Android, Harmony) have incorporated CLAT or equivalent features into their cellular interfaces since the inception of 464XLAT, and they have recently added it to other interfaces as well (such as Wi-Fi). However, IPv6-mostly is not supported on the cellular interface because DHCPv4 is generally not implemented there, either on the device itself or on mobile network infrastructure devices.

It’s important to note that using IPv6-only on a host also prevents communication with IPv4-only devices on the same or other segments of that network (including external access via IPv4 in the case of servers). In other words: Printers, cameras, and other IPv4-only devices cannot be used by IPv6-only devices. Obviously, in a corporate network, the administrator will explicitly configure solutions to allow such communication, such as through the internal PLAT or stateless NAT64 mechanisms with EAM (Explicit Address Mappings; RFC7757/STD103), SIIT-DC (RFC7755), etc.

Commonalities

In both 464XLAT and IPv6-mostly, various mechanisms have been used for discovering the NAT64 prefix, ranging from manual configuration to 3GPP’s own mechanisms for mobile networks and heuristic systems such as RFC7050 (updated by RFC8880) that are often incorrectly implemented. Recently, a better alternative has been adopted based on Router Advertisement (RA) messages, according to RFC8781.

Likewise, the use of DNS64 (RFC6147) is generally recommended, as it avoids translations in NAT46, reduces the load on the DNS server, and improves connection establishment times. Whenever possible, operating systems should perform self-synthesis to avoid DNSSEC validation failures, although it is not a common problem if DNS64 is correctly configured.

“Don’t get your wires crossed.”

IPv6-only+IPv4aaS (e.g., 464XLAT) is a suitable transition mechanism for access networks, which are typically unmanaged internally and mobile or residential, though sometimes this includes small or medium-sized corporate networks that don’t need to publish internal services on the Internet (or have few services and manual configuration is worthwhile).

IPv6-mostly was designed exclusively for use within managed corporate networks, whose access network should be dual-stack. Applying it to residential (unmanaged) or mobile networks would imply:

• The access network must be maintained in a dual-stack configuration with public IPv4 addresses or incorporate CLAT into the CPE.
• Communication between IPv6-mostly and IPv6-only devices is not possible unless mechanisms such as PLAT, EAM, or SIIT-DC are manually configured, possibly on the CPE, in which case the network becomes managed. Alternatively, these mechanisms could be configured virtually by the ISP in the cloud or on the operator’s infrastructure, considering the implications of many residential users potentially sharing the same private IPv4 addresses. This would force that traffic, instead of remaining local, to “upload” and “download” to the cloud or the operator’s infrastructure, with the consequent latency and additional bandwidth consumption.

Residential CPEs often fail to incorporate CLAT, usually erroniously citing its complexity as an excuse. Incorporating option 108 in DHCPv4 is even more complex, requiring additional code as well as the implementation of PLAT, EAM, or SIIT-DC and a user-friendly interface to facilitate the management for non-experts. Furthermore, in all cases, numerous open-source implementations exist, and the greatest cost actually lies in a deep understanding of these protocols, including IPv6 and transition mechanisms.

In Conclusion

In any case, the highest priority is user satisfaction. This compels us, on one hand, to use the appropriate protocols for each case and, on the other hand, to call on CPE manufacturers to incorporate CLAT into their devices (and, for corporate use, the relevant IPv6-mostly protocols).

We must also urge ISPs to demand this support. With alternatives on the market, our choices must be based not only on price (often, “you get what you pay for”), but also what is best for users and our networks. Only the market itself (or explicit regulation) will force manufacturers to implement what we need.

Post written by:

Jordi Palet Martínez
CEO/CTO of The IPv6 Company

Jordi Palet Martínez has been working with computers, networking, and technology since he was eight years old. For the last 24 years as CEO/CTO of “The IPv6 Company” he devoted most of his time to IPv6 R&D standardization, training, and consultancy, having already worked with IPv6 customers in 130 countries in the world. He has co-authored a number of RFCs and books related to IPv6, and has contributed to IPv6 training and policy-making in all the RIRs.

Any views, positions, statements, or opinions of a guest blog post are those of the author alone and do not represent those of ARIN. ARIN does not guarantee the accuracy, completeness, or validity of any claims or statements, nor shall ARIN be liable for any representations, omissions, or errors contained in a guest blog post.

Recent blogs categorized under: IPv6

• The Nine Lives of an Early Adopter: ESnet’s IPv6 Journey — and Why It Matters Now
• IP Addresses Through 2025
• What Is More Energy-Efficient: IPv4 or IPv6?
• Internet Evolution: Moore’s Law, Addressing Architectures, and the Future of Internet Scale