Tipping point reached: transition to IPv6 enters a new phase
Norm is now IPv6-with-IPv4, not IPv4-with-IPv6
Norm is now IPv6-with-IPv4, not IPv4-with-IPv6
With IPv6 steadily continuing to make ground, we have now reached the point where IPv4 is no longer the default Internet Protocol and should be regarded as legacy. When computer networks are built or upgraded, IPv6 should now serve as the basis, with support for IPv4-only systems realised by means of an overlaid service.
In the IPv6-focused landscape, a new group of IPv4-to-IPv6 transition mechanisms has acquired a central role. As we move towards an IPv6-mainly world, it's time for old mechanisms such as dual stack with NAT and CGNAT to make way for newer alternatives based on NAT64, DNS64 and 464XLAT.
Adoption of IPv6 began to gather momentum nearly 10 years ago. Since then, user-side adoption has been growing steadily at roughly 5 percentage points a year. At the time of writing (October 2023), IPv6 accounted for roughly 45 per cent of traffic to Google.
Figure 1: Global client-side IPv6 use. Source: Google.
According to RFC 9386, the 2 main drivers of IPv6 adoption are the shortage of IPv4 addresses and pressure from national governments.
One of the reasons why neighbouring countries are well ahead of the Netherlands with IPv6 adoption [1, 2], is government policy.
In Belgium, the use of CGNAT is capped at 16 users per public IPv4 address; so that CGNAT does not prevent the identification of cybercriminals. The cap has been in place for 10 years, under the terms of a covenant between the Belgian public service providers and the country's access providers. The adoption of IPv6 was also important in that context, since the CGNAT cap places access providers at an economic disadvantage. [1]
In France, mandatory support for IPv6 in the big cities is a 5G licensing condition. The French government seeks to promote IPv6 mainly in the interests of interoperability, innovation and competition (the removal of barriers to market entrants). [1]
In Germany, the adoption of IPv6 is promoted chiefly by the federal government, whose Netzstrategie 2030 für die öffentliche Verwaltung includes a strategic commitment to IPv6 as the basis for the digitisation of public services. The ultimate intention is to expand the federal government network so that it serves as the basic network for all tiers of government. The strategy and the associated measures were set out by the country's interior minister in the IPv6-Masterplan für die Bundesverwaltung.
Further afield, the US [1, 2], Chinese [1] and Indian governments [1, 2] have adopted similar strategies.
In places such as Brazil, India, China [1] and other Asian countries, IPv6-only is in any case the sole viable option for providing tens or even hundreds of millions of mobile users with internet access.
RFC 9386 identifies the main obstacles and incentives on the road to an IPv6-only future. The ultimate (albeit currently remote) objective is an internet without IPv4 access, whether realised directly using a dual-stack set-up or indirectly using a transition mechanism. The RFC's authors address the transition to IPv6-only for access providers in the broadest sense: the document covers not only IPv4-over-IPv6 access enabled by traditional internet access providers and mobile service providers, but also IPv4 access within corporations, academic institutions and government bodies.
Their underlying assumption throughout is that we have now passed the stage where IPv6 access is provided via an IPv4 network. All network development and upgrade projects of any size should now be based on IPv6, with IPv4 access as an overlaid (essential) service. Given the steady rise of IPv6, no other form of network architecture may be considered future-proof any longer. An added advantage of such a strategy is that it greatly simplifies the choice of transition mechanism.
A study carried out in 2020 found that a dual-stack set-up was the most widely used transition mechanism amongst internet access providers. Because it involves IPv4 and IPv6 networks that are entirely independent of each other, a dual stack is the easiest set-up to implement. However, the implementation, management, maintenance and security of 2 parallel networks is relatively costly. Fortunately, IPv6 doesn't require any separate hardware, since it's now supported by all systems. Indeed, with less NAT capacity required and IPv6 traffic routed directly onto the network without address translation, savings can be made.
Despite having certain advantages, a dual-stack architecture does not help with the shortage of IPv4 addresses. A user still needs an IPv4 address to access an IPv4-only server, even though they use it less (resulting in a reduced NAT workload). Also, you still have the extra complexity of CGNAT.
Beyond a certain point, therefore, an IPv6 network with separate, overlaid support for access to IPv4-only systems is preferable both on economic grounds and because of the complexity of all the IPv4 workarounds required for other architectures. Hence the term 'IPv4 as a service' (IPv4aaS). RFC 9386 suggests that the tipping point at which an alternative (successive) transition architecture becomes the best option is when IPv6 traffic accounts for 50 to 60 per cent of the total.
The authors distinguish 2 relevant types of transition architecture:
IPv6-only overlay: the classic end-to-end IPv4 network, over which IPv6 traffic is tunnelled. This type of architecture no longer represents a sound solution, because it implies fully retaining and maintaining/upgrading your existing IPv4 network. That is definitely not appropriate for a growing network.
IPv6-only underlay: the network carries only IPv6 traffic, with IPv4 traffic routed through tunnels. There are 2 important reasons for opting for this architecture:
It's future-proof, because you can scale back your IPv4aaS systems as the IPv4 traffic volume declines.
It provides a good transition route from a dual stack because, once the IPv4aaS facility is in place, you can remove the remaining IPv4 element of your network from the underlay.
Note that this approach typically works only for access networks. On the backbone, you simply switch from IPv4-only to IPv6-only. The complexity of a dual stack or another transition mechanism is inappropriate for a data centre. So, for example, the biggest online service providers, such as Microsoft, Facebook and LinkedIn (the 'hyperscalers'), adopted IPv6-only strategies for their internal networks some years ago. Where possible, they have also sought to translate that into an IPv6-first proposition [Amazon].
However, IPv6-only is an attractive commercial option for small and medium-sized hosting service providers as well. Swiss service provider Ungleich profiles itself explicitly as an IPv6-only service provider under the banner of IPv6onlyHosting. Meanwhile, Hetzner, PCextreme (prior to its acquisition by Versio) and TransIP all offer IPv6-only virtual private servers (VPSs).
In all cases, prices can be discounted by up to a few euros a month because the cost of an IPv4 address is not incurred. If you nevertheless want to make your IPv6-only server accessible to IPv4 users, that can be realised using a (reverse) proxy, where you share your IPv4 address with other servers on the basis of Server Name Indication (SNI).
One of the most challenging aspects of setting up an IPv6 strategy has always been selecting an appropriate transition mechanism. The choice depends on what equipment you've already got, the size, complexity and architecture of your network, how far you have come with your transition to IPv6, and who you are (data centre, access/mobile/hosting service provider, enterprise). The following summary shows a dozen possible mechanisms, and the list is not exhaustive.
Click image to enlarge. The text continues below the image.
However, the steady growth of IPv6 has greatly simplified the choice of mechanism: as we approach the IPv4-IPv6 tipping point, the obvious choice is now IPv6-only on your access network, in combination with IPv4aaS to enable access to IPv4-only hosts (referred to above as an 'IPv6-only underlay' architecture).
That leaves the question of what the most appropriate IPv4aaS mechanism is. However, that choice has also become considerably easier. The transition mechanisms currently available for access networks are listed below in the green panel. According to RFC 9313 (not to be confused with RFC 9386, referred to above), the mechanisms in that list are the only ones that should now be used. Although the characteristics of and differences between the 5 algorithms are discussed in the second section of the RFC, anyone looking for a more accessible explanation is invited to check out our IPv6 FAQs.
Click image to enlarge. The text continues below the image.
Of the current mechanisms listed in the green section of the table, all the tunnelling-based options in the top half, such as DS-Lite, can be disregarded if you follow the advice of the US National Security Agency. The NSA advises against using protocols that rely on tunnelling and translation, except for NAT64/DNS64 and 464XLAT in IPv6-only networks. An important objection to tunnelling is that a tunnel bypasses the security of the network perimeter – firewalls, screening routers, etc. Given that 464XLAT is based on NAT64 and DNS64, the only option remaining is 464XLAT.
The advantage of 464XLAT is that it addresses the main IPv4-related problem, namely the address shortage. What's more, unlike CGNAT with its shared IPv4 addresses, 464XLAT does not limit (segment) the port range for the individual user. With 464XLAT, therefore, malpractice by a single user doesn't lead to a large group of end users all being blocked, as often happens with CGNAT.
According to RFC 9386, 464XLAT is the most popular option in the mobile world, while DS-Lite has the preference of internet access providers. Both mechanisms provide for IPv4aaS (visible to end users as dual stack/NAT) on an IPv6-only underlay (important for providers working towards IPv6-only networks).
In recent years, many internet access providers began by transitioning from IPv4-only to dual stack (in combination with (CG)NAT) and now run IPv6-only in their data centres. For the organisations in question, the main considerations are the cost of new IPv4 addresses, the cost of providing end users with new CPE (modems), and the cost of CGNAT capacity. The higher IPv4 address prices rise, the more likely the providers are to opt for CGNAT or IPv4aaS. And CGNAT has the added advantage of enabling them to retain their existing dual-stack/NAT set-ups [Delta].
The high cost and long depreciation periods of CPE in particular mean that an internet access provider is typically able to switch to a new transition mechanism only when installing, upgrading or replacing end-user equipment. What's more, CGNAT is not particularly problematic for the average end user [1, 2, 3].
By contrast, IPv4aaS (particularly 464XLAT) is a more obvious choice for mobile service providers with large user populations, because they are more likely to face challenges arising from the constraints of their IPv4 address portfolios and CGNAT systems [Telstra case]. Also, mobile service providers don't have the headache of replacing end users' legacy CPE hardware in order to effect a transition [T-Mobile case].
Enterprises are also opting for IPv6-only on their internal networks. However, the main driver isn't generally the IPv4 address shortage, because, unlike hosting service providers, they don't generally need to make large numbers of systems accessible to the outside world via IPv4. Enterprises usually realise connections with the outside world using proxies and NAT gateways, and therefore make extensive use of private IPv4 addresses.
Adoption of IPv6-only tends to be motivated mainly by the desire to protect against IPv4 namespace conflicts, which can be a major barrier to network integration in the context of mergers and takeovers. Another factor is that, for innovations such as the Internet of Things (IoT), IPv6 is essential because of the number of sensors, actuators and other devices that require their own IP addresses.
Many enterprises and hosting service providers are also obliged to support IPv6 in order to do business with public-sector customers, many of whom include such support in their procurement criteria.
Although many industrial companies have large networks and large user populations, they are typically more cautious about adopting new technology, say the authors of RFC 9386. One of the reasons is that they tend to have machinery and installations whose economic life can run into decades.
Nevertheless, transition to IPv6 is not uncommon amongst industrial companies in the context of major innovations, such as Industry 4.0, Industrial IoT (IIoT) and smart manufacturing. Against that background, it's important to note that there are often discussions within the IETF about the future of IPv4 and about whether its development should be continued as IPv6 becomes the norm (beyond what is necessary to realise the switch from IPv4 to IPv6, followed by the phased withdrawal of IPv4) [1, 2, 3].
What enterprises and industrial companies have in common is that ICT is not part of their core activities. Moreover, both are inconvenienced by, respectively, applications and equipment that don't work with IPv6, usually because of 'literals': hard-coded IPv4 addresses. Similar problems can arise with some smart end-user devices, e.g. smart TVs. 464XLAT copes better than NAT64/DNS64, but does require IPv6 support.
RFC 9386's authors also see enterprises and industrial companies as the main groups hampered by a lack of IPv6-related knowledge and experience. (SMEs also lack relevant expertise, but their network infrastructures are normally provided by their internet access providers.) Information and training are therefore needed to promote the adoption of new network technologies in such settings. The main reasons for using IPv6 in the conservative industrial world are the auto-configuration of IIoT equipment and IP-based standardisation in place of proprietary application protocols and communication systems.
IPv6 is not fundamentally different from or more complex than IPv4, especially when the many workarounds necessary for IPv4 are taken into consideration. Nevertheless, transition from IPv4 to IPv6 is a specialist field that must be addressed at the network strategy level.
For accessible information about IPv6 and why this modern internet protocol is so important, or if you need or want to get to grips with IPv6 yourself, see our IPv6 FAQs. Although the information is presented in question-and-answer form, it's also suitable for reading through from start to finish. The SIDN Academy also provides 2 IPv6 e-learning modules for .nl registrars. Finally, we regularly make IPv6-related news available on our website.