Routing IPv6 Traffic over an IPv4 Infrastructure

Routing IPv6 Traffic over an IPv4 Infrastructure

An eventual successful transition to IPv6 requires interim coexistence of IPv6 nodes in today's predominantly IPv4 environment. To support this, IPv6 packets are automatically tunneled over IPv4 routing infrastructures, enabling IPv6 clients to communicate with each other by using 6to4 or ISATAP addresses and tunneling IPv6 packets across IPv4 networks. For information about automatic tunneling of IPv6 packets, see RFC 2893, "Transition Mechanisms for IPv6 Hosts and Routers."

Support for IPv6 automatic tunneling technologies in Windows XP and Windows Server 2003 includes:

6to4, to provide automatic intersite tunnels across the IPv4 Internet.

ISATAP, to provide automatic intrasite tunnels.

A computer running Windows XP or Windows Server 2003 can automatically configure itself for 6to4 and ISATAP tunneling. The IPv6 Helper service, included with the IPv6 protocol for Windows XP and Windows Server 2003, provides support for 6to4 hosts and 6to4 routers. Use netsh interface IPv6 isatap context commands to configure the IPv6 Helper service. In addition, you can configure a computer running Windows XP or Windows Server 2003 as a 6to4 router by enabling the Internet Connection Sharing (ICS) feature on the interface that is connected to the Internet.

Both 6to4 and ISATAP encapsulate an IPv6 packet wi 11111q169l thin an IPv4 header. However, they send the packet across an IPv4 infrastructure in different ways:

6to4 uses the IPv6 prefix. 6to4 uses a public IPv4 address to create the 64-bit subnet identifier portion for an IPv6 address. For example, 131.107.71.152 becomes 2002:836B:4798::/48.

ISATAP uses the IPv6 interface ID. ISATAP uses a locally assigned IPv4 address (public or private) to create a 64-bit interface identifier. For example, 172.31.71.152 becomes ::0:5EFE:172.31.71.152.

In both cases, IPv4 addresses that are embedded in portions of the IPv6 address provide the information to determine the source and destination addresses in the encapsulating IPv4 header.

By deploying 6to4 or ISATAP, you can integrate IPv6 traffic into your IPv4 network environment. Understanding examples of each automatic tunneling technology can help you decide whether to deploy 6to4, ISATAP, or both as you introduce IPv6 on your network.

Using 6to4 for IPv6 Traffic Between Subnets or Between Sites

6to4 is an address assignment and router-to-router automatic tunneling technology that is described in RFC 3056, "Connection of IPv6 Domains via IPv4 Clouds." To facilitate the introduction of IPv6 in current IPv4 environments, IPv6 is designed so that you can use 6to4 to handle traffic between IPv6 nodes without obtaining an IPv6 global address prefix from an IPv6 ISP, and without a direct connection to the IPv6 Internet.

Figure 1.16 shows one way to use 6to4 to handle the following types of traffic:

Direct 6to4 host communication within a site (no tunnel). A 6to4 host can communicate directly with another 6to4 host within the same site. A 6to4 host is an IPv6 host that is configured with at least one 6to4 address (a global address with the 2002::/16 prefix). Host A and Host B in Figure 1.16 use the local 6to4 router to communicate with each other.

Tunnel across the IPv4 Internet by using a 6to4 router. A 6to4 host can communicate with a non-local 6to4 host by using a tunnel from a local 6to4 router across an IPv4 network (such as the Internet) to a 6to4 router at the destination site. The first 6to4 router encapsulates the packet in an IPv4 header; the receiving 6to4 router removes the IPv4 header and then forwards the IPv6 packet to the destination 6to4 host. During the first and last stages of the packet's transmission - from the sending 6to4 host to its 6to4 router, and from the recipient 6to4 router to the destination 6to4 host - the IPv6 routing infrastructure in place at each site is used. In Figure 1.16, 6to4 Host A (or 6to4 Host B) sends its packet to 6to4 Router 1, which tunnels it across the IPv4 Internet to 6to4 Router 2, which then forwards the packet to 6to4 Host C.

