IPv6 at the 2008 Olympics

In my previous post I threw out a few thoughts about the idea of enticing users to switch to IPv6 – a sort of variation on the long-running “we need an IPv6 killer app” argument – and the contradictions such enticement efforts would present: Mainly that IP of any version should be transparent to end-users who only care about services, not how those services are delivered. Any enticements bring IPv6 into the spotlight, where it should not be (except for routing and infrastructure geeks like me).

Looking at the other side of this transparency issue, just getting IPv6 rolled out brings unwanted attention to it: Users might have to upgrade operating systems, and might encounter problems reaching some destinations and services as the public Internet becomes split between an IPv4 world and an IPv6 world.

It’s the job of those of us involved in implementing IPv6 – integrating it into routine network operations – to try to prevent IPv6 from calling attention to itself. Services must continue merrily along, with users blissfully unaware of whether those services are arriving over IPv4 or IPv6.

It will require some hair-pulling and sleepless nights on our part to make that happen.

The ultimate success or failure of IPv6 implementation is dependent on the practical experience we can attain in these early stages of deployment. One of the approaches I’ve been advocating for some time now is a phased implementation in which interaction and interoperability between IPv6 and IPv4 is delayed as long as possible, preferably to near the end of the project, or an implementation in a closed system which can be IPv6 only. That gives architects, engineers, and operators the time they need to gain experience with the protocol and work with vendors to close gaps in their implementations before having to face that most troublesome interoperability challenge.

An example I’ve held up for years is Comcast’s migration to IPv6. They are rolling it out in the core of their MSO network, then to their regional access networks, then to their CMTS. Only then does IPv6 begin to extend to the customer premise, and even then it is initially just to operate set-top boxes. All through the process Comcast personnel are gaining experience with the protocol, in a closed environment where IPv6 never touches the public Internet. It is after this well-controlled rollout is finished that Comcast plans to begin tackling the hard problem of transparently providing public Internet services over IPv6.

Another oft-cited example of this kind of approach is mobile providers. They could continue offering public Internet access from their handsets via IPv4, while beginning to deliver VoIP services over IPv6: Once again a closed, controlled environment in which to acquire IPv6 experience before phasing in interaction with IPv4.

Which brings me to another couple of good examples of this kind of approach – both in China, where the combination of population size and booming economy (read: more people with more money, wanting more online services) makes IPv6 deployment urgent.

Beijing Internet Institute (BII), one of China’s premier IPv6 research and development firms, has been leading a couple of IPv6 projects for the 2008 Olympics. One is the surveillance system – the security cameras and such – to be used throughout the Olympic venues. These will all run over IPv6. The other project, developed in partnership with China Netcom and Panasonic, is an IPv6-based intelligent lighting control system.

Liu Dong, BII’s CEO, tells me that the experience gained from projects such as these will expand to larger projects such as IPv6-enabled energy control systems that can help reduce energy use in buildings throughout China.

Again, these are closed systems that provide the opportunity to gain strong experience in IPv6 deployment and operations before tackling the issues of IPv4/IPv6 interoperability.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2008 IDG Communications, Inc.