5.  Specification of Clients, Servers, and Relays

   The Teredo service is realized by having clients interact with Teredo
   servers through the Teredo service protocol.  The clients will also
   receive IPv6 packets through Teredo relays.  The client behavior is
   specified in Section 5.2.

   The Teredo server is designed to be stateless.  It waits for Teredo
   requests and for IPv6 packets on the Teredo UDP port; it processes
   the requests by sending a response to the appropriate address and
   port; it forwards some Teredo IPv6 packets to the appropriate IPv4
   address and UDP port, or to native IPv6 peers of Teredo clients.  The
   precise behavior of the server is specified in Section 5.3.

   The Teredo relay advertises reachability of the Teredo service prefix
   over IPv6.  The scope of advertisement may be the entire Internet or
   a smaller subset such as an ISP network or an IPv6 site; it may even
   be as small as a single host in the case of "local relays".  The
   relay forwards Teredo IPv6 packets to the appropriate IPv4 address
   and UDP port.  The relay behavior is specified in Section 5.4.

   Teredo clients, servers, and relays must implement the sunset
   procedure defined in Section 5.5.

5.1.  Message Formats

5.1.1.  Teredo IPv6 Packet Encapsulation

   Teredo IPv6 packets are transmitted as UDP packets [RFC768] within
   IPv4 [RFC791].  The source and destination IP addresses and UDP ports
   take values that are specified in this section.  Packets can come in
   one of two formats, simple encapsulation and encapsulation with
   origin indication.

   When simple encapsulation is used, the packet will have a simple
   format, in which the IPv6 packet is carried as the payload of a UDP
   datagram:

   +------+-----+-------------+
   | IPv4 | UDP | IPv6 packet |
   +------+-----+-------------+

   When relaying some packets received from third parties, the server
   may insert an origin indication in the first bytes of the UDP
   payload:

   +------+-----+-------------------+-------------+
   | IPv4 | UDP | Origin indication | IPv6 packet |
   +------+-----+-------------------+-------------+

   The origin indication encapsulation is an 8-octet element, with the
   following content:

   +--------+--------+-----------------+
   |  0x00  | 0x00   | Origin port #   |
   +--------+--------+-----------------+
   |  Origin IPv4 address              |
   +-----------------------------------+

   The first two octets of the origin indication are set to a null
   value; this is used to discriminate between the simple encapsulation,
   in which the first 4 bits of the packet contain the indication of the
   IPv6 protocol, and the origin indication.

   The following 16 bits contain the obfuscated value of the port number
   from which the packet was received, in network byte order.  The next
   32 bits contain the obfuscated IPv4 address from which the packet was
   received, in network byte order.  In this format, both the original
   "IPv4 address" and "UDP port" of the client are obfuscated.  Each bit
   in the address and port number is reversed; this can be done by an
   exclusive OR of the 16-bit port number with the hexadecimal value
   0xFFFF, and an exclusive OR of the 32-bit address with the
   hexadecimal value 0xFFFFFFFF.

   For example, if the original UDP port number was 337 (hexadecimal
   0151) and original IPv4 address was 1.2.3.4 (hexadecimal 01020304),
   the origin indication would contain the value "0000FEAEFEFDFCFB".

   When exchanging Router Solicitation (RS) and Router Advertisement
   (RA) messages between a client and its server, the packets may
   include an authentication parameter:

   +------+-----+----------------+-------------+
   | IPv4 | UDP | Authentication | IPv6 packet |
   +------+-----+----------------+-------------+

   The authentication encapsulation is a variable-length element,
   containing a client identifier, an authentication value, a nonce
   value, and a confirmation byte.

   +--------+--------+--------+--------+
   |  0x00  | 0x01   | ID-len | AU-len |
   +--------+--------+--------+--------+
   |  Client identifier (ID-len        |
   +-----------------+-----------------+
   |  octets)        |  Authentication |
   +-----------------+--------+--------+
   | value (AU-len octets)    | Nonce  |
   +--------------------------+--------+
   | value (8 octets)                  |
   +--------------------------+--------+
   |                          | Conf.  |
   +--------------------------+--------+

   The first octet of the authentication encapsulation is set to a null
   value, and the second octet is set to the value 1; this enables
   differentiation from IPv6 packets and from origin information
   indication encapsulation.  The third octet indicates the length in
   bytes of the client identifier; the fourth octet indicates the length
   in bytes of the authentication value.  The computation of the
   authentication value is specified in Section 5.2.2. The
   authentication value is followed by an 8-octet nonce, and by a
   confirmation byte.

   Both ID-len and AU-len can be set to null values if the server does
   not require an explicit authentication of the client.

   Authentication and origin indication encapsulations may sometimes be
   combined, for example, in the RA responses sent by the server.  In
   this case, the authentication encapsulation MUST be the first element
   in the UDP payload:

   +------+-----+----------------+--------+-------------+
   | IPv4 | UDP | Authentication | Origin | IPv6 packet |
   +------+-----+----------------+--------+-------------+

5.1.2.  Maximum Transmission Unit

   Since Teredo uses UDP as an underlying transport, a Teredo Maximum
   Transmission Unit (MTU) could potentially be as large as the payload
   of the largest valid UDP datagram (65507 bytes).  However, since
   Teredo packets can travel on unpredictable paths over the Internet,
   it is best to contain this MTU to a small size, in order to minimize
   the effect of IPv4 packet fragmentation and reassembly.  The default
   link MTU assumed by a host, and the link MTU supplied by a Teredo
   server during router advertisement SHOULD normally be set to the
   minimum IPv6 MTU size of 1280 bytes [RFC2460].

   Teredo implementations SHOULD NOT set the Don't Fragment (DF) bit of
   the encapsulating IPv4 header.

