通过

IPv6 Transition Technologies (TechRef)

  • 项目

Applies To: Windows Server 2008

IPv6 Transition Technologies

Protocol transitions are not easy, and the transition from IPv4 to IPv6 is no exception. Protocol transitions are typically deployed by installing and configuring the new protocol on all nodes within the network and verifying that all node and router operations work. 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 becomes an impossible task.

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

RFC 1752 defines the following transition criteria:

  • Existing IPv4 hosts can be upgraded at any time, independent of the upgrade of other hosts or routers.

  • Hosts that use only IPv6 can be added at any time, without dependencies on other hosts or routing infrastructure.

  • IPv4 hosts on which IPv6 is installed can continue to use their IPv4 addresses and do not need additional addresses.

  • Little preparation is required to either upgrade IPv4 nodes to IPv6 or deploy new IPv6 nodes.

The inherent lack of dependencies between IPv4 and IPv6 hosts, IPv4 routing infrastructure, and IPv6 routing infrastructure requires several mechanisms that allow seamless coexistence.

Node Types

RFC 2893 defines the following node types:

IPv4-only Node

A node that implements only IPv4 (and has only IPv4 addresses). This node does not support IPv6. Most hosts and routers installed today are IPv4-only nodes.

IPv6-only Node

A node that implements only IPv6 (and has only IPv6 addresses). This node is able to communicate only with IPv6 nodes and applications. This type of node is not common today, but it might become more prevalent as smaller devices such as cellular phones and handheld computing devices include the IPv6 protocol.

IPv6/IPv4 Node

A node that implements both IPv4 and IPv6. This node is IPv6-enabled if it has an IPv6 interface configured.

IPv4 Node

A node that implements IPv4 (it can send and receive IPv4 packets). An IPv4 node can be an IPv4-only node or an IPv6/IPv4 node.

IPv6 Node

A node that implements IPv6 (it can send and receive IPv6 packets). An IPv6 node can be an IPv6-only node or an IPv6/IPv4 node.

For coexistence to occur, the largest number of 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/IPv4 nodes. IPv4-only nodes can communicate with IPv6-only nodes only through an IPv4-to-IPv6 proxy or translation gateway.

Address Compatibility

The following addresses are defined to help IPv4 and IPv6 nodes coexist:

IPv4-compatible Addresses

IPv6/IPv4 nodes that are communicating with IPv6 over an IPv4 infrastructure use IPv4-compatible addresses, 0:0:0:0:0:0:w.x.y.z or ::w.x.y.z (where w.x.y.z is the dotted decimal representation of a public IPv4 address). When an IPv4-compatible address is used as an IPv6 destination, IPv6 traffic is automatically encapsulated with IPv4 headers and sent to their destinations using the IPv4 infrastructure.

IPv4-mapped Addresses

The IPv4-mapped address, 0:0:0:0:0:FFFF:w.x.y.z or ::FFFF:w.x.y.z, is used to represent an IPv4-only node to an IPv6 node. It is used only for internal representation. The IPv4-mapped address is never used as a source or destination address of an IPv6 packet. The Windows Server 2008 IPv6 protocol does not support IPv4-mapped addresses. Some IPv6 implementations use IPv4-mapped addresses when translating traffic between IPv4-only and IPv6-only nodes.

6over4 Addresses

Each 6over4 address comprises a valid 64-bit unicast address prefix and the interface identifier ::WWXX:YYZZ (where WWXX:YYZZ is the colon-hexadecimal representation of w.x.y.z, a unicast IPv4 address assigned to an interface). An example of a link-local 6over4 address based on the IPv4 address of 131.107.4.92 is FE80::836B:45C. 6over4 addresses represent a host that uses the automatic tunneling mechanism defined in RFC 2529.

6to4 Addresses

6to4 addresses are based on the prefix 2002:WWXX:YYZZ::/48 (where WWXX:YYZZ is the colon-hexadecimal representation of w.x.y.z, a public IPv4 address assigned to an interface). 6to4 addresses represent sites that use the automatic tunneling mechanism defined in RFC 3056, also known as 6to4. For more information, see “6to4” later in this section.

ISATAP Addresses

Each Intra-site Automatic Tunnel Addressing Protocol (ISATAP) address comprises a valid 64-bit unicast address prefix and the interface identifier ::0:5EFE:w.x.y.z (where w.x.y.z is a unicast IPv4 address assigned to an interface). An example of a link-local ISATAP address is FE80::5EFE:131.107.4.92. ISATAP addresses represent hosts that use the automatic tunneling mechanism defined in the Internet draft titled “Intra-Site Automatic Tunnel Addressing Protocol (ISATAP).” For more information, see “ISATAP” later in this section.

Teredo Addresses

Teredo addresses use the prefix 3FFE:831F::/32. An example of a Teredo address is 3FFE:831F:CE49:7601:8000:EFFF:62C3:FFFE. Beyond the first 32 bits, Teredo addresses encode the IPv4 address of a Teredo server, flags, and the encoded version of the external address and port of a Teredo client. Teredo addresses represent hosts that use the automatic tunneling mechanism defined in the Internet draft titled “Teredo: Tunneling IPv6 over UDP through NATs.” For more information, see “Teredo” later in this section.

Transition Mechanisms

The following mechanisms are used to help IPv6 coexist with an IPv4 infrastructure and to provide an eventual transition to an IPv6-only infrastructure:

  • IPv6 over IPv4 tunneling

  • DNS infrastructure

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 as part of the tunnel interface or are automatically derived from the sending interface, the next-hop address of the matching route, or the source and destination IPv6 addresses in the IPv6 header.

The following figure shows IPv6 over IPv4 tunneling.

IPv6 over IPv4 Tunneling

For IPv6 over IPv4 tunneling, the IPv6 path MTU is typically 20 fewer bytes than the IPv4 path MTU. However, if the IPv4 path MTU is not stored for each tunnel, an intermediate IPv4 router might need to fragment the IPv4 packet. In this case, the Don’t Fragment flag in the IPv4 header must be set to 0 when IPv6 over IPv4 tunneled packets are sent.

DNS Infrastructure

Because most users refer to network resources by name rather than by address, successful coexistence requires upgrading the DNS infrastructure. Upgrading the DNS infrastructure consists of populating the DNS servers with records to support IPv6 name-to-address and address-to-name resolution. After the sending host obtains addresses using a DNS name query, the node must select which addresses to use for communication.

Address Records

