About Opentopia
Opentopia Directory Encyclopedia Tools

Teredo tunneling

Encyclopedia : T : TE : TER : Teredo tunneling

Teredo is a tunneling protocol designed to grant IPv6 connectivity to nodes that are located behind IPv6-unaware NAPT devices. It defines a way of encapsulating IPv6 packets within IPv4 UDP datagrams that can be routed through NAT devices and on the IPv4 Internet.

Contents

Purpose

6to4, the most common IPv6 over IPv4 tunneling protocol, requires the tunnel endpoint to have a public IPv4 address. However, many hosts are currently attached to the IPv4 Internet through one or several NAT devices, usually because of IPv4 address shortage. In such a situation, the only available public IPv4 address is assigned to the NAT device.

6to4, the recommended IPv6 tunnelling technology, requires that the local tunnel endpoint have a global IPv4 address. In practice, this means that in a NATted configuration, the 6to4 tunnel endpoint needs to be implemented on the NAT device. Many NAT devices currently deployed, however, cannot be upgraded to implement 6to4, for technical or economic reasons.

Teredo encapsulates IPv6 packets within UDP/IPv4 datagrams, which most NATs can forward properly. Thus, IPv6-aware hosts behind NATs can be used as Teredo tunnel endpoints even when they don't have a dedicated public IPv4 address. In effect, a host implementing Teredo can gain IPv6 connectivity with no cooperation from the local network environment.

Teredo is a temporary measure: in the long term, all IPv6 hosts should use native IPv6 connectivity. The Teredo protocol includes provisions for a sunset procedure: Teredo implementation should provide a way to stop using Teredo connectivity when IPv6 has matured and connectivity becomes available using a less brittle mechanism.

Overview

For a complete explanation, see Teredo Overview in External Links.
The Teredo protocol performs several functions:

  1. Diagnoses UDP over IPv4 (UDPv4) connectivity and discovers the kind of NAT present (using a simplified replacement to the STUN protocol);
  2. assigns a globally-routable unique IPv6 address to each host using it;
  3. encapsulates IPv6 packets inside UDPv4 datagrams for transmission over an IPv4 network (this inclues NAT traversal);
  4. routes traffic between Teredo hosts and native (or otherwise non-Teredo) IPv6 hosts.

Teredo node types

Teredo defines several different kind of nodes:

Teredo IPv6 addressing

Each Teredo client is assigned a public IPv6 address which is constructed as follows (the higher order bit is numbered 0):

As an example, 2001:0000:4136:e378:8000:63bf:3fff:fdd2 refers to a Teredo client:

Teredo servers

For a list of existing Teredo servers, see the list in External links.
Teredo servers are used by Teredo clients to autodetect the kind of NAT behind which they are located (if any), through a simplified STUN-like qualification procedure. Teredo clients also maintain a binding on their NAT toward their Teredo server, by sending a UDP packet at regular time interval. That ensures that the server can always contact any of its clients, which is required for hole punching to work properly.

If a Teredo relay (or another Teredo client) has to send an IPv6 packet to a Teredo client, it will first send a Teredo bubble packet to the client's Teredo server, whose IP address can be inferred from the Teredo IPv6 address of the Teredo client. The server can then forward the bubble to the client, so the Teredo client software knows that hole punching must be done toward the Teredo relay.

Teredo servers can also transmit ICMPv6 packet from Teredo clients toward the IPv6 Internet. In practice, when a Teredo client wants to contact a native IPv6 node, it must find out where the corresponding Teredo relay is (i.e. which public IPv4 and UDP port number to send encapsulated IPv6 packets to). To do that, the client crafts an ICMPv6 Echo Request (ping) toward the IPv6 node, and sends it through its configured Teredo server. The Teredo server decapsulates the ping onto the IPv6 Internet, so that the ping should eventually reach the IPv6 node. The IPv6 node should then reply with an ICMPv6 Echo Reply, as mandated by RFC 2460. This reply packet will be routed to the closest Teredo relay, which will finally try to contact the Teredo client.

Maintaining a Teredo server requires little bandwidth, as they are not involved into the actual transmission and reception of IPv6 packets. Also, it does not involve any access to the Internet routing protocols. The only requirements for a Teredo server are:

Teredo relays

A Teredo relay potentially requires a lot of network bandwidth. Also, it must export (advertise) a route toward the Teredo IPv6 prefix (2001:0::/32) to other IPv6 hosts. That way, the Teredo relay will receive traffic from the IPv6 hosts adressed to any Teredo client, and forward it over UDP/IPv4. Symmetrically, it will receive packets from Teredo clients addressed to native IPv6 hosts over UDP/IPv4 and inject those into the native IPv6 network.

