Managing Your Migration and Transition from IPv4 to IPv6

In “The Inevitability of IPv6, Part 1”, I provided you with an IPv6 overview and described the differences between IPv4 and IPv6. I covered the differences between IPv6 link-local, site-local, and globally aggregatable uncast addresses, and I defined multicast addresses and how they’re used. I also discussed how nodes get IPv6 addresses. In “The Inevitability of IPv6, Part 2”, I discussed support for IPv6 in Windows networks and showed you how to install and configure it.

Although you can get IPv6 up and running in your enterprise environment with surprising ease—and most applications can use it—you’ll face challenges when you try to use IPv6 over the Internet. First, most ISPs don’t yet natively support IPv6, and even if your ISP is IPv6-ready, your customers and business partners are most likely still running IPv4. For this reason, you’ll likely need to support both IPv4 and IPv6 simultaneously. The good news is that the IPv6 architects foresaw a need for coexistence, believing that many users would use IPv4 for some time to come. In this concluding article in my “Inevitability of IPv6” series, I describe some solutions for supporting and using both technologies, and I show you a means with which to connect remote sites running IPv6 over an IPv4 link.

Tunneling IPv6 Basics
It’s possible to encapsulate or tunnel IPv6 in IPv4 traffic—for example, to provide IPv6 connectivity between two sites over the IPv4 Internet. This is accomplished by using a dedicated IPv4 protocol type, number 41. When encapsulating IPv6 in IPv4, the Maximum Transmission Unit (MTU) for the IPv6 packet is less than the MTU for the IPv4 packet (typically, the IPv4 MTU minus the size of the IPv4 packet header).

The use of a dedicated protocol combined with the structure of the encapsulated packet doesn’t provide for tunnel setup or breakdown, guaranteed delivery at the IPv4 level, or basic security such as authentication, authorization, or encryption. These items are all handled within the IPv6 encapsulated packet. Tunnel endpoints send encapsulated IPv6 packets as necessary and will receive them unsolicited.

Tunnels can be established between hosts: from a host to a router, from a router to a host, and between routers. Tunnels can be either configured or automatic. As the names suggest, a configured tunnel is set up manually and an automatic tunnel is set up based on rules or some other logic.

Tunnels are useful for a couple of reasons. First, they’re an excellent means for establishing IPv6 connectivity between sites with unique, routable IPv4 addresses but with no public IPv6 addresses. Second, tunnels are useful as a means of transition to IPv6 by enabling access to the IPv6 Internet even if your ISP doesn’t support it. This is accomplished by utilizing the services of a tunnel broker. There are a number of tunnel brokers who offer low-cost or even free services.

Manually Configuring an IPv6 Tunnel
You can create an IPv6 tunnel between Windows nodes or a Windows node and a node running another OS by using the Netsh (netsch.exe) command to set the tunnel as the default route. For example,

NETSH interface ipv6 add v6v4tunnel
NETSH interface ipv6 set address
NETSH interface ipv6 add route ::/0

The argument TunnelInterfaceName is the name you give the tunnel interface. The IPv4 address a.b.c.d is the IP address of the local node from which the tunnel will be established, w.x.y.z is the IPv4 address of the remote node, and TunnelIPv6Address is the local node’s IPv6 address on the tunnel endpoint. The commands take optional arguments, including neighbordiscovery for the first command, which can be set to enabled or disabled, and which controls whether IPv6 neighbor discovery (described in Part 1 of this series) is enabled. The second optional argument, store, which can be set to active or persistent, controls whether the tunnel or route is persistent across reboots or just alive for the active session until the machine is shut down or rebooted. For tunnels between sites, you’ll likely want to enable neighbor discovery, but you’ll want to disable it (the default) on tunnels to an IPv6 tunnel broker. You’ll need to run these commands—reversing the IP addresses and IPv6 address—on the other end of the tunnel. There are similar commands for non-Windows systems.

