tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6081

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

Teredo Extensions

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

Updates:    4380


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                         D. Thaler
Request for Comments: 6081                                     Microsoft
Updates: 4380                                               January 2011
Category: Standards Track
ISSN: 2070-1721


                           Teredo Extensions

Abstract

   This document specifies a set of extensions to the Teredo protocol.
   These extensions provide additional capabilities to Teredo, including
   support for more types of Network Address Translations (NATs) and
   support for more efficient communication.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6081.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Top       Page 2 
Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Symmetric NAT Support Extension  . . . . . . . . . . . . .  9
     3.2.  UPnP-Enabled Symmetric NAT Extension . . . . . . . . . . . 11
     3.3.  Port-Preserving Symmetric NAT Extension  . . . . . . . . . 13
     3.4.  Sequential Port-Symmetric NAT Extension  . . . . . . . . . 14
     3.5.  Hairpinning Extension  . . . . . . . . . . . . . . . . . . 15
     3.6.  Server Load Reduction Extension  . . . . . . . . . . . . . 17
   4.  Message Syntax . . . . . . . . . . . . . . . . . . . . . . . . 18
     4.1.  Trailers . . . . . . . . . . . . . . . . . . . . . . . . . 18
     4.2.  Nonce Trailer  . . . . . . . . . . . . . . . . . . . . . . 19
     4.3.  Alternate Address Trailer  . . . . . . . . . . . . . . . . 19
     4.4.  Neighbor Discovery Option Trailer  . . . . . . . . . . . . 20
     4.5.  Random Port Trailer  . . . . . . . . . . . . . . . . . . . 21
   5.  Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 22
     5.1.  Common Processing  . . . . . . . . . . . . . . . . . . . . 22
       5.1.1.  Refresh Interval . . . . . . . . . . . . . . . . . . . 22
       5.1.2.  Trailer Processing . . . . . . . . . . . . . . . . . . 23
     5.2.  Symmetric NAT Support Extension  . . . . . . . . . . . . . 23
       5.2.1.  Abstract Data Model  . . . . . . . . . . . . . . . . . 24
       5.2.2.  Timers . . . . . . . . . . . . . . . . . . . . . . . . 24
       5.2.3.  Initialization . . . . . . . . . . . . . . . . . . . . 24
       5.2.4.  Message Processing . . . . . . . . . . . . . . . . . . 24
     5.3.  UPnP-Enabled Symmetric NAT Extension . . . . . . . . . . . 25
       5.3.1.  Abstract Data Model  . . . . . . . . . . . . . . . . . 26
       5.3.2.  Timers . . . . . . . . . . . . . . . . . . . . . . . . 26
       5.3.3.  Initialization . . . . . . . . . . . . . . . . . . . . 27
       5.3.4.  Message Processing . . . . . . . . . . . . . . . . . . 28
       5.3.5.  Shutdown . . . . . . . . . . . . . . . . . . . . . . . 29
     5.4.  Port-Preserving Symmetric NAT Extension  . . . . . . . . . 30
       5.4.1.  Abstract Data Model  . . . . . . . . . . . . . . . . . 30
       5.4.2.  Timers . . . . . . . . . . . . . . . . . . . . . . . . 31
       5.4.3.  Initialization . . . . . . . . . . . . . . . . . . . . 32
       5.4.4.  Message Processing . . . . . . . . . . . . . . . . . . 32
     5.5.  Sequential Port-Symmetric NAT Extension  . . . . . . . . . 35
       5.5.1.  Abstract Data Model  . . . . . . . . . . . . . . . . . 35
       5.5.2.  Timers . . . . . . . . . . . . . . . . . . . . . . . . 36
       5.5.3.  Initialization . . . . . . . . . . . . . . . . . . . . 37
       5.5.4.  Message Processing . . . . . . . . . . . . . . . . . . 37
     5.6.  Hairpinning Extension  . . . . . . . . . . . . . . . . . . 39
       5.6.1.  Abstract Data Model  . . . . . . . . . . . . . . . . . 39
       5.6.2.  Timers . . . . . . . . . . . . . . . . . . . . . . . . 39
       5.6.3.  Initialization . . . . . . . . . . . . . . . . . . . . 39
       5.6.4.  Message Processing . . . . . . . . . . . . . . . . . . 40

Top      ToC       Page 3 
     5.7.  Server Load Reduction Extension  . . . . . . . . . . . . . 41
       5.7.1.  Abstract Data Model  . . . . . . . . . . . . . . . . . 41
       5.7.2.  Timers . . . . . . . . . . . . . . . . . . . . . . . . 41
       5.7.3.  Initialization . . . . . . . . . . . . . . . . . . . . 42
       5.7.4.  Message Processing . . . . . . . . . . . . . . . . . . 42
   6.  Protocol Examples  . . . . . . . . . . . . . . . . . . . . . . 42
     6.1.  Symmetric NAT Support Extension  . . . . . . . . . . . . . 42
     6.2.  UPnP-Enabled Symmetric NAT Extension . . . . . . . . . . . 45
     6.3.  Port-Preserving Symmetric NAT Extension  . . . . . . . . . 47
     6.4.  Sequential Port-Symmetric NAT Extension  . . . . . . . . . 51
     6.5.  Hairpinning Extension  . . . . . . . . . . . . . . . . . . 54
     6.6.  Server Load Reduction Extension  . . . . . . . . . . . . . 57
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 58
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 58
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 58
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 58
     10.2. Informative References . . . . . . . . . . . . . . . . . . 59