The DNS infrastructure must contain the following resource records (populated either manually or dynamically) for the successful resolution of domain names to addresses:

  • A records for IPv4-only and IPv6/IPv4 nodes

  • AAAA records for IPv6-only and IPv6/IPv4 nodes

Pointer Records

The DNS infrastructure must contain the following resource records (populated either manually or dynamically) for the successful resolution of address to domain names (reverse queries):

  • PTR records in the IN-ADDR.ARPA domain for IPv4-only and IPv6/IPv4 nodes

  • PTR records in the IP6.ARPA domain for IPv6-only and IPv6/IPv4 nodes (optional)

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

This choice is not an issue in today’s environment, in which IPv4-only nodes prevail. However, in an environment in which IPv4 and IPv6 coexist, the set of addresses returned in a DNS query might contain multiple IPv4 and IPv6 addresses. The querying host is configured with at least one IPv4 address and (typically) multiple IPv6 addresses. It is not an easy task to decide which type of address (IPv4 versus IPv6) and then which scope (public versus private for IPv4 and link-local versus global versus compatible for IPv6) to use for both the source and the destination addresses.

Default address selection rules are currently under discussion and are described in RFC 3484.

You can view the default address selection rules for the IPv6 protocol using the netsh interface ipv6 show prefixpolicy command to display the prefix policy table. 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.

Tunneling Configurations

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

  • Router-to-Router

  • Host-to-Router or Router-to-Host

  • Host-to-Host