5.2.  Teredo Client Specification

   Before using the Teredo service, the client must be configured with:

   - the IPv4 address of a server.
   - a secondary IPv4 address of that server.

   If secure discovery is required, the client must also be configured
   with:

   - a client identifier,
   - a secret value, shared with the server,
   - an authentication algorithm, shared with the server.

   A Teredo client expects to exchange IPv6 packets through a UDP port,
   the Teredo service port.  To avoid problems when operating behind a
   "port conserving" NAT, different clients operating behind the same
   NAT should use different service port numbers.  This can be achieved
   through explicit configuration or, in the absence of configuration,
   by picking the service port number at random.

   The client will maintain the following variables that reflect the
   state of the Teredo service:

   - Teredo connectivity status,
   - Mapped address and port number associated with the Teredo service
     port,
   - Teredo IPv6 prefix associated with the Teredo service port,
   - Teredo IPv6 address or addresses derived from the prefix,
   - Link local address,
   - Date and time of the last interaction with the Teredo server,
   - Teredo Refresh Interval,
   - Randomized Refresh Interval,
   - List of recent Teredo peers.

   Before sending any packets, the client must perform the Teredo
   qualification procedure, which determines the Teredo connectivity
   status, the mapped address and port number, and the Teredo IPv6
   prefix.  It should then perform the cone NAT determination procedure,
   which determines the cone NAT status and may alter the value of the
   prefix.  If the qualification is successful, the client may use the
   Teredo service port to transmit and receive IPv6 packets, according
   to the transmission and reception procedures.  These procedures use
   the "list of recent peers".  For each peer, the list contains:

   - The IPv6 address of the peer,
   - The mapped IPv4 address and mapped UDP port of the peer,
   - The status of the mapped address, i.e., trusted or not,
   - The value of the last nonce sent to the peer,
   - The date and time of the last reception from the peer,
   - The date and time of the last transmission to the peer,
   - The number of bubbles transmitted to the peer.

   The list of peers is used to enable the transmission of IPv6 packets
   by using a "direct path" for the IPv6 packets.  The list of peers
   could grow over time.  Clients should implement a list management
   strategy, for example, deleting the least recently used entries.
   Clients should make sure that the list has a sufficient size, to
   avoid unnecessary exchanges of bubbles.

   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.

   In order to avoid triangle routing for stations that are located
   behind the same NAT, the Teredo clients MAY use the optional local
   client discovery procedure defined in Section 5.2.8. Using this
   procedure will also enhance connectivity when the NAT cannot do
   "hairpin" routing, i.e., cannot redirect a packet sent from one
   internal host to the mapped address and port of another internal
   host.

5.2.1.  Qualification Procedure

   The purposes of the qualification procedure are to establish the
   status of the local IPv4 connection and to determine the Teredo IPv6
   client prefix of the local Teredo interface.  The procedure starts
   when the service is in the "initial" state, and it results in a
   "qualified" state if successful, and in an "off-line" state if
   unsuccessful.

          /---------\
          | Initial |
          \---------/
               |
          +----+----------+
          | Set ConeBit=1 |
          +----+----------+
               |
               +<-------------------------------------------+
               |                                            |
          +----+----+                                       |
          | Start   |<------+                               |
          +----+----+       |                    +----------+----+
               |            |                    | Set ConeBit=0 |
               v            |                    +----------+----+
          /---------\ Timer | N                             ^
          |Starting |-------+ attempts /----------------\Yes|
          \---------/----------------->| ConeBit == 1 ? |---+
               | Response              \----------------/
               |                              | No
               V                              V
        /---------------\ Yes            /----------\
        | ConeBit == 1? |-----+          | Off line |
        \---------------/     |          \----------/
            No |              v
               |         /----------\
               |         | Cone NAT |
         +-----+-----+   \----------/
         | New Server|
         +-----+-----+
               |
          +----+----+
          | Start   |<------+
          +----+----+       |
               |            |
               v            |
          /---------\ Timer |
          |Starting |-------+ N attempts /----------\
          \---------/------------------->| Off line |
               | Response                \----------/
               |
               V

         /------------\ No      /---------------\
         | Same port? |-------->| Symmetric NAT |
         \------------/         \---------------/
               | Yes
               V
          /----------------------\
          | Restricted Cone NAT  |
          \----------------------/

   Initially, the Teredo connectivity status is set to "Initial".

   When the interface is initialized, the system first performs the
   "start action" by sending a Router Solicitation message, as defined
   in [RFC2461].  The client picks a link-local address and uses it as
   the IPv6 source of the message; the cone bit in the address is set to
   1 (see Section 4 for the address format); the IPv6 destination of the
   RS is the all-routers multicast address; the packet will be sent over
   UDP from the service port to the Teredo server's IPv4 address and
   Teredo UDP port.  The connectivity status moves then to "Starting".

   In the starting state, the client waits for a router advertisement
   from the Teredo server.  If no response comes within a time-out T,
   the client should repeat the start action, by resending the Router
   Solicitation message.  If no response has arrived after N
   repetitions, the client concludes that it is not behind a cone NAT.
   It sets the cone bit to 0, and repeats the procedure.  If after N
   other timer expirations and retransmissions there is still no
   response, the client concludes that it cannot use UDP, and that the
   Teredo service is not available; the status is set to "Off-line".  In
   accordance with [RFC2461], the default time-out value is set to T=4
   seconds, and the maximum number of repetitions is set to N=3.

   If a response arrives, the client checks that the response contains
   an origin indication and a valid router advertisement as defined in
   [RFC2461], that the IPv6 destination address is equal to the link-
   local address used in the router solicitation, and that the router
   advertisement contains exactly one advertised Prefix Information
   option.  This prefix should be a valid Teredo IPv6 server prefix: the
   first 32 bits should contain the global Teredo IPv6 service prefix,
   and the next 32 bits should contain the server's IPv4 address.  If
   this is the case, the client learns the Teredo mapped address and
   Teredo mapped port from the origin indication.  The IPv6 source
   address of the Router Advertisement is a link-local server address of
   the Teredo server.  (Responses that are not valid advertisements are
   simply discarded.)

   If the client has received an RA with the cone bit in the IPv6
   destination address set to 1, it is behind a cone NAT and is fully
   qualified.  If the RA is received with the cone bit set to 0, the
   client does not know whether the local NAT is restricted or
   symmetric.  The client selects the secondary IPv4 server address, and
   repeats the procedure, the cone bit remaining to the value zero.  If
   the client does not receive a response, it detects that the service
   is not usable.  If the client receives a response, it compares the
   mapped address and mapped port in this second response to the first
   received values.  If the values are different, the client detects a
   symmetric NAT: it cannot use the Teredo service.  If the values are
   the same, the client detects a port-restricted or restricted cone
   NAT: the client is qualified to use the service.  (Teredo operates
   the same way for restricted and port-restricted NAT.)

   If the client is qualified, it builds a Teredo IPv6 address using the
   Teredo IPv6 server prefix learned from the RA and the obfuscated
   values of the UDP port and IPv4 address learned from the origin
   indication.  The cone bit should be set to the value used to receive
   the RA, i.e., 1 if the client is behind a cone NAT, 0 otherwise.  The
   client can start using the Teredo service.