1.  Introduction

   This document specifies extensions to the Teredo protocol, as
   specified in [RFC4380].  These extensions provide additional
   capabilities to Teredo, including support for more types of Network
   Address Translations (NATs) and support for more efficient
   communication.

2.  Terminology

   Because this document extends [RFC4380], it uses the following
   terminology, for consistency with [RFC4380].

   Address-Restricted NAT: A restricted NAT that accepts packets from an
   external host's IP address X and port Y if the internal host has sent
   a packet that is destined to IP address X regardless of the
   destination port.  In the terminology of [RFC4787], this is a NAT
   with Endpoint-Independent Mapping and Address-Dependent Filtering.

   Address-Symmetric NAT: A symmetric NAT that has multiple external IP
   addresses and that assigns different IP addresses and ports when
   communicating with different external hosts.

   Cone NAT: A NAT that maps all requests from the same internal IP
   address and port to the same external IP address and port.
   Furthermore, any external host can send a packet to the internal host
   by sending a packet to the mapped external address and port.  In the
   terminology of [RFC4787], this is a NAT with Endpoint-Independent
   Mapping and Endpoint-Independent Filtering.

Top      ToC       Page 4 
   Direct Bubble: A Teredo bubble that is sent directly to the IPv4 node
   whose Teredo address is contained in the Destination field of the
   IPv6 header, as specified in Section 2.8 of [RFC4380].  The IPv4
   Destination Address and UDP Destination Port fields contain a mapped
   address/port.

   Echo Test: A mechanism to predict the mapped address/port a
   sequential port-symmetric NAT is using for a client behind it.

   Hairpinning: A feature that is available in some NATs where two or
   more hosts are positioned behind a NAT and each of those hosts is
   assigned a specific external (public) address and port by the NAT.
   Hairpinning support in a NAT allows these hosts to send a packet to
   the external address and port that is assigned to one of the other
   hosts, and the NAT automatically routes the packet back to the
   correct host.  The term hairpinning is derived from the behavior of
   the packet, which arrives on, and is sent out to, the same NAT
   interface.

   Indirect Bubble: A Teredo bubble that is sent indirectly (via the
   destination's Teredo server) to another Teredo client, as specified
   in Section 5.2.4 of [RFC4380].

   Local Address/Port: The IPv4 address and UDP port from which a Teredo
   client sends Teredo packets.  The local port is referred to as the
   Teredo service port in [RFC4380].  The local address of a node may or
   may not be globally routable because the node can be located behind
   one or more NATs.

   Mapped Address/Port: A global IPv4 address and a UDP port that
   results from the translation of a node's own local address/port by
   one or more NATs.  The node learns these values through the Teredo
   protocol as specified in [RFC4380].  For symmetric NATs, the mapped
   address/port can be different for every peer with which a node tries
   to communicate.

   Network Address Translation (NAT): The process of converting between
   IP addresses used within an intranet or other private network and
   Internet IP addresses.

   Nonce: A time-variant random value used in the connection setup phase
   to prevent message replay and other types of attacks.

   Peer: A Teredo client with which another Teredo client needs to
   communicate.

Top      ToC       Page 5 
   Port-Preserving NAT: A NAT that translates a local address/port to a
   mapped address/port such that the mapped port has the same value as
   the local port, as long as that same mapped address/port has not
   already been used for a different local address/port.

   Port-Restricted NAT: A restricted NAT that accepts packets from an
   external host's IP address X and port Y only if the internal host has
   sent a packet destined to IP address X and port Y.  In the
   terminology of [RFC4787], this is a NAT with Endpoint-Independent
   Mapping and Address and Port-Dependent Filtering.

   Port-Symmetric NAT: A symmetric NAT that has only a single external
   IP address and hence only assigns different ports when communicating
   with different external hosts.

   Private Address: An IPv4 address that is not globally routable but is
   part of the private address space specified in Section 3 of
   [RFC1918].

   Public Address: An external global address used by a NAT.

   Restricted NAT: A NAT where all requests from the same internal IP
   address and port are mapped to the same external IP address and port.
   Unlike the cone NAT, an external host can send packets to an internal
   host (by sending a packet to the external mapped address and port)
   only if the internal host has first sent a packet to the external
   host.  There are two kinds of restricted NATs: address-restricted
   NATs and port-restricted NATs.

   Sequential Port-Symmetric NAT: A port-symmetric NAT that allocates
   external ports sequentially for every {internal IP address and port,
   destination IP address and port} tuple.  The delta used in the
   sequential assignment is typically 1 or 2 for most such NATs.

   Symmetric NAT: A NAT where all requests from the same internal IP
   address and port and to the same destination IP address and port are
   mapped to the same external IP address and port.  Requests from the
   same internal IP address and port to a different destination IP
   address and port may be mapped to a different external IP address and
   port.  Furthermore, a symmetric NAT accepts packets received from an
   external host's IP address X and port Y only if some internal host
   has sent packets to IP address X and port Y.  In the terminology of
   [RFC4787], this is a NAT with a mapping behavior of either Address-
   Dependent Mapping or Address- and Port-Dependent Mapping, and a
   filtering behavior of either Address-Dependent Filtering or Address-
   and Port-Dependent Filtering.

Top      ToC       Page 6 
   Teredo Bubble: A Teredo control message (specified in Section 2.8 of
   [RFC4380]) that is used to create a mapping in a NAT.  There are two
   types of Teredo bubbles: direct bubbles and indirect bubbles.

   Teredo Client: A node that has access to the IPv4 Internet and wants
   to gain access to the IPv6 Internet using the Teredo protocol.

   Teredo IPv6 Address: An IPv6 address of a Teredo client, as specified
   in Section 2.14 of [RFC4380].

   Teredo Secondary Server Address: A secondary IPv4 address of a Teredo
   server with which a Teredo client is configured, as specified in
   Section 5.2 of [RFC4380].

   Teredo Server: A node that has a globally routable address on the
   IPv4 Internet, and is used as a helper to provide IPv6 connectivity
   to Teredo clients.

   Teredo Server Address: A (primary) IPv4 address of a Teredo server
   with which a Teredo client is configured, as specified in Section 5.2
   of [RFC4380].

   UPnP-enabled NAT: A NAT that has the UPnP device control protocol
   enabled, as specified in [UPNPWANIP].  (Note that today, by default,
   most UPnP-capable NATs have the UPnP device control protocol
   disabled.)

   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 RFC 2119 [RFC2119].

3.  Overview

   The Teredo protocol (as specified in [RFC4380]) enables nodes located
   behind one or more IPv4 NATs to obtain IPv6 connectivity by tunneling
   packets over UDP.

   When a node behind a NAT needs to communicate with a peer (i.e.,
   another node) that is behind a NAT, there are four sets of IPv4
   address/port pairs of interest:

   o  The node's own IPv4 address/port.

   o  The external IPv4 address/port to which the node's NAT translates.

   o  The peer's own IPv4 address/port.

   o  The external IPv4 address/port to which the peer's NAT translates.

Top      ToC       Page 7 
   When the node sends a packet to a peer, the node needs to send it
   from the node's own IPv4 address/port, destined to the peer's
   external IPv4 address/port.  By the time it arrives at the peer
   (i.e., after passing through both NATs), the peer will see the same
   packet as coming from the node's external IPv4 address/port, destined
   to the peer's own IPv4 address/port.

   In this document, the term local address/port refers to a Teredo
   client's own IPv4 address/port, and mapped address/port refers to the
   external IPv4 address/port to which its NAT translates the local
   address/port.  That is, the mapped address/port is what the IPv4
   Internet sees the Teredo client as.

   A Teredo client running on a node communicates with a Teredo server
   to discover its mapped address/port.  The mapped address/port, along
   with the Teredo server address, is used to generate an IPv6 address
   known as a Teredo IPv6 address.  This allows any peer that gets the
   node's IPv6 address to easily determine the external IPv4 address/
   port to which to send IPv6 packets encapsulated in IPv4 UDP messages.

   This document specifies extensions to the Teredo protocol.  These
   Teredo extensions are independent of each other and can be
   implemented in isolation, except that the UPnP-Symmetric NAT
   Extension and the Port-Preserving Symmetric NAT Extension both
   require the Symmetric NAT Support Extension to be implemented.  An
   implementation of this specification can support any combination of
   the Teredo extensions, subject to the above-mentioned restriction.

   The following matrix outlines the connectivity improvements of some
   of the extensions outlined in this document.

Top      ToC       Page 8 
                                 Destination NAT
          |      |      |      |      |      | Port-|      |      |
          |      |      |      | UPnP | UPnP | pres.| Seq. |      |
          |      | Addr.| Port | Port | Port | Port-| Port-| Port-| Addr
Source NAT| Cone | rest.| rest.| rest.| symm.| symm.| symm.| symm.| symm
----------+------+------+------+------+------+------+------+------+-----
Cone      |  Yes |  Yes |  Yes |  Yes |  SNS |  SNS |  SNS |  SNS |  SNS
----------+------+------+------+------+------+------+------+------+-----
Address   |  Yes |  Yes |  Yes |  Yes |  SNS |  SNS |  SNS |  SNS |  No
restricted|      |      |      |      |      |      |      |      |
----------+------+------+------+------+------+------+------+------+-----
Port      |  Yes |  Yes |  Yes |  Yes |  No  | SNS+ | SNS+ |  No  |  No
restricted|      |      |      |      |      |  PP  |  SS  |      |
----------+------+------+------+------+------+------+------+------+-----
UPnP Port-|  Yes |  Yes |  Yes |  Yes | SNS+ |  No  |  No  |  No  |  No
restricted|      |      |      |      | UPnP |      |      |      |
----------+------+------+------+------+------+------+------+------+-----
UPnP Port |  SNS |  SNS |  No  | SNS+ | SNS+ |  No  |  No  |  No  |  No
symmetric |      |      |      | UPnP | UPnP |      |      |      |
----------+------+------+------+------+------+------+------+------+-----
Port-     |      |      |  SNS |      |      |  SNS |  SNS |      |
preserving|  SNS |  SNS |   +  |  No  |  No  |   +  |   +  |  No  |  No
Port-     |      |      |  PP  |      |      |  PP  |  SS  |      |
symmetric |      |      |      |      |      |      |      |      |
----------+------+------+------+------+------+------+------+------+-----
Sequential|      |      |  SNS |      |      |      |      |      |
Port-     |  SNS |  SNS |   +  |  No  |  No  |  No  |  No  |  No  |  No
symmetric |      |      |  SS  |      |      |      |      |      |
----------+------+------+------+------+------+------+------+------+-----
Port-     |  SNS |  SNS |  No  |  No  |  No  |  No  |  No  |  No  |  No
symmetric |      |      |      |      |      |      |      |      |
----------+------+------+------+------+------+------+------+------+-----
Address-  |  SNS |  No  |  No  |  No  |  No  |  No  |  No  |  No  |  No
symmetric |      |      |      |      |      |      |      |      |
----------+------+------+------+------+------+------+------+------+-----

     Yes = Supported by [RFC4380].

     SNS = Supported with the Symmetric NAT Support Extension.

SNS+UPnP = Supported with the Symmetric NAT Support Extension and UPnP
           Symmetric NAT Extension.

  SNS+PP = Supported with the Symmetric NAT Support Extension and Port-
           Preserving Symmetric NAT Extension.

  SNS+SS = Supported with the Symmetric NAT Support Extension and
           Sequential Port-Symmetric NAT Extension.

Top      ToC       Page 9 
      No = No connectivity.

    Figure 1: Matrix of Connectivity Improvements for Teredo Extensions

   Note that as with [RFC4380], if the qualification process is not
   successful, Teredo will not be configured with an IPv6 address, and
   connectivity will function as if Teredo were not present.  Similarly,
   for any combination of NAT types that are not supported by Teredo and
   the extensions defined herein, the connectivity tests between a
   client and a peer will fail within a finite period of time, allowing
   the client to handle this case as with any other type of unreachable
   destination address (e.g., by trying another address of the
   destination such as a native IPv4 address).

3.1.  Symmetric NAT Support Extension

   The qualification procedure (as specified in Section 5.2.1 of
   [RFC4380]) is a process that allows a Teredo client to determine the
   type of NAT that it is behind, in addition to its mapped address/port
   as seen by its Teredo server.  However, Section 5.2.1 of [RFC4380]
   suggests that if the client learns it is behind a symmetric NAT, the
   Teredo client should go into an "offline state" where it is not able
   to use Teredo.  The primary reason for doing so is that it is not
   easy for Teredo clients to connect to each other if either or both of
   them are positioned behind a symmetric NAT.  Because of the way a
   symmetric NAT works, a peer sees a different mapped address/port in
   the IPv4/UDP headers of packets coming from a Teredo client than the
   node's Teredo server sees (and hence appears in the node's Teredo
   IPv6 address).  Consequently, a symmetric NAT does not allow incoming
   packets from a peer that are addressed to the mapped address/port
   embedded in the node's Teredo IPv6 address.  Thus, the incoming
   packets are dropped and communication with Teredo clients behind
   symmetric NATs is not established.

   With the Symmetric NAT Support Extension, Teredo clients begin to use
   Teredo even after they detect that they are positioned behind a
   symmetric NAT.

   Consider the topology shown in Figure 2.  Teredo Client B uses Teredo
   Server 2 to learn that its mapped address/port is 192.0.2.10:8192,
   and constructs a Teredo IPv6 address, as specified in Section 4 of
   [RFC4380].  Hence, c633:6476 is the hexadecimal value of the address
   of Teredo Server 2 (198.51.100.118), the mapped port is exclusive-
   OR'ed with 0xffff to form dfff, and the Mapped Address is exclusive-
   OR'ed with 0xffffffff to form 3fff:fdf5.