A Windows node with a tunnel endpoint can act as an IPv6 router for other nodes on the intranet. By using ISATAP (which I discuss below), it can do this even if IPv6 isn’t supported on the intranet. To enable a Windows node with an IPv6 tunnel to route packets, you need to configure the node further, using the following commands:

NETSH interface ipv6 set interface forwarding=enabled advertise=enabled
NETSH interface ipv6 add route / publish=yes

In each command InterfaceName is the name of the physical or tunnel interface (e.g., Local Area Connection 2), IPv6Address is the IPv6 node or network address of the route, and PrefixLength is the length of the address to be used for routing purposes. You need to repeat the first command for every interface you want to route IPv6 packets between, and repeat the second command for every interface for which you want to enable router solicitation and discovery. Typically, you won’t use the advertise=enabled option to the first command (or the second command at all) on the tunnel interface itself. Instead, you’ll want to create a default route for the remote tunnel endpoint.

For nodes other than the tunnel endpoints, when not using router solicitation and advertisement or ISATAP, you’ll need to ensure that they know the tunnel exists by manually or automatically populating their routing tables with the IPv6 prefixes of networks on the other end of the tunnel, or setting the local tunnel endpoint as the default IPv6 router. This approach lets nodes with either site-local or globally aggregatable addresses communicate with other IPv6 nodes through the tunnel.

Finally, when you’re using a manually established tunnel with a tunnel broker to enable IPv6 Internet access, you’ll need a public, static IPv4 address. You probably won’t be able to use a non-routable IPv4 address behind a proxy server or firewall with Network Address Translation (NAT) or Port Address Translation (PAT). IPv4 addresses provided to you by an ISP using DHCP (commonly found on xDSL and cable modem–based Internet connections) won’t suffice either because you would have to update the tunnel endpoints each time the IPv4 address changes.

6to4
An alternative to manual tunnel configuration is another transition mechanism called 6to4. Unlike a manual tunnel, 6to4 tunnels are set up and torn down between nodes—without user intervention—as necessary, and not all data is sent over a single tunnel. Tunnels are established with nodes based on destination IPv6 address.

There’s a special IPv6 address prefix (i.e., 2002::/16) set aside for 6to4. Note that 6to4 nodes can be hosts (end nodes) and routers (nodes with public IPv4 and global IPv6 addresses). Each will have an IPv6 interface with an address that has this prefix. The next 32 bits of the 6to4 address are the node’s public IPv4 address in hexadecimal format, to create a /48 prefix.

A Windows Vista, Windows Server 2008, Windows Server 2003, or Windows XP system with a public, routable IPv4 address will assign itself a 6to4 IPv6 address based on that IPv4 address if it hasn’t received an IPv6 address as part of router solicitation and advertisement, and can’t find an ISATAP router (which I discuss next). The IPv6 address takes the form 2002: wx:yz::wx:yz, where wx represents the first two bytes in hexadecimal format of the system’s IPv4 address, and yz represents the last two. With a 6to4 address, the 6to4 node will attempt to find a 6to4 relay router on the Internet. A 6to4 relay router is a node that sits on both the IPv4 Internet and the IPv6 Internet and allows 6to4 systems to connect with nodes on the IPv6 Internet through them. Vista, Server 2008, Windows 2003, and XP systems find a 6to4 relay router by using DNS to resolve the fully qualified domain name (FQDN) 6to4.ipv6.microsoft.com. This returns the IPv4 address of a relay router.

A system with a 6to4 address can act as a router for itself and for 6to4 hosts; 6to4 hosts receive their 6to4 IPv6 address from the 6to4 router as part of router solicitation and advertisement. Note that 6to4 hosts have a global unicast address with the prefix 2002: wx:yz:subnetid::/64, where wx and yz are the hexadecimal representation of the 6to4 router’s public IPv4 address w.x.y.z, and subnetid is unique to the physical adapter on the 6to4 router over which the router solicitation and advertisement takes places. Remember that 6to4 hosts append their 64-bit interface address based upon their MAC address (which I described in the first article in this series). And 6to4 hosts might also have a private, non-routable IPv4 address. When a 6to4 host gets its IPv6 address from a 6to4 router, that router becomes the default route for the host.

