When considering all these advantages, maybe the question should be: "Why not IPv6?" When talking to customers, we often find that they share a similar set of misconceptions preventing them from considering IPv6. Here are the most common ones:"The introduction of IPv6 puts our current IP infrastructureour networks and servicesat risk."

This concern is unsubstantiated. A major focus in IPv6's development was to create integration mechanisms that allow both protocols to coexist peacefully. You can use IPv6 both in tandem with and independently of IPv4. It is possible to introduce IPv6 and use it for access to new services while retaining IPv4 to access legacy services. This not only ensures undisrupted access to IPv4 services, but it also allows a step-by-step introduction of IPv6.

"The IPv6 protocol is immature and hasn't proven that it stands the test of time or whether it is capable of handling the requirements."

This is only partially true. IPv6 has been implemented in most router and operating systems for almost a decade, and has been tested and optimized extensively. There are substantial international research efforts and test networks for deployment that are further optimizing integration methods. One of the largest tests currently running is Moonv6 (http://www.moonv6.com). Moonv6 is a test network where the U.S. Department of Defense (DoD), IPv6 developers and vendors, and various academic and industry bodies conduct extensive interoperability and conformance testing of the IPv6 base features, as well as extended features such as quality of service, mobility, and security.

"The costs of introducing IPv6 are too high."

There will certainly be costs associated with adopting IPv6. In many cases, newer networks will find that the level of IPv6 support in their current infrastructure is actually high. Regardless, the transition will necessitate some hardware and software costs. Organizations will need to train their IT staff, and, depending on the speed at which integration must occur, they may need to seek outside expertise.

However, the cost savings associated with IPv6 are becoming easier to define. Networks based on IPv4 are becoming increasingly more complex. New IT services such as VoIP, instant messaging, video teleconferencing, IPTV, and unified communications are adding layers of middleware and complexity. Merging organizations or those conducting B2B transactions are implementing NAT overlap solutions that have high management costs and are difficult to troubleshoot. And a growing market of mobile devices and network appliances requires robust access models that are expensive and difficult to implement in an IPv4 world. In all of these cases, IPv6 presents a cleaner and more cost-effective model in the long run than IPv4 can provide.

"With Stateless autoconfiguration, we will not be able to control or monitor network access."

While this statement may generally be true for networks that widely utilize Stateless autoconfiguration, administrators will have a choice about their level of control. DHCPv6 as defined in RFC 3315 has been extended to support two general modes of operation, Stateful and Stateless. Stateful mode is what those who currently utilize DHCP (for IPv4) are familiar with, in which a node (DHCP client) requests an IP address and configuration options dynamically from a DHCP server. DHCPv6 also offers a Stateless mode in which DHCPv6 clients simply request configuration options from a DHCPv6 server and use other means, such as Stateless autoconfiguration, to obtain an IPv6 address. On the other hand, you can configure IPv6 networks to force the use of DHCPv6 for dynamic address assignment and configure DHCPv6 to enhance security, since authentication is available as part of the protocol.

"Our Internet Service Provider (ISP) does not offer IPv6 services, so we can't use it."

You do not have to wait for your ISP to use IPv6 in your corporate or private network. If you want to connect to the global IPv6 Internet, you can use one of the transition mechanisms and tunnel your IPv6 packets over the IPv4 infrastructure of your ISP.

"It would be too expensive and complex to upgrade our backbone."

The transition mechanisms make it possible to use IPv6 where appropriate without dictating an order of upgrade. Usually for the backbone it is advisable to wait for the regular life cycle, when hardware needs to be exchanged anyway. Make sure to choose hardware that supports performance IPv6 routing. In the meantime, you can tunnel your IPv6 packets over the IPv4 backbone. Networks that use MPLS have an easy way to tunnel IPv6 packets over their IPv4 MPLS backbone.

"It would be too complex and expensive to port all of our applications to IPv6."

The effort necessary to port applications to run over IPv6 is often much lower than expected. If an application is well-written, it may simply run over IPv6 without modification. Instead of assuming that it won't work, test it to find out. For applications that need modifications that are not yet available, or for applications in which porting does not make sense, there are mechanisms available that support IPv4 applications in IPv6 networks and IPv6 applications in IPv4 networks. Alternatively, you can run a dual-stack network, in which you use IPv4 to access IPv4 applications and IPv6 to access IPv6 applications.

"We have enough IPv4 addresses; we don't need IPv6."

Trueif you have enough IPv4 addresses, there may be no immediate need to integrate IPv6 today. But ignoring IPv6 for this reason is a perspective that assumes that your network stands completely isolated from the rest of the world, including your vendors, partners, and customers. IPv6 adoption is further along in Asia than in the United States, so even though you may have adequate address space for your operations in Denver, interconnecting with a partner organization in Tokyo may eventually become complicated if you do not support IPv6. Plus, the assumption that IPv6 is about address space only doesn't account for the advanced features that IPv6 brings to the table