Deploying IPv6-Mostly Access Networks

For many years, many network operators have been trying to migrate most of their network to IPv6-only to address the shortage of IPv4 addressing. For end-user access networks, this presents a problem as there are still many legacy devices, apps and/or services that cannot work properly in an IPv6-only environment. Dual stack networks provide arguably the best user experience, but at the expense of not addressing the IPv4 shortage at all.

Mobiles are ready, desktops are not

The state of support for IPv6-only differs mostly by device type or, more precisely, by its operating system. In general, there should be no problem providing IPv6-only networks (with NAT64 and DNS64 to support Legacy IP) for mobile operating systems iOS and Android. In case of iOS, Apple forces all the app developers to publish only apps that support operation in an IPv6-only network. For web pages with IPv4 literals or broken dual-stack servers where IPv6 actually does not work, there is Happy Eyeballs version 2 (RFC 8305) support that mitigates possible bad user experience. Finally, for the purpose of tethering to a desktop computer, there is also a CLAT engine so that the tethered device gets dual stack service despite the fact that the mobile network can be IPv6-only.

In case of Android, the CLAT engine is the key feature mitigating problems with IPv6-only access networks. This allows unmodified legacy apps to work without major issues because, from the app perspective, the device is still connected to a dual stack network. Both iOS and Android devices are massively operated in IPv6-only mobile networks around the world, so it is pretty safe to expect that there should not be any major issues.

Regarding desktop operating systems, the situation is less satisfying. Users of Windows, Linux and macOS are still free to install apps from various sources, including legacy apps that use deprecated IPv4-only APIs. Such apps will not work unless IPv4 is provisioned to the device. At the same time, a CLAT engine that would address these issues is virtually non-existent. For Linux, there is clatd script, but it is not a standard part of any common distribution. Windows do feature a CLAT engine, but it only gets activated when a WWAN modem is directly connected to the machine. This way a Windows laptop can connect to mobile networks running IPv6-only and still support IPv4-only apps.

Due to this limitation of desktop operating systems, deploying IPv6-only access networks would cause issues for a certain amount of users. Network operators are therefore forced to run dual stack networks despite the fact that a significant number of devices do not require IPv4 anymore.

Turn off IPv4 by a DHCP option

To address this situation, a new DHCP option number 108 called IPv6-only Preferred has been recently standardised in RFC 8925. It allows a device to signal its capability to work properly on an IPv6-only network. This is done by requesting this option during the usual DHCP handshake. If the DHCP server is aware that the particular network supports IPv6-only operation, it will include such an option in the response, which will make the client stop the DHCP handshake before an IPv4 address is assigned. Therefore, despite the fact the network is dual-stack capable, IPv4 addressing is provided only to legacy clients not requesting the IPv6-only Preferred DHCP option. This may help in reducing the size of the IPv4 address pool.

I was curious to find out if this new DHCP option is already used on today's devices. For that purpose, I decided to measure the amount of devices requesting this option in the RIPE Meeting network during RIPE 84 in Berlin in May 2022. Throughout the week, I captured DHCP messages into a PCAP file. I then created a simple analyser using Scapy that counts how many unique MAC addresses requested the IPv6-only Preferred DHCP option. Here are the results:

Assuming that the number of unique MAC addresses correspond to the number of devices connected, this means that almost two thirds of devices claimed to support IPv6-only operation. Considering the fact that RFC 8925 is pretty recent, this is a very positive outcome. It turned out that the DHCP option is requested by not only all recent Android and iOS devices, but also by recent macOS (12.0.1 and newer). Neither of these platforms has a knob that would allow user to change the default behaviour. This would be concerning especially in case of macOS, where legacy IPv4-only apps can be still run.

There is a CLAT in macOS

It turned out the engineers from Apple considered this concern and actually included CLAT into recent versions of macOS. It gets activated only if these conditions are fulfilled:

• The DHCP server responds with IPv6-only Preferred option and
• There is PREF64 (RFC 8781) option containing the NAT64 prefix in the Router Advertisement

The second requirement is pretty interesting, as all the previous mitigations of issues with IPv6-only networks on macOS used NAT64 prefix discovery by means of DNS64 (RFC 7050). But since this type of discovery makes use of unauthenticated DNS, there are some security concerns. The PREF64 option on the other end, despite being also unauthenticated, shares fate with the other configuration parameters and thus can be trusted a bit more. If both requirements are satisfied, the CLAT gets activated, visible in the output of ifconfig command. Its function can be tested by trying to ping an IPv4 address literal.

New DHCP option is easy, new RA option is harder

So in order create a proper IPv6-mostly access network, we need to support both new DHCP option - telling compatible clients not to use IPv4 - and the new Router Advertisement option - carrying the NAT64 prefix. The former is pretty easy to achieve on most DHCP servers, as RFC 8925 does not require any special processing on the server side. So any DHCP server that supports custom DHCP options can be configured to offer option 108 to those clients who request it, containing only 32 bit timer value of how long should the IPv4 stack stay deactivated.

Regarding the PREF64 option for Router Advertisements, every single router has to be updated to support this new option. Fortunately, the support is slowly appearing in software routers:

• There is a prototype implementation in Python
• There is a pull request for FRR
• Support has been added to radvd
• There is a pull request for odhcpd daemon used in OpenWRT

DNS64 is still needed for Safari and iOS

Since the PREF64 option of Router Advertisements activates the CLAT engine, it is tempting to try running a network without DNS64. In such a setup, all IPv4 traffic would be forced through the CLAT engine. It works without issue on Android, as well as with most apps on macOS with one big exception: Safari. Somehow Safari refuses to use the CLAT engine and without DNS64, it will just not load any IPv4-only resources, neither domain names, nor IPv4 literals. The same situation is true for iOS. With just PREF64 and no DNS64, most apps cannot reach IPv4 Internet.

That means the IPv6-mostly network has to run DNS64 in addition to NAT64, the PREF64 RA option and the IPv6-only Preferred DHCP option. This will have some impact on legacy devices using IPv6-mostly network as a dual stack network. Since IPv6 is in general preferred over IPv4, all IPv6-ready apps will prefer to use NAT64 in place of native IPv4. Native IPv4 will be only used for corner cases like legacy IPv4-only app or using IPv4 address literals. By measuring the amount of native IPv4 traffic in the network, one can determine whether such cases are still happening or not and perhaps decide to retire IPv4 completely at some point in time.

IPv6-mostly looks promising

From my tests, it seems that IPv6-mostly network is fulfilling its purpose of providing the best user experience while utilising the least amount of IPv4 resources. On the other hand, there is some added complexity on top of traditional dual-stack networks and no direct saving on IPv4 resources, as IPv4 still has to be deployed everywhere in order to support legacy devices. But with coming years the amount of native IPv4 traffic in such network is supposed to decrease down to a point where it would make sense not to deploy IPv4 at all. With traditional dual stack, scarce IPv4 addresses would be assigned even to the majority of devices that don't need them, so DHCP pools are deemed to keep growing without limits.