When Will We Stop Using IPv4?
by Scott Hogg, on Oct 15, 2018 9:40:30 AM
When someone first starts learning about IPv6 they quickly come to understand that an IPv4-only node cannot communicate with an IPv6-only node and that dual-stack is the dominant transition method. Now, six years after World IPv6 Launch, there is a growing amount of IPv6 traffic on the Internet and in the next few years we might observe IPv6 Internet traffic surpassing IPv4 traffic volumes for the first time. One of the IPv6 novice questions we are being asked more frequently is “when will we stop using IPv4?” Let’s dive into this question and see if we can’t answer it.
Protocols Come and Go
There was an era twenty years ago when it was perfectly normal to operate a multiprotocol network running IPX/SPX, AppleTalk, SNA and IPv4. It has been decades since protocols like DECnet, ARCNET, CLNP, Vines, X.25, Frame Relay, DLSW, and so on, were used on enterprise networks.
Remember how satisfying it was to decommission some legacy piece of technology? Recall the joy you experienced when you took out that FDDI ring from your network, or when you turned off that last Windows XP computer? Ahh, for that refreshing feeling of cleanliness and accomplishment removing some old IT detritus and basking in the radiance of the remaining homogenous modern network!
IPv4: Here Today, Here to Stay
In the 1990s, TCP/IP took over as the dominant routed network protocol and quickly became ubiquitous on private networks. As the Internet exploded, IPv4 traffic volumes rose exponentially. When you look at a graph of the number of entries in the IPv4 BGP default-free-zone routing tables, you can barely spot the dot-com bubble bursting in 2000 or the 2009 global economic recession. IPv4 has been growing at a significant rate and will continue to increase as documented in theCisco Visual Networking Index (VNI). Now, with the rise of Internet video usage, global proliferation of mobile devices, and the Internet of Things, more and more IPv4 packets continue to flood the Internet.
IPv6 Enters the Picture
In the early 1990s, first generation Internet engineers determined that the use of classful IPv4 addressing and the expected growth of the Internet were going to cause scalability problems that would potentially inhibit its further expansion. The IETF initiated an effort to develop a next generation Internet protocol that could scale to meet future demands of global networks. By 1998, IPv6 was born as RFC 2460, which has now become a full standard with RFC 8200.
Since then, IPv6 has experienced an uphill battle as the prospect of migrating from IPv4 to IPv6 became more challenging each year that IPv4 continued to flourish. IPv6 needed to be integrated into the end-node operating systems, integrated into the network devices, deployed by broadband, deployed by the mobile service providers, and adopted by content providers. It became apparent that running IPv6 in addition to IPv4 was the only viable approach to smoothly migrate from one protocol to the other (given that IPv6 is not backwards-compatible with IPv4).
However, the downside to the dual-stack migration strategy is that you end up running two protocols in parallel for possibly a long time. Theoretically, the duration of the dual-stack phase of IPv6 migration begins when the first device receives an IPv6 address until the last device disables IPv4. Depending on the size of the network, this interval could be as brief as a few minutes or as long as decades! The other challenge with running a dual-protocol network is that you have to maintain both protocols, thus increasing operational costs.
For several years now, Internet IPv6 traffic volumes have been doubling. Depending on where you take your measurements, IPv6 can sum to a sizable amount of the network bandwidth. There is evidence that IPv6’s growth is having a slowing effect on IPv4 traffic volumes. There have also been studies showing that IPv6 is accelerating as IPv4 is nearing its peak. The crossover point where the IPv6 traffic percentage surpasses the IPv4 traffic percentage may only be a couple years away.
The IPv4 Long Tail
John Curran, President and CEO of ARIN, gave a presentation at the 2017 North American IPv6 Summit where he discussed the long-tail of IPv4 (see slide 15). It is clear that we will be using both IPv6 and IPv4 in parallel for many years to come. There is no specific predetermined date when the Internet or private networks will stop using IPv4 entirely. Just like there was no “flag-day” for an Internet-wide migration to IPv6, there will be no “flag day” for IPv4 decommissioning. However, there have been flag days of-a-sort when the RIRs have exhausted their supply of IPv4 addresses.
Imagine a consumer who has just purchased an Internet-based cat feeder that only uses IPv4 to communicate to a cloud service and the owner’s mobile app. This new IoT device should last for many years and cats have been known to live 15 or more years. Therefore, if you are the ISP for this subscriber you will need to support IPv4 for a considerable length of time and you will need to provide a unique public IPv4 address to this subscriber’s home router that performs NAT. After all, you don’t want someone’s poor cat to starve, do you?
Also, there are still many enterprise organizations that have not yet deployed IPv6, and probably haven’t even contemplated IPv6 to any significant degree. Many enterprises have not provided IPv6 training to their IT teams and those teams have not obtained IPv6 education on their own. These enterprises have not taken their first steps toward creating a plan for IPv6 deployment, much less requested global IPv6 address resources or created an addressing plan. These technology laggards on the “diffusion of innovations” and the IPv6 adoption curves will lengthen this dual-protocol phase for all. Those IPv6 slowpokes will learn to love NATs as described in the Internet Protocol Journal article by Geoff Huston, Chief Scientist at APNIC, titled “In Defense of NATs” (see page 25).
Getting Ready for IPv6-Only
There are some organizations that are aggressive about their use of technology to achieve a competitive advantage and that, as a result, are starting to deploy IPv6-only networks. Many of these organizations presented their IPv6-only strategies at the 2017 North American IPv6 Summit event. However, all these organizations are providing some method for their IPv6-only hosts to reach legacy IPv4-only systems, such as DNS64/NAT64.
T-Mobile has been working on IPv6-only mobile devices for their subscribers for several years now. Stephan Lagerholm, Senior Manager, Systems Design and Strategy, Technology at T-Mobile, gave a presentation at NANOG 73 on “Going IPv6 Only”.
LinkedIn’s IPv6 Engineering team has had a preference for IPv6 for a number of years and last summer they published how their IPv6 traffic volume passed the 50% mark.
Facebook has been striving to operate IPv6-only data centers. In May of 2018, they noted that their IPv6 traffic volume surpassed their IPv4 traffic volume for the first time.
Microsoft has been operating IPv6-only environments in their buildings. Veronika McKillop, network architect at Microsoft recently wrote about their experiences operating these IPv6-only environments.
Cisco has been experimenting with an IPv6-only environment in their San Jose California Campus Building 23.
On a broader scale, there are a few countries that have passed the 50% IPv6 milestone. Belgium is one of the first countries to be listed on the Google IPv6 Statistics page as having over 50% IPv6 traffic. Countries like Germany, India, United States, Uruguay, Sweden, Greece, Switzerland, and Finland (among others) may be close to reaching the 50% mark in the next year or two.
Internet service providers and mobile carriers would rather operate only a single protocol on their massive backbone networks. However, even though they would prefer to operate an IPv6-only network, their subscribers have many IPv4-only devices that will need to be supported for many years. Service providers are calling this method of connecting legacy IPv4 nodes over an IPv6-only core “IPv4-as-a-Service” (v4aaS). This 3-part Infoblox IPv6 COE blog series provides background on this v4aaS topic (Part 1, Part 2, Part 3).
Predicting a Date
Generally speaking, asking an IPv6 evangelist to predict a date of when something will occur is not advisable and the answer is likely highly suspect. Even with that disclaimer now in place, we have evidence of places on the Internet where IPv6 has already surpassed IPv4 traffic volumes. We also have evidence that there are private networks that are running IPv6-only (e.g. T-Mobile, Cisco, Microsoft, LinkedIn, Facebook). We see IPv6 traffic volumes continuing to increase as more devices get upgraded and service providers continue their deployments. We expect more IPv6 traffic once enterprises start their IPv6 deployments.
Typical IT refresh cycles for organizations can vary between 3 and 10 years. If you assume that we expect to cross-over the 50% threshold of IPv6 traffic surpassing IPv4 traffic in the 2020 timeframe, then you can add another 10 years to that date for IPv4 traffic volumes to decline. Predicting that IPv4 will “go the way of the dodo” sometime after 2030 would be a reasonable estimate.
This post originally appeared on Infoblox Community at https://community.infoblox.com/t5/IPv6-CoE-Blog/When-Will-We-Stop-Using-IPv4/ba-p/14817.
Scott Hogg is the Chief Technical Officer (CTO) of Zivaro, formerly GTRI.