To coexist with an IPv4 infrastructure and to provide eventual migration to an IPv6-only infrastructure, the following mechanisms are used:
The dual IP layer is an implementation of the TCP/IP suite of protocols that includes both an IPv4 Internet layer and an IPv6 Internet layer. This is the mechanism used by IPv6/IPv4 nodes so that communication with both IPv4 and IPv6 nodes can occur. A dual IP layer contains a single implementation of Host-to-Host layer protocols such as TCP and UDP. All upper layer protocols in a dual IP layer implementation can communicate over IPv4, IPv6, or IPv6 tunneled over IPv4.
Figure 11-1 shows a dual IP layer architecture.
Figure 11-1. A dual IP layer architecture
The IPv6 protocol for Windows XP and the Windows .NET Server 2003 family is not a dual IP layer. The IPv6 protocol driver, Tcpip6.sys, contains a separate implementation of TCP and UDP and is sometimes referred to as a dual-stack implementation. Figure 11-2 shows the dual stack architecture for the IPv6 protocol for Windows XP and the Windows .NET Server 2003 family.
Figure 11-2. The dual stack architecture for Windows XPand the Windows .NET Server 2003 family
Although the IPv6 protocol for Windows XP and the Windows .NET Server 2003 family is not a dual IP layer, it functions in the same way as a dual IP layer in terms of providing functionality for coexistence and migration.
IPv6 over IPv4 tunneling is the encapsulation of IPv6 packets with an IPv4 header so that IPv6 packets can be sent over an IPv4 infrastructure. Within the IPv4 header:
Figure 11-3 shows IPv6 over IPv4 tunneling.
Figure 11-3. IPv6 over IPv4 tunneling
For IPv6 over IPv4 tunneling, the IPv6 path MTU for the destination is typically 20 less than the IPv4 path MTU for the destination. However, if the IPv4 path MTU is not stored for each tunnel, there are instances in which the IPv4 packet will need to be fragmented at an intermediate IPv4 router. In this case, an IPv6 over IPv4 tunneled packet must be sent with the Don't Fragment flag in the IPv4 header set to 0.
Here is an example of an ICMPv6 Echo Request message encapsulated with an IPv4 header as displayed by Network Monitor (capture 11_01 in the \NetworkMonitorCaptures folder on the companion CD-ROM):
+ Frame: Base frame properties + ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol IP: Protocol = IPv6 - Ipv6; Packet ID = 65372; Total IP Length =
100; Options = No Options IP: Type of Service = Normal Service IP: Total Length = 100 (0x64) IP: Identification = 65372 (0xFF5C) + IP: Fragmentation Summary = 0 (0x0) IP: Time to Live = 128 (0x80) IP: Protocol = IPv6 - IPv6 IP: Checksum = 60987 (0XEE3B) IP: Source Address = 22.214.171.124 IP: Destination Address = 126.96.36.199 IP6: Proto = ICMP6; Len = 40 IP6: Version = 6 (0x6) IP6: Traffic Class = 0 (0x0) IP6: Flow Label = 0 (0x0) IP6: Payload Length = 40 (0x28) IP6: Next Header = 58 (ICMP6) IP6: Hop Limit = 128 (0x80) IP6: Source Address = fe80::5efe:9d36:8a13 IP6: Destination Address = fe80::5efe:9d3c:8852 IP6: Payload: Number of data bytes remaining = 40 (0x0028) + ICMP6: Echo Request; ID = 0, Seq = 17
Notice that the Protocol field in the IP header indicates an IPv6 packet. In this example, link-local ISATAP addresses are used to tunnel IPv6 packets across an IPv4 infrastructure. For more information about link-local ISATAP addresses, see "ISATAP" in this chapter.
A DNS infrastructure is needed for successful coexistence because of the prevalent use of names (rather than addresses) to refer to network resources. Upgrading the DNS infrastructure consists of populating the DNS servers with AAAA and PTR records to support IPv6 name-to-address and address-to-name resolutions. After the addresses are obtained by using a DNS name query, the sending node must select which addresses are used for communication.
The DNS infrastructure must contain the following resource records (populated either manually or dynamically) for the successful resolution of domain names to addresses:
The DNS infrastructure must contain the following resource records (populated either manually or dynamically) for the successful resolution of addresses to domain names (reverse queries):
For name-to-address resolution, after the querying node obtains the set of addresses corresponding to the name, the node must determine the set of addresses to choose as source and destination for outbound packets.
This is not an issue in today's prevalent IPv4-only environment. However, in an environment in which IPv4 and IPv6 coexist, the set of addresses returned in a DNS query may contain multiple IPv4 and IPv6 addresses. The querying host is configured with at least one IPv4 address and (typically) multiple IPv6 addresses. Deciding which type of address (IPv4 vs. IPv6), and then the scope of the address (public vs. private for IPv4 and link-local vs. site-local vs. global vs. coexistence for IPv6), for both the source and the destination addresses is not an easy task.
Default address selection rules are currently under discussion and are described in the Internet draft titled "Default Address Selection for IPv6."
You can view the default address selection rules for the IPv6 protocol for Windows XP and the Windows .NET Server 2003 family by using the netsh interface ipv6 show prefixpolicy command to display the prefix policy table. You can modify the entries in the prefix policy table by using the netsh interface ipv6 add|set|delete prefixpolicy commands. By default, IPv6 addresses in DNS query responses are preferred over IPv4 addresses.
RFC 2893 defines the following tunneling configurations with which to tunnel IPv6 traffic between IPv6/IPv4 nodes over an IPv4 infrastructure:
IPv6 over IPv4 tunneling describes only an encapsulation of IPv6 packets with an IPv4 header so that IPv6 nodes are reachable across an IPv4 infrastructure. Unlike tunneling for PPTP and the Layer Two Tunneling Protocol (L2TP), there is no exchange of messages for tunnel setup, maintenance, or termination.
In the router-to-router tunneling configuration, two IP infrastructures-IPv4, IPv6, or mixed-are connected by two IPv6/IPv4 routers over an IPv4 infrastructure. The tunnel endpoints span a logical link in the path between the source and destination. The IPv6 over IPv4 tunnel between the two routers acts as a single hop. Routes within each IPv4 or IPv6 infrastructure point to the IPv6/IPv4 router on the edge. For each IPv6/IPv4 router, there is a tunnel interface representing the IPv6 over IPv4 tunnel and routes that use the tunnel interface.
Figure 11-4 shows router-to-router tunneling.
Figure 11-4. Router-to-router tunneling
Examples of this tunneling configuration are:
In the host-to-router tunneling configuration, an IPv6/IPv4 node that resides within an IPv4 infrastructure creates an IPv6 over IPv4 tunnel to reach an IPv6/IPv4 router. The tunnel endpoints span the first segment of the path between the source and destination nodes. The IPv6 over IPv4 tunnel between the IPv6/IPv4 node and the IPv6/IPv4 router acts as a single hop.
On the IPv6/IPv4 node, a tunnel interface representing the IPv6 over IPv4 tunnel is created and a route (typically a default route) is added using the tunnel interface. The IPv6/IPv4 node tunnels the IPv6 packet based on the matching route, the tunnel interface, and the next-hop address of the IPv6/IPv4 router.
In the router-to-host tunneling configuration, an IPv6/IPv4 router creates an IPv6 over IPv4 tunnel across an IPv4 infrastructure to reach an IPv6/IPv4 node. The tunnel endpoints span the last segment of the path between the source and destination nodes. The IPv6 over IPv4 tunnel between the IPv6/IPv4 router and the IPv6/IPv4 node acts as a single hop.
On the IPv6/IPv4 router, a tunnel interface representing the IPv6 over IPv4 tunnel is created and a route (typically a subnet route) is added using the tunnel interface. The IPv6/IPv4 router tunnels the IPv6 packet based on the matching subnet route, the tunnel interface, and the destination address of the IPv6/IPv4 node.
Figure 11-5 shows host-to-router (for traffic traveling from Node A to Node B) and router-to-host (for traffic traveling from Node B to Node A) tunneling.
Figure 11-5. Host-to-router and router-to-host tunneling
Examples of host-to-router and router-to-host tunneling are:
In the host-to-host tunneling configuration, an IPv6/IPv4 node that resides within an IPv4 infrastructure creates an IPv6 over IPv4 tunnel to reach another IPv6/IPv4 node that resides within the same IPv4 infrastructure. The tunnel endpoints span the entire path between the source and destination nodes. The IPv6 over IPv4 tunnel between the IPv6/IPv4 nodes acts as a single hop.
On each IPv6/IPv4 node, an interface representing the IPv6 over IPv4 tunnel is created. Routes might be present to indicate that the destination node is on the same logical subnet defined by the IPv4 infrastructure. Based on the sending interface, the optional route, and the destination address, the sending host tunnels the IPv6 traffic to the destination.
Figure 11-6 shows host-to-host tunneling.
Figure 11-6. Host-to-host tunneling
Examples of this tunneling configuration are:
RFC 2893 defines the following types of tunnels:
A configured tunnel requires manual configuration of the tunnel endpoints. In a configured tunnel, the IPv4 addresses of tunnel endpoints are not encoded in the IPv6 source or destination addresses, nor in the next-hop address of the matching route.
Typically, router-to-router and host-to-router tunneling configurations are configured manually. The tunnel interface configuration, consisting of the IPv4 addresses of the tunnel endpoints, must be specified manually along with static routes that use the tunnel interface.
To manually create configured tunnels for the IPv6 protocol for Windows XP and the Windows .NET Server 2003 family, use the netsh interface ipv6 add v6v4tunnel command.
An automatic tunnel is a tunnel that does not require manual configuration. Tunnel endpoints are determined by the use of logical tunnel interfaces, routes, and source and destination IPv6 addresses.
As defined in RFC 2893, IPv6 Automatic Tunneling is the tunneling that occurs when IPv4-compatible addresses (::w.x.y.z where w.x.y.z is a public IPv4 address) are used. IPv6 Automatic Tunneling is a host-to-host tunnel between two IPv6/IPv4 hosts using IPv4-compatible addresses.
For example, Host A (with the public IPv4 address of 188.8.131.52 and corresponding IPv4-compatible address of ::184.108.40.206) sends traffic to Host B (with the IPv4 address of 220.127.116.11 and corresponding IPv4-compatible address of ::18.104.22.168). The addresses in the IPv6 and IPv4 headers are as listed in Table 11-1.
Table 11-1. An Example of IPv6 AutomaticTunneling Addresses
IPv6 Source Address
IPv6 Destination Address
IPv4 Source Address
IPv4 Destination Address
To test connectivity, use the ping command. For example, Host A would use the following command to ping Host B by using its IPv4-compatible address:
Because IPv4-compatible addresses are defined only for public IPv4 addresses and are not widely used, IPv4-compatible addresses for the IPv6 protocol for Windows XP and the Windows .NET Server 2003 family are disabled by default. Instead, link-local ISATAP addresses can be used to test connectivity of two IPv6/IPv4 nodes across an IPv4 infrastructure. For more information, see "ISATAP" in this chapter.
To enable IPv4-compatible addresses, use the netsh interface ipv6 set state v4compat=enabled command. When enabled for the IPv6 protocol for Windows XP and the Windows .NET Server 2003 family, communication to IPv4-compatible addresses is facilitated by a ::/96 route in the IPv6 routing table that uses the Automatic Tunneling Pseudo-Interface (interface index 2). This route indicates that all addresses with the first 96 bits set to 0 are forwarded to their destination addresses using the Automatic Tunneling Pseudo-Interface. The Automatic Tunneling Pseudo-Interface uses the last 32 bits in the source and destination IPv6 addresses (corresponding to the embedded IPv4 addresses) as the source and destination IPv4 addresses for the outgoing IPv4 packet.
In this book, the term "IPv6 Automatic Tunneling" refers to the use of IPv4-compatible addresses. The term "automatic tunneling" is tunneling that occurs without manual configuration, independent of the type of addressing being used.