tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 4380

 Errata 
Proposed STD
Pages: 53
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: ~ipv6

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

Part 1 of 3, p. 1 to 12
None       Next RFC Part

Updated by:    5991    6081


Top       ToC       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       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       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       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       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       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       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       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       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       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       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       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.


Next RFC Part