Request for Comments: 4380 Microsoft
Category: Standards Track February 2006
Teredo: Tunneling IPv6 over UDP
through Network Address Translations (NATs)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
We propose here a service that enables nodes located behind one or
more IPv4 Network Address Translations (NATs) to obtain IPv6
connectivity by tunneling packets over UDP; we call this the Teredo
service. Running the service requires the help of "Teredo servers"
and "Teredo relays". The Teredo servers are stateless, and only have
to manage a small fraction of the traffic between Teredo clients; the
Teredo relays act as IPv6 routers between the Teredo service and the
"native" IPv6 Internet. The relays can also provide interoperability
with hosts using other transition mechanisms such as "6to4".
Table of Contents
1. Introduction ....................................................3
2. Definitions .....................................................4
2.1. Teredo Service .............................................4
2.2. Teredo Client ..............................................4
2.3. Teredo Server ..............................................4
2.4. Teredo Relay ...............................................4
2.5. Teredo IPv6 Service Prefix .................................4
2.6. Global Teredo IPv6 Service Prefix ..........................4
2.7. Teredo UDP Port ............................................4
2.8. Teredo Bubble ..............................................4
2.9. Teredo Service Port ........................................5
2.10. Teredo Server Address .....................................5
2.11. Teredo Mapped Address and Teredo Mapped Port ..............5
2.12. Teredo IPv6 Client Prefix .................................5
2.13. Teredo Node Identifier ....................................5
2.14. Teredo IPv6 Address .......................................5
2.15. Teredo Refresh Interval ...................................5
2.16. Teredo Secondary Port .....................................6
2.17. Teredo IPv4 Discovery Address .............................6
3. Design Goals, Requirements, and Model of Operation ..............6
3.1. Hypotheses about NAT Behavior ..............................6
3.2. IPv6 Provider of Last Resort ...............................8
3.3. Operational Requirements ...................................9
3.4. Model of Operation ........................................10
4. Teredo Addresses ...............................................11
5. Specification of Clients, Servers, and Relays ..................13
5.1. Message Formats ...........................................13
5.2. Teredo Client Specification ...............................16
5.3. Teredo Server Specification ...............................31
5.4. Teredo Relay Specification ................................33
5.5. Implementation of Automatic Sunset ........................36
6. Further Study, Use of Teredo to Implement a Tunnel Service .....37
7. Security Considerations ........................................38
7.1. Opening a Hole in the NAT .................................38
7.2. Using the Teredo Service for a Man-in-the-Middle Attack ...39
7.3. Denial of the Teredo service ..............................42
7.4. Denial of Service against Non-Teredo Nodes ................43
8. IAB Considerations .............................................46
8.1. Problem Definition ........................................46
8.2. Exit Strategy .............................................47
8.3. Brittleness Introduced by Teredo ..........................48
8.4. Requirements for a Long-Term Solution .....................50
9. IANA Considerations ............................................50
10. Acknowledgements ..............................................50
11. References ....................................................51
11.1. Normative References .....................................51
11.2. Informative References ...................................52
1. Introduction
Classic tunneling methods envisaged for IPv6 transition operate by
sending IPv6 packets as payload of IPv4 packets; the 6to4 proposal
[RFC3056] proposes automatic discovery in this context. A problem
with these methods is that they don’t work when the IPv6 candidate
node is isolated behind a Network Address Translator (NAT) device:
NATs are typically not programmed to allow the transmission of
arbitrary payload types; even when they are, the local address cannot
be used in a 6to4 scheme. 6to4 will work with a NAT if the NAT and
6to4 router functions are in the same box; we want to cover the
relatively frequent case when the NAT cannot be readily upgraded to
provide a 6to4 router function.
A possible way to solve the problem is to rely on a set of "tunnel
brokers". However, there are limits to any solution that is based on
such brokers: the quality of service may be limited, since the
traffic follows a dogleg route from the source to the broker and then
the destination; the broker has to provide sufficient transmission
capacity to relay all packets and thus suffers a high cost. For
these two reasons, it may be desirable to have solutions that allow
for "automatic tunneling", i.e., let the packets follow a direct path
to the destination.
The automatic tunneling requirement is indeed at odds with some of
the specificities of NATs. Establishing a direct path supposes that
the IPv6 candidate node can retrieve a "globally routable" address
that results from the translation of its local address by one or more
NATs; it also supposes that we can find a way to bypass the various
"per destination protections" that many NATs implement. In this
memo, we will explain how IPv6 candidates located behind NATs use
"Teredo servers" to learn their "global address" and to obtain
connectivity, how they exchange packets with native IPv6 hosts
through "Teredo relays", and how clients, servers, and relays can be
organized in Teredo networks.
The specification is organized as follows. Section 2 contains the
definition of the terms used in the memo. Section 3 presents the
hypotheses on NAT behavior used in the design, as well as the
operational requirements that the design should meet. Section 4
presents the IPv6 address format used by Teredo. Section 5 contains
the format of the messages and the specification of the protocol.
Section 6 presents guidelines for further work on configured tunnels
that would be complementary to the current approach. Section 7
contains a security discussion, section 8 contains a discussion of
the Unilateral Self Address Fixing (UNSAF) issues, and section 9
contains IANA considerations.
2. Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
This specification uses the following definitions:
2.1. Teredo Service
The transmission of IPv6 packets over UDP, as defined in this memo.
2.2. Teredo Client
A node that has some access to the IPv4 Internet and wants to gain
access to the IPv6 Internet.
2.3. Teredo Server
A node that has access to the IPv4 Internet through a globally
routable address, and is used as a helper to provide IPv6
connectivity to Teredo clients.
2.4. Teredo Relay
An IPv6 router that can receive traffic destined to Teredo clients
and forward it using the Teredo service.
2.5. Teredo IPv6 Service Prefix
An IPv6 addressing prefix that is used to construct the IPv6 address
of Teredo clients.
2.6. Global Teredo IPv6 Service Prefix
An IPv6 addressing prefix whose value is 2001:0000:/32.
2.7. Teredo UDP Port
The UDP port number at which Teredo servers are waiting for packets.
The value of this port is 3544.
2.8. Teredo Bubble
A Teredo bubble is a minimal IPv6 packet, made of an IPv6 header and
a null payload. The payload type is set to 59, No Next Header, as
per [RFC2460]. The Teredo clients and relays may send bubbles in
order to create a mapping in a NAT.
2.9. Teredo Service Port
The port from which the Teredo client sends Teredo packets. This
port is attached to one of the client’s IPv4 addresses. The IPv4
address may or may not be globally routable, as the client may be
located behind one or more NAT.
2.10. Teredo Server Address
The IPv4 address of the Teredo server selected by a particular
client.
2.11. Teredo Mapped Address and Teredo Mapped Port
A global IPv4 address and a UDP port that results from the
translation of the IPv4 address and UDP port of a client’s Teredo
service port by one or more NATs. The client learns these values
through the Teredo protocol described in this memo.
2.12. Teredo IPv6 Client Prefix
A global scope IPv6 prefix composed of the Teredo IPv6 service prefix
and the Teredo server address.
2.13. Teredo Node Identifier
A 64-bit identifier that contains the UDP port and IPv4 address at
which a client can be reached through the Teredo service, as well as
a flag indicating the type of NAT through which the client accesses
the IPv4 Internet.
2.14. Teredo IPv6 Address
A Teredo IPv6 address obtained by combining a Teredo IPv6 client
prefix and a Teredo node identifier.
2.15. Teredo Refresh Interval
The interval during which a Teredo IPv6 address is expected to remain
valid in the absence of "refresh" traffic. For a client located
behind a NAT, the interval depends on configuration parameters of the
local NAT, or the combination of NATs in the path to the Teredo
server. By default, clients assume an interval value of 30 seconds;
a longer value may be determined by local tests, as described in
section 5.
2.16. Teredo Secondary Port
A UDP port used to send or receive packets in order to determine the
appropriate value of the refresh interval, but not used to carry any
Teredo traffic.
2.17. Teredo IPv4 Discovery Address
An IPv4 multicast address used to discover other Teredo clients on
the same IPv4 subnet. The value of this address is 224.0.0.253.
3. Design Goals, Requirements, and Model of Operation
The proposed solution transports IPv6 packets as the payload of UDP
packets. This is based on the observation that TCP and UDP are the
only protocols guaranteed to cross the majority of NAT devices.
Tunneling packets over TCP would be possible, but would result in a
poor quality of service; encapsulation over UDP is a better choice.
The design of our solution is based on a set of hypotheses and
observations on the behavior of NATs, our desire to provide an "IPv6
provider of last resort", and a list of operational requirements. It
results in a model of operation in which the Teredo service is
enabled by a set of servers and relays.
3.1. Hypotheses about NAT Behavior
NAT devices typically incorporate some support for UDP, in order to
enable users in the natted domain to use UDP-based applications. The
NAT will typically allocate a "mapping" when it sees a UDP packet
coming through for which there is not yet an existing mapping. The
handling of UDP "sessions" by NAT devices differs by two important
parameters, the type and the duration of the mappings.
The type of mappings is analyzed in [RFC3489], which distinguishes
between "cone NAT", "restricted cone NAT", "port restricted cone NAT"
and "symmetric NAT". The Teredo solution ensures connectivity for
clients located behind cone NATs, restricted cone NATs, or port-
restricted cone NATs.
Transmission of regular IPv6 packets only takes place after an
exchange of "bubbles" between the parties. This exchange would often
fail for clients behind symmetric NAT, because their peer cannot
predict the UDP port number that the NAT expects.
Clients located behind a symmetric NAT will only be able to use
Teredo if they can somehow program the NAT and reserve a Teredo
service port for each client, for example, using the DMZ functions of
the NAT. This is obviously an onerous requirement, at odds with the
design goal of an automatic solution. However, measurement campaigns
and studies of documentations have shown that, at least in simple
"unmanaged" networks, symmetric NATs are a small minority; moreover,
it seems that new NAT models or firmware upgrades avoid the
"symmetric" design.
Investigations on the performance of [RFC3489] have shown the
relative frequency of a particular NAT design, which we might call
"port conserving". In this design, the NAT tries to keep the same
port number inside and outside, unless the "outside" port number is
already in use for another mapping with the same host. Port
conserving NAT appear as "cone" or "restricted cone NAT" most of the
time, but they will behave as "symmetric NAT" when multiple internal
hosts use the same port number to communicate to the same server.
The Teredo design minimizes the risk of encountering the "symmetric"
behavior by asking multiple hosts located behind the same NAT to use
different Teredo service ports.
Other investigation in the behavior of NAT also outlined the
"probabilistic rewrite" behavior. Some brands of NAT will examine
all packets for "embedded addresses", IP addresses, and port numbers
present in application payloads. They will systematically replace
32-bit values that match a local address by the corresponding mapped
address. The Teredo specification includes an "obfuscation"
procedure in order to avoid this behavior.
Regardless of their types, UDP mappings are not kept forever. The
typical algorithm is to remove the mapping if no traffic is observed
on the specified port for a "lifetime" period. The Teredo client
that wants to maintain a mapping open in the NAT will have to send
some "keep alive" traffic before the lifetime expires. For that, it
needs an estimate of the "lifetime" parameter used in the NAT. We
observed that the implementation of lifetime control can vary in
several ways.
Most NATs implement a "minimum lifetime", which is set as a parameter
of the implementation. Our observations of various boxes showed that
this parameter can vary between about 45 seconds and several minutes.
In many NATs, mappings can be kept for a duration that exceeds this
minimum, even in the absence of traffic. We suspect that many
implementation perform "garbage collection" of unused mappings on
special events, e.g., when the overall number of mappings exceeds
some limit.
In some cases, e.g., NATs that manage Integrated Services Digital
Network (ISDN) or dial-up connections, the mappings will be released
when the connection is released, i.e., when no traffic is observed on
the connection for a period of a few minutes.
Any algorithm used to estimate the lifetime of mapping will have to
be robust against these variations.
In some cases, clients are located behind multiple NAT. The Teredo
procedures will ensure communications between clients between
multiple NATs and clients "on the other side" of these NATs. They
will also ensure communication when clients are located in a single
subnet behind the same NAT.
The procedures do not make any hypothesis about the type of IPv4
address used behind a NAT, and in particular do not assume that these
are private addresses defined in [RFC1918].
3.2. IPv6 Provider of Last Resort
Teredo is designed to provide an "IPv6 access of last resort" to
nodes that need IPv6 connectivity but cannot use any of the other
IPv6 transition schemes. This design objective has several
consequences on when to use Teredo, how to program clients, and what
to expect of servers. Another consequence is that we expect to see a
point in time at which the Teredo technology ceases to be used.
3.2.1. When to Use Teredo
Teredo is designed to robustly enable IPv6 traffic through NATs, and
the price of robustness is a reasonable amount of overhead, due to
UDP encapsulation and transmission of bubbles. Nodes that want to
connect to the IPv6 Internet SHOULD only use the Teredo service as a
"last resort" option: they SHOULD prefer using direct IPv6
connectivity if it is locally available, if it is provided by a 6to4
router co-located with the local NAT, or if it is provided by a
configured tunnel service; and they SHOULD prefer using the less
onerous 6to4 encapsulation if they can use a global IPv4 address.
3.2.2. Autonomous Deployment
In an IPv6-enabled network, the IPv6 service is configured
automatically, by using mechanisms such as IPv6 Stateless Address
Autoconfiguration [RFC2462] and Neighbor Discovery [RFC2461]. A
design objective is to configure the Teredo service as automatically
as possible. In practice, however, it is required that the client
learn the IPv4 address of a server that is willing to serve the
client; some servers may also require some form of access control.
3.2.3. Minimal Load on Servers
During the peak of the transition, there will be a requirement to
deploy Teredo servers supporting a large number of Teredo clients.
Minimizing the load on the server is a good way to facilitate this
deployment. To achieve this goal, servers should be as stateless as
possible, and they should also not be required to carry any more
traffic than necessary. To achieve this objective, we require only
that servers enable the packet exchange between clients, but we don’t
require servers to carry the actual data packets: these packets will
have to be exchanged directly between the Teredo clients, or through
a destination-selected relay for exchanges between Teredo clients and
other IPv6 clients.
3.2.4. Automatic Sunset
Teredo is meant as a short-term solution to the specific problem of
providing IPv6 service to nodes located behind a NAT. The problem is
expected to be resolved over time by transforming the "IPv4 NAT" into
an "IPv6 router". This can be done in one of two ways: upgrading
the NAT to provide 6to4 functions or upgrading the Internet
connection used by the NAT to a native IPv6 service, and then adding
IPv6 router functionality in the NAT. In either case, the former NAT
can present itself as an IPv6 router to the systems behind it. These
systems will start receiving the "router advertisements"; they will
notice that they have IPv6 connectivity and will stop using Teredo.
3.3. Operational Requirements
3.3.1. Robustness Requirement
The Teredo service is designed primarily for robustness: packets are
carried over UDP in order to cross as many NAT implementations as
possible. The servers are designed to be stateless, which means that
they can easily be replicated. We expect indeed to find many such
servers replicated at multiple Internet locations.
3.3.2. Minimal Support Cost
The service requires the support of Teredo servers and Teredo relays.
In order to facilitate the deployment of these servers and relays,
the Teredo procedures are designed to minimize the amount of
coordination required between servers and relays.
Meeting this objective implies that the Teredo addresses will
incorporate the IPv4 address and UDP port through which a Teredo
client can be reached. This creates an implicit limit on the
stability of the Teredo addresses, which can only remain valid as
long as the underlying IPv4 address and UDP port remain valid.
3.3.3. Protection against Denial of Service Attacks
The Teredo clients obtain mapped addresses and ports from the Teredo
servers. The service must be protected against denial of service
attacks in which a third party spoofs a Teredo server and sends
improper information to the client.
3.3.4. Protection against Distributed Denial of Service Attacks
Teredo relays will act as a relay for IPv6 packets. Improperly
designed packet relays can be used by denial of service attackers to
hide their address, making the attack untraceable. The Teredo
service must include adequate protection against such misuse.
3.3.5. Compatibility with Ingress Filtering
Routers may perform ingress filtering by checking that the source
address of the packets received on a given interface is "legitimate",
i.e., belongs to network prefixes from which traffic is expected at a
network interface. Ingress filtering is a recommended practice, as
it thwarts the use of forged source IP addresses by malfeasant
hackers, notably to cover their tracks during denial of service
attacks. The Teredo specification must not force networks to disable
ingress filtering.
3.4. Model of Operation
The operation of Teredo involves four types of nodes: Teredo clients,
Teredo servers, Teredo relays, and "plain" IPv6 nodes.
Teredo clients start operation by interacting with a Teredo server,
performing a "qualification procedure". During this procedure, the
client will discover whether it is behind a cone, restricted cone, or
symmetric NAT. If the client is not located behind a symmetric NAT,
the procedure will be successful and the client will configure a
"Teredo address".
The Teredo IPv6 address embeds the "mapped address and port" through
which the client can receive IPv4/UDP packets encapsulating IPv6
packets. If the client is not located behind a cone NAT,
transmission of regular IPv6 packets must be preceded by an exchange
of "bubbles" that will install a mapping in the NAT. This document
specifies how the bubbles can be exchanged between Teredo clients in
order to enable transmission along a direct path.
Teredo clients can exchange IPv6 packets with plain IPv6 nodes (e.g.,
native nodes or 6to4 nodes) through Teredo relays. Teredo relays
advertise reachability of the Teredo prefix to a certain subset of
the IPv6 Internet: a relay set up by an ISP will typically serve only
the IPv6 customers of this ISP; a relay set-up for a site will only
serve the IPv6 hosts of this site. Dual-stack hosts may implement a
"local relay", allowing them to communicate directly with Teredo
hosts by sending IPv6 packets over UDP and IPv4 without having to
advertise a Teredo IPv6 address.
Teredo clients have to discover the relay that is closest to each
native IPv6 or 6to4 peer. They have to perform this discovery for
each native IPv6 or 6to4 peer with which they communicate. In order
to prevent spoofing, the Teredo clients perform a relay discovery
procedure by sending an ICMP echo request to the native host. This
message is a regularly formatted IPv6 ICMP packet, which is
encapsulated in UDP and sent by the client to its Teredo server; the
server decapsulates the IPv6 message and forwards it to the intended
IPv6 destination. The payload of the echo request contains a large
random number. The echo reply is sent by the peer to the IPv6
address of the client, and is forwarded through standard IPv6 routing
mechanisms. It will naturally reach the Teredo relay closest to the
native or 6to4 peer, and will be forwarded by this relay using the
Teredo mechanisms. The Teredo client will discover the IPv4 address
and UDP port used by the relay to send the echo reply, and will send
further IPv6 packets to the peer by encapsulating them in UDP packets
sent to this IPv4 address and port. In order to prevent spoofing,
the Teredo client verifies that the payload of the echo reply
contains the proper random number.
The procedures are designed so that the Teredo server only
participates in the qualification procedure and in the exchange of
bubbles and ICMP echo requests. The Teredo server never carries
actual data traffic. There are two rationales for this design:
reduce the load on the server in order to enable scaling, and avoid
privacy issues that could occur if a Teredo server kept copies of the
client’s data packets.
4. Teredo Addresses
The Teredo addresses are composed of 5 components:
+-------------+-------------+-------+------+-------------+
| Prefix | Server IPv4 | Flags | Port | Client IPv4 |
+-------------+-------------+-------+------+-------------+
- Prefix: the 32-bit Teredo service prefix.
- Server IPv4: the IPv4 address of a Teredo server.