In practice, network administrators can set up a private Teredo relay for their company or campus; this will provide a short path between their IPv6 network and any Teredo client. However setting up a Teredo relay on a scale beyond that of a single network requires the ability to export BGP IPv6 routes to the other autonomous systems (AS).

For near-realtime infos on Teredo and BGP, see the External links.
On March 30 2006, Italian ISP [ITGate] was the first AS to start advertising a route toward 2001::/32 on the IPv6 Internet, so that RFC 4380-compliant Teredo implementations would be fully usable.

It is expected that large network operators will be maintaining Teredo relays. As with 6to4, it remains however unclear how well the Teredo service will scale up if a large proportion of Internet hosts start using IPv6 through Teredo in addition to IPv4.

While Microsoft has been operating a set of Teredo servers ever since the first Teredo pseudo-tunnel for Windows XP was released, it has never provided a Teredo relay service for the IPv6 Internet as a whole.

Limitations

Teredo is not compatible with all NAT devices. Using the terminology of RFC 3489, full cone, restricted and port-restricted NAT devices are supported, while symmetric NATs are not.

Indeed, Teredo assumes that when two clients exchange encapsulated IPv6 packets, the mapped/external UDP port numbers used will be the same as those that were used to contact the Teredo server (and building the Teredo IPv6 address). Without this assumption, it would not be possible to establish a direct communication between the two clients, and a costly relay would have to be used to perform triangle routing. A Teredo implementation tries to detect the type of NAT at startup, and will refuse to operate if the NAT appears to be symmetric. (This limitation can sometimes be worked around by manually configuring a port forwarding rule on the NAT box, which requires administrative access to the device).

Teredo can only provide a single IPv6 address per tunnel endpoint. As such, it is not possible to use a single Teredo tunnel to connect multiple hosts, contrary to 6to4 and some point-to-point IPv6 tunnels.

The bandwidth available to all Teredo clients toward the IPv6 Internet is limited by the availability of Teredo relays (which are no different in that respect from 6to4 relays).

Alternatives to Teredo

6to4 requires a public IPv4 address, but provides a large 48-bits IPv6 prefix for each tunnel endpoint, and has a lower encapsulation overhead.

Point-to-point tunnels may be more reliable and accountable than automatic pseudo-tunneling schemes (Teredo and 6to4), and might provide permanent IPv6 addresses that do not depend on the IPv4 address of the tunnel endpoint. Some point-to-point tunnel brokers additionnaly support UDP encapsulation to traverse NATs (for instance, the AYIYA protocol can do this). On the other hand, point-to-point tunnels normally require registration, and might not scale to a large user base.

Implementations

Several implementations of Teredo are currently available:

IANA has assigned 2001::/32 (can be written out full as 2001:0000::/32) as the permanent Teredo prefix. However, the current version of the Teredo client provided with Windows XP only accept the former experimental Teredo prefix, 3ffe:831f::/32. To this day, Microsoft's Teredo servers still stick to the old prefix as well.

[The Teredo prefix can be configured] on Windows XP and Server 2003 by adding or modifying the REG_DWORD value TeredoPrefix under the HKLM\System\CurrentControlSet\Services\Tcpip6\Parameters\GlobalParams key, in the Windows registry. The DWORD value is interpreted as a 32 bits prefix, in network byte order, thus the correct value is 0x00000120 (288). For this to work, a Teredo server advertising the new prefix is required, which is not the case of the default ones.

It was expected that the old prefix would be relinquished before the 6th June 2006, while the 6bone is to be phased out. It is also supposed that Windows Vista will ship with an updated Teredo implementation.

Choice of the name Teredo

The initial nickname of the teredo tunneling protocol was shipworm. The idea was that the protocol would pierce holes through NAT, much like the shipworms bore tunnels through wood. Shipworms are pretty nasty animals, responsible for the loss of very many wooden hulls, but Christian Huitema in the original draft noted that ''the animal only survives in relatively clean and unpolluted water; its recent comeback in several Northern American harbors is a testimony to their newly retrieved cleanliness. Similarly, by piercing holes through NAT, the service would contribute to a newly retrieved transparency of the Internet.''

Christian Huitema works for Microsoft, and was obviously pressed by Microsoft's public relations to pick a slightly less offensive name. Teredo navalis is the latin name of one of the best known species of shipworm. At least, the name Teredo does not immediately evoke computer worms.

References

External links

 

From Wikipedia, the Free Encyclopedia. Original article here. Support Wikipedia by contributing or donating.
All text is available under the terms of the GNU Free Documentation License See Wikipedia Copyrights for details.

Search Titles
0123456789
ABCDEFGHIJ
KLMNOPQRST
UVWXYZ?

E-mail this article to:

Personal Message: