- Flags: a set of 16 bits that document type of address and NAT.
- Port: the obfuscated "mapped UDP port" of the Teredo service at
the client.
- Client IPv4: the obfuscated "mapped IPv4 address" of the client.
In this format, both the "mapped UDP port" and "mapped IPv4 address"
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.
The IPv6 addressing rules specify that "for all unicast addresses,
except those that start with binary value 000, Interface IDs are
required to be 64 bits long and to be constructed in Modified EUI-64
format". This dictates the encoding of the flags, 16 intermediate
bits that should correspond to valid values of the most significant
16 bits of a Modified EUI-64 ID:
0 0 0 1
|0 7 8 5
+----+----+----+----+
|Czzz|zzUG|zzzz|zzzz|
+----+----+----+----+
In this format:
- The bits "UG" should be set to the value "00", indicating a non-
global unicast identifier;
- The bit "C" (cone) should be set to 1 if the client believes it is
behind a cone NAT, to 0 otherwise; these values determine
different server behavior during the qualification procedure, as
specified in Section 5.2.1, as well as different bubble processing
by clients and relays.
- The bits indicated with "z" must be set to zero and ignored on
receipt.
Thus, there are two currently specified values of the Flags field:
"0x0000" (all null) if the cone bit is set to 0, and "0x8000" if the
cone bit is set to 1. (Further versions of this specification may
assign new values to the reserved bits.)
In some cases, Teredo nodes use link-local addresses. These
addresses contain a link-local prefix (FE80::/64) and a 64-bit
identifier, constructed using the same format as presented above. A
difference between link-local addresses and global addresses is that
the identifiers used in global addresses MUST include a global scope
unicast IPv4 address, while the identifiers used in link-local
addresses MAY include a private IPv4 address.
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