The Teredo transitioning mechanism [Hui05], is a form of automatic tunnelling intended to provide IPv6 connectivity to IPv4 hosts that are located behind a NAT [RFC1613] and therefore do not possess permanent, global-scope IPv4 addresses. It is a host-to-host automatic tunnelling mechanism that provides IPv6 connectivity, when dual-stack hosts are located behind one ore multiple NATs by encapsulating IPv6 packets in IPv4-based User Datagram Protocol (UDP) messages.
As illustrated in Figure 5-3, the Teredo service employs two entities, a Teredo server and a Teredo relay, in order to provide IPv6 connectivity to Teredo clients located behind a NAT. Unlike other tunnelling mechanisms, Teredo encapsulates IPv6 packets in UDP (instead of directly over IPv4). A well-known UDP port (3544) is used by the Teredo server to listen for requests from the Teredo clients. Teredo addresses have the following structure:
Both the “mapped client UDP port” and the “mapped client IPv4 address” are obfuscated; each bit in the address and port number is reversed. Note that IPv6 addressing rules specify that for all unicast addresses, Interface IDs are required to be 64 bits except those that begin with binary value 000. Hence the flags field has to be encoded to conform to this requirement (see [Hui05] for more details).
The Teredo server listens for requests from Teredo clients, responding with an IPv6 address for them to use. The Teredo server forwards the IPv4-encapsulated IPv6 packets sent from Teredo clients to the Teredo relay. The server also forwards IPv6 packets received from the Teredo relay, that are destined for a Teredo client, to the appropriate IPv4 address and UDP port of the client. The Teredo relay thus acts as an IPv6 router and forwards IPv6 packets destined for Teredo clients to the Teredo server from the IPv6 Internet and forwards IPv6 packets received from the Teredo server to the IPv6 Internet. The Teredo relay also advertises the reachability of the Teredo service into the IPv6 Internet. It is likely that the Teredo server and relay entities would be co-located as shown in Figure 5-3.
Analysing the Teredo IPv6 address format it becomes evident that the Teredo specification makes rather inefficient use of the IPv6 address space with respect to the injection of routing prefixes. This is because the Teredo relay must advertise the reachability of the Teredo service to the rest of the IPv6 Internet. The 32-bit Teredo prefix is common to all Teredo servers, so the relay must advertise IPv6 prefixes consisting of at least the Teredo prefix plus the IPv4 address of the Teredo server. This means that routing prefixes for every distinct Teredo server must be injected into the IPv6 Internet. In theory, this could mean injecting a routing prefixe into the IPv6 Internet for every IPv4 site that employs NAT.
As such, the Teredo service should only be used as a ‘last resort’ where direct IPv6 connectivity or colocating a 6to4 router with the NAT is not possible. Furthermore, the Teredo method is complex, and cannot be guaranteed to work across all NATs due in part to variations in NAT implementations.