Note

  • 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 Point-to-Point Tunneling Protocol (PPTP) and Layer Two Tunneling Protocol (L2TP), no messages are exchanged for tunnel setup, maintenance, or termination. Additionally, IPv6 over IPv4 tunneling does not provide security for tunneled IPv6 packets.

    • Router-to-Router

    In the tunneling configuration between routers, two IPv6/IPv4 routers connect two IPv4 or IPv6 infrastructures over an IPv4 infrastructure. The tunnel spans 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, an interface represents the IPv6 over IPv4 tunnel and routes that use the tunnel interface.

    The following figure shows tunneling between two routers.

    Router-to-Router Tunneling

    Examples of this tunneling configuration include:

    • An IPv6-only test lab that tunnels across an organization’s IPv4 infrastructure to reach the IPv6 Internet.

    • Two IPv6-only routing domains that tunnel across the IPv4 Internet.

    • A 6to4 router that tunnels across the IPv4 Internet to reach another 6to4 router or a 6to4 relay router. For more information about “6to4”, see “6to4” later in this section.

    Host-to-Router and 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 spans 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 node and destination node. 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.

    The following figure 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.

    Host-to-Router and Router-to-Host Tunneling

    Examples of host-to-router and router-to-host tunneling include:

    • An IPv6/IPv4 host that tunnels across an organization’s IPv4 infrastructure to reach the IPv6 Internet.

    • An ISATAP host that tunnels across an IPv4 network to an ISATAP router to reach the IPv4 Internet, another IPv4 network, or an IPv6 network. For more information about “ISATAP”, see “ISATAP” later in this section.

    • An ISATAP router that tunnels across an IPv4 network to reach an ISATAP host.

    Host-to-Host

    In the tunneling configuration between hosts, 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 spans 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 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.

    The following figure shows tunneling between hosts.

    Host-to-Host Tunneling

    Examples of this tunneling configuration include:

    • IPv6/IPv4 hosts that use ISATAP addresses to tunnel across an organization’s IPv4 infrastructure.

    • IPv6/IPv4 hosts that use IPv4-compatible addresses to tunnel across an organization’s IPv4 infrastructure.

    Types of Tunnels

    RFC 2893 defines the following types of tunnels:

    • Configured

    • Automatic

    Configured Tunnels

    A configured tunnel is one whose endpoints must be configured manually. In a configured tunnel, the endpoints have IPv4 addresses that are not derived from the IPv6 source or destination addresses or the next-hop address of the matching route.

    Tunnels between routers are typically configured manually. To configure the tunnel interface, the IPv4 addresses of the tunnel endpoints must be manually specified along with static routes that use the tunnel interface.

    To manually configure tunnels for IPv6, use the netsh interface ipv6 add v6v4tunnel command.

    Automatic Tunnels

    An automatic tunnel is one whose endpoints do not need to be configured manually. Tunnel endpoints are determined from logical tunnel interfaces, routes, and source and destination IPv6 addresses.

    The IPv6 protocol for Windows Server 2008 supports the following automatic tunneling technologies:

    • 6to4, which is enabled by default.

    • ISATAP, which is enabled by default. For more information, see “ISATAP” later in this section.

    • IPv6 Automatic Tunneling, which is disabled by default.

    • 6over4, which is disabled by default.

    Additionally, the IPv6 protocol for Windows XP with Service Pack 1 also supports Teredo when the Advanced Networking Pack for Windows XP is installed. Teredo is enabled by default. For more information, see “Teredo” later in this section.

    6to4

    6to4 is a technology that assigns addresses and automatically configures tunnels between routers to provide unicast IPv6 connectivity between IPv6 sites and hosts across the IPv4 Internet. 6to4 uses the global address prefix:

    2002:WWXX:YYZZ::/48

    in which 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]

    RFC 3056 describes 6to4 in 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 they create 6to4 addresses using standard address autoconfiguration mechanisms.

    • 6to4 router

    An IPv6/IPv4 router that supports the use of a 6to4 tunnel interface and that is typically used to forward 6to4-addressed traffic between the 6to4 hosts within a site and other 6to4 routers or 6to4 relay routers on an IPv4 internetwork, such as the Internet. 6to4 routers require additional processing logic for proper encapsulation and decapsulation, and they might require manual configuration.

    • 6to4 relay router

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

    The following figure shows 6to4 components.

    6to4 Components

    Within a site, IPv6 routers advertise 2002:WWXX:YYZZ:[Subnet ID]::/64 prefixes so that hosts can create an autoconfigured 6to4 address and 64-bit prefix routes are used to deliver traffic between 6to4 hosts within the site. 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. All IPv6 traffic that does not match a 64-bit prefix used by one of the subnets 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 the previous figure, 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 6to4 tunnel interface and the 2002::/16 route in its routing table, encapsulates the packet with an IPv4 header and tunnels the packet to the 6to4 router in Site 2. When the 6to4 router in Site 2 receives the packet, the router removes the IPv4 header and, using the 64-bit prefix route in its routing table, forwards the IPv6 packet to Host C.

    In this example, Host A (with the interface ID ID_A) resides on subnet 1 within Site 1, which uses the public IPv4 address of 157.60.91.123. Host C (with the interface ID ID_C) resides on subnet 2 within Site 2, which uses the public IPv4 address of 131.107.210.49. When the 6to4 router in Site 1 sends the IPv4-encapsulated IPv6 packet to the 6to4 router in Site 2, the addresses in the IPv4 and IPv6 headers are as listed in the following table.

    Example 6to4 Addresses

    Field Value

    IPv6 Source Address

    2002:9D3C:5B7B:1:[ID_A]

    IPv6 Destination Address

    2002:836B:D231:2:[ID_C]

    IPv4 Source Address

    157.60.91.123

    IPv4 Destination Address

    131.107.210.49

    For a more detailed example of 6to4 traffic using ISATAP-derived interface identifiers, see “ISATAP” later in this section.

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

    • A 6to4 host can communicate with another 6to4 host within the same site.

      This type of communication is available with the IPv6 routing infrastructure, which provides reachability to all hosts within the site. The previous figure shows this type of 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 the 6to4 router for the local site. The 6to4 router for the local site tunnels the IPv6 traffic through the IPv4 Internet to the 6to4 router at the destination site. 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. The previous figure shows this type of 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 the 6to4 router for the local site. The 6to4 router for the local site 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 routing infrastructure of the IPv6 Internet. The previous figure shows this type of communication between Host A and Host D.

    All of these types of communication use IPv6 traffic without having to obtain either a direct connection to the IPv6 Internet or an IPv6 global address prefix from an ISP.

    Communicating Using a 6to4 Address

    The IPv6 protocol for Windows Server 2008 contains a 6to4 component that supports 6to4 hosts and 6to4 routers. If a public IPv4 address is assigned to an interface on the host and a global prefix is not received in a router advertisement, the 6to4 component:

    • Configures 6to4 addresses on the 6to4 Tunneling Pseudo-Interface for all public IPv4 addresses that are assigned to interfaces on the computer.

    • Creates a 2002::/16 route that forwards all 6to4 traffic with the 6to4 Tunneling Pseudo-Interface (interface index 3). All traffic forwarded by this host to 6to4 destinations is encapsulated with an IPv4 header.

    • Performs a DNS query to obtain the IPv4 address of a 6to4 relay router on the Internet. You can also 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 6to4 component autoconfiguration vary depending on the configuration of the host. The following figure shows how 6to4 is configured for different types of hosts running (except IPv6 host D).

    6to4 for Hosts Running Windows

    For a host that is assigned a private IPv4 address or receives a router advertisement for a global prefix, no 6to4 addresses are assigned to the 6to4 Tunneling Pseudo-Interface. Addresses are autoconfigured based on the global prefix, and the routing table contains a 64-bit global prefix route and default route. This configuration corresponds to Host A, Host B, and Host C in the previous figure.

    For a host that is assigned a public IPv4 address and does not receive a router advertisement for a global prefix, a 6to4 address of the form 2002:WWXX:YYZZ::WWXX:YYZZ is automatically assigned to the 6to4 Tunneling Pseudo-Interface. A 2002::/16 route using the 6to4 Tunneling Pseudo-Interface is added, and, if the DNS query for the 6to4 relay router is successful, a default route using the 6to4 address of the 6to4 relay router as the next hop is added. This configuration corresponds to Host E in the previous figure, a host that is directly connected to the IPv4 Internet. In this case, the host is acting as its own site and its own 6to4 router.

    The 6to4 component can also enable a computer running Windows Server 2008 as a 6to4 router by utilizing the configuration of the Internet Connection Sharing (ICS) feature. This configuration corresponds to 6to4 router 1 and 6to4 router 2 in the previous figure.

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

    • Enables IPv6 forwarding on both the public and private interfaces.

      The public interface is connected to the Internet. 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 global 6to4 address prefix that is based on the public IPv4 address assigned to the public interface. The Subnet ID in the 6to4 address 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 private interface, the advertised prefix would be 2002:836B:1759:5::/64. Private hosts that receive this router advertisement would create global addresses through normal address autoconfiguration. The hosts would also 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 6to4 sites or the IPv6 Internet, the IPv6 packets are forwarded 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 IPv4 headers and sends the packets 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 IPv4 headers and sends the packets across the IPv4 Internet to a 6to4 relay router.

    Note

  • The 6to4 component does not perform network address translation on the IPv6 packets that it forwards. ICS translates network addresses for IPv4 packets being forwarded to and from private hosts. The 6to4 component uses the ICS configuration to determine the public IPv4 address and public interface.

    • ISATAP

    ISATAP is a technology that assigns addresses, configures tunnels between hosts and between routers and hosts, and provides unicast IPv6 connectivity between IPv6 hosts across an IPv4 intranet. ISATAP is described in the Internet draft titled “Intra-Site Automatic Tunnel Addressing Protocol (ISATAP).” ISATAP hosts do not require any manual configuration, and they create ISATAP addresses using standard mechanisms for address autoconfiguration.

    IPv6/IPv4 nodes can use ISATAP to communicate on an IPv4 network. ISATAP addresses use the locally administered interface identifier ::0:5EFE:w.x.y.z where the w.x.y.z portion is any public or private unicast IPv4 address.

    The ISATAP interface identifier can be combined with any 64-bit prefix that is valid for IPv6 unicast addresses. This includes the link-local address prefix (FE80::/64) and global prefixes (including 6to4 prefixes).

    Like IPv4-compatible addresses, 6over4 addresses, and 6to4 addresses, ISATAP addresses contain embedded IPv4 addresses that are used to determine either the source or destination IPv4 addresses within the IPv4 header when ISATAP-addressed IPv6 traffic is tunneled across an IPv4 network.

    By default, the IPv6 protocol for Windows Server 2008 automatically configures the link-local ISATAP address of FE80::5EFE:w.x.y.z on the Automatic Tunneling Pseudo-Interface (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 addresses.

    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 Windows Server 2008 is started, Host A is automatically configured with the ISATAP address of FE80::5EFE:10.40.1.29, and Host B is automatically configured with the ISATAP address of FE80::5EFE:192.168.41.30. The following figure shows this configuration.

    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 the following table.

    Example Link-Local ISATAP Addresses

    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, use the ping command. For example, Host A would use the following command to ping Host B by using 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 specifies 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 Automatic Tunneling Pseudo-Interface uses the link-local ISATAP address assigned to the interface as a source. The Automatic Tunneling Pseudo-Interface also 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.

    ISATAP Router

    The use of link-local ISATAP addresses allows IPv6/IPv4 hosts on the same logical subnet (an IPv4 network) to communicate with each other, but not with other IPv6 addresses on other subnets. To communicate outside the logical subnet using ISATAP-derived global addresses, IPv6 hosts using ISATAP addresses must tunnel their packets to an ISATAP router. The following figure shows this configuration.

    An ISATAP Router

    An ISATAP router is an IPv6 router that:

    • Forwards packets between ISATAP hosts on a logical subnet (an IPv4 network) and hosts on other subnets.

      The other subnets can be other IPv4 networks (such as a portion of an organization network or the IPv4 Internet) or subnets in a native IPv6 routing domain (such as an organization’s IPv6 network or the IPv6 Internet).

    • Acts as a default router for ISATAP hosts.

    • Advertises address prefixes to identify the logical subnet on which ISATAP hosts are located. ISATAP hosts use the advertised address prefixes to configure global ISATAP addresses.

    When an ISATAP host receives a Router Advertisement message from an ISATAP router, a default route (::/0) is added using the Automatic Tunneling Pseudo-Interface with next-hop address set to the link-local ISATAP address that corresponds to the logical subnet interface of the ISATAP router. When packets destined to locations outside the logical subnet are sent, they are tunneled to the IPv4 address that corresponds to the ISATAP router’s interface on the logical subnet defined by the IPv4 network containing the ISATAP router and ISATAP host. The ISATAP router then forwards the IPv6 packet.

    For the IPv6 protocol for Windows Server 2008, the configuration of the intranet IPv4 address of the ISATAP router is obtained through one of the following:

    • The 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 2008 starts, it attempts to resolve the name “ISATAP” to an IPv4 address using normal TCP/IP name resolution techniques. These techniques include the following:

    1. Checking the local host name.

    2. Checking the DNS client resolver cache, which includes the entries in the Hosts file. This file is located in the systemroot\system32\drivers\etc folder.

    3. Forming a fully qualified domain name and sending a DNS name query. For example, if the computer running Windows Server 2008 is a member of the example.contoso.com domain (and example.contoso.com is the only domain name in the search list), the computer sends a DNS query to resolve the name isatap.example.contoso.com.

    4. Converting the ISATAP name into the NetBIOS name “ISATAP <00>” and checking the NetBIOS name cache.

    5. Sending a NetBIOS name query to the configured Windows Internet Name Service (WINS) servers.

    6. Sending NetBIOS broadcasts.

    7. Checking the Lmhosts file. This file is located in the systemroot\system32\drivers\etc folder.

    If the name is resolved, the host sends an IPv4-encapsulated Router Solicitation message to the ISATAP router. The ISATAP router responds with an IPv4-encapsulated unicast Router Advertisement message that contains prefixes to use for autoconfiguring 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 of the following:

    • If the ISATAP router is a computer running Windows Server 2008, name tinhe computer ISATAP, and it will automatically register the appropriate records in DNS and WINS.

    • Manually create an ISATAP address (A) record in the appropriate domain in DNS. For example, create an A record for isatap.example.contoso.com.

    • 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:

      IPv4Address ISATAP

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

      IPv4Address 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 configure this address manually by using the netsh interface ipv6 isatap set router command. The syntax of this command is:

    netsh interface ipv6 isatap set router AddressOrName

    where AddressOrName 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

    After a host has been configured, it sends an IPv4-encapsulated Router Solicitation message to the ISATAP router. The ISATAP router responds with an IPv4-encapsulated unicast Router Advertisement message that contains prefixes to use for autoconfiguring ISATAP-based addresses. This additional configuration is needed only when no IPv6 router is on the host’s subnet.

    PortProxy

    To facilitate communication between nodes or applications that cannot connect using a common Internet layer protocol (IPv4 or IPv6), the IPv6 protocol for Windows Server 2008 provides PortProxy, a component that allows the following traffic to be proxied:

    • IPv4 to IPv4

      TCP traffic to an IPv4 address is proxied to TCP traffic to another IPv4 address.

    • IPv4 to IPv6

      TCP traffic to an IPv4 address is proxied to TCP traffic to an IPv6 address.

    • IPv6 to IPv6

      TCP traffic to an IPv6 address is proxied to TCP traffic to another IPv6 address.

    • IPv6 to IPv4

      TCP traffic to an IPv6 address is proxied to TCP traffic to an IPv4 address.

      The most interesting and useful proxying for IPv6/IPv4 coexistence and migration is from IPv4 to IPv6 and from IPv6 to IPv4. For coexistence and migration, PortProxy enables the following scenarios:

    • An IPv4-only node can access an IPv6-only node.

      In the IPv4 DNS infrastructure of the IPv4-only node, the name of the IPv6-only node resolves to an IPv4 address assigned to an interface of the PortProxy computer. (Resolving this name might require an A record to be configured manually in DNS.) The PortProxy computer is configured to proxy IPv4 to IPv6. All TCP traffic sent by the IPv4-only node is proxied in a manner similar to Internet proxy servers: the IPv4-only node establishes a TCP connection with the PortProxy computer, and the PortProxy computer establishes a separate TCP connection with the IPv6-only node. The TCP connection data is transferred between the IPv4-only node and the IPv6-only node by the PortProxy component.

    • An IPv6-only node can access an IPv4-only node.

      In the IPv6 DNS infrastructure of the IPv6-only node, the name of the IPv4-only node resolves to an IPv6 address assigned to an interface of the PortProxy computer. (Resolving this name might require AAAA records to be manually configured in DNS.) The PortProxy computer is configured to proxy IPv6 to IPv4. TCP traffic sent by the IPv6-only node to the PortProxy computer is proxied to the IPv4-only node.

    • An IPv6 node can access an IPv4-only service running on a PortProxy computer.

      In the IPv6 DNS infrastructure of the IPv6-only node, the name of the IPv6/IPv4 node resolves to an IPv6 address assigned to an interface of the PortProxy computer. The PortProxy computer is configured to proxy from IPv6 to IPv4 on itself. TCP traffic sent by the IPv6 node to the PortProxy computer is proxied to an IPv4-only service or application running on the PortProxy computer.

    The last scenario allows IPv6 nodes to access services that are running on a server that does not support IPv6. For example, Windows Server 2008 includes a Telnet Client, which supports IPv6, and Telnet Server, which does not. However, you can allow IPv6 nodes to access the Telnet service by running PortProxy on the computer that is running Telnet Server.

    To configure the PortProxy component, use the netsh interface portproxy add|set|delete v4tov4|v4tov6|v6tov4|v6tov6 commands. For example, use the netsh interface portproxy add v6tov4 23 command to enable IPv6 on the Telnet service (using TCP port 23) on a computer that is running Windows Server 2008.

    By default, the IPv6/IPv4 node that is running Telnet Server dynamically registers both its IPv6 and IPv4 addresses in DNS. By default, a computer that is running Windows Server 2008 queries DNS for all record types, preferring IPv6 addresses to IPv4 addresses. When the Telnet client is a computer that is running Windows Server 2008, it attempts to connect using IPv6 first. With PortProxy properly configured, the first attempt to connect using an IPv6 address of the computer that is running Telnet Server should succeed without manual configuration of DNS records.

    Note

  • The PortProxy component is provided only with the IPv6 protocol for Windows Server 2008.

  • The PortProxy component works only for TCP traffic and for application-layer protocols that do not embed address or port information inside the upper-layer PDU. PortProxy has no facilities to check for and change embedded address or port information in upper layer PDUs that are being proxied. For example, PortProxy cannot enable the FTP server service for IPv6 because the FTP PORT command embeds IPv4 address information inside the FTP PDU.

    • IPv6 Automatic Tunneling

    RFC 2893 defines IPv6 Automatic Tunneling as 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, when Host1 (with the public IPv4 address of 157.60.91.123 and corresponding IPv4-compatible address of ::157.60.91.123) sends traffic to Host2 (with the IPv4 address of 131.107.210.49 and corresponding IPv4-compatible address of ::131.107.210.49), the addresses in the IPv4 and IPv6 headers are as listed in the following table.

    Example IPv6 Automatic Tunneling Addresses

    Field Value

    IPv6 Source Address

    ::157.60.91.123

    IPv6 Destination Address

    ::131.107.210.49

    IPv4 Source Address

    157.60.91.123

    IPv4 Destination Address

    131.107.210.49

    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:

    ping ::131.107.210.49

    The IPv6 protocol for Windows Server® 2008 does not use IPv4-compatible addresses by default. To enable IPv4-compatible addresses, use the netsh interface ipv6 set state v4compat=enabled command. When the IPv6 protocol for Windows Server 2008 is enabled, 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 packets with destination addresses in which the first 96 bits are set to 0 are forwarded to their destination addresses with 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.

    Note

  • In this section, 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.

  • IPv4-compatible addresses are not widely used because they are defined only for public IPv4 addresses, and their functionality has been replaced with ISATAP for IPv4 intranets and 6to4 for the IPv4 Internet. For more information, see “ISATAP” and “6to4” earlier in this section.

    • 6over4

    6over4, also known as IPv4 multicast tunneling, is a technology that automatically configures tunnels between hosts, between routers, and between hosts and routers. 6over4 provides unicast and multicast connectivity between IPv6 nodes across an IPv4 intranet. RFC 2529 describes 6over4. 6over4 hosts use a valid 64-bit prefix for unicast addresses and the interface identifier ::WWXX:YYZZ, where WWXX:YYZZ is the colon-hexadecimal representation of the IPv4 address (w.x.y.z) that is assigned to the host. By default, 6over4 hosts automatically configure the link-local address FE80::WWXX:YYZZ on each 6over4 interface.

    6over4 treats an IPv4 infrastructure as a single link with multicast capabilities. Neighbor Discovery processes (such as address resolution and router discovery) work over a physical link with multicast capabilities. To emulate a multicast-capable link, the IPv4 infrastructure must be enabled for IPv4 multicast traffic. The following figure shows a 6over4 configuration.

    A 6over4 Configuration

    To facilitate IPv6 multicast communication over an infrastructure that is enabled for IPv4 multicast traffic, RFC 2529 defines the following mapping to translate an IPv6 multicast address to an IPv4 multicast address:

    239.192.[second to last byte of IPv6 address].[last byte of IPv6 address]

    The following are example mappings for IPv6 multicast addresses:

    • FF02::1 (link-local scope all-hosts multicast address) is mapped to 239.192.0.1.

    • FF02::2 (link-local scope all-routers multicast address) is mapped to 239.192.0.2.

    • FF02::1:FF28:9C5A (example solicited-node multicast address) is mapped to 239.192.156.90.

    When 6over4 is enabled, the IPv4 layer uses Internet Group Membership Protocol (IGMP) messages to inform local IPv4 routers that it will receive IPv4 multicast traffic that is sent to the mapped IPv4 multicast addresses. Hosts that are enabled for 6over4 also register additional multicast MAC addresses with their network adapters that correspond to the mapped IPv4 multicast addresses. For example, for an Ethernet adapter:

    • The corresponding multicast MAC address for 239.192.0.1 is 01-00-5E-40-00-01.

    • The corresponding multicast MAC address for 239.192.0.2 is 01-00-5E-40-00-02.

    • The corresponding multicast MAC address for 239.192.156.90 is 01-00-5E-40-9C-5A.

    Because the IPv4 infrastructure acts as a multicast-capable link, hosts can use Neighbor Solicitation and Neighbor Advertisement messages to resolve each other’s link-layer addresses. The 6over4 link-layer addresses are the tunnel endpoints. Hosts and routers can use Router Solicitation and Router Advertisement messages for router, prefix, and parameter discovery. The following figure shows the format for the Source and Target Link-Layer Address options that, as defined in RFC 2529, facilitate Neighbor Discovery.

    Source and Target Link-Layer Address Options for 6over4

    For example, Host1 has the public IPv4 address of 157.60.91.123 and corresponding link-local 6over4 address of FE80::9D3C:5B7B. Host2 has the public IPv4 address of 131.107.210.49 and corresponding link-local 6over4 address of FE80::836B:D231. When Host 1 sends traffic to Host 2, the addresses in the IPv4 and IPv6 headers are as listed in the following table.

    Example 6over4 Addresses

    Field Value

    IPv6 Source Address

    FE80::9D3C:5B7B

    IPv6 Destination Address

    FE80::836B:D231

    IPv4 Source Address

    157.60.91.123

    IPv4 Destination Address

    131.107.210.49

    The use of 6over4 for the IPv6 protocol is disabled by default. To enable the use of 6over4, use the netsh interface ipv6 set state 6over4=enabled command. This command creates a 6over4 tunneling interface for each IPv4 address assigned to the computer. If the computer receives Router Advertisement messages over any of these interfaces (through the multicast mapping mechanism described earlier), appropriate addresses for this interface and routes that use this interface are automatically configured.

    Routes and the 6over4 tunneling interface facilitate communication to 6over4 addresses. For example, the interface index for the 6over4 tunneling interface of a host is 5. (The actual interface index for the 6over4 tunneling interface varies depending on the configuration of the computer.) A Router Advertisement message from a router with the link-local 6over4 address of FE80::C0A8:1501 is received. The router is advertised as a default router, and the message contains the auto-configuration prefix FEC0:0:0:21A8::/64. The host configures a default route with the next-hop address of FE80::C0A8:1501 and a subnet route for prefix FEC0:0:0:21A8::/64 that uses interface index 5.

    When packets are sent using the default or FEC0:0:0:21A8::/64 routes, the sending host uses the appropriate locally assigned 6over4 address as a source. The node also 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.

    A packet to a destination that matches the prefix FEC0:0:0:21A8::/64 is sent to the next-hop address of the destination using the 6over4 tunneling interface. The 6over4 tunneling interface uses address resolution for the destination address to determine the source and destination link-layer addresses (and corresponding IPv4 addresses) to use when sending the IPv4-encapsulated IPv6 packet.

    A packet to a destination that matches the default route is sent to the next-hop address of FE80::C0A8:1501 using the 6over4 tunneling interface. The 6over4 tunneling interface uses address resolution for the next-hop address to determine the source and destination link-layer addresses (and corresponding IPv4 addresses) to use when sending the IPv4-encapsulated IPv6 packet.

    Note

  • 6over4 is not widely used because it requires an IPv4 multicast infrastructure.

  • The difference between using ISATAP versus 6over4 on an IPv4 intranet is that 6over4 supports IPv6 multicast, and ISATAP currently does not.

  • When you enable 6over4 with the netsh interface ipv6 set state 6over4=enabled command, it creates a 6over4 tunneling interface with a name that is based on a globally unique identifier (GUID). To create a 6over4 tunneling interface with a friendlier name, use the netsh interface ipv6 add 6over4tunnel command instead.

    • Teredo

    Teredo, also known as IPv4 network address translation (NAT) traversal for IPv6, is an IPv6/IPv4 transition technology. Teredo provides address assignment and host-to-host automatic tunneling for unicast IPv6 connectivity when IPv6/IPv4 hosts are located behind one or multiple IPv4 NATs. To traverse IPv4 NATs, IPv6 packets are sent as IPv4-based User Datagram Protocol (UDP) messages. This section provides an overview of Teredo — including Teredo addresses and packet structures — and detailed explanations of how communication is initiated between Teredo clients, Teredo host-specific relays, and IPv6-only hosts that use the IPv4 Internet, the IPv6 Internet, Teredo servers, and Teredo relays.

    Teredo is an address assignment and automatic tunneling technology that provides unicast IPv6 connectivity across the IPv4 Internet. 6to4 is a well-defined automatic tunneling technology that provides unicast IPv6 connectivity across the IPv4 Internet. However 6to4 works best when a 6to4 router exists at the edge of the site. The 6to4 router uses a public IPv4 address to construct the 6to4 prefix and acts as an IPv6 advertising and forwarding router. The 6to4 router encapsulates and decapsulates IPv6 traffic sent to and from site nodes.

    6to4 relies on the configuration of a public IPv4 address and the implementation of 6to4 routing functionality in the edge device. Many small office/home office (SOHO) configurations include an IPv4 network address translator (NAT). For more information about how network address translation works, see “Overview of Network Address Translators (NATs)” later in this section. In most NAT configurations, the device providing NAT functionality is not capable of being a 6to4 router. Even if all NAT devices could support 6to4, some configurations contain multiple levels of NATs. In these configurations, a 6to4-capable NAT device will not work because it does not have a public IPv4 address.

    Teredo fills the need for 6to4 functionality in modern-day NATs and multi-layered NAT configurations by tunneling IPv6 packets between the hosts within the sites. In contrast, 6to4 uses tunneling from the edge device. Tunneling between 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 translate only TCP or UDP traffic, and they must either be manually configured to translate other protocols or have installed NAT editors that handle the translation. Because Protocol 41 translation is not a common feature of NATs, IPv4-encapsulated IPv6 traffic will not traverse typical NATs. Therefore, to allow IPv6 traffic to traverse one or multiple NATs, the IPv6 packet is encapsulated as an IPv4 UDP message, containing both an IPv4 and a UDP header. UDP messages can be translated universally by NATs and can traverse multiple layers of NATs.

    To summarize, Teredo is an IPv6/IPv4 transition technology that allows automatic IPv6 tunneling between hosts that are located across one or more IPv4 NATs. IPv6 traffic from Teredo hosts can traverse NATs because it is sent as IPv4 UDP messages. If a NAT supports UDP port translation, then the NAT supports Teredo. The exception is a symmetric NAT. For more information, see “Types of NATs” later in this section.

    Teredo is designed as a last-resort transition technology for IPv6 connectivity. If native IPv6, 6to4, or ISATAP connectivity is present, the host does not act as a Teredo client. As more IPv4 NATs are upgraded to support 6to4 and IPv6 connectivity becomes ubiquitous, Teredo will be used less and less and eventually eliminated.

    Network Address Translators

    As defined in RFC 1631, a network address translator (NAT) is an IPv4 router that can translate the IP addresses and TCP/UDP port numbers of packets as it forwards them. For example, consider a small business network with multiple computers that connect to the Internet. Without a NAT, this business would need to obtain a public IP address for each computer on the network. With a NAT, however, the small business can use private addressing (as described in RFC 1918) and have the NAT map its private addresses to a single or to multiple public IP addresses.

    NAT is a common solution for the following combination of requirements:

    • The administrator wants to leverage a single connection over multiple computers, rather than connecting each one to the Internet.

    • The administrator wants to use private addressing.

    • The administrator wants to allow access to Internet resources without having to deploy a proxy server.

    How network address translation works

    When a private user on the small business intranet connects to an Internet resource, the user’s TCP/IP protocol creates an IP packet with the following values set in the IP and TCP or UDP headers (bold text indicates the fields that are affected by the NAT):

    • Destination IP Address: IP address of the Internet resource

    • Source IP Address: Private IP address

    • Destination Port: TCP or UDP port of the Internet resource

    • Source Port: Source application TCP or UDP port

    The source host or another router forwards this IP packet to the NAT, which translates the addresses of the outgoing packet as follows:

    • Destination IP Address: IP address of the Internet resource

    • Source IP Address: ISP-allocated public address

    • Destination Port: TCP or UDP port of the Internet resource

    • Source Port: Remapped source application TCP or UDP port

    The NAT sends the remapped IP packet over the Internet. The responding computer sends back a response to the NAT. The response contains the following addressing information:

    • Destination IP Address: ISP-allocated public address

    • Source IP Address: IP address of the Internet resource

    • Destination Port: Remapped source application TCP or UDP port

    • Source Port: TCP or UDP port of the Internet resource

    When the NAT maps and translates the addresses and forwards the packet to the intranet client, the packet contains the following addressing information:

    • Destination IP Address: Private IP address

    • Source IP Address: IP address of the Internet resource

    • Destination Port: Source application TCP or UDP port

    • Source Port: TCP or UDP port of the Internet resource

    For outgoing packets, the source IP address and TCP/UDP port numbers are mapped to a public source IP address and a possibly changed TCP/UDP port number. For incoming packets, the destination IP address and TCP/UDP port numbers are mapped to the private IP address and original TCP/UDP port numbers.

    For example, a small business is using the 192.168.0.0/24 private network ID for its intranet and has been allocated a single public IP address of 131.107.0.1 by its ISP. When a user with the private address 192.168.0.99 on the small business intranet connects to a Web server at the IP address 157.60.0.1, the user’s TCP/IP protocol creates an IP packet with the following values set in the IP and TCP or UDP headers:

    • Destination IP Address: 157.60.0.1

    • Source IP Address: 192.168.0.99

    • Destination Port: 80

    • Source Port: 1025

    The source host forwards this packet to the NAT device, which translates the addresses of the outgoing packet as follows:

    • Destination IP Address: 157.60.0.1

    • Source IP Address: 131.107.0.1

    • Destination Port: 80

    • Source Port: 5000

    The NAT sends the remapped packet over the Internet. The Web server sends back a response to the NAT. The response contains the following addressing information:

    • Destination IP Address: 131.107.0.1

    • Source IP Address: 157.60.0.1

    • Destination Port: 5000

    • Source Port: 80

    When the NAT maps and translates the addresses and forwards the packet to the intranet client, the packet contains the following addressing information:

    • Destination IP Address: 192.168.0.99

    • Source IP Address: 157.60.0.1

    • Destination Port: 1025

    • Source Port: 80

    The following figure shows the configuration for this example.

    NAT example

    The mappings for private to public traffic are stored in a NAT translation table, which can contain two types of entries:

    • Dynamic mappings

      Created when private network clients initiate communication. Dynamic mappings are removed from the NAT translation table after a specified amount of time, unless traffic that corresponds to the mapping refreshes it.

    • Static mappings

      Configured manually so that communication that Internet clients initiate can be mapped to specific private network addresses and ports. Static mappings are needed when you want to make servers (for example, Web servers) or applications (for example, games) on the private network available to computers that are connected to the Internet. Static mappings are not automatically removed from the NAT translation table.

    The NAT forwards traffic from the Internet to the private network only if the NAT translation table contains an appropriate mapping. In this way, the NAT provides a level of protection for computers that are connected to private network segments. However, a NAT should not be used in place of a fully featured firewall when Internet security is a concern.

    Types of NATs

    NATs fall into the following types:

    • Cone NATs

      A NAT in which the NAT translation table entry stores a mapping between an internal address and port number and an external address and port number. When the NAT translation table entry is in place, inbound traffic to the external address and port number from any source address and port number is translated.

    • Restricted NATs

      A NAT in which the NAT translation table entry stores a mapping between an internal address and port number and an external address and port number, for either specific source addresses or specific source address and port numbers. An inbound packet from an unknown external address or port number is silently discarded.

    • Symmetric NATs

      A NAT that maps the same internal address and port number to different external addresses and ports, depending on the external destination address (for outbound traffic).

    Teredo can work over only cone and restricted NATs. Teredo cannot work over symmetric NATs.

    Teredo Components

    The following figure shows the components of the Teredo infrastructure:

    • Teredo clients

    • Teredo servers

    • Teredo relays

    • Teredo host-specific relays

    Components of the Teredo infrastructure

    Teredo client

    A Teredo client is 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). A Teredo client communicates with a Teredo server to obtain an address prefix from which a Teredo-based IPv6 address is configured or to help initiate communication with other Teredo clients or hosts on the IPv6 Internet.

    The Advanced Networking Pack for Windows XP includes a Teredo client.

    Teredo server

    A Teredo server is an IPv6/IPv4 node that is connected to both the IPv4 Internet and the IPv6 Internet, supports a Teredo tunneling interface over which packets are received. The general role of the Teredo server is to help configure addresses for Teredo clients and to facilitate the initial communication between Teredo clients and other Teredo clients or between Teredo clients and IPv6-only hosts. The Teredo server listens on UDP port 3544 for Teredo traffic.

    The Advanced Networking Pack for Windows XP does not include Teredo server functionality. To facilitate communication between computers using the Advanced Networking Pack for Windows XP, Microsoft has deployed Teredo servers on the IPv4 Internet.

    Teredo relay

    A Teredo relay is an IPv6/IPv4 router that can forward packets between Teredo clients on the IPv4 Internet (using a Teredo tunneling interface) and IPv6-only hosts. In some cases, the Teredo relay interacts with a Teredo server to help it facilitate initial communication between Teredo clients and IPv6-only hosts. The Teredo relay listens on UDP port 3544 for Teredo traffic.

    The Advanced Networking Pack for Windows XP does not include Teredo relay functionality. Microsoft does not plan to deploy any Teredo relays on the IPv4 Internet. Individual Internet service providers (ISPs) could deploy their own Teredo relays. The implementation of the Teredo client in the Advanced Networking Pack for Windows XP will work with a Teredo relay when sending traffic to an IPv6-only host on the IPv6 Internet. Teredo relays are not needed to communicate with Teredo host-specific relays.

    Teredo host-specific relay

    Communication between Teredo clients and IPv6 hosts that are configured with global addresses must go through a Teredo relay. This is required for IPv6-only hosts connected to the IPv6 Internet. However, when the IPv6 host enabled for both IPv6 and IPv4 and connected to both the IPv4 Internet and IPv6 Internet, then communication should occur between the Teredo client and the IPv6 host over the IPv4 Internet, rather than having to traverse the IPv6 Internet and go through a Teredo relay.

    A Teredo host-specific relay is an IPv6/IPv4 node that has an interface and connectivity to both the IPv4 Internet and the IPv6 Internet and that 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, where IPv6 packets are tunneled across the IPv4 Internet. The Teredo host-specific relay listens on UDP port 3544 for Teredo traffic.

    The implementation of the Teredo client in the Advanced Networking Pack for Windows XP includes Teredo host-specific relay functionality. When the Advanced Networking Pack for Windows XP is installed, the Teredo host-specific relay functionality is automatically enabled if the computer running Windows XP SP1 has a global address assigned. A global address can be assigned from a Router Advertisement message from a native IPv6 router, an ISATAP router, or a 6to4 router. If the computer running Windows XP SP1 does not have a global address, Teredo client functionality is enabled.

    The Teredo host-specific relay allows Teredo clients to efficiently communicate with 6to4 hosts, IPv6 hosts with a non-6to4 global prefix, or ISATAP or 6over4 hosts within organizations that use a global prefix for their addresses, provided both hosts are using the Advanced Networking Pack for Windows XP.

    Teredo Addresses

    The following figure shows the format of Teredo addresses.

    Teredo Address Format

    A Teredo address consists of the following:

    • Teredo prefix (Prefix)

      The first 32 bits are for the Teredo prefix, which is the same for all Teredo addresses. The Internet Assigned Numbers Authority (IANA) has not yet defined this prefix, although the prefix 3FFE:831F::/32 is used for initial deployment.

    • Teredo server IPv4 address

      The next 32 bits contain the IPv4 public address of the Teredo server that helped configure this Teredo address.

    • Flags

      The next 16 bits for 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 NAT that is connected to the Internet is a cone NAT. The determination of whether the NAT that is connected to the Internet is a cone NAT occurs during the initial configuration of a Teredo client.

    • 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. The Teredo client maintains this port mapping so that it remains in the NAT’s translation table. Therefore, all Teredo traffic for the host uses the same external, mapped UDP port. The Teredo server determines the external UDP port from the source UDP port of the incoming initial packet that the Teredo client sent, and the Teredo server sends the port information back to the Teredo client.

      The external port is obscured by XORing the external port with 0xFFFF. For example, the obscured version of external port 5000 in hexadecimal format is EC77 (5000 = 0x1388, 0x1388 XOR 0xFFFF = 0xEC77). Obscuring the external port prevents NATs from translating the external port within the payload of the packets that they are forwarding.

    • 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 (public) address. The Teredo client maintains this address mapping so that it remains in the NAT’s translation table. Therefore, all Teredo traffic for the host uses the same external, mapped, public IPv4 address. The Teredo server determines the external IPv4 address from the source IPv4 address of the incoming initial packet that the Teredo client sent, and the Teredo server sends the address information back to the Teredo client.

      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 = 0x836B0001, 0x836B0001 XOR 0xFFFFFFFF = 0x7C94FFFE). Obscuring the external address prevents NATs from translating the external address within the payload of the packets that they are forwarding.

    The following figure shows an example of two Teredo clients and their addressing.

    Teredo Addressing Example

    For Teredo client A, the following are used to construct its Teredo address:

    • Its external address and port for its Teredo traffic is 157.60.0.1, UDP port 4096.

    • Its Teredo server is at the public IPv4 address of 206.73.118.1.

    • It has determined that it is behind a cone NAT.

    Therefore, using the Teredo address format of Prefix:ServerAddr:Flags:ObscExtPort:ObscExtAddr, the address for Teredo client A is 3FFE:831F:CE49:7601:8000:EFFF:62C3:FFFE. This address is based on the following:

    • CE49:7601 is the colon-hexadecimal version of 206.73.118.1.

    • 8000 is the Flags field in which the Cone flag is set to 1, indicating that Teredo client A’s

    NAT is a cone NAT.

    • EFFF is the obscured version of 4096 (0x1000).

    • 62C3:FFFE is the obscured version of 157.60.0.1.

    For Teredo client B, the following are used to construct its Teredo address:

    • Its external address and port for its Teredo traffic is 131.107.0.1, UDP port 8192.

    • Its Teredo server is at the public IPv4 address of 206.73.118.1.

    • It has determined that it is behind a restricted NAT.

    Therefore, using the Teredo address format of Prefix:ServerAddr:Flags:ObscExtPort:ObscExtAddr, the address for Teredo client B is 3FFE:831F:CE49:7601:0:DFFF:7C94:FFFE. This address is based on the following:

    • CE49:7601 is the colon-hexadecimal version of 206.73.118.1.

    • 0 is the Flags field in which the Cone flag is set to 0, indicating that Teredo client B’s NAT is a restricted NAT.

    • DFFF is the obscured version of 8192 (0x2000).

    • 7C94:FFFE is the obscured version of 131.107.0.1.

    Teredo addresses are assigned to Teredo clients only. Teredo servers, relays, and host-specific relays are not assigned Teredo addresses.

    Communicating Using a Teredo Address

    Initial configuration for Teredo clients is accomplished by sending a series of Router Solicitation messages to Teredo servers. The clients use the responses to derive a Teredo address and determine whether they are behind cone, restricted, or symmetric NATs. If a Teredo client is behind a symmetric NAT, then it cannot function. You can see what type of NAT a Teredo client has discovered from the display of the netsh interface ipv6 show teredo command.

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

    • The first 64 bits are set to the value that the Prefix Information option of the Router Advertisement message includes. The 64-bit prefix that the Teredo server advertises consists of the Teredo prefix (32 bits) 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 that a special Teredo header in the Router Advertisement message includes.

    • The last 32 bits are set to the obscured external IP address that a special Teredo header in the Router Advertisement message includes.

    The success of initial communication between Teredo clients that are located in different sites depends on whether those sites are using cone NATs or restricted NATs.

    When both Teredo clients are located behind cone NATs, the NAT translation table entries for Teredo traffic for each Teredo client allow traffic from any source IP address or source UDP port. Therefore, a Teredo client in one site can send packets directly to a Teredo client in another site without the use of additional packets to establish NAT translation table entries.

    When both Teredo clients are located behind restricted NATs, the clients must establish additional NAT translation table entries before they can exchange unicast packets. The following figure shows the initial communication process between Teredo clients that are located in different sites when both sites are using restricted NATs.

    Initial Communication Process Between Teredo Clients that Are Located in Different Sites when Both Sites Are Using Restricted NATs

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

    1. 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 the NAT translation table contains a source-specific entry. Assuming that no such entry exists, 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.

    2. 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.

    3. Teredo Server 2 forwards the bubble packet to Teredo Client B. The restricted NAT for Teredo Client B forwards the packet because a source-specific mapping exists for Teredo traffic from Teredo Server 2 (established by the initial configuration of Teredo Client B).

    4. 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.

    5. When Teredo Client A receives 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.

    This process occurs transparently to the user at Teredo Client A.