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.