By Brian Boyko
Editor, Network Performance Daily

2008. Leap year. Election year. Government deadline for IPv6.

With the exception of the military, federal government agency CIOs are doing the bare minimum required by law to meet the mandate to move to the IPv6 network protocol by June, 2008. That bare minimum, according to this Network World story, is for all the hardware to be IPv6 capable - but does not actually require any IPv6 traffic to go across the network.

Whether or not this delay is a pragmatic consideration or the path of least resistance, most of you are probably having the same reaction regardless of your ideological bent. Liberals can call it typical of the current administration; conservatives can call it typical of government in general. Either way, the reaction that is probably shared by most of us consists of rolled eyes, a resigned sigh, and the word "typical" muttered slightly louder than a whisper under our breath.

For a contemporary example, the HDTV changeover, for example, has been looming "on the horizon" for decades now. At least one person I've talked to in the company has bought what they thought would be the "last SDTV they ever bought" four times since then. I'm still using an NTSC, instead of ATSC (high-def), tuner in my media PC because I don't believe that NTSC broadcasts will cease anytime soon, despite the February 2009 hard shut-off date.

Let's face it. It's hard to get the government to move on something until they have no other choice. This differs from the corporate world in so far as it's impossible to get a company to move on something until you can prove that they have no other choice. Which is one of the reasons government adoption of IPv6 is such an important issue.

Companies are not going to move to IPv6 unless it can be proven that the multiple and numerous drawbacks - reconfiguring an entire network, making sure existing applications (including network management software) are compatible, reconfiguring security, and, oh yeah, that looming $200B infrastructure cost - outweigh the benefits. And of course, backwards compatibility with IPv4 must be maintained until almost everyone is on IPv6.

Additionally, because of NAT and similar technologies (which have some beneficial side effects), the problem can often seem like it can be perpetually postponed. NAT solutions, of course, break P2P apps, impact network robustness by having an additional potential point of failure, and add complexity to the design and deployment of networks. Trying to solve IPv4 address exhaustion with more NAT is like trying to solve global warming with more air conditioning.

And the benefit is that you'll be able to add new devices to the network, and that configuration will be more in-line with the "end-to-end principle." There are some advantages, such as auto-configuration and mobility, some built-in QoS configuration, some new ways to deal with end-user computer security and better routing scalability, but many of these problems have existing solutions in IPv4. Those solutions may be more complex, harder to maintain, and may be less optimal for your network performance, but they exist. So, in short, IPv6's main selling point is that you'll be able to do the same things as you currently do on your IPv4 network.

If that's the carrot, what's the stick? Without it, you'll be less able to communicate with all the other networks that exclusively use IPv6. This does include China, which has already made the switchover, but does not, as stated earlier, include the U.S. government.

You can see why this can be a tough sell. Tons of work for IT, at a time when everyone's got some major project like a VoIP rollout whose benefits are a bit less ephemeral and a bit more quantifiable - all because we're running out of IP addresses.

We've faced problems like this before. But the prospect of running out of IP addresses isn't as sexy or scary as some of the nightmare scenarios that were associated with the Y2K problem. People were stockpiling cans of beans in basements waiting for the Russian nukes to fly and robots to revolt and for anything more sophisticated than the steam-powered abacus to stop working or something like that.

In response to the unadulterated panic associated with Y2K, the U.S. government passed the "Year 2000 Information and Readiness Disclosure Act," which worked with private companies to solve the problem. So what will it take to get governments and corporations to move in a timely manner? Apparently, threat of nuclear Armageddon and a ticking digital clock.

So, until we convince the writers of "24" that Jack Bauer's next adventure should deal with terrorists threatening to blow up unallocated IP addresses, the best plan to move to IPv6 is to get the government to move to IPv6, which will get the government contractors to move to IPv6, which will get everyone else to move to IPv6.

Without IPv6, there is a theory that an impending IPv4 address exhaustion will result in a speculative market on IPv4 addresses. That may very well occur, but such a market would only postpone absolute exhaustion of IPv4, trading of addresses would result in fragmented allocation patterns that would fragment and expand routing tables - older or low-powered routers may not be able to handle the increased load, and, since each change in an IP number requires massive changes to network configurations, there's little market liquidity in it. In short, the development of an IPv4 market might be so disruptive to the operations of the network that IPv6 might be less disruptive.

So, the fact that the government isn't actually moving to IPv6 despite the implied promise that it would, is, therefore, a problem.

Take away from this a simple lesson: sometimes it takes a few bold actors to move forward with broad change even if it seems early to do so. Without those bold actors, the inevitable change may take much longer to reach the tipping point - causing pain and strain for everyone.

What motivates you to changeover to IPv6, or what motivations would you need to change to IPv6? Feel free to leave a comment in our comments section.