Teredo Overview

Published: January 01, 2003 | Updated: January 15, 2007

Abstract

Teredo is an IPv6 transition technology that provides address assignment and host-to-host automatic tunneling for unicast IPv6 traffic when IPv6/IPv4 hosts are located behind one or multiple IPv4 network address translators (NATs). To traverse IPv4 NATs, IPv6 packets are sent as IPv4-based User Datagram Protocol (UDP) messages. This article 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 using the IPv4 Internet, the IPv6 Internet, Teredo servers, and Teredo relays.

On This Page

Introduction
Overview of Network Address Translators (NATs)
Teredo Components
Teredo Addresses
Teredo Packet Formats
Teredo Routing
Teredo Processes
Using Teredo in Windows XP Service Pack 2
Summary
Related Links

Introduction

Teredo is an address assignment and automatic tunneling technology that provides unicast IPv6 connectivity across the IPv4 Internet. 6to4 is another automatic tunneling technology that provides unicast IPv6 connectivity across the IPv4 Internet. However, 6to4 works well 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 use an IPv4 network address translator (NAT) for Internet connectivity. For more information about how network address translation works, see "Overview of Network Address Translators (NATs)" in this article. In most NAT configurations, the device providing NAT functionality is not capable of acting as a 6to4 router. Even if 6to4 was universally supported in Internet edge devices, there are some Internet connectivity configurations that contain multiple levels of NATs. A 6to4-capable edge device cannot use 6to4 if it is not assigned a public IPv4 address.

Teredo solves the issues of the lack of 6to4 functionality in modern-day Internet edge devices and multi-layered NAT configurations by tunneling IPv6 packets between the hosts within the sites. In contrast, 6to4 tunnels IPv6 packets between the edge devices. Tunneling from the hosts presents another issue for NATs: IPv6 packets that are encapsulated with IPv4 have 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 NAT editors installed that handle the translation. Because Protocol 41 translation is not a common feature of NATs, IPv4-encapsulated IPv6 traffic will not flow through typical NATs. Therefore, to allow IPv6 traffic to flow through one or multiple NATs, Teredo encapsulates the IPv6 packet as an IPv4 UDP message, containing both an IPv4 and UDP header. UDP messages can be translated universally by NATs and can traverse multiple layers of NATs.

To summarize, Teredo is an IPv6 transition technology that allows automatic IPv6 tunneling between hosts that are located across one or more IPv4 NATs. IPv6 traffic from Teredo hosts can flow across NATs because it is sent as an IPv4 UDP message. If the NAT supports UDP port translation, then the NAT supports Teredo. The exception is a symmetric NAT, which is described in "Types of NATs" in this article.

Teredo is designed as a last resort transition technology for IPv6 connectivity. If native IPv6, 6to4, or Intrasite Automatic Tunnel Addressing Protocol (ISATAP) connectivity is present, the host does not act as a Teredo client. As more IPv4 edge devices are upgraded to support 6to4 and IPv6 connectivity becomes ubiquitous, Teredo will be used less and less until finally it is not used at all.

Benefits of Using Teredo

Teredo is a NAT traversal technology for IPv6 traffic. IPv6 traffic tunneled using Teredo can cross one or multiple NATs and allow a Teredo client to access the hosts on the IPv6 Internet (through a Teredo relay) and other Teredo clients on the IPv4 Internet. The ability to connect to other Teredo clients that are connected to the IPv4 Internet enables communication between applications that would otherwise have problems communicating over a NAT. With Teredo, IPv6-enabled applications can successfully communicate more frequently over the IPv4 Internet than IPv4-only applications.

Some types of IPv4-only server or peer applications have problems communicating when running on a computer that is behind a NAT. For more information, see Problems with Using Network Address Translators. These types of applications either require manual configuration of the NAT (to allow unsolicited incoming traffic to the server or peer computer on the private network) or the application must provide its own solution for NAT traversal.

If the application is IPv6-capable, it can use Teredo. There is no need to either configure the NAT or modify the application to perform its own NAT traversal. Therefore, rather than spending development time modifying applications for a custom NAT traversal solution, application vendors should update their applications to be IPv6-capable. If the application is already IPv6-capable, it can use Teredo, the NAT traversal solution for Windows.

Teredo Support in Microsoft Windows

The following table lists the versions of Microsoft® Windows® that include a Teredo client and host-specific relay and whether IPv6 and Teredo is enabled by default.

Version of Windows	IPv6 enabled by default?	Teredo enabled by default?
Windows XP with Service Pack 1 (SP1) with the Advanced Networking Pack for Windows XP	No	No
Windows XP Service Pack 2 (SP2)	No	No
Windows Server® 2003 Service Pack 1	No	No
Windows Vista™	Yes	Yes (In Windows Vista, the Teredo component is enabled but inactive by default. In order to become active, a user must either install an application that needs to use Teredo, or configure advanced Windows Firewall filter settings to allow edge traversal.)
Windows Server Code Name "Longhorn" (now in beta testing)	Yes	No

All implementations of Teredo in Windows are based on RFC 4380.

To use Teredo functionality in Windows XP Service Pack 2 or Windows Server 2003 Service Pack 1, see the “Using Teredo in Windows XP Service Pack 2” section of this article.

For information about changes to Teredo for Windows Vista and Windows Server "Longhorn," see Changes to IPv6 in Windows Vista and Windows Server "Longhorn".

Note:  This article assumes knowledge of IPv6 and IPv6 transition technologies. For more information, see Introduction to IPv6 and IPv6 Transition Technologies.

Teredo and Protection from Unsolicited Incoming IPv6 Traffic

As described in Using IPv6 and Teredo, IPv6 traffic that is tunneled with Teredo is not subject to the IPv4 packet filtering function of typical NATs. Although this might sound like Teredo is bypassing the NAT and allowing potentially malicious IPv6 traffic on private networks, consider the following:

