From Wikipedia, the free encyclopedia - View original article
|IPv6 transition mechanisms|
In computer networking, Teredo is a transition technology that gives full IPv6 connectivity for IPv6-capable hosts which are on the IPv4 Internet but which have no direct native connection to an IPv6 network. Compared to other similar protocols its distinguishing feature is that it is able to perform its function even from behind network address translation (NAT) devices such as home routers.
Teredo operates using a platform independent tunneling protocol designed to provide IPv6 (Internet Protocol version 6) connectivity by encapsulating IPv6 datagram packets within IPv4 User Datagram Protocol (UDP) packets. These datagrams can be routed on the IPv4 Internet and through NAT devices. Other Teredo nodes elsewhere called Teredo relays that have access to the IPv6 network then receive the packets, unencapsulate them, and route them on.
Teredo is designed as a last resort transition technology and is intended to be a temporary measure: in the long term, all IPv6 hosts should use native IPv6 connectivity. Teredo should therefore be disabled when native IPv6 connectivity becomes available.
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, and the 6to4 tunnel endpoint needs to be implemented on the NAT device itself. Many NAT devices currently deployed, however, cannot be upgraded to implement 6to4, for technical or economic reasons.
Teredo alleviates this problem by encapsulating 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 intended to be 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.
As of IETF88, Microsoft plans to deactivate their Teredo servers for Windows clients in the first half of 2014 (exact date TBD), and encourage the deactivation of publicly operated Teredo relays.
The Teredo protocol performs several functions:
Teredo defines several different kinds of nodes:
Each Teredo client is assigned a public IPv6 address which is constructed as follows (the higher order bit is numbered 0):
Teredo IPv6 addressing table
|Bits||0 - 31||32 - 63||64 - 79||80 - 95||96 - 127|
|Length||32 bits||32 bits||16 bits||16 bits||32 bits|
As an example, the IPv6 address 2001:0000:4136:e378:8000:63bf:3fff:fdd2 refers to a Teredo client:
Teredo IPv6 example table
|Bits||0 - 31||32 - 63||64 - 79||80 - 95||96 - 127|
|Length||32 bits||32 bits||16 bits||16 bits||32 bits|
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 intervals. 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 because they are not involved into the actual transmission and reception of IPv6 traffic packets. Also, it does not involve any access to the Internet routing protocols. The only requirements for a Teredo server are:
Public teredo servers:
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 addressed 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's).
Unlike 6to4, where the two halves of a connection can use different relays, traffic between a native IPv6 host and a Teredo client will use the same Teredo relay, namely the one that is closest to the native IPv6 host network-wise. The Teredo client cannot localize a relay by itself (since it cannot send IPv6 packets by itself); if it needs to initiate a connection to a native IPv6 host, it will send the first packet through the Teredo server, which sends a packet to the native IPv6 host using the client's Teredo IPv6 address. The native IPv6 host then responds as usual to the client's Teredo IPv6 address, which will eventually cause the packet to find a Teredo relay, which will initiate a connection to the client (possibly using the Teredo server for NAT piercing). The relay is then used for communication between the Teredo Client and native IPv6 host for as long as is needed. This design means that neither the Teredo server nor client needs to know the IPv4 address of any Teredo relays; a suitable one is automatically found by means of the global IPv6 routing table, since all Teredo relays advertise the network 2001:0::/32.
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. As of 16 February 2007, it is not functional.
In Q1 2009, IPv6 backbone Hurricane Electric enabled 14 Teredo relays in an anycast implementation and advertising 2001::/32 globally. The relays were located in Seattle, Fremont, Los Angeles, Chicago, Dallas, Toronto, New York, Ashburn, Miami, London, Paris, Amsterdam, Frankfurt and Hong Kong.
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.
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. The original shipworm specification out of which the final Teredo protocol came supported symmetric NATs too, but this was dropped due to security concerns.
People at the National Chiao Tung University later proposed SymTeredo which enhanced the original Teredo protocol to support symmetric NATs, and the Microsoft and Miredo implementations implement certain unspecified non-standard extensions to improve support for symmetric NATs. However, connectivity between a Teredo client behind a symmetric NAT, and a Teredo client behind a port-restricted or symmetric NAT remains seemingly impossible.
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).
Point-to-point tunnels can be more reliable and are more accountable than Teredo, and typically provides permanent IPv6 addresses that do not depend on the IPv4 address of the tunnel endpoint. Some point-to-point tunnel brokers additionally 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. Automated tools (for instance AICCU) exist to make it easy to use Point-to-Point tunnels.
Teredo increases the attack surface by assigning globally routable IPv6 addresses to network hosts behind NAT devices, which are otherwise mostly unreachable from the Internet. By doing so, Teredo potentially exposes any IPv6-enabled application with an open port to the outside. However, such a vulnerability is an intrinsic effect from NAT traversal. Teredo also exposes the IPv6 stack and the tunneling software to attacks should they have any remotely exploitable vulnerability.
The Microsoft IPv6 stack has a "protection level" socket option. This allows applications to specify whether they are willing to handle traffic coming from the Teredo tunnel, from anywhere except Teredo (the default), or only from the local Intranet.
For a Teredo pseudo-tunnel to operate properly, outgoing UDP packets must not be filtered. Moreover, replies to these packets (i.e. "solicited traffic") must also not be filtered. This corresponds to the typical setup of a NAT and its stateful firewall functionality.
Teredo tunneling software will detect a fatal error and stop if outgoing IPv4 UDP traffic is blocked. Also, blocking of outgoing traffic to UDP port 3544 can interfere with Teredo activity.
Some new methods to create denial of service attacks via routing loops using Teredo tunnels have been uncovered recently. They are relatively easy to prevent.
Several implementations of Teredo are currently available:
The initial nickname of the Teredo tunneling protocol was shipworm. The idea was that the protocol would pierce holes through NAT devices, much like the shipworms bore tunnels through wood. Shipworms are 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."