5.2.2.  Secure Qualification

   The client may be required to perform secured qualification.  The
   client will perform exactly the algorithm described in Section 5.2.1,
   but it will incorporate an authentication encapsulation in the UDP
   packet carrying the router solicitation message, and it will verify
   the presence of a valid authentication parameter in the UDP message
   that carries the router advertisement provided by the sender.

   In these packets, the nonce value is chosen by the client, and is
   repeated in the response from the server; the client identifier is a
   value with which the client was configured.

   A first level of protection is provided by just checking that the
   value of the nonce in the response matches the value initially sent
   by the client.  If they don't match, the packet MUST be discarded.
   If no other protection is used, the authentication payload does not
   contain any identifier or authentication field; the ID-len and AU-len
   fields are set to a null value.  When stronger protection is
   required, the authentication payload contains the identifier and
   location fields, as explained in the following paragraphs.

   The confirmation byte is set to 0 by the client.  A null value
   returned by the server indicates that the client's key is still
   valid; a non-null value indicates that the client should obtain a new
   key.

   When stronger authentication is provided, the client and the server
   are provisioned with a client identifier, a shared secret, and the
   identification of an authentication algorithm.  Before transmission,
   the authentication value is computed according to the specified
   algorithm; on reception, the same algorithm is used to compute a
   target value from the content of the receive packet.  The receiver
   deems the authentication successful if the two values match.  If they
   don't, the packet MUST be discarded.

   To maximize interoperability, this specification defines a default
   algorithm in which the authentication value is computed according the
   HMAC specification [RFC2104] and the SHA1 function [FIPS-180].
   Clients and servers may agree to use HMAC combined with a different
   function, or to use a different algorithm altogether, such as for
   example AES-XCBC-MAC-96 [RFC3566].

   The default authentication algorithm is based on the HMAC algorithm
   according to the following specifications:

   - the hash function shall be the SHA1 function [FIPS-180].
   - the secret value shall be the shared secret with which the client
     was configured.

   The clear text to be protected includes:

   - the nonce value,
   - the confirmation byte,
   - the origin indication encapsulation, if it is present,
   - the IPv6 packet.

   The HMAC procedure is applied to the concatenation of these four
   components, without any additional padding.

5.2.3.  Packet Reception

   The Teredo client receives packets over the Teredo interface.  The
   role of the packet reception procedure, besides receiving packets, is
   to maintain the date and time of the last interaction with the Teredo
   server and the "list of recent peers".

   When a UDP packet is received over the Teredo service port, the
   Teredo client checks that it is encoded according to the packet
   encoding rules defined in Section 5.1.1, and that it contains either
   a valid IPv6 packet or the combination of a valid origin indication
   encapsulation and a valid IPv6 packet, possibly protected by a valid
   authentication encapsulation.  If this is not the case, the packet is
   silently discarded.

   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 to its own Teredo
   address.

   Then, the Teredo client examines the IPv4 source address and UDP port
   number from which the packet is received.  If these values match the
   IPv4 address of the server and the Teredo port, the client updates
   the "date and time of the last interaction with the Teredo server" to
   the current date and time; if an origin indication is present, the
   client should perform the "direct IPv6 connectivity test" described
   in Section 5.2.9.

   If the IPv4 source address and UDP port number are different from the
   IPv4 address of the server and the Teredo port, the client examines
   the IPv6 source address of the packet:

   1) If there is an entry for the source IPv6 address in the list of
   peers whose status is trusted, the client compares the mapped IPv4
   address and mapped port in the entry with the source IPv4 address and
   source port of the packet.  If the values match, the packet is
   accepted; the date and time of the last reception from the peer is
   updated.

   2) If there is an entry for the source IPv6 address in the list of
   peers whose status is not trusted, the client checks whether the
   packet is an ICMPv6 echo reply.  If this is the case, and if the
   ICMPv6 data of the reply matches the nonce stored in the peer entry,
   the packet should be accepted; the status of the entry should be
   changed to "trusted", the mapped IPv4 and mapped port in the entry
   should be set to the source IPv4 address and source port from which
   the packet was received, and the date and time of the last reception
   from the peer should be updated.  Any packet queued for this IPv6
   peer (as specified in Section 5.2.4) should be de-queued and
   forwarded to the newly learned IPv4 address and UDP port.

   3) If the source IPv6 address is a Teredo address, the client
   compares the mapped IPv4 address and mapped port in the source
   address with the source IPv4 address and source port of the packet.
   If the values match, the client MUST create a peer entry for the IPv6
   source address in the list of peers; it should update the entry if
   one already existed; the mapped IPv4 address and mapped port in the
   entry should be set to the value from which the packet was received,
   and the status should be set to "trusted".  If a new entry is
   created, the last transmission date is set to 30 seconds before the
   current date, and the number of bubbles to zero.  If the packet is a

   bubble, it should be discarded after this processing; otherwise, the
   packet should be accepted.  In all cases, the client must de-queue
   and forward any packet queued for that destination.

   4) If the IPv4 destination address through which the packet was
   received is the Teredo IPv4 Discovery Address, the source address is
   a valid Teredo address, and the destination address is the "all nodes
   on link" multicast address, the packet should be treated as a local
   discovery bubble.  If no local entry already existed for the source
   address, a new one is created, but its status is set to "not
   trusted".  The client SHOULD reply with a unicast Teredo bubble, sent
   to the source IPv4 address and source port of the local discovery
   bubble; the IPv6 source address of the bubble will be set to local
   Teredo IPv6 address; the IPv6 destination address of the bubble
   should be set to the IPv6 source address of the local discovery
   bubble.  (Clients that do not implement the optional local discovery
   procedure will not process local discovery bubbles.)

   5) If the source IPv6 address is a Teredo address, and the mapped
   IPv4 address and mapped port in the source address do not match the
   source IPv4 address and source port of the packet, the client checks
   whether there is an existing "local" entry for that IPv6 address.  If
   there is such an entry, and if the local IPv4 address and local port
   indicated in that entry match the source IPv4 address and source

   port of the packet, the client updates the "local" entry, whose
   status should be set to "trusted".  If the packet is a bubble, it
   should be discarded after this processing; otherwise, the packet
   should be accepted.  In all cases, the client must de-queue and
   forward any packet queued for that destination.

   6) In the other cases, the packet may be accepted, but the client
   should be conscious that the source address may be spoofed; before
   processing the packet, the client should perform the "direct IPv6
   connectivity test" described in Section 5.2.9.

   Whatever the IPv4 source address and UDP source port, the client that
   receives an IPv6 packet MAY send a Teredo bubble towards that target,
   as specified in Section 5.2.6.