Top      ToC       Page 10 
   Teredo Client A uses Teredo Server 1 to learn that its mapped
   address/port is 192.0.2.1:4096 and, with this extension, constructs a
   Teredo IPv6 address (as specified in Section 4 of [RFC4380]) even
   though it learns that it is behind a symmetric NAT.  Hence, cb00:7178
   is the hexadecimal value of the address of Teredo Server 1
   (203.0.113.120), the mapped port is exclusive-OR'ed with 0xffff to
   form efff, and the Mapped Address is exclusive-OR'ed with 0xffffffff
   to form 3fff:fdfe.

   The Symmetric NAT Support Extension enables a Teredo client
   positioned behind a symmetric NAT to communicate with Teredo peers
   positioned behind a cone or address-restricted NATs as follows,
   depending on what side initiates the communication.

               --------------------------------------------
              /                                            \
             <               IPv6 Internet                  >
              \                                            /
               -|----------------------------------------|-
                |                                        |
          +----------+                             +----------+
          |  Teredo  |                             |  Teredo  |
          | Server 1 |                             | Server 2 |
          +----------+                             +----------+
   203.0.113.120|                          198.51.100.118|
               -|----------------------------------------|-
              /                                            \
             <               IPv4 Internet                  >
              \                                            /
               -|----------------------------------------|-
       192.0.2.1|                              192.0.2.10|
   UDP port 4096|                           UDP port 8192|
           +---------+                             +----------+
           |Symmetric|                             |Other type|
           |   NAT   |                             |  of NAT  |
           +---------+                             +----------+
                |                                        |
       +-----------------+                      +-----------------+
       | Teredo client A |                      | Teredo client B |
       +-----------------+                      +-----------------+
