As a consultant or VAR, it may be tempting to push customers toward IPv6 because of all the labor, hardware and software sales it would mean. But like any project you're trying to sell, walking customers through a business case is much more conducive to a long-term relationship. Unfortunately, doing so for an IPv6 migration is difficult at best since the only reason to migrate is lack of IPv4 address space -- a problem unlikely to be experienced by your North American customers. If your customer is the exception to the rule, then the following are some things to consider -- many of which will impact your cost justification efforts.
First, your customer needs to understand the big picture, which is that IPv6 is a different protocol and that applications are written to protocols. Theoretically, the move from IPv4 to v6 is like moving from IPv4 to IPX or DECNet. That's because network-aware applications are written to a protocol. For instance, moving from SNA to IPv4 on the mainframe or from DECNet to IPv4 on a VAX/VMS is not as simple as binding the protocol to the network adapter. You have to change your applications. This means buying upgrades to packaged apps and re-writing homegrown apps. The hearty souls who ran ATM to the desktop in the late 1990s will understand this well.
IPv6 was built with some backward compatibility to make the transition less painful, but again, your customers need to understand that their apps are using backward compatibility features. They won't be making native IPv6 calls or taking advantage of native IPv6 features until the apps are upgraded. Of course by now, many applications already support IPv6, but even then, you want to test, test, test, because many early IPv6 implementations are chock-full of bugs.
The next thing you and your customer need to agree on is a strategy for the migration, as parts of the network will convert before others. Your three basic options are to use tunneling, translation or running both protocols in parallel, which is sometimes called a "dual-stack." The advantages and considerations of these methods are beyond the scope of this article, and will take some time and research to understand.
Another task is to look to strategic changes in some applications. Some of the major drivers for version 6 revolve around improved QoS mechanisms and improved multicast. This will affect the way you solution Voice over IP, video and other services.
You will also need to look at IP services, like DHCP and DNS. These obviously will need to change to support the new protocol, but also hang around to support IPv4 during the migration. These services may be tightly coupled with enterprise directories like Active Directory and IP address management systems like Lucent's QIP, and other applications. Network management apps using protocols like SNMP may also change.
Finally, you need to get an allocation of registered IPv6 addresses. To do that, you need to honestly assess the customer's space needs, based on current and future plans.
About the author
Tom Lancaster, CCIE# 8829 CNX# 1105, is a consultant with 15 years of experience in the networking industry. He is co-author of several books on networking, most recently,CCSP: Secure PIX and Secure VPN Study Guide, published by Sybex.
