Internet Performance Delivered right to your inbox

Bashing IPv6 at TelecomNEXT

IPv6 is dead, and I think pretty much everyone already knows it. I gave a presentation about IPv6 at TelecomNEXT in Las Vegas last week (full presentation archived here) entitled “Realities of IPv6 as the Future Network Layer”. I regard it as a largely straightforward presentation of the facts: IPv6 is used by virtually no one, is not seeing significant adoption and has lost in the marketplace of new ideas. Since we will, in fact, run out of IPv4 address space eventually, and since IPv6 is obviously not the solution that people want for this problem, let’s start working on a better one right away. Of course, the presentation contains juicy quotes like:

  • “The market has spoken: IPv6 is the wrong technology at the wrong time and most organizations will profit from simply ignoring it”
  • “NAT and IPv6 are both evil, but IPv6 is the more dangerous of the two.”
  • “IPv6 was designed with no migration strategy from the real Internet.”

This perspective has been making a lot of people angry, since it implies (or rather, bluntly states) that those who have made significant investments in IPv6 have wasted their money, since we will obviously have to replace it with something else. I think that this conclusion is painfully obvious, but I guess lots of people are still deluding themselves. So who will win and who will lose in the ultimate failure of IPv6?

The basics of the argument are outlined in the presentation, but the core point is the one about a migration strategy: IPv6 is a new network protocol with no interoperability with IPv4 (and no, tunnels don’t count). It’s just a new, non-Internet network protocol. When network operators face the decision of whether to deploy it, they can consider IPv6 along with every other non-Internet network protocol to decide whether they meet some need. IPv6 gains no advantage whatsoever from the huge existing installed base of IPv4. That is the truly sad fact. Protocol designers chose purity of implementation over interoperability and thereby doomed IPv6 to a permanent, marginal existence.

Moreover, since virtually every important feature of IPv6 has been back-ported to IPv4 (auto-configuration, security, QoS), there’s no compelling reason for any individual user or end-site to want IPv6 service and there are a lot of reasons not to want it. There’s no content to look at. This is largely because there are no users. There are no users because there are no other users. And so on. The lack of true interoperability with IPv4 is death for any new network protocol hoping for Internet-scale adoption, even if it has “IP” at the front of its name.

So who is pushing IPv6? I think there are at least three categories of interested parties: equipment vendors, network consultants and protocol designers/developers. These last are true believers and will never agree with me on this issue. They’re convinced that IPv6 is a great network protocol and that everyone else will soon realize this. Perhaps. But they’ve been saying that for at least 5 years now. I suspect that we could just wait to see the continued non-adoption of IPv6 if we weren’t in need of a solution to the address space exhaustion issue.

Consultants like IPv6 precisely because it’s not compatible. It requires lots more work to integrate IPv6 with IPv4 than it should. And more work means more money for consultants. Example: Bechtel announces IPv6 roll-out, alone among US enterprises. Is it at all surprising that Bechtel, a contracting company that does the bulk of its work for the US military, would cheer IPv6 adoption? Smells fishy to me. It’s certainly not representative of the views of US industry in general.

Equipment vendors think that they like IPv6 because it obsoletes old hardware and encourages upgrading. But I think they’re seriously missing the big picture on this one: a long-term, slow, partial adoption of a new network protocol is just about the worst thing that can happen to someone like Cisco. Massive investment in new software and firmware and ASICs to handle IPv6 is being amortized over essentially zero business. Router vendors should wake up to the fact that IPv6 isn’t what people want to move to, and should get behind an effort to develop a protocol that interoperates with IPv4 while solving the address space problem. Such a protocol would have massive, immediate adoption and would spur far greater equipment upgrades and purchases than IPv6 ever will.

I suspect this won’t happen, though. I suspect that most of the people who have been involved in IPv6 (and dreamed up the shim6 end-station multi-homing foolishness) for the last several years probably think I’m an idiot. They think that these issues were discussed and settled and that the prudent thing is to go forward trying to fix IPv6. The problem is that they’ve been “fixing” IPv6 for at least eight years and it’s still not what anyone really wants.

Ultimately, if I’m right, it will be obvious by the fact that 2-3 years from now no one will be using IPv6. The only problem with that is that we’ll be that much closer to address-space exhaustion for real Internet (IPv4) addresses. Fortunately, we have some time. Geoff Huston estimates that IPv4 addresses will run out in June, 2013. Furthermore, once they run out, allocated-but-not-used space will be reclaimed taking us up to something like 2023. I guess that’s just about enough time for the stubborn IPv6 camp to admit they’re wrong and for all of us to come together and make something that we can easily migrate to.

Share Now

Whois: Dyn Guest Blogs

Oracle Dyn is a pioneer in managed DNS and a leader in cloud-based infrastructure that connects users with digital content and experiences across a global internet.

To current Dyn Customers and visitors considering our Dynamic DNS product: Oracle acquired Dyn and its subsidiaries in November 2016. After June 29th, 2020, visitors to will be redirected here where you can still access your current Dyn service and purchase or start a trial of Dynamic DNS. Support for your service will continue to be available at its current site here. Sincerely, Oracle Dyn