2001:0:cb00:7178:0:efff:3fff:fdfe      2001:0:c633:6476:0:dfff:3fff:fdf5
          Teredo Address                           Teredo Address

                      Figure 2: Symmetric NAT Example

   In the first case, assume that a Teredo Client B (B) positioned
   behind a cone or address-restricted NATs initiates communication with
   Teredo Client A (A) positioned behind a symmetric NAT.  B sends an

Top      ToC       Page 11 
   indirect bubble via A's server (Teredo Server 1) to A, and A responds
   with a direct bubble.  This direct bubble reaches B, because it is
   positioned behind a cone or address-restricted NAT.  However, the
   mapped address/port in the IPv4/UDP headers of the direct bubble are
   different from the mapped address/port embedded in A's Teredo IPv6
   address.  B therefore remembers the mapped address/port of the direct
   bubble and uses them for future communication with A, and thus
   communication is established.

   In the second case, assume that A, positioned behind a symmetric NAT,
   initiates communication with B, positioned behind a cone or address-
   restricted NAT.  A sends an indirect bubble to B via B's server
   (Teredo Server 2), and B responds with a direct bubble.  This direct
   bubble is dropped by A's symmetric NAT because the direct bubble is
   addressed to the mapped address/port embedded in A's Teredo IPv6
   address.  However, communication can be established by having B
   respond with an indirect bubble via A's server (Teredo Server 1).
   Now the scenario is similar to the first case and communication will
   be established.