• Teredo does not change the behavior of NATs. Teredo clients create dynamic NAT translation table entries for their own Teredo traffic. The NAT forwards incoming Teredo traffic to the host that created the matching NAT translation table entry. The NAT will not forward Teredo traffic to computers on the private network that are not Teredo clients.

• Teredo clients that use a host-based, stateful firewall that supports IPv6 traffic, such as Windows Firewall, are protected from unsolicited, unwanted, incoming IPv6 traffic. Windows Firewall is enabled by default for Windows XP with SP2, Windows Vista, and Windows Server "Longhorn."

The combination of IPv6, Teredo, and a host-based, stateful, IPv6 firewall does not affect the packet filtering function of the NAT for IPv4-based traffic and does not make your Windows-based computer more susceptible to attacks by malicious users and programs that use IPv6 traffic, rather than IPv4 traffic.

Overview of Network Address Translators (NATs)

A network address translator (NAT) is an IPv4 router defined in RFC 1631 that can translate the IP addresses and TCP/UDP port numbers of packets as they are forwarded. For example, consider a small business network with multiple computers that connect to the Internet. This business would normally have to obtain a public IP address for each computer on the network from an Internet service provider (ISP). 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:

• You want to leverage the use of a single connection, rather than connecting multiple computers, to the Internet.

• You want to use private addressing.

• You want 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: Internet resource IP address

• Source IP Address: Private IP address

• Destination Port: Internet resource TCP or UDP port

• 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: Internet resource IP address

• Source IP Address: ISP-allocated public address

• Destination Port: Internet resource TCP or UDP port

• 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. When it is received by the NAT, the packet contains the following addressing information:

• Destination IP Address: ISP-allocated public address

• Source IP Address: Internet resource IP address

• Destination Port: Remapped source application TCP or UDP port

• Source Port: Internet resource TCP or UDP port

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

• Destination IP Address: Private IP address

• Source IP Address: Internet resource IP address

• Destination Port: Source application TCP or UDP port

• Source Port: Internet resource TCP or UDP port

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

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 IP 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 IP packet over the Internet. The Web server sends back a response to the NAT. When it is received by the NAT, the packet contains the following addressing information:

• Destination IP Address: 131.107.0.1

• Source IP Address: 157.50.0.1

• Destination Port: 5000

• Source Port: 80

When the NAT maps and translates the addresses, and forwards the packet to the intranet client, it 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

Figure 1 shows the configuration for this example.

Figure 1: NAT example

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

1. Dynamic mappings

   Created when private network clients initiate communications. Dynamic mappings are removed from the NAT translation table after a specified amount of time, unless refreshed by traffic that corresponds to the NAT translation table entry.

2. Static mappings

   Configured manually so that communications initiated by Internet clients can be mapped to a specific private network address and port. Static mappings are needed when there are servers (for example, Web servers) or applications (for example, games) on the private network that you want to make available to computers that are connected to the Internet. Static mappings are not removed from the NAT translation table.

The NAT only forwards traffic from the Internet to the private network if a mapping exists in the NAT translation table. In this way, the NAT provides a simple, stateful, packet filtering function for the computers on the private network.

Types of NATs

The following types of NATs are defined:

• 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. Once 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 allowed and 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 that matches the NAT translation table entry for the external destination address and port number 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 works well over cone and restricted NATs. Teredo in Windows XP SP2, Windows XP SP1 and the Advanced Networking Pack for Windows XP, and Windows Server 2003 Service Pack 1 cannot work over symmetric NATs. Teredo in Windows Vista and Windows Server "Longhorn" can work between Teredo clients if only one Teredo client is behind one or more symmetric NATs. For example, Teredo in Windows Vista and Windows Server "Longhorn" will work if one of the peers is behind a symmetric NAT and the other is behind a cone or restricted NAT.

Teredo Components

The Teredo infrastructure consists of the following components (as shown in Figure 2):

• Teredo clients

• Teredo servers

• Teredo relays

