IPv6-only vs IPv6-mostly: Appropriate use cases

A matter of terminology

IETF terminology is not always clearly defined, which can lead to confusion and, in some cases, the use of mechanisms outside the scenarios for which they were originally intended, potentially affecting the quality of service offered to users.

The terms IPv6-only and IPv6-mostly are a clear example of this. But despite the difficulty of reaching consensus on definitions, the IPv6 Operations (v6ops) Working Group is making progress on this front through 'IPv6-Only and IPv6-Mostly Terminology Definitions'.

One of the key points emerging from this work is that terms such as IPv6-only and IPv6-mostly only make sense when their scope is clearly defined. For example, saying that a network is IPv6-only is probably incorrect, because it would imply that IPv4 is neither configured nor used anywhere in the network.

This is not a common scenario today, as services, applications, and internal or external content may still require IPv4 connectivity. If instead we say 'IPv6-only access network', we make it clear that only the access portion of the network is IPv6-only. The Customer Premise Equipment Local Area Network (CPE LAN) and other parts of the operator's network may still operate in dual-stack mode.

Understanding where these terms apply in practice helps explain why IPv6-only and IPv6-mostly should not be treated as interchangeable.

IPv6-only+IPv4aaS

This is the most common scenario today in mobile access networks that use 464XLAT and is a growing trend in residential access networks. It is one of the five IPv6-only + IPv4aaS ('IPv4 as a Service') transition mechanisms for access networks. It allows the Wide Area Network (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: RFC 6877, RFC 8585, RFC 8683, RFC 9313, draft-ietf-v6ops-rfc6146-bis, and draft-ietf-v6ops-rfc7084bis.

These five mechanisms, and especially 464XLAT (which is 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 devices they have on their home networks or tethering networks (when the mobile phone becomes a router to provide access to other devices) use IPv4, IPv6, or both, since the CPE incorporates a stateless Network Address Translation 4to6 (NAT46) mechanism (Customer-side Translator (CLAT) or equivalent) to facilitate communication between IPv4 and IPv6, without local communication traffic having to leave the local network or be translated (Figure 1).

In recent years, IPv6 deployment has progressed globally (Figure 2), especially in mobile and residential networks. This is reflected in statistics from Akamai, APNIC, Facebook, and Google, among others, which indicate IPv6 adoption rates exceeding 50%. This figure doesn't even include traffic from China (which has legal IPv6-only obligations for ISPs), likely placing that percentage closer to 70 - 75% and growing rapidly in that economy. However, while major content providers have deployed IPv6-only data centres, 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, that is, 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 RFC 8925 : A dual-stack host can signal, using a new DHCPv4 option (108), that it does not need to use IPv4 on its interface. The goal is to avoid deploying dedicated IPv6-only network segments, 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 RFC 8925, first in macOS and Linux, and more recently (Public Preview) in Windows 11.

Mobile operating systems (iOS, Android, Harmony) have incorporated CLAT or equivalent features into their cellular interfaces since the inception of 464XLAT, and 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 on that interface, 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 Explicit Address Mappings (EAM) (RFC 7757 / STD 103), SIIT-DC (RFC 7755), and so on.

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 RFC 7050 (updated by RFC 8880, but generally not correctly implemented in most networks). Recently, a better alternative has been adopted, based on Router Advertisement (RA) messages, according to RFC 8781.

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

'Birds of a feather flock together'

IPv6-only+IPv4aaS (for example, 464XLAT) is a suitable transition mechanism for access networks. Networks connected using these mechanisms are typically unmanaged internally, generally mobile and residential, and even small and medium-sized corporate networks when they 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 citing its complexity as an excuse, which is untrue. 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 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.

Concluding

The most important thing is user satisfaction, and 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 also urge ISPs to demand this support. There are alternatives on the market, and we must choose not only based 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. Let's not rule out highly competitive OEM options with OpenWrt, which is even suitable for avoiding replacing existing CPEs with custom firmware for our network.

Jordi Palet Martínez has been working with computers, networking, and technology since he was eight years old. For the last 30 years, as CEO/CTO at The IPv6 Company, he has devoted most of his time to IPv6 R&D, standardization, training and consultancy, having already worked with hundreds of IPv6 customers in more than 150 economies across the world. He has co-authored several RFCs and books related to IPv6 and contributed to IPv6 training and policy-making in all the RIRs.

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.