Planning for IPv6 Deployment

364Understanding IPv6, Second Edition

■Host-based security and IPv6 traffic

■Prioritized delivery for IPv6 traffic

Platform Support for IPv6

Microsoft has supplied a production-quality IPv6 protocol in the following versions of Windows for personal computers:

■Windows Server 2008

■Windows Vista

■Windows Server 2003

■Windows XP with Service Pack 1 or later

As described in Chapter 2, “IPv6 Protocol for Windows Server 2008 and Windows Vista,” almost all of the included applications in Windows Server 2008 and Windows Vista will work over IPv6. Windows Server 2008 and Windows Vista are the recommended versions of Windows for an IPv6 deployment because of the widespread application use for authentication (Active Directory) and user (Internet Information Services) services.

Windows Server 2003 and Windows XP with Service Pack 1 or later provide an IPv6 protocol, but they have limited support for IPv6 operation in included applications. For example, Windows Server 2003 and Windows XP with Service Pack 1 or later components do not support Active Directory operations over IPv6. Therefore, if you deploy IPv6 on an intranet that consists of computers running Windows Server 2003 or Windows XP with Service Pack 1 or later, there will not be a lot of IPv6 traffic because not many built-in applications in these operating systems support IPv6.

However, an intranet with computers running only Windows Server 2008 or Windows Vista is not a prerequisite for IPv6 deployment. For example, if your intranet consists of hosts running Windows Server 2003 or Windows XP, you can deploy IPv6 connectivity and name resolution infrastructure and begin updating your applications for IPv6 support now. As you deploy Windows Vista, Windows Server 2008, and updated applications on hosts across your intranet, the amount of IPv6 traffic on your intranet will gradually increase.

Application Support for IPv6

Although almost all the applications in Windows Server 2008 and Windows Vista support operation over IPv6, whether third-party applications and custom applications developed for use by your organization support operation over IPv6 depends on the application programming interfaces (APIs) that they use for network operations. For applications that use IP protocol–independent APIs, such as Microsoft Remote Procedure Call (RPC) or the .NET Framework, no modification is needed for operation over IPv6.

Applications that use IP protocol-dependent APIs such as Windows Sockets (Winsock) might need to be updated to support operation over IPv6. For example, a Winsock application

might use the older Gethostbyname() function, which is an IPv4 protocol–specific function that returns only IPv4 addresses. This application must be modified to use the new Getaddrinfo() function, which returns both IPv4 and IPv6 addresses.

For the details of Winsock support for IPv6, see Appendix B, “Windows Sockets Changes for IPv6.”

Unicast IPv6 Addressing

Just as for your IPv4 infrastructure, you must decide on a unicast IPv6 addressing plan for your intranet, even if you are initially using tunnel-based IPv6 connectivity. You must determine how to number the individual subnets of your organization. Subnet addressing for IPv6 is actually easier than IPv4, due to the 64-bit prefix length for LAN subnets and the relative abundance of address space for organizations.

You can implement a flat addressing scheme that does not use route summarization, in which each subnet prefix becomes a separate route in the routing tables of your native IPv6 routers. Alternately, you can configure your routing infrastructure so that unicast address prefixes are summarized by routers at suitable boundaries. For unicast addresses for your subnets, you can use global addresses and unique local addresses.

Global addresses require a global address prefix. Most organizations can obtain a global address prefix from their Internet service providers (ISPs). A large enterprise or an organization that is providing IPv6 connectivity for other organizations should obtain a suitable global prefix from a regional Internet registry, such as the American Registry for Internet Numbers (ARIN) at http://www.arin.net. A global address implies reachability from any location on the IPv6 Internet, although actual reachability between an IPv6 Internet location and an intranet location can be restricted by the edge firewalls of an organization or by not advertising the global prefix outside the organization’s intranet.

For unique local addresses, you must create a 40-bit random hexadecimal number which, when combined with the prefix FC00::/8 or FD00::/8, becomes a 48-bit unique local prefix for your organization. See RFC 4193 for information about how to create a random number for the Global ID portion of your unique local prefixes. If your organization has multiple sites, you can create a 48-bit unique local prefix for each site. A unique local address prefix is not designed to be reachable from the IPv6 Internet—your edge routers should not be advertising your unique local prefix to other routers on the IPv6 Internet. The use of unique local address prefixes is optional.

When determining the boundaries of IPv6 subnets, consider the following:

■You can define your subnet boundaries to be the same as your IPv4 subnet boundaries. This is the easiest approach to take because there are already IPv4 routers at your IPv4 subnet boundaries and they just need to be configured or updated to act as IPv6 routers. In this configuration, every local area network (LAN) subnet will have an IPv4 subnet prefix and one or multiple IPv6 subnet prefixes.

tested, and deployed. The traffic of both types of applications share a single common IPv4 infrastructure.

