With the official exhaustion of IPv4 open-pool addresses in February, the long migration path to IPv6 has passed another important milestone. Since the IANA IPv6 worldwide deployment announcement in 1999, the issue has never been whether, but simply when IPv6 would become the core protocol for global Internet traffic.

Quiz: How prepared are you for IPv6?

The low percentage of actual IPv6 deployments, to date less than 10% worldwide, lags behind early estimates that predicted full adoption of IPv6 as the dominant Internet protocol by the end of 2007. Factors in delayed deployments include unfamiliarity with the protocol, cost and security concerns, a lack of trained personnel, and a shortage of carrier-grade IPv6 bandwidth providers.

The reality is that even in optimistic scenarios, IPv6 is not likely to become the dominant protocol in the immediate future. With finite IT resources, data center managers may be reluctant to push seemingly optional IPv6 initiatives to management as a ‘hair on fire’ priority. But a decision to wait could mean higher costs and more deployment headaches later. (IPv6 deployment misperception: Enterprises aren’t deploying IPv6.)

As with most emerging technologies that are destined for widespread adoption, at some point critical mass will be reached and by tacit universal agreement the move to IPv6 will accelerate geometrically, leaving organizations who have bet wrong on the timing scrambling to catch up. The takeaway is that even companies with no immediate plans to deploy IPv6 should have a full grasp of the technology, its operational impacts, and at the very least, a viable, well-designed transition plan.

Here are six steps to take now to get ready for IPv6:

1. Request an IPv6 prefix from your upstream provider or RIR

Start by requesting an IPv6 PA (Provider-Assigned) prefix from your bandwidth provider. Even if you don’t plan to immediately deploy IPv6 on public-facing hosts, it’s important to know if your ISP can deliver IPv6 connectivity. PA prefixes are typically provided at no charge. If a PA prefix is not available, ask for timelines. If the answers are unsatisfactory (e.g. your provider has no plans for IPv6 migration or cannot specify a delivery schedule), you may want to consider beginning the search for an IPv6-capable host.

Qualified organizations may also purchase a PI (Provider-Independent) prefix, which is usually assigned by a RIR (Regional Internet Registry). PI addresses are not host-specific and will allow you to change hosts, but a PI address by itself does not eliminate the need for an IPv6-capable host.

2. Conduct a simple IPv6 ‘Hello World’ test

Even if your current bandwidth provider doesn’t provide IPv6 service, you can still begin testing on your internal LAN or WAN. IPv4 and IPv6 protocols, while not directly interoperable, can co-exist in a dual-stack, parallel configuration and are already doing so in some form on most networks. This provides an excellent environment for testing.

The following dual-stack ‘Hello World” example uses just two machines (one Windows 2008 IIS/DNSserver and one Windows 7 client) and is fast and easy to configure.

On a Windows 2008 Server running IIS and DNS:

IPv4 Node

1. Set up a new website in IIS. Bind the site to any unallocated local IPv4 address. If you need an extra IPv4 address, assign an unused address from your subnet to the local interface prior to configuring the website. (DNS is not required for the first two sets of connectivity tests).

2. Save the following text in a file in the home directory of the new website named ‘index.html’:

Hello World

3. Confirm that you can view the page in the server’s browser using the IPv4 address assigned (ex: http://192.168.0.1).

IPv6Node

4. Add a new, static IPv6 address to the LAN interface (for test purposes only, you can get a randomly-generated local IPv6 address at sites like https://www.ultratools.com/tools/rangeGenerator). Note that the prefix of a Unique Local Address (ULA) begins with fd. Use a subnet prefix length of 64 as shown in Figure 1. Use the server’s IPv6 address for the Preferred DNS server. (The server’s IPv6 address may be obtained by issuing an ipconfig command at a command prompt.)

5. Open a browser window on the server and type the IPv6 address into the location bar, using the static IPV6 address you just added to the interface with following (bracketed) syntax:

http://%5Bfd63:ae70:9a8d:9ef7::]/

You should now see the same ‘Hello World’ screen you saw in Step 2.

6. Configure IPv6 connectivity on the Windows 7 client machine. This can be done by opening the IPv6 configuration dialog (similar to figure 1 above) and entering either a random IPv6 address or the IPv6 address of the Windows 7 machine, which you can obtain by running IPConfig in the command window. For the default gateway, enter the IPv6 address assigned to the server in step 4. You should now be able to open a browser and access the ‘Hello World’ page exactly as in step 5.

Configuring DNS

To enable the test for ‘dual-stack’ domain name resolution using IPv4, under DNS you would add a Forward Lookup Zone as usual with an A record mapped to the ‘Hello World’ website IPv4 address. To enable IPv6 for the same example, add a quad-A (AAAA) record as shown in Figure 2.

3. Analyze protocol differences and perform an impact analysis.

The differences between IPv4 and IPv6 are significant (see Table 1 – IPv4/IPv6 Side-by-Side Comparison).

The impact of the migration to IPv6 tends to increase with the size of the organization, thus larger enterprises need more lead time for planning deployments. Consider assembling a task force to assess impacts and make recommendations.

4. Prioritize the order of IPv6 deployments.

A direct switch from IPv4 to native IPv6 is the exception and not the rule, because of the relatively small number of native IPv6 hosts and upstream providers. In order to provide maximum availability of network resources (both internal and Internet-facing), many organizations choose a transition strategy that employs dual-stack nodes together with tunneling protocols or other translation mechanisms between IPv4 and IPv6 nodes where dual-stack is not feasible.

Here’s an example of a rollout strategy designed to lessen the impact of the transition to IPv6. Naturally, organizations will need to consider multiple factors when devising their own deployment plans.

• Phase I – deploy Internet-facing services (web and e-mail) with dual-stack nodes and tunneling/translation mechanisms for bridging IPv4/IPv6 ‘islands’

• Phase II – migrate LAN/WAN from stateless (automatic) to stateful (configured) IPv6

• Phase III – identify and upgrade non-IPv6 equipment/applications

Phase I — deploy Internet-facing services (web and e-mail) with dual-stack architecture. As shown in the ‘Hello World’ example above, dual-stack involves running parallel IPv4 and IPv6 nodes. This is typically achieved by adding a configured, routable IPv6 address and allowing requesting devices to choose automatically whether to route requests to IPv4 or IPv6. It should be noted that this approach, while simplifying the addition of IPv6 nodes, does not reduce the dependence on unique IPv4 addresses and should be replaced by IPv6-only services as soon as feasible. It is also important to note that Internet-facing dual-stack nodes may introduce perceived performance issues for Internet users due to IPv6 timeouts when there is a lack of available upstream IPv6 routes.

Where indicated, tunneling or other translation methods can be used to deliver traffic between IPv4-only and IPv6-only hosts. Some tunneling methods may pose security risks, so it is important to understand how each one operates and when to allow/disallow traffic from tunneled sources.

Scariest IPv6 attack scenarios

Implementing e-mail in dual-stack mode may require configuration changes on the SMTP server, such as adding a port to listen on an IPv6 address, and providing an IPv6 Internet range. DNS quad-A records are also required, together with MX records that resolve to an IPv6-capable host. As with other tests, it is advisable to use a non-production machine.

Phase II – migrate LAN/WAN from stateless to stateful IPv6. Most current operating systems ship with support for stateless (autoconfiguration) IPv6:

• Linux (kernel 2.2 and higher)

• Mac OS X

• FreeBSD/NetBSD/OpenBSD

• Windows Server 2000/2003/ 2008; Windows XP/7

In autoconfiguration or stateless mode, IPv6 link-local addresses are assigned to devices automatically without the need for server management. This means that the moment the OS is switched on, the device automatically has a discoverable IPv6 address. Stateful (configured) mode uses Dynamic Host Configuration Protocol for IPv6 (DHCPv6) for the installation and administration network nodes. Previous OS versions may have limited IPv6 stateful capabilities. For example, Windows Server 2003 requires DHCP in order to enable IPv6 stateful services.

Phase III – Identify and upgrade non-IPv6 equipment and applications. This step is necessary before you can switch wholesale to native IPv6 across the board. If you operate a large network, it may be necessary to utilize a third-party application specifically designed to identify IPv6 connectivity limitations, such as IPv4 dependence.

5. Create an addressing plan

Addressing space has increased exponentially in IPv6 with more than a billion possible addresses for every human being on the planet. The vast number of unique addresses eliminates subnetting conflicts and allows organizations to freely formulate flexible addressing schemes according to physical or logical groups within the organization, or to use configured random addresses for increased host privacy.

IPv6 supports the following address types:

• Multicast – sends packets to all interfaces that are part of a multicast group, represented by the IPv6 destination address of the packet; allows for aggregation of routing prefixes to limit the number of global routing table entries

• Anycast – sends packets to a single interface associated with the address, typically routed to the nearest node

• Unicast – identifies a single interface

• Global aggregatable – allows for aggregation of routing prefixes to limit the number of global routing table entries

• Link-Local – allows communications between devices on a local link without requiring a globally unique prefix

• Site-Local – allows communications within an organization without need for a public prefix

• Loopback – used by a node to send an IPv6 packet to itself

• Unspecified – used by new interfaces until the application or device has obtained the host’s source address

6. Understand the risks and develop a security policy

Organizations must make plans to address the impact of IPv6 on network security. For example, tunneling and translation mechanisms that facilitate the routing of traffic between IPv4 and IPv6 hosts can also introduce security risks by carrying IPv6 malware traffic that may evade detection by non-IPv6-aware firewalls. Additionally, the auto-configuration feature of IPv6 can be used to further route malware traffic once inside the network after it has escaped perimeter detection.

On the positive side, support for IPSec is now mandatory in IPv6. Developed by the IETF, IPSec was designed to provide security services such as data confidentiality, integrity and packet origin authentication. IPSec operates at the network layer and when properly configured can be a powerful tool for protecting and authenticating IPv6 traffic. Although support for IPSec is required in IPv6, this by no means implies that security is ‘built-in’ on day one. IPSec must be properly configured in order to provide the protection it was designed to deliver.