Dual-stack is the most common way of deploying IPv6 in access networks. A recent standard defines IPv6-mostly access networks, providing IPv4 connectivity only for legacy devices while allowing modern devices to run IPv6-only. It is already well supported and allows network operators to gradually phase out IPv4 from the access networks.
Many network operators have been trying to migrate most of their network to IPv6-only to address the scarcity of unallocated 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 IPv4 scarcity 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 the 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 poor user experience. Finally, for the purpose of tethering to a desktop computer, there is also a Customer-Side Translator (CLAT) engine so that the tethered device gets dual-stack service despite the fact that the mobile network can be IPv6-only.
In the case of Android, the CLAT engine is the critical 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 a clatd script, but it is not a standard part of any common distribution. Windows does 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 number 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 with a DHCP option
To address this situation, a new DHCP option number 108 called IPv6-only Preferred has been recently standardized 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 network being 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 number 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:
Unique MACs: 1441
Option 108 enabled: 951 65%Assuming that the number of unique MAC addresses corresponds 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) devices. Neither of these platforms has a knob that would allow users to change the default behaviour. This would be concerning especially in the case of macOS, where legacy IPv4-only apps can still be run.
There is a CLAT in macOS
It turned out that engineers from Apple considered this concern and actually included CLAT in recent versions of macOS. It gets activated only if these conditions are fulfilled:
- The DHCP server responds with the IPv6-only Preferred option, and
- There is a PREF64 (RFC 8781) option containing the NAT64 prefix in the Router Advertisement (RA)
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.
The new DHCP option is easy, new RA option is harder
So, in order to create a proper IPv6-mostly access network, we need to support both the new DHCP option — telling compatible clients not to use IPv4 — and the new RA 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 a 32-bit timer value of how long should the IPv4 stack stay deactivated.
Regarding the PREF64 option for RAs, 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 the odhcpd daemon used in OpenWRT
DNS64 is still needed for Safari and iOS
Since the PREF64 option of RAs activates the CLAT engine, it is tempting to try running a network without DNS64. All IPv4 traffic would be forced through the CLAT engine in such a setup. 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 the 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 apps 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 the IPv6-mostly network is fulfilling its purpose of providing the best user experience while utilizing 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. However, in the coming years, the amount of native IPv4 traffic in such networks is expected to decrease to a point where it would make sense to not 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.
Ondřej Caletka is a technical expert in the Learning and Development team at RIPE NCC.
This post is adapted from the original at RIPE Labs.
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.