tech-invite   World Map     

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

RFC 6081

 
 
 

Teredo Extensions

Part 2 of 3, p. 22 to 42
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 22 
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;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



(page 42 continued on part 3)

Next RFC Part