3.2.  UPnP-Enabled Symmetric NAT Extension

   The UPnP-enabled Symmetric NAT Extension is dependent on the
   Symmetric NAT Support Extension.  Only if Teredo clients have been
   enabled to acquire a Teredo IPv6 address in spite of being behind a
   symmetric NAT will this extension help in traversing UPnP-enabled
   Symmetric NATs.

   The Symmetric NAT Support Extension enables communication between
   Teredo clients behind symmetric NATs with Teredo clients behind cone
   NATs or address-restricted NATs.  However, clients behind symmetric
   NATs can still not communicate with clients behind port-restricted
   NATs or symmetric NATs.

   Referring again to Figure 2 (see Section 3.1), assume that Teredo
   Client A is positioned behind a symmetric NAT and initiates
   communication with Client B, which is positioned behind a port-
   restricted NAT.  Client A sends a direct bubble and an indirect
   bubble to Client B via Client B's server (Teredo Server 2).  As per
   the characteristics of the symmetric NAT, the IPv4 source of the
   direct bubble contains a different mapped address and/or port than
   the one embedded in the Teredo server.  This direct bubble is dropped
   because Client B's NAT does not have state to let it pass through,
   and Client B does not learn the mapped address/port used in the IPv4/
   UDP headers.  In response to the indirect bubble from Client A,
   Client B sends a direct bubble destined to the mapped address/port
   embedded in Client A's Teredo IPv6 address.  This direct bubble is
   dropped because Client A's NAT does not have state to accept packets

Top      ToC       Page 12 
   destined to that mapped address/port.  The direct bubble does,
   however, cause Client B's NAT to set up outgoing state for the mapped
   address/port embedded in Client A's Teredo IPv6 address.

   As described in Section 3.1, Client B also sends an indirect bubble
   that elicits a direct bubble from Client A.  Unlike the case in
   Section 3.1, however, the direct bubble from Client A is dropped as
   Client B's NAT does not have state for the mapped address/port that
   Client A's NAT uses.  Note that Client B's NAT is port-restricted and
   hence requires both the mapped address and port to be the same as in
   its outgoing state, whereas in Section 3.1, Client A's NAT was a cone
   or address-restricted NAT which only required the mapped address (but
   not port) to be the same.  Thus, communication between Client A and
   Client B fails.  If Client B were behind a symmetric NAT, the problem
   is further complicated by Client B's NAT using a different outgoing
   mapped address/port than the one embedded in Client B's Teredo IPv6
   address.

   If a Teredo client is separated from the global Internet by a single
   UPnP-enabled symmetric or port-restricted NAT, it can communicate
   with other Teredo clients that are positioned behind a single UPnP-
   enabled symmetric or port-restricted NAT as follows.

   Teredo clients, before communicating with the Teredo server during
   the qualification procedure, use UPnP to reserve a translation from a
   local address/port to a mapped-address/port.  Therefore, during the
   qualification procedure, the Teredo server reflects back the reserved
   mapped address/port, which then is included in the Teredo IPv6
   address.  The mapping created by UPnP allows the NAT to forward
   packets destined for the mapped address/port to the local address/
   port, independent of the source of the packets.  It typically does
   not, however, cause packets sourced from the local address/port to be
   translated to have the mapped address/port as the external source and
   hence continues to function as a symmetric NAT in this respect.

   Thus, a Teredo client, positioned behind a UPnP-enabled symmetric
   NAT, can receive a direct bubble sent by any Teredo peer.  The Teredo
   client compares the peer's mapped address/port as seen in the IPv4/
   UDP headers with the mapped address/port in the peer's Teredo IPv6
   address.  If the two mappings are different, the packet was sent by
   another Teredo client positioned behind a symmetric NAT.  The
   Symmetric NAT Support Extension suggested that the Teredo client use
   the peer's mapped address/port seen in the IPv4/UDP headers for
   future communication.  However, because symmetric NAT-to-symmetric
   NAT communication would not have been possible anyway, the Teredo
   client sends back a direct bubble to the mapped port/address embedded

Top      ToC       Page 13 
   in the peer's Teredo IPv6 address.  If the peer is also situated
   behind a UPnP-enabled NAT, the direct bubble will make it through and
   communication will be established.

   Even though communication is established between the two Teredo IPv6
   addresses, the mappings will be asymmetric in the two directions of
   data transfer.  Specifically, incoming packets will be destined to
   the reserved mapped address/port that is embedded in the Teredo IPv6
   address.  Outgoing packets will instead appear to come from a
   different mapped address/port due to the symmetric NAT behavior.

3.3.  Port-Preserving Symmetric NAT Extension

   The Port-Preserving Symmetric NAT Extension is dependent on the
   Symmetric NAT Support Extension (Section 3.1).  Only if Teredo
   clients have been enabled to acquire a Teredo IPv6 address in spite
   of being behind a symmetric NAT will this extension help in
   traversing port-preserving symmetric NATs.

   The Symmetric NAT Support Extension enables communication between
   Teredo clients behind symmetric NATs with Teredo clients behind cone
   NATs or address-restricted NATs.  However, clients behind symmetric
   NATs can still not communicate with clients behind port-restricted or
   symmetric NATs, as described in Section 3.2.  Note that the Port-
   Preserving Symmetric NAT Extension described here is independent of
   the UPnP-enabled Symmetric NAT Extension, described in Section 3.2.

   If a Teredo client is positioned behind a port-preserving symmetric
   NAT, the client can communicate with other Teredo clients positioned
   behind a port-restricted NAT or a port-preserving symmetric NAT as
   follows.

   Teredo clients compare the mapped port learned during the
   qualification procedure with their local port to determine if they
   are positioned behind a port-preserving NAT.  If both the mapped port
   and the local port have the same value, the Teredo client is
   positioned behind a port-preserving NAT.  At the end of the
   qualification procedure, the Teredo client also knows if it is
   positioned behind a symmetric NAT, as described in Section 3.1.

   Teredo clients positioned behind port-preserving symmetric NATs can
   also listen on randomly chosen local ports.  If the randomly chosen
   local port has not been used by the symmetric NAT as a mapped port in
   a prior port-mapping, the NAT uses the same port number as the mapped
   port.  Thus, the challenge is to get the first direct bubble sent out
   from the random port to be destined to a valid destination address
   and port.  When the mapped address/port is embedded in the
   destination's Teredo IPv6 address, this is easy.

Top      ToC       Page 14 
   The communication setup is more complicated when the destination
   Teredo client is also positioned behind a port-preserving symmetric
   NAT.  In such a case, both Teredo clients need to send their first
   direct bubbles to the correct destination mapped address/port.  Thus,
   the protocol messages, which communicate one Teredo client's random
   port number to the other Teredo client, must be exchanged indirectly
   (via Teredo servers).  When one Teredo client has access to the other
   Teredo client's random port number, it can send a direct bubble
   destined to the mapped address embedded in the destination's Teredo
   IPv6 address, and the mapped port can be the same as the
   destination's random port number.  If both NATs are port-preserving,
   port-preserved mappings are created on both NATs and the second
   direct bubble succeeds in reaching the destination.

3.4.  Sequential Port-Symmetric NAT Extension

   The Sequential Port-Symmetric NAT Extension is dependent on the
   Symmetric NAT Support Extension (Section 3.1).  This extension helps
   in traversing a sequential port-symmetric NAT only if Teredo clients
   are enabled to acquire a Teredo IPv6 address even when behind a
   symmetric NAT.

   When the Sequential Port-Symmetric NAT Extension is used, if a Teredo
   client is positioned behind a sequential port-symmetric NAT, the
   client can communicate with other Teredo clients that are positioned
   behind a port-restricted NAT as follows.

   During qualification, if the client discovers it is behind a
   symmetric NAT that is not port-preserving, the client assumes by
   default that it is behind a sequential port-symmetric NAT.  This
   assumption is proactive for the following reasons:

   o  There is no perfect method of discovering whether the client is
      behind a sequential port-symmetric NAT.

   o  These kinds of NATs are notorious for changing their behavior.  At
      times, they could be sequential port-symmetric and at other times
      not.

   o  There is no other solution for symmetric NAT traversal so this is
      a last resort.

   Teredo clients positioned behind sequential port-symmetric NATs can
   also listen on a randomly chosen local port when communicating with a
   peer.  To predict the external port being used for a given peer, the
   client sends three packets:

Top      ToC       Page 15 
   o  Packet 1 is a router solicitation (as specified in Section 5.2.1
      of [RFC4380]) sent to the Teredo server address.

   o  Packet 2 is a direct bubble sent to the peer.

   o  Packet 3 is a router solicitation sent to the secondary Teredo
      server address.

   As part of the normal Teredo protocol, the Teredo server responds to
   packets 1 and 3.  Based on the information in the responses, the
   client now knows that Packet 1 was seen as coming from one external
   port, and Packet 3 was seen as coming from another external port.
   Assuming the NAT is a sequential port-symmetric NAT, the external
   port for Packet 2 is estimated (or predicted) to be midway between
   the external ports for Packets 1 and 3.  Note that because other
   applications might also have been using the NAT between packets 1 and
   3, the actual port might not be exactly the midpoint.

   The Teredo client then communicates the predicted port to its peer,
   which sends a direct bubble to the communicated port.  If the
   communicated port is indeed the external port for Packet 2, the
   direct bubble will reach the Teredo client.

3.5.  Hairpinning Extension

   Hairpinning support in a NAT routes packets that are sent from a
   private (local) address destined to a public (mapped) address of the
   NAT, back to another private (local) destination address behind the
   same NAT.  If hairpinning support is not available in a NAT, two
   Teredo clients behind the same NAT are not able to communicate with
   each other, as specified in Section 8.3 of [RFC4380].

   The Hairpinning Extension enables two clients behind the same NAT to
   talk to each other when the NAT does not support hairpinning.  This
   process is illustrated in the following diagram.

Top      ToC       Page 16 
               --------------------------------------------
              /                                            \
             <               IPv6 Internet                  >
              \                                            /
               --------------------|-----------------------
                                   |
                             +----------+
                             |  Teredo  |
                             |  Server  |
                             +----------+
                      203.0.113.120|
               --------------------|-----------------------
              /                                            \
             <               IPv4 Internet                  >
              \                                            /
               --------------------|-----------------------
                     198.51.100.118|
                           NAT +-------+
                       without |  NAT  |
                   hairpinning |   E   |
                       support +-------+
                                   |
                +------------------+--------------------+
     192.168.1.0|                            192.168.1.1|
   UDP port 4095|                          UDP port 4096|
           +---------+                            +----------+
           |   NAT   |                            |    NAT   |
           |    F    |                            |     G    |
           +---------+                            +----------+
                |                                       |
       +-----------------+                     +-----------------+
       | Teredo client A |                     | Teredo client B |
       +-----------------+                     +-----------------+
2001:0:cb00:7178:0:f000:39cc:9b89      2001:0:cb00:7178:0:efff:39cc:9b89
          Teredo Address                          Teredo Address

                       Figure 3: Hairpinning Example

   The Teredo Client A (A) includes, as part of its indirect bubble sent
   to Teredo Client B (B), its local address/port.  B, upon receiving
   the indirect bubble, tries to establish communication by sending
   direct bubbles to the mapped address/port of A, and also to the local
   address/port of B.

   If a Teredo client is part of a multi-NAT hierarchy and the NAT to
   which the Teredo client is connected supports the UPnP protocol (as
   specified in [UPNPWANIP]), the Teredo client can use UPnP to
   determine the mapped address/port assigned to it by the NAT.  This

Top      ToC       Page 17 
   information can be included along with the local address/port when
   sending the indirect bubble.  The destination Teredo client now tries
   to establish a connection by sending direct bubbles to the mapped
   address/port in the Teredo IPv6 address, to the local address/port
   included in the bubble, and also to the mapped address/port included
   in the bubble.

   Note that UPnP support is only required if the Teredo clients are
   behind different NATs in a multi-NAT hierarchy.  Without UPnP
   support, the Hairpinning Extension still allows two hosts behind the
   same non-hairpinning NAT to communicate using their Teredo IPv6
   addresses.

3.6.  Server Load Reduction Extension

   If communication between a Teredo client and a Teredo peer was
   successfully established but at a later stage was silent for a while,
   for efficiency, it is best to refresh the mapping state in the NATs
   that are positioned between them.  To refresh the communication
   between itself and a Teredo peer, a Teredo client needs to solicit a
   direct bubble response from the Teredo peer.  An indirect bubble is
   sent to solicit a direct bubble response from a Teredo peer, as
   specified in Section 5.2.4 of [RFC4380].  However, these indirect
   bubbles increase the load on the Teredo server.

   The Server Load Reduction Extension allows Teredo clients to send
   direct bubbles most of the time instead of sending indirect bubbles
   all of the time in the following way:

   1.  When a Teredo client tries to refresh its communication with a
       Teredo peer, it uses a direct bubble instead of an indirect
       bubble.  However, because direct bubbles do not normally solicit
       a response, the direct bubble format is extended to be able to
       solicit a response.

   2.  When a Teredo client receives a direct bubble that is soliciting
       a response, the Teredo client responds with a direct bubble.

   3.  If attempts to re-establish communication with the help of direct
       bubbles fail, the Teredo client starts over the process of
       establishing communication with the Teredo peer, as specified in
       Section 5.2.4 of [RFC4380].

Top      ToC       Page 18 
4.  Message Syntax

   All Teredo messages are transported over the User Datagram Protocol
   (UDP), as specified in Section 3 of [RFC4380].

   In addition, Section 5.2.3 of [RFC4380] states:

      An IPv6 packet is deemed valid if it conforms to [RFC2460]: the
      protocol identifier should indicate an IPv6 packet and the payload
      length should be consistent with the length of the UDP datagram in
      which the packet is encapsulated.  In addition, the client should
      check that the IPv6 destination address correspond [sic] to its
      own Teredo address.

   This document updates the word "consistent" above as follows.  The
   IPv6 payload length is "consistent" with the length of the UDP
   datagram if the IPv6 packet length (i.e., the Payload Length value in
   the IPv6 header plus the IPv6 header size) is less than or equal to
   the UDP payload length (i.e., the Length value in the UDP header
   minus the UDP header size).  This allows the use of trailers after
   the IPv6 packet, which are defined in the following sections.

