Archive for August, 2013

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.

  1. boot to the head to anyone who insists on any transition technology for our internal networks, without a very convincing argument
  2. dual stack the (internal, client) networks + provide “outbound” external dual-stack paths to the public Internet
  3. dual-stack DNS and DHCP and any thing else I need to manage and operate the clients, such as Active Directory
  4. 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)
  5. 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
  6. 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
  7. 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
  8. Finally, after years, you can look into turning off IPv4. Start by pouring petrol into the pit of doom and lighting it on fire.
  9. 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.

Don’t be afraid to move forward, it’s easier than you think.

1 Comment

IPv6 transition – just get on with it!

A recent DEFCON presentation highlights the need to accelerate adoption of IPv6 on your network. You can either turn off IPv6 on all your hosts (which will break things), or get on with it and deploy IPv6 “for real”.

(TL;DR: your hosts already have dual-stack activated, not having IPv6 supported in your network opens up a  man-in-the-middle (MITM) attack. Though long known, there is now a “one click” exploit available.)

There’s been a lot of discussion on various IPv6-related mailing lists with how to drive the transition, how to transition, and which (if any) of the transition technologies should be used.

In general, NONE of the transition technologies (other than dual-stack) address this particular MITM attack. They (for the most part) leave old IPv4 nodes as-is on your network, and try to translate protocols and hide IPv6 from those old nodes (and vice versa).

Personally, I find it quite heartening that many are making good business cases for aggressive adoption of native IPv6. Some are also providing good historical evidence that we’ve made similar transitions in the past, without extensive transition technologies, with good success:

On 8/8/13 1:40 PM, Ray Hunter wrote (v6ops):
Actually I think your reasoning and reference to the IPX and Appletalk
phase out would suggest it’s easier to make a bold call: move to IPv6
ASAP for critical systems via dual stack, and for the rest you draw a
box around it and call it legacy and run it on IPv4 until it dies a natural death.

IMHO Going half way with NAT64/DNS64 just prolongs the pain and locks
you into a transition technology that is expensive and difficult to
operate for the life cycle of that box, and which has to remain in place
until the last app is migrated or switched off.

I’ve been in a fair number projects where you sometimes just have to
dare to cut the cord whilst maintaining a process to find out what has
broken. So one valid IPv6 only migration strategy might be: “If it’s
important, they’ll migrate before a flag day date. Otherwise they get
cut off.”

I cannot agree enough with the “prolongs the pain”  and “locks you into a transition technology “observations.

At work, we’re going on the assumption that we’ll be able to go dual-stack and not need any translation. So far, that looks viable for our internal networks. When we get to the consumer-facing stuff, well, we’ll see.

Leave a comment

Stupid email disclaimers – they just won’t die

Every day I get email messages with really stupid disclaimers at the bottom. Some of the worst are from vendors that are sending me information or invites to events.

Stupid email disclaimers seem to have come into vogue in or about 2001 or so.  Many people, myself included, thought that this would be just a passing fad, and folks would realize how stupid these make you and your organization appear to rational people.

Hah. Nope.  Obviously too much faith in humanity going on here.

The folks at did a collection of these, and why they are stupid, back in 2001.  The Register, Slashdot and Slate also took pokes at the topic. Sadly, it appears that rational thought has given up and just decided to accept the status quo.

Disclaimers should have died a decade ago.

Starting this week, I’m going to post some of these disclaimers. The stupid, it burns. I’m torn on whether or not to release the company names with the disclaimers. Vote it he comments, if you dare.

Confidentiality Note: This e-mail, and any attachment to it, contains privileged and confidential information intended only for the use of the individual(s) or entity named on the e-mail. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that reading it is strictly prohibited (emphasis added). If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.

So, I’m prohibited from reading the email, to get to the bottom disclaimer to find out that I’m prohibited from reading the email?

Yup, you’re a vendor I’m adding to the blacklist, for excessive stupid. If every email your company sends looks like this, I wonder what your service contracts look like? Do you even have competent lawyers?

Leave a comment

%d bloggers like this: