Chapter 15 – IPv6 Transition Technologies

Artikel
08/31/2011

Published: April 18, 2006 | Updated: November 06, 2006

Abstract

This chapter describes the mechanisms that aid in the transition of Internet Protocol version 4 (IPv4) to Internet Protocol version 6 (IPv6) and the set of IPv6 transition technologies that are included with Microsoft® Windows Server™ 2003 and Windows® XP. Because the deployment of IPv6-only environments will not replace IPv4-only environments in the near future, network administrators must understand transition technologies that allow the concurrent use of IPv6 and IPv4 in a mixed environment.

For a download of the entire "TCP/IP Fundamentals for Microsoft Windows" online book, which contains a version of this chapter that has been updated for Windows Vista and Windows Server 2008, click here.

Chapter Objectives

After completing this chapter, you will be able to:

List and describe the different types of IPv4 and IPv6 nodes.
Describe the mechanisms for IPv4 to IPv6 transition.
List and describe the types of tunneling configurations.
Define the differences between configured and automatic tunneling.
Describe ISATAP in terms of its purpose, requirements, and addresses.
Describe 6to4 in terms of its purpose, requirements, and addresses.
Describe Teredo in terms of its purpose, requirements, and addresses.
List and describe the steps in migrating from IPv4 to IPv6.

Introduction

Protocol transitions are typically done by installing and configuring the new protocol on all nodes within the network and verifying that all node and router operations work successfully. Although this might be possible in a small or medium sized organization, the challenge of making a rapid protocol transition in a large organization is very difficult. Additionally, given the scope of the Internet, rapid protocol transition is an impossible task.

The designers of IPv6 recognized that the transition from IPv4 to IPv6 would take years and that there might be organizations or hosts within organizations that will continue to use IPv4 indefinitely. Therefore, while migration is the long-term goal, equal consideration must be given to the interim coexistence of IPv4 and IPv6 nodes.

RFC 2893 defines the following node types:

IPv4-only node

A node that uses only IPv4 and has only IPv4 addresses assigned. This node type does not support IPv6. Most hosts and routers installed today are IPv4-only nodes.
IPv6-only node

A node that uses only IPv6 and has only IPv6 addresses assigned. This node type is only able to communicate with IPv6 nodes and applications. This type of node is not common today, but will become more prevalent as smaller devices such as cellular phones and handheld computing devices use only the IPv6 protocol.
IPv6/IPv4 node

A node that uses both IPv4 and IPv6.
IPv4 node

A node that uses IPv4. An IPv4 node can be an IPv4-only node or an IPv6/IPv4 node.
IPv6 node

A node that uses IPv6. An IPv6 node can be an IPv6-only node or an IPv6/IPv4 node.

For coexistence to occur, all nodes (IPv4 or IPv6 nodes) can communicate using an IPv4 infrastructure, an IPv6 infrastructure, or an infrastructure that is a combination of IPv4 and IPv6. True migration is achieved when all IPv4 nodes are converted to IPv6-only nodes. However, for the foreseeable future, practical migration is achieved when as many IPv4-only nodes as possible are converted to IPv6-only nodes. IPv4-only nodes can communicate with IPv6-only nodes through an IPv4-to-IPv6 proxy or translation gateway.

IPv6 Transition Mechanisms

To coexist with an IPv4 infrastructure and to provide an eventual transition to an IPv6-only infrastructure, the following mechanisms are used:

Dual stack or dual IP layer architectures
DNS infrastructure
IPv6 over IPv4 tunneling

Dual Stack or Dual IP Layer Architectures

IPv6/IPv4 hosts can be based on a dual stack or dual IP layer architecture. In either architecture, the following types of traffic are possible:

IPv4
IPv6
IPv6 traffic sent with an IPv4 header (IPv6 over IPv4 tunneling)

Figure 15-1 shows the dual stack architecture.

Figure 15-1 The dual stack architecture

Figure 15-1 The dual stack architecture

The IPv6 protocol for Windows Server 2003 and Windows XP uses the dual stack architecture. The IPv6 protocol driver in Windows Server 2003 and Windows XP, Tcpip6.sys, contains a separate implementation of TCP and UDP.

A dual IP layer contains a single implementation of Transport layer protocols such as TCP and UDP. Figure 15-2 shows a dual IP layer architecture.

Figure 15-2 The dual IP layer architecture

Figure 15-2 The dual IP layer architecture

Both dual stack and dual IP layer architecture provide the same functionality for IPv6 transition.

DNS Infrastructure

A Domain Name System (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 records to support IPv6 name-to-address and address-to-name resolutions.

For name-to-address resolutions, the DNS infrastructure must be able to store AAAA records for IPv6 nodes that are populated either manually or dynamically.

For address-to-name resolutions (reverse queries), the DNS infrastructure must be able to store PTR records in the IP6.ARPA domain for IPv6 nodes, populated either manually or dynamically.

Address Selection Rules

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 outgoing packets.

This is not an issue in today’s prevalent IPv4-only environments. However, in an environment in which IPv4 and IPv6 coexist, the set of addresses returned in a DNS query may contain both IPv4 and IPv6 addresses. The typical querying IPv6/IPv4 host is configured with at least one IPv4 address and multiple IPv6 addresses. Deciding which type of address (IPv4 vs. IPv6) and, for IPv6 addresses, a source and the destination address that is matched in scope and purpose is not an easy task.

For more information, see Source and Destination Address Selection for IPv6. Default address selection rules are defined in RFC 3484.

The default address selection rules for the IPv6 protocol for Windows Server 2003 and Windows XP are stored in the prefix policy table, which you can view with the netsh interface ipv6 show prefixpolicy command. You can modify the entries in the prefix policy table using the netsh interface ipv6 add|set|delete prefixpolicy commands. By default, IPv6 addresses in DNS query responses are preferred over IPv4 addresses.

IPv6 Over IPv4 Tunneling

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:

The IPv4 Protocol field is set to 41 to indicate an encapsulated IPv6 packet.
The Source and Destination fields are set to IPv4 addresses of the tunnel endpoints. The tunnel endpoints are either manually configured or are automatically derived from the sending tunnel interface and the next-hop address of the matching route for the destination IPv6 address in the tunneled packet.

Figure 15-3 shows IPv6 over IPv4 tunneling.

Figure 15-3 IPv6 over IPv4 tunneling

Note: IPv6 over IPv4 tunneling only describes an encapsulation of IPv6 packets with an IPv4 header so that IPv6 nodes are reachable across an IPv4 infrastructure. Unlike tunneling for the Point-to-Point Tunneling Protocol (PPTP) and Layer Two Tunneling Protocol (L2TP), there is no exchange of messages for tunnel setup, maintenance, or termination. Additionally, IPv6 over IPv4 tunneling does not provide security for tunneled IPv6 packets. For more information about PPTP and L2TP, see Chapter 14, "Virtual Private Networking.”

Tunneling Configurations

RFC 2893 defines the following tunneling configurations with which to tunnel IPv6 traffic between IPv6/IPv4 nodes over an IPv4 infrastructure:

Router-to-router

In the router-to-router tunneling configuration, two IPv6/IPv4 routers connect two IPv6-capable infrastructures 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 IPv6-capable infrastructure point to the IPv6/IPv4 router on the edge.
Host-to-router or router-to-host

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.

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 node and destination node. The IPv6 over IPv4 tunnel between the IPv6/IPv4 router and the IPv6/IPv4 node acts as a single hop.
Host-to-host

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. IPv6 routes are added that use the tunnel interface. Based on the sending tunnel interface, the route, and the destination address, the sending node tunnels the IPv6 traffic to the next hop or to the destination. The IPv4 address of the tunnel endpoint can be manually configured or automatically determined from the next-hop address for the destination and the tunnel interface.

Types of Tunnels

RFC 2893 defines the following types of tunnels:

Configured

A configured tunnel requires manual configuration of tunnel endpoints. In a configured tunnel, the IPv4 addresses of tunnel endpoints are not derived from the next-hop address corresponding to the destination address.

Typically, router-to-router tunneling configurations are manually configured. The tunnel interface configuration, consisting of the IPv4 addresses of the tunnel endpoints, must be manually specified along with routes that use the tunnel interface.

To manually create configured tunnels for the IPv6 protocol for Windows Server 2003 and Windows XP, use the netsh interface ipv6 add v6v4tunnel command.
Automatic

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 destination IPv6 addresses.

The IPv6 protocol for Windows Server 2003 and Windows XP supports the following automatic tunneling technologies:

Intra-site Automatic Tunnel Addressing Protocol (ISATAP)
6to4
Teredo

The IPv6 protocol for Windows Server 2003 and Windows XP also supports automatic tunneling using IPv6-compatible addresses and 6over4. For more information, see IPv6 Transition Technologies.

ISATAP

ISATAP is an address assignment and host-to-host, host-to-router, and router-to-host automatic tunneling technology that provides unicast IPv6 connectivity between IPv6 hosts across an IPv4 intranet. ISATAP is described in RFC 4214. ISATAP hosts do not require any manual configuration and create ISATAP addresses using standard address autoconfiguration mechanisms.

ISATAP can be used for communication between IPv6/IPv4 nodes on an IPv4 intranet. ISATAP addresses use the locally administered interface identifier ::0:5EFE:w.x.y.z, in which w.x.y.z is a unicast public or private IPv4 address. An example of a link-local ISATAP address is FE80::5EFE:131.107.4.92. The ISATAP interface identifier can be combined with any 64-bit subnet prefix that is valid for IPv6 unicast addresses, including global, site-local, and local prefixes.

By default, the IPv6 protocol for Windows Server 2003 and Windows XP automatically configures the link-local ISATAP address of FE80::5EFE:w.x.y.z on the Automatic Tunneling Pseudo-Interface (the ISATAP interface with an interface index 2) for each IPv4 address that is assigned to the node. This link-local ISATAP address allows two hosts to communicate over an IPv4 network by using each other's link-local ISATAP address.

For example, Host A is configured with the IPv4 address of 10.40.1.29 and Host B is configured with the IPv4 address of 192.168.41.30. When the IPv6 protocol for Widows XP and Windows Server 2003 is started, Host A automatically configures the ISATAP address of FE80::5EFE:10.40.1.29 and Host B automatically configures the ISATAP address of FE80::5EFE:192.168.41.30. Figure 15-4 shows this example configuration.

Figure 15-4 An example ISATAP configuration

When Host A sends IPv6 traffic to Host B by using Host B's link-local ISATAP address, the source and destination addresses for the IPv6 and IPv4 headers are as listed in Table 15-1.

Table 15-1 Example of IPv4 and IPv6 addresses for ISATAP

Field

Value

IPv6 Source Address

FE80::5EFE:10.40.1.29

IPv6 Destination Address

FE80::5EFE:192.168.41.30

IPv4 Source Address

10.40.1.29

IPv4 Destination Address

192.168.41.30

To test connectivity, a user on Host A can use the following command to ping Host B with its link-local ISATAP address:

ping FE80::5EFE:192.168.41.30%2

Because the destination of the ping command is a link-local address, the %ZoneID portion of the command must be used to specify the interface index of the interface from which traffic is sent. In this case, %2 specifies interface 2, which is the interface index assigned to the Automatic Tunneling Pseudo-Interface on Host A. The ISATAP interface uses the last 32-bits of the destination IPv6 address as the destination IPv4 address and the locally assigned IPv4 address as the source IPv4 address.

Using an ISATAP Router

The use of link-local ISATAP addresses allows IPv6/IPv4 hosts on the same logical ISATAP subnet to communicate with each other, but link-local addresses are not registered in DNS and cannot be used to communicate with other IPv6 hosts on other subnets. To obtain additional subnet prefixes, ISATAP hosts must perform router discovery and address autoconfiguration with an ISATAP router. To communicate outside the logical subnet using non-link-local ISATAP-based addresses, ISATAP hosts must tunnel their packets to an ISATAP router. Figure 15-5 shows an ISATAP router.

Figure 15-5 An ISATAP router

An ISATAP router is an IPv4/IPv6 router that performs the following:

Advertises subnet prefixes assigned to the logical ISATAP subnet on which ISATAP hosts are located. ISATAP hosts use the advertised subnet prefixes to configure global ISATAP addresses.
Forwards packets between ISATAP hosts and hosts on other IPv6 subnets (optional).

The other subnets can be subnets in an IPv6-capable portion of the organization's network or the IPv6 Internet.

When an ISATAP host receives a router advertisement from an ISATAP router, it performs address autoconfiguration and configures additional IPv6 addresses on the ISATAP interface with the interface ID ::5EFE:w.x.y.z.

If the ISATAP router advertises itself as a default router, the ISATAP host adds a default route (::/0) using the ISATAP interface with the next-hop address set to the link-local ISATAP address of the ISATAP router. When an ISATAP host sends packets destined to locations outside the logical ISATAP subnet, they are tunneled to the IPv4 address of the ISATAP router. The ISATAP router then forwards the IPv6 packet.

The IPv6 protocol for Windows Server 2003 and Windows XP obtains the IPv4 address of the ISATAP router through one of the following:

The successful resolution of the name “ISATAP” to an IPv4 address.
The netsh interface ipv6 isatap set router command.

Resolving the ISATAP Name

When the IPv6 protocol for Windows Server 2003 and Windows XP starts, it attempts to resolve the name “ISATAP” to an IPv4 address using the following TCP/IP name resolution techniques:

Check the local host name.
Check the DNS client resolver cache, which includes the entries in the Hosts file in the SystemRoot\system32\drivers\etc folder.
Form a fully qualified domain name and sending a DNS name query. For example, if the computer running Windows Server 2003 or Windows XP is a member of the example.com domain (and example.com is the only domain name in the search list), the computer sends a DNS query to resolve the name isatap.example.com.
Convert the ISATAP name into the NetBIOS name "
```
ISATAP         <00>
```

" and check the NetBIOS name cache.

Send a NetBIOS name query to the configured Windows Internet Name Service (WINS) servers.
Send NetBIOS broadcasts.
Check the Lmhosts file in the SystemRoot\system32\drivers\etc folder.

If successful, the host sends an IPv4-encapsulated Router Solicitation message to the ISATAP router. The ISATAP router responds with an IPv4-encapsulated Router Advertisement message containing subnet prefixes to use for autoconfiguration of ISATAP-based addresses and, optionally, advertising itself as a default router.

To ensure that at least one of these attempts is successful, you can do one or more of the following as needed:

If the ISATAP router is a computer running Windows Server 2003 or Windows XP, name the computer ISATAP and it will automatically register the appropriate records in DNS and WINS.
Manually create an address (A) record for the name "ISATAP" in the appropriate domains in DNS. For example, for the example.com domain, create an A record for isatap.example.com with the IPv4 address of the ISATAP router.
Manually create a static WINS record in WINS for the NetBIOS name "ISATAP <00>".
Add the following entry to the Hosts file of the computers that need to resolve the name ISATAP:

IPv4_Address ISATAP
Add the following entry to the Lmhosts file of the computers that need to resolve the name ISATAP:

IPv4_Address ISATAP

Using the netsh interface ipv6 isatap set router Command

Although the automatic resolution of the ISATAP name is the recommended method for configuring the IPv4 address of the ISATAP router, you can manually configure the name or IPv4 address of the ISATAP router with the netsh interface ipv6 isatap set router command. The syntax of this command is:

netsh interface ipv6 isatap set router Address_Or_Name

Address_Or_Name is the name or IPv4 address of the ISATAP router's intranet interface. For example, if the ISATAP router's IPv4 address is 192.168.39.1, the command is:

netsh interface ipv6 isatap set router 192.168.39.1

Setting up an ISATAP Router

A computer running Windows Server 2003 or Windows XP can be configured as an ISATAP router. Assuming that the router is already configured to forward IPv6 traffic on its LAN interfaces and has a default route that is configured to be published, the additional commands that need to be issued on the router are:

netsh interface ipv6 set interface "Automatic Tunneling Pseudo-Interface" forwarding=enabled advertise=enabled

netsh interface ipv6 add route Subnet_Prefix / Prefix_Length "Automatic Tunneling Pseudo-Interface" publish=yes

The first command enables forwarding and advertising on the Automatic Tunneling Pseudo-Interface (the ISATAP interface).

The second command enables the advertisement of a specific subnet prefix (Subnet_Prefix/Prefix_Length) over the Automatic Tunneling Pseudo-Interface. Use this command one or multiple times to advertise as many subnet prefixes as you need. All the subnet prefixes configured using this command are included in the Router Advertisement message sent back to the ISATAP host.

If the router is not named ISATAP or the name ISATAP is not resolved to the IPv4 address of the router's intranet interface, you also need to issue the following command on the router:

netsh interface ipv6 isatap set router Address_Or_Name

6to4

6to4 is an address assignment and router-to-router automatic tunneling technology that provides unicast IPv6 connectivity between IPv6 sites and hosts across the IPv4 Internet. 6to4 uses the global address prefix 2002:WWXX:YYZZ::/48. WWXX:YYZZ is the colon-hexadecimal representation of a public IPv4 address (w.x.y.z) assigned to a site or host. The full 6to4 address is:

2002:WWXX:YYZZ:Subnet_ID:Interface_ID

6to4 is described in RFC 3056, which defines the following terms:

6to4 host

Any IPv6 host that is configured with at least one 6to4 address (a global address with the 2002::/16 prefix). 6to4 hosts do not require any manual configuration and create 6to4 addresses using standard address autoconfiguration mechanisms.
6to4 router

An IPv6/IPv4 router that supports the use of a 6to4 tunnel interface and is typically used to forward 6to4-addressed traffic between the 6to4 hosts within a site and either other 6to4 routers or the IPv6 Internet through a 6to4 relay router.
6to4 relay router

An IPv6/IPv4 router that forwards 6to4-addressed traffic between 6to4 routers on the IPv4 Internet and hosts on the IPv6 Internet.

Figure 15-6 shows 6to4 components.

Figure 15-6 6to4 components

Within a site, local IPv6 routers advertise 2002:WWXX:YYZZ:Subnet_ID::/64 subnet prefixes so that hosts autoconfigure 6to4 addresses. IPv6 routers within the site deliver traffic between 6to4 hosts. Hosts on individual subnets are automatically configured with a 64-bit subnet route for direct delivery to neighbors and a default route with the next-hop address of the advertising router. IPv6 traffic that does not match any of the subnet prefixes used within the site is forwarded to a 6to4 router on the site border. The 6to4 router on the site border has a 2002::/16 route that is used to forward traffic to other 6to4 sites and a default route (::/0) that is used to forward traffic to a 6to4 relay router.

In the example network shown in Figure 15-6, Host A and Host B can communicate with each other because of a default route using the next-hop address of the 6to4 router in Site 1. When Host A communicates with Host C in another site, Host A sends the traffic to the 6to4 router in Site 1 as IPv6 packets. The 6to4 router in Site 1, using the 2002::/16 route in its routing table and the 6to4 tunnel interface, encapsulates the traffic with an IPv4 header and tunnels it to the 6to4 router in Site 2. The 6to4 router in Site 2 receives the tunneled traffic, removes the IPv4 header and, using the subnet prefix route in its routing table, forwards the IPv6 packet to Host C.

For example, Host A resides on subnet 1 within Site 1 that uses the public IPv4 address of 157.60.91.123. Host C resides on subnet 2 within Site 2 that uses the public IPv4 address of 131.107.210.49. Table 2 lists the addresses in the IPv4 and IPv6 headers when the 6to4 router in Site 1 sends the IPv4-encapsulated IPv6 packet to the 6to4 router in Site 2.

Table 15-2 Example 6to4 addresses

Field

Value

IPv6 Source Address

2002:9D3C:5B7B:1::1

IPv6 Destination Address

2002:836B:D231:2::3

IPv4 Source Address

157.60.91.123

IPv4 Destination Address

131.107.210.49

When you use 6to4 hosts, an IPv6 routing infrastructure within a site, a 6to4 router at the site boundary, and a 6to4 relay router, the following types of communication are possible:

A 6to4 host can communicate with other 6to4 hosts within the same site.

This type of communication is available by using the IPv6 routing infrastructure within the site, which provides reachability to all hosts within the site. In Figure 15-6, this is the communication between Host A and Host B.
A 6to4 host can communicate with 6to4 hosts in other sites across the IPv4 Internet.

This type of communication occurs when a 6to4 host forwards IPv6 traffic that is destined to a 6to4 host in another site to its local site 6to4 router. The local site 6to4 router tunnels the IPv6 traffic to the 6to4 router at the destination site on the IPv4 Internet. The 6to4 router at the destination site removes the IPv4 header and forwards the IPv6 packet to the appropriate 6to4 host by using the IPv6 routing infrastructure of the destination site. In Figure 15-6, this is the communication between Host A and Host C.
A 6to4 host can communicate with hosts on the IPv6 Internet.

This type of communication occurs when a 6to4 host forwards IPv6 traffic that is destined for an IPv6 Internet host to its local site 6to4 router. The local site 6to4 router tunnels the IPv6 traffic to a 6to4 relay router that is connected to both the IPv4 Internet and the IPv6 Internet. The 6to4 relay router removes the IPv4 header and forwards the IPv6 packet to the appropriate IPv6 Internet host by using the IPv6 routing infrastructure of the IPv6 Internet. In Figure 15-6, this is the communication between Host A and Host D.

All of these types of communication use IPv6 traffic without the requirement of obtaining either a direct connection to the IPv6 Internet or a global address prefix from an Internet service provider (ISP).

6to4 Support in Windows Server 2003 and Windows XP

The 6to4 component of the IPv6 protocol for Windows Server 2003 and Windows XP provides 6to4 tunneling support. If there is a public IPv4 address assigned to an interface on the host and a global prefix is not received in a router advertisement, the 6to4 component:

Automatically configures 6to4 addresses on the 6to4 Tunneling Pseudo-Interface for all public IPv4 addresses that are assigned to interfaces on the computer.
Automatically creates a 2002::/16 route that forwards all 6to4 traffic with the 6to4 Tunneling Pseudo-Interface. All traffic forwarded by this host to 6to4 destinations is encapsulated with an IPv4 header.
Automatically performs a DNS query to obtain the IPv4 address of a 6to4 relay router on the IPv4 Internet. By default, the 6to4 component queries for the name 6to4.ipv6.microsoft.com. You can use the netsh interface ipv6 6to4 set relay command to specify the DNS name to query. If the query is successful, a default route is added using the 6to4 Tunneling Pseudo-Interface and the next-hop address is set to the 6to4 address of the 6to4 relay router.

The results of the 6to4 component autoconfiguration vary depending on the configuration of the host. Figure 15-7 shows how 6to4 is configured for different types of hosts running Windows Server 2003 or Windows XP (except IPv6 host D).

Figure 15-7 6to4 for Windows hosts

For a host that is assigned a private IPv4 address or receives a router advertisement for a global prefix, there are no 6to4 addresses assigned to the 6to4 Tunneling Pseudo-Interface. Addresses and routes are autoconfigured based on the received router advertisement. This configuration corresponds to Host A, Host B, and Host C in Figure 15-7.

A host that is assigned a public IPv4 address and does not receive a router advertisement for a global prefix automatically configures a 6to4 address of the form 2002:WWXX:YYZZ::WWXX:YYZZ is on the 6to4 Tunneling Pseudo-Interface. The host adds a 2002::/16 route using the 6to4 Tunneling Pseudo-Interface and, if the DNS query for the 6to4 relay router is successful, adds a default route using the 6to4 address of the 6to4 relay router as the next hop. This type of host is a 6to4 host and performs its own tunneling like a 6to4 router. This configuration corresponds to 6to4 host/router E in Figure 15-7, a host that is directly connected to the IPv4 Internet.

A computer running Windows Server 2003 or Windows XP can automatically configure itself as a 6to4 router by utilizing the configuration of the Internet Connection Sharing (ICS) feature. This configuration corresponds to 6to4 router 1 in Figure 15-7.

If ICS is enabled on an interface that is assigned a public IPv4 address, the 6to4 component automatically:

Enables IPv6 forwarding on the 6to4 Tunneling Pseudo-Interface and the private interface.

The private interface is connected to a single-subnet intranet and uses private IPv4 addresses from the 192.168.0.0/24 prefix.
Sends Router Advertisement messages on the private interface.

The router advertisements advertise the ICS computer as a default router and contain a 6to4 subnet prefix that is based on the public IPv4 address assigned to the public interface. The Subnet ID in the 6to4 subnet prefix is set to the interface index of the interface on which the advertisements are sent.

For example, for an ICS computer using the public IPv4 address of 131.107.23.89 and interface 5 as the interface index of the private interface, the advertised prefix would be 2002:836B:1759:5::/64. Private hosts receiving this router advertisement would create global addresses through normal address autoconfiguration and add a 2002:836B:1759:5::/64 route for the local subnet and a default route with a next-hop address of the link-local address of the ICS computer's private interface. Private hosts can communicate with each other on the same subnet using the 2002:836B:1759:5::/64 route. For all other destinations to other 6to4 sites or the IPv6 Internet, the 6to4 hosts forward the IPv6 packets to the ICS computer using the default route.

For traffic to other 6to4 sites, the ICS computer uses its 2002::/16 route and encapsulates the IPv6 traffic with an IPv4 header and sends it across the IPv4 Internet to another 6to4 router. For all other IPv6 traffic, the ICS computer uses its default route and encapsulates the IPv6 traffic with an IPv4 header and sends it across the IPv4 Internet to a 6to4 relay router.

To manually configure a computer running Windows Server 2003 or Windows XP as a 6to4 router, you must do the following:

Ensure that the 6to4 router computer has a public address assigned to its Internet interface and has not received a Router Advertisement message from either an IPv6 router on an attached subnet or an ISATAP router. If this is the case, the 6to4 component automatically adds a 2002::/16 route to the routing table that uses the 6to4 Tunneling Pseudo-Interface and adds a default route that points to a 6to4 relay router on the IPv4 Internet.
Enable forwarding and advertising on the interfaces attached to your intranet. You can do this with the following command:

netsh interface ipv6 set interface Interface_Name_Or_Index forwarding=enabled advertise=enabled
Enable forwarding on the 6to4 Pseudo-Interface. You can do this with the following command:

netsh interface ipv6 set interface "6to4 Tunneling Pseudo-Interface" forwarding=enabled
Add routes for 6to4 prefixes to the interfaces attached to your intranet and configure them to be published. You can do this with the following command:

netsh interface ipv6 add route 2002: WWXX : YYZZ : Subnet_ID ::/64 Interface_Name_Or_Index publish=yes

WWXX:YYZZ is the colon-hexadecimal notation for w.x.y.z, the public IPv4 address that is assigned to the interface that is attached to the Internet. Subnet_ID identifies an individual subnet within the 6to4 site.

For example, a computer has three LAN interfaces with the following configuration:

Local Area Connection is attached to the IPv4 Internet and is assigned the public IPv4 address 131.107.0.1.
Local Area Connection 2 is an intranet interface that is using interface index 5.
Local Area Connection 3 is an intranet interface that is using interface index 6.

To configure this computer as a 6to4 router), run the following commands:

netsh interface ipv6 set interface "Local Area Connection 2" forwarding=enabled
advertise=enabled netsh interface ipv6 set interface "Local Area Connection 3"
forwarding=enabled advertise=enabled netsh interface ipv6 set interface "6to4
Tunneling Pseudo-Interface" forwarding=enabled netsh interface ipv6 add route
2002:836b:1:5::/64 "Local Area Connection 2" publish=yes netsh interface ipv6 add
route 2002:836b:1:6::/64 "Local Area Connection 3" publish=yes

For this example, the subnet prefix 2002:836b:1:5::/64 is advertised over Local Area Connection 2 and the subnet prefix 2002:836b:1:6::/64 is advertised over Local Area Connection 3 (836b:1 is the hexadecimal colon notation for the public IPv4 address 131.107.0.1). By convention, the subnet ID is set to the interface index of the interface over which the prefix is advertised. You can specify any subnet ID you want (from 0 to 0xffff).

Teredo

Teredo, also known as IPv4 network address translator (NAT) traversal (NAT-T) for IPv6, provides address assignment and host-to-host automatic tunneling for unicast IPv6 connectivity across the IPv4 Internet when IPv6/IPv4 hosts are located behind one or multiple IPv4 NATs. Teredo is defined in RFC 4380. To traverse IPv4 NATs, IPv6 packets are sent as IPv4-based User Datagram Protocol (UDP) messages.

6to4 provides a similar function as Teredo. However, 6to4 router support is required in the edge device that is connected to the Internet. 6to4 router functionality is not widely supported by IPv4 NATs. Even if the edge NAT were 6to4-capable, 6to4 would still not work for configurations in which there are multiple NATs between a site and the Internet.

Teredo resolves the issues of the lack of 6to4 functionality in modern-day NATs or multi-layered NAT configurations by tunneling IPv6 packets between the hosts within the sites. In contrast, 6to4 uses tunneling from the edge device. Tunneling from the hosts presents another issue for NATs: IPv4-encapsulated IPv6 packets are sent with the Protocol field in the IPv4 header set to 41. Most NATs only translate TCP or UDP traffic and must either be manually configured to translate other protocols or have an installed NAT editor that handles the translation. Because Protocol 41 translation is not a common feature of NATs, IPv4-encapsulated IPv6 traffic will not flow through typical NATs. Therefore, the IPv6 packet is encapsulated as an IPv4 UDP message, containing both IPv4 and UDP headers. UDP messages can be translated by most NATs and can traverse multiple layers of NATs.

Teredo is designed as a last resort transition technology for IPv6 connectivity. If native IPv6, 6to4, or ISATAP connectivity is present between communicating nodes, Teredo is not used. As more IPv4 NATs are upgraded to support 6to4 and IPv6 connectivity becomes ubiquitous, Teredo will be used less and less, until eventually it is not used at all.

Teredo in Windows Server 2003 Service Pack 1, Windows XP SP2, and Windows XP SP1 with the Advanced Networking Pack for Windows XP works only over cone and restricted NATs.

A cone NAT stores a mapping between an internal (private) address and port number and an external (public) address and port number. After the NAT translation table entry is in place, incoming traffic from the Internet to the external address and port number is allowed from any source address and port number.
A restricted NAT stores a mapping between an internal address and port number and an external address and port number, for either specific external addresses or specific external addresses and port numbers. An incoming packet from the Internet that does not match a NAT translation table entry for both the external destination address and port number and a specific source external address or port number is silently discarded.

There is an additional type of NAT, known as a symmetric NAT, which maps the same internal address and port number to different external addresses and ports, depending on the external destination address (for outgoing traffic). Teredo in Windows Server 2003 and Windows XP does not support symmetric NATs.

Teredo Components

Figure 15-8 shows the set of components for Teredo connectivity.

Figure 15-8 Teredo components

The components of Teredo are the following:

Teredo client

An IPv6/IPv4 node that supports a Teredo tunneling interface through which packets are tunneled to either other Teredo clients or nodes on the IPv6 Internet through a Teredo relay.
Teredo server

An IPv6/IPv4 node that is connected to both the IPv4 Internet and the IPv6 Internet. The role of the Teredo server is to assist in the initial configuration of Teredo clients and to facilitate the initial communication between either Teredo clients in different sites or between Teredo clients and IPv6-only hosts on the IPv6 Internet.
Teredo relay

An IPv6/IPv4 router that can forward packets between Teredo clients on the IPv4 Internet and IPv6-only hosts on the IPv6 Internet.
Teredo host-specific relay

An IPv6/IPv4 node that has an interface and connectivity to both the IPv4 Internet and the IPv6 Internet and can communicate directly with Teredo clients over the IPv4 Internet, without the need for an intermediate Teredo relay. The connectivity to the IPv4 Internet can be through a public IPv4 address or through a private IPv4 address and a neighboring NAT. The connectivity to the IPv6 Internet can be through a direct connection to the IPv6 Internet or through an IPv6 transition technology such as 6to4.

Windows Server 2003 with Service Pack 1, Windows XP with SP2, and Windows XP with SP1 and the Advanced Networking Pack for Windows XP include Teredo client and Teredo host-specific relay functionality. The Teredo host-specific relay functionality is automatically enabled if a global IPv6 address has been assigned. A global address can be assigned from a Router Advertisement message that is received from a native IPv6 router, an ISATAP router, or a 6to4 router. If there is no global address configured, Teredo client functionality is enabled.

Teredo Addresses

Teredo addresses have the format shown in Figure 15-9.

Figure 15-9 Teredo addresses

A Teredo address consists of the following:

Teredo prefix

The first 32 bits are for the Teredo prefix, which is the same for all Teredo addresses. The 3FFE:831F::/32 prefix was initially used for the Windows XP and Windows Server 2003 implementation of Teredo. The address space of 2001::/32 has been reserved for Teredo by IANA. Computers running Windows XP or Windows Server 2003 will use the new 2001::/32 prefix when updated with Microsoft Security Bulletin MS06-064.
Teredo server IPv4 address

The next 32 bits contain the IPv4 public address of the Teredo server that assisted in the configuration of this Teredo address.
Flags

The next 16 bits are reserved for Teredo flags. The only defined flag is the high-order bit known as the Cone flag. The Cone flag is set when the Teredo client detects that it is located behind a cone NAT.
Obscured external port

The next 16 bits store an obscured version of the external UDP port that corresponds to all Teredo traffic for this Teredo client. When the Teredo client sends its initial packet to a Teredo server, the source UDP port of the packet is mapped by the NAT to a different, external UDP port. All Teredo traffic for the host uses the same external, mapped UDP port.

The external port is obscured by exclusive ORing (XORing) the external port with 0xFFFF. For example, the obscured version of the external port 5000 in hexadecimal format is EC77 (5000 equals 0x1388, and 0x1388 XOR 0xFFFF = 0xEC77). Obscuring the external port prevents a NAT from translating the external port contained within the payload of the packets that are being forwarded.
Obscured external address

The last 32 bits store an obscured version of the external IPv4 address that corresponds to all Teredo traffic for this Teredo client. Just like the external port, when the Teredo client sends its initial packet to a Teredo server, the source IP address of the packet is mapped by the NAT to a different, external address.

The external address is obscured by XORing the external address with 0xFFFFFFFF. For example, the obscured version of the public IPv4 address 131.107.0.1 in colon-hexadecimal format is 7C94:FFFE (131.107.0.1 equals 0x836B0001, and 0x836B0001 XOR 0xFFFFFFFF = 0x7C94FFFE). Obscuring the external address prevents NATs from translating the external address contained within the payload of the packets that are being forwarded.

How Teredo Works

For two Windows-based Teredo clients, the most crucial Teredo processes are those used for initial configuration and communication with a peer in a different site.

Initial Configuration

Teredo clients perform initial configuration by sending a series of Router Solicitation messages to multiple Teredo servers. Windows-based Teredo clients obtain the IPv4 addresses of Teredo servers on the IPv4 Internet by performing a DNS query the name teredo.ipv6.microsoft.com. You can use the netsh interface ipv6 set teredo servername= Address_Or_Name command to specify the DNS name to query. The Teredo client uses the router advertisements to derive a Teredo address and determine whether the client is behind a cone, restricted, or symmetric NAT. You can see what type of NAT the Teredo client has discovered from the display of the netsh interface ipv6 show teredo command.

Based on the received Router Advertisement messages, the Teredo client constructs its Teredo address from the following:

The first 64 bits are set to the value included in the Prefix Information option of the received router advertisement. The 64-bit prefix advertised by the Teredo server consists of the Teredo prefix and the public IPv4 address of the Teredo server (32 bits).
The next 16 bits are either 0x8000 (cone NAT) or 0x0 (restricted NAT).
The next 16 bits are set to the obscured external UDP port number for Teredo traffic.
The last 32 bits are set to the obscured external IPv4 address for Teredo traffic.

The external IPv4 address and UDP port number for Teredo traffic are included in an extra Teredo header in the router advertisements sent by the Teredo servers.

Initial Communication Between Two Teredo Clients in Different Sites

The set of packets sent during the initial communication between Teredo clients located in different sites depends on whether the Teredo clients are located behind cone NATs or restricted NATs.

When a Teredo client is located behind a cone NAT, the NAT translation table entries for Teredo traffic for the Teredo client allows traffic from any source IP address or source UDP port. Therefore, a Teredo client can send packets directly to another Teredo client behind a cone NAT without having to send additional packets.

When a Teredo client is located behind a restricted NAT, the NAT translation table entries for Teredo traffic for the Teredo client is only allowed from specific IPv4 addresses and UDP port numbers. Therefore, when a Teredo client is located behind a restricted NAT, an initiating Teredo client must first send packets to create a source-specific NAT mapping that allows the initiating Teredo client's traffic to traverse the restricted NAT, prior to sending the initial communication packet.

Figure 15-10 shows the initial communication process between Teredo clients that are located in different sites when both sites are using restricted NATs.

Figure 15-10 Process for sending an initial packet when two Teredo clients are located behind a restricted NAT

To send an initial communication packet from Teredo Client A to Teredo Client B, the following process is used:

