IPv6: Migration Issues Loom for Network Administrators
In the second part of our series on IPv6, we look at where operating system and hardware vendors stand in the migration process and some strategies you can adopt to make the transition easier.
The gradual nature of IPV6 migration might lessen the financial pain, but it will also lead to migration issues for network managers. Fortunately, a number of workaround solutions are already emerging for connecting IPV4 nodes and networks to IPV6 till more IPV6-enabled products hit the streets.
IPV6 is not backward compatible with IPV4, the version of IP still in nearly universal use. End-to-end IPV6 deployment will call for the use of IPV6-enabled network routers, switches, and hubs, as well as operating environments, application software, and network interface cards (NICs).
Overnight migration would be prohibitively expensive for most organizations in the US, even if all of today's products were IPV6-compliant, according to Rob Batchelder, research director, Internet infrastructure, Gartner Group.
Several elements of enterprise networks, though, have started to comply with IPV6 already:
Linux kernel 2.4 includes iptables extensions for IPV6, as well as packages such as ping6, traceroute6, and tracepath6, for example. Sun Solaris 8 and Microsoft's Windows XP also have built-in support for IPV6, as does Sun's Java. Several implementations of BSD include IPV6 through integration with the KAME Project's KAME Kit. These include FreeBSD 4.0 and beyond, NetBSD 1.5 and beyond, Open BSD 2.7 and beyond, and BSD/OS 4.2 and beyond
Just as importantly, network routers are being outfitted with dual protocol stacks for IPV4 and IPV6. This means you can run either IPV4, IPV6, or some combination of the two protocols. Cisco, for example, has supported IPV6 since May of 2001 in its IOS software.
Most enterprises will slide into the new protocol by running IPV6 natively on their backbones, predicts Frank Arundell, director of business development at Stealth Communications, a New York City-based ISP and IPV6/IPV4 exchange point operator.
Many organizations will then use IPV6 over IPV4 tunneling for connectivity between the backbone and IP4 nodes on their own networks, as well as for Internet communications.
IPV6 over IPV4 tunneling has its drawbacks, though. For one thing, tunneling can slow throughput. Moreover, IPV6 over IPV4 tunneling requires network managers to configure information about tunnel endpoints into the encapsulating node, a tedious and time-consuming process. Also, administrators can't reasonably expect end users such as road warriors, dialing in through ISPs, to be able to configure tunnels.
Under some circumstances, other workarounds are also appropriate. On networks where IPV4 multicast is available, experts recommend a solution called "6over4." In this approach, IPV6 multicast is deployed over IPV4 multicast. IPV6 can then utilize neighbor discovery for self-configuration.
Another alternative, "tunnel brokering," can be used even in situations where IPV4 multicast isn't available. This solution uses dedicated servers to configure tunnels on behalf of remote IPV6 clients. The main disadvantage is that a tunnel will persist, unless the client asks for it to be torn down before ending the session. If the tunnel persists, future users of the same IPV4 address might receive IPV6 packets first intended for someone else.
Organizations such as Hurricane Electric and the XS26 Project are currently offering experimental tunnel brokering services free of charge on the Web.
A third solution, "6to4," is meant to let single hosts or small domains on IPV4 networks communicate with IPV6 nodes using a minimum manual configuration. First, you need access to an IPV6/IPV4 gateway router. You also need to give the IPV4 border router an address that is recognizable to the IPV6 domain. To do this, you use the prefix "2002," followed by the 32- bit IPV4 address of the border router.
Commercial NSPs (network service providers) are also helping to set the stage for IPV6, with limited deployments. Global Crossing, for instance, now has five interconnected IPV6-enabled routers. "In the future, we will run dual-stack on all our edge routers. This might occur as early as the end of this year. But it will happen whenever the technology, the market, and the applications are ready," says John Longo, Global Crossing's VP of data services.
New applications will be coming along that will take advantage of IPV4's advantages in areas such as QoS and mobile IP addressing. Existing software applications will also need upgrading, though, to exploit IPV6's new security features, for instance, as well as to communicate with IPV6 hosts.
Meanwhile, though, Global Crossing has rolled out a tool called freeidb to prolong the life of IPV4 till IPV6 is more ubiquitous. Available free of charge at http://www.freeipdb.org , the tool is aimed at auditing existing IPV4 address space and streamlining the allocation process, to help BGP (Border Gateway Protocol) tables manage router information.
As more network components become IPV6-enabled, the need for transitional workaround solutions is expected to fade. Companies will purchase products with dual IPV4/IPV6 connectivity as part of their natural upgrade paths. Given the choice between IPV4 and IPV6, organizations will opt for the new IP protocol, many observers say.
Competition is another factor that should help spur IPV6 product development. Ironically, counties without entrenched IPV4 networks, such as China and Japan, will undoubtedly be better positioned over the short term to derive the benefits of IPV6.