ISATAP does not support IPv6 multicast traffic. Therefore, as you begin to convert IPv4-only subnets to native IPv6-capable subnets, those subnets might have IPv6 multicast support. However, all the ISATAP hosts on the IPv4-only portion of your intranet will not be able to use IPv6 multicast traffic. For example, some organizations use multicast traffic for streaming media of live presentations. During the transition between an IPv4-only to IPv6-capable intranet, multicast traffic sent over IPv6 will not reach the ISATAP hosts on the IPv4-only portion of the intranet. Therefore, you should send your multicast traffic over IPv4 until your entire intranet is IPv6-capable.

ISATAP is described in Chapter 12, “ISATAP.”

6to4

6to4 provides unicast connectivity for IPv6/IPv4 hosts or IPv6 sites and connectivity to the IPv6 Internet across the IPv4 Internet. As implemented in Windows, 6to4 is best suited for small office/home office networks that use the Internet Connection Sharing (ICS) feature and for individual computers that connect to the IPv4 Internet with a public IPv4 address.

For intranets, 6to4 can provide a 48-bit global prefix for each site that has a public IPv4 address and connectivity to the IPv6 Internet across the IPv4 Internet. However, for connectivity between IPv6-enabled sites of an organization across the Internet, 6to4 does not provide any protection for the IPv4-encapsulated IPv6 packets. To protect 6to4-based traffic between sites across the IPv4 Internet, you can manually configure 6to4 routing and use Internet Protocol security (IPsec) policies to protect all IPv4 protocol 41 traffic between the public IPv4 addresses of your 6to4 routers. Alternately, you can use Routing and Remote Access and configure site-to-site virtual private network (VPN) connections to route IPv6 packets between the sites of an organization across the IPv4 or IPv6 Internets.

6to4 is described in Chapter 13, “6to4.”

Teredo

Teredo provides unicast connectivity across the IPv4 Internet between IPv6/IPv4 hosts, even when they are located behind IPv4 Network Address Translators (NATs). With a Teredo relay, Teredo also provides connectivity to the IPv6 Internet across the IPv4 Internet. As implemented in Windows, Teredo is designed for individual computers that connect to the IPv4 Internet and is not a suitable technology for tunneling between IPv6/IPv4 hosts on an intranet.

Teredo is described in Chapter 14, “Teredo.”

368 Understanding IPv6, Second Edition

Manually Configured Tunnels

You can also manually configure tunnels between IPv6-capable routers. Configured tunnels are static tunnels that rely on routes in the IPv6 routing table to forward traffic through the tunnel. Routers on each end of the tunnel must be configured with a tunneling interface and an appropriate set of routes. You can use configured tunnels to do the following:

■Connect IPv6 islands on an intranet For example, if you have different portions of your intranet that are not contiguous but are IPv6-capable, you can connect them with configured tunnels.

■ Connect to the IPv6 Internet across the IPv4 Internet Rather than using an ISP with native IPv6 connectivity, you can also connect to the IPv6 Internet through an ISP that offers tunneled connectivity to the IPv6 Internet. In this case, you configure an edge router of your organization with a configured tunnel to the ISP’s router.

Manual tunnel configuration is described in Chapter 11, “IPv6 Transition Technologies.”

Disabling Tunneling Technologies

If you decide not to use tunnel-based IPv6 connectivity and you want to disable all the automatic tunneling technologies for computers running Windows Server 2008 or Windows Vista, you can create and set the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tcpip6\Parameters\DisabledComponents registry value to 1 (DWORD type). DisabledComponents does not exist by default and must be manually created with the Registry Editor tool (Regedit.exe). Setting DisabledComponents to 1 disables all ISATAP, 6to4, and Teredo interfaces.

Because the DisabledComponents registry value applies only to computers running Windows Server 2008 and Windows Vista, an intranet containing computers running Windows Server 2003 or Windows XP with Service Pack 1 or later can still use ISATAP, 6to4, or Teredo. To prevent IPv6 tunneled traffic for ISATAP, 6to4, or Teredo from being forwarded across your intranet, you can configure your routers to silently discard the following types of traffic:

■IPv6 protocol 41 (ISATAP and 6to4 traffic)

■Source or destination UDP port 3544 (Teredo traffic)

To prevent IPv6 tunneled traffic for ISATAP, 6to4, or Teredo from being forwarded between your intranet and hosts on the IPv4 Internet, configure your edge routers to silently discard these types of traffic.

As an alternative to the DisabledComponents registry value, you can disable 6to4 and Teredo by creating records in your internal Domain Name System (DNS) that resolve the names 6to4.ipv6.microsoft.com and teredo.ipv6.microsoft.com to unreachable addresses. If the 6to4 and Teredo components cannot successfully contact the servers at their resolved addresses, the 6to4 and Teredo tunneling interfaces will be disabled.