tech-invite   World Map     

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

RFC 6081

 
 
 

Teredo Extensions

Part 3 of 3, p. 42 to 59
Prev RFC Part

 


prevText      Top      Up      ToC       Page 42 
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.

Top      Up      ToC       Page 43 
   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

Top      Up      ToC       Page 44 
   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).

Top      Up      ToC       Page 45 
   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).

Top      Up      ToC       Page 46 
   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

Top      Up      ToC       Page 47 
       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.

Top      Up      ToC       Page 48 
   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.

Top      Up      ToC       Page 49 
   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

Top      Up      ToC       Page 50 
        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

Top      Up      ToC       Page 51 
        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.

Top      Up      ToC       Page 52 
   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

Top      Up      ToC       Page 53 
       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.

Top      Up      ToC       Page 54 
       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.

Top      Up      ToC       Page 55 
   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.

Top      Up      ToC       Page 56 
   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.

Top      Up      ToC       Page 57 
   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.

Top      Up      ToC       Page 58 
   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.

Top      Up      ToC       Page 59 
   [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