For a Windows system to act as a 6to4 router, it must first have a 6to4 address and it must be manually configured through the use of the Netsh command. The commands necessary to enable a 6to4 router are

NETSH interface ipv6 set interface forwarding=enabled advertise=enabled siteprefixlength=48
NETSH interface ipv6 6to4 set state enabled
NETSH interface ipv6 set interface ɞto4 interface> forwarding=enabled siteprefixlength=48
NETSH interface ipv6 add route 2002:::::/64 publish=yes siteprefixlength=48

In these commands, PrivateInterface is the name of the network adapter that is the private, intranet interface (e.g., Local Area Connection 2), wx represents the hexadecimal first two bytes of the IPv4 address, yz represents the hexadecimal last two bytes of the IPv4 address, and subnetid is the interface index allocated to the adapter. If the 6to4 router has more than one interface, the first and fourth Netsh commands must be repeated for each, if IPv6 communication is desired on each.

A 6to4 host—when establishing an outbound connection to a node that isn’t available using a link-local or site-local address—will forward IPv6 packets to the 6to4 router from which it got its 6to4 address. The 6to4 router will examine the destination address to determine how best to route it. An address that is a 6to4 address itself (i.e., one beginning with 2002::/16) will be reached by using the IPv4 address contained in the prefix and encapsulating the IPv6 packet in an IPv4 packet with the protocol type set to 41. If the destination IPv6 address isn’t a 6to4 address, the 6to4 router will instead send the packet to the IPv4 address of the 6to4 relay, which was obtained when resolving 6to4.ipv6.microsoft.com.

Like nodes with manual tunnels, 6to4 routers need a public IPv4 address; 6to4 routers and hosts, including those with private IPv4 addresses, are reachable by IPv6 nodes on the IPv6 Internet and will see incoming packets. When an IPv6 node wants to communicate with a 6to4 host, the IPv6 packets will be directed to the 6to4 router, using its IPv4 address. The 6to4 router will forward the packet to the 6to4 host. For this reason, all 6to4 hosts and routers must be behind an IPv6 firewall or have a suitable host-based firewall. I discuss firewalls and IPv6 host security in a moment.

ISATAP
I covered Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) briefly in the second article in this series. ISATAP, designed for use in intranet environments, lets IPv6 nodes on different links in a site communicate over an IPv4 network when there are no IPv6-capable routers and when site local addressing can’t be used. ISATAP is an example of an automatic tunnel mechanism.

ISATAP is also useful as a transition strategy. An IPv6 node running Server 2008 or Windows 2003 can function as an ISATAP router and can be used as a gateway for IPv6 nodes with IPv4 addresses on a network without IPv6 routers, as well as an IPv6 network such as the IPv6 Internet. In this scenario, the ISATAP router is configured with a global unicast address, either manually (as part of router solicitation and advertisement) or with a 6to4 address, the prefix of which it will advertise to IPv6 nodes that communicate with it over IPv4 so that they can access the IPv6 network. When IPv6-enabled Windows nodes start up, they perform a name lookup for ISATAP using the local hosts file, NetBIOS name broadcast, and DNS lookup. You can also manually configure IPv6 hosts with the IPv4 address of an ISATAP router by using the Netsh command:

netsh interface ipv6 isatap set router

In the command, w.x.y.z is the IPv4 address of the ISATAP router. The IPv6 nodes will contact the ISATAP router using IPv6, encapsulated in IPv4 packets, with the protocol set to 41. The IPv6-enabled nodes will send a router-solicitation message to the ISATAP router, which will reply with router advertisements, including details of the prefix of any globally aggregatable addresses allocated to the ISATAP router. IPv6 nodes that establish communication with an ISATAP router—and are given IPv6 prefixes as part of router solicitation and advertisement—are called ISATAP hosts.

