We shouldn't gauge the success of IPv6 by looking at how much IPv6 replaces IPv4, but by how much IPv6 complements IPv4. And it's already doing that quite well today by making IPv4aaS (IPv4 as a service) possible.
Some 15 years ago, I used to tell people that the fact that virtually nobody was paying attention to the IPv6 transition meant that by 2020 or so, IPv6 would either be the biggest technology failure ever, or the biggest technology triumph ever. Failure if after the internet industry doing an incredible amount of work to get IPv6 off the ground, we'd still be at 0% IPv6 deployment by that time. Triumph if 100% of all devices that interact with the internet had been updated to use IPv6 without users noticing. Back then, it could still have gone either way.
Turns out, as we saw two weeks ago in The rise of IPv6 and fall of IPv4 in the 2010s, as of today, about 25 to 30 % of the internet has IPv6 connectivity. So the binary thinking "0% IPv6 = failure, 100% IPv6 = success" didn't pan out. So far, at least. So do we wait a bit—or a lot—longer for IPv6 to reach 100% deployment so we can claim success? Or do we move the goalposts and adopt new criteria for success?
But first, let's have a look at the prospects for reaching 100% IPv6 deployment. Looking at the Google statistics, global IPv6 deployment increased by about 5% per year since the start of 2016. So at this rate, we should reach 100% IPv6 deployment in 2034. However, adoption of new technology doesn't follow a straight line like this. According to the theory of diffusion of innovations, such adoption follows an S-curve:
So we should expect IPv6 adoption to start slowing down at some point. In 2017, APNIC's George Michaelson fit Google's stats to an S-curve and concluded that we'd be at 80% IPv6 deployment in 2022. However, we missed the predicted 40% by 2020 by at least 10%. In a follow-up article from 2019, he concludes that the story has both become clearer and not become clearer.
And last year, Christofer Flinta of Ericsson Research modeled IPv6 deployment and determined that "the model predicts a surprisingly low final level of IPv6 deployment at only around 28%". IPv6 deployment is around 30% during weekends and currently only about 25% during week days, so we're still 3% below the predicted 28%.
So based on the data, the 100% IPv6 date can fall anywhere between 2027 and when the cows come home. Then again, prediction is hard, and very few people are still running IPX or AppleTalk or other network protocols that were common throughout the 1980s and 1990s. (And moving from IPv4 to IPv6 is a breeze compared to moving from IPX or AppleTalk to IPv4.)
IPv6 is better than IPv4 in many ways. But not so much better that it's worth it to replace IPv4 with IPv6 for people who currently have IPv4 connectivity that works well. Even adding IPv6 to IPv4 doesn't really make economic sense for those with good IPv4. Even though the same equipment will run both IPv4 and IPv6, there's the additional complexity of running an extra protocol and the interaction between the two protocols.
That means that staying with (only) IPv4 makes all the sense in the world, except for that tiny little detail: we don't have enough IPv4 addresses. However, IP addresses are not consumables: the IPv4 addresses you already have keep working just fine. The problems start when you need more addresses because an enterprise network adds more devices, or a service provider network adds more subscribers.
Disconnecting from the IPv4 world is not an option at this time, as IPv4 has all the content and IPv6 only a quarter or so. So in places where IPv4 addresses are becoming scarce because of growth, IPv4 addresses need to be shared. This is not new: pretty much all consumers have multiple internet-connected devices, but they only get a single public IPv4 address from their ISP. The home router slices and dices that address through Network Address Translation (NAT) so multiple systems in the home can share it. This works fine for communication initiated on the inside and then going out to a system outside, because the NAT saw the outgoing packets so it knows to which system it needs to send the matching incoming packets.
However, NATs do get in the way of incoming communication, because the NAT has no idea which internal system wants to see those packets. When this firewall-like side effect of NAT isn't desired, it's usually possible to work around this by telling the home gateway which system should be the recipient of incoming communication.
When ISPs no longer have enough IPv4 addresses to give one to each subscriber, they can add a big NAT of their own (often called Carrier Grade NAT, CGN). However, this makes getting incoming communication to work a lot harder. Few users want or need to run a server, but incoming communication is also needed for peer-to-peer communication, including VoIP and especially video chat such as Facetime.
Another issue with NAT in the ISP network is that all traffic needs to go through the NAT. So when traffic increases, this means buying more or bigger NATs.
The severity of these NAT issues is greatly reduced by adding IPv6. If a user has IPv6, they can engage in peer-to-peer communication with other similar users over IPv6. And in the case of peer-to-peer communication with an IPv4 user, the peer-to-peer session can be initiated from the NAT+IPv6 user towards the IPv4 user, so the NAT on the NAT+IPv6 side is not an issue.
NAT+IPv6 also requires less NAT capacity because the NAT+IPv6 user will be communicating over IPv6 some of the time, and that IPv6 traffic doesn't go through the NAT. Even better: as more and more services become available over IPv6, the amount of traffic through the NAT could actually go down. At the very least, NAT capacity needed for NAT+IPv6 users will always be smaller than that needed by NAT users who don't have IPv6.
It's a well-known fact that all technology issues magically go away by adding "aaS" to an acronym. It is of course possible to create a NAT+IPv6 service by providing public IPv6 and private IPv4 to users, and then translate the private IPv4 to public IPv4 with a CGN. But this means running three networks: IPv6, public IPv4 and private IPv4.
How about this alternative: we give the subscriber just IPv6, and then we provide translated (NAT64) or tunneled NAT (DS-Lite) IPv4 service over that IPv6 connectivity. This way, there are no IPv4 packets with private addresses passing through the network that may cause confusion. At some point, ISPs will probably want to get out of the business of providing translated IPv4 and outsource this service to specialized "IPv4aaS" suppliers.
When IPv6+IPv4aaS users visit websites that are only reachable over IPv4, that means a NAT64 or a DS-Lite CGN has to translate the traffic. Not a big deal, that's why it's there. Regular web traffic isn't all that much. But what if that same user starts to watch video? That's at least a megabit or two, and can be as high as 15 or 25 Mbps—lasting for many minutes, maybe even hours.
So for an ISP with IPv6+IPv4aaS users, it's much better if those users watch their streaming video on streaming services that have IPv6, such as Netflix. When users stream video from a service that is only reachable over IPv4, such as Disney+ (in December 2019, at least), those massive amounts of traffic need to be translated, which requires more hardware and more IPv4 addresses.
In general, it's in the best interest of both content providers and ISPs to have direct network connections ("peering"), as that saves both parties costs and provides the best user experience. ISPs often attach conditions to peering. It makes sense that in the future, ISPs start requiring that high traffic services be available over IPv6 as a condition for peering.
Or perhaps they won't upgrade their NAT64/CGN capacity quite as quickly as traffic increases, so translated IPv4 may experience slowdowns while IPv6 is fast. Even without that, IPv6 is likely to perform better, because routers can select a direct path from the user to the outside world. Unless the NAT64/CGN is on that direct path, the IPv4 path will be longer and therefore (a little) slower.
In this roundabout way, the people who are feeling the IPv4 squeeze will pass on the pain to those who don't, and give them an incentive to upgrade, too.
Based on the above, we can conclude that over the next few years, two groups will deploy IPv6: ISPs with a quickly growing subscriber base and big content providers. We're already seeing significant NAT64 deployment by mobile operators, as most modern phones work well with NAT64 and the operators can easily give NAT64 to compatible phones and IPv4 (with NAT) to other phones.
For a new enterprise network, it could make sense to adopt the IPv6+IPv4aaS model, although they may encounter hardware or software that won't work over such an IPv6-only enterprise network. For existing enterprise networks, it's already expensive and complex to just add IPv6, let alone remove IPv4. So it's unlikely that much IPv6 deployment will happen in enterprises, except maybe in enterprise networks that are so large that they run out of private IPv4 address space.
Right now, the internet is no longer an IPv4-only network. IPv6 is doing what it was designed for: allow the internet to continue to grow even though IPv4 can no longer support that growth as it has before. Success! But for the foreseeable future, there is no business case to be made for an all-IPv6 internet... IPv4 will probably be around to celebrate its 50th birthday in 2031.
23 January 2020, by Iljitsch van Beijnum.
