IPv6: Migration Issues Loom for Network Administrators


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.


“That’s one of the reasons we don’t have HDTV yet, either, for example.
It’d be a huge investment (for broadcasters and consumers) to have to go
out and buy all new cameras, recording decks, video editing suites, and
receivers,” Batchelder notes.

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.


»


See All Articles by Columnist
Jacqueline Emigh

Latest Articles

Follow Us On Social Media

Explore More