5.2.4.  Packet Transmission

   When a Teredo client has to transmit a packet over a Teredo
   interface, it examines the destination IPv6 address.  The client
   checks first if there is an entry for this IPv6 address in the list
   of recent Teredo peers, and if the entry is still valid: an entry
   associated with a local peer is valid if the last reception date and
   time associated with that list entry is less that 30 seconds from the

   current time; an entry associated with a non-local peer is valid if
   the last reception date and time associated with that list entry is
   less that 30 seconds from the current time.  (Local peer entries can
   only be present if the client uses the local discovery procedure
   discussed in Section 5.2.8.)

   The client then performs the following:

   1) If there is an entry for that IPv6 address in the list of peers,
   and if the status of the entry is set to "trusted", the IPv6 packet
   should be sent over UDP to the IPv4 address and UDP port specified in
   the entry.  The client updates the date of last transmission in the
   peer entry.

   2) If the destination is not a Teredo IPv6 address, the packet is
   queued, and the client performs the "direct IPv6 connectivity test"
   described in Section 5.2.9. The packet will be de-queued and
   forwarded if this procedure completes successfully.  If the direct
   IPv6 connectivity test fails to complete within a 2-second time-out,
   it should be repeated up to 3 times.

   3) If the destination is the Teredo IPv6 address of a local peer
   (i.e., a Teredo address from which a local discovery bubble has been
   received in the last 600 seconds), the packet is queued.  The client
   sends a unicast Teredo bubble to the local IPv4 address and local
   port specified in the entry, and a local Teredo bubble to the Teredo
   IPv4 discovery address.

   4) If the destination is a Teredo IPv6 address in which the cone bit
   is set to 1, the packet is sent over UDP to the mapped IPv4 address
   and mapped UDP port extracted from that IPv6 address.

   5) If the destination is a Teredo IPv6 address in which the cone bit
   is set to 0, the packet is queued.  If the client is not located
   behind a cone NAT, it sends a direct bubble to the Teredo
   destination, i.e., to the mapped IP address and mapped port of the
   destination.  In all cases, the client sends an indirect bubble to
   the Teredo destination, sending it over UDP to the server address and
   to the Teredo port.  The packet will be de-queued and forwarded when
   the client receives a bubble or another packet directly from this
   Teredo peer.  If no bubble is received within a 2-second time-out,
   the bubble transmission should be repeated up to 3 times.

   In cases 4 and 5, before sending a packet over UDP, the client MUST
   check that the IPv4 destination address is in the format of a global
   unicast address; if this is not the case, the packet MUST be silently

   discarded.  (Note that a packet can legitimately be sent to a non-
   global unicast address in case 1, as a result of the local discovery
   procedure.)

   The global unicast address check is designed to thwart a number of
   possible attacks in which an attacker tries to use a Teredo host to
   attack either a single local IPv4 target or a set of such targets.
   For the purpose of this specification, and IPv4 address is deemed to
   be a global unicast address if it does not belong to or match:

   - the "local" subnet 0.0.0.0/8,
   - the "loopback" subnet 127.0.0.0/8,
   - the local addressing ranges 10.0.0.0/8,
   - the local addressing ranges 172.16.0.0/12,
   - the local addressing ranges 192.168.0.0/16,
   - the link local block 169.254.0.0/16,
   - the block reserved for 6to4 anycast addresses 192.88.99.0/24,
   - the multicast address block 224.0.0.0/4,
   - the "limited broadcast" destination address 255.255.255.255,
   - the directed broadcast addresses corresponding to the subnets to
     which the host is attached.

   A list of special-use IPv4 addresses is provided in [RFC3330].

   For reliability reasons, clients MAY decide to ignore the value of
   the cone bit in the flag, skip the "case 4" test and always perform
   the "case 5", i.e., treat all Teredo peers as if they were located
   behind non-cone NAT.  This will result in some increase in traffic,
   but may avoid reliability issues if the determination of the NAT
   status was for some reason erroneous.  For the same reason, clients
   MAY also decide to always send a direct bubble in case 5, even if
   they do not believe that they are located behind a non-cone NAT.

