IPv6 — Still No Love?


For the last few Interop conferences in North America, I’ve been the Infrastructure track chair or co-chair. As such, it’s my job to put speakers on the platform who are addressing key issues in networking, data center operations, and anything else broadly falling under the category of infrastructure. Sometimes, I recommend sessions that aren’t likely to enjoy huge popularity, but are appropriate in the context of what should be important to the industry. IPv6 has been one of those topics.

First, a question. Do we need IPv6? The answer is yes. IPv4 address depletion is in its final stages. There are almost no more IPv4 address space to give out — 0.21 /8’s from ARIN as of this writing. RIPE, too, is nearly out. It’s true that carriers have been aggressively deploying IPv6, and companies like CloudFlare make it easy for your web site to be IPv6 accessible. But North American enterprises have not been deploying IPv6 all that much.

  1. When I ask vendors about IPv6 support in their products, the response is almost always that “customers aren’t asking for it.” I’m tired of that answer. Vendors should have IPv6 functionality available from the start, and not make a half-hearted attempt later to roll it in. There are times when a vendor needs to give customers what they need, not what they want. Some customers ask for dumb things or don’t know what they should be asking for.
  2. When vendors do support IPv6, there’s often an asterisk. Yes, IPv6 is supported.* (Sort of.) Full IPv6 support seems hard to come by in many products.
  3. Workarounds for the IPv4 shortage problem abound. NAT. CG-NAT. IPv6/IPv4 proxies. And now, as noticed at Interop, companies specializing in the IPv4 aftermarket. There are many organizations who have more IPv4 addresses than they need, and thus they are selling them off since IPv4 is still in demand, creating a market opportunity. This transfer still involves a RIR, as I understand it, but the point is that IPv4’s overly long life continues to be extended by those desperate to cling on as long as possible.

On the plus side, folks are waking up to the fact that there is genuinely an IPv6 need, and that IPv6 runs by default on common operating systems like Microsoft Windows. There was good interest in Interop IPv6 sessions by Ed Horley and Jeff Carrell. That said, the adoption problem remains one of time and priority. When network engineers have a long list of competing priorities, IPv6 will fall to the bottom of the pile.

When IPv6 becomes a business problem, and not a technical one, it will start seeing serious adoption in the enterprise. A lack of available IPv4 addresses and expensive aftermarket pricing might start driving North America towards broad IPv6 adoption. Finally.

At Interop, a few of us got together as a Tech Field Day delegation to riff on the IPv4 & IPv6 trends we noticed at the conference. Enjoy.

About the author

Ethan Banks

Most people know me because I write & podcast about IT on the Packet Pushers network. I also co-authored "Computer Networks Problems & Solutions" with Russ White.

Find out more on my about page.


  • So the first implementations of IPv6 is 20 years old this year:

    Let’s say it takes 10 years to: define all the protocols and build implementations and do interop testing.

    So what is the percentage of the hardware in the average datacenter or network that is still running and older than 10 years ?

    But surprising enough we are at less than 25% of the providers networks:


    I understand why this is, sometimes that just makes me a bit sad.

  • Please, anyone, convince me that the business value of running v6 INSIDE an enterprise exceeds the business costs of migration, retraining, complexity and add-on security risk. Won’t the need for more than 2^24 addresses remain literally an edge case for decades? Even on the global Internet, how long before a cheap-and-good-enough simpler-to-implement alternative sends IPv6 to rest with X.400, X.500 and Token Ring in the junkyard of over-engineered geek dreams?

    • @Tellmemor – Deploying IPv6 is typically not an all or nothing proposition. In terms of deploying IPv6 throughout your entire Intranet, I agree – why would you do that? It would be expensive, time consuming and resource draining. Where I do see people deploying IPv6 it’s for specific needs – typically from the IoT space. For example, many companies are trying to reduce their energy costs as they are a large percentage of budget. Many automated facilities and energy management solutions are IPv6-only. Not all, but some. So if facilities finds the perfect solution to reduce their energy costs by 40%, they won’t ask IT for permission – they just do it. Typically it uses tunneling or some kind of VPN to phone home and works well. Other examples I’ve seen are SmartGrid and Autonomous/Connected Vehicles initiatives. Again, you won’t deploy IPv6 everywhere but rather you’ll have islands that support business justified needs. I think the key with IPv6 is to treat it like a new technology. When Hadoop came out you didn’t scrap all your old DBs, you just use it where it makes sense. IPv6 can be treated similarly.

    • Let’s be clear, you can’t ignore IPv6. You did take control of the IPv6 in your network, right ?:

      Otherwise you probably have IPv6 deployed and you don’t know it yet.

      I don’t right now see a reason to for an enterprise user needing to connect to an IPv6-only host.

      And you can always relay things like web traffic through proxy servers and WebRTC can fallback to using TURN servers.

      My bigger worry right now is that enterprises don’t deploy SNI capable HTTPS software (browsers or proxies).

      We are more and more moving to a HTTPS-only web, if every website needs it’s own IPv4 address that would be a problem.


Most people know me because I write & podcast about IT on the Packet Pushers network. I also co-authored "Computer Networks Problems & Solutions" with Russ White.

Find out more on my about page.

Subscribe via Email

Receive complete, ad-free posts in your inbox as I publish them here.