File: rfc6081.html

package info (click to toggle)
doc-rfc 20230121-1
links: PTS, VCS
area: non-free
in suites: bookworm, forky, sid, trixie
size: 1,609,944 kB
file content (3301 lines) | stat: -rw-r--r-- 173,592 bytes
parent folder | download | duplicates (2)
<pre>Internet Engineering Task Force (IETF)                         D. Thaler
Request for Comments: 6081                                     Microsoft
Updates: <a href="./rfc4380">4380</a>                                               January 2011
Category: Standards Track
ISSN: 2070-1721


                           <span class="h1">Teredo Extensions</span>

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 <a href="./rfc5741#section-2">Section&nbsp;2 of RFC 5741</a>.

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

Copyright Notice

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

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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.







<span class="grey">Thaler                       Standards Track                    [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


Table of Contents

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




<span class="grey">Thaler                       Standards Track                    [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


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

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   This document specifies extensions to the Teredo protocol, as
   specified in [<a href="./rfc4380" title="&quot;Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)&quot;">RFC4380</a>].  These extensions provide additional
   capabilities to Teredo, including support for more types of Network
   Address Translations (NATs) and support for more efficient
   communication.

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Terminology</span>

   Because this document extends [<a href="./rfc4380" title="&quot;Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)&quot;">RFC4380</a>], it uses the following
   terminology, for consistency with [<a href="./rfc4380" title="&quot;Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)&quot;">RFC4380</a>].

   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 [<a href="./rfc4787" title="&quot;Network Address Translation (NAT) Behavioral Requirements for Unicast UDP&quot;">RFC4787</a>], 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 [<a href="./rfc4787" title="&quot;Network Address Translation (NAT) Behavioral Requirements for Unicast UDP&quot;">RFC4787</a>], this is a NAT with Endpoint-Independent
   Mapping and Endpoint-Independent Filtering.



<span class="grey">Thaler                       Standards Track                    [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


   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 <a href="./rfc4380#section-2.8">Section&nbsp;2.8 of [RFC4380]</a>.  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 <a href="./rfc4380#section-5.2.4">Section&nbsp;5.2.4 of [RFC4380]</a>.

   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 [<a href="./rfc4380" title="&quot;Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)&quot;">RFC4380</a>].  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 [<a href="./rfc4380" title="&quot;Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)&quot;">RFC4380</a>].  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.






<span class="grey">Thaler                       Standards Track                    [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


   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 [<a href="./rfc4787" title="&quot;Network Address Translation (NAT) Behavioral Requirements for Unicast UDP&quot;">RFC4787</a>], 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 <a href="./rfc1918#section-3">Section&nbsp;3 of
   [RFC1918]</a>.

   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
   [<a href="./rfc4787" title="&quot;Network Address Translation (NAT) Behavioral Requirements for Unicast UDP&quot;">RFC4787</a>], 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.





<span class="grey">Thaler                       Standards Track                    [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


   Teredo Bubble: A Teredo control message (specified in <a href="./rfc4380#section-2.8">Section&nbsp;2.8 of
   [RFC4380]</a>) 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 <a href="./rfc4380#section-2.14">Section&nbsp;2.14 of [RFC4380]</a>.

   Teredo Secondary Server Address: A secondary IPv4 address of a Teredo
   server with which a Teredo client is configured, as specified in
   <a href="./rfc4380#section-5.2">Section&nbsp;5.2 of [RFC4380]</a>.

   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 <a href="./rfc4380#section-5.2">Section&nbsp;5.2
   of [RFC4380]</a>.

   UPnP-enabled NAT: A NAT that has the UPnP device control protocol
   enabled, as specified in [<a href="#ref-UPNPWANIP" title="&quot;WANIPConnection:1&quot;">UPNPWANIP</a>].  (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 <a href="./rfc2119">RFC 2119</a> [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>].

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Overview</span>

   The Teredo protocol (as specified in [<a href="./rfc4380" title="&quot;Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)&quot;">RFC4380</a>]) 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.



<span class="grey">Thaler                       Standards Track                    [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


   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.





















<span class="grey">Thaler                       Standards Track                    [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


                                 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 [<a href="./rfc4380" title="&quot;Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)&quot;">RFC4380</a>].

     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.



<span class="grey">Thaler                       Standards Track                    [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


      No = No connectivity.

    Figure 1: Matrix of Connectivity Improvements for Teredo Extensions

   Note that as with [<a href="./rfc4380" title="&quot;Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)&quot;">RFC4380</a>], 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).

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  Symmetric NAT Support Extension</span>

   The qualification procedure (as specified in <a href="./rfc4380#section-5.2.1">Section&nbsp;5.2.1 of
   [RFC4380]</a>) 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, <a href="./rfc4380#section-5.2.1">Section&nbsp;5.2.1 of [RFC4380]</a>
   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 <a href="./rfc4380#section-4">Section&nbsp;4 of
   [RFC4380]</a>.  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.






<span class="grey">Thaler                       Standards Track                    [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


   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 <a href="./rfc4380#section-4">Section&nbsp;4 of [RFC4380]</a>) 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.

               --------------------------------------------
              /                                            \
             &lt;               IPv6 Internet                  &gt;
              \                                            /
               -|----------------------------------------|-
                |                                        |
          +----------+                             +----------+
          |  Teredo  |                             |  Teredo  |
          | Server 1 |                             | Server 2 |
          +----------+                             +----------+
   203.0.113.120|                          198.51.100.118|
               -|----------------------------------------|-
              /                                            \
             &lt;               IPv4 Internet                  &gt;
              \                                            /
               -|----------------------------------------|-
       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



<span class="grey">Thaler                       Standards Track                   [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


   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.

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  UPnP-Enabled Symmetric NAT Extension</span>

   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 <a href="#section-3.1">Section 3.1</a>), 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



<span class="grey">Thaler                       Standards Track                   [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


   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 <a href="#section-3.1">Section 3.1</a>, Client B also sends an indirect bubble
   that elicits a direct bubble from Client A.  Unlike the case in
   <a href="#section-3.1">Section 3.1</a>, 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 <a href="#section-3.1">Section 3.1</a>, 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





<span class="grey">Thaler                       Standards Track                   [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


   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.

<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>.  Port-Preserving Symmetric NAT Extension</span>

   The Port-Preserving Symmetric NAT Extension is dependent on the
   Symmetric NAT Support Extension (<a href="#section-3.1">Section 3.1</a>).  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 <a href="#section-3.2">Section 3.2</a>.  Note that the Port-
   Preserving Symmetric NAT Extension described here is independent of
   the UPnP-enabled Symmetric NAT Extension, described in <a href="#section-3.2">Section 3.2</a>.

   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 <a href="#section-3.1">Section 3.1</a>.

   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.



<span class="grey">Thaler                       Standards Track                   [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


   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.

<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>.  Sequential Port-Symmetric NAT Extension</span>

   The Sequential Port-Symmetric NAT Extension is dependent on the
   Symmetric NAT Support Extension (<a href="#section-3.1">Section 3.1</a>).  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:





<span class="grey">Thaler                       Standards Track                   [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


   o  Packet 1 is a router solicitation (as specified in <a href="./rfc4380#section-5.2.1">Section&nbsp;5.2.1
      of [RFC4380]</a>) 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.

<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>.  Hairpinning Extension</span>

   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 <a href="./rfc4380#section-8.3">Section&nbsp;8.3 of [RFC4380]</a>.

   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.
















<span class="grey">Thaler                       Standards Track                   [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


               --------------------------------------------
              /                                            \
             &lt;               IPv6 Internet                  &gt;
              \                                            /
               --------------------|-----------------------
                                   |
                             +----------+
                             |  Teredo  |
                             |  Server  |
                             +----------+
                      203.0.113.120|
               --------------------|-----------------------
              /                                            \
             &lt;               IPv4 Internet                  &gt;
              \                                            /
               --------------------|-----------------------
                     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 [<a href="#ref-UPNPWANIP" title="&quot;WANIPConnection:1&quot;">UPNPWANIP</a>]), the Teredo client can use UPnP to
   determine the mapped address/port assigned to it by the NAT.  This



<span class="grey">Thaler                       Standards Track                   [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


   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.

<span class="h3"><a class="selflink" id="section-3.6" href="#section-3.6">3.6</a>.  Server Load Reduction Extension</span>

   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 <a href="./rfc4380#section-5.2.4">Section&nbsp;5.2.4 of [RFC4380]</a>.  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
       <a href="./rfc4380#section-5.2.4">Section&nbsp;5.2.4 of [RFC4380]</a>.









<span class="grey">Thaler                       Standards Track                   [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Message Syntax</span>

   All Teredo messages are transported over the User Datagram Protocol
   (UDP), as specified in <a href="./rfc4380#section-3">Section&nbsp;3 of [RFC4380]</a>.

   In addition, <a href="./rfc4380#section-5.2.3">Section&nbsp;5.2.3 of [RFC4380]</a> states:

      An IPv6 packet is deemed valid if it conforms to [<a href="./rfc2460" title="&quot;Internet Protocol, Version 6 (IPv6) Specification&quot;">RFC2460</a>]: 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.

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  Trailers</span>

   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 <a href="./rfc2460#section-4.2">[RFC2460] section&nbsp;4.2</a>):

                        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:







<span class="grey">Thaler                       Standards Track                   [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


   00, 10, 11 -  skip over this trailer and continue processing the
      packet.

   01 -  discard the packet.

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  Nonce Trailer</span>

   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.

<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>.  Alternate Address Trailer</span>

   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)           |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




<span class="grey">Thaler                       Standards Track                   [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


   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.

<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>.  Neighbor Discovery Option Trailer</span>

   The Neighbor Discovery Option Trailer is used by the Server Load
   Reduction Extension because it allows direct bubbles to encode an
   IPv6 Neighbor Solicitation (<a href="./rfc4861#section-4.3">Section&nbsp;4.3 of [RFC4861]</a>), in addition to
   an IPv6 Neighbor Advertisement (<a href="./rfc4861#section-4.4">Section&nbsp;4.4 of [RFC4861]</a>).  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.




<span class="grey">Thaler                       Standards Track                   [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


                        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.

<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>.  Random Port Trailer</span>

   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.



<span class="grey">Thaler                       Standards Track                   [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Protocol Details</span>

<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>.  Common Processing</span>

   The behavior in this section applies to multiple extensions.

   Packets equivalent to those sent for a peer the first time a
   connection is being established MAY be generated at other
   implementation-specific times.  (For example, an implementation might
   choose to do so when its Neighbor Cache Entry for the peer is in the
   PROBE state.)

<span class="h4"><a class="selflink" id="section-5.1.1" href="#section-5.1.1">5.1.1</a>.  Refresh Interval</span>

   <a href="./rfc4380#section-5.2">Section&nbsp;5.2 of [RFC4380]</a> states:

      The client must regularly perform the maintenance procedure in
      order to guarantee that the Teredo service port remains usable.
      The need to use this procedure or not depends on the delay since
      the last interaction with the Teredo server.  The refresh
      procedure takes as a parameter the "Teredo refresh interval".
      This parameter is initially set to 30 seconds; it can be updated
      as a result of the optional "interval determination procedure".
      The randomized refresh interval is set to a value randomly chosen
      between 75% and 100% of the refresh interval.

   This requirement can be problematic when the client is behind a NAT
   that expires state in less than 30 seconds.  The optional interval
   determination procedure (<a href="./rfc4380#section-5.2.7">Section&nbsp;5.2.7 of [RFC4380]</a>) also does not
   provide for intervals under 30 seconds.  Hence, this document refines
   the behavior by saying the initial parameter SHOULD be configurable
   and the default MUST be 30 seconds.  An implementation MAY set the
   randomized refresh interval to a value randomly chosen within an
   implementation-specific range.  Such a range MUST fall within 50% to
   150% of the refresh interval.

   <a href="./rfc4380#section-5.2.5">Section&nbsp;5.2.5 of [RFC4380]</a> states that:

      At regular intervals, the client MUST check the "date and time of
      the last interaction with the Teredo server" to ensure that at
      least one packet has been received in the last Randomized Teredo
      Refresh Interval.  If this is not the case, the client SHOULD send
      a router solicitation message to the server, as specified in
      <a href="#section-5.2.1">Section 5.2.1</a>;







<span class="grey">Thaler                       Standards Track                   [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


   This document refines the behavior as follows.  A Teredo client MAY
   choose to send additional router solicitation messages to the server
   at other implementation-specific times.  (For example, an
   implementation might choose to do so when its Neighbor Cache Entry
   for the router is in the PROBE state.)

<span class="h4"><a class="selflink" id="section-5.1.2" href="#section-5.1.2">5.1.2</a>.  Trailer Processing</span>

   A Teredo client MUST process the sequence of trailers in the same
   order as they appear in the packet.  If the Teredo client does not
   recognize the trailer Type while processing the trailers in the
   Teredo packet, the client MUST discard the packet if the highest-
   order bits of the trailer Type contain 01, or else the Teredo client
   MUST skip past the trailer.  A Teredo client MUST stop processing the
   trailers as soon as a malformed trailer appears in the sequence of
   trailers in the packet.  A trailer is defined as malformed if it has
   any of the following properties:

   o  The length in bytes of the remainder of the UDP datagram is less
      than 2 (the size of the Type and Length fields of a trailer).

   o  The length in bytes of the remainder of the UDP datagram is less
      than 2 + the value of the Length field of the trailer.

<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>.  Symmetric NAT Support Extension</span>

   <a href="./rfc4380#section-5.2.1">Section&nbsp;5.2.1 of [RFC4380]</a> advises that no Teredo IPv6 address be
   configured if the Teredo client is positioned behind a symmetric NAT.
   For Teredo clients positioned behind symmetric NATs, the mapped
   address/port used by its NAT when communicating with a Teredo peer is
   different from the mapped address/port embedded in the Teredo
   client's Teredo IPv6 address.  The Symmetric NAT Support Extension
   provides a solution to this problem.

   In addition, <a href="./rfc4380#section-5.2.9">Section&nbsp;5.2.9 of [RFC4380]</a> specifies a direct IPv6
   connectivity test to determine that the mapped address/port in the
   Teredo IPv6 address of a peer is not spoofed.  It does this through
   the use of a nonce in ICMPv6 Echo Request and Response messages
   (which are defined in <a href="./rfc4443#section-4">Section&nbsp;4 of [RFC4443]</a>).  However, the direct
   IPv6 connectivity test is limited only to communication between
   Teredo IPv6 addresses and non-Teredo IPv6 addresses.  In the
   following extension, we introduce the use of a nonce in direct and
   indirect bubbles and provide a mechanism to verify that the mapped
   address/port are not spoofed.

   This extension is optional; an implementation SHOULD support it.





<span class="grey">Thaler                       Standards Track                   [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


<span class="h4"><a class="selflink" id="section-5.2.1" href="#section-5.2.1">5.2.1</a>.  Abstract Data Model</span>

   This section describes a conceptual model of possible data
   organization that an implementation maintains to participate in this
   protocol.  The described organization is provided to facilitate the
   explanation of how the protocol behaves.  This document does not
   mandate that implementations adhere to this model as long as their
   external behavior is consistent with that described in this document.

   In addition to the state specified in <a href="./rfc4380#section-5.2">Section&nbsp;5.2 of [RFC4380]</a>, the
   following are also required.

   Peer Entry: The following additional state is required on a per-peer
   basis:

   o  Nonce Sent: The value of the nonce sent in the last indirect
      bubble sent to the Teredo peer.

   o  Nonce Received: The value of the nonce received in the last
      indirect bubble received from the Teredo peer.

<span class="h4"><a class="selflink" id="section-5.2.2" href="#section-5.2.2">5.2.2</a>.  Timers</span>

   No timers are necessary other than those in [<a href="./rfc4380" title="&quot;Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)&quot;">RFC4380</a>].

<span class="h4"><a class="selflink" id="section-5.2.3" href="#section-5.2.3">5.2.3</a>.  Initialization</span>

   No initialization is necessary other than that specified in
   [<a href="./rfc4380" title="&quot;Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)&quot;">RFC4380</a>].

<span class="h4"><a class="selflink" id="section-5.2.4" href="#section-5.2.4">5.2.4</a>.  Message Processing</span>

   Except as specified in the following sections, the rules for message
   processing are as specified in [<a href="./rfc4380" title="&quot;Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)&quot;">RFC4380</a>].

<span class="h5"><a class="selflink" id="section-5.2.4.1" href="#section-5.2.4.1">5.2.4.1</a>.  Sending an Indirect Bubble</span>

   The rules for when indirect bubbles are sent to a Teredo peer are
   specified in <a href="./rfc4380#section-5.2.6">Section&nbsp;5.2.6 of [RFC4380]</a>.  When a Teredo client sends
   an indirect bubble, it MUST generate a random 4-byte value and
   include it in the Nonce field of a Nonce Trailer (<a href="#section-4.2">Section 4.2</a>)
   appended to the indirect bubble, and also store it in the Nonce Sent
   field of its Peer Entry for that Teredo peer.








<span class="grey">Thaler                       Standards Track                   [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


<span class="h5"><a class="selflink" id="section-5.2.4.2" href="#section-5.2.4.2">5.2.4.2</a>.  Sending a Direct Bubble</span>

   The rules for when direct bubbles are sent to a Teredo peer are
   specified in <a href="./rfc4380#section-5.2.6">Section&nbsp;5.2.6 of [RFC4380]</a>.  When a Teredo client sends
   a direct bubble to a peer after receiving an indirect bubble with a
   Nonce Trailer, it MUST include in the direct bubble a Nonce Trailer
   with the same nonce value.

   If the Teredo client is about to send a direct bubble before it has
   received an indirect bubble from the Teredo peer, the Teredo client
   MUST NOT include a Nonce Trailer.

<span class="h5"><a class="selflink" id="section-5.2.4.3" href="#section-5.2.4.3">5.2.4.3</a>.  Receiving an Indirect Bubble</span>

   The rules for processing an indirect bubble are specified in <a href="./rfc4380#section-5.2.3">Section</a>
   <a href="./rfc4380#section-5.2.3">5.2.3 of [RFC4380]</a>.  In addition, when a Teredo client receives an
   indirect bubble containing a Nonce Trailer, the Teredo client MUST
   store the nonce in the Nonce Received field of its Peer Entry for
   that Teredo peer.  If an indirect bubble is received without a Nonce
   Trailer, and the Nonce Received field in the Peer Entry is non-zero,
   the Nonce Received field SHOULD be set to zero.

<span class="h5"><a class="selflink" id="section-5.2.4.4" href="#section-5.2.4.4">5.2.4.4</a>.  Receiving a Direct Bubble</span>

   If the mapped address/port of the direct bubble matches the mapped
   address/port embedded in the source Teredo IPv6 address, the direct
   bubble MUST be accepted, as specified in <a href="./rfc4380#section-5.2.3">Section&nbsp;5.2.3 of [RFC4380]</a>.

   In addition, if the mapped address/port does not match the embedded
   address/port but the direct bubble contains a Nonce Trailer with a
   nonce that matches the Nonce Sent field of the Teredo peer, the
   direct bubble MUST be accepted.

   If neither of the above conditions is true, the direct bubble MUST be
   dropped.

   If the direct bubble is accepted, the Teredo client MUST record the
   mapped address/port from which the direct bubble is received in the
   mapped address/port fields of the Teredo peer, as specified in
   <a href="./rfc4380#section-5.2">Section&nbsp;5.2 of [RFC4380]</a>.

<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>.  UPnP-Enabled Symmetric NAT Extension</span>

   The UPnP-enabled Symmetric NAT Extension is optional; an
   implementation SHOULD support it.  This extension has the Symmetric
   NAT Support Extension (<a href="#section-5.2">Section 5.2</a>) as a dependency.  Any node that
   implements this extension MUST also implement the Symmetric NAT
   Support Extension.



<span class="grey">Thaler                       Standards Track                   [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


<span class="h4"><a class="selflink" id="section-5.3.1" href="#section-5.3.1">5.3.1</a>.  Abstract Data Model</span>

   This section describes a conceptual model of possible data
   organization that an implementation maintains to participate in this
   protocol.  The described organization is provided to facilitate the
   explanation of how the protocol behaves.  This document does not
   mandate that implementations adhere to this model as long as their
   external behavior is consistent with that described in this document.

   This extension extends the abstract data model in <a href="#section-5.2.1">Section 5.2.1</a> by
   adding the following additional fields.

   UPnP-Enabled NAT flag: This is a Boolean value, set to TRUE if the
   NAT positioned in front of the Teredo client is UPnP enabled.  The
   default value of this flag is FALSE.

   UPnP-Mapped Address/Port: The mapped address/port assigned via UPnP
   to the Teredo client by the UPnP-enabled NAT behind which the Teredo
   client is positioned.  Note that this field has a valid value only if
   the NAT to which the Teredo client is connected is UPnP enabled.
   Also, note that if the Teredo client is positioned behind a single
   NAT only (as opposed to a series of nested NATs), this value is the
   same as the mapped address/port embedded in its Teredo IPv6 address.

   Symmetric NAT flag: This is a Boolean value, set to TRUE if the
   Teredo client is positioned behind a symmetric NAT.

   Peer Entry: The following state needs to be added on a per-peer
   basis:

   o  Symmetric Peer flag: This is a Boolean value and is TRUE if the
      Teredo peer is positioned behind a symmetric NAT.

   A Teredo client SHOULD also maintain the following state that is
   persisted across reboots:

   o  Persisted UPnP-Mapped Port: The mapped port assigned via UPnP to
      the Teredo client by the UPnP-enabled NAT behind which the Teredo
      client is positioned.  Note that this value is the same as the
      UPnP-Mapped Port value when both are non-zero.  The default value
      is all zero bytes.

<span class="h4"><a class="selflink" id="section-5.3.2" href="#section-5.3.2">5.3.2</a>.  Timers</span>

   No timers are necessary other than those in [<a href="./rfc4380" title="&quot;Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)&quot;">RFC4380</a>].






<span class="grey">Thaler                       Standards Track                   [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


<span class="h4"><a class="selflink" id="section-5.3.3" href="#section-5.3.3">5.3.3</a>.  Initialization</span>

   Prior to beginning the qualification procedure, the Teredo client
   MUST first perform the uninitialization procedure specified in
   <a href="#section-5.3.5.1">Section 5.3.5.1</a> if the Persisted UPnP-Mapped Port is supported and
   non-zero.

   The Teredo client MUST then invoke the AddPortMapping function, as
   specified in Section 2.4.16 of [<a href="#ref-UPNPWANIP" title="&quot;WANIPConnection:1&quot;">UPNPWANIP</a>], with the following
   parameters:

   o  NewRemoteHost: "" (empty string)

   o  NewExternalPort: Local Port value

   o  NewProtocol: UDP

   o  NewInternalPort: Local Port value

   o  NewInternalClient: Local Address value

   o  NewEnabled: TRUE

   o  NewPortMappingDescription: "TEREDO"

   o  NewLeaseDuration: 0

   The successful completion of the AddPortMapping function indicates
   that the NAT has created a port mapping from the external port of the
   NAT to the internal port of the Teredo client node.  The parameters
   are specified so that any external host should be able to send
   packets to the Teredo client by sending packets to the mapped
   address/port.  If the AddPortMapping function fails, the Teredo
   client MUST continue without using this extension.  Otherwise, it
   MUST proceed as follows.

   The Teredo client MUST set the UPnP-Mapped Port (and Persisted UPnP-
   Mapped Port, if supported) to the Local Port value specified in
   AddPortMapping.  The Teredo client MUST then call the
   GetExternalIPAddress function specified in Section 2.4.18 of
   [<a href="#ref-UPNPWANIP" title="&quot;WANIPConnection:1&quot;">UPNPWANIP</a>].  If the GetExternalIPAddress function fails, the Teredo
   client SHOULD perform the uninitialization procedure specified in
   <a href="#section-5.3.5.1">Section 5.3.5.1</a> and continue without using this extension.  If the
   GetExternalIPAddress function succeeds, the Teredo client MUST
   proceed as follows.






<span class="grey">Thaler                       Standards Track                   [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


   The Teredo client MUST set the UPnP-Mapped Address to the address
   returned from the GetExternalIPAddress function, and set the UPnP-
   Enabled NAT flag to TRUE.

   During the qualification procedure (as specified in <a href="./rfc4380#section-5.2.1">Section&nbsp;5.2.1 of
   [RFC4380]</a>) when the Teredo client receives a response from the
   secondary Teredo server, the Teredo client MUST compare the mapped
   address/port learned from the secondary Teredo server with the mapped
   address/port associated with the Teredo server.  If either the mapped
   address or the mapped port value is different, the Symmetric NAT flag
   MUST be set to TRUE.

   After the qualification procedure, the mapped address/port learned
   from the Teredo server MUST be compared to the UPnP-Mapped Address/
   Port.  If both are the same, the Teredo client is positioned behind a
   single NAT and the UPnP-Mapped Address/Port MUST be zeroed out.

<span class="h4"><a class="selflink" id="section-5.3.4" href="#section-5.3.4">5.3.4</a>.  Message Processing</span>

   Except as specified in the following sections, the rules for message
   processing are as specified in <a href="./rfc4380#section-5.2.3">Section&nbsp;5.2.3 of [RFC4380]</a>.

<span class="h5"><a class="selflink" id="section-5.3.4.1" href="#section-5.3.4.1">5.3.4.1</a>.  Receiving a Direct Bubble</span>

   Except as indicated below, the rules for handling a direct bubble are
   as specified in <a href="#section-5.2.4.4">Section 5.2.4.4</a>.

   A Teredo client positioned behind a UPnP-enabled NAT (port-restricted
   NAT as well as symmetric NAT) will receive all packets sent to the
   mapped address/port embedded in its Teredo IPv6 address.  Thus, when
   a Teredo client receives a direct bubble, it MUST compare the mapped
   address/port from which the packet was received with the mapped
   address/port embedded in the Teredo IPv6 address in the source
   address field of the IPv6 header.  If the two are not the same, it
   indicates that the Teredo peer is positioned behind a symmetric NAT,
   and it MUST set the Symmetric Peer flag in its Peer Entry.

<span class="h5"><a class="selflink" id="section-5.3.4.2" href="#section-5.3.4.2">5.3.4.2</a>.  Sending a Direct Bubble</span>

   The rules for sending a direct bubble are specified in <a href="./rfc4380#section-5.2.6">Section&nbsp;5.2.6
   of [RFC4380]</a> and <a href="#section-5.2.4.2">Section 5.2.4.2</a> of this document.  These rules are
   further refined as follows.

   If the Teredo client sending the direct bubble meets all of the
   following criteria:

   o  The Symmetric NAT flag is set to TRUE.




<span class="grey">Thaler                       Standards Track                   [Page 28]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-29" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


   o  The UPnP-Enabled NAT flag is set to TRUE.

   o  The UPnP-Mapped Address/Port are set to zero.

   o  The peer's Symmetric Peer flag is set to TRUE.

   then the Teredo client MUST send the direct bubble to the mapped
   address/port embedded in the peer's Teredo IPv6 address.

   This is because Symmetric-to-Symmetric and Port-Restricted-to-
   Symmetric NAT communication between the Teredo client and the peer
   would have failed anyway.  However, by taking a chance that the peer
   might also be positioned behind a UPnP-enabled NAT just like the
   Teredo client itself, the Teredo client can try sending the direct
   bubble to the mapped address/port in the peer's Teredo IPv6 address.
   If the packet does go through, communication is established.

<span class="h5"><a class="selflink" id="section-5.3.4.3" href="#section-5.3.4.3">5.3.4.3</a>.  Sending a Data Packet</span>

   The rules for sending a data packet are specified in <a href="./rfc4380#section-5.2.4">Section&nbsp;5.2.4 of
   [RFC4380]</a>.  These rules are further refined as follows.

   If the Teredo client sending the data packet meets all of the
   following criteria:

   o  The Symmetric NAT flag is set to TRUE.

   o  The UPnP-Enabled NAT flag is set to TRUE.

   o  The UPnP-Mapped Address/Port are set to zero.

   o  The peer's Symmetric Peer flag is set to TRUE.

   then the Teredo client MUST send the data packet to the mapped
   address/port embedded in the peer's Teredo IPv6 address.

<span class="h4"><a class="selflink" id="section-5.3.5" href="#section-5.3.5">5.3.5</a>.  Shutdown</span>

   When Teredo client functionality is being shut down, uninitialization
   MUST be performed as specified in <a href="#section-5.3.5.1">Section 5.3.5.1</a>.

<span class="h5"><a class="selflink" id="section-5.3.5.1" href="#section-5.3.5.1">5.3.5.1</a>.  Uninitialization</span>

   First determine the mapped port as follows.  If Persisted UPnP-Mapped
   Port is supported, use it as the mapped port.  Otherwise, use the
   UPnP-Mapped Port.





<span class="grey">Thaler                       Standards Track                   [Page 29]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-30" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


   If the mapped port is non-zero, the Teredo client MUST call the
   DeletePortMapping function, as specified in Section 2.4.17 of
   [<a href="#ref-UPNPWANIP" title="&quot;WANIPConnection:1&quot;">UPNPWANIP</a>], with the following parameters:

   o  NewRemoteHost: "" (empty string)

   o  NewExternalPort: the mapped port

   o  NewProtocol: UDP

<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>.  Port-Preserving Symmetric NAT Extension</span>

   The Port-Preserving Symmetric NAT Extension is optional; an
   implementation SHOULD support it.  This extension has the Symmetric
   NAT Support Extension (as specified in <a href="#section-5.2">Section 5.2</a>) as a dependency.
   Any node that implements this extension MUST also implement the
   Symmetric NAT Support Extension.

<span class="h4"><a class="selflink" id="section-5.4.1" href="#section-5.4.1">5.4.1</a>.  Abstract Data Model</span>

   This section describes a conceptual model of possible data
   organization that an implementation maintains to participate in this
   protocol.  The described organization is provided to facilitate the
   explanation of how the protocol behaves.  This document does not
   mandate that implementations adhere to this model as long as their
   external behavior is consistent with that described in this document.

   The Port-Preserving Symmetric NAT Extension extends the abstract data
   model in <a href="#section-5.2.1">Section 5.2.1</a> by adding the following additional fields.

   Port-Preserving NAT flag: This is a Boolean value, set to TRUE if the
   Teredo client is positioned behind a port-preserving NAT.

   Symmetric NAT flag: This is a Boolean value, set to TRUE if the
   Teredo client is positioned behind a symmetric NAT.

   Peer Entry: The following fields need to be added on a per-peer
   basis:

   o  Random Port: This field contains the value of the external port
      that the Teredo client predicts that its NAT has assigned it for
      communication with the peer.  Set to zero by default.

   o  Peer Random Port: This field contains the value of the random port
      that the peer is using for communication with this Teredo client.
      Set to zero by default.





<span class="grey">Thaler                       Standards Track                   [Page 30]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-31" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


   o  Direct Receive on Primary Port: This is a Boolean value, set to
      TRUE if a packet is received from the Teredo peer on the primary
      local port.  Set to FALSE by default.

   o  Direct Receive on Random Port: This is a Boolean value, set to
      TRUE if a packet is received from the Teredo peer on the Random
      Port.  Set to FALSE by default.

   o  Connection Refresh Count: This field contains the number of direct
      bubbles that have been sent to the peer since the last time data
      was sent to the peer.

   o  Last Data Packet Sent Timestamp: This field contains the timestamp
      of the last data packet sent to the peer.  This timestamp is
      different from the field that stores the data and time of last
      transmission to the peer (as specified in <a href="./rfc4380#section-5.2">Section&nbsp;5.2 of
      [RFC4380]</a>) because the RFC-defined field is also updated every
      time a direct bubble is sent.

<span class="h4"><a class="selflink" id="section-5.4.2" href="#section-5.4.2">5.4.2</a>.  Timers</span>

   Other than those in [<a href="./rfc4380" title="&quot;Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)&quot;">RFC4380</a>], the Port-Preserving Symmetric NAT
   Extension requires the following additional timer.

   Peer Refresh Timer: A timer to refresh peer connections through the
   random port, on which no data has been sent for a while.

<span class="h5"><a class="selflink" id="section-5.4.2.1" href="#section-5.4.2.1">5.4.2.1</a>.  Peer Refresh Timer Expiry</span>

   When the Peer Refresh Timer expires, the Teredo client MUST go
   through its list of peers and for each peer to which the Teredo
   client is communicating through the random port, the Teredo client
   MUST check the Last Data Packet Sent Timestamp to determine if data
   has been sent to the peer in the last 30 seconds, and check the
   Connection Refresh Count field to determine if the count has reached
   the maximum allowed value of 20.  If both checks are FALSE, the
   Teredo client MUST send a direct bubble (as specified in
   <a href="#section-5.4.4.3">Section 5.4.4.3</a>) to the peer and increment the Connection Refresh
   Count.  This direct bubble is sent as an attempt to keep the port
   mappings on all the intermediate NATs alive while the application/
   user may be temporarily inactive.  If on the other hand, data has
   been sent to the peer in the last 30 seconds, the Connection Refresh
   Count MUST be reset to zero.

   The Peer Refresh Timer MUST then be rescheduled to expire in 30
   seconds.





<span class="grey">Thaler                       Standards Track                   [Page 31]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-32" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


<span class="h4"><a class="selflink" id="section-5.4.3" href="#section-5.4.3">5.4.3</a>.  Initialization</span>

   In addition to the behavior specified in [<a href="./rfc4380" title="&quot;Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)&quot;">RFC4380</a>], the Port-
   Preserving NAT flag and Symmetric NAT flag MUST be set to FALSE when
   the Teredo client is started.  The Peer Refresh Timer MUST be started
   and scheduled to expire in 30 seconds.

   During the qualification procedure (as specified in <a href="./rfc4380#section-5.2.1">Section&nbsp;5.2.1 of
   [RFC4380]</a>), when the Teredo client receives a response from the
   Teredo server address, the Teredo client MUST compare the Port value
   in the origin indication, as specified in <a href="./rfc4380#section-5.1.1">Section&nbsp;5.1.1 of [RFC4380]</a>,
   with the Local Port value.  If both values match, the client MUST set
   the Port-Preserving NAT flag to TRUE.

<span class="h4"><a class="selflink" id="section-5.4.4" href="#section-5.4.4">5.4.4</a>.  Message Processing</span>

<span class="h5"><a class="selflink" id="section-5.4.4.1" href="#section-5.4.4.1">5.4.4.1</a>.  Sending a Data Packet</span>

   On receiving a data packet to be transmitted to the Teredo peer (in
   addition to the rules specified in <a href="./rfc4380#section-5.2.4">Section&nbsp;5.2.4 of [RFC4380]</a>), the
   Teredo client MUST update the Last Data Packet Sent Timestamp when
   the packet is actually sent.

<span class="h5"><a class="selflink" id="section-5.4.4.2" href="#section-5.4.4.2">5.4.4.2</a>.  Sending an Indirect Bubble</span>

   The rules for sending an indirect bubble are as specified in
   <a href="#section-5.2.4.1">Section 5.2.4.1</a> of this document and <a href="./rfc4380#section-5.2.6">Section&nbsp;5.2.6 of [RFC4380]</a>.  In
   addition to those rules, if the Port-Preserving NAT flag is TRUE, the
   Teredo client MUST do the following:

   o  If the Symmetric NAT flag is set, the Teredo peer is not marked as
      "trusted" (as specified in <a href="./rfc4380#section-5.2">Section&nbsp;5.2 of [RFC4380]</a>), and the
      Random Port is zero, the Teredo client MUST first select a random
      port number to use, and then begin listening on that port.  Since
      the NAT is port-preserving, the Teredo client can predict that the
      external port assigned will be equal to the random port chosen,
      and hence the Teredo client MUST store the random port chosen in
      the Random Port field of the Peer Entry.

   o  If the Random Port value is non-zero, the Teredo client MUST
      append a Random Port Trailer to the indirect bubble.










<span class="grey">Thaler                       Standards Track                   [Page 32]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-33" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


<span class="h5"><a class="selflink" id="section-5.4.4.3" href="#section-5.4.4.3">5.4.4.3</a>.  Sending a Direct Bubble</span>

   The rules for when direct bubbles are sent to a Teredo peer are as
   specified in <a href="./rfc4380#section-5.2.6">Section&nbsp;5.2.6 of [RFC4380]</a>.  In addition,
   <a href="#section-5.2.4.2">Section 5.2.4.2</a> defines rules for enabling communication for clients
   positioned behind a symmetric NAT.  In addition to the rules defined
   in both the aforementioned sections, if the Port-Preserving NAT flag
   is TRUE, the following rules apply also.

   If the Symmetric NAT flag is set, and the Teredo peer is not marked
   as "trusted" (as specified in <a href="./rfc4380#section-5.2">Section&nbsp;5.2 of [RFC4380]</a>) the Teredo
   client MUST send a direct bubble destined to the mapped address/port
   embedded in the Teredo IPv6 address of the Teredo peer.  If the peer
   Random Port field is non-zero, the Teredo client MUST send another
   direct bubble from its own random port, destined to the peer random
   port.  The IPv4 destination address MUST be the mapped address
   embedded in the Teredo IPv6 address.  In addition, the Teredo client
   MUST include the Random Port Trailer (<a href="#section-4.5">Section 4.5</a>).

<span class="h5"><a class="selflink" id="section-5.4.4.4" href="#section-5.4.4.4">5.4.4.4</a>.  Receiving an Indirect Bubble</span>

   The rules for processing an indirect bubble are as specified in
   <a href="#section-5.2.4.3">Section 5.2.4.3</a> of this document and <a href="./rfc4380#section-5.2.3">Section&nbsp;5.2.3 of [RFC4380]</a>.  In
   addition to these rules, if the incoming indirect bubble has a Random
   Port Trailer, the following additional processing MUST be done.

   If the Peer Random Port field of the Peer Entry is zero, the Teredo
   client MUST store the port from the Random Port Trailer in the Peer
   Random Port field of the Peer Entry.

   If the Peer Random Port field is non-zero and if either the Peer
   Random Port field and the new advertised port have the same value, or
   if active data has been exchanged between the two Teredo clients in
   the last 30 seconds (that is, "time of last transmission" or "time of
   last reception", as specified in <a href="./rfc4380#section-5.2">Section&nbsp;5.2 of [RFC4380]</a>, is set to
   a time that is less than 30 seconds ago), the new advertised port
   value MUST be ignored.

   If the Peer Random Port field is non-zero and the new advertised port
   value is different from the Peer Random Port value, and it has been
   more than 30 seconds since the last exchange of data packets between
   the two Teredo clients, (that is, "time of last transmission" and
   "time of last reception" are set to a time that is more than 30
   seconds ago), the Teredo client SHOULD store the new advertised port
   value in the Peer Random Port field and, if the Port-Preserving NAT
   flag is TRUE, then clear the Random Port field, and stop listening on
   the old random port.  This allows communication to be re-established
   if either side changes the random port that it is using.



<span class="grey">Thaler                       Standards Track                   [Page 33]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-34" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


<span class="h5"><a class="selflink" id="section-5.4.4.5" href="#section-5.4.4.5">5.4.4.5</a>.  Receiving a Direct Bubble</span>

   The rules for handling direct bubbles are specified in
   <a href="#section-5.2.4.4">Section 5.2.4.4</a> of this document and <a href="./rfc4380#section-5.2.3">Section&nbsp;5.2.3 of [RFC4380]</a>.  The
   rules for whether to accept a direct bubble are extended as follows,
   when the Port-Preserving NAT flag is TRUE:

   o  If the direct bubble is received on the primary port and the
      Teredo peer is not "trusted", the status field of the Teredo
      client MUST be changed to "trusted" and the Direct Receive on
      Primary Port flag MUST be set to TRUE.  The mapped address/port
      from which the direct bubble was received MUST be recorded in the
      mapped address/port fields of the Teredo peer, as specified in
      <a href="./rfc4380#section-5.2">Section&nbsp;5.2 of [RFC4380]</a>.  The Teredo client MUST then set the
      Random Port field in the Peer Entry to zero and stop listening on
      the old random port.

   o  If the direct bubble is received on the primary port, the Teredo
      peer is "trusted", and the Direct Receive on Primary flag is set
      to TRUE, the Teredo client MUST compare the mapped address/port of
      the direct bubble with the mapped address/port of the Peer Entry.
      If both mappings are the same, the direct bubble MUST be accepted.
      If the mappings are different and it has been more than 30 seconds
      since the last packet exchange with the Teredo peer (that is,
      "time of last transmission" and "time of last reception", as
      defined in <a href="./rfc4380#section-5.2">Section&nbsp;5.2 of [RFC4380]</a>, are set to a time that is
      more than 30 seconds ago), the mapping on the Teredo peer's NAT
      has changed and communication needs to be re-established.  This
      MUST be done by changing the status of the peer to "not-trusted",
      setting the Direct Receive on Primary Port flag to FALSE, and
      sending an indirect bubble to the Teredo peer via its Teredo
      server.

   o  If the direct bubble is received on the primary port, the Teredo
      peer is "trusted", the Direct Receive on Primary Port flag is set
      to FALSE, and the Direct Receive on Random Port flag is set to
      TRUE, the mapped address/port from which the direct bubble is
      received MUST be stored in the mapped address/port fields of the
      Peer Entry.  The Direct Receive on Primary Port flag MUST be set
      to TRUE.  The Teredo client MUST then set the Random Port field in
      the Peer Entry to zero and stop listening on the old random port.
      Finally, the Direct Receive on Random Port flag MUST be set to
      FALSE.








<span class="grey">Thaler                       Standards Track                   [Page 34]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-35" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


   o  If the direct bubble is received on the random port and the Teredo
      peer is not "trusted", the status field of the Teredo client MUST
      be changed to "trusted" and the Direct Receive on Random Port flag
      MUST be set to TRUE.  The mapped address/port from which the
      direct bubble was received MUST be recorded in the mapped address/
      port fields of the Teredo Peer Entry, as specified in <a href="./rfc4380#section-5.2">Section&nbsp;5.2
      of [RFC4380]</a>.

   o  If the direct bubble is received on the random port, the Teredo
      peer is "trusted", and the Direct Receive on Primary Port flag is
      FALSE, the Teredo client MUST compare the mapped address/port in
      the direct bubble with the mapped address/port in the Peer Entry.
      If the two mappings are the same, the direct bubble MUST be
      accepted.  If the mappings are different, it implies that the NAT
      had deleted the mapping and when it reassigned the mapping, a
      different external port was chosen.  In this instance, the Teredo
      client SHOULD set the Random Port field to zero, stop listening on
      the old random port, and send an indirect bubble to the Teredo
      peer as specified in <a href="#section-5.4.4.2">Section 5.4.4.2</a>.

   Note that once the Direct Receive on Primary Port flag is TRUE, the
   client will stop listening on the random port and hence a direct
   bubble cannot be received on the random port.  As a result, this case
   is intentionally omitted above.

<span class="h3"><a class="selflink" id="section-5.5" href="#section-5.5">5.5</a>.  Sequential Port-Symmetric NAT Extension</span>

   The Sequential Port-Symmetric NAT Extension is optional; an
   implementation SHOULD support it.  This extension has the Symmetric
   NAT Support Extension (<a href="#section-5.2">Section 5.2</a>) as a dependency.  Any node that
   implements this extension MUST also implement the Symmetric NAT
   Support Extension, as well as the Port-Preserving NAT Extension
   (<a href="#section-5.4">Section 5.4</a>).

<span class="h4"><a class="selflink" id="section-5.5.1" href="#section-5.5.1">5.5.1</a>.  Abstract Data Model</span>

   This section describes a conceptual model of possible data
   organization that an implementation maintains to participate in this
   protocol.  The described organization is provided to facilitate the
   explanation of how the protocol behaves.  This document does not
   mandate that implementations adhere to this model as long as their
   external behavior is consistent with that described in this document.

   The Sequential Port-Symmetric NAT Extension extends the abstract data
   model in <a href="#section-5.4.1">Section 5.4.1</a> by adding the following additional state.






<span class="grey">Thaler                       Standards Track                   [Page 35]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-36" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


   Peer Entry: The following fields need to be added on a per-peer
   basis:

   o  EchoTestNonce1: The value of the nonce sent as part of the
      authentication encapsulation, as specified in <a href="./rfc4380#section-5.1.1">Section&nbsp;5.1.1 of
      [RFC4380]</a>, in the router solicitation packet sent to the Teredo
      server address as part of the Echo Test.

   o  EchoTestNonce2: The value of the nonce sent as part of the
      authentication encapsulation in the router solicitation packet
      sent to the secondary Teredo server address as part of the Echo
      Test.

   o  EchoTestLowerPort: The value of the external port mapping
      extracted from the origin indication of the router advertisement
      received from the Teredo server address as part of the Echo Test.
      A value of 0 indicates that no such router advertisement has been
      received.

   o  EchoTestUpperPort: The value of the external port mapping
      extracted from the origin indication of the router advertisement
      received from the secondary Teredo server address as part of the
      Echo Test.  A value of 0 indicates that no such router
      advertisement has been received.

   o  EchoTestRetryCounter: The number of times an Echo Test has been
      attempted.

<span class="h4"><a class="selflink" id="section-5.5.2" href="#section-5.5.2">5.5.2</a>.  Timers</span>

   In addition to the timers specified in <a href="#section-5.4.2">Section 5.4.2</a>, the following
   additional timer is required per Peer Entry.

   Echo Test Failover Timer: A one-shot timer that runs whenever an Echo
   Test is in progress.

<span class="h5"><a class="selflink" id="section-5.5.2.1" href="#section-5.5.2.1">5.5.2.1</a>.  Peer Refresh Timer Expiry</span>

   The processing of the Peer Refresh Timer Expiry MUST be completed as
   specified in <a href="#section-5.4.2.1">Section 5.4.2.1</a>.  In addition to those rules, the Teredo
   client MUST set the EchoTestLowerPort, EchoTestUpperPort, and
   EchoTestRetryCounter to zero.

<span class="h5"><a class="selflink" id="section-5.5.2.2" href="#section-5.5.2.2">5.5.2.2</a>.  Echo Test Failover Timer Expiry</span>

   If the Echo Test Failover Timer expires, the Teredo client MUST do
   the following.




<span class="grey">Thaler                       Standards Track                   [Page 36]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-37" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


   If the value of the EchoTestRetryCounter is two, then the Teredo
   client MUST send an indirect bubble as specified in <a href="#section-5.2.4.1">Section 5.2.4.1</a>.

   If the value of the EchoTestRetryCounter is one, then the Teredo
   client MUST start another Echo Test as specified in
   <a href="#section-5.5.4.1.1">Section 5.5.4.1.1</a>.

<span class="h4"><a class="selflink" id="section-5.5.3" href="#section-5.5.3">5.5.3</a>.  Initialization</span>

   No behavior changes are required beyond what is specified in
   <a href="#section-5.4.3">Section 5.4.3</a>.

<span class="h4"><a class="selflink" id="section-5.5.4" href="#section-5.5.4">5.5.4</a>.  Message Processing</span>

   Except as specified in the following sections, the rules for message
   processing are as specified in <a href="#section-5.4.4">Section 5.4.4</a>.

<span class="h5"><a class="selflink" id="section-5.5.4.1" href="#section-5.5.4.1">5.5.4.1</a>.  Handling a Request to Send an Indirect Bubble</span>

   Whenever [<a href="./rfc4380" title="&quot;Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)&quot;">RFC4380</a>] or other extensions specified in this document
   specify that an indirect bubble is to be sent, the following actions
   apply at that time instead if the Symmetric NAT flag is TRUE and the
   Port-Preserving NAT flag is FALSE.  Note that any behavior specified
   by [<a href="./rfc4380" title="&quot;Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)&quot;">RFC4380</a>] or other extensions in this document still applies to
   how indirect bubbles are constructed, but such behavior is done at a
   later time as specified in <a href="#section-5.5.4.4">Section 5.5.4.4</a>.

   If the Symmetric NAT flag is TRUE, and the Port-Preserving NAT flag
   is FALSE, and the Teredo peer is not marked as "trusted" (as
   specified in <a href="./rfc4380#section-5.2">Section&nbsp;5.2 of [RFC4380]</a>), and the Random Port is zero,
   then the Teredo client MUST select a random port number to use, begin
   listening on that port, and start an Echo Test as specified below.

<span class="h6"><a class="selflink" id="section-5.5.4.1.1" href="#section-5.5.4.1.1">5.5.4.1.1</a>.  Starting an Echo Test</span>

   To start an Echo Test, the Teredo client MUST send the following
   three packets from this port:

   o  First, a router solicitation (as specified in <a href="./rfc4380#section-5.2.1">Section&nbsp;5.2.1 of
      [RFC4380]</a>) MUST be sent to the Teredo server address.  The router
      solicitation MUST include an authentication encapsulation with a
      randomly generated Nonce field, as specified in <a href="./rfc4380#section-5.1.1">Section&nbsp;5.1.1 of
      [RFC4380]</a>.  The nonce included in the authentication encapsulation
      MUST then be stored in the EchoTestNonce1 field of the Peer Entry.

   o  Second, a direct bubble MUST be sent to the peer.





<span class="grey">Thaler                       Standards Track                   [Page 37]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-38" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


   o  Third, a router solicitation MUST be sent to the secondary Teredo
      server address.  The router solicitation MUST include an
      authentication encapsulation with a randomly generated Nonce
      field, as specified in <a href="./rfc4380#section-5.1.1">Section&nbsp;5.1.1 of [RFC4380]</a>.  The nonce
      included in the authentication encapsulation MUST then be stored
      in the EchoTestNonce2 field of the Peer Entry.

   The Teredo client MUST then increment the EchoTestRetryCounter and
   set the Echo Test Failover Timer to expire in a number of seconds
   equal to EchoTestRetryCounter.

<span class="h5"><a class="selflink" id="section-5.5.4.2" href="#section-5.5.4.2">5.5.4.2</a>.  Sending an Indirect Bubble</span>

   The rules for sending an indirect bubble are as specified in
   <a href="#section-5.2.4.1">Section 5.2.4.1</a> of this document and <a href="./rfc4380#section-5.2.6">Section&nbsp;5.2.6 of [RFC4380]</a>.  In
   addition to those rules, if the Symmetric NAT flag is TRUE, and the
   Port-Preserving NAT flag is FALSE, and the Random Port value is non-
   zero, then the Teredo client MUST append a Random Port Trailer to the
   indirect bubble.

<span class="h5"><a class="selflink" id="section-5.5.4.3" href="#section-5.5.4.3">5.5.4.3</a>.  Receiving a Direct Bubble</span>

   The processing of the direct bubble MUST be completed as specified in
   <a href="#section-5.4.4.5">Section 5.4.4.5</a>, as if the Port-Preserving NAT flag were TRUE.  After
   the processing is complete, if the Direct Bubble Received on Primary
   flag is TRUE, and the Echo Test Failover Timer is running, then the
   Echo Test Failover Timer MUST be canceled and EchoTestLowerPort,
   EchoTestUpperPort, and EchoTestRetryCounter MUST be set to zero.

<span class="h5"><a class="selflink" id="section-5.5.4.4" href="#section-5.5.4.4">5.5.4.4</a>.  Receiving a Router Advertisement</span>

   The rules for processing a router advertisement are as specified in
   <a href="./rfc4380#section-5.2.1">Section&nbsp;5.2.1 of [RFC4380]</a>.  In addition to those rules, if the
   router advertisement contains an authentication encapsulation, the
   Teredo client MUST look for a Peer Entry whose EchoTestNonce1 or
   EchoTestNonce2 field matches the nonce in the authentication
   encapsulation.  If a Peer Entry is found, the Teredo client MUST do
   the following.

   If the received nonce is equal to EchoTestNonce1 and
   EchoTestLowerPort is zero, then EchoTestLowerPort MUST be set to the
   external port mapping extracted from the origin indication of this
   router advertisement.

   If the received nonce is equal to EchoTestNonce2 and
   EchoTestUpperPort is zero, then EchoTestUpperPort MUST be set to the
   external port mapping extracted from the origin indication of this
   router advertisement.



<span class="grey">Thaler                       Standards Track                   [Page 38]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-39" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


   If the EchoTestUpperPort and EchoTestLowerPort are now both non-zero,
   the Teredo client MUST then set the Random Port field of the Peer
   Entry to (EchoTestUpperPort + EchoTestUpperPort)/2, rounded down, and
   send an indirect bubble as specified in <a href="#section-5.5.4.2">Section 5.5.4.2</a>.

<span class="h3"><a class="selflink" id="section-5.6" href="#section-5.6">5.6</a>.  Hairpinning Extension</span>

   This extension is optional; an implementation SHOULD support it.

<span class="h4"><a class="selflink" id="section-5.6.1" href="#section-5.6.1">5.6.1</a>.  Abstract Data Model</span>

   This section describes a conceptual model of possible data
   organization that an implementation maintains to participate in this
   protocol.  The described organization is provided to facilitate the
   explanation of how the protocol behaves.  This document does not
   mandate that implementations adhere to this model as long as their
   external behavior is consistent with that described in this document.

   In addition to the state specified in <a href="./rfc4380#section-5.2">Section&nbsp;5.2 of [RFC4380]</a>, the
   following are also required:

   UPnP Mapped Address/Port: The mapped address/port assigned via UPnP
   to the Teredo client by the UPnP-enabled NAT behind which the Teredo
   client is positioned.  This field has a valid value only if the NAT
   to which the Teredo client is connected is UPnP enabled.  In
   addition, if the Teredo client is positioned behind a single NAT only
   (as opposed to a series of nested NATs), this value will be the same
   as the mapped address/port embedded in its Teredo IPv6 address.

   Peer Entry: Per-peer state is extended beyond what is described in
   [<a href="./rfc4380" title="&quot;Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)&quot;">RFC4380</a>] by including the following:

   o  Alternate Address/Port list: The list of alternate address/port
      pairs advertised by the peer.

<span class="h4"><a class="selflink" id="section-5.6.2" href="#section-5.6.2">5.6.2</a>.  Timers</span>

   No timers are necessary other than those in [<a href="./rfc4380" title="&quot;Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)&quot;">RFC4380</a>].

<span class="h4"><a class="selflink" id="section-5.6.3" href="#section-5.6.3">5.6.3</a>.  Initialization</span>

   Behavior is as specified in [<a href="./rfc4380" title="&quot;Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)&quot;">RFC4380</a>], with the following additions.

   Prior to beginning the qualification procedure, the Teredo client
   MUST invoke the AddPortMapping function (as specified in <a href="#section-2.4.16">Section</a>
   <a href="#section-2.4.16">2.4.16</a> of [<a href="#ref-UPNPWANIP" title="&quot;WANIPConnection:1&quot;">UPNPWANIP</a>]) with the parameters specified in
   <a href="#section-5.3.3">Section 5.3.3</a>.  If successful, it indicates that the NAT has created
   a port mapping from the external port of the NAT to the internal port



<span class="grey">Thaler                       Standards Track                   [Page 39]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-40" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


   of the Teredo client node.  If the AddPortMapping function is
   successful, the Teredo client MUST store the mapping assigned by the
   NAT in its UPnP Mapped Address/Port state.

   After the qualification procedure, the mapped address/port learned
   from the Teredo server MUST be compared to the UPnP Mapped Address/
   Port.  If both are the same, the Teredo client is positioned behind a
   single NAT and the UPnP Mapped Address/Port MUST be zeroed out.

<span class="h4"><a class="selflink" id="section-5.6.4" href="#section-5.6.4">5.6.4</a>.  Message Processing</span>

<span class="h5"><a class="selflink" id="section-5.6.4.1" href="#section-5.6.4.1">5.6.4.1</a>.  Sending an Indirect Bubble</span>

   The rules for when indirect bubbles are sent to a Teredo peer are as
   specified in <a href="./rfc4380#section-5.2.6">Section&nbsp;5.2.6 of [RFC4380]</a>.  If communication between a
   Teredo client and a Teredo peer has not been established, the Teredo
   client MUST include the Alternate Address Trailer in the indirect
   bubble.  The Alternate Address Trailer MUST include the node's local
   address/port in the Alternate Address/Port list.  If the UPnP Mapped
   Address/Port is non-zero, the Alternate Address Trailer MUST also
   include it in the list.

   Hairpinning requires "direct IPv6 connectivity tests" (as specified
   in <a href="./rfc4380#section-5.2.9">Section&nbsp;5.2.9 of [RFC4380]</a>) to succeed before it can accept
   packets from an IPv4 address and port not embedded in the Teredo IPv6
   address.  Hence, the indirect bubble MUST also include a Nonce
   Trailer.

<span class="h5"><a class="selflink" id="section-5.6.4.2" href="#section-5.6.4.2">5.6.4.2</a>.  Receiving an Indirect Bubble</span>

   The rules for processing indirect bubbles are as specified in <a href="./rfc4380#section-5.2.3">Section</a>
   <a href="./rfc4380#section-5.2.3">5.2.3 of [RFC4380]</a>.  In addition to those rules, when a Teredo client
   receives an indirect bubble with the Alternate Address Trailer, it
   SHOULD first verify that the Alternate Address Trailer is correctly
   formed (as specified in <a href="#section-4.3">Section 4.3</a>), and drop the bubble if not.
   Otherwise, it MUST set the Alternate Address/Port list in its Peer
   Entry to the list in the trailer.  The Teredo client, besides sending
   direct bubbles to the mapped address/port embedded in the Teredo IPv6
   address (as specified in <a href="./rfc4380#section-5.2.6">Section&nbsp;5.2.6 of [RFC4380]</a>), MUST also send
   a direct bubble to each mapped address/port advertised in the
   Alternate Address Trailer.

   In each of the direct bubbles, the Teredo client MUST include a Nonce
   Trailer with the nonce value received in the indirect bubble.







<span class="grey">Thaler                       Standards Track                   [Page 40]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-41" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


<span class="h5"><a class="selflink" id="section-5.6.4.3" href="#section-5.6.4.3">5.6.4.3</a>.  Receiving a Direct Bubble</span>

   If the mapped address/port of the direct bubble matches the mapped
   address/port embedded in the source Teredo IPv6 address, the direct
   bubble MUST be accepted, as specified in <a href="./rfc4380#section-5.2.3">Section&nbsp;5.2.3 of [RFC4380]</a>.

   If the mapped address/port does not match the embedded address/port,
   but the direct bubble contains a Nonce Trailer with a nonce that
   matches the Nonce Sent field of the Teredo peer, the direct bubble
   MUST be accepted.

   If neither of the above rules match, the direct bubble MUST be
   dropped.

<span class="h3"><a class="selflink" id="section-5.7" href="#section-5.7">5.7</a>.  Server Load Reduction Extension</span>

   This extension is optional; an implementation SHOULD support it.

<span class="h4"><a class="selflink" id="section-5.7.1" href="#section-5.7.1">5.7.1</a>.  Abstract Data Model</span>

   This section describes a conceptual model of possible data
   organization that an implementation maintains to participate in this
   protocol.  The described organization is provided to facilitate the
   explanation of how the protocol behaves.  This document does not
   mandate that implementations adhere to this model as long as their
   external behavior is consistent with that described in this document.

   In addition to the state specified in <a href="./rfc4380#section-5.2">Section&nbsp;5.2 of [RFC4380]</a>, the
   following are also required.

   Peer Entry: The following state needs to be added on a per-peer
   basis:

   o  Count of Solicitations Transmitted: The number of Solicitation
      packets sent.

<span class="h4"><a class="selflink" id="section-5.7.2" href="#section-5.7.2">5.7.2</a>.  Timers</span>

   Retransmission Timer: A timer used to retransmit Teredo Neighbor
   Solicitation packets.

   When the retransmission timer expires, the Teredo client MUST
   retransmit a direct bubble with a Neighbor Discovery Option Trailer,
   and increment the Count of Solicitations Transmitted.  If the count
   is less than three, it MUST then reset the timer to expire in two
   seconds.  Otherwise (if the count is now three), it MUST send an





<span class="grey">Thaler                       Standards Track                   [Page 41]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-42" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


   indirect bubble to the Teredo peer to re-establish connectivity as if
   no communication between the Teredo client and the Teredo peer had
   been established.

<span class="h4"><a class="selflink" id="section-5.7.3" href="#section-5.7.3">5.7.3</a>.  Initialization</span>

   No initialization is necessary other than that specified in
   [<a href="./rfc4380" title="&quot;Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)&quot;">RFC4380</a>].

<span class="h4"><a class="selflink" id="section-5.7.4" href="#section-5.7.4">5.7.4</a>.  Message Processing</span>

   Except as specified below, processing is the same as specified in
   [<a href="./rfc4380" title="&quot;Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)&quot;">RFC4380</a>].

<span class="h5"><a class="selflink" id="section-5.7.4.1" href="#section-5.7.4.1">5.7.4.1</a>.  Sending a Data Packet</span>

   Upon receiving a data packet to be transmitted to the Teredo peer,
   the Teredo client MUST determine whether data has been exchanged
   between the Teredo client and peer in either direction in the last 30
   seconds (using the state as specified in <a href="./rfc4380#section-5.2">Section&nbsp;5.2 of [RFC4380]</a>).
   If not, the Teredo client MUST send a direct bubble with a Neighbor
   Discovery Option Trailer having the DiscoveryType field set to
   TeredoDiscoverySolicitation.  The Count of Solicitations Transmitted
   field MUST be set to 1.  The retransmission timer MUST be set to
   expire in two seconds.

<span class="h5"><a class="selflink" id="section-5.7.4.2" href="#section-5.7.4.2">5.7.4.2</a>.  Receiving a Direct Bubble</span>

   The rules for processing direct bubbles are as specified in <a href="./rfc4380#section-5.2.3">Section</a>
   <a href="./rfc4380#section-5.2.3">5.2.3 of [RFC4380]</a>.  In addition to those rules, upon receiving a
   direct bubble containing a Neighbor Discovery Option Trailer with
   DiscoveryType field set to TeredoDiscoverySolicitation, the Teredo
   client MUST respond with a direct bubble with the Neighbor Discovery
   Option Trailer having the DiscoveryType field set to
   TeredoDiscoveryAdvertisement.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Protocol Examples</span>

   The following sections describe several operations as used in common
   scenarios to illustrate the function of Teredo Extensions.

<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>.  Symmetric NAT Support Extension</span>

   The following protocol example illustrates the use of the Symmetric
   NAT Support Extension.






<span class="grey">Thaler                       Standards Track                   [Page 42]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-43" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


   In Figure 2 (<a href="#section-3.1">Section 3.1</a>), assume that Teredo Client A, which is
   positioned behind a port-symmetric NAT, wants to communicate with
   Teredo Client B, which is positioned behind an address-restricted
   NAT.

   The qualification procedure where the Teredo client determines that
   it is positioned behind a symmetric NAT is exactly the same as that
   specified in <a href="./rfc4380#section-5.2.1">Section&nbsp;5.2.1 of [RFC4380]</a>.  Because of the Symmetric
   NAT Extension, Client A continues to configure a Teredo IPv6 address
   even after determining that the Teredo client is positioned behind a
   symmetric NAT.

   Next the following packet exchange helps Teredo Client A (A)
   establish communication with Teredo Client B (B).

   Teredo           Client A's              Client B's           Teredo
   Client             Teredo                  Teredo             Client
      A        NAT    Server                  Server      NAT       B
      |         |        |                       |         |        |
      |         |        |  Direct Bubble to B   |         |        |
    1 |---------------------------------------------------&gt;|        |
      |         |        |                       |         |        |
      |Indirect Bubble to B via B's Teredo Server|         |        |
    2 |-----------------------------------------&gt;|-----------------&gt;|
      |         |        |                       |         |        |
      |         |        |  Direct Bubble to A   |         |        |
      |         |&lt;--------------------------------------------------| 3
      |         |        |                       |         |        |
      |         |        |Indirect Bubble to A via A's Teredo Server|
      |&lt;-----------------|&lt;-----------------------------------------| 4
      |         |        |                       |         |        |
      |         |        |  Direct Bubble to B   |         |        |
    5 |------------------------------------------------------------&gt;|
      |         |        |                       |         |        |
      |Indirect Bubble to B via B's Teredo Server|         |        |
    6 |-----------------------------------------&gt;|-----------------&gt;|
      |         |        |                       |         |        |
      |         |        |  Direct Bubble to A   |         |        |
      |&lt;------------------------------------------------------------| 7
      |         |        |                       |         |        |

            Port-Symmetric NAT to Address-Restricted NAT Packet
                                 Exchange








<span class="grey">Thaler                       Standards Track                   [Page 43]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-44" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


   1.   A sends a direct bubble (Packet 1) destined to the mapped
        address/port embedded in B's Teredo IPv6 address.  The mapped
        port in the source field of the packet assigned by Client A's
        NAT is different from the mapped port embedded in A's Teredo
        IPv6 address.  This is characteristic of the port-symmetric NAT
        positioned in front of A.  The mapped address in the source
        field of the packet is the same as the mapped address embedded
        in the Teredo IPv6 address of A.

   2.   The aforementioned direct bubble is dropped by B's NAT because
        it has not seen an outgoing packet destined to A's mapped IPv4
        address.

   3.   A sends an indirect bubble (Packet 2) destined to B via Client
        B's Teredo server.

   4.   The above-mentioned indirect bubble is received by B.  B then
        responds with the following packets.  The first packet sent by B
        is a direct bubble (Packet 3) destined to the mapped address/
        port embedded in A's Teredo IPv6 address.

   5.   The above-mentioned direct bubble is dropped by A's NAT because
        the NAT has not seen any outgoing packet sourced from the mapped
        address/port embedded in A's Teredo IPv6 address and destined to
        the mapped address/port embedded in B's Teredo IPv6 address.

   6.   B also sends an indirect bubble (Packet 4) destined to A via A's
        Teredo Server.

   7.   The aforementioned indirect bubble is successfully received by
        A.  A responds to the indirect bubble with its own direct bubble
        (Packet 5).  This direct bubble is exactly the same as the first
        direct bubble (Packet 1) sent by A.

   8.   This time around the aforementioned direct bubble is accepted by
        B's NAT because the NAT has seen an outgoing packet (Packet 3)
        sourced from the mapped address/port embedded in B's Teredo IPv6
        address and destined to the mapped address/port embedded in A's
        Teredo IPv6 address.  It is important to remember that A's NAT
        is port-symmetric and therefore varies only the mapped port
        while the mapped address remains the same.  B's NAT is address-
        restricted and cares only about prior communication with the
        IPv4 address, not the specific port.  At this point,
        communication in one direction is now possible (B to A, but not
        vice versa).






<span class="grey">Thaler                       Standards Track                   [Page 44]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-45" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


   9.   After receiving the direct bubble, B remembers the new mapped
        address/port that was in the source fields of the direct bubble
        and uses those for future communication with A instead of the
        mapped address/port embedded in A's Teredo IPv6 address.

   10.  A then times out and resends an indirect bubble (Packet 6) and
        in response, B sends a direct bubble (Packet 7).  This direct
        bubble is destined to the new learned mapped address/port and
        hence A's NAT permits the direct bubble through.  Communication
        is now possible in the other direction (client A to B).

<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>.  UPnP-Enabled Symmetric NAT Extension</span>

   The following protocol example illustrates the use of the UPnP-
   Enabled Symmetric NAT Extension in addition to the Symmetric NAT
   Support Extension.

   Assume that Teredo Client A, which is positioned behind a UPnP-
   enabled port-symmetric NAT, wants to communicate with Teredo Client
   B, which is also positioned behind a UPnP-Enabled port-symmetric NAT.

   Before both clients start their qualification procedure, they use
   UPnP to reserve port mappings on their respective NATs.  The UPnP
   operations succeed for both the clients and the clients hence know
   that they are positioned behind UPnP-enabled NATs.  After the
   qualification procedure, both clients have valid Teredo IPv6
   addresses because they both support the Symmetric NAT Support
   Extension.  Also, after the qualification procedure both clients will
   compare their mapped address/port determined through UPnP with the
   mapped address/port determined through the qualification procedure.
   Because both will be the same, the clients will zero out their UPnP
   mapped address/port values and conclude that they are each located
   behind a single UPnP-enabled NAT.

   The following packet exchange shows Teredo client A (A) establishing
   communication with Teredo client B (B).















<span class="grey">Thaler                       Standards Track                   [Page 45]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-46" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


   Teredo           Client A's              Client B's           Teredo
   Client             Teredo                  Teredo             Client
      A        NAT    Server                  Server      NAT       B
      |         |        |                       |         |        |
      |         |        |  Direct Bubble to B   |         |        |
    1 |------------------------------------------------------------&gt;|
      |         |        |                       |         |        |
      |Indirect Bubble to B via B's Teredo Server|         |        |
    2 |-----------------------------------------&gt;|-----------------&gt;|
      |         |        |                       |         |        |
      |         |        |  Direct Bubble to A   |         |        |
      |&lt;------------------------------------------------------------| 3
      |         |        |                       |         |        |

                UPnP-enabled Symmetric NAT Packet Exchange

   1.  A sends a direct bubble (Packet 1) to the mapped address/port
       embedded in B's Teredo IPv6 address.  Because A's NAT is a
       symmetric NAT, the UDP source port field in the packet assigned
       by A's NAT is different from the mapped port embedded in A's
       Teredo IPv6 address, but the IPv4 source address of the packet is
       the same as the mapped address embedded in A's Teredo IPv6
       address.

   2.  The above-mentioned direct bubble is received by B because it is
       destined for the UPnP mapped address/port of B and hence is let
       through by the NAT.  At this point, B deduces that A is
       positioned behind a symmetric NAT because the mapped address/port
       from which the direct bubble is received is different from the
       mapped address/port that is embedded in A's Teredo IPv6 address.
       Hence, it remembers that the peer is positioned behind a
       symmetric NAT so that data packets will be sent to the mapped
       address/port embedded in A's Teredo IPv6 address, rather than the
       mapped address/port from which the direct bubble was received.
       At this point, communication in one direction is now possible (B
       to A, but not vice versa).

   3.  A also sends an indirect bubble (Packet 2) destined to B via B's
       Teredo Server.

   4.  The above indirect bubble is received by B.  B then responds with
       a direct bubble (Packet 3) destined to the mapped address/port
       embedded in A's Teredo IPv6 address, as in step 2.

   5.  Because A's NAT is also UPnP enabled, the above-mentioned direct
       bubble is received by A.  A also notices that B is positioned
       behind a Symmetric NAT because the mapped address/port from which
       the packet is received is different from the mapped address/port



<span class="grey">Thaler                       Standards Track                   [Page 46]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-47" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


       embedded in B's Teredo IPv6 address.  Hence, it remembers that
       the peer is positioned behind a symmetric NAT so that data
       packets will be sent to the mapped address/port embedded in B's
       Teredo IPv6 address, rather than the mapped address/port from
       which the direct bubble was received.  At this point,
       communication is now possible in the other direction (A to B).

<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>.  Port-Preserving Symmetric NAT Extension</span>

   The following protocol example illustrates the use of the Port-
   Preserving Symmetric NAT Extension.

   Assume that Teredo Client A (A), which is positioned behind a port-
   preserving symmetric NAT, wants to communicate with Teredo Client B
   (B), which is also positioned behind a port-preserving symmetric NAT.

   The following packet exchange explains the configuration setup and
   communication setup between the two clients.

































<span class="grey">Thaler                       Standards Track                   [Page 47]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-48" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


   Teredo           Client A's              Client B's           Teredo
   Client             Teredo                  Teredo             Client
      A        NAT    Server                  Server      NAT       B
      |         |        |                       |         |        |
      |         |        |  Direct Bubble to B   |         |        |
    1 |---------------------------------------------------&gt;|        |
      |         |        |                       |         |        |
      |Indirect Bubble to B via B's Teredo Server|         |        |
    2 |-----------------------------------------&gt;|-----------------&gt;|
      |         |        |                       |         |        |
      |         |        |  Direct Bubble to A   |         |        |
      |         |&lt;--------------------------------------------------| 3
      |         |        |                       |         |        |
      |         |        |  Direct Bubble to A   |         |        |
      |         |&lt;--------------------------------------------------| 4
      |         |        |                       |         |        |
      |         |        |Indirect Bubble to A via A's Teredo Server|
      |&lt;-----------------|&lt;-----------------------------------------| 5
      |         |        |                       |         |        |
      |         |        |  Direct Bubble to B   |         |        |
    6 |---------------------------------------------------&gt;|        |
      |         |        |                       |         |        |
      |         |        |  Direct Bubble to B   |         |        |
    7 |------------------------------------------------------------&gt;|
      |         |        |                       |         |        |
      |Indirect Bubble to B via B's Teredo Server|         |        |
    8 |-----------------------------------------&gt;|-----------------&gt;|
      |         |        |                       |         |        |
      |         |        |  Direct Bubble to A   |         |        |
      |&lt;------------------------------------------------------------| 9
      |         |        |                       |         |        |

               Port-Preserving Symmetric NAT Packet Exchange

   1.   During the qualification procedure, when the clients receive a
        response from the Teredo server, they compare the Port value in
        the Origin indication with the Local Port value.  If both values
        match, the clients set the Port-Preserving NAT flag to TRUE.

   2.   When the response is received from the secondary Teredo server,
        the mapped address/port value in the Origin indication is
        compared with the mapped address/port value learned from the
        response received from the primary server.  If the mappings are
        different, the Symmetric NAT flag is set to TRUE.

   3.   It is assumed that for both Clients A and B, the Port-Preserving
        NAT flag and the Symmetric NAT flag are set to TRUE at the end
        of the qualification procedure.



<span class="grey">Thaler                       Standards Track                   [Page 48]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-49" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


   4.   Before A sends packets to B, A checks to see if it is positioned
        behind a port-preserving NAT and a symmetric NAT, which in the
        example, it is.  A also checks to see if the peer is "trusted",
        but it currently is not.  Next, A checks if the Random Port is
        set to non-zero.  Since it is still zero, A allocates a new
        random port, begins listening on it, and stores the value in the
        Random Port field.

   5.   A sends a direct bubble (Packet 1) from the primary port to the
        mapped address/port embedded in B's Teredo IPv6 address.  This
        direct bubble does not have a Nonce Trailer or a Random Port
        Trailer attached to the end.

   6.   The aforementioned direct bubble is dropped by B's NAT because
        the NAT has not seen an outgoing packet destined to A's mapped
        address.

   7.   A sends an indirect bubble (Packet 2) destined to B via client
        B's Teredo server.  This indirect bubble contains two trailers:
        the Nonce Trailer containing a random nonce, and the Random Port
        Trailer containing the random port value from the Peer Entry.
        The nonce used in the Nonce Trailer is also stored in the Nonce
        Sent field of the Peer Entry.

   8.   The aforementioned indirect bubble is received by B.  B adds the
        Teredo peer to its peer list.  B saves the nonce value from the
        Nonce Trailer in the Nonce Advertised field of the Peer Entry.
        B stores the port value from the Random Port Trailer in the Peer
        Random Port field in the Peer Entry.

   9.   B responds by sending the following packets.  The first packet
        sent by B is a direct bubble (Packet 3) destined to the mapped
        address/port embedded in A's Teredo IPv6 address.  This packet
        is sent from the primary port.  It includes the Nonce Trailer
        with the nonce from the Nonce Advertised field of the Peer
        Entry.

   10.  The aforementioned direct bubble is dropped by A's NAT because
        the NAT has not seen any outgoing packet sourced from the mapped
        address/port embedded in A's Teredo IPv6 address and destined to
        the mapped address/port embedded in B's Teredo IPv6 address.

   11.  B then checks if it is positioned behind a port-restricted NAT
        or a symmetric NAT.  It also checks if the peer has already
        advertised a random port.  In this case, B is positioned behind
        a port-preserving symmetric NAT and the peer has advertised a
        random port; hence, it needs to use a random port.  It checks if
        its Random Port field is set to non-zero.  Since it is still



<span class="grey">Thaler                       Standards Track                   [Page 49]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-50" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


        zero, B allocates a new random port, begins listening on it, and
        stores it in the Random Port entry of the Peer Entry.  B then
        sends a direct bubble (Packet 4) destined to the mapped address
        embedded in A's Teredo IPv6 address and the port stored in the
        Peer Random Port field of the Peer Entry.  The direct bubble is
        sent from its own random port.

   12.  The above direct bubble is dropped by A's NAT because the NAT
        has not seen any outgoing packet sourced from the mapped address
        embedded in A's Teredo IPv6 address and random port advertised
        by A.

   13.  B also sends an indirect bubble (Packet 5) destined to A via A's
        Teredo Server.  This indirect bubble includes a Nonce Trailer
        and a Random Port Trailer.  The Nonce Trailer includes a new
        randomly generated nonce that is also stored in the Nonce Sent
        field of the Peer Entry.  The Random Port Trailer includes the
        value in the Random Port field of the Peer Entry.

   14.  The aforementioned indirect bubble is successfully received by
        A.  A parses the trailers and stores the nonce contained in the
        Nonce Trailer in the Nonce Received field of the Peer Entry.  A
        stores the port advertised in the Random Port Trailer in the
        Random Port field of the Peer Entry.

   15.  A responds with the following packets in response to the
        indirect bubble received.  The first packet is a direct bubble
        (Packet 6) sent from the primary port and is destined to the
        mapped address/port embedded in B's Teredo IPv6 address.

   16.  The aforementioned direct bubble again is dropped by B's NAT
        because the NAT has not seen an outgoing packet with the same
        4-tuple as the incoming packet.

   17.  The next packet is also a direct bubble (Packet 7) and this one
        is sent from A's random port.  The packet is destined to the
        mapped address embedded in B's Teredo IPv6 address and the Peer
        Random Port stored in the Peer Entry.

   18.  Because both NATs are port-preserving NATs and the random ports
        have not been used for any other mapping, the aforementioned
        direct bubble is received by B because B's NAT has seen an
        outgoing packet (Packet 4) with the same address/port pairs.  B
        stores the address/port from which the direct bubble was
        received in the mapped address/port fields of the Peer Entry.
        It changes the status of the peer to "trusted" and sets the





<span class="grey">Thaler                       Standards Track                   [Page 50]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-51" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


        Direct Receive on Random Port field to TRUE.  At this point,
        communication in one direction is now possible (B to A, but not
        vice versa).

   19.  Because A still considers B to be "not-trusted", it times out
        and retransmits an indirect bubble (Packet 8).  This packet
        contains a new nonce as part of the Nonce Trailer and also
        contains the value of the random port as part of the Random Port
        Trailer.

   20.  B receives the aforementioned indirect bubble.  The processing
        of this indirect bubble is similar to the processing of Packet
        2.  Since B received a direct bubble on its random port, it does
        not respond with a direct bubble from its primary port.
        Instead, it responds with a direct bubble (Packet 9) sent from
        its random port, which is similar to Packet 4 mentioned above.

   21.  A receives the direct bubble sent by B.  A stores the mapped
        address/port from which the direct bubble was received in mapped
        address/port fields in the Peer Entry.  A changes the status of
        B to "trusted" and sets the Direct Receive on Random Port field
        to TRUE.  At this point, the communication is now possible in
        the other direction (A to B).

<span class="h3"><a class="selflink" id="section-6.4" href="#section-6.4">6.4</a>.  Sequential Port-Symmetric NAT Extension</span>

   The following protocol example illustrates the use of the Sequential
   Port-Symmetric NAT Extension.

   Assume that Teredo Client A (A), which is positioned behind a
   sequential port-symmetric NAT and implements the Sequential Port-
   Symmetric NAT Extension, wants to communicate with Teredo Client B
   (B), which is positioned behind a port-restricted NAT that supports
   the Port-Preserving Port-Symmetric NAT Extension.  The following
   packet exchange explains the configuration setup and communication
   setup between the two clients.















<span class="grey">Thaler                       Standards Track                   [Page 51]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-52" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


   Teredo                 A's      A's            B's
   Client               Primary  Secondary      Teredo          Client
      A        NAT      Server    Server        Server   NAT       B
      |         |          |        |              |      |        |
      | Direct Bubble to B |        |              |      |        |
    1 |--------------------------------------------------&gt;|        |
      |         |          |        |              |      |        |
      |Router Solicitation |        |              |      |        |
    2 |-------------------&gt;|        |              |      |        |
      |         |          |        |              |      |        |
      |Router Advertisement|        |              |      |        |
      |&lt;-------------------| 3      |              |      |        |
      |         |          |        |              |      |        |
    4 | Direct Bubble to B |        |              |      |        |
      |--------------------------------------------------&gt;|        |
      |         |          |        |              |      |        |
      |  Router Solicitation        |              |      |        |
    5 |----------------------------&gt;|              |      |        |
      |         |          |        |              |      |        |
      |  Router Advertisement       |              |      |        |
      |&lt;----------------------------| 6            |      |        |
      |         |          |        |              |      |        |
      | Indirect Bubble to B via B's Teredo Server |      |        |
    7 |-------------------------------------------&gt;|--------------&gt;|
      |         |          |        |              |      |        |
      |         |          |        |         Direct Bubble to A   |
      |         |&lt;-------------------------------------------------| 8
      |         |          |        |              |      |        |
      |         |          |        |       Indirect Bubble to A   |
      |&lt;-------------------|&lt;--------------------------------------| 9
      |         |          |        |              |      |        |
      |         |          |        |         Direct Bubble to A   |
      |&lt;-----------------------------------------------------------| 10
      |         |          |        |              |      |        |
      |   Direct Bubble to B        |              |      |        |
   11 |-----------------------------------------------------------&gt;|

               Sequential Port-Symmetric NAT Packet Exchange

   1.  During the qualification procedure, when Client A receives a
       response from the Teredo Server, it compares the Port value in
       the Origin indication with the Local Port value.  Since they are
       different, it concludes that it is not behind a port-preserving
       NAT, and so assumes it is behind a sequential port-symmetric NAT.

   2.  When A wants to communicate with B, A starts by sending a direct
       bubble (Packet 1) from its primary port.  This occurs because
       Client A does not know Client B's NAT type, which could be a cone



<span class="grey">Thaler                       Standards Track                   [Page 52]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-53" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


       or address restricted NAT or UPnP-enabled NAT.  Because Client A
       is behind a symmetric NAT, the external port used by A's NAT is a
       new port.  This direct bubble will be dropped by B's NAT since
       Client B is behind a port-restricted NAT.

   3.  Because Client A does not know if B is behind a port restricted
       NAT or some other kind of NAT, Client A proactively opens a new
       random internal port, say, port 1100.

   4.  Client A then performs its Echo Test as follows:

       A.  Client A sends a router solicitation (Packet 2) to its Teredo
           Server address from port 1100.  The server responds with a
           router advertisement (Packet 3).

       B.  Client A sends a direct bubble (Packet 4) to the peer from
           port 1100 destined to the port advertised in Client B's
           Teredo address, say, port 2100.  This direct bubble is
           dropped by Client B's port-restricted NAT.

       C.  Client A sends a router solicitation (Packet 5) to its
           secondary Teredo server address from port 1100.  The server
           responds with a router advertisement (Packet 6).

       D.  On receiving the corresponding router advertisements for
           Packet 2 and Packet 4, Client A knows that port 1100 maps to,
           say, port 1200 for Packet 2 and port 1202 for Packet 4.

       E.  Client A then calculates its predicted port used for Packet 2
           as the average (rounded down) of 1200 and 1202, i.e., 1201.

   5.  Client A then sends out an indirect bubble (Packet 7).  This
       indirect bubble contains a random port trailer that contains the
       predicted port, port 1201.  This indirect bubble makes it to
       Client B.

   6.  Client B sends out the following bubbles in response to the
       indirect bubble:

       A.  The first direct bubble (Packet 8) is destined for the port
           mapping embedded in Client A's Teredo Address.  (It has been
           observed that some NATs display symmetric NAT behavior for
           outgoing packets but cone NAT behavior for incoming packets.
           The direct bubble described is likely to succeed if Client
           A's NAT displays such a behavior.)  Since in this example,
           A's NAT is a normal sequential port-symmetric NAT, this
           packet is dropped.




<span class="grey">Thaler                       Standards Track                   [Page 53]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-54" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


       B.  The second packet is an indirect bubble (Packet 9) sent to
           Client A without any trailers since Client B is behind a
           port-restricted NAT.

       C.  The next packet will be a direct bubble (Packet 10) sent to
           port 1201.  This packet will make it in to Client A since
           Client A previously sent an outgoing packet (Packet 4) with
           the same four tuple.  At this point, communication in one
           direction is now possible (A to B, but not vice versa).

   7.  Client A then sends a direct bubble (Packet 11) to Client B when
       it receives Packet 10.  This time, the bubble makes it through to
       B because it previously sent an outgoing packet (Packet 10) with
       the same four tuple.  At this point, communication is now
       possible in the other direction (B to A).

<span class="h3"><a class="selflink" id="section-6.5" href="#section-6.5">6.5</a>.  Hairpinning Extension</span>

   The following protocol example illustrates the use of the Hairpinning
   Extension.

   In Figure 3 (<a href="#section-3.5">Section 3.5</a>), Teredo Client A (A) and Teredo Client B
   (B) are positioned behind different immediate NATs in a two-layer NAT
   topology; that is, the outermost NAT (NAT E) is common to both A and
   B but the immediate NATs that they are connected to are different (A
   is connected to NAT F while B is connected to NAT G).  Further assume
   that the immediate NATs that A and B are connected to are UPnP-
   enabled (NAT F and NAT G are UPnP-enabled).  We assume that NAT E
   does not support hairpinning; that is, the NAT does not relay packets
   originating from the private address space and destined for the
   public address of the NAT, back to the private address of the NAT.

   Before starting the qualification procedure, both A and B use UPnP to
   reserve port mappings on their respective NATs.  They observe that
   the UPnP operation succeeds and both clients obtain valid UPnP Mapped
   Address/Port values.

   Next, both client A and client B implement the qualification
   procedure where they determine their mapped address/port values, as
   specified in <a href="./rfc4380#section-5.2.1">Section&nbsp;5.2.1 of [RFC4380]</a>.

   A and B both compare their UPnP Mapped Address/Port values with the
   mapped address/port values obtained through the qualification
   procedure.  Because both A and B are part of a two-layer NAT
   topology, these values will be different.  Hence, both A and B
   continue to hold on to their UPnP Mapped Address/Port.





<span class="grey">Thaler                       Standards Track                   [Page 54]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-55" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


   The following packet exchange shows client A establishing
   communication with client B.

   Teredo             Teredo                      Client A's  Client B's
   Client     NAT     Client        NAT      NAT    Teredo      Teredo
      A        F         B           G        E     Server      Server
      |        |         |           |        |        |           |
      |        | Direct Bubble to B  |        |        |           |
    1 |--------------------------------------&gt;|        |           |
      |        |         |           |        |        |           |
      |       Indirect Bubble to B via B's Teredo Server           |
    2 |-----------------------------------------------------------&gt;|
      |        |         |&lt;----------------------------------------|
      |        |         |           |        |        |           |
      |        |         | Direct Bubble to A |        |           |
    3 |        |         |-------------------&gt;|        |           |
      |        |         |           |        |        |           |
      |        |         |  Direct   |        |        |           |
      |        |         |Bubble to A|        |        |           |
    4 |        |         |----------&gt;|        |        |           |
      |        |         |           |        |        |           |
      |        |         |  Direct   |        |        |           |
      |        |         |Bubble to A|        |        |           |
    5 |        |         |----------&gt;|        |        |           |
      |&lt;-----------------------------|        |        |           |
      |        |         |           |        |        |           |
      |        |         |    Indirect Bubble to A     |           |
    6 |        |         |----------------------------&gt;|           |
      |&lt;-----------------------------------------------|           |
      |        |         |           |        |        |           |
      |Direct Bubble to B|           |        |        |           |
    7 |-----------------&gt;|           |        |        |           |
      |        |         |           |        |        |           |

                     Hairpinning-Based Packet Exchange

   1.   A sends a direct bubble (Packet 1) to the mapped address/port
        embedded in B's Teredo IPv6 address.

   2.   The aforementioned direct bubble is dropped by NAT E, because it
        does not support Hairpinning.

   3.   A sends out an indirect bubble (Packet 2) destined to B via B's
        Teredo Server.  In this indirect bubble, A includes an Alternate
        Address Trailer that includes both the local address/port and
        the UPnP mapped address/port.





<span class="grey">Thaler                       Standards Track                   [Page 55]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-56" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


   4.   The aforementioned indirect bubble is received by B.  After
        parsing the Alternate Address Trailer, B has a total of three
        addresses to communicate with: two from the Alternate Address
        Trailer and one from the mapped address/port embedded in A's
        Teredo IPv6 address.  B then responds with the following
        packets.  The first packet sent by B is a direct bubble (Packet
        3) destined to the mapped address/port embedded in A's Teredo
        IPv6 address.

   5.   The aforementioned direct bubble will be dropped by the NAT E
        because it does not support Hairpinning.

   6.   Because the local address/port was the first mapping in the
        Alternate Address Trailer, the second direct bubble (Packet 4)
        sent by B is destined to the local address/port.

   7.   The aforementioned direct bubble is dropped because A and B are
        positioned behind different NATs and hence have their own
        private address space.  A's local address is not reachable from
        B.

   8.   The next direct bubble (Packet 5) is sent by B destined to A's
        UPnP mapped address/port, which is the second mapping in the
        Alternate Address Trailer sent by A.

   9.   The aforementioned direct bubble is received by A because A's
        UPnP-mapped address is reachable from B.  A stores the source
        address from which the direct bubble was received in the mapped
        address/port fields of the Peer Entry, as defined in <a href="./rfc4380#section-5.2">Section&nbsp;5.2
        of [RFC4380]</a>.  Also, the mapped address status field (as
        specified in <a href="./rfc4380#section-5.2.3">Section&nbsp;5.2.3 of [RFC4380]</a>) is changed to
        "trusted".  At this point, communication in one direction (A to
        B) is now possible, but not vice versa because B has not yet
        marked A as trusted.

   10.  B also sends an indirect bubble (Packet 6) to A via A's Teredo
        server.  As part of the indirect bubble, B also includes an
        Alternate Address Trailer, which contains the local address/port
        and the UPnP mapped address/port of B.

   11.  The aforementioned indirect bubble is received by A.  After
        parsing the Alternate Address Trailer, A adds the two addresses
        in the Alternate Address Trailer to the Alternate Address List
        in the Peer Entry.  Because the peer's mapping is "trusted"
        (point 9), A responds with only one direct bubble (Packet 7)
        that is sent to the mapped address/port stored in the Peer
        Entry.




<span class="grey">Thaler                       Standards Track                   [Page 56]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-57" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


   12.  The aforementioned direct bubble is received by B.  B records
        the mapped address/port from which the direct bubble was
        received in the mapped address/port field in its Peer Entry, and
        changes the status of the mapped address to "trusted".  At this
        point, communication is now possible in the other direction (B
        to A).

<span class="h3"><a class="selflink" id="section-6.6" href="#section-6.6">6.6</a>.  Server Load Reduction Extension</span>

   The following protocol example illustrates the use of the Server Load
   Reduction Extension.

   Assume that Teredo Client A (A) has established communication with
   Teredo Client B (B).  Also, assume that at some later point when no
   data packets have been exchanged between both clients for more than
   30 seconds, the communication needs to be re-established because A
   wants to send a data packet to B.

   The following packet exchange helps A re-establish communication with
   B.

   Teredo           Client A's              Client B's           Teredo
   Client             Teredo                  Teredo             Client
      A        NAT    Server                  Server      NAT       B
      |         |        |                       |         |        |
      |         |        |  Direct Bubble to B   |         |        |
    1 |------------------------------------------------------------&gt;|
      |         |        |                       |         |        |
      |         |        |  Direct Bubble to A   |         |        |
      |&lt;------------------------------------------------------------| 2
      |         |        |                       |         |        |

                   Server Load Reduction Packet Exchange

   1.  A sends a direct bubble (Packet 1) with the Neighbor Discovery
       Option Trailer, with the DiscoveryType field set to
       TeredoDiscoverySolicitation.

   2.  If the mapping on either of the NATs has not expired, the direct
       bubble is received by B.  B parses the Neighbor Discovery Option
       and because the DiscoveryType was set to
       TeredoDiscoverySolicitation, B responds with a direct bubble
       (Packet 2).  B's direct bubble also contains the Neighbor
       Discovery Option and the DiscoveryType is set to
       TeredoDiscoveryAdvertisement.






<span class="grey">Thaler                       Standards Track                   [Page 57]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-58" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


   3.  The aforementioned direct bubble is received by A and at this
       point, communication between the Teredo clients is re-
       established.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Security Considerations</span>

   Security considerations are the same as those specified in <a href="./rfc4380#section-7">Section&nbsp;7
   of [RFC4380]</a>.

   In addition, the Hairpinning Extension introduces the possibility of
   an amplification attack if a malicious user could advertise a large
   number of port mappings in the Alternate Address Trailer, resulting
   in a large number of direct bubbles sent in response.  Because of
   this, <a href="#section-4.3">Section 4.3</a> explicitly limits the number of addresses that a
   Teredo client will accept.

   Because the nonce in the Nonce Trailer is used (as specified in
   <a href="#section-5.2.4.4">Section 5.2.4.4</a>) to prevent spoofing of bubbles that would result in
   directing traffic to the wrong place, it is important that the nonce
   be random so that attackers cannot predict its value.  See [<a href="./rfc4086" title="&quot;Randomness Requirements for Security&quot;">RFC4086</a>]
   for further discussion of randomness requirements.

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Acknowledgements</span>

   Thanks to Gurpreet Virdi and Poorna Gaddehosur for technical
   contributions to this document, and to the V6OPS WG and Jari Arkko
   for their helpful reviews.

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  IANA Considerations</span>

   IANA has created a new trailer Type registry.  Requests for new
   trailer Type values are made through Specification Required
   [<a href="./rfc5226" title="">RFC5226</a>].  Initial values are listed below.

   Trailer Type  Usage                              Reference
   ------------  ---------------------------------  ---------
      0x01       Nonce Trailer                      <a href="./rfc6081">RFC 6081</a>
      0x02       Random Port Trailer                <a href="./rfc6081">RFC 6081</a>
      0x03       Alternate Address Trailer          <a href="./rfc6081">RFC 6081</a>
      0x04       Neighbor Discovery Option Trailer  <a href="./rfc6081">RFC 6081</a>

<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>.  References</span>

<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>.  Normative References</span>

   [<a id="ref-RFC1918">RFC1918</a>]    Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G.,
                and E. Lear, "Address Allocation for Private Internets",
                <a href="https://www.rfc-editor.org/bcp/bcp5">BCP 5</a>, <a href="./rfc1918">RFC 1918</a>, February 1996.



<span class="grey">Thaler                       Standards Track                   [Page 58]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-59" ></span>
<span class="grey"><a href="./rfc6081">RFC 6081</a>                    Teredo Extensions               January 2011</span>


   [<a id="ref-RFC2119">RFC2119</a>]    Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.

   [<a id="ref-RFC2460">RFC2460</a>]    Deering, S. and R. Hinden, "Internet Protocol, Version 6
                (IPv6) Specification", <a href="./rfc2460">RFC 2460</a>, December 1998.

   [<a id="ref-RFC4380">RFC4380</a>]    Huitema, C., "Teredo: Tunneling IPv6 over UDP through
                Network Address Translations (NATs)", <a href="./rfc4380">RFC 4380</a>,
                February 2006.

   [<a id="ref-RFC4861">RFC4861</a>]    Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
                "Neighbor Discovery for IP version 6 (IPv6)", <a href="./rfc4861">RFC 4861</a>,
                September 2007.

   [<a id="ref-RFC5226">RFC5226</a>]    Narten, T. and H. Alvestrand, "Guidelines for Writing an
                IANA Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc5226">RFC 5226</a>,
                May 2008.

   [<a id="ref-UPNPWANIP">UPNPWANIP</a>]  UPnP Forum, "WANIPConnection:1", November 2001,
                &lt;<a href="http://www.upnp.org/standardizeddcps/documents/UPnP_IGD_WANIPConnection%201.0.pdf">http://www.upnp.org/standardizeddcps/documents/</a>
                <a href="http://www.upnp.org/standardizeddcps/documents/UPnP_IGD_WANIPConnection%201.0.pdf">UPnP_IGD_WANIPConnection%201.0.pdf</a>&gt;.

<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>.  Informative References</span>

   [<a id="ref-RFC4086">RFC4086</a>]    Eastlake, D., Schiller, J., and S. Crocker, "Randomness
                Requirements for Security", <a href="https://www.rfc-editor.org/bcp/bcp106">BCP 106</a>, <a href="./rfc4086">RFC 4086</a>,
                June 2005.

   [<a id="ref-RFC4443">RFC4443</a>]    Conta, A., Deering, S., and M. Gupta, "Internet Control
                Message Protocol (ICMPv6) for the Internet Protocol
                Version 6 (IPv6) Specification", <a href="./rfc4443">RFC 4443</a>, March 2006.

   [<a id="ref-RFC4787">RFC4787</a>]    Audet, F. and C. Jennings, "Network Address Translation
                (NAT) Behavioral Requirements for Unicast UDP", <a href="https://www.rfc-editor.org/bcp/bcp127">BCP 127</a>,
                <a href="./rfc4787">RFC 4787</a>, January 2007.

Author's Address

   Dave Thaler
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052
   USA

   Phone: +1 425 703 8835
   EMail: dthaler@microsoft.com





Thaler                       Standards Track                   [Page 59]
</pre>