Tunnel across the IPv4 Internet to the IPv6 Internet by using a 6to4 router and a 6to4 relay. A 6to4 host on an IPv4 network can communicate with an IPv6-only host on the IPv6 Internet by using a tunnel from a local 6to4 router across the IPv4 Internet to a 6to4 relay that then forwards the packet across the IPv6 Internet to the recipient IPv6-only host. In this case, it is the 6to4 relay that removes the IPv4 header and forwards the IPv6 packet to the recipient IPv6-only host. In Figure 1.16, Host A (or Host B) sends its packet to 6to4 Router 1, which tunnels it across the IPv4 Internet to the 6to4 relay, which then forwards the packet to 6to4 Host D.

Figure 1.    Using 6to4 to Route IPv6 Packets

In Figure 1.16, 6to4 Router 2 represents a computer running Windows XP with ICS enabled. The private interface of the ICS computer connects to a single-subnet intranet, and the ICS computer's public interface connects to the IPv4 Internet. The private interface of an ICS computer always uses the private IPv4 address 192.168.0.1.

Using ISATAP for IPv6 Traffic Between Subnets

Intrasite Automatic Tunnel Addressing Protocol (ISATAP) is an address assignment and automatic tunneling technology that is described in the Internet Draft "Intrasite Automatic Tunnel Addressing Protocol (ISATAP)." ISATAP enables unicast communication between IPv6/IPv4 nodes in an IPv4 intranet.

ISATAP derives an interface identifier (the last 64 bits of an IPv6 address) from any IPv4 address assigned to the node, either public or private. The ISATAP address format supports configuration of global addresses (including 6to4), site-local addresses, and link-local addresses.

Figure 1.17 shows two IPv6/IPv4 hosts communicating over an IPv4 network by using each other's automatically configured link-local ISATAP address.

Figure 1.    Using Link-Local ISATAP Addresses to Route IPv6 Packets on an IPv4 Network

IPv6/IPv4 hosts can also communicate with non-local IPv6/IPv4 hosts by using ISATAP-derived global addresses, and by using an ISATAP router to tunnel packets through an IPv4 infrastructure. Under the IPv6 protocol that Windows XP and Windows Server 2003 support, you can use either of the following methods to configure the intranet IPv4 address of an ISATAP router:

Name resolution (preferred). For computers running Windows XP (SP1 or later) or Windows Server 2003, automatic resolution of the name ISATAP to an IPv4 address. To ensure successful name resolution, name the computer used as the ISATAP router ISATAP. A computer running Windows XP or Windows Server 2003 then automatically registers the appropriate records in DNS and WINS. For computers running Windows XP (earlier than SP1), the name resolved is _ISATAP.

Netsh commands for Interface IPv6. Manual configuration by using commands in the Netsh Interface IPv6 context.

An ISATAP host sends an IPv4-encapsulated Router Solicitation message to a configured ISATAP router. The ISATAP router responds with an IPv4-encapsulated unicast Router Advertisement message that contains prefixes for use in autoconfiguring ISATAP-based addresses. This additional configuration is needed only when the host's subnet does not contain an IPv6 router.

The example in Figure 1.18 shows how two ISATAP hosts that use 6to4 prefixes can communicate across the Internet even though each site is using the 192.168.0.0/16 private address space.

Figure 1.    Using 6to4 and ISATAP to Route IPv6 Packets Across the IPv4 Internet

Configuring DNS for IPv6/IPv4 Coexistence

Through DNS dynamic update, DNS client computers register and dynamically update their resource records with a DNS server whenever an IP address changes. This reduces the need to manually administer zone files, especially for clients that frequently move or change locations and that use DHCP to obtain an IP address.

In an IPv4 environment, by default the DNS Client service on computers running Windows 2000, Windows XP, or Windows Server 2003 dynamically updates host (A) resource records (RRs) in DNS. If all hosts on your network run those operating systems, DNS dynamic updates are automatic.

However, on hosts that do not support dynamic update, you must either enable dynamic update or manually add or update their DNS records. The same is true on a network to which IPv6 has been introduced: hosts that do not support dynamic update must have dynamic update enabled or must have DNS records added manually. IPv6 has the additional requirement that IPv6 nodes use a new type of address resource record, known as AAAA (quad-A) resource records, to resolve a fully qualified domain name to an IPv6 address. (Four "A"s are used for the name of these resource records because 128-bit IPv6 addresses are four times as large as 32-bit IPv4 addresses.)

Systems that support IPv6 use the same domain names as the domain names used in IPv4 but have both IPv6 and IPv4 addresses registered in DNS. The DNS Server service in Windows Server 2003 and Windows 2000 support processing for DNS IPv6 host records as defined in RFC 1886, "DNS Extensions to Support IP Version 6."

An IPv6 host sends DNS name queries to the DNS server to resolve host names to IPv6 addresses. The AAAA resource records stored on the DNS server provide the mapping from a host name to its IPv6 address.

DNS traffic is also supported over IPv6 for both client and server. The client and server are configured for IPv6 over DNS using anycast or unicast DNS server IP addresses. For more information, see "IPv6 configuration items" in Help and Support Center for Windows Server 2003.

Because IPv6 addresses are too long to remember easily, you can populate your DNS servers with IPv6 address resource records to support IPv6 name-to-address resolutions and optionally with pointer resource records to support IPv6 address-to-name resolutions:

Address Resource Records. To successfully resolve names to addresses, the DNS infrastructure must contain the following resource records, populated either manually or dynamically:

A resource records for the IPv4 addresses of IPv4 nodes.

AAAA resource records for the IPv6 addresses of IPv6 nodes. The following is an example of a AAAA resource record:

       host1.microsoft.com     IN     AAAA     FEC0::2AA:FF:FE3F:2A1C

Pointer (PTR) Resource Records (optional; not recommended). The DNS infrastructure can also contain the following resource records, populated either manually or dynamically, to resolve addresses to host names in reverse queries:

PTR records in the IN-ADDR.ARPA domain for the IPv4 addresses of IPv4 nodes.

PTR records in the IP6.ARPA domain for the IPv6 addresses of IPv6 nodes. (Recall that RFC 3152 specifies that IP6.INT be phased out and replaced by IP6.ARPA.) The IP6.INT domain was created specifically for IPv6 reverse queries. To create the namespace for reverse queries, each hexadecimal digit in the 32-digit IPv6 address (zero compression and double-colon compression notation cannot be used) becomes a separate level in inverse order in the reverse domain hierarchy. Therefore, the reverse lookup domain name for the address FEC0::2AA:FF:FE3F:2A1C is:

C.1.A.2.F.3.E.F.F.F.0.0.A.A.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.C.E.F.IP6.INT

Avoid integrating PTR resource record support into your DNS infrastructure; the results can be unreliable.

For name-to-address resolution, after the querying node obtains the set of addresses corresponding to the name, that node must determine the best set of addresses to use as the source and destination for outbound packets.

While name-to-address resolution is fairly straightforward in an IPv4-only environment, it becomes more complex in an environment in which IPv4 and IPv6 coexist. In the mixed IPv6/IPv4 scenario, a DNS query can return both IPv4 and IPv6 addresses. The querying host is configured with at least one IPv4 address and, typically, multiple IPv6 addresses. Determining the type of address (IPv4 versus IPv6), and then the scope of the address (for IPv4, public versus private; for IPv6, link-local versus site-local versus global versus coexistence), for both the source and the destination addresses is complex.

Two algorithms, one to select the source address and another to select the destination address, specify default behavior for IPv6 implementations. These algorithms do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms include an optional mechanism that lets you override the default behavior. In dual-stack implementations, the destination address selection algorithm considers both IPv4 and IPv6 addresses, and determines whether it prefers IPv6 addresses over IPv4 addresses, or vice-versa.

For more information about default address selection rules for IPv6, including the source address selection algorithm and the destination address selection algorithm, see the Internet Draft "Default Address Selection for IPv6."

For an introduction to IPv6 and more information about Windows Server 2003 IPv6, see the Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at https://www.microsoft.com/reskit), or see the IPv6 link on the Web Resources page at https://www.microsoft.com/windows/reskits/webresources.