The Inevitability of IPv6, Part 2

As I maintained in “The Inevitability of IPv6, Part 1” (InstantDoc ID 96880), even if you have no immediate plans to migrate to IPv6 in your enterprise, you need to be ready for it, and you need to understand how Windows uses it. Some current and forthcoming Microsoft products and updates to existing products do or will ship with IPv6 enabled and running out of the box. If you communicate regularly with business partners over the Internet, you might be forced to tackle IPv6 because many companies are already beginning to make the transition. Increasingly, governments—including the US Government— are mandating its use.

In Part 1, I described how Microsoft is supporting IPv6 in its product line, and I provided an overview of how IPv6 addressing works. Be sure you’re well-versed in that article’s foundational information before taking the plunge into this month’s discussion, which is Part 2 of a three-part series. Now, without further ado, let’s investigate how to install and configure IPv6 in your Windows network and how to use IPv6 to communicate— even if your routing infrastructure doesn’t yet support it.

Installing IPv6 on Windows 2003 and XP
As I explained in Part 1, Windows Vista comes with IPv6 installed and running, as will Windows Server 2008 when it ships. However, if you’re running Windows Server 2003 and Windows XP, you’ll need to manually install and configure IPv6. Let’s get to it!

To install the IPv6 protocol on the earlier OSs, select the adapter on which you want to use IPv6, open its Properties dialog box, and click Install to open the Select Network Component Type dialog box. You can install Client, Server, and Protocol components. Select Protocol and click Add to open the Select Network Protocol dialog box, select Microsoft TCP/IP version 6 from the options, and click OK. Figure 1, page 56, shows the dialog boxes on a Windows 2003 system. You don’t need to visit each machine to install IPv6. You can simply run the Netsh Interface IPv6 Install command from a startup script or within a package that you can distribute to each system—perhaps via Microsoft Systems Management Server (SMS) or Group Policy.

Once you’ve installed IPv6, you’ll notice that—unlike IPv4—you can’t configure the protocol’s properties from the network connection’s Properties dialog box. With IPv4, you would configure an interface with a static IP address or configure it to use DHCP to get an address from a DHCP server. With IPv6, that’s not the case. As I described in Part 1, an IPv6 unicast link-local address can be derived from the NIC’s 48-bit MAC address. Windows 2003 and XP automatically use this process to assign a link-local IPv6 address to an interface. This address, which begins with FE80::/64, can be used to communicate with every other host running IPv6 on the same link but can’t be used to communicate with hosts through a router. IPv6 routers never route traffic with unicast link-local addresses.

A word of caution here: If you use Microsoft Virtual Server or another virtualization suite to host virtual machines (VMs), you need to make sure that each VM has a unique MAC address for each virtual NIC. If you don’t, each node running IPv6 will have the same IPv6 address—and that will cause you problems.

You can determine a node’s unicast linklocal address by running Ipconfig from the command line. Figure 2 shows the Ipconfig output on a Windows 2003 system. You’ll see three unicast link-local addresses; ignore the addresses for the Automatic Tunneling and Teredo adapters. (I’ll cover these later.) The %n component (where n is a number) at the end of each IPv6 address refers to the NIC or adapter to which the address is assigned. Windows uses numbers to identify both physical and virtual network interfaces or adapters. The adapter number is important for reasons that I will discuss shortly.

If you run Getmac from the command line, you’ll see how the MAC address for each NIC has been used to build the IPv6 unicast link-local address. You can verify that IPv6 is working on a node by using the Ping command to test the IPv6 loopback address, which is ::1. You can use Ping to verify communication with other IPv6 nodes if you know their IPv6 unicast link-local addresses. However, there’s a trick to successfully using Ping. When you specify the IPv6 address of the node for which you want to test connectivity, you must append your node’s adapter number. For example, in Figure 2, the unicast link-local address of the Local Area Network adapter has the suffix %5, meaning that the address is bound to adapter number 5. To ping the node with the unicast link-local address fe80::203:ffff:feab:3045, you would type in the command

ping fe80::203:feab:3045%5

As quick and easy as it is to get IPv6 up and running with unicast linklocal addresses, an enterprise still has to take several steps to build a useful IPv6 network. Unicast link-local addresses won’t work in routed networks and can’t be used over the Internet. Routable addresses need to be assigned to hosts, routers need to be configured, and DNS needs to be configured to enable mapping of FQDNs to IPv6 addresses.

Configuring Windows with Routable IPv6 Addresses
Configuring Windows with routable IPv6 addresses can be easy or difficult, depending on your enterprise’s circumstances. Typically, you configure a host to obtain an IPv4 address from a DHCP server, or set a static address. As I mentioned earlier, there’s no means to configure IPv6 from a network connection’s Properties dialog box in Windows 2003 or XP. (Vista and the forthcoming Server 2008 do let you set the IPv6 address in this fashion.) Additionally, there’s currently limited support for using DHCP with IPv6. There’s no supported IPv6-capable DHCP server available for Windows 2003 from Microsoft, and you’ll have to wait for Server 2008 for an IPv6-capable DHCP server.