• Teredo host-specific relays

  

  Figure 2: 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 (via 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.

Windows XP SP2, Windows XP SP1 with the Advanced Networking Pack for Windows XP, Windows Server 2003 with Service Pack 1, Windows Vista, and Windows Server "Longhorn" include 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 assist in the address configuration of Teredo client 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.

For more information about the role of the Teredo server in facilitating initial communication, see "Teredo Processes" in this article.

Windows XP SP2, Windows XP SP1 with the Advanced Networking Pack for Windows XP, Windows Server 2003 with Service Pack 1, Windows Vista, and Windows Server "Longhorn" do not include Teredo server functionality. To facilitate communication between Windows-based Teredo client computers, Microsoft has deployed Teredo servers on the IPv4 Internet. To obtain an update for Teredo Server functionality, contact Microsoft.

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.

For more information about the role of the Teredo relay in facilitating initial and ongoing communication between Teredo clients and IPv6-only hosts, see "Teredo Processes" in this article.

Windows XP SP2, Windows XP SP1 with the Advanced Networking Pack for Windows XP, Windows Server 2003 with Service Pack 1, Windows Vista, and Windows Server "Longhorn" do 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 Windows-based Teredo client 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 a global address must go through a Teredo relay. This is required for IPv6-only hosts connected to the IPv6 Internet. However, when the IPv6 host is IPv6 and IPv4-capable 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 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.

Windows XP SP2, Windows XP SP1 with the Advanced Networking Pack for Windows XP, Windows Server 2003 with Service Pack 1, Windows Vista, and Windows Server "Longhorn" include Teredo host-specific relay functionality, which is automatically enabled if the computer has a global address assigned. A global address can be assigned from a received Router Advertisement message from a native IPv6 router, an ISATAP router, or a 6to4 router. If the computer 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 a version of Windows that supports Teredo.

Teredo Addresses

Teredo addresses have the format as shown in Figure 3.

Figure 3: Teredo address format

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. Windows XP and Windows Server 2003 initially used the 3FFE:831F::/32 Teredo prefix. The prefix defined for Teredo in RFC 4380 is 2001::/32 and is the prefix used by Teredo in Windows Vista and Windows Server "Longhorn." Computers running Windows XP and Windows Server 2003 will use the 2001::/32 Teredo 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 helped configure this Teredo address. For more information, see "Initial configuration for Teredo clients" in this article.

• Flags

  The next 16 bits for are reserved for Teredo flags. For Windows XP-based Teredo clients, the only defined flag is the high order bit known as the Cone flag. The Cone flag is set when Teredo client is behind a cone NAT. The determination of whether the NAT connected to the Internet is a cone NAT occurs during the Teredo client's initial configuration. For more information, see "Initial configuration for Teredo clients" in this article.

  For Windows Vista and Windows Server "Longhorn"-based Teredo clients, unused bits within the Flags field provide a level of protection from address scans by malicious users. The 16 bits within the Flags field for Windows Vista and Windows Server "Longhorn"-based Teredo clients consists of the following: CRAAAAUG AAAAAAAA. The C bit is for the Cone flag. The R bit is reserved for future use. The U bit is for the Universal/Local flag (set to 0). The G bit is Individual/Group flag (set to 0). The A bits are set to a 12-bit randomly generated number. By using a random number for the A bits, a malicious user that has determined the rest of the Teredo address by capturing the initial configuration exchange of packets between the Teredo client and Teredo server will have to try up to 4,096 (212) different addresses to determine a Teredo client's address during an address scan.

• Obscured external port

  The next 16 bits store an obscured version of the external UDP port corresponding 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 external UDP port is determined by the Teredo server from the source UDP port of the incoming initial packet sent by the Teredo client and sent back to the Teredo client.

  The external port is obscured by XORing the external port with 0xFFFF. For example, the obscured version of the 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 corresponding 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 external IPv4 address is determined by the Teredo server from the source IPv4 address of the incoming initial packet sent by the Teredo client and sent 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.

Figure 4 shows an example Teredo configuration with two Teredo clients, one Teredo client located behind a cone NAT (Teredo client A) and one located behind a restricted NAT (Teredo client B).

Figure 4: Teredo addressing example

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

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

• It is behind a cone NAT.

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

Therefore, using the Teredo address format of 2001::ServerAddr:Flags:ObscExtPort:ObscExtAddr, a Teredo address for Teredo client A is 2001::CE49:7601:E866:EFFF:62C3:FFFE. This is based on the following:

• The 2001::/32 prefix that is used for Teredo in Windows Vista, Windows Server "Longhorn," and Windows XP with the Microsoft Security Bulletin MS06-064 installed. Windows XP-based Teredo clients initially used 3FFE:831F::/32 as the Teredo prefix.

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

• E866 is the Flags field in which the Cone flag is set to 1 (indicating that Teredo Client A is located behind a cone NAT), the U and G flags are set to 0, and the remaining 12 bits are set to a random sequence to help prevent external address scans. For a Windows XP-based Teredo client without the Microsoft Security Bulletin MS06-064 installed, the Flags field would be set to 8000.

• EFFF is the obscured version of UDP port 4096.

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

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

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

• It is behind a restricted NAT.

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

Therefore, a Teredo address for Teredo Client B is 2001::CE49:7601:2CAD:DFFF:7C94:FFFE. This is based on the following:

• The 2001::/32 Teredo prefix.

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

• 2CAD is the Flags field in which the Cone flag is set to 0 (indicating that Teredo Client B is located behind a restricted NAT), the U and G flags are set to 0, and the remaining 12 bits are set to a random sequence to help prevent external address scans. For a Windows XP-based Teredo client without the Microsoft Security Bulletin MS06-064 installed, the Flags field would be set to 0.

• DFFF is the obscured version of UDP port 8192.

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

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

Teredo Packet Formats

This section describes the following:

• Teredo data packet format

• Teredo bubble packets

• Teredo indicators

Teredo data packet format

Figure 5 shows the format of Teredo data packets.

Figure 5: Teredo data packet format

A Teredo packet consists of the following:

• The IPv4 header contains the source and destination IPv4 addresses corresponding to the automatic tunnel endpoints and can be translated by a NAT.

• The UDP header contains source and destination UDP ports for Teredo traffic and can be translated by a NAT.

• The IPv6 header contains the source and destination IPv6 addresses, at least one of which is a Teredo address.

• The IPv6 payload contains zero or more IPv6 extension headers and the upper layer protocol data unit (PDU) of the encapsulated IPv6 packet.

Teredo bubble packets

A Teredo bubble packet is typically sent to create or maintain a NAT mapping and consists of an IPv6 header with no IPv6 payload. Figure 6 shows the Teredo bubble packet.

Figure 6: Teredo bubble packet

In the IPv6 header, the Next Header field is set to 59, indicating that there is no payload present.

Teredo indicators

Teredo uses two different indicators, which are headers that are used to contain authentication or address and port information.

Authentication indicator

The Authentication indicator is used to secure the exchange of Router Solicitation and Router Advertisement messages between a Teredo client and a Teredo server. Both the Teredo client and the Teredo server are configured with a secret key, which is used to construct the authentication data in the Authentication indicator. The Authentication indicator is placed between the UDP header and the IPv6 packet. If both the Origin and Authentication indicators are present in the Router Advertisement message, the Authentication indicator is placed before the Origin indicator.

The Authentication indicator has the structure as shown in Figure 7.

Figure 7: Structure of the Authentication indicator

The Authentication indicator contains the following fields:

• Indicator Type

  This two-byte field specifies the type of indicator. For the Authentication indicator, it is set to 1. The Teredo client and the Teredo server can distinguish the Authentication indicator from the first two bytes of an IPv6 packet because the four high-order bits of an IPv6 packet are set to 0110 (6), which correspond to the Version field of the IPv6 header.

• Client ID Length

  This one-byte field indicates the length of the Client Identification field.

• Authentication Data Length

  This one-byte field indicates the length of the Authentication Value field.

• Client Identification

  This variable-length field contains an identification string for the Teredo client.

• Authentication Value

  This variable-length field contains the authentication value for this packet, calculated using the shared secret key.

• Nonce

  This eight-byte field contains a random number, which is used to provide proof of a live exchange of packets and to prevent packet replay attacks.

• Confirmation

  This one-byte field contains a value that indicates whether the Teredo client is using the correct secret key. In the Router Solicitation message, the Confirmation field is set to 0. In the Router Advertisement, the Confirmation field is set to either 0 if the secret key is correct or a non-zero value if it is not.

In Windows XP SP2, Windows XP SP1 with the Advanced Networking Pack for Windows XP, Windows Server 2003 with Service Pack 1, Windows Vista, and Windows Server "Longhorn," Teredo does not use a client identifier or an authentication value, although the Authentication indicator is still present in the Router Advertisement (RA) and Router Solicitation (RS) messages. When there is no client identifier or authentication value, the Authentication indicator has the format as shown in Figure 8.

Figure 8: Structure of the Authentication indicator when there is no client identifier or authentication value

Origin indicator

The Origin indicator is used to indicate an IPv4 address and UDP port number of a Teredo client, Teredo relay, or Teredo host-specific relay. An example of its use is when a Teredo server sends a RA message in response to a Teredo client's RS message. In this case, the Origin indicator contains the mapped IPv4 address and UDP port number corresponding to the Teredo traffic of a Teredo client. For more information, see "Initial configuration for Teredo clients" in this article.

Like the Authentication indicator, the Origin indicator is placed between the UDP header and the IPv6 packet. The Origin indicator has the structure as shown in Figure 9.

Figure 9: Structure of the Origin indicator

The Origin indicator contains the following fields:

• Indicator Type

  This two-byte field specifies the type of indicator. For the Origin indicator, it is set to 0. The Teredo client can distinguish the Origin indicator from the first two bytes of an IPv6 packet because the four high-order bits of an IPv6 packet are set to 0110 (6), which correspond to the Version field of the IPv6 header.

• Obscured Origin Port Number

  This two-byte field contains the obscured (XORed with 0xFFFF) external port corresponding to the Teredo traffic of a Teredo client, Teredo relay, or Teredo host-specific relay. To obtain the original port number, the value of the Obscured Origin Port Number field is XORed with 0xFFFF.

• Obscured Origin Address

  This four-byte field contains the obscured (XORed with 0xFFFFFFFF) external IPv4 address corresponding to the Teredo traffic Teredo client, Teredo relay, or Teredo host-specific relay. To obtain the original address, the value of the Obscured Origin Address field is XORed with 0xFFFFFFFF.

Figure 10 shows the three different types of packets that contain the Origin and Authentication indicators as implemented for the Windows Teredo client.

Figure 10: Types of packets containing the Authentication or Origin indicators

Teredo Routing

Figure 11 shows the routes that exist to enable the propagation of Teredo packets between Teredo hosts, Teredo servers, Teredo relays, Teredo host-specific relays, and IPv6-only hosts.

Figure 11: Teredo routes

On the IPv6 Internet, 2001::/32 routes in the routing infrastructure are used to forward packets using the defined Teredo prefix to the nearest Teredo relay. Teredo servers, Teredo relays, and Teredo host-specific relays have a 2001::/32 route, which considers all addresses using the prefix as on-link and using the Teredo tunneling interface. The Teredo tunneling interface is a logical interface that performs automatic IPv4 and UDP encapsulation for forwarded packets. Teredo servers, Teredo relays, and Teredo host-specific relays also have a default route (::/0) that points to the IPv6 Internet. Typically, this default route contains a next-hop IPv6 address of a neighboring router on the IPv6 Internet using a physical interface that is connected to the IPv6 Internet.

Routing for Teredo clients

The Teredo client in Windows XP SP2, Windows XP SP1 with the Advanced Networking Pack for Windows XP, Windows Server 2003 with Service Pack 1, Windows Vista, and Windows Server "Longhorn" has a default route (::/0) that considers all addresses using the prefix as on-link and using the Teredo tunneling interface. When this default route is used, the next-hop address is set to the destination address in the IPv6 packet and the next-hop interface is set to the Teredo tunneling interface.

When the Teredo tunneling interface forwards the packet, it distinguishes the following three cases:

1. The destination is a Teredo client on the same IPv4 link.

2. The destination is a Teredo client that is in another site.

3. The destination is a node on the IPv6 Internet.

On-link Teredo destination

For packets destined for another Teredo host in the same site and on the same link, the Teredo tunneling interface uses an exchange of bubble packets as the substitute for the address resolution process of Neighbor Discovery. The exchange of bubble packets assures each Teredo client that they can begin sending packets directly to each other. For more information, see "Initial communication between Teredo hosts on the same link" in this article.

To determine whether a destination Teredo address corresponds to a Teredo client on the same link, it checks its multicast bubble cache. Each Teredo client sends out multicast bubble packets on its IPv4 link used to communicate with Teredo servers to indicate its presence on the link. Each Teredo client receives the multicast bubble packets of other Teredo clients and adds their Teredo addresses and IPv4 addresses to the multicast bubble cache. Therefore, if the destination Teredo address is in the multicast bubble cache, the destination is an on-link neighbor.

Inter-site Teredo destination

For packets destined for another Teredo host in a different site, the Teredo tunneling interface uses bubble packets as the substitute for the address resolution process of Neighbor Discovery when both Teredo hosts are across restricted NATs. The exchange of bubble packets creates address and port-specific mappings in both restricted NATs so that the two Teredo clients can send packets directly to each other. For more information, see "Initial communication between Teredo clients in different sites" in this article.

IPv6 Internet destination

For packets destined for the IPv6 Internet, the Teredo tunneling interface uses ICMPv6 Echo Request and Echo Reply messages as substitute for the address resolution process of Neighbor Discovery. An ICMPv6 Echo Request message is sent to the destination. The ICMP Echo Reply message that is returned contains the IPv4 address of the Teredo relay closest to the IPv6 host on the IPv6 Internet. For more information, see "Initial communication from a Teredo client to a Teredo host-specific relay" and "Initial communication from a Teredo client to an IPv6-only host" in this article.

Teredo Processes

This section provides details on the set of Teredo packets exchanged to perform the following:

• Initial configuration for Teredo clients

• Maintaining the NAT mapping

• Initial communication between Teredo clients on the same link

• Initial communication between Teredo clients in different sites

• Initial communication from a Teredo client to a Teredo host-specific relay

• Initial communication from a Teredo host-specific relay to a Teredo client

• Initial communication from a Teredo client to an IPv6-only host

• Initial communication from an IPv6-only host to a Teredo client

All of these processes are supported by the Teredo client in Windows XP SP2, Windows XP SP1 with the Advanced Networking Pack for Windows XP, Windows Server 2003 with Service Pack 1, Windows Vista, and Windows Server "Longhorn" and are performed automatically, without requiring configuration or intervention from the user. The only exception is the optional configuration of the IPv4 address of a Teredo server.

Initial configuration for Teredo clients

Initial configuration for Teredo clients is accomplished by sending a series of Router Solicitation messages to Teredo servers to determine a Teredo address and whether the client is behind a cone, restricted, or symmetric NAT. Figure 12 shows the initial configuration process.

Figure 12: Initial configuration for Teredo clients

The initial configuration for Teredo clients consists of the following process:

1. A Router Solicitation (RS) message is sent from the Teredo Client to a preferred Teredo server (Teredo server 1). The Teredo Client sends the RS from a link-local address for which the Cone flag is set.

2. Teredo Server 1 responds with a Router Advertisement (RA) message. Because the RS had the Cone flag set, Teredo Server 1 sends the RA from an alternate IPv4 address. If the Teredo Client receives the RA, then it determines that it is behind a cone NAT.

3. If an RA is not received, the Teredo Client sends another RS from a link-local address for which the Cone flag is not set.

4. Teredo Server 1 responds with an RA. Because the RS had the Cone flag not set, Teredo Server 1 sends the RA from the source IPv4 address corresponding to the destination IPv4 address of the RS. If the Teredo Client receives the RA, then it determines that it is behind a restricted NAT.

5. To ensure that the Teredo Client is not behind a symmetric NAT, it sends another RA to a secondary Teredo server (Teredo Server 2).

6. Teredo Server 2 responds with an RA. The Teredo Client compares the mapped addresses and UDP ports in the Origin indicators of the RAs received by both Teredo servers. If they are different, then the NAT is mapping the same internal address and port number to different external addresses and port numbers. The Teredo Client determines that the NAT is a symmetric NAT and cannot use Teredo to communicate.

Based on the received RA (step 2 or 4 in the previous process), 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 RA. The 64-bit prefix advertised by the Teredo server consists of the Teredo prefix (32 bits) and the IPv4 address of the Teredo server (32 bits).

• The next 16 bits are the Flags field

• The next 16 bits are set to the external UDP port number from the Origin indicator in the RA

• The last 32 bits are set to the external IP address from the Origin indicator in the RA

The Teredo client in Windows XP SP2, Windows XP SP1 with the Advanced Networking Pack for Windows XP, Windows Server 2003 with Service Pack 1, Windows Vista, and Windows Server "Longhorn" automatically attempts to determine the IPv4 addresses of Teredo servers by resolving the name teredo.ipv6.microsoft.com. Alternately, you can use the netsh interface ipv6 set teredo servername= command to configure the IPv4 address of a Teredo server.

Maintaining the NAT mapping

Figure 13 shows how Teredo clients maintain the NAT mapping for Teredo traffic.

Figure 13: Maintaining the NAT mapping

On a periodic basis (by default every 30 seconds), Teredo clients send a single bubble packet to the Teredo server. The Teredo server discards the bubble packet and sends a response. The periodic bubble packet refreshes the IP address/UDP port mapping in the NAT's translation table. Otherwise, the mapping becomes stale and is removed. If the mapping is not present, all inbound Teredo traffic (for a cone NAT) or inbound Teredo traffic from the Teredo server (restricted NAT) to the Teredo host is silently discarded by the NAT. From the response, the Teredo client can determine if the external address and port number for its Teredo traffic have changed.

Initial communication between Teredo clients on the same link

Figure 14 shows the initial communication between Teredo clients on the same link.

Figure 14: Initial communication between Teredo clients on the same link

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

1. Teredo Client A sends a bubble packet to the Teredo IPv4 Discovery Address, a reserved IPv4 multicast address (actual address is to be determined by IANA). In the IPv6 header of the bubble packet, the destination address is set to Teredo Client B's Teredo address.

2. Upon receipt of the multicast bubble packet from Teredo Client A, Teredo Client B determines the on-link IPv4 address of Teredo Client A and the UDP port used for Teredo traffic and sends a unicast bubble packet to Teredo Client A in response. Upon receipt of the unicast bubble packet from Teredo Client B, Teredo Client A determines the on-link IPv4 address of Teredo Client A and the UDP port used for Teredo traffic.

3. Teredo Client A sends an initial communication packet to Teredo Client B.

Initial communication between Teredo clients in different sites

Initial communication between Teredo clients in different sites depends on whether the sites are using cone NATs or restricted NATs.

Cone NAT

Figure 15 shows the initial communication between Teredo clients in different sites when both sites are using cone NATs.

Figure 15: Initial communication between Teredo clients in different sites with cone NATs

When both Teredo clients are located behind cone NATs, the NAT translation table entry for Teredo traffic for each Teredo client allows traffic from any source IP address or source UDP port. Therefore, Teredo Client A can send packets directly to Teredo Client B without the use of bubble packets to establish additional NAT translation table entries.

Restricted NAT

Figure 16 shows the initial communication between Teredo clients in different sites when both sites are using restricted NATs.

Figure 16: Initial communication between Teredo clients in different sites with 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. 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.

2. Teredo Client A sends a bubble packet to Teredo Client B via Teredo Server 2 (Teredo Client B's Teredo server). The IPv4 destination address in the bubble 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 processes the packet, determines that the IPv6 destination address is for a Teredo client, and then 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.

4. Teredo Client B responds to the bubble packet received from Teredo Client A with its own bubble packet 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), the bubble packet is forwarded to Teredo Client A.

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

Initial communication from a Teredo client to a Teredo host-specific relay

Initial communication from a Teredo client to a Teredo host-specific relay depends on whether the Teredo client is behind a cone NAT or restricted NAT.

Cone NAT

Figure 17 shows the initial communication from a Teredo client to a Teredo host-specific relay when the Teredo client is located behind a cone NAT.

Figure 17: Initial communication from a Teredo client to a Teredo host-specific relay with a cone NAT

To send an initial communication packet from the Teredo Client to the Teredo Host-Specific Relay, the following process is used:

1. Teredo Client A sends an ICMPv6 Echo Request message to the Teredo Host-Specific Relay via its own Teredo Server.

2. The Teredo Server receives the ICMPv6 Echo Request message and forwards it to the Teredo Host-Specific Relay over the IPv6 Internet or tunneled over the IPv4 Internet.

3. The Teredo Host-Specific Relay responds with an ICMPv6 Echo Reply sent to Teredo Client A's Teredo address. Because the Teredo Host-Specific Relay has a Teredo route (2001::/32) and a Teredo tunneling interface, the Teredo Host-Specific Relay sends the packet directly to Teredo Client A.

4. After receiving the Echo Reply from the Teredo Host-Specific Relay, the Teredo Client sends an initial communication packet to the IPv4 address and UDP port of the Teredo Host-Specific Relay.

All subsequent packets between the Teredo Client and the Teredo Host-Specific Relay are sent directly.

Restricted NAT

Figure 18 shows the initial communication from a Teredo client to a Teredo host-specific relay when the Teredo client is located behind a restricted NAT.

Figure 18: Initial communication from a Teredo client to a Teredo host-specific relay with a restricted NAT

To send an initial communication packet from the Teredo Client to the Teredo Host-Specific Relay, the following process is used:

1. The Teredo Client sends an ICMPv6 Echo Request message to the Teredo Host-Specific Relay via its own Teredo Server.

2. The Teredo Server receives the ICMPv6 Echo Request message and forwards it to the Teredo Host-Specific Relay over the IPv6 Internet or tunneled over the IPv4 Internet.

3. The Teredo Host-Specific Relay determines that the Teredo Client is behind a restricted NAT. If the Teredo Relay were to send the ICMPv6 Echo Request message to the Teredo Client, the NAT would silently discard it because there is no source-specific mapping for Teredo traffic from the Teredo Host-Specific Relay. Therefore, the Teredo Host-Specific Relay sends a bubble packet to the Teredo Client via the Teredo Server over the IPv4 Internet.

4. The Teredo Server receives the bubble packet from the Teredo Host-Specific Relay. The Teredo Server forwards the bubble packet to the Teredo Client, with an Origin indicator that contains the IPv4 address and UDP port number of the Teredo Host-Specific Relay. Because a source-specific mapping for Teredo traffic from the Teredo Server exists in the NAT, the bubble packet is forwarded to the Teredo Client.

5. The Teredo Client determines the IPv4 address and UDP port of the Teredo Host-Specific Relay from the Origin indicator of the received bubble packet. To establish a source-specific mapping for Teredo traffic from the Teredo Host-Specific Relay, the Teredo Client sends a bubble packet to the Teredo Host-Specific Relay.

6. Based on the receipt of the bubble packet from the Teredo Client that corresponds to a packet that is queued for forwarding (the ICMPv6 Echo Reply message), the Teredo Host-Specific Relay determines that a source-specific NAT mapping now exists in the restricted NAT of the Teredo Client. The Teredo Host-Specific Relay forwards the ICMPv6 Echo Reply message to the Teredo Client.

7. An initial communication packet is sent from the Teredo Client to the IPv4 address and UDP port of the Teredo Host-Specific Relay.

All subsequent packets between the Teredo Client and the Teredo Host-Specific Relay are sent directly.

Initial communication from a Teredo host-specific relay to a Teredo client

Initial communication from a Teredo host-specific relay to a Teredo client depends on whether the Teredo client is behind a cone NAT or restricted NAT.

Cone NAT

Figure 19 shows the initial communication from a Teredo host-specific relay to a Teredo client when the Teredo client is located behind a cone NAT.

Figure 19: Initial communication from a Teredo host-specific relay to a Teredo client with a cone NAT

To send an initial communication packet from the Teredo Host-Specific Relay to the Teredo Client, the Teredo Host-Specific Relay determines that the Teredo Client is behind a cone NAT. Therefore, it sends the initial communication packet directly to the Teredo Client.

To ensure that the IPv6 address of the initial communication packet has not been spoofed and corresponds to the Teredo Host-Specific Relay, the Teredo Client performs an ICMPv6 Echo Request/Echo Reply message exchange with the Teredo Host Specific Relay using steps 1-3 of the "Initial communication from a Teredo client to a Teredo host-specific relay" (for a cone NAT) section of this article. After this exchange is complete, the Teredo Client sends the response to the initial communication packet to the Teredo Host-Specific Relay.

Restricted NAT

Figure 20 shows the initial communication from a Teredo host-specific relay to a Teredo client when the Teredo client is located behind a restricted NAT.

Figure 20: Initial communication from a Teredo host-specific relay to a Teredo client with a restricted NAT

To send an initial communication packet from the Teredo Host-Specific Relay to the Teredo Client, the following process is used:

1. The Teredo Host-Specific Relay sends a bubble packet to the Teredo Client via the Teredo Server over the IPv4 Internet.

2. The Teredo Server receives the bubble packet from the Teredo Host-Specific Relay. The Teredo Server forwards the bubble to the Teredo Client, with an Origin indicator that contains the IPv4 address and UDP port number of the Teredo Host-Specific Relay. Because a source-specific mapping for Teredo traffic from the Teredo Server exists in the NAT, the bubble packet is forwarded to the Teredo Client.

3. The Teredo Client determines the IPv4 address and UDP port of the Teredo Host-Specific Relay from the Origin indicator of the received bubble packet. To establish a source-specific mapping for Teredo traffic from the Teredo Relay, the Teredo Client sends a bubble packet to the Teredo Host-Specific Relay.

4. Based on the receipt of the bubble packet that corresponds to a packet that is queued for forwarding (the packet from the Teredo Host-Specific Relay), the Teredo Host-Specific Relay determines that a source-specific NAT mapping now exists in the restricted NAT of the Teredo Client. The Teredo Host-Specific Relay sends the initial communication packet to the Teredo Client.

To ensure that the IPv6 address of the initial communication packet has not been spoofed and corresponds to the Teredo Host-Specific Relay, the Teredo Client performs an ICMPv6 Echo Request/Echo Reply message exchange with the Teredo Host Specific Relay using steps 1-6 of the "Initial communication from a Teredo client to a Teredo host-specific relay" (for a restricted NAT) section of this article. After this exchange is complete, the Teredo Client sends the response to the initial communication packet to the Teredo Host-Specific Relay.

Initial communication from a Teredo client to an IPv6-only host

Initial communication from a Teredo client to an IPv6-only host depends on whether the Teredo client is behind a cone NAT or restricted NAT.

Cone NAT

Figure 21 shows the initial communication from a Teredo client to an IPv6-only host when the Teredo client is located behind a cone NAT.

Figure 21: Initial communication from a Teredo client to an IPv6-only host with a cone NAT

To send an initial communication packet from the Teredo Client to the IPv6-only Host, the following process is used:

1. To send an initial communication packet to the IPv6-only Host, the Teredo Client must first determine the IPv4 address and UDP port of the Teredo relay that is nearest to the IPv6-only Host. Teredo Client A sends an ICMPv6 Echo Request message to the IPv6-only Host via its own Teredo Server.

2. The Teredo Server receives the ICMPv6 Echo Request message and forwards it to the IPv6-only Host over the IPv6 Internet.

3. The IPv6-only Host responds with an ICMPv6 Echo Reply sent to Teredo Client A's Teredo address. Due to the routing infrastructure of the IPv6 Internet, the Teredo-addressed packet is forwarded to the nearest Teredo relay.

4. The Teredo Relay encapsulates the ICMPv6 Echo Reply message and sends it directly to the Teredo Client. Because the NAT is a cone NAT, the packet from the Teredo Relay is forwarded to the Teredo Client.

5. The Teredo Client determines the IPv4 address of the Teredo Relay closest to the IPv6-only Host from the source IPv4 address and UDP port of the ICMPv6 Echo Reply message. An initial communication packet is sent from the Teredo Client to the IPv4 address and UDP port of the Teredo Relay.

6. The Teredo Relay removes the IPv4 and UDP headers and forwards the packet to the IPv6-only Host.

All subsequent packets sent between the Teredo Client and the IPv6-only Host takes this path via the Teredo Relay.

Restricted NAT

Figure 22 shows the initial communication from a Teredo client to an IPv6-only host when the Teredo client is located behind a restricted NAT.

Figure 22: Initial communication from a Teredo client to an IPv6-only host with a restricted NAT

To send an initial communication packet from the Teredo Client to the IPv6-only Host, the following process is used:

1. To send an initial communication packet to the IPv6-only Host, the Teredo Client must first determine the IPv4 address of the Teredo relay that is nearest to the IPv6-only Host. Teredo Client A sends an ICMPv6 Echo Request message to the IPv6-only Host via its own Teredo Server.

2. The Teredo Server receives the ICMPv6 Echo Request message and forwards it to the IPv6-only Host over the IPv6 Internet.

3. The IPv6-only Host responds with an ICMPv6 Echo Reply sent to Teredo Client A's Teredo address. Due to the routing infrastructure of the IPv6 Internet, the Teredo-addressed packet is forwarded to the nearest Teredo relay.

4. The Teredo Relay determines that the Teredo Client is behind a restricted NAT. If the Teredo Relay were to send the ICMPv6 Echo Request message to the Teredo Client, the NAT would silently discard it because there is no source-specific mapping for Teredo traffic from the Teredo Relay. Therefore, the Teredo Relay sends a bubble packet to the Teredo Client via the Teredo Server over the IPv4 Internet.

5. The Teredo Server receives the bubble packet from the Teredo Relay. The Teredo Server forwards the bubble packet to the Teredo Client, with an Origin indicator that contains the IPv4 address and UDP port number of the Teredo Relay. Because a source-specific mapping for Teredo traffic from the Teredo Server exists in the NAT, the bubble packet is forwarded to the Teredo Client.

6. The Teredo Client determines the IPv4 address of the Teredo Relay closest to the IPv6-only Host from the Origin indicator of the received bubble packet. To establish a source-specific mapping for Teredo traffic from the Teredo Relay, the Teredo Client sends a bubble packet to the Teredo Relay.

7. Based on the receipt of the bubble packet that corresponds to a packet that is queued for forwarding (the ICMPv6 Echo Reply message), the Teredo Relay determines that a source-specific NAT mapping now exists in the restricted NAT of the Teredo Client. The Teredo Relay forwards the ICMPv6 Echo Reply message to the Teredo Client.

8. An initial communication packet is sent from the Teredo Client to the IPv4 address and UDP port of the Teredo Relay.

9. The Teredo Relay removes the IPv4 and UDP headers and forwards the packet to the IPv6-only Host.

All subsequent packets sent between the Teredo Client and the IPv6-only Host takes this path via the Teredo Relay.

Initial communication from an IPv6-only host to a Teredo client

Initial communication from an IPv6-only host to a Teredo client depends on whether the Teredo client is behind a cone NAT or restricted NAT.

Cone NAT

Figure 23 shows the initial communication from an IPv6-only host to a Teredo client when the Teredo client is located behind a cone NAT.

Figure 23: Initial communication from an IPv6-only host to a Teredo client with a cone NAT

To send an initial communication packet from the IPv6-only Host to the Teredo Client, the following process is used:

1. The IPv6-only Host sends an initial communication packet to the Teredo Client. Due to the routing infrastructure of the IPv6 Internet, the Teredo-addressed packet is forwarded to the nearest Teredo relay.

2. The Teredo Relay determines that the Teredo Client is behind a cone NAT. Therefore; it forwards the packet from the IPv6-only Host, encapsulated with IPv4 and UDP headers, to the Teredo Client.

Upon receipt of this packet, the Teredo client stores the IPv4 address and UDP port corresponding to the Teredo Relay so that response packets can be forwarded to the Teredo Relay, which receives them, removes the IPv4 and UDP headers, and forwards the IPv6 packet to the IPv6-only Host.

To ensure that the IPv6 address of the initial communication packet has not been spoofed and corresponds to the IPv6-only Host, the Teredo Client performs an ICMPv6 Echo Request/Echo Reply message exchange with the IPv6-only Host using steps 1-4 of the "Initial communication from a Teredo client to an IPv6-only host" (for a cone NAT) section of this article. After this exchange is complete, the Teredo Client sends the response to the initial communication packet to the IPv6-only Host.

Restricted NAT

Figure 24 shows the initial communication from an IPv6-only host to a Teredo client when the Teredo client is located behind a restricted NAT.

Figure 24: Initial communication from an IPv6-only host to a Teredo client with a restricted NAT

To send an initial communication packet from the IPv6-only Host to the Teredo Client, the following process is used:

1. The IPv6-only Host sends a packet to the Teredo Client. Due to the routing infrastructure of the IPv6 Internet, the Teredo-addressed packet is forwarded to the nearest Teredo relay.

2. The Teredo Relay determines that the Teredo Client is behind a restricted NAT. If the Teredo Relay were to send the packet to the Teredo Client, the NAT would silently discard it because there is no source-specific mapping for Teredo traffic from the Teredo Relay. Therefore, the Teredo Relay sends a bubble packet to the Teredo Client via the Teredo Server over the IPv4 Internet.

3. The Teredo Server receives the bubble packet from the Teredo Relay. The Teredo Server forwards the bubble to the Teredo Client, with an Origin indicator that contains the IPv4 address and UDP port number of the Teredo Relay. Because a source-specific mapping for Teredo traffic from the Teredo Server exists in the NAT, the bubble packet is forwarded to the Teredo Client.

4. The Teredo Client determines the IPv4 address of the Teredo Relay closest to the IPv6-only Host from the Origin indicator of the received bubble packet. To establish a source-specific mapping for Teredo traffic from the Teredo Relay, the Teredo Client sends a bubble packet to the Teredo Relay.

5. Based on the receipt of the bubble packet that corresponds to a packet that is queued for forwarding (the packet from the IPv6-only Host), the Teredo Relay determines that a source-specific NAT mapping now exists in the restricted NAT of the Teredo Client. The Teredo Relay forwards the packet to the Teredo Client.

To ensure that the IPv6 address of the initial communication packet has not been spoofed and corresponds to the IPv6-only Host, the Teredo Client performs an ICMPv6 Echo Request/Echo Reply message exchange with the IPv6-only Host using steps 1-7 of the "Initial communication from a Teredo client to an IPv6-only host" (for a restricted NAT) section of this article. After this exchange is complete, the Teredo Client sends the response to the initial communication packet to the IPv6-only Host.

Using Teredo in Windows XP Service Pack 2

To use the Teredo client or host-specific relay on computers running Windows XP with Service Pack 2 or Windows Server 2003 with Service Pack 1, an application developer must do the following:

• Ensure that the application is compatible with IPv6 by using new Windows Sockets 2 programming elements (functions and structures) that support both IPv4 and IPv6. For more information, see the IPv6 Guide for Windows Sockets Applications.

• Enable the use of Teredo in your application by setting the IPV6_PROTECTION_LEVEL Windows Sockets socket option to the PROTECTION_LEVEL_UNRESTRICTED level. For more information, see Using IPV6_PROTECTION_LEVEL. You can also set this option through the System.Net.Sockets .NET Framework class.

• Create an exception for the Windows Firewall to allow unsolicited incoming Teredo traffic. Use the Windows Firewall APIs to create a port exception for the UDP port assigned for Teredo traffic.

To ensure that Teredo is available for use when the application runs, application developers should do the following during the application's installation process:

• Install IPv6 with the netsh interface ipv6 install command. Windows Firewall protects the user's computer from unsolicited incoming IPv6 traffic in the same way as IPv4 traffic.

• Enable Teredo with the netsh interface ipv6 set teredo client command.

Optionally, you can test whether IPv6 is installed each time your application runs and install IPv6 and enable Teredo as needed.

You should also inform the user that IPv6 is being installed and that Teredo is being enabled.

Summary

Teredo is an address assignment and automatic tunneling technology that provides unicast IPv6 connectivity when IPv6/IPv4 hosts are located behind one or multiple IPv4 NATs. Teredo tunneled packets are sent as IPv4 UDP messages. Teredo communication is facilitated by Teredo servers and Teredo relays. A Teredo host-specific relay is an IPv6/IPv4 host that does not use Teredo addresses, but can communicate with Teredo clients without having to use a Teredo relay in the communication path. There are defined processes for obtaining a Teredo address, maintaining a NAT mapping, and performing initial communications between Teredo clients, Teredo host-specific relays, and IPv6-only hosts. The initial communication process in each case depends on whether the Teredo client is located behind a cone or restricted NAT.

Related Links

See the following resources for further information:

• Introduction to IPv6 white paper

• IPv6 Transition Technologies white paper

• Microsoft IPv6 Web site

• For the latest information about Windows XP, see the Windows XP Web site at https://www.microsoft.com/windowsxp/default.asp.