Tech-invite3GPPspecsSIPRFCs
898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100

in Index   Prev   Next

RFC 4380

Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)

Pages: 53
Proposed Standard
Errata
Updated by:  59916081
Part 1 of 3 – Pages 1 to 12
None   None   Next

Top   ToC   RFC4380 - Page 1
Network Working Group                                         C. Huitema
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
Top   ToC   RFC4380 - Page 2
      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
Top   ToC   RFC4380 - Page 3

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.
Top   ToC   RFC4380 - Page 4

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.
Top   ToC   RFC4380 - Page 5

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.
Top   ToC   RFC4380 - Page 6

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
Top   ToC   RFC4380 - Page 7
   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.
Top   ToC   RFC4380 - Page 8
   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.
Top   ToC   RFC4380 - Page 9

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
Top   ToC   RFC4380 - Page 10
   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.
Top   ToC   RFC4380 - Page 11
   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.
Top   ToC   RFC4380 - Page 12
   - Flags: a set of 16 bits that document type of address and NAT.
   - Port: the obfuscated "mapped UDP port" of the Teredo service at
     the client.
   - Client IPv4: the obfuscated "mapped IPv4 address" of the client.

   In this format, both the "mapped UDP port" and "mapped IPv4 address"
   of the client are obfuscated.  Each bit in the address and port
   number is reversed; this can be done by an exclusive OR of the 16-bit
   port number with the hexadecimal value 0xFFFF, and an exclusive OR of
   the 32-bit address with the hexadecimal value 0xFFFFFFFF.

   The IPv6 addressing rules specify that "for all unicast addresses,
   except those that start with binary value 000, Interface IDs are
   required to be 64 bits long and to be constructed in Modified EUI-64
   format".  This dictates the encoding of the flags, 16 intermediate
   bits that should correspond to valid values of the most significant
   16 bits of a Modified EUI-64 ID:

          0       0 0       1
         |0       7 8       5
         +----+----+----+----+
         |Czzz|zzUG|zzzz|zzzz|
         +----+----+----+----+

   In this format:

   -  The bits "UG" should be set to the value "00", indicating a non-
      global unicast identifier;
   -  The bit "C" (cone) should be set to 1 if the client believes it is
      behind a cone NAT, to 0 otherwise; these values determine
      different server behavior during the qualification procedure, as
      specified in Section 5.2.1, as well as different bubble processing
      by clients and relays.
   -  The bits indicated with "z" must be set to zero and ignored on
      receipt.

   Thus, there are two currently specified values of the Flags field:
   "0x0000" (all null) if the cone bit is set to 0, and "0x8000" if the
   cone bit is set to 1.  (Further versions of this specification may
   assign new values to the reserved bits.)

   In some cases, Teredo nodes use link-local addresses.  These
   addresses contain a link-local prefix (FE80::/64) and a 64-bit
   identifier, constructed using the same format as presented above.  A
   difference between link-local addresses and global addresses is that
   the identifiers used in global addresses MUST include a global scope
   unicast IPv4 address, while the identifiers used in link-local
   addresses MAY include a private IPv4 address.