When an ISATAP host wants to communicate with an IPv6 node that isn’t on the same link and isn’t reachable using the ISATAP interface, it sends the IPv6 packet encapsulated in IPv4 to the ISATAP router, with the IP protocol number set to 41. The ISATAP router extracts the IPv6 packet and forwards it to the next hop, determined by its IPv6 routing table, or to its default IPv6 router if no suitable routing table entries exist.

A Server 2008 or Windows 2003 IPv6 node must be configured as an ISATAP router. To configure the node as an ISATAP router, you can issue the following commands:

NETSH interface ipv6 isatap set state enabled
NETSH interface ipv6 set interface forwarding=enabled
NETSH interface ipv6 set interface “Automatic Tunneling Pseudo-Interface” forwarding=enabled advertise=enabled
NETSH interface ipv6 add route / “Automatic Tunneling Pseudo-Interface” publish=yes
NETSH interface ipv6 isatap set router

In the above commands, PublicOrTunnelInterfaceName is the name of the Internet-connected adapter or tunnel interface, address/prefix is the portion of the IPv6 address you want the ISATAP router to advertise (the prefix is usually set to 48 or 64), and w.x.y.z is the ISATAP router’s private (intranet) IPv4 address. The last command is necessary only if the ISATAP router can’t resolve the name ISATAP. These commands will take effect immediately and will persist until the next reboot. You can use the store=persistent argument with the Set Interface and Add Route commands to make these configurations changes persist across reboots.

I recommend that you disable IPv6 on the private (intranet) physical adapter. If your ISATAP router is using a tunnel to connect to the Internet (rather than a 6to4 address on a public IPv4 address) or is physically connected to the IPv6 Internet on the public (Internet) interface, I recommend that you also disable IPv6 on the public (Internet) physical adapter. You can do this by clearing the Microsoft TCP/IP version 6 check box in the adapters’ Properties dialog box. The reason for doing this is that you might find you can’t advertise routes on the Automatic Tunneling Pseudo-Interface, and ISATAP clients won’t be able to connect to the IPv6 Internet if IPv6 is configured on the private interface.

Securing IPv6
Because IPv6 is a replacement at the network layer for IPv4, and because TCP connections and UDP transmissions run over IPv6 as they do over IPv4, securing your IPv6 network is essential. In fact, when it comes to deploying network firewalls, deploying host-based firewalls, or configuring routers with ACLs, IPv6 should be considered with special caution.

On networks in which IPv6 is supported in the routing infrastructure, and every host has a globally aggregatable unicast IPv6 address, you can configure your IPv6-capable network and host-based firewalls and routers with ACLs much like you do for IPv4, based on source and destination IPv6 address, source and destination ports, and TCP or UDP protocol. Content inspection in application-level filtering firewalls should work without problems.

When using 6to4 or ISATAP, there are particular security concerns for the end systems or hosts. Every IPv6 node is reachable from the IPv6 Internet through the 6to4 or ISATAP router, as each has a global unicast address. I recommend a defense-in-depth approach. The first line of defense in this approach would be the use of a network-level firewall that supports IPv6 to filter out unwanted or potentially malicious traffic before it reaches the ISATAP or 6to4 router. The second is to use Windows Firewall on the ISATAP or 6to4 router itself. Note that Windows Firewall supports IPv6 over physical adapters, but not tunnels. If you use a tunnel you won’t be able to configure the firewall to filter out unwanted traffic. The third line in the layered defense model is the use of host-based firewalls. The fine line is to disable any unnecessary services on end IPv6 nodes.

Finally it’s important to remember that ISA Server 2006 doesn’t support IPv6, and I strongly recommend that you not use an ISA Server 2006 system as an IPv6 router in any configuration.

More to Consider
IPv6 was designed with transition from IPv4 in mind. I’ve covered three common means with which to get your current network up and running on the IPv6 Internet even if your ISP doesn’t support IPv6 yet. One method, ISATAP, lets you use IPv6 throughout your organization even though your internal network infrastructure doesn’t support IPv6. There are other technologies and transition strategies available to you, including Teredo, which works behind NAT routers and firewalls. For more information about other transition strategies, I recommend you read the Microsoft article “IPv6 Transition Technologies”.