5.2.5.  Maintenance

   The Teredo client must ensure that the mappings that it uses remain
   valid.  It does so by checking that packets are regularly received
   from the Teredo server.

   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;
   the client should use the same value of the cone bit that resulted in
   the reception of an RA during the qualification procedure.

   When the router advertisement is received, the client SHOULD check
   its validity as specified in Section 5.2.1; invalid advertisements
   are silently discarded.  If the advertisement is valid, the client
   MUST check that the mapped address and port correspond to the current
   Teredo address.  If this is not the case, the mapping has changed;
   the client must mark the old address as invalid and start using the
   new address.

5.2.6.  Sending Teredo Bubbles

   The Teredo client may have to send a bubble towards another Teredo
   client, either after a packet reception or after a transmission
   attempt, as explained in Sections 5.2.3 and 5.2.4. There are two
   kinds of bubbles: direct bubbles, which are sent directly to the
   mapped IPv4 address and mapped UDP port of the peer, and indirect
   bubbles, which are sent through the Teredo server of the peer.

   When a Teredo client attempts to send a direct bubble, it extracts
   the mapped IPv4 address and mapped UDP port from the Teredo IPv6
   address of the target.  It then checks whether there is already an
   entry for this IPv6 address in the current list of peers.  If there
   is no entry, the client MUST create a new list entry for the address,
   setting the last reception date and the last transmission date to 30
   seconds before the current date, and the number of bubbles to zero.

   When a Teredo client attempts to send an indirect bubble, it extracts
   the Teredo server IPv4 address from the Teredo prefix of the IPv6
   address of the target (different clients may be using different
   servers); the bubble will be sent to that IPv4 address and the Teredo
   UDP port.

   Bubbles may be lost in transit, and it is reasonable to enhance the
   reliability of the Teredo service by allowing multiple transmissions;
   however, bubbles will also be lost systematically in certain NAT
   configurations.  In order to strike a balance between reliability and
   unnecessary retransmissions, we specify the following:

   - The client MUST NOT send a bubble if the last transmission date
     and time is less than 2 seconds before the current date and time;

   - The client MUST NOT send a bubble if it has already sent 4 bubbles
     to the peer in the last 300 seconds without receiving a direct
     response.

   In the other cases, the client MAY proceed with the transmission of
   the bubble.  When transmitting the bubble, the client MUST update the
   last transmission date and time to that peer, and must also increment
   the number of transmitted bubbles.

5.2.7.  Optional Refresh Interval Determination Procedure

   In addition to the regular client resources described in the
   beginning of this section, the refresh interval determination
   procedure uses an additional UDP port, the Teredo secondary port, and
   the following variables:

   - Teredo secondary connectivity status,
   - Mapped address and port number of the Teredo secondary port,
   - Teredo secondary IPv6 prefix associated with the secondary port,
   - Teredo secondary IPv6 address derived from this prefix,
   - Date and time of the last interaction on the secondary port,
   - Maximum Teredo Refresh Interval.
   - Candidate Teredo Refresh Interval.

   The secondary connectivity status, mapped address and prefix are
   determined by running the qualification procedure on the secondary
   port.  When the client uses the interval determination procedure, the
   qualification procedure MUST be run for the secondary port
   immediately after running it on the service port.  If the secondary
   qualification fails, the interval determination procedure will not be
   used, and the interval value will remain to the default value, 30
   seconds.  If the secondary qualification succeeds, the maximum
   refresh interval is set to 120 seconds, and the candidate Teredo
   refresh interval is set to 60 seconds, i.e., twice the Teredo refresh
   interval.  The procedure is then performed at regular intervals,
   until it concludes:

   1) wait until the candidate refresh interval is elapsed after the
      last interaction on the secondary port.

   2) send a Teredo bubble to the Teredo secondary IPv6 address, through
      the service port.

   3) wait for reception of the bubble on the secondary port.  If a
      timer of 2 seconds elapses without reception, repeat step 2 at
      most three times.  If there is still no reception, the candidate
      has failed; if there is a reception, the candidate has succeeded.

   4) if the candidate has succeeded, set the Teredo refresh interval to
      the candidate value, and set a new candidate value to the minimum
      of twice the new refresh interval, or the average of the refresh
      interval and the maximum refresh interval.

   5) if the candidate has failed, set the maximum refresh interval to
      the candidate value.  If the current refresh interval is larger
      than or equal to 75% of the maximum, the determination procedure
      has concluded; otherwise, set a new candidate value to the average
      of the refresh interval and the maximum refresh interval.

   6) if the procedure has not concluded, perform the maintenance
      procedure on the secondary port, which will reset the date and
      time of the last interaction on the secondary port, and may result
      in the allocation of a new Teredo secondary IPv6 address; this
      would not affect the values of the refresh interval, candidate
      interval, or maximum refresh interval.

   The secondary port MUST NOT be used for any other purpose than the
   interval determination procedure.  It should be closed when the
   procedure ends.

