As I was preparing my keynote presentation for the recent UK IPv6 Council AGM held in London earlier this month, it occurred to me that I’ve spent a significant amount of time talking about how good IPv6 is at these and other meetings, often to those who are already championing and using the protocol. So, I’m writing it down and sharing it with a wider audience, notably those who are using common misconceptions as reasons for not deploying IPv6.

Misconception #1: It’s been 25 years and only a quarter of the Internet is using IPv6, it should be abandoned

About a month ago, I came across an article that talked about IPv6 being a failure and should be abandoned due to it taking 25 years to reach 25% deployment. What struck me the most was the reference to it having been 25 years.

If you look at Figure 1, it’s obvious that IPv6 was dormant (non-existent) until IPv6 World Day in 2011 and the IPv6 World Launch in 2012. These two events really kickstarted the concerted push for IPv6 — not only its deployment but content delivered by it. As such, I’d say it has not been 25 years but six or seven years, at the most.

Figure 1 — IPv6 adoption graph. Source: Google

One might argue that even 25% adoption is still not impressive in this time frame. Well, there is one thing to remember here: 25% is an average adoption rate across the whole Internet, and many of you realize there is no such thing as a homogeneous Internet. The Internet comprises millions of different kinds of networks with their own drivers and challenges on the road to IPv6 adoption. As such their experiences will vary.

For example, there are enterprises and financial networks that are very conservative, with a long hardware/software life cycle, happily hiding behind a single public IPv4 address. These networks are in no hurry to deploy IPv6 even though some have started moving slowly in the right direction.

On the other side of the spectrum mobile networks, which have a huge and rapidly increasing number of clients, cannot continue to hide behind layers of NAT. Apple measurements show that for cellular networks, 44% of all connections globally are made from an IPv6-enabled network; in the US that number is almost double. In other words: half of all mobile devices are IPv6 enabled and if you are in the US, there’s almost a 90% chance that your phone has IPv6. Instances like this make it hard to believe that IPv6 should be abandoned because no one is using it.

Read: The Mobile Internet: Home of IPv6

Misconception #2: “I don’t need IPv6”

For those who read the section above and recognize that IPv6 is being deployed by multiple networks but believe it is and won’t be relevant for your network, let me try to convince you otherwise.

We’ve been talking about ‘why you might need to deploy IPv6’ for years; IPv4 address scarcity and issues caused by NAT are all well known. However, there are some other reasons for you to consider deploying IPv6.

First, let me tell you a story.

About 12 years ago, when I was working for a network equipment vendor, I was talking to a customer about a shiny new wireless solution that included centralized management and wireless controller access points providing not just Wi-Fi but also allowing location tracking using triangulation. “Oh no!” said the customer. “We do not need all that weird stuff. We are happy with our Cat5 cables. Besides, it must be very insecure and would allow anyone to connect to our network!”.

The truth was they had wireless network features deployed already but in a totally uncontrolled and very insecure manner. Their employees were bringing their own access points creating ad-hoc networks because it was convenient for them; more so than being locked to an ethernet plug. But all these things were discovered later when the customer decided to deploy the wireless network and started to monitor the environment.

Now, what does this have to do with IPv6? Well, the same principle applies: if the mountain won’t come to Muhammad, then Muhammad must go to the mountain. If you won’t come to IPv6, then IPv6 must go to you (and you might not even notice). Most modern switches and routers have IPv6 enabled and so have end hosts (laptops, mobile devices). As soon as you connect two such devices to the same network, they are now able to communicate over IPv6.

Networks that are intended to be IPv4-only might (and most likely will) be lacking IPv6 security features, which leads to accidental service disruptions and deliberate attacks. The most obvious example is a rogue device that sends router advertisements, making itself an IPv6 default router for all IPv6-enabled devices on the link. While Happy Eyeballs would provide a quick fallback to IPv4, if a rogue router is just a plain misconfiguration, the intentional attack could easily result in a connectivity outage or a man-in-the-middle attack scenario. You can find more details on this topic here: RFC 7123, Security Implications of IPv6 on IPv4 Networks.

Read: Happy Eyeballs – promoting a healthy IPv4 and IPv6 coexistence

For those who care more about serving content to users, IPv6 might bring some benefits too. To serve content you need DNS, which in turns means that DNSSEC might (or shall I say should?) be of interest to you. There is one problem with DNSSEC though: it does not work very well for IPv6-only validating clients and DNS64. It’s 2018 (almost 2019) and it’s a bit late to say ‘don’t deploy NAT64/DNS64 networks’ for that ship has sailed; there are millions and millions of IPv6-only devices in mobile networks. Therefore, if you deploy DNS, you should deploy DNSSEC and if you deploy DNSSEC you should also enable IPv6.

There is another compelling reason for IPv6 adoption: allegedly it might be faster than IPv4, at least in some economies. APNIC measurements look quite positive and Akamai reported that for US mobile clients IPv6 is 10% faster than IPv4.

Check back tomorrow for four more misconceptions.

Jen Linkova is a Network Engineer at Google and Co-Chair of the RIPE IPv6 Working Group.

Rate this article

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.