As I discussed in Part 1, a routable IPv6 address can be a unicast site-local or globally aggregatable address. A site-local address is similar to private IPv4 addresses that fall in the range 10.0.0.0 to 10.255.255.255, 172.16.0.0 to 172.31.255.255, and 192.168.0.0 to 192.168.255.255, and begin with FEC0::/48. Each site-local address has a 16-bit subnetwork identifier, followed by a 64-bit interface identifier. A site can have as many as 65,535 subnetworks. The interface identifier is derived from the NIC’s MAC address, just like a link-local address. Like the IPv4 equivalent, site-local addresses can’t be used to communicate over the Internet; thus, site-local addresses are useful if you want to use IPv6 internally. Without an IPv6-capabale DHCP server, configuring a site-local address for a node is accomplished either as a manual, per-machine process using Netsh or, more usually, through address autoconfiguration.

Auto-configuration is a means by which nodes can determine both site-local and globally aggregatable addresses from IPv6 routers on the same link—that is, routers that can be pinged using their link-local address from a node. When a node starts or when the network interface is reset (e.g., a previously disconnected laptop connects to a corporate network), the node will send out a router-solicitation message on each network interface—in essence, a request for routers on the same link to make themselves known. Properly configured IPv6 routers will respond with a router advertisement address, consisting of a site-local prefix address in the form of fec0:0000:0000:subnetid::/64. The node will configure each interface on which it receives a router advertisement in response to a routersolicitation message with an IPv6 address consisting of the site-local prefix received from the router and the 48-bit MAC address of the interface the solicitation was sent over and the advertisement received.

Figure 3 shows the output of the Ipconfig command on Vista, clearly identifying the sitelocal address assigned to the Local Area Connection adapter. Neither Windows 2003 nor XP differentiates between link-local and site-local addresses and instead just displays them as IP Address. Windows will configure the IPv6 router to be the default gateway for IPv6 traffic. Assuming your routers have accurate routing IPv6 tables, you don’t need to configure your Windows nodes further.

To verify that you can connect with IPv6 nodes not on the local link, you can use Ping and specify site-local addresses instead of linklocal addresses. You don’t need to append the IPv6 address of the destination node with the adapter number of an interface when using site-local addresses, because each address should be unique across all your subnets— assuming your routers are configured correctly with subnetwork identifiers.

Connectivity with ISATAP
If your network doesn’t have IPv6-capable routers, it’s still possible to use IPv6 in your enterprise to facilitate communication between nodes on different links, by using a technology called Intra-Site Automatic Tunnel Addressing Protocol (ISATAP), which is configured automatically for you. You can use ISATAP only on nodes running both IPv4 and IPv6. If you look back at Figure 2, you’ll see the entry for the Automatic Tunneling adapter. This is the ISATAP- configured IPv6 address. (You can identify it in Vista by running the command Ipconfig /all and looking for a tunnel adapter whose description begins with the name isatap.)

Every Windows OS with IPv6 enabled and an IPv4 address will automatically create an ISATAP address. ISATAP addresses take the form ::5EFE:w.x.y.z, where w.x.y.z is the host’s IPv4 address. ISATAP addresses can have any prefix, including a link-local address, site-local address, or a globally aggregatable address, although a prefix that is a site-local or globally aggregatable address implies that IPv6 routing is possible, and ISATAP isn’t necessary. For this reason, ISATAP addresses on Windows use the link-local prefix fe80::.

One IPv6 node can reach another by using its ISATAP address, even if it’s on a different link and there’s no IPv6-capable router connecting the links. ISATAP is a great transition technology, letting you use IPv6 on IPv4 networks when there’s no support at the router or gateway level. In Part 3 of this series, I’ll further discuss ISATAP and show you how to use it to communicate over the Internet.

DNS and IPv6
With site-local IPv6 addresses allocated to your nodes, each can use IPv6 instead of IPv4 to communicate with the other. Member servers running Windows 2003 R2 and XP and Vista clients will register their site-local IPv6 addresses in DNS, if possible. IPv6 addresses are stored as AAAA records. (IPv4 addresses are stored as A records.) DCs, even if they’re IPv6 nodes, don’t register AAAA records for themselves in DNS. You can always use the DNS Microsoft Management Console (MMC) snap-in to manually add AAAA records for IPv6 nodes, including non-Windows hosts. Note that if you replicate your DNS zones containing AAAA records to non-Windows 2003 servers, you might encounter difficulties because not all DNS servers support AAAA records.

You can use the Ping command to test lookups of IPv6 addresses for FQDNs; simply specify the FQDN of the target host on the command line. The address retrieved and subsequently used in the ICMP echo request should be an IPv6 address. You can also use the command-line tool Nslookup to query DNS for AAAA records by simply typing set type=AAAA into Nslookup before typing the name of the server for which you’re querying. Figure 4 shows the use of Nslookup to query for a Web server’s IPv4 address (the default), followed by a request for the IPv6 address.

Although an IPv6 address might be available for a host in DNS, there’s no guarantee that the network services running on it will support IPv6. For this reason, I don’t recommend that you create AAAA records for your Windows 2003–based DCs; many of the services that run on a DC don’t yet support IPv6. Figure 4: Using Nslookup to query a host’s IPv4/IPv6 addresses

In the Thick of It
So, now you know how to install IPv6 on your DCs, member servers, and clients running Windows 2003 R2 and XP SP2. You also know how to test link-local connectivity between IPv6 nodes, and how nodes use auto-configuration in communication with IPv6-capable routers to automatically assign site-local IPv6 addresses.

In Part 3, I’ll describe how to configure globally aggregatable addresses so that your nodes can communicate over the Internet with other IPv6 nodes, as well as a means to facilitate interoperability with IPv4 nodes and to run IPv6 over IPv4 when your ISP doesn’t support IPv6. Stay tuned!

End of Article