Has IPv6 Peaked?

Several articles have attempted to address the topic of IPv6 Internet penetration over the years, including some of mine, based on metrics compiled and published by google in terms of the percentage of IPv6 connection attempts to their websites with respect to total attempts. Certainly this is but one metric of IPv6 end user devices and a convenient one at that. Over time I've fitted trend lines to these data points in an attempt to gauge the present and predict future penetration growth. Let's take a look at how those trends and forecasts have changed with increasing data points over time. We'll examine these cases with the application of a third order polynomial trend line in each scenario for consistency.

The following chart illustrates three such trends and predictions at roughly two year intervals. A dotted vertical line for each prediction indicates the point in time when the projection of the corresponding matching color was made. For our first prediction in June, 2016, made at the point in time shown by the leftmost vertical line in the chart, the trend line curved up steeply. Had that trend proven true, we'd be at 40% penetration right now and would reach 50% within a year. Two years later, in July, 2018 as shown in the chart at the point of the middle vertical line, the trend exuded a less optimistic path to IPv6 domination as the slope damped downward to a more linearly oriented growth trajectory, not eclipsing 40% penetration until February, 2021 and 50% fourteen months later.



Today's trend fitting of the data, shown at the point of the rightmost vertical line, has again diminished in slope and even hints the appearance of a leveling off. In fact, if we take the first derivative of the trend equation, graphed in the figure below, we can see that the rate of change has in fact peaked and is now diminishing. In fact, according to this formulation, the inflection point occurred in August, 2018.


Now just because we can fit a curve to google's observed data, obviously doesn't mean we can make definitive predictions, as made obvious by our prior attempts over the years. But it does call to question, at what point will IPv6 be "fully deployed"? Initial enthusiasm for the new Internet Protocol and the realization that IPv4 address space faced exhaustion certainly sparked bold predictions of total migration of IPv4 to IPv6 over only a few years. But countermeasures such as network address translators (NATs) of various flavors helped large organizations, namely service providers to better utilize their IPv4 space, and as some organizations such as cloud providers outright purchased IPv4 space, the fervor for IPv4's imminent demise faded.

Despite the IETF's attempts to declare IPv6 as "the" Internet Protocol and IPv4 as the legacy protocol to encourage deployment of IPv6, hopes of rapid, full migration faded to acknowledgment of a long tail for IPv4 and of IPv4-IPv6 co-existence. Unlike other technology "migrations" such as from prior generation mobile phones to smart phones, where the perceived benefits included new and desirable functionality for both consumers and service providers at a worthy cost, belief in a comparable leap in benefits of moving to IPv6 is not universally held. 

Most large service providers have IPv6 fully deployed within their networks, but given the incompatibility of IPv4 and IPv6, they've leveraged the aforementioned NATs or similar capabilities to enable their subscribers to access the dual protocol Internet. But for many enterprises, perceived IPv6 benefits do not surpass the cost and effort to deploy universally. These costs include the effort to validate infrastructure (compute, networking, applications) for IPv6 compatibility, managing the implementation, training of engineers and support personnel, and ongoing management, security and user support. Key benefits include improved mobility support, native Internet of Things (IoT) support over lossy networks, and a plentiful address supply. 

The chief benefit in my mind however is the ability to serve the whole Internet from your Internet presence; if google is currently seeing one-third of users attempting to connect with IPv6, you may be too. Thus I've been advocating for some time deployment of IPv6 alongside your IPv4 at least within your Internet facing services, e.g., your web services, email, DNS and other Internet-accessible applications. 

A dual stack Internet presence enables your organization to serve the full Internet without having to fully deploy IPv6 within your enterprise network. This approach offers savings related to confining the deployment scope and reducing the end user support costs since end users would still use IPv4 internally. In terms of adoption of such server-side Internet support, Eric Vyncke's website publishes measurements which indicate about 27% of Alexa sites have implemented IPv6 in terms of website and email reachability. 

As for the question of "are we done yet?," the answer is "not yet." While the rate of IPv6 penetration has slowed, growth is still positive and equilibrium may yield a roughly 50/50 split of IPv4 and IPv6 connections. But IPv6 ubiquity or even dominance won't happen until major device, networking equipment, cloud, and content network providers support only IPv6, necessitating organizational support. When all business communications may ensue using IPv6 bidirectionally and ubiquitously, only then may IPv4 be decommissioned. Until that time, we will likely see IPv6 penetration continue to slowly and steadily rise. So if you haven't deployed IPv6, I'd recommend analyzing your effort and cost to do so within your Internet presence initially.

If you're new to IPv6 and would like to learn more about it, I invite you to access our free online tools to help you familiarize yourself with business drivers for IPv6, your return on investment (ROI) for deploying IPv6, as well as IPv6 addressing and subnetting. These tools can help you understand the implications both of deploying IPv6 and of not deploying in terms of upside opportunity versus cost.

Comments

Popular posts from this blog

Handy AAAA filter in BIND 9.8

Inglorious DDI

BIND 9.8.0 Adds DNS64 Support - Part 2 - How is it configured?