IPv6 transition and the pit of doom

In case anyone hasn’t noticed, I’m not a big fan of the IPv6 transition technologies, such as Teredo, 6to4, DNS64, etc. I also don’t like “big bang”, everything today, or “flag day” cutovers either. Fortunately, for IPv6 there’s a good middle ground, dual-stack.

Consumer-facing may be different, but here’s the strategy that I like for transitioning an internal, corporate or .EDU network to IPv6. You don’t have to build anything that you won’t be using for the future, so no spending on technological cul-de-sacs or band-aids. You won’t have to install, maintain, and then eventually turn off any transition mechanisms. Just a steady, always forward, straightforward path that will eventually lead you to 100% IPv6, and eventually allow you to turn off IPv4, if you ever so desire. You won’t have to, you just may not have many people to talk to on IPv4 in a few years.

You can begin this transition today, given time and a steady plan to refresh your technology over the course of a few years. If you have an urgent need for IPv6, you can go faster. If you don’t, or are time or money constrained, you can go slower, taking years to make the switch.

boot to the head to anyone who insists on any transition technology for our internal networks, without a very convincing argument

dual-stack DNS and DHCP and any thing else I need to manage and operate the clients, such as Active Directory

dual stack the clients – if an OS doesn’t do IPv6, chuck it or confine it to the legacy pit of doom, an IPv4-only subnet (or two)

dual stack the servers – do this on your regular refresh/upgrade cycle or as-needed, or if it can’t be upgraded, it goes into the pit

dual stack any remaining services – your software vendors and internal developers have had enough time to sort out dual-stack network calls, or they go into the pit

At this point your network, clients, servers and services are all dual-stacked. The users can reach everything on the public Internet, old or new, as well as all your internal services on both IPv4 and IPv6. And guess what? By this time, you’ll only have two reasons to keep IPv4 around:

Your users might still need to reach old crufty web sites and services out there in the real world

You might still need to talk to some things in the pit of doom

Finally, after years, you can look into turning off IPv4. Start by pouring petrol into the pit of doom and lighting it on fire.

Then start turning off IPv4, first on the the services and servers, then the clients, and eventually the network. Take your time, you’re in no hurry. You can take years, if you like.

We’re doing 1,2 and 3 this year and next. We’ve started on 4 and that will continue for the next year or so. We can start on 5 as soon as we have time. New servers will be born dual-stack starting early next year. A year or three from now we clean up 6, and we’ll be at stage 7.

Then, and only then, do we think about Step 8, turning off IPv4. If that begins by 2017, I’ll be surprised. If Step 9 doesn’t start until 2020, I don’t care.

As long as I’ve got 1 – 4 done, I have a lot less pressure and I can proceed on a rational, non-panic’ed basis to replace servers and services as part of a regular refresh cycle. For many companies, this is 3-4 (or even 5) years.

The consumer-facing case has completely different drivers and requirements, it gets a completely different plan and schedule. But I bet it won’t have any transition technologies in it, if I can help it.

This is rather cold-blooded and (I freely admit) a bit of a pipe dream. But if I can make this work, I’ll never have to justify, pay for, create, debug, support, and then decommission any of the transition technologies. I’ll always have a fall back if there’s a problem with a particular IPv6 implementation or if we run into a show stopper on vendor support for IPv6.

I hate building things that I know I’m only building as a temporary bridge. Spending time (and money) putting in the transition strategies can be better spent just moving forward, not sideways.

IPv6 just isn’t has hard as some might lead you to believe. There are still some implementation glitches here and there, but every day there’s better vendor support and fewer bugs.