5.2.8.  Optional Local Client Discovery Procedure

   It is desirable to enable direct communication between Teredo clients
   that are located behind the same NAT, without forcing a systematic
   relay through a Teredo server.  It is hard to design a general
   solution to this problem, but we can design a partial solution when
   the Teredo clients are connected through IPv4 to the same link.

   A Teredo client who wishes to enable local discovery SHOULD join the
   IPv4 multicast group identified by Teredo IPv4 Discovery Address.
   The client SHOULD wait for discovery bubbles to be received on the
   Teredo IPv4 Discovery Address.  The client SHOULD send local
   discovery bubbles to the Teredo IPv4 Discovery Address at random
   intervals, uniformly distributed between 200 and 300 seconds.  A
   local Teredo bubble has the following characteristics:

   - IPv4 source address: the IPv4 address of the sender

   - IPv4 destination address: the Teredo IPv4 Discovery Address

   - IPv4 ttl: 1

   - UDP source port: the Teredo service port of the sender

   - UDP destination port: the Teredo UDP port

   - UDP payload: a minimal IPv6 packet, as follows

   - IPv6 source: the global Teredo IPv6 address of the sender

   - IPv6 destination: the all-nodes on-link multicast address

   - IPv6 payload type: 59 (No Next Header, as per [RFC2460])

   - IPv6 payload length: 0

   - IPv6 hop limit: 1

   The local discovery procedure carries a denial of service risk, as
   malevolent nodes could send fake bubbles to unsuspecting parties, and
   thus capture the traffic originating from these parties.  The risk is
   mitigated by the filtering rules described in Section 5.2.5, and also
   by "link only" multicast scope of the Teredo IPv4 Discovery Address,
   which implies that packets sent to this address will not be forwarded
   across routers.

   To benefit from the "link only multicast" protection, the clients
   should silently discard all local discovery bubbles that are received
   over a unicast address.  To further mitigate the denial of service
   risk, the client MUST silently discard all local discovery bubbles
   whose IPv6 source address is not a well-formed Teredo IPv6 address,
   or whose IPv4 source address does not belong to the local IPv4
   subnet; the client MAY decide to silently discard all local discovery
   bubbles whose Teredo IPv6 address do not include the same mapped IPv4
   address as its own.

   If the bubble is accepted, the client checks whether there is an
   entry in the list of recent peers that correspond to the mapped IPv4
   address and mapped UDP port associated with the source IPv6 address
   of the bubble.  If there is such an entry, the client MUST update the
   local peer address and local peer port parameters to reflect the IPv4
   source address and UDP source port of the bubble.  If there is no
   entry, the client MUST create one, setting the local peer address and
   local peer port parameters to reflect the IPv4 source address and UDP
   source port of the bubble, the last reception date to the current
   date and time, the last transmission date to 30 seconds before the
   current date, and the number of bubbles to zero.  The state of the
   entry is set to "not trusted".

   Upon reception of a discovery bubble, clients reply with a unicast
   bubble as specified in Section 5.2.3.

5.2.9.  Direct IPv6 Connectivity Test

   The Teredo procedures are designed to enable direct connections
   between a Teredo host and a Teredo relay.  Teredo hosts located
   behind a cone NAT will receive packets directly from relays; other
   Teredo hosts will learn the original addresses and UDP ports of third
   parties through the local Teredo server.  In all of these cases,
   there is a risk that the IPv6 address of the source will be spoofed

   by a malevolent party.  Teredo hosts must make two decisions, whether
   to accept the packet for local processing and whether to transmit
   further packets to the IPv6 address through the newly

   learned IPv4 address and UDP port.  The basic rule is that the hosts
   should be generous in what they accept and careful in what they send.
   Refusing to accept packets due to spoofing concerns would compromise
   connectivity and should only be done when there is a near certainty
   that the source address is spoofed.  On the other hand, sending
   packets to the wrong address should be avoided.

   When the client wants to send a packet to a native IPv6 node or a
   6to4 node, it should check whether a valid peer entry already exists
   for the IPv6 address of the destination.  If this is not the case,
   the client will pick a random number (a nonce) and format an ICMPv6
   Echo Request message whose source is the local Teredo address, whose
   destination is the address of the IPv6 node, and whose Data field is
   set to the nonce.  (It is recommended to use a random number at least
   64 bits long.)  The nonce value and the date at which the packet was
   sent will be documented in a provisional peer entry for the IPV6
   destination.  The ICMPv6 packet will then be sent encapsulated in a
   UDP packet destined to the Teredo server IPv4 address and to the
   Teredo port.  The rules of Section 5.2.3 specify how the reply to
   this packet will be processed.

5.2.10.  Working around symmetric NAT

   The client procedures are designed to enable IPv6 connectivity
   through the most common types of NAT, which are commonly called "cone
   NAT" and "restricted cone NAT" [RFC3489].  Some NATs employ a
   different design; they are often called "symmetric NAT".  The
   qualification algorithm in Section 5.2.1 will not succeed when the
   local NAT is a symmetric NAT.

   In many cases, it is possible to work around the limitations of these
   NATs by explicitly reserving a UDP port for Teredo service on a
   client, using a function often called "DMZ" in the NAT's manual.
   This port will become the "service port" used by the Teredo hosts.
   The implementers of Teredo functions in hosts must make sure that the
   value of the service port can be explicitly provisioned, so that the
   user can provision the same value in the host and in the NAT.

   The reservation procedure guarantees that the port mapping will
   remain the same for all destinations.  After the explicit
   reservation, the qualification algorithm in Section 5.2.1 will
   succeed, and the Teredo client will behave as if behind a "cone NAT".

   When different clients use Teredo behind a single symmetric NAT, each
   of these clients must reserve and use a different service port.

5.3.  Teredo Server Specification

   The Teredo server is designed to be stateless.  The Teredo server
   waits for incoming UDP packets at the Teredo Port, using the IPv4
   address that has been selected for the service.  In addition, the
   server is able to receive and transmit some packets using a different
   IPv4 address and a different port number.

   The Teredo server acts as an IPv6 router.  As such, it will receive
   Router Solicitation messages, to which it will respond with Router
   Advertisement messages as explained in Section 5.3.2.  It may also
   receive other packets, for example, ICMPv6 messages and Teredo
   bubbles, which are processed according to the IPv6 specification.

   By default, the routing functions of the Teredo server are limited.
   Teredo servers are expected to relay Teredo bubbles, ICMPv6 Echo
   requests, and ICMPv6 Echo replies, but they are not expected to relay
   other types of IPv6 packets.  Operators may, however, decide to
   combine the functions of "Teredo server" and "Teredo relay", as
   explained in Section 5.4.

5.3.1.  Processing of Teredo IPv6 Packets

   Before processing the packet, the Teredo server MUST check the
   validity of the encapsulated IPv6 source address, the IPv4 source
   address, and the UDP source port:

   1)  If the UDP content is not a well-formed Teredo IPv6 packet, as
   defined in Section 5.1.1, the packet MUST be silently discarded.

   2)  If the UDP packet is not a Teredo bubble or an ICMPv6 message, it
   SHOULD be discarded.  (The packet may be processed if the Teredo
   server also operates as a Teredo relay, as explained in Section 5.4.)

   3)  If the IPv4 source address is not in the format of a global
   unicast address, the packet MUST be silently discarded (see Section
   5.2.4 for a definition of global unicast addresses).

   4)  If the IPv6 source address is an IPv6 link-local address, the
   IPv6 destination address is the link-local scope all routers
   multicast address (FF02::2), and the packet contains an ICMPv6 Router
   Solicitation message, the packet MUST be accepted.  It MUST be
   discarded if the server requires secure qualification and the
   authentication encapsulation is absent or verification fails.

   5)  If the IPv6 source address is a Teredo IPv6 address, and if the
   IPv4 address and UDP port embedded in that address match the IPv4
   source address and UDP source port, the packet SHOULD be accepted.

   6)  If the IPv6 source address is not a Teredo IPv6 address, and if
   the IPv6 destination address is a Teredo address allocated through
   this server, the packet SHOULD be accepted.

   7)  In all other cases, the packet MUST be silently discarded.

   The Teredo server will then check the IPv6 destination address of the
   encapsulated IPv6 packet:

   If the IPv6 destination address is the link-local scope all routers
   multicast address (FF02::2), or the link-local address of the server,
   the Teredo server processes the packet; it may have to process Router
   Solicitation messages and ICMPv6 Echo Request messages.

   If the destination IPv6 address is not a global scope IPv6 address,
   the packet MUST NOT be forwarded.

   If the destination address is not a Teredo IPv6 address, the packet
   should be relayed to the IPv6 Internet using regular IPv6 routing.

   If the IPv6 destination address is a valid Teredo IPv6 address as
   defined in Section 2.13, the Teredo Server MUST check that the IPv4
   address derived from this IPv6 address is in the format of a global
   unicast address; if this is not the case, the packet MUST be silently
   discarded.

   If the address is valid, the Teredo server encapsulates the IPv6
   packet in a new UDP datagram, in which the following parameters are
   set:

   - The destination IPv4 address is derived from the IPv6 destination.

   - The source IPv4 address is the Teredo server IPv4 address.

   - The destination UDP port is derived from the IPv6 destination.

   - The source UDP port is set to the Teredo UDP Port.

   If the destination IPv6 address is a Teredo client whose address is
   serviced by this specific server, the server should insert an origin
   indication in the first bytes of the UDP payload, as specified in
   Section 5.1.1.  (To verify that the client is served by this server,
   the server compares bits 32-63 of the client's Teredo IPv6 address to
   the server's IPv4 address.)

5.3.2.  Processing of Router Solicitations

   When the Teredo server receives a Router Solicitation message (RS,
   [RFC2461]), it retains the IPv4 address and UDP port from which the
   solicitation was received; these become the Teredo mapped address and
   Teredo mapped port of the client.  The router uses these values to
   compose the origin indication encapsulation that will be sent with
   the response to the solicitation.

   The Teredo server responds to the router solicitation by sending a
   Router Advertisement message [RFC2461].  The router advertisement
   MUST advertise the Teredo IPv6 prefix composed from the service

   prefix and the server's IPv4 address.  The IPv6 source address should
   be set to a Teredo link-local server address associated to the local
   interface; this address is derived from the IPv4 address of the
   server and from the Teredo port, as specified in Section 4; the cone
   bit is set to 1.  The IPv6 destination address is set to the IPv6
   source address of the RS.  The Router Advertisement message must be
   sent over UDP to the Teredo mapped address and Teredo mapped port of
   the client; the IPv4 source address and UDP source port should be set
   to the server's IPv4 address and Teredo Port.  If the cone bit of the
   client's IPv6 address is set to 1, the RA must be sent from a
   different IPv4 source address than the server address over which the
   RS was received; if the cone bit is set to zero, the response must be
   sent back from the same address.

   Before sending the packet, the Teredo server MUST check that the IPv4
   destination address is in the format of a global unicast address; if
   this is not the case, the packet MUST be silently discarded (see
   Section 5.2.4 for a definition of global unicast addresses).

   If secure qualification is required, the server MUST insert a valid
   authentication parameter in the UDP packet carrying the router
   advertisement.  The client identifier and the nonce value used in the
   authentication parameter MUST be the same identifier and nonce as
   received in the router solicitation.  The confirmation byte MUST be
   set to zero if the client identifier is still valid, and a non-null
   value otherwise; the authentication value SHOULD be computed using
   the secret that corresponds to the client identifier.

5.4.  Teredo Relay Specification

   Teredo relays are IPv6 routers that advertise reachability of the
   Teredo service IPv6 prefix through the IPv6 routing protocols.  (A
   minimal Teredo relay may serve just a local host, and would not
   advertise the prefix beyond this host.)  Teredo relays will receive
   IPv6 packets bound to Teredo clients.  Teredo relays should be able

   to receive packets sent over IPv4 and UDP by Teredo clients; they may
   apply filtering rules, e.g., only accept packets from Teredo clients
   if they have previously sent traffic to these Teredo clients.

   The receiving and sending rules used by Teredo relays are very
   similar to those of Teredo clients.  Teredo relays must use a Teredo
   service port to transmit packets to Teredo clients; they must
   maintain a "list of peers", identical to the list of peers maintained
   by Teredo clients.

5.4.1.  Transmission by Relays to Teredo Clients

   When a Teredo relay has to transmit a packet to a Teredo client, it
   examines the destination IPv6 address.  By definition, the Teredo
   relays will only send over UDP IPv6 packets whose IPv6 destination
   address is a valid Teredo IPv6 address.

   Before processing these packets, the Teredo Relay MUST check that the
   IPv4 destination address embedded in the Teredo IPv6 address is in
   the format of a global unicast address; if this is not the case, the
   packet MUST be silently discarded (see Section 5.2.4 for a definition
   of global unicast addresses).

   The relay then checks if there is an entry for this IPv6 address in
   the list of recent Teredo peers, and if the entry is still valid.
   The relay then performs the following:

   1) If there is an entry for that IPv6 address in the list of peers,
   and if the status of the entry is set to "trusted", the IPv6 packet
   should be sent over UDP to the mapped IPv4 address and mapped UDP
   port of the entry.  The relay updates the date of last transmission
   in the peer entry.

   2) If there is no trusted entry in the list of peers, and if the
   destination is a Teredo IPv6 address in which the cone bit is set to
   1, the packet is sent over UDP to the mapped IPv4 address and mapped
   UDP port extracted from that IPv6 address.

   3) If there is no trusted entry in the list of peers, and if the
   destination is a Teredo IPv6 address in which the cone bit is set to
   0, the Teredo relay creates a bubble whose source address is set to a
   local IPv6 address, and whose destination address is set to the
   Teredo IPv6 address of the packet's destination.  The bubble is sent
   to the server address corresponding to the Teredo destination.  The
   entry becomes trusted when a bubble or another packet is received
   from this IPv6 address; if no such packet is received before a time-
   out of 2 seconds, the Teredo relay may repeat the bubble, up to three
   times.  If the relay fails to receive a bubble after these

   repetitions, the entry is removed from the list of peers.  The relay
   MAY queue packets bound to untrusted entries; the queued packets
   SHOULD be de-queued and forwarded when the entry becomes trusted;
   they SHOULD be deleted if the entry is deleted.  To avoid denial of
   service attacks, the relays SHOULD limit the number of packets in
   such queues.

   In cases 2 and 3, the Teredo relay should create a peer entry for the
   IPv6 address; the entry status is marked as trusted in case 2 (cone
   NAT) and not trusted in case 3.  In case 3, if the Teredo relay
   happens to be located behind a non-cone NAT, it should also send a
   bubble directly to the mapped IPv4 address and mapped port number of
   the Teredo destination.  This will "open the path" for the return
   bubble from the Teredo client.

   For reliability reasons, relays MAY decide to ignore the value of the
   cone bit in the flag, and always perform the "case 3", i.e., treat
   all Teredo peers as if they were located behind a non-cone NAT.  This
   will result in some increase in traffic, but may avoid

   reliability issues if the determination of the NAT status was for
   some reason erroneous.  For the same reason, relays MAY also decide
   to always send a direct bubble to the mapped IPv4 address and mapped
   port number of the Teredo destination, even if they do not believe
   that they are located behind a non-cone NAT.

5.4.2.  Reception from Teredo Clients

   The Teredo relay may receive packets from Teredo clients; the packets
   should normally only be sent by clients to which the relay previously
   transmitted packets, i.e., clients whose IPv6 address is present in
   the list of peers.  Relays, like clients, use the packet reception
   procedure to maintain the date and time of the last interaction with
   the Teredo server and the "list of recent peers".

   When a UDP packet is received over the Teredo service port, the
   Teredo relay checks that it contains a valid IPv6 packet as specified
   in [RFC2460].  If this is not the case, the packet is silently
   discarded.

   Then, the Teredo relay examines whether the IPv6 source address is a
   valid Teredo address, and if the mapped IPv4 address and mapped port
   match the IPv4 source address and port number from which the packet
   is received.  If this is not the case, the packet is silently
   discarded.

   The Teredo relay then examines whether there is an entry for the IPv6
   source address in the list of recent peers.  If this is not the case,

   the packet may be silently discarded.  If this is the case, the entry
   status is set to "trusted"; the relay updates the "date and time of
   the last interaction" to the current date and time.

   Finally, the relay examines the destination IPv6 address.  If the
   destination belongs to a range of IPv6 addresses served by the relay,
   the packet SHOULD be accepted and forwarded to the destination.  In
   the other cases, the packet SHOULD be silently discarded.

5.4.3.  Difference between Teredo Relays and Teredo Servers

   Because Teredo servers can relay Teredo packets over IPv6, all Teredo
   servers must be capable of behaving as Teredo relays.  There is,
   however, no requirement that Teredo relays behave as Teredo servers.

   The dual role of server and relays implies an additional complexity
   for the programming of servers: the processing of incoming packets
   should be a combination of the server processing rules defined in
   Section 5.3.1, and the relay processing rules defined in Section
   5.4.2.  (Section 5.3 only specifies the rules implemented by a pure
   server, not a combination relay+server.)

5.5.  Implementation of Automatic Sunset

   Teredo is designed as an interim transition mechanism, and it is
   important that it should not be used any longer than necessary.  The
   "sunset" procedure will be implemented by Teredo clients, servers,
   and relays, as specified in this section.

   The Teredo-capable nodes MUST NOT behave as Teredo clients if they
   already have IPv6 connectivity through any other means, such as
   native IPv6 connectivity.  In particular, nodes that have a global
   IPv4 address SHOULD obtain connectivity through the 6to4 service
   rather than through the Teredo service.  The classic reason why a
   node that does not need connectivity would still enable the Teredo
   service is to guarantee good performance when interacting with Teredo
   clients; however, a Teredo-capable node that has IPv4 connectivity
   and that has obtained IPv6 connectivity outside the Teredo service
   MAY decide to behave as a Teredo relay, and still obtain good
   performance when interacting with Teredo clients.

   The Teredo servers are expected to participate in the sunset
   procedure by announcing a date at which they will stop providing the
   service.  This date depends on the availability of alternative
   solutions to their clients, such as "dual-mode" gateways that behave
   simultaneously as IPv4 NATs and IPv6 routers.  Most Teredo servers
   will not be expected to operate more than a few years.  Teredo relays
   are expected to have the same life span as Teredo servers.