4.1.  Trailers

   Teredo packets can carry a variable number of type-length-value (TLV)
   encoded trailers, of the following format (intended to be similar to
   the use of IPv6 options defined in [RFC2460] section 4.2):

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |        Value (variable)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type (1 byte): 8-bit identifier of the type of trailer.

   Length (1 byte): 8-bit unsigned integer.  Length of the Value field
   of this trailer, in octets.

   Value (variable): Trailer-Type-specific data.

   The trailer Type identifiers are internally encoded such that their
   highest-order two bits specify the action that is to be taken if the
   host does not recognize the trailer Type:

Top      ToC       Page 19 
   00, 10, 11 -  skip over this trailer and continue processing the
      packet.

   01 -  discard the packet.

4.2.  Nonce Trailer

   The Nonce Trailer is used by the Symmetric NAT Support Extension (and
   therefore the UPnP-enabled Symmetric NAT Extension and Port-
   Preserving Symmetric NAT Extension also) and the Hairpinning
   Extension.  The Nonce Trailer can be present in both indirect and
   direct bubbles.  The nonce in the Nonce Trailer helps authenticate a
   Teredo client positioned behind a Symmetric NAT.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |             Nonce             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              ...              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type (1 byte): The Trailer Option type.  This field MUST be set to
   0x01.

   Length (1 byte): The length in bytes of the rest of the option.  This
   field MUST be set to 0x04.

   Nonce (4 bytes): The nonce value.

4.3.  Alternate Address Trailer

   The Alternate Address Trailer is used by the Hairpinning Extension.
   The Alternate Address Trailer MUST NOT be present in any packets
   other than indirect bubbles sent by a Teredo client.  The Alternate
   Address Trailer provides another Teredo client positioned behind the
   same NAT with more address options that it can use to connect.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |              Alternate Address/Port List (variable)           |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      ToC       Page 20 
   Type (1 byte): The Trailer Option type.  This field MUST be set to
   0x03.

   Length (1 byte): The length in bytes of the rest of the option.  The
   value of this field MUST be in the range 8 to 26 (i.e., 2 bytes for
   the Reserved field, and 6 bytes for each entry in the Alternate
   Address/Port List).  This allows for a minimum of one address/port
   mapping and a maximum of four address/port mappings to be advertised.
   It SHOULD be at most 14 as a maximum of two address/port mappings can
   be determined by Teredo: one local address/port and one obtained
   using UPnP.  Because the length of the alternate address/port is 6
   bytes, the valid range of values is only 8, 14, 20, and 26.

   Reserved (2 bytes): This field MUST be set to 0x0000 and ignored on
   receipt.

   Alternate Address/Port List (variable): An array of additional
   address/port pairs that can be used by other Teredo clients to
   communicate with the sender.  Each alternate address/port entry MUST
   be formatted as follows:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      IPv4 Address                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Port             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv4 Address (4 bytes): An IPv4 address in network byte order.  This
   field MUST contain a valid unicast address.

   Port (2 bytes): A port number in network byte order.  This field MUST
   NOT be zero.

4.4.  Neighbor Discovery Option Trailer

   The Neighbor Discovery Option Trailer is used by the Server Load
   Reduction Extension because it allows direct bubbles to encode an
   IPv6 Neighbor Solicitation (Section 4.3 of [RFC4861]), in addition to
   an IPv6 Neighbor Advertisement (Section 4.4 of [RFC4861]).  This
   allows packets to be sent without having to relay them through a
   Teredo server.  The Neighbor Discovery Option Trailer allows the
   receiver to differentiate between a direct bubble that is soliciting
   a response versus a regular direct bubble.  This allows Teredo
   clients to use direct bubbles to refresh inactive connections instead
   of using indirect bubbles.

Top      ToC       Page 21 
                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |     Length    | DiscoveryType |   Reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              ...              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type (1 byte): The Trailer Option type.  This field MUST be set to
   0x04.

   Length (1 byte): The length in bytes of the rest of the option.  This
   field MUST be set to 0x04.

   DiscoveryType (1 byte): This field MUST be set to one of the
   following values:

      TeredoDiscoverySolicitation (0x00): The receiver is requested to
      respond with a direct bubble of DiscoveryType
      TeredoDiscoveryAdvertisement.

      TeredoDiscoveryAdvertisement (0x01): The direct bubble is in
      response to a direct bubble or an indirect bubbles containing
      DiscoveryType TeredoDiscoverySolicitation.

   Reserved (3 bytes): This field MUST be set to 0x000000 on
   transmission and ignored on receipt.

4.5.  Random Port Trailer

   The Random Port Trailer is used by the Port-Preserving Symmetric NAT
   Extension in both indirect and direct bubbles.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |     Length    |          Random Port          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type (1 byte): The Trailer Option type.  This field MUST be set to
   0x05.

   Length (1 byte): The length in bytes of the rest of the option.  This
   field MUST be set to 0x02.

   Random Port (2 bytes): The external port that the sender predicts
   that its NAT has assigned it for communication with the destination.
   This field MUST be specified in network byte order.


Next RFC Part