In my previous three IPv6 articles—"The Inevitability of IPv6, Part 1," "The Inevitability of IPv6, Part 2," and "Managing Your Migration and Transition from IPv4 to IPv6"—I introduced you to the fundamentals of IPv6, described various aspects of its use in Windows and non-Windows environments, and discussed migration and transition technologies.
Now, with Windows Server 2008 in the picture, I want to focus on using the new server OS to support IPv6 in your environments, including how to use it in the common migration and transition scenarios. When Microsoft released Server 2008, the company made some changes to how IPv6 is supported to improve security and to ease migration and transition to IPv6. I'll cover those changes, too.
IPv6 changes in Server 2008
To better support IPv6 and improve security, Microsoft made some key changes to common features and to the OS itself. The two most obvious changes are the addition of Dynamic Host Configuration Protocol for IPv6 (DHCPv6), and improved support for IPv6 addresses in DNS, particularly for the registration and display of IPv6 addresses. But two other changes are of significant note.
The first is that Server 2008, by default, won't generate an Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) if no ISATAP router is available. Server 2008 will determine that no ISATAP router is available if the host name ISATAP can't be resolved through standard means, including DNS queries, HOST file lookup, and name broadcast. This security feature prevents nodes that have ISATAP interfaces from connecting to Server 2008 using IPv6 packets encapsulated in IPv4 packets, potentially bypassing router Access Control Lists (ACLs) and firewalls. The theory is that if the host name ISATAP can be resolved, then the network administrator wants to permit IPv6 connectivity through encapsulation of IPv6 in IPv4 packets. If you need to enable the ISATAP interface when there no ISATAP router is available—say, to support IPv6-only applications—you can manually enable the ISATAP interface and force Server 2008 to accept incoming encapsulated traffic by typing the command
netsh interface ipv6 isatap set state enabled
Note that all other version of Windows that support IPv6—Windows Vista, Windows XP, and Windows Server 2003—will allocate an address to the ISATAP interface even if the host name ISATAP can't be resolved, and it can be used to communicate with other ISATAP-enabled hosts. The second noteworthy change in Server 2008 is also related to ISATAP. If you create an A record in a DNS zone on a Server 2008-based DNS server for ISATAP, the DNS server won't respond to DNS queries for the host name ISATAP, by default. This feature, also security-related, prevents a user from inadvertently (or maliciously) starting a machine called ISATAP and having an A record created in DNS that can then be resolved. A machine with the name ISATAP is presumed to be an ISATAP router, and all IPv6 nodes will attempt to communicate with it—via encapsulation of IPv6 packets in IPv4 packets—to request IPv6 addresses through router solicitation. If the machine named ISATAP responds with an IPv6 address prefix, it will become the default router for all IPv6 traffic, allowing a rogue administrator to intercept all traffic.
If you want to use ISATAP as part of your migration and transition strategy, and you've installed and configured an ISATAP server, you can enable Server 2008–based DNS to serve responses to queries for an A record for the host name ISATAP by editing the registry entry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters\GlobalQueryBlockList. This entry is a multi-string and contains two entries— isatap and wpad (which also has security implications). Simply remove the isatap entry and restart the DNS server. You'll need to make this change on all the DNS servers that contain the zone(s) in which the entry ISATAP is defined. You can also use the Dnscmd command line utility. For more information about configuring the global query block list, including how to use Dnscmd tool to manage it, download the Microsoft article "DNS Server Global Query Block List."
Planning and Reorganizing for IPv6
Before you start to configure Server 2008 to support your IPv6 network, you need to plan how you'll support IPv6 in your environment. And before you can begin planning, you need to gather some basic information. First, you need to make decide whether you're going to use globally aggregatable (public) IPv6 addresses throughout or whether you'll be using a private address space. If you decide to use public IPv6 addresses, you need to get an IPv6 address prefix from your ISP. If your ISP doesn't support IPv6, yet, you can get an address prefix from a tunnel provider. If you decide to use private IPv6 addresses, the preferred approach is to use locally unique addresses, but most OSs and applications still support site local addresses, which are officially deprecated. If you want to use locally unique addresses, you'll need to obtain a unique prefix. A growing number of sites on the Internet provide a locally unique address prefix generator—for example, SixXS. In a Windows environment, there's a distinct advantage to using site local addresses, which I'll describe later. (Note that you can use private addresses in the interim to provide IPv6 connectivity in your intranet today, then move to public IPv6 addresses later.)
Next, you need to evaluate each of your network's end systems—servers, desktops, laptops, and even devices such as VoIP phones and mobile devices. Anything that connects to your network will be in-scope for inspection. For each system, you need to determine whether IPv6 is supported by the OS and by the applications that run on them. It's extremely unlikely that every platform and application will offer full support for IPv6 (or can be upgraded to support it), so you'll most likely need to continue to support IPv4. You should also determine which systems support IPv6 migration and transition mechanisms, including 6to4 and ISATAP. Luckily, IPv6 is designed to coexist with IPv4, so you can run both together, if necessary.
Next, inspect your network infrastructure for IPv6 support. Your network infrastructure will include your routers, gateways, firewalls, and DHCP and DNS servers. You'll have to rely on migration and transition technologies to provide IPv6 connectivity to end systems connected to any network device that doesn't support IPv6 natively and can't be upgraded to support it. At a minimum, you'll need DNS servers that support IPv6—for example Server 2008-based DNS. At this point, I recommend that you reorganize your network so that all the end systems and network devices that support IPv6 are connected to one another. Doing so will allow as much of your environment as possible to run IPv6 natively, and you can rely on migration and transition technologies to provide IPv6 support to those end systems that support IPv6 but are connected to non-IPv6 capable infrastructure. As a rule, don't require servers that support IPv6—especially critical infrastructure servers or heavily accessed servers—to rely on migration and transition technologies for IPv6 connectivity. Doing so will slow down access to those end systems and might even destabilize your network. Remember that Windows, and increasingly applications and other OSs, will attempt to communicate using IPv6 by default.
If you've identified networking infrastructure that doesn't support IPv6, and there will be end systems connected to it that can support IPv6, you need to decide whether you want to use a migration and transition technology to provide IPv6 connectivity to those end systems, or whether to continue relying on IPv4. Assuming that you do want to provide IPv6 connectivity, you need to examine the systems further to determine what migration and transition technology is the most applicable. If the end systems have public routable IPv4 address (i.e., an IPv4 address that doesn't start with 10.x.x.x, 172.16.x.x-172.31.x.x, or 192.168.x.x), 6to4 is probably most applicable and is enabled by default to provide IPv6 connectivity. If the end systems have a private IPv4 address (i.e., an address that does start with 10.x.x.x, 172.16.x.x-172.31.x.x, or 192.168.x.x)—and if there isn't a Network Address Translation (NAT) device between those end systems and your other IPv6-capable end systems and network infrastructure—ISATAP is the technology you'll want to use. If there is a NAT device between your end systems and your other IPv6-capable end systems and networks, you can use a technology called Teredo. Support for Windows to function as a Teredo client is available, but unfortunately no Teredo server functionality is available in Server 2008. You can use a third-party Teredo server, or you can wait for Server 2008 R2, which will provide this functionality. (For more information on features in Windows Server 2008 R2, download the Microsoft PowerPoint presentation "Introducing Windows Server 2008 R2".)
Enabling Basic IPv6 Connectivity with Router Solicitation
If your routers support it, you can simply configure each router in your environment to advertise a unique IPv6 address prefix on each subnet interface. If you're using globally aggregatable IPv6 addresses, you'll get a 48-bit prefix from your ISP, which will begin with 2001::/16. The Site Level Aggregation Identifier (SLA ID) is the lower 16 bits of the upper 64 bits of a globally aggregatable IPv6 address and can be used to subnet your site—which the upper 48 bits of the top 64 bits uniquely identifies. For example, if you got the prefix 2001:470:8097::/48, you would configure your routers with the prefixes for each interface in sequence as 2001:470:8097:1::/64, 2001:470:8097:2::/64, 2001:470:8097:3::/64, and so on. If you're using locally unique addresses, you'll get a 48-bit prefix—for example, fd37:533b:f40d::/48. (Locally unique addresses begin with fd00::/8.) As with a globally aggregatable address, use the lower 16 bits to uniquely identify each subnet interface. Finally, if you're using deprecated site local address that begin with fec0::/10, you can use as many as 54 bits in the top 64 bits of the IPv6 address to uniquely indentify subnets, although conventionally a site local address begins with fec0:0:0::/48, leaving 16 bits to create up to 65,536 subnets.
Following the instructions that come with your router software, you'll need to enable router solicitation and advertisements, as well as built-in routing table management software, such as Routing Information Protocol for IPv6 (RIPv6). With such a router configuration, your IPv6-capable end systems will get routable IPv6 addresses from the routers (through the process of router solicitation), configure default gateways, and be able to communicate using IPv6 with each other and—in the case of end systems with globally aggregatable IPv6 addresses—the IPv6 Internet itself.
Using Migration and Transition Technologies for Basic IPv6 Connectivity
If one, a few, or all of your routers don't support IPv6, router solicitation and discovery, or routing table management, you'll need to fall back to using the migration and transition technologies to facilitate IPv6 connectivity. Both 6to4 and ISATAP rely on encapsulation of IPv6 packets in IPv4 packets. When an IPv6 packet is encapsulated in an IPv4 packet, the IPv4 packet protocol type is 41. For these migration and transition technologies to work, you need to ensure that your routers will allow IPv4 packets with a packet protocol type of 41 to pass unhindered.
As I mentioned earlier, if your end systems have public IPv4 addresses, and they support 6to4 (as Windows does), they will have been assigned a 6to4 IPv6 address, which can be easily identified as it will begin with 2002::/16. You can verify connectivity between systems and the IPv6 Internet with 6to4 addresses using Ping—for example,
ping -6 www.arin.net
If you're using a combination of 6to4 and globally aggregatable addresses in your network, be aware that traffic between a node with a 6to4 address and a node with a globally aggregatable address (and vice versa) will flow over the IPv4 and IPv6 Internets, through a public 6to4 relay, and you might suffer poor performance. If this is the case, you might want to use ISATAP instead. Note also that connectivity between a node with a 6to4 address and a node with a locally unique or site local address (and vice versa) isn't possible via public 6to4 relays. This situation occurs when some end systems use public IPv4 addresses and some use private IPv4 addresses, and private routers are configured to allow them to communicate with each other. In such cases I recommend that you consider using only public or only private IPv4 addresses throughout, and use ISATAP exclusively.
When using private IPv4 addresses, and when your network infrastructure doesn't support IPv6, the best option for IPv6 connectivity is ISATAP. You need to designate a system in your network as an ISATAP router. Your ISATAP router will usually have a minimum of two network interfaces: one public and one private. Public interfaces will have a globally aggregatable IPv6 address or a 6to4 address in conjunction with a public IPv4 address assigned to them. Private interfaces will have an ISATAP address assigned to them. The ISATAP router will listen for router-solicitation requests on the private interface(s) and reply with router advertisements. IPv6 traffic is encapsulated in IPv4 packets on the private interface(s). Server 2008 makes an ideal ISATAP router, especially when run on Server Core. The simplest way to make Server 2008 function as an ISATAP router is to give it fixed public and private IPv4 addresses and to name it ISATAP. It will register the name ISATAP in DNS, allowing for ISATAP discovery. (Remember to configure DNS to serve queries for ISATAP, as I described earlier, if DNS is running on Server 2008). You'll need to configure Server 2008 with the following commands for each private interface:
netsh interface ipv6 set interface (Interface)
forwarding=enabled advertise=enabled
netsh interface ipv6 add route (IPv6 48-bit address):
(16-bit subnet)::/64 (Interface) publish=yes
where IPv6 48-bit address is the 48-bit prefix given to you by your ISP (or the top 48 bits of your 6to4 address), 16-bit subnet is a 16-bit subnet identifier unique to the interface, and Interface is the name of the ISATAP interface or its Index number. If you don't have a globally aggregatable address or 6to4 prefix to use with ISATAP, you can use a locally unique or site local address instead.
Once your ISATAP router is configured, and hosts can resolve the name ISATAP at startup, they will get routable IPv6 addresses from the ISATAP router and publish them in DNS. You can force configuration on running systems with the command
ipconfig /renew6
Configuring DNS Clients
Even though machines can communicate using IPv6, you'll have difficulty establishing communication at the application level if you can't resolve Fully Qualified Domain Names (FQDNs), or host names. If you're running IPv4 and IPv6 side-by-side, and your DNS servers can be reached using IPv4, you should have no problems registering and resolving IPv6 addresses in your environment, and resolving the IPv6 addresses of hosts on the IPv6 Internet.
Every Windows client assumes that there are DNS servers listening on the site local IPv6 addresses fec0:0:0:ffff::1, fec0:0:0:ffff::2, and fec0:0:0:ffff::3. If you're running only IPv6 and are willing to use site local addressing, you can leverage the assumption that Windows makes about where DNS servers are located and configure your subnets to facilitate DNS client configuration. Remember, you can use site local addressing and globally aggregatable, locally unique, or ISATAP addresses simultaneously. If you don't want to use site local addresses simply to support your DNS clients, you can configure Windows to use different DNS servers with the command:
netsh interface ipv6 add dnsserver (IPv6 address)
Using DHCPv6
In native IPv6 networks, you can use DHCPv6 instead of router solicitation and advertisement to serve IPv6 addresses to your end systems. For DHCPv6 to work, your routers must be capable of functioning as IPv6 DHCP relay servers. You can also use DHCPv6 in small, isolated network environments where there are no routers, when you want to enable IPv6 connectivity between nodes.
DHCPv6 works similarly to DHCP. A key difference is that you specify the /64 prefix and then the address ranges within the subnet that you want to allocate IPv6 addresses from. There are also fewer DHCPv6 scope options than DHCP scope options. As with DHCP, you can use DHCPv6 to serve the list of DNS servers that your nodes should use for name resolution, along with the IPv6 address allocated. The advantage of using DHCPv6 over the default site-local addresses configured in Windows is that you can serve the IP addresses of DNS servers on different subnets, for fault-tolerance purposes. You can also configure the DHCPv6 server on Server 2008 to serve the list of IPv6 addresses for DNS servers by configuring Server Options alone, which is useful when you choose not to use DHCPv6 to serve IPv6 address leases and rely on router solicitation and advertisements instead. You can also provide the list of domain suffixes to search, too.
Coming in Server 2008 R2
One topic I haven't covered is the use of IPv6 in VPN, or remote-access, scenarios. With Windows 7 and Server 2008 R2, Microsoft will release Direct Access, which will provide a more effective, secure means of accessing enterprise resources remotely. Direct Access combines Teredo with IPv6 IPsec, and a new feature called IP-HTTPS, which will allow IPv6 packets to be tunneled through HTTPS connections when Teredo cannot be used or is blocked. I will describe Direct Access in more detail closer to the release of Windows 7 and Server 2008 R2. In the interim, you can find out more details here. For more information about IPv6 in Windows Vista and Windows Server, I recommend you visit the Microsoft website.
