Now that HTTPS is almost everywhere, what about IPv6?

Let’s Encrypt launched April 12, 2016 with the intent to support and encourage sites to enable HTTPS everywhere (sometimes referred to as SSL everywhere even though the web is steadily moving toward TLS as the preferred protocol). As of the end of February 2017, EFF (who launched the effort) estimates that half the web is now encrypted. Now certainly not all of that is attributable to EFF and Let’s Encrypt. After all, I have data from well before that date that indicates a majority of F5 customers enabled HTTPS on client-facing services, in the 70% range. So clearly folks were supporting HTTPS before EFF launched its efforts, but given the significant number of certificates* it has issued the effort is not without measurable success.

On Sept 11, 2006, ICANN “ratified a global policy for the allocation of IPv6 addresses by the Internet Assigned Numbers Authority (IANA)”. While the standard itself was ratified many years (like a decade) before, without a policy governing the allocation of those addresses it really wasn’t all that significant. But as of 2006 we were serious about moving toward IPv6. After all, the web was growing, mobile was exploding, and available IPv4 addresses were dwindling to nothing.

We needed IPv6 if not for its enhanced security then for its expanded address space that would allow us to support billions of connected devices and things.

And yet the adoption rate is abysmal. Consider that “the cloud” was born in an age when IPv6 was available. And yet it took until late 2016 for Amazon AWS and Microsoft Azure to turn on IPv6 in their cloud offerings for compute instances.  

This has led some to lamenting that if we can get HTTPS almost everywhere in such a short time, why are we still seeing such a small percentage of sites supporting IPv6? Google estimates that 16.06% of users are IPv6 enabled (which is interesting when compared to service providers support as tracked by the World IPv6 Launch) but only 10% of web sites (according to W3C Techs) support it.

To be fair, HTTPS was not new. EFF was merely encouraging and empowering folks to enable what was already at their fingertips. HTTPS is well-supported, well-understood, and thoroughly baked. So perhaps it would be more fair to compare it to a newer standard, one with similar drawbacks such as incompatibility with previous standards, like HTTP/2.

Back in May 2015, a new version of a stalwart web standard was ratified: HTTP/2. Like IPv6, it is incompatible with previous versions. Unlike “SSL Everywhere”, supporting IPv6 or HTTP/2 is not simply a case of acquiring a certificate and enabling HTTPS on your web servers or infrastructure. While it’s true that moving from HTTP to HTTPS can be disruptive – it can impact your network infrastructure – it’s not the same level of disruption as incurred by IPv6 or HTTP/2.

Moving to new foundational protocols requires a transitional approach; one that requires support for both the old and the new simultaneously until some future point in time. That means “dual-stacks” for every device through which traffic might flow. This is a Herculean effort for some organizations, and an architectural nightmare for others. Just as software incurs technical debt, networks incur architectural debt, and it is likely the case that the “interest payments” on that architectural debt make it difficult to build a valid case for adopting IPv6. After all, it’s not like it’s a requirement or anything. Business will continue if you don’t support IPv6.

Or will it?

Let’s remember that originally, HTTP/2 was going to require TLS/SSL. There was some grumbling and eventually it was made optional. Browser builders blithely ignored that and only provided support for HTTP/2 over TLS/SSL, effectively forcing the requirement on everyone. In late 2015 Google began prioritizing HTTPS-enabled sites in search rankings. And in 2016, Apple made similar moves that required all native apps to use App Transport Security, again effectively forcing the move to HTTPS.

Basically, HTTPS has been forced by those on the client side to support it.

For IPv6 right now there’s no similar requirement. We all watched as IPv4 addresses disappeared but it had relatively little or no impact. So no one feels a real impetus (yet) to make a move that’s potentially going to be disruptive and expensive. But as more things emerge it’s entirely possible that they’ll eventually come out of the box supporting only IPv6. Things have small form factors and their processing power is limited. Less is more in the Internet of Things. That’s one of the reasons many IoT devices eschew HTTP in favor of MQTT; it’s smaller, faster, and more efficient than its heavier web cousin. Supporting both IPv4 and IPv6 is similar. Because they are incompatible most devices support one or the other. And eventually they’re going to choose one and everyone will be scrambling to support it.

Even if they don’t, the IPv4 addressed available today can accommodate less than 20% of the 20 billion devices projected to be in use by 2020 (Gartner). IPv6 supports way more than even Cisco’s more aggressive predictions of 50 billion devices. And that’s just the IoT.

Cloud, too, is problematic because it can’t buy up enough IPv4 addresses to support its growing customer base. If IaaS is going to grow as predicted, cloud providers must move to IPv6. Which is no doubt in part behind the move by Amazon and Microsoft to do so.

What all these means is that a forcing function will eventually come that requires IPv6 support. It may be IoT, or it may be the cloud, itself. It may be the explosively disruptive combined force of the two on your business. Either way, we’re going to have to transition at some point, and it’s always best if you aren’t rushed into it. We’ve had a long time to work out the kinks with IPv6, and there are more than enough solutions on the market today to support the dual-stack approach to get the transition going. So if you haven’t yet, it’s time to seriously consider enabling IPv6, before you’re forced into it by the things business needs to keep on growing.

* Yes, we could dive into the number of seemingly fraudulent certificates and that blindly handing them out like candy is fraught with risk, but that’s another issue for another day.