doc: Add RFC documents

1 files changed, 3307 insertions, 0 deletions

diff --git a/doc/rfc/rfc6081.txt b/doc/rfc/rfc6081.txt
new file mode 100644
index 0000000..d17c6ab
--- /dev/null
+++ b/doc/rfc/rfc6081.txt
@@ -0,0 +1,3307 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         D. Thaler
+Request for Comments: 6081                                     Microsoft
+Updates: 4380                                               January 2011
+Category: Standards Track
+ISSN: 2070-1721
+
+
+                           Teredo Extensions
+
+Abstract
+
+   This document specifies a set of extensions to the Teredo protocol.
+   These extensions provide additional capabilities to Teredo, including
+   support for more types of Network Address Translations (NATs) and
+   support for more efficient communication.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6081.
+
+Copyright Notice
+
+   Copyright (c) 2011 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+Thaler                       Standards Track                    [Page 1]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
+     3.1.  Symmetric NAT Support Extension  . . . . . . . . . . . . .  9
+     3.2.  UPnP-Enabled Symmetric NAT Extension . . . . . . . . . . . 11
+     3.3.  Port-Preserving Symmetric NAT Extension  . . . . . . . . . 13
+     3.4.  Sequential Port-Symmetric NAT Extension  . . . . . . . . . 14
+     3.5.  Hairpinning Extension  . . . . . . . . . . . . . . . . . . 15
+     3.6.  Server Load Reduction Extension  . . . . . . . . . . . . . 17
+   4.  Message Syntax . . . . . . . . . . . . . . . . . . . . . . . . 18
+     4.1.  Trailers . . . . . . . . . . . . . . . . . . . . . . . . . 18
+     4.2.  Nonce Trailer  . . . . . . . . . . . . . . . . . . . . . . 19
+     4.3.  Alternate Address Trailer  . . . . . . . . . . . . . . . . 19
+     4.4.  Neighbor Discovery Option Trailer  . . . . . . . . . . . . 20
+     4.5.  Random Port Trailer  . . . . . . . . . . . . . . . . . . . 21
+   5.  Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 22
+     5.1.  Common Processing  . . . . . . . . . . . . . . . . . . . . 22
+       5.1.1.  Refresh Interval . . . . . . . . . . . . . . . . . . . 22
+       5.1.2.  Trailer Processing . . . . . . . . . . . . . . . . . . 23
+     5.2.  Symmetric NAT Support Extension  . . . . . . . . . . . . . 23
+       5.2.1.  Abstract Data Model  . . . . . . . . . . . . . . . . . 24
+       5.2.2.  Timers . . . . . . . . . . . . . . . . . . . . . . . . 24
+       5.2.3.  Initialization . . . . . . . . . . . . . . . . . . . . 24
+       5.2.4.  Message Processing . . . . . . . . . . . . . . . . . . 24
+     5.3.  UPnP-Enabled Symmetric NAT Extension . . . . . . . . . . . 25
+       5.3.1.  Abstract Data Model  . . . . . . . . . . . . . . . . . 26
+       5.3.2.  Timers . . . . . . . . . . . . . . . . . . . . . . . . 26
+       5.3.3.  Initialization . . . . . . . . . . . . . . . . . . . . 27
+       5.3.4.  Message Processing . . . . . . . . . . . . . . . . . . 28
+       5.3.5.  Shutdown . . . . . . . . . . . . . . . . . . . . . . . 29
+     5.4.  Port-Preserving Symmetric NAT Extension  . . . . . . . . . 30
+       5.4.1.  Abstract Data Model  . . . . . . . . . . . . . . . . . 30
+       5.4.2.  Timers . . . . . . . . . . . . . . . . . . . . . . . . 31
+       5.4.3.  Initialization . . . . . . . . . . . . . . . . . . . . 32
+       5.4.4.  Message Processing . . . . . . . . . . . . . . . . . . 32
+     5.5.  Sequential Port-Symmetric NAT Extension  . . . . . . . . . 35
+       5.5.1.  Abstract Data Model  . . . . . . . . . . . . . . . . . 35
+       5.5.2.  Timers . . . . . . . . . . . . . . . . . . . . . . . . 36
+       5.5.3.  Initialization . . . . . . . . . . . . . . . . . . . . 37
+       5.5.4.  Message Processing . . . . . . . . . . . . . . . . . . 37
+     5.6.  Hairpinning Extension  . . . . . . . . . . . . . . . . . . 39
+       5.6.1.  Abstract Data Model  . . . . . . . . . . . . . . . . . 39
+       5.6.2.  Timers . . . . . . . . . . . . . . . . . . . . . . . . 39
+       5.6.3.  Initialization . . . . . . . . . . . . . . . . . . . . 39
+       5.6.4.  Message Processing . . . . . . . . . . . . . . . . . . 40
+
+
+
+
+Thaler                       Standards Track                    [Page 2]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+     5.7.  Server Load Reduction Extension  . . . . . . . . . . . . . 41
+       5.7.1.  Abstract Data Model  . . . . . . . . . . . . . . . . . 41
+       5.7.2.  Timers . . . . . . . . . . . . . . . . . . . . . . . . 41
+       5.7.3.  Initialization . . . . . . . . . . . . . . . . . . . . 42
+       5.7.4.  Message Processing . . . . . . . . . . . . . . . . . . 42
+   6.  Protocol Examples  . . . . . . . . . . . . . . . . . . . . . . 42
+     6.1.  Symmetric NAT Support Extension  . . . . . . . . . . . . . 42
+     6.2.  UPnP-Enabled Symmetric NAT Extension . . . . . . . . . . . 45
+     6.3.  Port-Preserving Symmetric NAT Extension  . . . . . . . . . 47
+     6.4.  Sequential Port-Symmetric NAT Extension  . . . . . . . . . 51
+     6.5.  Hairpinning Extension  . . . . . . . . . . . . . . . . . . 54
+     6.6.  Server Load Reduction Extension  . . . . . . . . . . . . . 57
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 58
+   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 58
+   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 58
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58
+     10.1. Normative References . . . . . . . . . . . . . . . . . . . 58
+     10.2. Informative References . . . . . . . . . . . . . . . . . . 59
+
+1.  Introduction
+
+   This document specifies extensions to the Teredo protocol, as
+   specified in [RFC4380].  These extensions provide additional
+   capabilities to Teredo, including support for more types of Network
+   Address Translations (NATs) and support for more efficient
+   communication.
+
+2.  Terminology
+
+   Because this document extends [RFC4380], it uses the following
+   terminology, for consistency with [RFC4380].
+
+   Address-Restricted NAT: A restricted NAT that accepts packets from an
+   external host's IP address X and port Y if the internal host has sent
+   a packet that is destined to IP address X regardless of the
+   destination port.  In the terminology of [RFC4787], this is a NAT
+   with Endpoint-Independent Mapping and Address-Dependent Filtering.
+
+   Address-Symmetric NAT: A symmetric NAT that has multiple external IP
+   addresses and that assigns different IP addresses and ports when
+   communicating with different external hosts.
+
+   Cone NAT: A NAT that maps all requests from the same internal IP
+   address and port to the same external IP address and port.
+   Furthermore, any external host can send a packet to the internal host
+   by sending a packet to the mapped external address and port.  In the
+   terminology of [RFC4787], this is a NAT with Endpoint-Independent
+   Mapping and Endpoint-Independent Filtering.
+
+
+
+Thaler                       Standards Track                    [Page 3]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+   Direct Bubble: A Teredo bubble that is sent directly to the IPv4 node
+   whose Teredo address is contained in the Destination field of the
+   IPv6 header, as specified in Section 2.8 of [RFC4380].  The IPv4
+   Destination Address and UDP Destination Port fields contain a mapped
+   address/port.
+
+   Echo Test: A mechanism to predict the mapped address/port a
+   sequential port-symmetric NAT is using for a client behind it.
+
+   Hairpinning: A feature that is available in some NATs where two or
+   more hosts are positioned behind a NAT and each of those hosts is
+   assigned a specific external (public) address and port by the NAT.
+   Hairpinning support in a NAT allows these hosts to send a packet to
+   the external address and port that is assigned to one of the other
+   hosts, and the NAT automatically routes the packet back to the
+   correct host.  The term hairpinning is derived from the behavior of
+   the packet, which arrives on, and is sent out to, the same NAT
+   interface.
+
+   Indirect Bubble: A Teredo bubble that is sent indirectly (via the
+   destination's Teredo server) to another Teredo client, as specified
+   in Section 5.2.4 of [RFC4380].
+
+   Local Address/Port: The IPv4 address and UDP port from which a Teredo
+   client sends Teredo packets.  The local port is referred to as the
+   Teredo service port in [RFC4380].  The local address of a node may or
+   may not be globally routable because the node can be located behind
+   one or more NATs.
+
+   Mapped Address/Port: A global IPv4 address and a UDP port that
+   results from the translation of a node's own local address/port by
+   one or more NATs.  The node learns these values through the Teredo
+   protocol as specified in [RFC4380].  For symmetric NATs, the mapped
+   address/port can be different for every peer with which a node tries
+   to communicate.
+
+   Network Address Translation (NAT): The process of converting between
+   IP addresses used within an intranet or other private network and
+   Internet IP addresses.
+
+   Nonce: A time-variant random value used in the connection setup phase
+   to prevent message replay and other types of attacks.
+
+   Peer: A Teredo client with which another Teredo client needs to
+   communicate.
+
+
+
+
+
+
+Thaler                       Standards Track                    [Page 4]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+   Port-Preserving NAT: A NAT that translates a local address/port to a
+   mapped address/port such that the mapped port has the same value as
+   the local port, as long as that same mapped address/port has not
+   already been used for a different local address/port.
+
+   Port-Restricted NAT: A restricted NAT that accepts packets from an
+   external host's IP address X and port Y only if the internal host has
+   sent a packet destined to IP address X and port Y.  In the
+   terminology of [RFC4787], this is a NAT with Endpoint-Independent
+   Mapping and Address and Port-Dependent Filtering.
+
+   Port-Symmetric NAT: A symmetric NAT that has only a single external
+   IP address and hence only assigns different ports when communicating
+   with different external hosts.
+
+   Private Address: An IPv4 address that is not globally routable but is
+   part of the private address space specified in Section 3 of
+   [RFC1918].
+
+   Public Address: An external global address used by a NAT.
+
+   Restricted NAT: A NAT where all requests from the same internal IP
+   address and port are mapped to the same external IP address and port.
+   Unlike the cone NAT, an external host can send packets to an internal
+   host (by sending a packet to the external mapped address and port)
+   only if the internal host has first sent a packet to the external
+   host.  There are two kinds of restricted NATs: address-restricted
+   NATs and port-restricted NATs.
+
+   Sequential Port-Symmetric NAT: A port-symmetric NAT that allocates
+   external ports sequentially for every {internal IP address and port,
+   destination IP address and port} tuple.  The delta used in the
+   sequential assignment is typically 1 or 2 for most such NATs.
+
+   Symmetric NAT: A NAT where all requests from the same internal IP
+   address and port and to the same destination IP address and port are
+   mapped to the same external IP address and port.  Requests from the
+   same internal IP address and port to a different destination IP
+   address and port may be mapped to a different external IP address and
+   port.  Furthermore, a symmetric NAT accepts packets received from an
+   external host's IP address X and port Y only if some internal host
+   has sent packets to IP address X and port Y.  In the terminology of
+   [RFC4787], this is a NAT with a mapping behavior of either Address-
+   Dependent Mapping or Address- and Port-Dependent Mapping, and a
+   filtering behavior of either Address-Dependent Filtering or Address-
+   and Port-Dependent Filtering.
+
+
+
+
+
+Thaler                       Standards Track                    [Page 5]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+   Teredo Bubble: A Teredo control message (specified in Section 2.8 of
+   [RFC4380]) that is used to create a mapping in a NAT.  There are two
+   types of Teredo bubbles: direct bubbles and indirect bubbles.
+
+   Teredo Client: A node that has access to the IPv4 Internet and wants
+   to gain access to the IPv6 Internet using the Teredo protocol.
+
+   Teredo IPv6 Address: An IPv6 address of a Teredo client, as specified
+   in Section 2.14 of [RFC4380].
+
+   Teredo Secondary Server Address: A secondary IPv4 address of a Teredo
+   server with which a Teredo client is configured, as specified in
+   Section 5.2 of [RFC4380].
+
+   Teredo Server: A node that has a globally routable address on the
+   IPv4 Internet, and is used as a helper to provide IPv6 connectivity
+   to Teredo clients.
+
+   Teredo Server Address: A (primary) IPv4 address of a Teredo server
+   with which a Teredo client is configured, as specified in Section 5.2
+   of [RFC4380].
+
+   UPnP-enabled NAT: A NAT that has the UPnP device control protocol
+   enabled, as specified in [UPNPWANIP].  (Note that today, by default,
+   most UPnP-capable NATs have the UPnP device control protocol
+   disabled.)
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+3.  Overview
+
+   The Teredo protocol (as specified in [RFC4380]) enables nodes located
+   behind one or more IPv4 NATs to obtain IPv6 connectivity by tunneling
+   packets over UDP.
+
+   When a node behind a NAT needs to communicate with a peer (i.e.,
+   another node) that is behind a NAT, there are four sets of IPv4
+   address/port pairs of interest:
+
+   o  The node's own IPv4 address/port.
+
+   o  The external IPv4 address/port to which the node's NAT translates.
+
+   o  The peer's own IPv4 address/port.
+
+   o  The external IPv4 address/port to which the peer's NAT translates.
+
+
+
+Thaler                       Standards Track                    [Page 6]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thaler                       Standards Track                    [Page 7]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+                                 Destination NAT
+          |      |      |      |      |      | Port-|      |      |
+          |      |      |      | UPnP | UPnP | pres.| Seq. |      |
+          |      | Addr.| Port | Port | Port | Port-| Port-| Port-| Addr
+Source NAT| Cone | rest.| rest.| rest.| symm.| symm.| symm.| symm.| symm
+----------+------+------+------+------+------+------+------+------+-----
+Cone      |  Yes |  Yes |  Yes |  Yes |  SNS |  SNS |  SNS |  SNS |  SNS
+----------+------+------+------+------+------+------+------+------+-----
+Address   |  Yes |  Yes |  Yes |  Yes |  SNS |  SNS |  SNS |  SNS |  No
+restricted|      |      |      |      |      |      |      |      |
+----------+------+------+------+------+------+------+------+------+-----
+Port      |  Yes |  Yes |  Yes |  Yes |  No  | SNS+ | SNS+ |  No  |  No
+restricted|      |      |      |      |      |  PP  |  SS  |      |
+----------+------+------+------+------+------+------+------+------+-----
+UPnP Port-|  Yes |  Yes |  Yes |  Yes | SNS+ |  No  |  No  |  No  |  No
+restricted|      |      |      |      | UPnP |      |      |      |
+----------+------+------+------+------+------+------+------+------+-----
+UPnP Port |  SNS |  SNS |  No  | SNS+ | SNS+ |  No  |  No  |  No  |  No
+symmetric |      |      |      | UPnP | UPnP |      |      |      |
+----------+------+------+------+------+------+------+------+------+-----
+Port-     |      |      |  SNS |      |      |  SNS |  SNS |      |
+preserving|  SNS |  SNS |   +  |  No  |  No  |   +  |   +  |  No  |  No
+Port-     |      |      |  PP  |      |      |  PP  |  SS  |      |
+symmetric |      |      |      |      |      |      |      |      |
+----------+------+------+------+------+------+------+------+------+-----
+Sequential|      |      |  SNS |      |      |      |      |      |
+Port-     |  SNS |  SNS |   +  |  No  |  No  |  No  |  No  |  No  |  No
+symmetric |      |      |  SS  |      |      |      |      |      |
+----------+------+------+------+------+------+------+------+------+-----
+Port-     |  SNS |  SNS |  No  |  No  |  No  |  No  |  No  |  No  |  No
+symmetric |      |      |      |      |      |      |      |      |
+----------+------+------+------+------+------+------+------+------+-----
+Address-  |  SNS |  No  |  No  |  No  |  No  |  No  |  No  |  No  |  No
+symmetric |      |      |      |      |      |      |      |      |
+----------+------+------+------+------+------+------+------+------+-----
+
+     Yes = Supported by [RFC4380].
+
+     SNS = Supported with the Symmetric NAT Support Extension.
+
+SNS+UPnP = Supported with the Symmetric NAT Support Extension and UPnP
+           Symmetric NAT Extension.
+
+  SNS+PP = Supported with the Symmetric NAT Support Extension and Port-
+           Preserving Symmetric NAT Extension.
+
+  SNS+SS = Supported with the Symmetric NAT Support Extension and
+           Sequential Port-Symmetric NAT Extension.
+
+
+
+Thaler                       Standards Track                    [Page 8]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+      No = No connectivity.
+
+    Figure 1: Matrix of Connectivity Improvements for Teredo Extensions
+
+   Note that as with [RFC4380], if the qualification process is not
+   successful, Teredo will not be configured with an IPv6 address, and
+   connectivity will function as if Teredo were not present.  Similarly,
+   for any combination of NAT types that are not supported by Teredo and
+   the extensions defined herein, the connectivity tests between a
+   client and a peer will fail within a finite period of time, allowing
+   the client to handle this case as with any other type of unreachable
+   destination address (e.g., by trying another address of the
+   destination such as a native IPv4 address).
+
+3.1.  Symmetric NAT Support Extension
+
+   The qualification procedure (as specified in Section 5.2.1 of
+   [RFC4380]) is a process that allows a Teredo client to determine the
+   type of NAT that it is behind, in addition to its mapped address/port
+   as seen by its Teredo server.  However, Section 5.2.1 of [RFC4380]
+   suggests that if the client learns it is behind a symmetric NAT, the
+   Teredo client should go into an "offline state" where it is not able
+   to use Teredo.  The primary reason for doing so is that it is not
+   easy for Teredo clients to connect to each other if either or both of
+   them are positioned behind a symmetric NAT.  Because of the way a
+   symmetric NAT works, a peer sees a different mapped address/port in
+   the IPv4/UDP headers of packets coming from a Teredo client than the
+   node's Teredo server sees (and hence appears in the node's Teredo
+   IPv6 address).  Consequently, a symmetric NAT does not allow incoming
+   packets from a peer that are addressed to the mapped address/port
+   embedded in the node's Teredo IPv6 address.  Thus, the incoming
+   packets are dropped and communication with Teredo clients behind
+   symmetric NATs is not established.
+
+   With the Symmetric NAT Support Extension, Teredo clients begin to use
+   Teredo even after they detect that they are positioned behind a
+   symmetric NAT.
+
+   Consider the topology shown in Figure 2.  Teredo Client B uses Teredo
+   Server 2 to learn that its mapped address/port is 192.0.2.10:8192,
+   and constructs a Teredo IPv6 address, as specified in Section 4 of
+   [RFC4380].  Hence, c633:6476 is the hexadecimal value of the address
+   of Teredo Server 2 (198.51.100.118), the mapped port is exclusive-
+   OR'ed with 0xffff to form dfff, and the Mapped Address is exclusive-
+   OR'ed with 0xffffffff to form 3fff:fdf5.
+
+
+
+
+
+
+Thaler                       Standards Track                    [Page 9]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+   Teredo Client A uses Teredo Server 1 to learn that its mapped
+   address/port is 192.0.2.1:4096 and, with this extension, constructs a
+   Teredo IPv6 address (as specified in Section 4 of [RFC4380]) even
+   though it learns that it is behind a symmetric NAT.  Hence, cb00:7178
+   is the hexadecimal value of the address of Teredo Server 1
+   (203.0.113.120), the mapped port is exclusive-OR'ed with 0xffff to
+   form efff, and the Mapped Address is exclusive-OR'ed with 0xffffffff
+   to form 3fff:fdfe.
+
+   The Symmetric NAT Support Extension enables a Teredo client
+   positioned behind a symmetric NAT to communicate with Teredo peers
+   positioned behind a cone or address-restricted NATs as follows,
+   depending on what side initiates the communication.
+
+               --------------------------------------------
+              /                                            \
+             <               IPv6 Internet                  >
+              \                                            /
+               -|----------------------------------------|-
+                |                                        |
+          +----------+                             +----------+
+          |  Teredo  |                             |  Teredo  |
+          | Server 1 |                             | Server 2 |
+          +----------+                             +----------+
+   203.0.113.120|                          198.51.100.118|
+               -|----------------------------------------|-
+              /                                            \
+             <               IPv4 Internet                  >
+              \                                            /
+               -|----------------------------------------|-
+       192.0.2.1|                              192.0.2.10|
+   UDP port 4096|                           UDP port 8192|
+           +---------+                             +----------+
+           |Symmetric|                             |Other type|
+           |   NAT   |                             |  of NAT  |
+           +---------+                             +----------+
+                |                                        |
+       +-----------------+                      +-----------------+
+       | Teredo client A |                      | Teredo client B |
+       +-----------------+                      +-----------------+
+2001:0:cb00:7178:0:efff:3fff:fdfe      2001:0:c633:6476:0:dfff:3fff:fdf5
+          Teredo Address                           Teredo Address
+
+                      Figure 2: Symmetric NAT Example
+
+   In the first case, assume that a Teredo Client B (B) positioned
+   behind a cone or address-restricted NATs initiates communication with
+   Teredo Client A (A) positioned behind a symmetric NAT.  B sends an
+
+
+
+Thaler                       Standards Track                   [Page 10]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+   indirect bubble via A's server (Teredo Server 1) to A, and A responds
+   with a direct bubble.  This direct bubble reaches B, because it is
+   positioned behind a cone or address-restricted NAT.  However, the
+   mapped address/port in the IPv4/UDP headers of the direct bubble are
+   different from the mapped address/port embedded in A's Teredo IPv6
+   address.  B therefore remembers the mapped address/port of the direct
+   bubble and uses them for future communication with A, and thus
+   communication is established.
+
+   In the second case, assume that A, positioned behind a symmetric NAT,
+   initiates communication with B, positioned behind a cone or address-
+   restricted NAT.  A sends an indirect bubble to B via B's server
+   (Teredo Server 2), and B responds with a direct bubble.  This direct
+   bubble is dropped by A's symmetric NAT because the direct bubble is
+   addressed to the mapped address/port embedded in A's Teredo IPv6
+   address.  However, communication can be established by having B
+   respond with an indirect bubble via A's server (Teredo Server 1).
+   Now the scenario is similar to the first case and communication will
+   be established.
+
+3.2.  UPnP-Enabled Symmetric NAT Extension
+
+   The UPnP-enabled Symmetric NAT Extension is dependent on the
+   Symmetric NAT Support Extension.  Only if Teredo clients have been
+   enabled to acquire a Teredo IPv6 address in spite of being behind a
+   symmetric NAT will this extension help in traversing UPnP-enabled
+   Symmetric NATs.
+
+   The Symmetric NAT Support Extension enables communication between
+   Teredo clients behind symmetric NATs with Teredo clients behind cone
+   NATs or address-restricted NATs.  However, clients behind symmetric
+   NATs can still not communicate with clients behind port-restricted
+   NATs or symmetric NATs.
+
+   Referring again to Figure 2 (see Section 3.1), assume that Teredo
+   Client A is positioned behind a symmetric NAT and initiates
+   communication with Client B, which is positioned behind a port-
+   restricted NAT.  Client A sends a direct bubble and an indirect
+   bubble to Client B via Client B's server (Teredo Server 2).  As per
+   the characteristics of the symmetric NAT, the IPv4 source of the
+   direct bubble contains a different mapped address and/or port than
+   the one embedded in the Teredo server.  This direct bubble is dropped
+   because Client B's NAT does not have state to let it pass through,
+   and Client B does not learn the mapped address/port used in the IPv4/
+   UDP headers.  In response to the indirect bubble from Client A,
+   Client B sends a direct bubble destined to the mapped address/port
+   embedded in Client A's Teredo IPv6 address.  This direct bubble is
+   dropped because Client A's NAT does not have state to accept packets
+
+
+
+Thaler                       Standards Track                   [Page 11]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+   destined to that mapped address/port.  The direct bubble does,
+   however, cause Client B's NAT to set up outgoing state for the mapped
+   address/port embedded in Client A's Teredo IPv6 address.
+
+   As described in Section 3.1, Client B also sends an indirect bubble
+   that elicits a direct bubble from Client A.  Unlike the case in
+   Section 3.1, however, the direct bubble from Client A is dropped as
+   Client B's NAT does not have state for the mapped address/port that
+   Client A's NAT uses.  Note that Client B's NAT is port-restricted and
+   hence requires both the mapped address and port to be the same as in
+   its outgoing state, whereas in Section 3.1, Client A's NAT was a cone
+   or address-restricted NAT which only required the mapped address (but
+   not port) to be the same.  Thus, communication between Client A and
+   Client B fails.  If Client B were behind a symmetric NAT, the problem
+   is further complicated by Client B's NAT using a different outgoing
+   mapped address/port than the one embedded in Client B's Teredo IPv6
+   address.
+
+   If a Teredo client is separated from the global Internet by a single
+   UPnP-enabled symmetric or port-restricted NAT, it can communicate
+   with other Teredo clients that are positioned behind a single UPnP-
+   enabled symmetric or port-restricted NAT as follows.
+
+   Teredo clients, before communicating with the Teredo server during
+   the qualification procedure, use UPnP to reserve a translation from a
+   local address/port to a mapped-address/port.  Therefore, during the
+   qualification procedure, the Teredo server reflects back the reserved
+   mapped address/port, which then is included in the Teredo IPv6
+   address.  The mapping created by UPnP allows the NAT to forward
+   packets destined for the mapped address/port to the local address/
+   port, independent of the source of the packets.  It typically does
+   not, however, cause packets sourced from the local address/port to be
+   translated to have the mapped address/port as the external source and
+   hence continues to function as a symmetric NAT in this respect.
+
+   Thus, a Teredo client, positioned behind a UPnP-enabled symmetric
+   NAT, can receive a direct bubble sent by any Teredo peer.  The Teredo
+   client compares the peer's mapped address/port as seen in the IPv4/
+   UDP headers with the mapped address/port in the peer's Teredo IPv6
+   address.  If the two mappings are different, the packet was sent by
+   another Teredo client positioned behind a symmetric NAT.  The
+   Symmetric NAT Support Extension suggested that the Teredo client use
+   the peer's mapped address/port seen in the IPv4/UDP headers for
+   future communication.  However, because symmetric NAT-to-symmetric
+   NAT communication would not have been possible anyway, the Teredo
+   client sends back a direct bubble to the mapped port/address embedded
+
+
+
+
+
+Thaler                       Standards Track                   [Page 12]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+   in the peer's Teredo IPv6 address.  If the peer is also situated
+   behind a UPnP-enabled NAT, the direct bubble will make it through and
+   communication will be established.
+
+   Even though communication is established between the two Teredo IPv6
+   addresses, the mappings will be asymmetric in the two directions of
+   data transfer.  Specifically, incoming packets will be destined to
+   the reserved mapped address/port that is embedded in the Teredo IPv6
+   address.  Outgoing packets will instead appear to come from a
+   different mapped address/port due to the symmetric NAT behavior.
+
+3.3.  Port-Preserving Symmetric NAT Extension
+
+   The Port-Preserving Symmetric NAT Extension is dependent on the
+   Symmetric NAT Support Extension (Section 3.1).  Only if Teredo
+   clients have been enabled to acquire a Teredo IPv6 address in spite
+   of being behind a symmetric NAT will this extension help in
+   traversing port-preserving symmetric NATs.
+
+   The Symmetric NAT Support Extension enables communication between
+   Teredo clients behind symmetric NATs with Teredo clients behind cone
+   NATs or address-restricted NATs.  However, clients behind symmetric
+   NATs can still not communicate with clients behind port-restricted or
+   symmetric NATs, as described in Section 3.2.  Note that the Port-
+   Preserving Symmetric NAT Extension described here is independent of
+   the UPnP-enabled Symmetric NAT Extension, described in Section 3.2.
+
+   If a Teredo client is positioned behind a port-preserving symmetric
+   NAT, the client can communicate with other Teredo clients positioned
+   behind a port-restricted NAT or a port-preserving symmetric NAT as
+   follows.
+
+   Teredo clients compare the mapped port learned during the
+   qualification procedure with their local port to determine if they
+   are positioned behind a port-preserving NAT.  If both the mapped port
+   and the local port have the same value, the Teredo client is
+   positioned behind a port-preserving NAT.  At the end of the
+   qualification procedure, the Teredo client also knows if it is
+   positioned behind a symmetric NAT, as described in Section 3.1.
+
+   Teredo clients positioned behind port-preserving symmetric NATs can
+   also listen on randomly chosen local ports.  If the randomly chosen
+   local port has not been used by the symmetric NAT as a mapped port in
+   a prior port-mapping, the NAT uses the same port number as the mapped
+   port.  Thus, the challenge is to get the first direct bubble sent out
+   from the random port to be destined to a valid destination address
+   and port.  When the mapped address/port is embedded in the
+   destination's Teredo IPv6 address, this is easy.
+
+
+
+Thaler                       Standards Track                   [Page 13]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+   The communication setup is more complicated when the destination
+   Teredo client is also positioned behind a port-preserving symmetric
+   NAT.  In such a case, both Teredo clients need to send their first
+   direct bubbles to the correct destination mapped address/port.  Thus,
+   the protocol messages, which communicate one Teredo client's random
+   port number to the other Teredo client, must be exchanged indirectly
+   (via Teredo servers).  When one Teredo client has access to the other
+   Teredo client's random port number, it can send a direct bubble
+   destined to the mapped address embedded in the destination's Teredo
+   IPv6 address, and the mapped port can be the same as the
+   destination's random port number.  If both NATs are port-preserving,
+   port-preserved mappings are created on both NATs and the second
+   direct bubble succeeds in reaching the destination.
+
+3.4.  Sequential Port-Symmetric NAT Extension
+
+   The Sequential Port-Symmetric NAT Extension is dependent on the
+   Symmetric NAT Support Extension (Section 3.1).  This extension helps
+   in traversing a sequential port-symmetric NAT only if Teredo clients
+   are enabled to acquire a Teredo IPv6 address even when behind a
+   symmetric NAT.
+
+   When the Sequential Port-Symmetric NAT Extension is used, if a Teredo
+   client is positioned behind a sequential port-symmetric NAT, the
+   client can communicate with other Teredo clients that are positioned
+   behind a port-restricted NAT as follows.
+
+   During qualification, if the client discovers it is behind a
+   symmetric NAT that is not port-preserving, the client assumes by
+   default that it is behind a sequential port-symmetric NAT.  This
+   assumption is proactive for the following reasons:
+
+   o  There is no perfect method of discovering whether the client is
+      behind a sequential port-symmetric NAT.
+
+   o  These kinds of NATs are notorious for changing their behavior.  At
+      times, they could be sequential port-symmetric and at other times
+      not.
+
+   o  There is no other solution for symmetric NAT traversal so this is
+      a last resort.
+
+   Teredo clients positioned behind sequential port-symmetric NATs can
+   also listen on a randomly chosen local port when communicating with a
+   peer.  To predict the external port being used for a given peer, the
+   client sends three packets:
+
+
+
+
+
+Thaler                       Standards Track                   [Page 14]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+   o  Packet 1 is a router solicitation (as specified in Section 5.2.1
+      of [RFC4380]) sent to the Teredo server address.
+
+   o  Packet 2 is a direct bubble sent to the peer.
+
+   o  Packet 3 is a router solicitation sent to the secondary Teredo
+      server address.
+
+   As part of the normal Teredo protocol, the Teredo server responds to
+   packets 1 and 3.  Based on the information in the responses, the
+   client now knows that Packet 1 was seen as coming from one external
+   port, and Packet 3 was seen as coming from another external port.
+   Assuming the NAT is a sequential port-symmetric NAT, the external
+   port for Packet 2 is estimated (or predicted) to be midway between
+   the external ports for Packets 1 and 3.  Note that because other
+   applications might also have been using the NAT between packets 1 and
+   3, the actual port might not be exactly the midpoint.
+
+   The Teredo client then communicates the predicted port to its peer,
+   which sends a direct bubble to the communicated port.  If the
+   communicated port is indeed the external port for Packet 2, the
+   direct bubble will reach the Teredo client.
+
+3.5.  Hairpinning Extension
+
+   Hairpinning support in a NAT routes packets that are sent from a
+   private (local) address destined to a public (mapped) address of the
+   NAT, back to another private (local) destination address behind the
+   same NAT.  If hairpinning support is not available in a NAT, two
+   Teredo clients behind the same NAT are not able to communicate with
+   each other, as specified in Section 8.3 of [RFC4380].
+
+   The Hairpinning Extension enables two clients behind the same NAT to
+   talk to each other when the NAT does not support hairpinning.  This
+   process is illustrated in the following diagram.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thaler                       Standards Track                   [Page 15]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+               --------------------------------------------
+              /                                            \
+             <               IPv6 Internet                  >
+              \                                            /
+               --------------------|-----------------------
+                                   |
+                             +----------+
+                             |  Teredo  |
+                             |  Server  |
+                             +----------+
+                      203.0.113.120|
+               --------------------|-----------------------
+              /                                            \
+             <               IPv4 Internet                  >
+              \                                            /
+               --------------------|-----------------------
+                     198.51.100.118|
+                           NAT +-------+
+                       without |  NAT  |
+                   hairpinning |   E   |
+                       support +-------+
+                                   |
+                +------------------+--------------------+
+     192.168.1.0|                            192.168.1.1|
+   UDP port 4095|                          UDP port 4096|
+           +---------+                            +----------+
+           |   NAT   |                            |    NAT   |
+           |    F    |                            |     G    |
+           +---------+                            +----------+
+                |                                       |
+       +-----------------+                     +-----------------+
+       | Teredo client A |                     | Teredo client B |
+       +-----------------+                     +-----------------+
+2001:0:cb00:7178:0:f000:39cc:9b89      2001:0:cb00:7178:0:efff:39cc:9b89
+          Teredo Address                          Teredo Address
+
+                       Figure 3: Hairpinning Example
+
+   The Teredo Client A (A) includes, as part of its indirect bubble sent
+   to Teredo Client B (B), its local address/port.  B, upon receiving
+   the indirect bubble, tries to establish communication by sending
+   direct bubbles to the mapped address/port of A, and also to the local
+   address/port of B.
+
+   If a Teredo client is part of a multi-NAT hierarchy and the NAT to
+   which the Teredo client is connected supports the UPnP protocol (as
+   specified in [UPNPWANIP]), the Teredo client can use UPnP to
+   determine the mapped address/port assigned to it by the NAT.  This
+
+
+
+Thaler                       Standards Track                   [Page 16]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+   information can be included along with the local address/port when
+   sending the indirect bubble.  The destination Teredo client now tries
+   to establish a connection by sending direct bubbles to the mapped
+   address/port in the Teredo IPv6 address, to the local address/port
+   included in the bubble, and also to the mapped address/port included
+   in the bubble.
+
+   Note that UPnP support is only required if the Teredo clients are
+   behind different NATs in a multi-NAT hierarchy.  Without UPnP
+   support, the Hairpinning Extension still allows two hosts behind the
+   same non-hairpinning NAT to communicate using their Teredo IPv6
+   addresses.
+
+3.6.  Server Load Reduction Extension
+
+   If communication between a Teredo client and a Teredo peer was
+   successfully established but at a later stage was silent for a while,
+   for efficiency, it is best to refresh the mapping state in the NATs
+   that are positioned between them.  To refresh the communication
+   between itself and a Teredo peer, a Teredo client needs to solicit a
+   direct bubble response from the Teredo peer.  An indirect bubble is
+   sent to solicit a direct bubble response from a Teredo peer, as
+   specified in Section 5.2.4 of [RFC4380].  However, these indirect
+   bubbles increase the load on the Teredo server.
+
+   The Server Load Reduction Extension allows Teredo clients to send
+   direct bubbles most of the time instead of sending indirect bubbles
+   all of the time in the following way:
+
+   1.  When a Teredo client tries to refresh its communication with a
+       Teredo peer, it uses a direct bubble instead of an indirect
+       bubble.  However, because direct bubbles do not normally solicit
+       a response, the direct bubble format is extended to be able to
+       solicit a response.
+
+   2.  When a Teredo client receives a direct bubble that is soliciting
+       a response, the Teredo client responds with a direct bubble.
+
+   3.  If attempts to re-establish communication with the help of direct
+       bubbles fail, the Teredo client starts over the process of
+       establishing communication with the Teredo peer, as specified in
+       Section 5.2.4 of [RFC4380].
+
+
+
+
+
+
+
+
+
+Thaler                       Standards Track                   [Page 17]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+4.  Message Syntax
+
+   All Teredo messages are transported over the User Datagram Protocol
+   (UDP), as specified in Section 3 of [RFC4380].
+
+   In addition, Section 5.2.3 of [RFC4380] states:
+
+      An IPv6 packet is deemed valid if it conforms to [RFC2460]: the
+      protocol identifier should indicate an IPv6 packet and the payload
+      length should be consistent with the length of the UDP datagram in
+      which the packet is encapsulated.  In addition, the client should
+      check that the IPv6 destination address correspond [sic] to its
+      own Teredo address.
+
+   This document updates the word "consistent" above as follows.  The
+   IPv6 payload length is "consistent" with the length of the UDP
+   datagram if the IPv6 packet length (i.e., the Payload Length value in
+   the IPv6 header plus the IPv6 header size) is less than or equal to
+   the UDP payload length (i.e., the Length value in the UDP header
+   minus the UDP header size).  This allows the use of trailers after
+   the IPv6 packet, which are defined in the following sections.
+
+4.1.  Trailers
+
+   Teredo packets can carry a variable number of type-length-value (TLV)
+   encoded trailers, of the following format (intended to be similar to
+   the use of IPv6 options defined in [RFC2460] section 4.2):
+
+                        1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |        Value (variable)       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type (1 byte): 8-bit identifier of the type of trailer.
+
+   Length (1 byte): 8-bit unsigned integer.  Length of the Value field
+   of this trailer, in octets.
+
+   Value (variable): Trailer-Type-specific data.
+
+   The trailer Type identifiers are internally encoded such that their
+   highest-order two bits specify the action that is to be taken if the
+   host does not recognize the trailer Type:
+
+
+
+
+
+
+
+Thaler                       Standards Track                   [Page 18]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+   00, 10, 11 -  skip over this trailer and continue processing the
+      packet.
+
+   01 -  discard the packet.
+
+4.2.  Nonce Trailer
+
+   The Nonce Trailer is used by the Symmetric NAT Support Extension (and
+   therefore the UPnP-enabled Symmetric NAT Extension and Port-
+   Preserving Symmetric NAT Extension also) and the Hairpinning
+   Extension.  The Nonce Trailer can be present in both indirect and
+   direct bubbles.  The nonce in the Nonce Trailer helps authenticate a
+   Teredo client positioned behind a Symmetric NAT.
+
+                        1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Nonce             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              ...              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type (1 byte): The Trailer Option type.  This field MUST be set to
+   0x01.
+
+   Length (1 byte): The length in bytes of the rest of the option.  This
+   field MUST be set to 0x04.
+
+   Nonce (4 bytes): The nonce value.
+
+4.3.  Alternate Address Trailer
+
+   The Alternate Address Trailer is used by the Hairpinning Extension.
+   The Alternate Address Trailer MUST NOT be present in any packets
+   other than indirect bubbles sent by a Teredo client.  The Alternate
+   Address Trailer provides another Teredo client positioned behind the
+   same NAT with more address options that it can use to connect.
+
+                        1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |            Reserved           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   |              Alternate Address/Port List (variable)           |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+Thaler                       Standards Track                   [Page 19]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+   Type (1 byte): The Trailer Option type.  This field MUST be set to
+   0x03.
+
+   Length (1 byte): The length in bytes of the rest of the option.  The
+   value of this field MUST be in the range 8 to 26 (i.e., 2 bytes for
+   the Reserved field, and 6 bytes for each entry in the Alternate
+   Address/Port List).  This allows for a minimum of one address/port
+   mapping and a maximum of four address/port mappings to be advertised.
+   It SHOULD be at most 14 as a maximum of two address/port mappings can
+   be determined by Teredo: one local address/port and one obtained
+   using UPnP.  Because the length of the alternate address/port is 6
+   bytes, the valid range of values is only 8, 14, 20, and 26.
+
+   Reserved (2 bytes): This field MUST be set to 0x0000 and ignored on
+   receipt.
+
+   Alternate Address/Port List (variable): An array of additional
+   address/port pairs that can be used by other Teredo clients to
+   communicate with the sender.  Each alternate address/port entry MUST
+   be formatted as follows:
+
+                        1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      IPv4 Address                             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              Port             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   IPv4 Address (4 bytes): An IPv4 address in network byte order.  This
+   field MUST contain a valid unicast address.
+
+   Port (2 bytes): A port number in network byte order.  This field MUST
+   NOT be zero.
+
+4.4.  Neighbor Discovery Option Trailer
+
+   The Neighbor Discovery Option Trailer is used by the Server Load
+   Reduction Extension because it allows direct bubbles to encode an
+   IPv6 Neighbor Solicitation (Section 4.3 of [RFC4861]), in addition to
+   an IPv6 Neighbor Advertisement (Section 4.4 of [RFC4861]).  This
+   allows packets to be sent without having to relay them through a
+   Teredo server.  The Neighbor Discovery Option Trailer allows the
+   receiver to differentiate between a direct bubble that is soliciting
+   a response versus a regular direct bubble.  This allows Teredo
+   clients to use direct bubbles to refresh inactive connections instead
+   of using indirect bubbles.
+
+
+
+
+Thaler                       Standards Track                   [Page 20]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+                        1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |      Type     |     Length    | DiscoveryType |   Reserved    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              ...              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type (1 byte): The Trailer Option type.  This field MUST be set to
+   0x04.
+
+   Length (1 byte): The length in bytes of the rest of the option.  This
+   field MUST be set to 0x04.
+
+   DiscoveryType (1 byte): This field MUST be set to one of the
+   following values:
+
+      TeredoDiscoverySolicitation (0x00): The receiver is requested to
+      respond with a direct bubble of DiscoveryType
+      TeredoDiscoveryAdvertisement.
+
+      TeredoDiscoveryAdvertisement (0x01): The direct bubble is in
+      response to a direct bubble or an indirect bubbles containing
+      DiscoveryType TeredoDiscoverySolicitation.
+
+   Reserved (3 bytes): This field MUST be set to 0x000000 on
+   transmission and ignored on receipt.
+
+4.5.  Random Port Trailer
+
+   The Random Port Trailer is used by the Port-Preserving Symmetric NAT
+   Extension in both indirect and direct bubbles.
+
+                        1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |      Type     |     Length    |          Random Port          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type (1 byte): The Trailer Option type.  This field MUST be set to
+   0x05.
+
+   Length (1 byte): The length in bytes of the rest of the option.  This
+   field MUST be set to 0x02.
+
+   Random Port (2 bytes): The external port that the sender predicts
+   that its NAT has assigned it for communication with the destination.
+   This field MUST be specified in network byte order.
+
+
+
+Thaler                       Standards Track                   [Page 21]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+5.  Protocol Details
+
+5.1.  Common Processing
+
+   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.)
+
+5.1.1.  Refresh Interval
+
+   Section 5.2 of [RFC4380] 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 (Section 5.2.7 of [RFC4380]) 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.
+
+   Section 5.2.5 of [RFC4380] 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
+      Section 5.2.1;
+
+
+
+
+
+
+
+Thaler                       Standards Track                   [Page 22]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+   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.)
+
+5.1.2.  Trailer Processing
+
+   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.
+
+5.2.  Symmetric NAT Support Extension
+
+   Section 5.2.1 of [RFC4380] 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, Section 5.2.9 of [RFC4380] 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 Section 4 of [RFC4443]).  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.
+
+
+
+
+
+Thaler                       Standards Track                   [Page 23]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+5.2.1.  Abstract Data Model
+
+   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 Section 5.2 of [RFC4380], 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.
+
+5.2.2.  Timers
+
+   No timers are necessary other than those in [RFC4380].
+
+5.2.3.  Initialization
+
+   No initialization is necessary other than that specified in
+   [RFC4380].
+
+5.2.4.  Message Processing
+
+   Except as specified in the following sections, the rules for message
+   processing are as specified in [RFC4380].
+
+5.2.4.1.  Sending an Indirect Bubble
+
+   The rules for when indirect bubbles are sent to a Teredo peer are
+   specified in Section 5.2.6 of [RFC4380].  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 (Section 4.2)
+   appended to the indirect bubble, and also store it in the Nonce Sent
+   field of its Peer Entry for that Teredo peer.
+
+
+
+
+
+
+
+
+Thaler                       Standards Track                   [Page 24]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+5.2.4.2.  Sending a Direct Bubble
+
+   The rules for when direct bubbles are sent to a Teredo peer are
+   specified in Section 5.2.6 of [RFC4380].  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.
+
+5.2.4.3.  Receiving an Indirect Bubble
+
+   The rules for processing an indirect bubble are specified in Section
+   5.2.3 of [RFC4380].  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.
+
+5.2.4.4.  Receiving a Direct Bubble
+
+   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 Section 5.2.3 of [RFC4380].
+
+   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
+   Section 5.2 of [RFC4380].
+
+5.3.  UPnP-Enabled Symmetric NAT Extension
+
+   The UPnP-enabled Symmetric NAT Extension is optional; an
+   implementation SHOULD support it.  This extension has the Symmetric
+   NAT Support Extension (Section 5.2) as a dependency.  Any node that
+   implements this extension MUST also implement the Symmetric NAT
+   Support Extension.
+
+
+
+Thaler                       Standards Track                   [Page 25]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+5.3.1.  Abstract Data Model
+
+   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 Section 5.2.1 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.
+
+5.3.2.  Timers
+
+   No timers are necessary other than those in [RFC4380].
+
+
+
+
+
+
+Thaler                       Standards Track                   [Page 26]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+5.3.3.  Initialization
+
+   Prior to beginning the qualification procedure, the Teredo client
+   MUST first perform the uninitialization procedure specified in
+   Section 5.3.5.1 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 [UPNPWANIP], 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
+   [UPNPWANIP].  If the GetExternalIPAddress function fails, the Teredo
+   client SHOULD perform the uninitialization procedure specified in
+   Section 5.3.5.1 and continue without using this extension.  If the
+   GetExternalIPAddress function succeeds, the Teredo client MUST
+   proceed as follows.
+
+
+
+
+
+
+Thaler                       Standards Track                   [Page 27]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+   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 Section 5.2.1 of
+   [RFC4380]) 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.
+
+5.3.4.  Message Processing
+
+   Except as specified in the following sections, the rules for message
+   processing are as specified in Section 5.2.3 of [RFC4380].
+
+5.3.4.1.  Receiving a Direct Bubble
+
+   Except as indicated below, the rules for handling a direct bubble are
+   as specified in Section 5.2.4.4.
+
+   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.
+
+5.3.4.2.  Sending a Direct Bubble
+
+   The rules for sending a direct bubble are specified in Section 5.2.6
+   of [RFC4380] and Section 5.2.4.2 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.
+
+
+
+
+Thaler                       Standards Track                   [Page 28]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+   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.
+
+5.3.4.3.  Sending a Data Packet
+
+   The rules for sending a data packet are specified in Section 5.2.4 of
+   [RFC4380].  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.
+
+5.3.5.  Shutdown
+
+   When Teredo client functionality is being shut down, uninitialization
+   MUST be performed as specified in Section 5.3.5.1.
+
+5.3.5.1.  Uninitialization
+
+   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.
+
+
+
+
+
+Thaler                       Standards Track                   [Page 29]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+   If the mapped port is non-zero, the Teredo client MUST call the
+   DeletePortMapping function, as specified in Section 2.4.17 of
+   [UPNPWANIP], with the following parameters:
+
+   o  NewRemoteHost: "" (empty string)
+
+   o  NewExternalPort: the mapped port
+
+   o  NewProtocol: UDP
+
+5.4.  Port-Preserving Symmetric NAT Extension
+
+   The Port-Preserving Symmetric NAT Extension is optional; an
+   implementation SHOULD support it.  This extension has the Symmetric
+   NAT Support Extension (as specified in Section 5.2) as a dependency.
+   Any node that implements this extension MUST also implement the
+   Symmetric NAT Support Extension.
+
+5.4.1.  Abstract Data Model
+
+   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 Section 5.2.1 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.
+
+
+
+
+
+Thaler                       Standards Track                   [Page 30]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+   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 Section 5.2 of
+      [RFC4380]) because the RFC-defined field is also updated every
+      time a direct bubble is sent.
+
+5.4.2.  Timers
+
+   Other than those in [RFC4380], 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.
+
+5.4.2.1.  Peer Refresh Timer Expiry
+
+   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
+   Section 5.4.4.3) 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.
+
+
+
+
+
+Thaler                       Standards Track                   [Page 31]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+5.4.3.  Initialization
+
+   In addition to the behavior specified in [RFC4380], 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 Section 5.2.1 of
+   [RFC4380]), 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 Section 5.1.1 of [RFC4380],
+   with the Local Port value.  If both values match, the client MUST set
+   the Port-Preserving NAT flag to TRUE.
+
+5.4.4.  Message Processing
+
+5.4.4.1.  Sending a Data Packet
+
+   On receiving a data packet to be transmitted to the Teredo peer (in
+   addition to the rules specified in Section 5.2.4 of [RFC4380]), the
+   Teredo client MUST update the Last Data Packet Sent Timestamp when
+   the packet is actually sent.
+
+5.4.4.2.  Sending an Indirect Bubble
+
+   The rules for sending an indirect bubble are as specified in
+   Section 5.2.4.1 of this document and Section 5.2.6 of [RFC4380].  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 Section 5.2 of [RFC4380]), 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.
+
+
+
+
+
+
+
+
+
+
+Thaler                       Standards Track                   [Page 32]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+5.4.4.3.  Sending a Direct Bubble
+
+   The rules for when direct bubbles are sent to a Teredo peer are as
+   specified in Section 5.2.6 of [RFC4380].  In addition,
+   Section 5.2.4.2 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 Section 5.2 of [RFC4380]) 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 (Section 4.5).
+
+5.4.4.4.  Receiving an Indirect Bubble
+
+   The rules for processing an indirect bubble are as specified in
+   Section 5.2.4.3 of this document and Section 5.2.3 of [RFC4380].  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 Section 5.2 of [RFC4380], 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.
+
+
+
+Thaler                       Standards Track                   [Page 33]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+5.4.4.5.  Receiving a Direct Bubble
+
+   The rules for handling direct bubbles are specified in
+   Section 5.2.4.4 of this document and Section 5.2.3 of [RFC4380].  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
+      Section 5.2 of [RFC4380].  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 Section 5.2 of [RFC4380], 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.
+
+
+
+
+
+
+
+
+Thaler                       Standards Track                   [Page 34]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+   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 Section 5.2
+      of [RFC4380].
+
+   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 Section 5.4.4.2.
+
+   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.
+
+5.5.  Sequential Port-Symmetric NAT Extension
+
+   The Sequential Port-Symmetric NAT Extension is optional; an
+   implementation SHOULD support it.  This extension has the Symmetric
+   NAT Support Extension (Section 5.2) 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
+   (Section 5.4).
+
+5.5.1.  Abstract Data Model
+
+   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 Section 5.4.1 by adding the following additional state.
+
+
+
+
+
+
+Thaler                       Standards Track                   [Page 35]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+   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 Section 5.1.1 of
+      [RFC4380], 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.
+
+5.5.2.  Timers
+
+   In addition to the timers specified in Section 5.4.2, 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.
+
+5.5.2.1.  Peer Refresh Timer Expiry
+
+   The processing of the Peer Refresh Timer Expiry MUST be completed as
+   specified in Section 5.4.2.1.  In addition to those rules, the Teredo
+   client MUST set the EchoTestLowerPort, EchoTestUpperPort, and
+   EchoTestRetryCounter to zero.
+
+5.5.2.2.  Echo Test Failover Timer Expiry
+
+   If the Echo Test Failover Timer expires, the Teredo client MUST do
+   the following.
+
+
+
+
+Thaler                       Standards Track                   [Page 36]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+   If the value of the EchoTestRetryCounter is two, then the Teredo
+   client MUST send an indirect bubble as specified in Section 5.2.4.1.
+
+   If the value of the EchoTestRetryCounter is one, then the Teredo
+   client MUST start another Echo Test as specified in
+   Section 5.5.4.1.1.
+
+5.5.3.  Initialization
+
+   No behavior changes are required beyond what is specified in
+   Section 5.4.3.
+
+5.5.4.  Message Processing
+
+   Except as specified in the following sections, the rules for message
+   processing are as specified in Section 5.4.4.
+
+5.5.4.1.  Handling a Request to Send an Indirect Bubble
+
+   Whenever [RFC4380] 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 [RFC4380] 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 Section 5.5.4.4.
+
+   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 Section 5.2 of [RFC4380]), 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.
+
+5.5.4.1.1.  Starting an Echo Test
+
+   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 Section 5.2.1 of
+      [RFC4380]) 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 Section 5.1.1 of
+      [RFC4380].  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.
+
+
+
+
+
+Thaler                       Standards Track                   [Page 37]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+   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 Section 5.1.1 of [RFC4380].  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.
+
+5.5.4.2.  Sending an Indirect Bubble
+
+   The rules for sending an indirect bubble are as specified in
+   Section 5.2.4.1 of this document and Section 5.2.6 of [RFC4380].  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.
+
+5.5.4.3.  Receiving a Direct Bubble
+
+   The processing of the direct bubble MUST be completed as specified in
+   Section 5.4.4.5, 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.
+
+5.5.4.4.  Receiving a Router Advertisement
+
+   The rules for processing a router advertisement are as specified in
+   Section 5.2.1 of [RFC4380].  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.
+
+
+
+Thaler                       Standards Track                   [Page 38]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+   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 Section 5.5.4.2.
+
+5.6.  Hairpinning Extension
+
+   This extension is optional; an implementation SHOULD support it.
+
+5.6.1.  Abstract Data Model
+
+   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 Section 5.2 of [RFC4380], 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
+   [RFC4380] by including the following:
+
+   o  Alternate Address/Port list: The list of alternate address/port
+      pairs advertised by the peer.
+
+5.6.2.  Timers
+
+   No timers are necessary other than those in [RFC4380].
+
+5.6.3.  Initialization
+
+   Behavior is as specified in [RFC4380], with the following additions.
+
+   Prior to beginning the qualification procedure, the Teredo client
+   MUST invoke the AddPortMapping function (as specified in Section
+   2.4.16 of [UPNPWANIP]) with the parameters specified in
+   Section 5.3.3.  If successful, it indicates that the NAT has created
+   a port mapping from the external port of the NAT to the internal port
+
+
+
+Thaler                       Standards Track                   [Page 39]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+   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.
+
+5.6.4.  Message Processing
+
+5.6.4.1.  Sending an Indirect Bubble
+
+   The rules for when indirect bubbles are sent to a Teredo peer are as
+   specified in Section 5.2.6 of [RFC4380].  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 Section 5.2.9 of [RFC4380]) 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.
+
+5.6.4.2.  Receiving an Indirect Bubble
+
+   The rules for processing indirect bubbles are as specified in Section
+   5.2.3 of [RFC4380].  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 Section 4.3), 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 Section 5.2.6 of [RFC4380]), 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.
+
+
+
+
+
+
+
+Thaler                       Standards Track                   [Page 40]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+5.6.4.3.  Receiving a Direct Bubble
+
+   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 Section 5.2.3 of [RFC4380].
+
+   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.
+
+5.7.  Server Load Reduction Extension
+
+   This extension is optional; an implementation SHOULD support it.
+
+5.7.1.  Abstract Data Model
+
+   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 Section 5.2 of [RFC4380], 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.
+
+5.7.2.  Timers
+
+   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
+
+
+
+
+
+Thaler                       Standards Track                   [Page 41]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+   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.
+
+5.7.3.  Initialization
+
+   No initialization is necessary other than that specified in
+   [RFC4380].
+
+5.7.4.  Message Processing
+
+   Except as specified below, processing is the same as specified in
+   [RFC4380].
+
+5.7.4.1.  Sending a Data Packet
+
+   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 Section 5.2 of [RFC4380]).
+   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.
+
+5.7.4.2.  Receiving a Direct Bubble
+
+   The rules for processing direct bubbles are as specified in Section
+   5.2.3 of [RFC4380].  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.
+
+6.  Protocol Examples
+
+   The following sections describe several operations as used in common
+   scenarios to illustrate the function of Teredo Extensions.
+
+6.1.  Symmetric NAT Support Extension
+
+   The following protocol example illustrates the use of the Symmetric
+   NAT Support Extension.
+
+
+
+
+
+
+Thaler                       Standards Track                   [Page 42]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+   In Figure 2 (Section 3.1), 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 Section 5.2.1 of [RFC4380].  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 |--------------------------------------------------->|        |
+      |         |        |                       |         |        |
+      |Indirect Bubble to B via B's Teredo Server|         |        |
+    2 |----------------------------------------->|----------------->|
+      |         |        |                       |         |        |
+      |         |        |  Direct Bubble to A   |         |        |
+      |         |<--------------------------------------------------| 3
+      |         |        |                       |         |        |
+      |         |        |Indirect Bubble to A via A's Teredo Server|
+      |<-----------------|<-----------------------------------------| 4
+      |         |        |                       |         |        |
+      |         |        |  Direct Bubble to B   |         |        |
+    5 |------------------------------------------------------------>|
+      |         |        |                       |         |        |
+      |Indirect Bubble to B via B's Teredo Server|         |        |
+    6 |----------------------------------------->|----------------->|
+      |         |        |                       |         |        |
+      |         |        |  Direct Bubble to A   |         |        |
+      |<------------------------------------------------------------| 7
+      |         |        |                       |         |        |
+
+            Port-Symmetric NAT to Address-Restricted NAT Packet
+                                 Exchange
+
+
+
+
+
+
+
+
+Thaler                       Standards Track                   [Page 43]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+   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).
+
+
+
+
+
+
+Thaler                       Standards Track                   [Page 44]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+   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).
+
+6.2.  UPnP-Enabled Symmetric NAT Extension
+
+   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).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thaler                       Standards Track                   [Page 45]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+   Teredo           Client A's              Client B's           Teredo
+   Client             Teredo                  Teredo             Client
+      A        NAT    Server                  Server      NAT       B
+      |         |        |                       |         |        |
+      |         |        |  Direct Bubble to B   |         |        |
+    1 |------------------------------------------------------------>|
+      |         |        |                       |         |        |
+      |Indirect Bubble to B via B's Teredo Server|         |        |
+    2 |----------------------------------------->|----------------->|
+      |         |        |                       |         |        |
+      |         |        |  Direct Bubble to A   |         |        |
+      |<------------------------------------------------------------| 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
+
+
+
+Thaler                       Standards Track                   [Page 46]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+       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).
+
+6.3.  Port-Preserving Symmetric NAT Extension
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thaler                       Standards Track                   [Page 47]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+   Teredo           Client A's              Client B's           Teredo
+   Client             Teredo                  Teredo             Client
+      A        NAT    Server                  Server      NAT       B
+      |         |        |                       |         |        |
+      |         |        |  Direct Bubble to B   |         |        |
+    1 |--------------------------------------------------->|        |
+      |         |        |                       |         |        |
+      |Indirect Bubble to B via B's Teredo Server|         |        |
+    2 |----------------------------------------->|----------------->|
+      |         |        |                       |         |        |
+      |         |        |  Direct Bubble to A   |         |        |
+      |         |<--------------------------------------------------| 3
+      |         |        |                       |         |        |
+      |         |        |  Direct Bubble to A   |         |        |
+      |         |<--------------------------------------------------| 4
+      |         |        |                       |         |        |
+      |         |        |Indirect Bubble to A via A's Teredo Server|
+      |<-----------------|<-----------------------------------------| 5
+      |         |        |                       |         |        |
+      |         |        |  Direct Bubble to B   |         |        |
+    6 |--------------------------------------------------->|        |
+      |         |        |                       |         |        |
+      |         |        |  Direct Bubble to B   |         |        |
+    7 |------------------------------------------------------------>|
+      |         |        |                       |         |        |
+      |Indirect Bubble to B via B's Teredo Server|         |        |
+    8 |----------------------------------------->|----------------->|
+      |         |        |                       |         |        |
+      |         |        |  Direct Bubble to A   |         |        |
+      |<------------------------------------------------------------| 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.
+
+
+
+Thaler                       Standards Track                   [Page 48]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+   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
+
+
+
+Thaler                       Standards Track                   [Page 49]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+        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
+
+
+
+
+
+Thaler                       Standards Track                   [Page 50]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+        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).
+
+6.4.  Sequential Port-Symmetric NAT Extension
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thaler                       Standards Track                   [Page 51]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+   Teredo                 A's      A's            B's
+   Client               Primary  Secondary      Teredo          Client
+      A        NAT      Server    Server        Server   NAT       B
+      |         |          |        |              |      |        |
+      | Direct Bubble to B |        |              |      |        |
+    1 |-------------------------------------------------->|        |
+      |         |          |        |              |      |        |
+      |Router Solicitation |        |              |      |        |
+    2 |------------------->|        |              |      |        |
+      |         |          |        |              |      |        |
+      |Router Advertisement|        |              |      |        |
+      |<-------------------| 3      |              |      |        |
+      |         |          |        |              |      |        |
+    4 | Direct Bubble to B |        |              |      |        |
+      |-------------------------------------------------->|        |
+      |         |          |        |              |      |        |
+      |  Router Solicitation        |              |      |        |
+    5 |---------------------------->|              |      |        |
+      |         |          |        |              |      |        |
+      |  Router Advertisement       |              |      |        |
+      |<----------------------------| 6            |      |        |
+      |         |          |        |              |      |        |
+      | Indirect Bubble to B via B's Teredo Server |      |        |
+    7 |------------------------------------------->|-------------->|
+      |         |          |        |              |      |        |
+      |         |          |        |         Direct Bubble to A   |
+      |         |<-------------------------------------------------| 8
+      |         |          |        |              |      |        |
+      |         |          |        |       Indirect Bubble to A   |
+      |<-------------------|<--------------------------------------| 9
+      |         |          |        |              |      |        |
+      |         |          |        |         Direct Bubble to A   |
+      |<-----------------------------------------------------------| 10
+      |         |          |        |              |      |        |
+      |   Direct Bubble to B        |              |      |        |
+   11 |----------------------------------------------------------->|
+
+               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
+
+
+
+Thaler                       Standards Track                   [Page 52]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+       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.
+
+
+
+
+Thaler                       Standards Track                   [Page 53]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+       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).
+
+6.5.  Hairpinning Extension
+
+   The following protocol example illustrates the use of the Hairpinning
+   Extension.
+
+   In Figure 3 (Section 3.5), 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 Section 5.2.1 of [RFC4380].
+
+   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.
+
+
+
+
+
+Thaler                       Standards Track                   [Page 54]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+   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 |-------------------------------------->|        |           |
+      |        |         |           |        |        |           |
+      |       Indirect Bubble to B via B's Teredo Server           |
+    2 |----------------------------------------------------------->|
+      |        |         |<----------------------------------------|
+      |        |         |           |        |        |           |
+      |        |         | Direct Bubble to A |        |           |
+    3 |        |         |------------------->|        |           |
+      |        |         |           |        |        |           |
+      |        |         |  Direct   |        |        |           |
+      |        |         |Bubble to A|        |        |           |
+    4 |        |         |---------->|        |        |           |
+      |        |         |           |        |        |           |
+      |        |         |  Direct   |        |        |           |
+      |        |         |Bubble to A|        |        |           |
+    5 |        |         |---------->|        |        |           |
+      |<-----------------------------|        |        |           |
+      |        |         |           |        |        |           |
+      |        |         |    Indirect Bubble to A     |           |
+    6 |        |         |---------------------------->|           |
+      |<-----------------------------------------------|           |
+      |        |         |           |        |        |           |
+      |Direct Bubble to B|           |        |        |           |
+    7 |----------------->|           |        |        |           |
+      |        |         |           |        |        |           |
+
+                     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.
+
+
+
+
+
+Thaler                       Standards Track                   [Page 55]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+   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 Section 5.2
+        of [RFC4380].  Also, the mapped address status field (as
+        specified in Section 5.2.3 of [RFC4380]) 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.
+
+
+
+
+Thaler                       Standards Track                   [Page 56]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+   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).
+
+6.6.  Server Load Reduction Extension
+
+   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 |------------------------------------------------------------>|
+      |         |        |                       |         |        |
+      |         |        |  Direct Bubble to A   |         |        |
+      |<------------------------------------------------------------| 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.
+
+
+
+
+
+
+Thaler                       Standards Track                   [Page 57]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+   3.  The aforementioned direct bubble is received by A and at this
+       point, communication between the Teredo clients is re-
+       established.
+
+7.  Security Considerations
+
+   Security considerations are the same as those specified in Section 7
+   of [RFC4380].
+
+   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, Section 4.3 explicitly limits the number of addresses that a
+   Teredo client will accept.
+
+   Because the nonce in the Nonce Trailer is used (as specified in
+   Section 5.2.4.4) 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 [RFC4086]
+   for further discussion of randomness requirements.
+
+8.  Acknowledgements
+
+   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.
+
+9.  IANA Considerations
+
+   IANA has created a new trailer Type registry.  Requests for new
+   trailer Type values are made through Specification Required
+   [RFC5226].  Initial values are listed below.
+
+   Trailer Type  Usage                              Reference
+   ------------  ---------------------------------  ---------
+      0x01       Nonce Trailer                      RFC 6081
+      0x02       Random Port Trailer                RFC 6081
+      0x03       Alternate Address Trailer          RFC 6081
+      0x04       Neighbor Discovery Option Trailer  RFC 6081
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC1918]    Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G.,
+                and E. Lear, "Address Allocation for Private Internets",
+                BCP 5, RFC 1918, February 1996.
+
+
+
+Thaler                       Standards Track                   [Page 58]
+
+RFC 6081                    Teredo Extensions               January 2011
+
+
+   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2460]    Deering, S. and R. Hinden, "Internet Protocol, Version 6
+                (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC4380]    Huitema, C., "Teredo: Tunneling IPv6 over UDP through
+                Network Address Translations (NATs)", RFC 4380,
+                February 2006.
+
+   [RFC4861]    Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
+                "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
+                September 2007.
+
+   [RFC5226]    Narten, T. and H. Alvestrand, "Guidelines for Writing an
+                IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+                May 2008.
+
+   [UPNPWANIP]  UPnP Forum, "WANIPConnection:1", November 2001,
+                <http://www.upnp.org/standardizeddcps/documents/
+                UPnP_IGD_WANIPConnection%201.0.pdf>.
+
+10.2.  Informative References
+
+   [RFC4086]    Eastlake, D., Schiller, J., and S. Crocker, "Randomness
+                Requirements for Security", BCP 106, RFC 4086,
+                June 2005.
+
+   [RFC4443]    Conta, A., Deering, S., and M. Gupta, "Internet Control
+                Message Protocol (ICMPv6) for the Internet Protocol
+                Version 6 (IPv6) Specification", RFC 4443, March 2006.
+
+   [RFC4787]    Audet, F. and C. Jennings, "Network Address Translation
+                (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
+                RFC 4787, 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]
+