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,