Skip to main content

IAB to IESG:Comments on Teredo , 3 November, 2004

Document Type IAB Statement
Title IAB to IESG:Comments on Teredo , 3 November, 2004
Published 2004-11-03
Metadata last updated 2023-08-09
State Active
Send notices to (None)
Date: Wed, 03 Nov 2004 
From: Jonathan Rosenberg 
To: The IESG, Christian Huitema 
Subject: IAB comments on IAB considerations section of Teredo

IESG, Christian,

The IAB has reviewed the IAB considerations section of draft-huitema-v6ops-teredo, and has the following comments:

The specific problems being solved by Teredo is the provision of IPv6 connectivity for a host that cannot obtain IPv6 connectivity either natively or by other means, such as 6to4.

The scope of Teredo is a little more focused that that; it concentrates on IPv4 hosts that cannot make use of 6to4 because of the presence of a NAT between them and the relay.

Teredo comes with its own built in exit strategy: as soon as IPv6 connectivity is obtained by other means, Teredo will cease to be used.

This is true for any particular client, not for the service overall. Suggest rewording to: “Teredo comes with its own built in exit strategy: as soon as a client obtains IPv6 connectivity by other means, either 6to4 or native IPv6, it can cease using the Teredo service.”

This fact really represents the essence of the reason why Teredo would be short lived. However, this fact requires some justification. There would appear to be reasons why a teredo implementation might decide to continue usage of the teredo service:

  1. If, for some reason, the teredo link is providing the client with better service than the native IPv6 link, in terms of bandwidth, packet loss, etc.
  2. When a client is dual homed, and it wishes to improve the service when communicating with other teredo hosts that are “nearby” on the IPv4 network. If the client only used its native IPv6 service, the teredo hosts would be reached only through the relay. By maintaining teredo, the teredo hosts can be reached by direct transmission over IPv4.

These are just examples. I suggest that this part of the IAB considerations section present a stronger justification for why this sunset is likely to occur, or if there are reasons where it may not happen, that these be documented. This does not mean that the document needs to discuss the above two issues in particular; it should only do so if the authors of teredo believe that these are valid reasons why such a transition may not occur. In cases where such considerations are documented in other specifications (for example, RFC 3904), it is acceptable to merely reference the appropriate section of that specification.

Teredo introduces brittleness into the system in several ways: the discovery process assumes a certain classification of devices based on their treatment of UDP; the mappings need to be continuously refreshed; and addressing structure may cause some hosts located beyond a common NAT to be unreachable from each other. (There are many similarities between these points and those introduced by STUN [RFC3489].)

I believe that Teredo is actually less brittle than STUN in its discovery procedures. The reason is that all teredo packets are sent from the local IPv4 teredo service port, including discovery, bubbles and actual encapsulated packets. This is different from STUN, where NAT type detection and binding allocation use different local ports (ephemeral, in both cases). One of the difficulties found in real NATs is that their behavior depends on whether or not the source port on the private side has already been allocated. In some NATs, the behavior can vary between full cone and port restricted depending on this. In regular STUN, this means that the NAT type detection may reveal full cone, but actual binding allocations may see port restricted behavior. This is not so with teredo since only a single mapping is used in the NAT for all functions. This difference is worth pointing out.

The use of the Teredo server as an additional network element introduces another point of potential security attack. These attacks are largely prevented by the security measures provided by Teredo, but not entirely.

The use of the Teredo server as an additional network element introduces another point of failure. If the client cannot locate a Teredo server, or if the server should be unavailable due to failure, the Teredo client will not be able to obtain IPv6 connectivity.

Teredo introduces two elements – the relay and the server, not just one.

There are also additional points of brittleness that are worth mentioning:

  • Teredo service will not work through NATs of the symmetric variety
  • Teredo service depends on the Teredo server running on a network that is a common ancestor to all Teredo clients; typically this is the public Internet. If the teredo server is itself behind a NAT, teredo service will not work to certain peers
  • Teredo introduces jitter into the IPv6 service it provides, due to the queuing of packets while bubble exchanges take place. This jitter can negatively impact applications, particularly latency sensitive ones, such as VoIP.

Teredo imposes some restrictions on the network topologies for proper operation. In particular, if the same NAT is on the path between two clients and the Teredo server, these clients will only be able to interoperate if they are connected to the same link, or if the common NAT is capable of “looping” packets sent by one client to another.

This is referred to as “hairpinning” in draft-audet-nat-behave; I’d suggest usage of that terminology.


Jonathan Rosenberg for the IAB