Teredo Client A sends a bubble packet directly to Teredo Client B. A bubble packet contains no data and is used to create or maintain NAT mappings. Because Teredo Client B is behind a restricted NAT, Teredo traffic from an arbitrary source IPv4 address and UDP port number is not allowed unless there is a source-specific NAT translation table entry. Assuming that there is none, the restricted NAT silently discards the bubble packet. However, when the restricted NAT for Teredo Client A forwarded the bubble packet, it created a source-specific NAT translation table entry that will allow future packets sent from Teredo Client B to be forwarded to Teredo Client A.
Teredo Client A sends a bubble packet to Teredo Client B through Teredo Server 2 (Teredo Client B's Teredo server). The IPv4 destination address in the bubble packet is set to the IPv4 address of Teredo Server 2, which Teredo Client A determines from the third and fourth blocks of Teredo Client B's Teredo address.
Teredo Server 2 forwards the bubble packet to Teredo Client B. The restricted NAT for Teredo Client B forwards the packet because there is an existing source-specific mapping for Teredo traffic from Teredo Server 2 (established by the initial configuration of Teredo Client B).
Teredo Client B responds to the bubble packet received from Teredo Client A with its own bubble packet, which is sent directly to Teredo Client A. Because Teredo Client A's restricted NAT has a source-specific mapping for Teredo traffic from Teredo Client B (as established by the initial bubble packet sent from Teredo Client A in step 1), it forwards the bubble packet to Teredo Client A.
Upon receipt of the bubble packet from Teredo Client B, Teredo Client A determines that source-specific NAT mappings exist for both NATs. Teredo Client A sends an initial communication packet directly to Teredo Client B. Subsequent packets are sent directly between Teredo Client A and Teredo Client B.

This process occurs transparently to the users at Teredo Client A and Teredo Client B.

There are additional initial communication processes for when the destination for the initial packet is on the same link, on the IPv6 Internet, or with a Teredo host-specific relay. For more information, see Teredo Overview.

Migrating to IPv6

The migration of IPv4 to IPv6 will be a long process. As a general guideline, to migrate from IPv4 to IPv6, you must perform the following steps:

Upgrade your applications to be independent of IPv4 or IPv6.

Applications must be changed to use new Windows Sockets application programming interfaces (APIs) and other APIs so that name resolution, socket creation, and other functions are independent of whether IPv4 or IPv6 is being used.
Update the DNS infrastructure to support IPv6 address and PTR records.

The DNS infrastructure might need to be upgraded to support the new AAAA records and PTR records in the IP6.ARPA reverse domain.
Upgrade hosts to IPv6/IPv4 nodes.

Hosts must be upgraded to use both IPv4 and IPv6 in a dual IP layer or dual stack architecture. DNS resolver support must also be updated to process DNS query results that contain both IPv4 and IPv6 addresses.
Upgrade routing infrastructure for native IPv6 routing.

Routers must be upgraded and configured to support native IPv6 prefix advertisement and routing.
Convert IPv6/IPv4 nodes to IPv6-only nodes.

IPv6/IPv4 nodes can be upgraded to be IPv6-only nodes. This should be a long-term goal because it will take years for current IPv4-only network devices to be upgraded to IPv6-only. For those IPv4-only nodes that cannot be upgraded to IPv6/IPv4 or IPv6-only, employ translation gateways or proxies as appropriate so that IPv4-only nodes can communicate with IPv6-only nodes.

Chapter Summary

The chapter includes the following pieces of key information:

IPv6/IPv4 nodes with a dual stack or dual IP architecture, DNS infrastructure, and IPv6 over IPv4 tunneling are used to coexist with an IPv4 infrastructure and to provide eventual migration to an IPv6-only infrastructure.
A configured tunnel requires manual configuration of the tunnel endpoints. An automatic tunnel is a tunnel that does not require manual configuration. Tunnel endpoints are determined from routes and tunneling interfaces.
ISATAP is an address assignment and host-to-host, host-to-router, and router-to-host automatic tunneling technology that provides unicast IPv6 connectivity between IPv6 hosts across an IPv4 intranet.
ISATAP addresses are composed of a valid 64-bit unicast address prefix and the interface identifier ::0:5EFE:w.x.y.z (w.x.y.z is a unicast IPv4 address assigned to an interface).
6to4 is an address assignment and router-to-router automatic tunneling technology that provides unicast IPv6 connectivity between IPv6 sites and hosts across the IPv4 Internet.
6to4 addresses are based on the prefix 2002:WWXX:YYZZ::/48 (in which WWXX:YYZZ is the colon hexadecimal representation of w.x.y.z, a public IPv4 address).
Teredo is an address assignment and host-to-host or host-to-router automatic tunneling technology that provides unicast IPv6 connectivity across the IPv4 Internet when IPv6/IPv4 hosts are located behind one or multiple IPv4 NATs.
To migrate from IPv4 to IPv6 you must upgrade your applications to be independent of IPv4 or IPv6, update the DNS infrastructure to support IPv6 address records, upgrade hosts to IPv6/IPv4 nodes, upgrade your routing infrastructure for native IPv6 routing, and then convert IPv6/IPv4 nodes to IPv6-only nodes.

Chapter Glossary

_ISATAP name – See ISATAP name.

6to4 – An IPv6 transition technology that is used to provide unicast IPv6 connectivity between IPv6 sites across the IPv4 Internet. 6to4 uses a public IPv4 address to construct a global IPv6 address prefix.

6to4 address – An address of the type 2002:WWXX:YYZZ:Subnet_ID:Interface_ID, where WWXX:YYZZ is the colon hexadecimal representation of w.x.y.z (a public IPv4 address). A 6to4 address is used to represent a node for the 6to4 transition technology.

6to4 host – An IPv6 host that is configured with at least one 6to4 address (a global address with the 2002::/16 prefix). 6to4 hosts do not require manual configuration and create 6to4 addresses by using standard address autoconfiguration mechanisms.

6to4 relay router – An IPv6/IPv4 router that forwards 6to4-addressed traffic between 6to4 routers on the IPv4 Internet and hosts on the IPv6 Internet.

6to4 router – An IPv6/IPv4 router that supports the use of a 6to4 tunnel interface and is typically used to forward 6to4-addressed traffic between the 6to4 hosts within a site and other 6to4 routers or 6to4 relay routers on the IPv4 Internet.

automatic tunnel – An IPv6 over IPv4 tunnel in which the tunnel endpoints are determined by the use of logical tunnel interfaces and routes.

configured tunnel – An IPv6 over IPv4 tunnel in which the tunnel endpoints are determined by manual configuration.

dual IP layer architecture – The architecture of an IPv6/IPv4 node in which a single implementation of Transport layer protocols such as TCP and UDP operate over separate implementations of IPv4 and IPv6.

dual stack architecture – The architecture of an IPv6/IPv4 node that consists of two separate protocol stacks, one for IPv4 and one for IPv6, and each stack has its own implementation of the Transport layer protocols (TCP and UDP).

host-to-host tunneling – IPv6 over IPv4 tunneling where the tunnel endpoints are two hosts. For example, an IPv6/IPv4 node that resides within an IPv4 infrastructure creates an IPv6 over IPv4 tunnel to reach another host that resides within the same IPv4 infrastructure.

host-to-router tunneling – IPv6 over IPv4 tunneling where the tunnel begins at a sending host and ends at an IPv6/IPv4 router. For example, an IPv6/IPv4 node that resides within an IPv4 infrastructure creates an IPv6 over IPv4 tunnel to reach an IPv6/IPv4 router.

Intra-site Automatic Tunnel Addressing Protocol (ISATAP) – An IPv6 transition technology that provides unicast IPv6 connectivity between IPv6 hosts across an IPv4 intranet. ISATAP derives the interface ID from an IPv4 address (public or private) assigned to a host.

IPv6 in IPv4 – See IPv6 over IPv4 tunneling.

IPv6 over IPv4 tunneling – The encapsulation of IPv6 packets with an IPv4 header so that IPv6 traffic can be sent across an IPv4 infrastructure. In the IPv4 header, the Protocol field is set to 41.

IPv6/IPv4 node – A node that uses both IPv4 and IPv6.

IPv6-only node – A node that uses only IPv6 and is assigned only IPv6 addresses.

ISATAP – See Intra-site Automatic Tunnel Addressing Protocol (ISATAP).

ISATAP address – An address of the type Unicast_Address_Prefix:0:5EFE:w.x.y.z, where w.x.y.z is a public or private IPv4 address that is assigned to an ISATAP host.

ISATAP host – A host that is assigned an ISATAP address.

ISATAP name – The name that by default is resolved by computers running Windows XP with Service Pack 1, Windows XP with Service Pack 2, or Windows Server 2003 to automatically discover the IPv4 address of the ISATAP router. Computers running Windows XP with no service packs installed by default attempt to resolve the name "_ISATAP".

ISATAP router – An IPv6/IPv4 router that responds to tunneled router solicitations from ISATAP hosts and forwards traffic between ISATAP hosts and nodes on other IPv6 subnets.

router-to-host tunneling – IPv6 over IPv4 tunneling in which the tunnel begins at a forwarding router and ends at an IPv6/IPv4 host. For example, an IPv6/IPv4 router creates an IPv6 over IPv4 tunnel to reach an IPv6/IPv4 host that resides within an IPv4 infrastructure.

router-to-router tunneling – IPv6 over IPv4 tunneling in which the tunnel begins at a forwarding router and ends at an IPv6/IPv4 router. For example, an IPv6/IPv4 router on the edge of an IPv6 network creates an IPv6 over IPv4 tunnel to reach another IPv6/IPv4 router.

Freigeben über