I am starting to look at Internet Protocol version 6 (IPv6) for selected live systems. While I do not have a particular need or requirement for using the updated version of the lifeblood of my network, I want to start formulating plans and scenarios so that there are no surprises when the time comes to implement IPv6 across the board. The feature list of IPv6 is compelling with IPSec, 128-bit address space, built-in efficiency, and the removal of subnet masks, making perfect sense when engineering is a protocol.

All that is fine and good; it is just that the change is going to be a real pain. One of the bigger inhibitors in migrating to IPv6 is that it does not have native backward compatibility. This alone effectively mandates dual-stack nodes. In fact, Windows Server 2008 default installations load both IPv4 and IPv6 protocol stacks. There is no guarantee for applications to work correctly with IPv6. This will be an issue, and identification of the applications that will not function correctly in the IPv6 address space will be an involved discovery process.I feel that the dual-protocol world will exist for a while once IPv6 becomes frequently used, possibly with IPv4 address spaces used exclusively in internal networks, a cross-version of NAT if you will. This, however, is only a stopgap solution. DNS will be playing a key part of the coexistence of both IPv4 and IPv6. One example is that Windows Server 2008’s DNS server supports both versions of TCP/IP within DNS on the same server instance. Take the standard host (A) record, in IPv6 it is now the AAAA record. The figure below shows the creation of the AAAA record in the DNS console in Windows Server 2008:

Only once a basic framework for IPv6 is in place and then put to use will we be able to identify what kind of growing pains are going to be upon us. How are you testing and preparing for IPv6 in your environment? Share your comments below.