IPv6 Operations Working Group D. Thaler
Internet-Draft Microsoft
Expires: May 5, 2009 November 1, 2008
Teredo Extensions
draft-thaler-v6ops-teredo-extensions-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 5, 2009.
Abstract
This document specifies a set of extensions to the Teredo protocol.
These extensions provide additional capabilities to Teredo, including
support for more types of Network Address Translations (NATs), and
support for more efficient communication.
Thaler Expires May 5, 2009 [Page 1]
Internet-Draft Teredo Extensions November 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Symmetric NAT Support Extension . . . . . . . . . . . . . 9
3.2. UPnP-Enabled Symmetric NAT Extension . . . . . . . . . . . 11
3.3. Port-Preserving Symmetric NAT Extension . . . . . . . . . 12
3.4. Sequential Port-Symmetric NAT Extension . . . . . . . . . 13
3.5. Hairpinning Extension . . . . . . . . . . . . . . . . . . 14
3.6. Server Load Reduction Extension . . . . . . . . . . . . . 16
4. Message Syntax . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Nonce Trailer . . . . . . . . . . . . . . . . . . . . . . 17
4.2. Alternate Address Trailer . . . . . . . . . . . . . . . . 17
4.3. Neighbor Discovery Option Trailer . . . . . . . . . . . . 18
4.4. Random Port Trailer . . . . . . . . . . . . . . . . . . . 19
5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 20
5.1. Symmetric NAT Support Extension . . . . . . . . . . . . . 20
5.1.1. Abstract Data Model . . . . . . . . . . . . . . . . . 20
5.1.2. Timers . . . . . . . . . . . . . . . . . . . . . . . . 20
5.1.3. Initialization . . . . . . . . . . . . . . . . . . . . 21
5.1.4. Message Processing . . . . . . . . . . . . . . . . . . 21
5.2. UPnP-Enabled Symmetric NAT Extension . . . . . . . . . . . 22
5.2.1. Abstract Data Model . . . . . . . . . . . . . . . . . 22
5.2.2. Timers . . . . . . . . . . . . . . . . . . . . . . . . 23
5.2.3. Initialization . . . . . . . . . . . . . . . . . . . . 23
5.2.4. Message Processing . . . . . . . . . . . . . . . . . . 23
5.3. Port-Preserving Symmetric NAT Extension . . . . . . . . . 24
5.3.1. Abstract Data Model . . . . . . . . . . . . . . . . . 25
5.3.2. Timers . . . . . . . . . . . . . . . . . . . . . . . . 25
5.3.3. Initialization . . . . . . . . . . . . . . . . . . . . 26
5.3.4. Message Processing . . . . . . . . . . . . . . . . . . 26
5.4. Sequential Port-Symmetric NAT Extension . . . . . . . . . 29
5.4.1. Abstract Data Model . . . . . . . . . . . . . . . . . 29
5.4.2. Timers . . . . . . . . . . . . . . . . . . . . . . . . 30
5.4.3. Initialization . . . . . . . . . . . . . . . . . . . . 31
5.4.4. Message Processing . . . . . . . . . . . . . . . . . . 31
5.5. Hairpinning Extension . . . . . . . . . . . . . . . . . . 32
5.5.1. Abstract Data Model . . . . . . . . . . . . . . . . . 32
5.5.2. Timers . . . . . . . . . . . . . . . . . . . . . . . . 33
5.5.3. Initialization . . . . . . . . . . . . . . . . . . . . 33
5.5.4. Message Processing . . . . . . . . . . . . . . . . . . 33
5.6. Server Load Reduction Extension . . . . . . . . . . . . . 34
5.6.1. Abstract Data Model . . . . . . . . . . . . . . . . . 34
5.6.2. Timers . . . . . . . . . . . . . . . . . . . . . . . . 35
5.6.3. Initialization . . . . . . . . . . . . . . . . . . . . 35
5.6.4. Message Processing . . . . . . . . . . . . . . . . . . 35
6. Protocol Examples . . . . . . . . . . . . . . . . . . . . . . 36
Thaler Expires May 5, 2009 [Page 2]
Internet-Draft Teredo Extensions November 2008
6.1. Symmetric NAT Support Extension . . . . . . . . . . . . . 36
6.2. UPnP-enabled Symmetric NAT Extension . . . . . . . . . . . 38
6.3. Port-Preserving Symmetric NAT Extension . . . . . . . . . 40
6.4. Sequential Port-Symmetric NAT Extension . . . . . . . . . 44
6.5. Hairpinning Extension . . . . . . . . . . . . . . . . . . 47
6.6. Server Load Reduction Extension . . . . . . . . . . . . . 49
7. Security Considerations . . . . . . . . . . . . . . . . . . . 50
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51
9.1. Normative References . . . . . . . . . . . . . . . . . . . 51
9.2. Informative References . . . . . . . . . . . . . . . . . . 51
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 51
Intellectual Property and Copyright Statements . . . . . . . . . . 53
Thaler Expires May 5, 2009 [Page 3]
Internet-Draft Teredo Extensions November 2008
1. Introduction
This document specifies extensions to the Teredo protocol, as
specified in [RFC4380]. These extensions provide additional
capabilities to Teredo, including support for more types of Network
Address Translations (NATs), and support for more efficient
communication.
2. Terminology
This document uses the following terminology, for consistency with
[RFC4380].
Address-Restricted NAT: A Restricted NAT that accepts packets from an
external host's IP address X and port Y if the internal host has sent
a packet that is destined to IP address X regardless of the
destination port.
Address-Symmetric NAT: A symmetric NAT that has multiple external IP
addresses and that assigns different IP addresses and ports when
communicating with different external hosts.
Cone NAT: A NAT that maps all requests from the same internal IP
address and port to the same external IP address and port.
Furthermore, any external host can send a packet to the internal host
by sending a packet to the mapped external address and port.
Direct Bubble: A Teredo bubble that is sent directly to the IPv4 node
whose Teredo address is contained in the Destination field of the
IPv6 header, as specified in [RFC4380] section 2.8. The IPv4
Destination Address and UDP Destination Port fields contain a mapped
address/port.
Echo Test: A mechanism to predict the mapped address/port a
sequential port-symmetric NAT is using for a client behind it.
Hairpinning: A feature that is available in some NATs where two or
more hosts are positioned behind a NAT and each of those hosts is
assigned a specific external (public) address and port by the NAT.
Hairpinning support in a NAT allows these hosts to send a packet to
the external address and port that is assigned to one of the other
hosts, and the NAT automatically routes the packet back to the
correct host. The term hairpinning is derived from the behavior of
the packet, which arrives on, and is sent out to, the same NAT
interface.
Indirect Bubble: A Teredo bubble that is sent indirectly (via the
Thaler Expires May 5, 2009 [Page 4]
Internet-Draft Teredo Extensions November 2008
destination's Teredo server) to another Teredo client, as specified
in [RFC4380] section 5.2.4.
Local Address/Port: The IPv4 address and UDP port from which a Teredo
client sends Teredo packets. The local port is referred to as the
Teredo service port in [RFC4380]. The local address of a node may or
may not be globally routable because the node can be located behind
one or more NATs.
Mapped Address/Port: A global IPv4 address and a UDP port that
results from the translation of a node's own local address/port by
one or more NATs. The node learns these values through the Teredo
protocol specified in [RFC4380]. For symmetric NATs, the mapped
address/port can be different for every peer that a node tries to
communicate with.
Network Address Translation (NAT): The process of converting between
IP addresses used within an intranet or other private network and
Internet IP addresses.
Nonce: A time-variant counter used in the connection setup phase to
prevent message replay and other types of attacks.
Peer: A Teredo client with which another Teredo Client needs to
communicate.
Port-Preserving NAT: A NAT that translates a local address/port to a
mapped address/port such that the mapped port has the same value as
the local port, as long as that same mapped address/port has not
already been used for a different local address/port.
Port-Restricted NAT: A restricted NAT that accepts packets from an
external host's IP address X and port Y only if the internal host has
sent a packet destined to IP address X and port Y.
Port-Symmetric NAT: A symmetric NAT that has only a single external
IP address and hence only assigns different ports when communicating
with different external hosts.
Private Address: An IPv4 address that is not globally routable but is
part of the private address space specified in [RFC1918] section 3.
Public Address: An external global address used by a NAT.
Restricted NAT: A NAT where all requests from the same internal IP
address and port are mapped to the same external IP address and port.
Unlike the cone NAT, an external host can send packets to an internal
host (by sending a packet to the external mapped address and port)
Thaler Expires May 5, 2009 [Page 5]
Internet-Draft Teredo Extensions November 2008
only if the internal host has first sent a packet to the external
host. There are two kinds of restricted NATs: address-restricted
NATs and port-restricted NATs.
Sequential Port-Symmetric NAT: A port-symmetric NAT that allocates
external ports sequentially for every {internal IP address and port,
destination IP address and port>} tuple. The delta used in the
sequential assignment is typically 1 or 2 for most such NATs.
Symmetric NAT: A NAT where all requests from the same internal IP
address and port and to the same destination IP address and port, are
mapped to the same external IP address and port. Requests from the
same internal IP address and port to a different destination IP
address and port may be mapped to a different external IP address and
port. Furthermore, a symmetric NAT accepts packets received from an
external host's IP address X and port Y only if some internal host
has sent packets to IP address X and port Y.
Teredo Bubble: A Teredo control message (specified in [RFC4380]
section 2.8) that is used to create a mapping in a NAT. There are
two types of Teredo bubbles: direct bubbles and indirect bubbles.
Teredo Client: A node that has access to the IPv4 Internet and wants
to gain access to the IPv6 Internet.
Teredo IPv6 Address: An IPv6 address that starts with the prefix
2001:0000:/32 and is formed as specified in [RFC4380] section 2.14.
Teredo Secondary Server Address: A secondary IPv4 address of a Teredo
server with which a Teredo client is configured, as specified in
[RFC4380] section 5.2.
Teredo Server: A node that has a globally routable address on the
IPv4 Internet, and is used as a helper to provide IPv6 connectivity
to Teredo clients.
Teredo Server Address: A (primary) IPv4 address of a Teredo server
with which a Teredo client is configured, as specified in [RFC4380]
section 5.2.
UPnP-enabled NAT: A NAT that has the UPnP device control protocol
enabled, as specified in [UPNPWANIP]. (Note that today, by default,
most UPnP-capable NATs have the UPnP device control protocol
disabled.)
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Thaler Expires May 5, 2009 [Page 6]
Internet-Draft Teredo Extensions November 2008
3. Overview
The Teredo protocol (as specified in [RFC4380]) enables nodes located
behind one or more IPv4 NATs to obtain IPv6 connectivity by tunneling
packets over UDP.
When a node behind a NAT needs to communicate with a peer (i.e.,
another node) that is behind a NAT, there are four sets of IPv4
address/port pairs of interest:
o The node's own IPv4 address/port.
o The external IPv4 address/port to which the node's NAT translates.
o The peer's own IPv4 address/port.
o The external IPv4 address/port to which the peer's NAT translates.
When the node sends a packet to a peer, the node needs to send it
from the node's own IPv4 address/port, destined to the peer's
external IPv4 address/port. By the time it arrives at the peer
(i.e., after passing through both NATs), the peer will see the same
packet as coming from the node's external IPv4 address/port, destined
to the peer's own IPv4 address/port.
In this document, the term local address/port refers to a Teredo
client's own IPv4 address/port; and mapped address/port refers to the
external IPv4 address/port to which its NAT translates the local
address/port. That is, the mapped address/port is what the IPv4
Internet sees the Teredo client as.
A Teredo client running on a node communicates with a Teredo server
to discover its mapped address/port. The mapped address/port, along
with the Teredo server address, are used to generate an IPv6 address
known as a Teredo IPv6 address. This allows any peer that gets the
node's IPv6 address to easily determine the external IPv4 address/
port to which to send IPv6 packets encapsulated in IPv4 UDP messages.
This document specifies extensions to the Teredo protocol. These
Teredo extensions are independent of each other and can be
implemented in isolation, except that the UPnP-Symmetric NAT
Extension and the Port-Preserving Symmetric NAT Extension both
require the Symmetric NAT Support Extension to be implemented. An
implementation of this specification can support any combination of
the Teredo extensions, subject to the above-mentioned restriction.
The following matrix outlines the connectivity improvements of some
of the extensions outlined in this document.
Destination NAT
| | | | | | Port-| | |
| | | | UPnP | UPnP | pres.| Seq. | |
Thaler Expires May 5, 2009 [Page 7]
Internet-Draft Teredo Extensions November 2008
| | Addr.| Port | Port | Port | Port-| Port-| Port-| Addr.
Source NAT | Cone | rest.| rest.| rest.| symm.| symm.| symm.| symm.| symm.
-----------+------+------+------+------+------+------+------+------+------
Cone | Yes | Yes | Yes | Yes | SNS | SNS | SNS | SNS | SNS
-----------+------+------+------+------+------+------+------+------+------
Address | Yes | Yes | Yes | Yes | SNS | SNS | SNS | SNS | No
restricted | | | | | | | | |
-----------+------+------+------+------+------+------+------+------+------
Port | Yes | Yes | Yes | Yes | No | SNS+ | SNS+ | No | No
restricted | | | | | | PP | SS | |
-----------+------+------+------+------+------+------+------+------+------
UPnP Port- | Yes | Yes | Yes | Yes | SNS+ | No | No | No | No
restricted | | | | | UPnP | | | |
-----------+------+------+------+------+------+------+------+------+------
UPnP Port | SNS | SNS | No | SNS+ | SNS+ | No | No | No | No
symmetric | | | | UPnP | UPnP | | | |
-----------+------+------+------+------+------+------+------+------+------
Port- | | | SNS | | | SNS | SNS | |
preserving | SNS | SNS | + | No | No | + | + | No | No
Port- | | | PP | | | PP | SS | |
symmetric | | | | | | | | |
-----------+------+------+------+------+------+------+------+------+------
Sequential | | | SNS | | | | | |
Port- | SNS | SNS | + | No | No | No | No | No | No
symmetric | | | SS | | | | | |
-----------+------+------+------+------+------+------+------+------+------
Port- | SNS | SNS | No | No | No | No | No | No | No
symmetric | | | | | | | | |
-----------+------+------+------+------+------+------+------+------+------
Address- | SNS | No | No | No | No | No | No | No | No
symmetric | | | | | | | | |
-----------+------+------+------+------+------+------+------+------+------
Yes = Supported by <xref target="RFC4380"/>.
SNS = Supported with the Symmetric NAT Support Extension.
SNS+UPNP = Supported with the Symmetric NAT Support Extension and UPnP
Symmetric NAT Extension.
SNS+PP = Supported with the Symmetric NAT Support Extension and Port-
Preserving Symmetric NAT Extension.
SNS+SS = Supported with the Symmetric NAT Support Extension and
Sequential Port-Symmetric NAT Extension.
No = No connectivity.
Thaler Expires May 5, 2009 [Page 8]
Internet-Draft Teredo Extensions November 2008
Matrix of Connectivity Improvements for Teredo Extensions
Figure 1
3.1. Symmetric NAT Support Extension
The qualification procedure (as specified in [RFC4380] section 5.2.1)
is a process that allows a Teredo client to determine the type of NAT
that it is behind, in addition to its mapped address/port as seen by
its Teredo server. However, [RFC4380] section 5.2.1 suggests that if
the client learns it is behind a symmetric NAT, the Teredo client
should go into an "offline state" where it is not able to use Teredo.
The primary reason for doing so is that it is not easy for Teredo
clients to connect to each other if either or both of them are
positioned behind a symmetric NAT. Because of the way a symmetric
NAT works, a peer sees a different mapped address/port in the IPv4/
UDP headers of packets coming from a Teredo client than the node's
Teredo server sees (and hence appears in the node's Teredo IPv6
address). Consequently, a symmetric NAT does not allow incoming
packets from a peer that are addressed to the mapped address/port
embedded in the node's Teredo IPv6 address. Thus, the incoming
packets are dropped and communication with Teredo client behind
symmetric NATs is not established.
With the Symmetric NAT Support Extension, Teredo clients begin to use
Teredo even after they detect that they are positioned behind a
symmetric NAT.
Consider the topology shown in Figure 2. Teredo Client B uses Teredo
Server 2 to learn that its mapped address/port is 137.107.0.1:8192,
and constructs a Teredo IPv6 address, as specified in [RFC4380]
section 4. Hence, CE49:7601 is the hexadecimal value of the address
of Teredo Server 2 (206.73.118.1), the mapped port is exclusive-OR'ed
with 0xFFFF to form DFFF, and the Mapped Address is exclusive-OR'ed
with 0xFFFFFFFF to form 7C94:FFFE.
Teredo Client A uses Teredo Server 1 to learn that its mapped
address/port is 157.60.0.1:4096 and, with this extension, constructs
a Teredo IPv6 address (as specified in [RFC4380] section 4) even
though it learns that it is behind a symmetric NAT. Hence, 4136:E378
is the hexadecimal value of the address of Teredo Server 1
(65.54.227.120), the mapped port is exclusive-OR'ed with 0xFFFF to
form EFFF, and the Mapped Address is exclusive-OR'ed with 0xFFFFFFFF
to form 62C3:FFFE.
The Symmetric NAT Support Extension enables a Teredo client
positioned behind a symmetric NAT to communicate with Teredo peers
positioned behind a cone or address-restricted NATs as follows,
Thaler Expires May 5, 2009 [Page 9]
Internet-Draft Teredo Extensions November 2008
depending on what side initiates the communication.
--------------------------------------------
/ \
< IPv6 Internet >
\ /
-|----------------------------------------|-
| |
+----------+ +----------+
| Teredo | | Teredo |
| Server 1 | | Server 2 |
+----------+ +----------+
65.54.227.120| 206.73.118.1|
-|----------------------------------------|-
/ \
< IPv4 Internet >
\ /
-|----------------------------------------|-
157.60.0.1| 137.107.0.1|
UDP port 4096| UDP port 8192|
+---------+ +----------+
|Symmetric| |Other type|
| NAT | | of NAT |
+---------+ +----------+
| |
+-----------------+ +-----------------+
| Teredo client A | | Teredo client B |
+-----------------+ +-----------------+
3FFE:831F:4136:E378:8000:EFFF:62C3:FFFE 3FFE:831F:CE49:7601:0:DFFF:7C94:FFFE
Teredo Address Teredo Address
Symmetric NAT example
Figure 2
In the first case, assume that a Teredo Client B (B) positioned
behind a cone or address-restricted NATs, initiates communication
with Teredo Client A (A) positioned behind a symmetric NAT. B sends
an indirect bubble via A's server (Teredo Server 1) to A, and A
responds with a direct bubble. This direct bubble reaches B, because
it is positioned behind a cone or address-restricted NAT. However,
the mapped address/port in the IPv4/UDP headers of the direct bubble
are different from the mapped address/port embedded in A's Teredo
IPv6 address. B therefore remembers the mapped address/port of the
direct bubble and uses them for future communication with A, and thus
communication is established.
In the second case, assume that A, positioned behind a symmetric NAT,
Thaler Expires May 5, 2009 [Page 10]
Internet-Draft Teredo Extensions November 2008
initiates communication with B, positioned behind a cone or address-
restricted NAT. A sends an indirect bubble to B via B's server
(Teredo Server 2), and B responds with a direct bubble. This direct
bubble is dropped by A's symmetric NAT because the direct bubble is
addressed to the mapped address/port embedded in A's Teredo IPv6
address. However, communication can be established by having B
respond with an indirect bubble via A's server (Teredo Server 1).
Now the scenario is similar to the first case and communication will
be established.
3.2. UPnP-Enabled Symmetric NAT Extension
The UPnP-enabled Symmetric NAT Extension is dependent on the
Symmetric NAT Support Extension. Only if Teredo clients have been
enabled to acquire a Teredo IPv6 address in spite of being behind a
symmetric NAT, will this extension help in traversing UPnP-enabled
Symmetric NATs.
The Symmetric NAT Support Extension enables communication between
Teredo clients behind symmetric NATs with Teredo clients behind cone
NATs or address-restricted NATs. However, clients behind symmetric
NATs can still not communicate with clients behind port-restricted
NATs or symmetric NATs.
Referring again to Figure 2 (see Section 3.1), assume that Teredo
Client A is positioned behind a symmetric NAT and initiates
communication with Client B, which is positioned behind a port-
restricted NAT. Client A sends a direct bubble and an indirect
bubble to Client B via Client B's server (Teredo Server 2). As per
the characteristics of the symmetric NAT, the IPv4 source of the
direct bubble contains a different mapped address and/or port than
the one embedded in the Teredo server. This direct bubble is dropped
because Client B's NAT does not have state to let it pass through,
and Client B does not learn the mapped address/port used in the IPv4/
UDP headers. In response to the indirect bubble from Client A,
Client B sends a direct bubble destined to the mapped address/port
embedded in Client A's Teredo IPv6 address. This direct bubble is
dropped because Client A's NAT does not have state to accept packets
destined to that mapped address/port. The direct bubble does,
however, cause Client B's NAT to set up outgoing state for the mapped
address/port embedded in Client A's Teredo IPv6 address.
As described in Section 3.1, Client B also sends an indirect bubble
that elicits a direct bubble from Client A. Unlike the case in
Section 3.1, however, the direct bubble from Client A is dropped as
Client B's NAT does not have state for the mapped address/port that
Client A's NAT uses. Note that Client B's NAT is port-restricted and
hence requires both the mapped address and port to be the same as in
Thaler Expires May 5, 2009 [Page 11]
Internet-Draft Teredo Extensions November 2008
its outgoing state, whereas in Section 3.1, Client A's NAT was a cone
or address-restricted NAT which only required the mapped address (but
not port) to be the same. Thus, communication between Client A and
Client B fails. If Client B were behind a symmetric NAT, the problem
is further complicated by Client B's NAT using a different outgoing
mapped address/port than the one embedded in Client B's Teredo IPv6
address.
If a Teredo client is separated from the global Internet by a single
UPnP-enabled symmetric or port-restricted NAT, it can communicate
with other Teredo clients that are positioned behind a single UPnP-
enabled symmetric or port-restricted NAT as follows:
Teredo clients, before communicating with the Teredo server during
the qualification procedure, use UPnP to reserve a local address/port
to mapped address/port translation. Therefore, during the
qualification procedure, the Teredo server reflects back the reserved
mapped address/port, which then is included in the Teredo IPv6
address. The mapping created by UPnP allows the NAT to forward
packets destined for the mapped address/port to the local address/
port, independent of the source of the packets.
Thus, a Teredo client, positioned behind a UPnP-enabled symmetric
NAT, can receive a direct bubble sent by any Teredo peer. The Teredo
client compares the peer's mapped address/port as seen in the IPv4/
UDP headers with the mapped address/port in the peer's Teredo IPv6
address. If the two mappings are different, the packet was sent by
another Teredo client positioned behind a symmetric NAT. The
Symmetric NAT Support Extension suggested that the Teredo client use
the peer's mapped address/port seen in the IPv4/UDP headers for
future communication. However, because symmetric NAT-to-symmetric
NAT communication would not have been possible anyway, the Teredo
client sends back a direct bubble to the mapped port/address embedded
in the peer's Teredo IPv6 address. If the peer is also situated
behind a UPnP-enabled NAT, the direct bubble will make it through and
communication will be established.
3.3. Port-Preserving Symmetric NAT Extension
The Port-Preserving Symmetric NAT Extension is dependent on the
Symmetric NAT Support Extension (Section 3.1). Only if Teredo
clients have been enabled to acquire a Teredo IPv6 address in spite
of being behind a symmetric NAT will this extension help in
traversing port-preserving symmetric NATs.
The Symmetric NAT Support Extension enables communication between
Teredo clients behind symmetric NATs with Teredo clients behind cone
NATs or address-restricted NATs. However, clients behind symmetric
Thaler Expires May 5, 2009 [Page 12]
Internet-Draft Teredo Extensions November 2008
NATs can still not communicate with clients behind port-restricted or
symmetric NATs, as described in Section 3.2. Note that the Port-
Preserving Symmetric NAT Extension described here is independent of
the UPnP-enabled Symmetric NAT Extension, described in Section 3.2.
If a Teredo client is positioned behind a port-preserving symmetric
NAT, the client can communicate with other Teredo clients positioned
behind a port-restricted NAT or a port-preserving symmetric NAT as
follows.
Teredo clients compare the mapped port learned during the
qualification procedure with their local port to determine if they
are positioned behind a port-preserving NAT. If both the mapped port
and the local port have the same value, the Teredo client is
positioned behind a port-preserving NAT. At the end of the
qualification procedure, the Teredo client also knows if it is
positioned behind a symmetric NAT, as described in Section 3.1.
Teredo clients positioned behind port-preserving symmetric NATs can
also listen on randomly chosen local ports. If the randomly chosen
local port has not been used by the symmetric NAT as a mapped port in
a prior port-mapping, the NAT uses the same port number as the mapped
port. Thus, the challenge is to get the first direct bubble sent out
from the random port to be destined to a valid destination address
and port. When the mapped address/port is embedded in the
destination's Teredo IPv6 address, this is easy.
The communication setup is more complicated when the destination
Teredo client is also positioned behind a port-preserving symmetric
NAT. In such a case, both Teredo clients need to send their first
direct bubbles to the correct destination mapped address/port. Thus
the protocol messages, which communicate one Teredo client's random
port number to the other Teredo client, must be exchanged indirectly
(via Teredo servers). When one Teredo client has access to the other
Teredo client's random port number, it can send a direct bubble
destined to the mapped address embedded in the destination's Teredo
IPv6 address, and the mapped port can be the same as the
destination's random port number. If both NATs are port-preserving,
port-preserved mappings are created on both NATs and the second
direct bubble succeeds in reaching the destination.
3.4. Sequential Port-Symmetric NAT Extension
The Sequential Port-Symmetric NAT Extension is dependent on the
Symmetric NAT Support Extension (Section 3.1). Only if Teredo
clients have been enabled to acquire a Teredo IPv6 address in spite
of being behind a symmetric NAT will this extension help in
traversing a sequential port-symmetric NAT.
Thaler Expires May 5, 2009 [Page 13]
Internet-Draft Teredo Extensions November 2008
With this extension, if a Teredo client is positioned behind a
sequential port-symmetric NAT, the client can communicate with other
Teredo clients positioned behind a port-restricted NAT as follows.
If during qualification the client discovers it is behind a symmetric
NAT that is not port-preserving, it assumes by default that it is
behind a sequential port-symmetric NAT. This assumption is proactive
for the following reasons:
o There is no perfect method of discovering whether the client is
behind a sequential port-symmetric NAT.
o These kinds of NATs are notorious for changing their behavior. At
times they could be sequential port-symmetric and at other times
not.
o There is no other solution for symmetric NAT traversal so this is
a last resort.
Teredo clients positioned behind sequential port-symmetric NATs can
also listen on a randomly chosen local port when communicating with a
peer. To predict the external port being used for a given peer, the
client sends three packets:
o Packet 1 is a router solicitation (as specified in [RFC4380]
section 5.2.1) sent to the Teredo server address.
o Packet 2 is a direct bubble sent to the peer.
o Packet 3 is a router solicitation sent to the secondary Teredo
server address.
As part of the normal Teredo protocol, the Teredo server responds to
Packets 1 and 3. Based on the information in the responses, the
client now knows that Packet 1 was seen as coming from one external
port, and Packet 3 was seen as coming from another external port.
Assuming the NAT is a sequential port-symmetric NAT, the external
port for Packet 2 is estimated (or predicted) to be midway between
the external ports for Packets 1 and 3. Note that because other
applications may have also been using the NAT between Packets 1 and
3, the actual port might not be exactly the midpoint.
The Teredo client then communicates the predicted port to its peer,
which sends a direct bubble to the communicated port. If the
communicated port is indeed the external port for Packet 2, the
direct bubble will reach the Teredo client.
3.5. Hairpinning Extension
Hairpinning support in a NAT routes packets that are sent from a
private (local) address destined to a public (mapped) address of the
NAT, back to another private (local) destination address behind the
same NAT. If hairpinning support is not available in a NAT, two
Teredo clients behind the same NAT are not able to communicate with
Thaler Expires May 5, 2009 [Page 14]
Internet-Draft Teredo Extensions November 2008
each other, as specified in [RFC4380] section 8.3.
The Hairpinning Extension enables two clients behind the same NAT to
talk to each other when the NAT does not support hairpinning. This
process is illustrated in the following diagram.
--------------------------------------------
/ \
< IPv6 Internet >
\ /
-|----------------------------------------|-
| |
+----------+ +----------+
| Teredo | | Teredo |
| Server 1 | | Server 2 |
+----------+ +----------+
206.73.118.1| 65.54.227.120|
-|----------------------------------------|-
/ \
< IPv4 Internet >
\ /
--------------------|-----------------------
|
NAT +-------+
without | NAT |
hairpinning | E |
support +-------+
|
+------------------+---------------------+
192.168.1.0| 192.168.1.1|
UDP port 4095| UDP port 4096|
+---------+ +----------+
| NAT | | NAT |
| F | | G |
+---------+ +----------+
| |
+-----------------+ +-----------------+
| Teredo client A | | Teredo client B |
+-----------------+ +-----------------+
3FFE:831F:CE49:7601:0:DFFF:7C94:FFFE 3FFE:831F:4136:E378:8000:EFFF:62C3:FFFE
Teredo Address Teredo Address
Hairpinning example
Figure 3
The Teredo Client A (A) includes, as part of its indirect bubble sent
to Teredo Client B (B), its local address/port. B, upon receiving
Thaler Expires May 5, 2009 [Page 15]
Internet-Draft Teredo Extensions November 2008
the indirect bubble, tries to establish communication by sending
direct bubbles to the mapped address/port of A, and also to the local
address/port of B.
If a Teredo client is part of a multi-NAT hierarchy and the NAT to
which the Teredo client is connected supports the UPnP protocol (as
specified in [UPNPWANIP]), the Teredo client can use UPnP to
determine the mapped address/port assigned to it by the NAT. This
information can be included along with the local address/port when
sending the indirect bubble. The destination Teredo client now tries
to establish a connection by sending direct bubbles to the mapped
address/port in the Teredo IPv6 address, to the local address/port
included in the bubble, and also to the mapped address/port included
in the bubble.
3.6. Server Load Reduction Extension
If communication between a Teredo client and a Teredo peer was
successfully established but at a later stage was silent for a while,
for efficiency it is best to refresh the mapping state in the NATs
that are positioned between them. To refresh the communication
between itself and a Teredo peer, a Teredo client needs to solicit a
direct bubble response from the Teredo peer. An indirect bubble is
sent to solicit a direct bubble response from a Teredo peer, as
specified in [RFC4380] section 5.2.4. However, these indirect
bubbles increase the load on the Teredo server.
The Server Load Reduction Extension allows Teredo clients to send
direct bubbles most of the time instead of sending indirect bubbles
all of the time in the following way:
1. When a Teredo client tries to refresh its communication with a
Teredo peer, it uses a direct bubble instead of an indirect
bubble. However, because direct bubbles do not normally solicit
a response, the direct bubble format is extended to be able to
solicit a response.
2. When a Teredo client receives a direct bubble that is soliciting
a response, the Teredo client responds with a direct bubble.
3. If attempts to reestablish communication with the help of direct
bubbles fail, the Teredo client starts over the process of
establishing communication with the Teredo peer, as specified in
[RFC4380] section 5.2.4.
4. Message Syntax
All Teredo messages are transported over the User Datagram Protocol
(UDP), as specified in [RFC4380] section 3.
Thaler Expires May 5, 2009 [Page 16]
Internet-Draft Teredo Extensions November 2008
4.1. Nonce Trailer
The Nonce Trailer is used by the Symmetric NAT Support Extension (and
therefore the UPnP-enabled Symmetric NAT Extension and Port-
Preserving Symmetric NAT Extension also) and the Hairpinning
Extension. The Nonce Trailer can be present in both indirect and
direct bubbles sent by the Teredo client. The nonce in the Nonce
Trailer helps authenticate a Teredo client positioned behind a
Symmetric NAT.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (1 byte): The Trailer Option type. This field MUST be set to
0x01.
Length (1 byte): The length in bytes of the rest of the option. This
field MUST be set to 0x04.
Nonce (4 bytes): The Nonce value.
4.2. Alternate Address Trailer
The Alternate Address Trailer is used by the Hairpinning Extension.
The Alternate Address Trailer MUST NOT be present in any packets
other than direct or indirect bubbles sent by a Teredo client. The
Alternate Address Trailer provides another Teredo client positioned
behind the same NAT with more address options that it can use to
connect.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Alternate Address/Port List (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (1 byte): The Trailer Option type. This field MUST be set to
0x03.
Thaler Expires May 5, 2009 [Page 17]
Internet-Draft Teredo Extensions November 2008
Length (1 byte): The length in bytes of the rest of the option. The
value of this field MUST be in the range 8 to 26 (i.e., 2 bytes for
the Reserved field, and 6 bytes for each entry in the Alternate
Address/Port List). This allows for a minimum of one address/port
mapping and a maximum of four address/port mappings to be advertised.
It SHOULD be at most 14 as a maximum of two address/port mappings can
be determined by Teredo: one local address/port and one obtained
using UPnP. Because the length of the alternate address/port is 6
bytes, the valid range of values is only 8, 14, 20 and 26.
Reserved (2 bytes): This field MUST be set to 0x0000 and ignored on
receipt.
Alternate Address/Port List (variable): An array of additional
address/port pairs that can be used by other Teredo clients to
communicate with the sender. Each alternate address/port entry MUST
be formatted as follows:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Address (4 bytes): An IPv4 address in network byte order. This
field MUST contain a valid unicast address.
Port (2 bytes): A port number in network byte order. This field MUST
NOT be zero.
4.3. Neighbor Discovery Option Trailer
The Neighbor Discovery Option Trailer is used by the Server Load
Reduction Extension because it allows direct bubbles to encode an
IPv6 Neighbor Solicitation ([RFC4861] section 4.3), in addition to an
IPv6 Neighbor Advertisement ([RFC4861] section 4.4), which prevents
packets from being relayed indirectly through a Teredo server. The
Neighbor Discovery Option Trailer allows the receiver to
differentiate between a direct bubble that is soliciting a response
versus a regular direct bubble. This allows Teredo clients to use
direct bubbles to refresh inactive connections instead of using
indirect bubbles.
Thaler Expires May 5, 2009 [Page 18]
Internet-Draft Teredo Extensions November 2008
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | DiscoveryType | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (1 byte): The Trailer Option type. This field MUST be set to
0x04.
Length (1 byte): The length in bytes of the rest of the option. This
field MUST be set to 0x04.
DiscoveryType (1 byte): This field MUST be set to one of the
following values:
TeredoDiscoverySolicitation (0x00): The receiver is requested to
respond with a direct bubble of DiscoveryType
TeredoDiscoveryAdvertisement.
TeredoDiscoveryAdvertisement (0x01): The direct bubble is in response
to a direct bubble or an indirect bubbles containing DiscoveryType
TeredoDiscoverySolicitation.
Reserved (3 bytes): This field MUST be set to 0x000000 on
transmission and ignored on receipt.
4.4. Random Port Trailer
The Random Port Trailer is used by the Port-Preserving Symmetric NAT
Extension in both indirect and direct bubbles.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Random Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (1 byte): The Trailer Option type. This field MUST be set to
0x05.
Length (1 byte): The length in bytes of the rest of the option. This
field MUST be set to 0x02.
Random Port (2 bytes): The external port that the sender predicts
that its NAT has assigned it for communication with the destination.
This field MUST be specified in network byte order.
Thaler Expires May 5, 2009 [Page 19]
Internet-Draft Teredo Extensions November 2008
5. Protocol Details
5.1. Symmetric NAT Support Extension
[RFC4380] section 5.2.1 advises that no Teredo IPv6 address be
configured if the Teredo client is positioned behind a symmetric NAT.
For Teredo clients positioned behind symmetric NATs, the mapped
address/port used by its NAT when communicating with a Teredo peer is
different from the mapped address/port embedded in the Teredo
client's Teredo IPv6 address. The Symmetric NAT Support Extension
provides a solution to this problem.
In addition, [RFC4380] section 5.2.9 specifies a direct IPv6
connectivity test to determine that the mapped address/port in the
Teredo IPv6 address of a peer is not spoofed. It does this through
the use of a nonce in ICMPv6 Echo Request and Response messages
(which are defined in [RFC2463] section 4). However, the direct IPv6
connectivity test is limited only to communication between Teredo
IPv6 addresses and non-Teredo IPv6 addresses. In the following
extension, we introduce the use of a nonce in direct and indirect
bubbles and provide a mechanism to verify that the mapped address/
port are not spoofed.
This extension is optional; an implementation SHOULD support it.
5.1.1. Abstract Data Model
This section describes a conceptual model of possible data
organization that an implementation maintains to participate in this
protocol. The described organization is provided to facilitate the
explanation of how the protocol behaves. This document does not
mandate that implementations adhere to this model as long as their
external behavior is consistent with that described in this document.
In addition to the state specified in [RFC4380] section 5.2, the
following are also required:
Peer Entry: The following additional state is required on a per-peer
basis:
o Nonce Sent: The value of the nonce sent in the last indirect
bubble sent to the Teredo peer.
o Nonce Received: The value of the nonce received in the last
indirect bubble received from the Teredo peer.
5.1.2. Timers
No timers are necessary other than those in [RFC4380].
Thaler Expires May 5, 2009 [Page 20]
Internet-Draft Teredo Extensions November 2008
5.1.3. Initialization
No initialization is necessary other than that specified in
[RFC4380].
5.1.4. Message Processing
Except as specified in the following sections, the rules for message
processing are as specified in [RFC4380].
5.1.4.1. Sending an Indirect Bubble
The rules for when indirect bubbles are sent to a Teredo peer are
specified in [RFC4380] section 5.2.6. When a Teredo client sends an
indirect bubble, it MUST generate a random 4-byte value, and include
it in the Nonce field of a Nonce Trailer (section 2.2.1) appended to
the indirect bubble, and also store it in the Nonce Sent field of its
Peer Entry for that Teredo peer.
5.1.4.2. Sending a Direct Bubble
The rules for when direct bubbles are sent to a Teredo peer are
specified in [RFC4380] section 5.2.6. When a Teredo client sends a
direct bubble to a peer after receiving an indirect bubble with a
Nonce Trailer, it MUST include in the direct bubble a Nonce Trailer
with the same nonce value.
If the Teredo client is about to send a direct bubble before it has
received an indirect bubble from the Teredo peer, the Teredo client
MUST NOT include a Nonce Trailer.
5.1.4.3. Receiving an Indirect Bubble
The rules for processing an indirect bubble are specified in
[RFC4380] section 5.2.3. In addition, when a Teredo client receives
an indirect bubble containing a Nonce Trailer, the Teredo client MUST
store the nonce in the Nonce Received field of its Peer Entry for
that Teredo peer. If an indirect bubble is received without a Nonce
Trailer, and the Nonce Received field in the Peer Entry is non-zero,
the Nonce Received field SHOULD be set to zero.
5.1.4.4. Receiving a Direct Bubble
If the mapped address/port of the direct bubble matches the mapped
address/port embedded in the source Teredo IPv6 address, the direct
bubble MUST be accepted, as specified in [RFC4380] section 5.2.3.
In addition, if the mapped address/port does not match the embedded
Thaler Expires May 5, 2009 [Page 21]
Internet-Draft Teredo Extensions November 2008
address/port but the direct bubble contains a Nonce Trailer with a
nonce that matches the Nonce Sent field of the Teredo peer, the
direct bubble MUST be accepted.
If neither of the above conditions is true, the direct bubble MUST be
dropped.
If the direct bubble is accepted, the Teredo client MUST record the
mapped address/port from which the direct bubble is received in the
mapped address/port fields of the Teredo peer, as specified in
[RFC4380] section 5.2.
5.2. UPnP-Enabled Symmetric NAT Extension
The UPnP-enabled Symmetric NAT Extension is optional; an
implementation SHOULD support it. This extension has the Symmetric
NAT Support Extension (Section 5.1) as a dependency. Any node that
implements this extension MUST also implement the Symmetric NAT
Support Extension.
5.2.1. Abstract Data Model
This section describes a conceptual model of possible data
organization that an implementation maintains to participate in this
protocol. The described organization is provided to facilitate the
explanation of how the protocol behaves. This document does not
mandate that implementations adhere to this model as long as their
external behavior is consistent with that described in this document.
This extension extends the abstract data model in Section 5.1.1 by
adding the following additional fields.
UPnP-Enabled NAT flag: This is a Boolean value, set to TRUE if the
NAT positioned in front of the Teredo client is UPnP enabled.
UPnP-Mapped Address/Port: The mapped address/port assigned via UPnP
to the Teredo client by the UPnP-enabled NAT behind which the Teredo
client is positioned. Note that this field has a valid value only if
the NAT to which the Teredo client is connected is UPnP enabled.
Also note that if the Teredo client is positioned behind a single NAT
only (as opposed to a series of nested NATs), this value is the same
as the mapped address/port embedded in its Teredo IPv6 address.
Symmetric NAT flag: This is a Boolean value, set to TRUE if the
Teredo client is positioned behind a symmetric NAT.
Peer Entry: The following state needs to be added on a per-peer
basis:
Thaler Expires May 5, 2009 [Page 22]
Internet-Draft Teredo Extensions November 2008
Symmetric Peer flag: This is a Boolean value and is TRUE if the
Teredo peer is positioned behind a symmetric NAT.
5.2.2. Timers
No timers are necessary other than those in [RFC4380].
5.2.3. Initialization
Prior to beginning the qualification procedure, the Teredo client
MUST invoke the AddPortMapping function, as specified in [UPNPWANIP]
section 2.4.16, with the following parameters:
o NewRemoteHost: "" (empty string)
o NewExternalPort: Local Port value
o NewProtocol: UDP
o NewInternalPort: Local Port value
o NewInternalClient: Local Address value
o NewEnabled: TRUE
o NewPortMappingDescription: "TEREDO"
o NewLeaseDuration: 0
The successful completion of the AddPortMapping function indicates
that the NAT has created a port mapping from the external port of the
NAT to the internal port of the Teredo client node. The parameters
are specified so that any external host should be able to send
packets to the Teredo client by sending packets to the mapped
address/port. The Teredo client MUST set its UPnP-Enabled NAT flag
based on whether the AddPortMapping function succeeded or failed.
During the qualification procedure (as specified in [RFC4380] section
5.2.1) when the Teredo client receives a response from the secondary
Teredo server, the Teredo client MUST compare the mapped address/port
learned from the secondary Teredo server with the mapped address/port
associated with the Teredo server. If either the mapped address or
mapped port value is different, the Symmetric NAT flag MUST be set to
TRUE.
After the qualification procedure, the mapped address/port learned
from the Teredo server MUST be compared to the UPnP-Mapped Address/
Port. If both are the same, the Teredo client is positioned behind a
single NAT and the UPnP-Mapped Address/Port MUST be zeroed out.
5.2.4. Message Processing
Except as specified in the following sections, the rules for message
processing are as specified in [RFC4380] section 5.2.3.
Thaler Expires May 5, 2009 [Page 23]
Internet-Draft Teredo Extensions November 2008
5.2.4.1. Receiving a Direct Bubble
Except as indicated below, the rules for handling a direct bubble are
as specified in Section 5.1.4.4.
A Teredo client positioned behind a UPnP-enabled NAT (port-restricted
NAT as well as symmetric NAT) will receive all packets sent to the
mapped address/port embedded in its Teredo IPv6 address. Thus when a
Teredo client receives a direct bubble, it MUST compare the mapped
address/port from which the packet was received with the mapped
address/port embedded in the Teredo IPv6 address in the source
address field of the IPv6 header. If the two are not the same, it
indicates that the Teredo peer is positioned behind a symmetric NAT
and it MUST set the Symmetric Peer flag in its Peer Entry.
5.2.4.2. Sending a Direct Bubble
The rules for sending a direct bubble are specified in [RFC4380]
section 5.2.6 and in Section 5.1.4.2. These rules are further
refined as follows.
If the Teredo client sending the direct bubble meets all of the
following criteria:
o The Symmetric NAT flag is set to TRUE.
o The UPnP-Enabled NAT flag is set to TRUE.
o The UPnP-Mapped Address/Port are set to zero.
o The peer'sSymmetric Peer flag is set to TRUE.
then the Teredo client MUST send the direct bubble to the mapped
address/port embedded in the peer's Teredo IPv6 address.
This is because Symmetric-to-Symmetric and Port-Restricted-to-
Symmetric NAT communication between the Teredo client and the peer
would have failed anyway. However, by taking a chance that the peer
can also be positioned behind a UPnP-enabled NAT just like the Teredo
client itself, the Teredo client can try sending the direct bubble to
the mapped address/port in the peer's Teredo IPv6 address. If the
packet does go through, communication is established.
5.3. Port-Preserving Symmetric NAT Extension
The Port-Preserving Symmetric NAT Extension is optional; an
implementation SHOULD support it. This extension has the Symmetric
NAT Support Extension (as specified in Section 5.1) as a dependency.
Any node that implements this extension MUST also implement the
Symmetric NAT Support Extension.
Thaler Expires May 5, 2009 [Page 24]
Internet-Draft Teredo Extensions November 2008
5.3.1. Abstract Data Model
This section describes a conceptual model of possible data
organization that an implementation maintains to participate in this
protocol. The described organization is provided to facilitate the
explanation of how the protocol behaves. This document does not
mandate that implementations adhere to this model as long as their
external behavior is consistent with that described in this document.
The Port-Preserving Symmetric NAT Extension extends the abstract data
model in Section 5.1.1 by adding the following additional fields.
Port-Preserving NAT flag: This is a Boolean value, set to TRUE if the
Teredo client is positioned behind a port-preserving NAT.
Symmetric NAT flag: This is a Boolean value, set to TRUE if the
Teredo client is positioned behind a symmetric NAT.
Peer Entry: The following fields need to be added on a per-peer
basis:
o Random Port: This field contains the value of the external port
that the Teredo client predicts that its NAT has assigned it for
communication with the peer. Set to zero by default.
o Peer Random Port: This field contains the value of the random port
that the peer is using for communication with this Teredo client.
Set to zero by default.
o Direct Receive on Primary Port: This is a Boolean value, set to
TRUE if a packet is received from the Teredo peer on the primary
local port. Set to FALSE by default.
o Direct Receive on Random Port: This is a Boolean value, set to
TRUE if a packet is received from the Teredo peer on the Random
Port. Set to FALSE by default.
o Connection Refresh Count: This field contains the number of direct
bubbles that have been sent to the peer since the last time data
was communicated between the two peers.
o Last Data Packet Sent Timestamp: This field contains the time
stamp of the last data packet sent to the peer. This time stamp
is different from the field that stores the data and time of last
transmission to the peer (as specified in [RFC4380] section 5.2)
because the RFC-defined field is also updated every time a direct
bubble is sent.
5.3.2. Timers
Other than those in [RFC4380], the Port-Preserving Symmetric NAT
Extension requires the following additional timer:
Refresh timer: A timer to refresh peer connections on which no data
Thaler Expires May 5, 2009 [Page 25]
Internet-Draft Teredo Extensions November 2008
has been sent for a while.
5.3.2.1. Refresh Timer Expiry
When the refresh timer expires, the Teredo client MUST go through its
list of peers and for each peer to which the Teredo client is
communicating through the random port, the Teredo client MUST check
the Last Data Packet Sent Timestamp to determine if data has been
sent to the peer in the last 30 seconds, and check the Connection
Refresh Count field to determine if the count has reached the maximum
allowed value of 20. If both checks are false, the Teredo client
MUST send a direct bubble (as specified in Section 5.3.4.3) to the
peer and increment the Connection Refresh Count. This direct bubble
is sent as an attempt to keep the port mappings on all the
intermediate NATs alive while the application/user may be temporarily
inactive. If on the other hand, data has been sent to the peer in
the last 30 seconds, the Connection Refresh Count MUST be reset to
zero.
The refresh timer MUST then be rescheduled to expire in 30 seconds.
5.3.3. Initialization
In addition to the behavior specified in [RFC4380], the Port-
Preserving NAT flag and Symmetric NAT flag MUST be set to FALSE when
the Teredo client is started. The Refresh Timer MUST be started and
scheduled to expire in 30 seconds.
During the qualification procedure (as specified in [RFC4380] section
5.2.1), when the Teredo client receives a response from the Teredo
server address, the Teredo client MUST compare the Port value in the
origin indication, as specified in [RFC4380] section 5.1.1, with the
Local Port value. If both values match, the client MUST set the
Port-Preserving NAT flag to TRUE.
5.3.4. Message Processing
5.3.4.1. Sending a Data Packet
On receiving a data packet to be transmitted to the Teredo Peer (in
addition to the rules specified in [RFC4380] section 5.2.4), the
Teredo client MUST update the Last Data Packet Sent Timestamp when
the packet is actually sent.
5.3.4.2. Sending an Indirect Bubble
The rules for sending an indirect bubble are as specified in
Section 5.1.4.1 and [RFC4380] section 5.2.6. In addition to those
Thaler Expires May 5, 2009 [Page 26]
Internet-Draft Teredo Extensions November 2008
rules, if the Port-Preserving NAT Flag is TRUE, the Teredo client
MUST do the following:
o If the Symmetric NAT flag is set, and the Teredo peer is not
marked as "trusted" (as specified in [RFC4380] section 5.2) and
the Random Port is zero, the Teredo client MUST first select a
random port number to use, and begin listening on that port.
Since the NAT is port-preserving, the Teredo client can predict
that the external port assigned will be equal to the random port
chosen, and hence the Teredo client MUST store it in the Random
Port field of the Peer Entry.
o If the Random Port value is non-zero, the Teredo client MUST
append a Random Port Trailer to the indirect bubble.
5.3.4.3. Sending a Direct Bubble
The rules for when direct bubbles are sent to a Teredo peer are as
specified in [RFC4380] section 5.2.6. In addition, Section 5.1.4.2
defines rules for enabling communication for clients positioned
behind a symmetric NAT. In addition to the rules defined in both the
aforementioned sections, if the Port Preserving NAT Flag is TRUE, the
following rules apply also.
If the Symmetric NAT flag is set, and the Teredo peer is not marked
as "trusted" (as specified in [RFC4380] section 5.2) the Teredo
client MUST send a direct bubble destined to the mapped address/port
embedded in the Teredo IPv6 address of the Teredo peer. (This direct
bubble will contain the Nonce Trailer (section 2.2.1).) If the peer
Random Port field is non-zero, the Teredo client MUST send another
direct bubble from its own random port, destined to the peer random
port. The IPv4 destination address MUST be the mapped address
embedded in the Teredo IPv6 address. In addition, the Teredo client
MUST include the Random Port Trailer (section 2.2.5).
5.3.4.4. Receiving an Indirect Bubble
The rules for processing an indirect bubble are as specified in
Section 5.1.4.3 and [RFC4380] section 5.2.3. In addition to these
rules, if the incoming indirect bubble has a Random Port Trailer, the
following additional processing MUST be done.
If the Peer Random Port field of the Peer Entry is zero, the Teredo
client MUST store the port from the Random Port Trailer in the Peer
Random Port field of the Peer Entry.
If the Peer Random Port field is non-zero and if either the Peer
Random Port field and the new advertised port have the same value, or
if active data has been exchanged between the two Teredo clients in
the last 30 seconds (that is, "time of last transmission" or "time of
Thaler Expires May 5, 2009 [Page 27]
Internet-Draft Teredo Extensions November 2008
last reception," as specified in [RFC4380] section 5.2, is set to a
time that is less than 30 seconds ago), the new advertised port value
MUST be ignored.
If the Peer Random Port field is non-zero and the new advertised port
value is different from the Peer Random Port value, and it has been
more than 30 seconds since the last exchange of data packets between
the two Teredo clients, (that is, "time of last transmission" and
"time of last reception" are set to a time that is more than 30
seconds ago), the Teredo client SHOULD store the new advertised port
value in the Peer Random Port field and, if the Port-Preserving NAT
Flag is TRUE, then clear the Random Port field, and stop listening on
the old random port. This allows communication to be reestablished
if either side changes the random port that it is using.
5.3.4.5. Receiving a Direct Bubble
The rules for handling direct bubbles are specified in
Section 5.1.4.4 and [RFC4380] section 5.2.3. The rules for whether
to accept a direct bubble are extended as follows, when the Port-
Preserving NAT Flag is TRUE:
o If the direct bubble is received on the primary port and the
Teredo peer is not "trusted," the status field of the Teredo
client MUST be changed to "trusted" and the Direct Receive on
Primary Port flag MUST be set to TRUE. The mapped address/port
from which the direct bubble was received MUST be recorded in the
mapped address/port fields of the Teredo peer, as specified in
[RFC4380] section 5.2. The Teredo client MUST then set the Random
Port field in the Peer Entry to zero and stop listening on the old
random port.
o If the direct bubble is received on the primary port, the Teredo
peer is "trusted," and the Direct Receive on Primary flag is set
to TRUE, the Teredo client MUST compare the mapped address/port of
the direct bubble with the mapped address/port of the Peer Entry.
If both mappings are the same, the direct bubble MUST be accepted.
If the mappings are different and it has been more than 30 seconds
since the last packet exchange with the Teredo peer (that is,
"time of last transmission" and "time of last reception," as
defined in [RFC4380] section 5.2, are set to a time that is more
than 30 seconds ago), the mapping on the Teredo peer's NAT has
changed and communication needs to be reestablished. This MUST be
done by changing the status of the peer to "not-trusted", setting
the Direct Receive on Primary Port flag to FALSE, and sending an
indirect bubble to the Teredo peer via its Teredo server.
o If the direct bubble is received on the primary port, the Teredo
peer is "trusted," the Direct Receive on Primary Port flag is set
to FALSE, and the Direct Receive on Random Port flag is set to
TRUE, the mapped address/port from which the direct bubble is
Thaler Expires May 5, 2009 [Page 28]
Internet-Draft Teredo Extensions November 2008
received MUST be stored in the mapped address/port fields of the
Peer Entry. The Direct Receive on Primary Port flag MUST be set
to TRUE. The Teredo client MUST then set the Random Port field in
the Peer Entry to zero and stop listening on the old random port.
Finally, the Direct Receive on Random Port flag MUST be set to
FALSE.
o If the direct bubble is received on the random port and the Teredo
peer is not "trusted," the status field of the Teredo client MUST
be changed to "trusted" and the Direct Receive on Random Port flag
MUST be set to TRUE. The mapped address/port from which the
direct bubble was received MUST be recorded in the mapped address/
port fields of the Teredo Peer Entry, as specified in [RFC4380]
section 5.2.
o If the direct bubble is received on the random port, the Teredo
peer is "trusted," the Direct Receive on Primary Port flag is
FALSE, and the Direct Receive on Random Port flag is set to TRUE,
the Teredo client MUST compare the mapped address/port in the
direct bubble with the mapped address/port in the Peer Entry. If
the two mappings are the same, the direct bubble MUST be accepted.
If the mappings are different, it implies that the NAT had deleted
the mapping and when it reassigned the mapping, a different
external port was chosen. In this instance the Teredo client
SHOULD set the Random Port field to zero, stop listening on the
old random port, and send an indirect bubble to the Teredo peer as
specified in Section 5.3.4.2.
5.4. Sequential Port-Symmetric NAT Extension
The Sequential Port-Symmetric NAT Extension is optional; an
implementation SHOULD support it. This extension has the Symmetric
NAT Support Extension (Section 5.1) as a dependency. Any node that
implements this extension MUST also implement the Symmetric NAT
Support Extension, as well as the Port-Preserving NAT Extension
(Section 5.3).
5.4.1. Abstract Data Model
This section describes a conceptual model of possible data
organization that an implementation maintains to participate in this
protocol. The described organization is provided to facilitate the
explanation of how the protocol behaves. This document does not
mandate that implementations adhere to this model as long as their
external behavior is consistent with that described in this document.
The Sequential Port-Symmetric NAT Extension extends the abstract data
model in Section 5.3.1 by adding the following additional state.
Peer Entry: The following fields need to be added on a per-peer
Thaler Expires May 5, 2009 [Page 29]
Internet-Draft Teredo Extensions November 2008
basis:
o EchoTestNonce1: The value of the nonce sent as part of the
authentication encapsulation, as specified in [RFC4380] section
5.1.1, in the router solicitation packet sent to the Teredo server
address as part of the Echo Test.
o EchoTestNonce2: The value of the nonce sent as part of the
authentication encapsulation in the router solicitation packet
sent to the secondary Teredo server address as part of the Echo
Test.
o EchoTestLowerPort: The value of the external port mapping
extracted from the origin indication of the router advertisement
received from the Teredo server address as part of the Echo Test.
A value of 0 indicates that no such router advertisement has been
received.
o EchoTestUpperPort: The value of the external port mapping
extracted from the origin indication of the router advertisement
received from the secondary Teredo server address as part of the
Echo Test. A value of 0 indicates that no such router
advertisement has been received.
o EchoTestRetryCounter: The number of times an Echo Test has been
attempted.
5.4.2. Timers
In addition to those in Section 5.3.2, the following additional timer
is required per Peer entry.
Echo Test Failover Timer: A one-shot timer that is running whenever
an Echo Test is in progress.
5.4.2.1. Refresh Timer Expiry
The processing of the Refresh Timer Expiry MUST be completed as
specified in Section 5.3.2.1. In addition to those rules, the Teredo
client MUST set the EchoTestLowerPort, EchoTestUpperPort, and
EchoTestRetryCounter to zero.
5.4.2.2. Echo Test Failover Timer Expiry
If the Echo Test Failover Timer expires, the Teredo client MUST do
the following.
If the value of the EchoTestRetryCounter is two, then the Teredo
client MUST send an indirect bubble as specified in Section 5.1.4.1.
If the value of the EchoTestRetryCounter is one, then the Teredo
client MUST start another Echo Test as specified in
Section 5.4.4.1.1.
Thaler Expires May 5, 2009 [Page 30]
Internet-Draft Teredo Extensions November 2008
5.4.3. Initialization
No behavior changes are required beyond what is specified in
Section 5.3.3.
5.4.4. Message Processing
Except as specified in the following sections, the rules for message
processing are as specified in Section 5.3.4.
5.4.4.1. Handling a Request to Send an Indirect Bubble
Whenever [RFC4380] or other extensions specified in this document
specify that an indirect bubble is to be sent, the following actions
apply at that time instead if the Symmetric NAT Flag is TRUE and the
Port-Preserving NAT Flag is FALSE. Note that any behavior specified
by [RFC4380] or other extensions in this document still applies to
how indirect bubbles are constructed, but such behavior is done at a
later time as specified in Section 5.4.4.3 and Section 5.4.2.1 below.
If the Symmetric NAT Flag is TRUE, and the Port Preserving NAT Flag
is FALSE, then the Teredo client MUST select a random port number to
use, begin listening on that port, and start an Echo Test as
specified below.
5.4.4.1.1. Starting an Echo Test
To start an Echo Test, the Teredo client MUST send the following
three packets from this port:
o First, a router solicitation (as specified in [RFC4380] section
5.2.1) MUST be sent to the Teredo server address. The router
solicitation MUST include an authentication encapsulation with a
randomly-generated Nonce field, as specified in [RFC4380] section
5.1.1. The nonce included in the authentication encapsulation
MUST then be stored in the EchoTestNonce1 field of the Peer entry.
o Second, a direct bubble MUST be sent to the peer.
o Third, a router solicitation MUST be sent to the secondary Teredo
server address. The router solicitation MUST include an
authentication encapsulation with a randomly-generated Nonce
field, as specified in [RFC4380] section 5.1.1. The nonce
included in the authentication encapsulation MUST then be stored
in the EchoTestNonce2 field of the Peer entry.
The Teredo client MUST then increment the EchoTestRetryCounter and
set the Echo Test Failover Timer to expire in a number of seconds
equal to EchoTestRetryCounter.
Thaler Expires May 5, 2009 [Page 31]
Internet-Draft Teredo Extensions November 2008
5.4.4.2. Receiving a Direct Bubble
The processing of the direct bubble MUST be completed as specified in
Section 5.3.4.5, as if the Port Preserving NAT Flag was TRUE. After
the processing is complete, if the Direct Bubble Received on Primary
flag is TRUE, and the Echo Test Failover Timer is running, then the
Echo Test Failover Timer MUST be cancelled and EchoTestLowerPort,
EchoTestUpperPort, and EchoTestRetryCounter MUST be set to zero.
5.4.4.3. Receiving a Router Advertisement
The rules for processing a router advertisement are as specified in
[RFC4380] section 5.2.1. In addition to those rules, if the router
advertisement contains an authentication encapsulation, the Teredo
client MUST look for a Peer entry whose EchoTestNonce1 or
EchoTestNonce2 field matches the nonce in the authentication
encapsulation. If a Peer entry is found, the Teredo client MUST do
the following.
If the received nonce is equal to EchoTestNonce1 and
EchoTestLowerPort is zero, then EchoTestLowerPort MUST be set to the
external port mapping extracted from the origin indication of this
router advertisement.
If the received nonce is equal to EchoTestNonce2 and
EchoTestUpperPort is zero, then EchoTestUpperPort MUST be set to the
external port mapping extracted from the origin indication of this
router advertisement.
If the EchoTestUpperPort and EchoTestLowerPort are now both nonzero,
the Teredo client MUST then set the Random Port field of the Peer
Entry to (EchoTestUpperPort + EchoTestUpperPort)/2, rounded down, and
send an indirect bubble as specified in Section 5.3.4.2.
5.5. Hairpinning Extension
This extension is optional; an implementation SHOULD support it.
5.5.1. Abstract Data Model
This section describes a conceptual model of possible data
organization that an implementation maintains to participate in this
protocol. The described organization is provided to facilitate the
explanation of how the protocol behaves. This document does not
mandate that implementations adhere to this model as long as their
external behavior is consistent with that described in this document.
In addition to the state specified in [RFC4380] section 5.2, the
Thaler Expires May 5, 2009 [Page 32]
Internet-Draft Teredo Extensions November 2008
following are also required:
UPnP Mapped Address/Port: The mapped address/port assigned via UPnP
to the Teredo client by the UPnP-enabled NAT behind which the Teredo
client is positioned. This field has a valid value only if the NAT
to which the Teredo client is connected is UPnP-enabled. In
addition, if the Teredo client is positioned behind a single NAT only
(as opposed to a series of nested NATs), this value will be the same
as the mapped address/port embedded in its Teredo IPv6 address.
Peer Entry: Per-peer state is extended beyond what is described in
[RFC4380] by including the following:
o Alternate Address/Port list: The list of alternate address/port
pairs advertised by the peer.
5.5.2. Timers
No timers are necessary other than those in [RFC4380].
5.5.3. Initialization
Behavior is as specified in [RFC4380], with the following additions.
Prior to beginning the qualification procedure, the Teredo client
MUST invoke the AddPortMapping function (as specified in [UPNPWANIP]
section 2.4.16) with the parameters specified in Section 5.2.3. If
successful, it indicates that the NAT has created a port mapping from
the external port of the NAT to the internal port of the Teredo
client node. If the AddPortMapping function is successful, the
Teredo client MUST store the mapping assigned by the NAT in its UPnP
Mapped Address/Port state.
After the qualification procedure, the mapped address/port learned
from the Teredo server MUST be compared to the UPnP Mapped Address/
Port. If both are the same, the Teredo client is positioned behind a
single NAT and the UPnP Mapped Address/Port MUST be zeroed out.
5.5.4. Message Processing
5.5.4.1. Sending an Indirect Bubble
The rules for when indirect bubbles are sent to a Teredo peer are as
specified in [RFC4380] section 5.2.6. If communication between a
Teredo client and a Teredo peer has not been established, the Teredo
client MUST include the Alternate Address Trailer in the indirect
bubble. The Alternate Address Trailer MUST include the node's local
address/port in the Alternate Address/Port list. If the UPnP Mapped
Address/Port is non-zero, the Alternate Address Trailer MUST also
Thaler Expires May 5, 2009 [Page 33]
Internet-Draft Teredo Extensions November 2008
include it in the list.
Hairpinning requires "direct IPv6 connectivity tests" (as specified
in [RFC4380] section 5.2.9) to succeed before it can accept packets
from an IPv4 address and port not embedded in the Teredo IPv6
address. Hence the indirect bubble MUST also include a Nonce
Trailer.
5.5.4.2. Receiving an Indirect Bubble
The rules for processing indirect bubbles are as specified in
[RFC4380] section 5.2.3. In addition to those rules, when a Teredo
client receives an indirect bubble with the Alternate Address
Trailer, it SHOULD first verify that the Alternate Address Trailer is
correctly formed (as specified in Section 4.2), and drop the bubble
if not. Otherwise, it MUST set the Alternate Address/Port list in
its Peer Entry to the list in the trailer. The Teredo client,
besides sending direct bubbles to the mapped address/port embedded in
the Teredo IPv6 address (as specified in [RFC4380] section 5.2.6),
MUST also send a direct bubble to each mapped address/port advertised
in the Alternate Address Trailer.
In each of the direct bubbles, the Teredo client MUST include a Nonce
Trailer with the nonce value received in the indirect bubble.
5.5.4.3. Receiving a Direct Bubble
If the mapped address/port of the direct bubble matches the mapped
address/port embedded in the source Teredo IPv6 address, the direct
bubble MUST be accepted, as specified in [RFC4380] section 5.2.3.
If the mapped address/port does not match the embedded address/port,
but the direct bubble contains a Nonce Trailer with a nonce that
matches the Nonce Sent field of the Teredo peer, the direct bubble
MUST be accepted.
If neither of the above rules match, the direct bubble MUST be
dropped.
5.6. Server Load Reduction Extension
This extension is optional; an implementation SHOULD support it.
5.6.1. Abstract Data Model
This section describes a conceptual model of possible data
organization that an implementation maintains to participate in this
protocol. The described organization is provided to facilitate the
Thaler Expires May 5, 2009 [Page 34]
Internet-Draft Teredo Extensions November 2008
explanation of how the protocol behaves. This document does not
mandate that implementations adhere to this model as long as their
external behavior is consistent with that described in this document.
In addition to the state specified in [RFC4380] section 5.2, the
following are also required:
Peer Entry: The following state needs to be added on a per-peer
basis:
o Count of Solicitations Transmitted: The number of Solicitation
packets sent.
5.6.2. Timers
Retransmission Timer: A timer used to retransmit Teredo Neighbor
Solicitation packets.
When the retransmission timer expires, the Teredo client MUST
retransmit a direct bubble with a Neighbor Discovery Option Trailer,
and increment the Count of Solicitations Transmitted. If the count
is less than three, it MUST then reset the timer to expire in two
seconds. Otherwise (if the count is now three), it MUST send an
indirect bubble to the Teredo peer to reestablish connectivity as if
no communication between the Teredo client and the Teredo peer had
been established.
5.6.3. Initialization
No initialization is necessary other than that specified in
[RFC4380].
5.6.4. Message Processing
Except as specified below, processing is the same as specified in
[RFC4380].
5.6.4.1. Sending a Data Packet
Upon receiving a data packet to be transmitted to the Teredo peer,
the Teredo client MUST determine whether data has been exchanged
between the Teredo client and peer in either direction in the last 30
seconds (using the state as specified in [RFC4380] section 5.2). If
not, the Teredo client MUST send a direct bubble with a Neighbor
Discovery Option Trailer having the DiscoveryType field set to
TeredoDiscoverySolicitation. The Count of Solicitations Transmitted
field MUST be set to 1. The retransmission timer MUST be set to
expire in two seconds.
Thaler Expires May 5, 2009 [Page 35]
Internet-Draft Teredo Extensions November 2008
5.6.4.2. Receiving a Direct Bubble
The rules for processing direct bubbles are as specified in [RFC4380]
section 5.2.3. In addition to those rules, upon receiving a direct
bubble containing a Neighbor Discovery Option Trailer with
DiscoveryType field set to TeredoDiscoverySolicitation, the Teredo
client MUST respond with a direct bubble with the Neighbor Discovery
Option Trailer having the DiscoveryType field set to
TeredoDiscoveryAdvertisement.
6. Protocol Examples
The following sections describe several operations as used in common
scenarios to illustrate the function of Teredo Extensions.
6.1. Symmetric NAT Support Extension
The following protocol example illustrates the use of the Symmetric
NAT Support Extension.
In Figure 2 (Section 3.1), assume that Teredo Client A, which is
positioned behind a port-symmetric NAT, wants to communicate with
Teredo Client B, which is positioned behind an address-restricted
NAT.
The qualification procedure where the Teredo client determines that
it is positioned behind a symmetric NAT is exactly the same as that
specified in [RFC4380] section 5.2.1. Because of the Symmetric NAT
Extension, Client A continues to configure a Teredo IPv6 address even
after determining that the Teredo client is positioned behind a
symmetric NAT.
Next the following packet exchange helps Teredo Client A (A)
establish communication with Teredo Client B (B).
Thaler Expires May 5, 2009 [Page 36]
Internet-Draft Teredo Extensions November 2008
Teredo Client A's Client B's Teredo
Client Teredo Teredo Client
A NAT Server Server NAT B
| | | | | |
| | | Direct Bubble to B | | |
1 |--------------------------------------------------->| |
| | | | | |
|Indirect Bubble to B via B's Teredo Server| | |
2 |----------------------------------------->|----------------->|
| | | | | |
| | | Direct Bubble to A | | |
| |<--------------------------------------------------| 3
| | | | | |
| | |Indirect Bubble to A via A's Teredo Server|
|<-----------------|<-----------------------------------------| 4
| | | | | |
| | | Direct Bubble to B | | |
5 |------------------------------------------------------------>|
| | | | | |
|Indirect Bubble to B via B's Teredo Server| | |
6 |----------------------------------------->|----------------->|
| | | | | |
| | | Direct Bubble to A | | |
|<------------------------------------------------------------| 7
| | | | | |
Port-Symmetric NAT to Address-Restricted NAT Packet Exchange
1. A sends a direct bubble (Packet 1) destined to the mapped
address/port embedded in B's Teredo IPv6 address. The mapped
port in the source field of the packet assigned by client A's
NAT is different from the mapped port embedded in A's Teredo
IPv6 address. This is characteristic of the port-symmetric NAT
positioned in front of A. The mapped address in the source field
of the packet is the same as the mapped address embedded in the
Teredo IPv6 address of A.
2. The aforementioned direct bubble is dropped by B's NAT because
it has not seen an outgoing packet destined to A's mapped IPv4
address.
3. A sends an indirect bubble (Packet 2) destined to B via client
B's Teredo server.
4. The above-mentioned indirect bubble is received by B. B then
responds with the following packets. The first packet sent by B
is a direct bubble (Packet 3) destined to the mapped address/
port embedded in A's Teredo IPv6 address.
5. The above-mentioned direct bubble is dropped by A's NAT because
the NAT has not seen any outgoing packet sourced from the mapped
address/port embedded in A's Teredo IPv6 address and destined to
the mapped address/port embedded in B's Teredo IPv6 address.
Thaler Expires May 5, 2009 [Page 37]
Internet-Draft Teredo Extensions November 2008
6. B also sends an indirect bubble (Packet 4) destined to A via A's
Teredo Server.
7. The aforementioned indirect bubble is successfully received by
A. A responds to the indirect bubble with its own direct bubble
(Packet 5). This direct bubble is exactly the same as the first
direct bubble (Packet 1) sent by A.
8. This time around the aforementioned direct bubble is accepted by
B's NAT because the NAT has seen an outgoing packet (Packet 3)
sourced from the mapped address/port embedded in B's Teredo IPv6
address and destined to the mapped address/port embedded in A's
Teredo IPv6 address. It is important to remember that A's NAT
is port-symmetric and therefore varies only the mapped port
while the mapped address remains the same. B's NAT is address-
restricted and cares only about prior communication with the
IPv4 address, not the specific port. At this point,
communication in one direction is now possible (B to A, but not
vice versa).
9. After receiving the direct bubble, B remembers the new mapped
address/port that was in the source fields of the direct bubble
and uses those for future communication with A instead of the
mapped address/port embedded in A's Teredo IPv6 address.
10. A then times out and resends an indirect bubble (Packet 6) and
in response, B sends a direct bubble (Packet 7). This direct
bubble is destined to the new learned mapped address/port and
hence A's NAT permits the direct bubble through. Communication
is now possible in the other direction (client A to B).
6.2. UPnP-enabled Symmetric NAT Extension
The following protocol example illustrates the use of the UPnP-
Enabled Symmetric NAT Extension in addition to the Symmetric NAT
Support Extension.
Assume that Teredo Client A, which is positioned behind a UPnP-
enabled port-symmetric NAT, wants to communicate with Teredo Client
B, which is also positioned behind a UPnP-Enabled port-symmetric NAT.
Before both clients start their qualification procedure, they use
UPnP to reserve port mappings on their respective NATs. The UPnP
operations succeed for both the clients and the clients hence know
that they are positioned behind UPnP-enabled NATs. After the
qualification procedure, both clients have valid Teredo IPv6
addresses because they both support the Symmetric NAT Support
Extension. Also, after the qualification procedure both clients will
compare their mapped address/port determined through UPnP with the
mapped address/port determined through the qualification procedure.
Because both will be the same, the clients will zero out their UPnP
mapped address/port values and conclude that they are each located
Thaler Expires May 5, 2009 [Page 38]
Internet-Draft Teredo Extensions November 2008
behind a single UPnP-enabled NAT.
The following packet exchange shows Teredo client A (A) establishing
communication with Teredo client B (B).
Teredo Client A's Client B's Teredo
Client Teredo Teredo Client
A NAT Server Server NAT B
| | | | | |
| | | Direct Bubble to B | | |
1 |------------------------------------------------------------>|
| | | | | |
|Indirect Bubble to B via B's Teredo Server| | |
2 |----------------------------------------->|----------------->|
| | | | | |
| | | Direct Bubble to A | | |
|<------------------------------------------------------------| 3
| | | | | |
UPnP-enabled Symmetric NAT Packet Exchange
1. A sends a direct bubble (Packet 1) to the mapped address/port
embedded in B's Teredo IPv6 address. Because A's NAT is a
symmetric NAT, the UDP source port field in the packet assigned
by A's NAT is different from the mapped port embedded in A's
Teredo IPv6 address, but the IPv4 source address of the packet is
the same as the mapped address embedded in A's Teredo IPv6
address.
2. The above-mentioned direct bubble is received by B because it is
destined for the UPnP mapped address/port of B and hence is let
through by the NAT. At this point, B deduces that A is
positioned behind a symmetric NAT because the mapped address/port
from which the direct bubble is received is different from the
mapped address/port that is embedded in A's Teredo IPv6 address.
B also knows that itself is positioned behind a UPnP-enabled
symmetric NAT. Hence, instead of storing the mapped address/port
from which the direct bubble was received, it stores the mapped
address/port embedded in A's Teredo IPv6 Address for further
communication with A. At this point, communication in one
direction is now possible (B to A, but not vice versa).
3. A also sends an indirect bubble (Packet 2) destined to B via B's
Teredo Server.
4. The above indirect bubble is received by B. B then responds with
a direct bubble (Packet 3) destined to the mapped address/port
embedded in A's Teredo IPv6 address, as in step 2.
5. Because A's NAT is also UPnP-enabled, the above-mentioned direct
bubble is received by A. A also notices that B is positioned
behind a Symmetric NAT because the mapped address/port from which
Thaler Expires May 5, 2009 [Page 39]
Internet-Draft Teredo Extensions November 2008
the packet is received is different from the mapped address/port
embedded in B's Teredo IPv6 address. Because A knows it is
positioned behind a UPnP-enabled symmetric NAT, it records the
mapped address/port embedded in B's Teredo IPv6 address for
further communication with B. At this point, communication is now
possible in the other direction (A to B).
6.3. Port-Preserving Symmetric NAT Extension
The following protocol example illustrates the use of the Port-
Preserving Symmetric NAT Extension.
Assume that Teredo Client A (A), which is positioned behind a port-
preserving symmetric NAT, wants to communicate with Teredo Client B
(B), which is also positioned behind a port-preserving symmetric NAT.
The following packet exchange explains the configuration setup and
communication setup between the two clients.
Thaler Expires May 5, 2009 [Page 40]
Internet-Draft Teredo Extensions November 2008
Teredo Client A's Client B's Teredo
Client Teredo Teredo Client
A NAT Server Server NAT B
| | | | | |
| | | Direct Bubble to B | | |
1 |--------------------------------------------------->| |
| | | | | |
|Indirect Bubble to B via B's Teredo Server| | |
2 |----------------------------------------->|----------------->|
| | | | | |
| | | Direct Bubble to A | | |
| |<--------------------------------------------------| 3
| | | | | |
| | | Direct Bubble to A | | |
| |<--------------------------------------------------| 4
| | | | | |
| | |Indirect Bubble to A via A's Teredo Server|
|<-----------------|<-----------------------------------------| 5
| | | | | |
| | | Direct Bubble to B | | |
6 |--------------------------------------------------->| |
| | | | | |
| | | Direct Bubble to B | | |
7 |------------------------------------------------------------>|
| | | | | |
|Indirect Bubble to B via B's Teredo Server| | |
8 |----------------------------------------->|----------------->|
| | | | | |
| | | Direct Bubble to A | | |
|<------------------------------------------------------------| 9
| | | | | |
Port-Preserving Symmetric NAT Packet Exchange
1. During the qualification procedure, when the clients receive a
response from the Teredo server, they compare the Port value in
the Origin indication with the Local Port value. If both values
match, the clients set the Port-Preserving NAT flag to TRUE.
2. When the response is received from the secondary Teredo server,
the mapped address/port value in the Origin indication is
compared with the mapped address/port value learned from the
response received from the primary server. If the mappings are
different, the Symmetric NAT flag is set to TRUE.
3. It is assumed that for both clients A and B, the Port-Preserving
NAT flag and the Symmetric NAT flag are set to TRUE at the end
of the qualification procedure.
Thaler Expires May 5, 2009 [Page 41]
Internet-Draft Teredo Extensions November 2008
4. Before A sends packets to B, A checks to see if it is positioned
behind a port-preserving NAT and a symmetric NAT, which in the
example, it is. A also checks to see if the peer is "trusted,"
but it currently is not. Next, A checks if the Random Port is
set to non-zero. Since it is still zero, A allocates a new
random port, begins listening on it, and stores the value in the
Random Port field.
5. A sends a direct bubble (Packet 1) from the primary port to the
mapped address/port embedded in B's Teredo IPv6 Address. This
direct bubble does not have a Nonce Trailer or a Random Port
Trailer attached to the end.
6. The aforementioned direct bubble is dropped by B's NAT because
the NAT has not seen an outgoing packet destined to A's mapped
address.
7. A sends an indirect bubble (Packet 2) destined to B via client
B's Teredo server. This indirect bubble contains two trailers:
the Nonce Trailer containing a random nonce, and the Random Port
Trailer containing the random port value from the Peer Entry.
The nonce used in the Nonce Trailer is also stored in the Nonce
Sent field of the Peer Entry.
8. The aforementioned indirect bubble is received by B. B adds the
Teredo peer to its peer list. B saves the nonce value from the
Nonce Trailer in the Nonce Advertised field of the Peer Entry.
B stores the port value from the Random Port Trailer in the Peer
Random Port field in the Peer Entry.
9. B responds by sending the following packets. The first packet
sent by B is a direct bubble (Packet 3) destined to the mapped
address/port embedded in A's Teredo IPv6 Address. This packet
is sent from the primary port. It includes the Nonce Trailer
with the nonce from the Nonce Advertised field of the Peer
Entry.
10. The aforementioned direct bubble is dropped by A's NAT because
the NAT has not seen any outgoing packet sourced from the mapped
address/port embedded in A's Teredo IPv6 Address and destined to
the mapped address/port embedded in B's Teredo IPv6 Address.
11. B then checks if it is positioned behind a port-restricted NAT
or a symmetric NAT. It also checks if the peer has already
advertised a random port. In this case, B is positioned behind
a port-preserving symmetric NAT and the peer has advertised a
random port; hence it needs to use a random port. It checks if
its Random Port field is set to non-zero. Since it is still
zero, B allocates a new random port, begins listening on it, and
stores it in the Random Port entry of the Peer Entry. B then
sends a direct bubble (Packet 4) destined to the mapped address
embedded in A's Teredo IPv6 address and the port stored in the
Peer Random Port field of the Peer Entry. The direct bubble is
sent from its own random port.
Thaler Expires May 5, 2009 [Page 42]
Internet-Draft Teredo Extensions November 2008
12. The above direct bubble is dropped by A's NAT because the NAT
has not seen any outgoing packet sourced from the mapped address
embedded in A's Teredo IPv6 address and random port advertised
by A.
13. B also sends an indirect bubble (Packet 5) destined to A via A's
Teredo server. This indirect bubble includes a Nonce Trailer
and a Random Port Trailer. The Nonce Trailer includes a new
randomly generated nonce that is also stored in the Nonce Sent
field of the Peer Entry. The Random Port Trailer includes the
value in the Random Port field of the Peer Entry.
14. The aforementioned indirect bubble is successfully received by
A. A parses the trailers and stores the nonce contained in the
Nonce Trailer in the Nonce Received field of the Peer Entry. A
stores the port advertised in the Random Port Trailer in the
Random Port field of the Peer Entry.
15. A responds with the following packets in response to the
indirect bubble received. The first packet is a direct bubble
(Packet 6) sent from the primary port and is destined to the
mapped address/port embedded in B's Teredo IPv6 Address.
16. The aforementioned direct bubble again is dropped by B's NAT
because the NAT has not seen an outgoing packet with the same
4-tuple as the incoming packet.
17. The next packet is also a direct bubble (Packet 7) and this one
is sent from A's random port. The packet is destined to the
mapped address embedded in B's Teredo IPv6 address and the Peer
Random Port stored in the Peer Entry.
18. Because both NATs are port-preserving NATs and the random ports
have not been used for any other mapping, the aforementioned
direct bubble is received by B because B's NAT has seen an
outgoing packet (Packet 4) with the same address/port pairs. B
stores the address/port from which the direct bubble was
received in the mapped address/port fields of the Peer Entry.
It changes the status of the peer to "trusted" and sets the
Direct Receive on Random Port field to TRUE. At this point,
communication in one direction is now possible (B to A, but not
vice versa).
19. Because A still considers B to be "not-trusted," it times out
and retransmits an indirect bubble (Packet 8). This packet
contains a new nonce as part of the Nonce Trailer and also
contains the value of the random port as part of the Random Port
Trailer.
20. B receives the aforementioned indirect bubble. The processing
of this indirect bubble is similar to the processing of Packet
2. Since B received a direct bubble on its random port, it does
not respond with a direct bubble from its primary port.
Instead, it responds with a direct bubble (Packet 9) sent from
its random port, which is similar to Packet 4 mentioned above.
Thaler Expires May 5, 2009 [Page 43]
Internet-Draft Teredo Extensions November 2008
21. A receives the direct bubble sent by B. A stores the mapped
address/port from which the direct bubble was received in mapped
address/port fields in the Peer Entry. A changes the status of
B to "trusted" and sets the Direct Receive on Random Port field
to TRUE. At this point, the communication is now possible in
the other direction (A to B).
6.4. Sequential Port-Symmetric NAT Extension
The following protocol example illustrates the use of the Sequential
Port-Symmetric NAT Extension.
Assume that Teredo Client A (A), which is positioned behind a
sequential port-symmetric NAT and implements the Sequential Port-
Symmetric NAT Extension, wants to communicate with Teredo Client B
(B), which is positioned behind a port-restricted NAT that supports
the Port-Preserving Port-Symmetric NAT Extension. The following
packet exchange explains the configuration setup and communication
setup between the two clients.
Thaler Expires May 5, 2009 [Page 44]
Internet-Draft Teredo Extensions November 2008
Teredo A's A's B's
Client Primary Secondary Teredo Client
A NAT Server Server Server NAT B
| | | | | | |
| Direct Bubble to B | | | | |
1 |-------------------------------------------------->| |
| | | | | | |
|Router Solicitation | | | | |
2 |------------------->| | | | |
| | | | | | |
|Router Advertisement| | | | |
|<-------------------| 3 | | | |
| | | | | | |
4 | Direct Bubble to B | | | | |
|-------------------------------------------------->| |
| | | | | | |
| Router Solicitation | | | |
5 |---------------------------->| | | |
| | | | | | |
| Router Advertisement | | | |
|<----------------------------| 6 | | |
| | | | | | |
| Indirect Bubble to B via B's Teredo Server | | |
7 |------------------------------------------->|-------------->|
| | | | | | |
| | | | Direct Bubble to A |
| |<-------------------------------------------------| 8
| | | | | | |
| | | | Indirect Bubble to A |
|<-------------------|<--------------------------------------| 9
| | | | | | |
| | | | Direct Bubble to A |
|<-----------------------------------------------------------| 10
| | | | | | |
| Direct Bubble to B | | | |
11 |----------------------------------------------------------->|
Sequential Port-Symmetric NAT Packet Exchange
1. During the qualification procedure, when the clients receive a
response from the Teredo server, they compare the Port value in
the Origin indication with the Local Port value. Since they were
different for Client A, it concluded that it is not behind a port
preserving NAT, and so assumed it is behind a sequential port-
symmetric NAT.
2. When A wants to communicate with B, A starts by sending a direct
bubble (Packet 1) from its primary port. This occurs because
Client A does not know Client B's NAT type, which could be a cone
Thaler Expires May 5, 2009 [Page 45]
Internet-Draft Teredo Extensions November 2008
or address restricted NAT or UPnP-enabled NAT. Because Client A
is behind a symmetric NAT, the external port used by A's NAT is a
new port. This direct bubble will be dropped by B's NAT since
Client B is behind a port-restricted NAT.
3. Because Client A does not know if B is behind a port restricted
NAT or some other kind of NAT, Client A proactively opens a new
random internal port, say, port 1100.
4. Client A then performs its Echo Test as follows:
A. Client A sends a router solicitation (Packet 2) to its Teredo
server address from port 1100. The server responds with a
router advertisement (Packet 3).
B. Client A sends a direct bubble (Packet 4) to the peer from
port 1100 destined to the port advertised in Client B's
Teredo address, say, port 2100. This direct bubble is
dropped by Client B's port-restricted NAT.
C. Client A sends a router solicitation (Packet 5) to its
secondary Teredo server address from port 1100. The server
responds with a router advertisement (Packet 6).
D. On receiving the corresponding router advertisements for
Packet 2 and Packet 4, Client A knows that port 1100 maps to,
say, port 1200 for Packet 2 and port 1202 for Packet 4.
E. Client A then calculates its predicted port used for Packet 2
as the average (rounded down) of 1200 and 1202, i.e., 1201.
5. Client A then sends out an indirect bubble (Packet 7). This
indirect bubble contains a random port trailer that contains the
predicted port, port 1201. This indirect bubble makes it to
Client B.
6. Client B sends out the following bubbles in response to the
indirect bubble:
A. The first direct bubble (Packet 8) is destined for the port
mapping embedded in Client A's Teredo Address. (It has been
observed that some NATs display symmetric NAT behavior for
outgoing packets but cone NAT behavior for incoming packets.
The direct bubble described is likely to succeed if Client
A's NAT displays such a behavior.) Since in this example,
A's NAT is a normal sequential port-symmetric NAT, this
packet is dropped.
B. The second packet is an indirect bubble (Packet 9) sent to
Client A without any trailers since Client B is behind a
port-restricted NAT.
C. The next packet will be a direct bubble (Packet 10) sent to
port 1201. This packet will make it in to Client A since
Client A previously sent an outgoing packet (Packet 4) with
the same four tuple. At this point, communication in one
direction is now possible (A to B, but not vice versa).
7. Client A then sends a direct bubble (Packet 11) to Client B when
it receives Packet 10. This time, the bubble makes it through to
B because it previously sent an outgoing packet (Packet 10) with
Thaler Expires May 5, 2009 [Page 46]
Internet-Draft Teredo Extensions November 2008
the same four tuple. At this point, communication is now
possible in the other direction (B to A).
6.5. Hairpinning Extension
The following protocol example illustrates the use of the Hairpinning
Extension.
In Figure 3 Figure 3 (Section 3.5), Teredo Client A (A) and Teredo
Client B (B) are positioned behind different immediate NATs in a two-
layer NAT topology; that is, the outermost NAT (NAT E) is common to
both A and B but the immediate NATs that they are connected to are
different (A is connected to NAT F while B is connected to NAT G).
Further assume that the immediate NATs that A and B are connected to
are UPnP-enabled (NAT F and NAT G are UPnP-enabled). We assume that
NAT E does not support hairpinning; that is, the NAT does not relay
packets originating from the private address space and destined for
the public address of the NAT, back to the private address of the
NAT.
Before starting the qualification procedure, both A and B use UPnP to
reserve port mappings on their respective NATs. They observe that
the UPnP operation succeeds and both clients obtain valid UPnP Mapped
Address/Port values.
Next, both client A and client B implement the qualification
procedure where they determine their mapped address/port values, as
specified in [RFC4380] section 5.2.1.
A and B both compare their UPnP Mapped Address/Port values with the
mapped address/port values obtained through the qualification
procedure. Because both A and B are part of a two-layer NAT
topology, these values will be different. Hence both A and B
continue to hold on to their UPnP Mapped Address/Port.
The following packet exchange shows client A establishing
communication with client B.
Thaler Expires May 5, 2009 [Page 47]
Internet-Draft Teredo Extensions November 2008
Teredo Teredo Client A's Client B's
Client NAT Client NAT NAT Teredo Teredo
A F B G E Server Server
| | | | | | |
| | Direct Bubble to B | | | |
1 |-------------------------------------->| | |
| | | | | | |
| Indirect Bubble to B via B's Teredo Server |
2 |----------------------------------------------------------->|
| | |<----------------------------------------|
| | | | | | |
| | | Direct Bubble to A | | |
3 | | |------------------->| | |
| | | | | | |
| | | Direct | | | |
| | |Bubble to A| | | |
4 | | |---------->| | | |
| | | | | | |
| | | Direct | | | |
| | |Bubble to A| | | |
5 | | |---------->| | | |
|<-----------------------------| | | |
| | | | | | |
| | | Indirect Bubble to A | |
6 | | |---------------------------->| |
|<-----------------------------------------------| |
| | | | | | |
|Direct Bubble to B| | | | |
7 |----------------->| | | | |
| | | | | | |
Hairpinning-based Packet Exchange
1. A sends a direct bubble (Packet 1) to the mapped address/port
embedded in B's Teredo IPv6 address.
2. The aforementioned direct bubble is dropped by NAT E, because it
does not support Hairpinning.
3. A sends out an indirect bubble (Packet 2) destined to B via B's
Teredo Server. In this indirect bubble, A includes an Alternate
Address Trailer that includes both the local address/port and
the UPnP mapped address/port.
4. The aforementioned indirect bubble is received by B. After
parsing the Alternate Address Trailer, B has a total of three
addresses to communicate with: two from the Alternate Address
Trailer and one from the mapped address/port embedded in A's
Teredo IPv6 address. B then responds with the following
packets. The first packet sent by B is a direct bubble (Packet
3) destined to the mapped address/port embedded in A's Teredo
Thaler Expires May 5, 2009 [Page 48]
Internet-Draft Teredo Extensions November 2008
IPv6 address.
5. The aforementioned direct bubble will be dropped by the NAT E
because it does not support Hairpinning.
6. Because the local address/port was the first mapping in the
Alternate Address Trailer, the second direct bubble (Packet 4)
sent by B is destined to the local address/port.
7. The aforementioned direct bubble is dropped because A and B are
positioned behind different NATs and hence have their own
private address space. A's local address is not reachable from
B.
8. The next direct bubble (Packet 5) is sent by B destined to A's
UPnP mapped address/port, which is the second mapping in the
Alternate Address Trailer sent by A.
9. The aforementioned direct bubble is received by A because A's
UPnP-mapped address is reachable from B. A stores the source
address from which the direct bubble was received in the mapped
address/port fields of the Peer Entry, as defined in [RFC4380]
section 5.2. Also, the mapped address status field (as
specified in [RFC4380] section 5.2.3) is changed to "trusted."
At this point, communication in one direction is now possible (A
to B, but not vice versa).
10. B also sends an indirect bubble (Packet 6) to A via A's Teredo
server. As part of the indirect bubble, B also includes an
Alternate Address Trailer, which contains the local address/port
and the UPnP mapped address/port of B.
11. The aforementioned indirect bubble is received by A. After
parsing the Alternate Address Trailer, A adds the two addresses
in the Alternate Address Trailer to the Alternate Address List
in the Peer Entry. Because the peer's mapping is "trusted"
(point 9), A responds with only one direct bubble (Packet 7)
that is sent to the mapped address/port stored in the Peer
Entry.
12. The aforementioned direct bubble is received by B. B records the
mapped address/port from which the direct bubble was received in
the mapped address/port field in its Peer Entry, and changes the
status of the mapped address to "trusted." At this point,
communication is now possible in the other direction (B to A).
6.6. Server Load Reduction Extension
The following protocol example illustrates the use of the Server Load
Reduction Extension.
Assume that Teredo client A (A) has established communication with
Teredo Client B (B). Also assume that at some later point when no
data packets have been exchanged between both clients for more than
30 seconds, the communication needs to be reestablished because A
wants to send a data packet to B.
Thaler Expires May 5, 2009 [Page 49]
Internet-Draft Teredo Extensions November 2008
The following packet exchange helps A reestablish communication with
B.
Teredo Client A's Client B's Teredo
Client Teredo Teredo Client
A NAT Server Server NAT B
| | | | | |
| | | Direct Bubble to B | | |
1 |------------------------------------------------------------>|
| | | | | |
| | | Direct Bubble to A | | |
|<------------------------------------------------------------| 2
| | | | | |
Server Load Reduction Packet Exchange
1. A sends a direct bubble (Packet 1) with the Neighbor Discovery
Option Trailer, with the DiscoveryType field set to
TeredoDiscoverySolicitation.
2. If the mapping on either of the NATs has not expired, the direct
bubble is received by B. B parses the Neighbor Discovery Option
and because the DiscoveryType was set to
TeredoDiscoverySolicitation, B responds with a direct bubble
(Packet 2). B's direct bubble also contains the Neighbor
Discovery Option and the DiscoveryType is set to
TeredoDiscoveryAdvertisement.
3. The aforementioned direct bubble is received by A and at this
point, communication between the Teredo clients is reestablished.
7. Security Considerations
Security considerations are the same as those specified in [RFC4380]
section 7.
In addition, the Hairpinning Extension introduces the possibility of
an amplification attack if a malicious user could advertise a large
number of port mappings in the Alternate Address Trailer, resulting
in a large number of direct bubbles sent in response. Because of
this, Section 4.2 explicitly limits the number of addresses that a
Teredo client will accept.
Because the nonce in the Nonce Trailer is used (as specified in
Section 5.1.4.4) to prevent spoofing of bubbles that would result in
directing traffic to the wrong place, it is important that the nonce
be random so that attackers cannot predict its value.
Thaler Expires May 5, 2009 [Page 50]
Internet-Draft Teredo Extensions November 2008
8. IANA Considerations
[RFC Editor: please remove this section prior to publication.]
This document has no IANA Actions.
9. References
9.1. Normative References
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
February 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[UPNPWANIP]
UPnP Forum, "Internet Gateway Device (IGD) V 1.0",
November 2001,
<http://www.upnp.org/standardizeddcps/igd.asp>.
9.2. Informative References
[RFC2463] Conta, A. and S. Deering, "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6) Specification", RFC 2463, December 1998.
Thaler Expires May 5, 2009 [Page 51]
Internet-Draft Teredo Extensions November 2008
Author's Address
Dave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
Phone: +1 425 703 8835
Email: dthaler@microsoft.com
Thaler Expires May 5, 2009 [Page 52]
Internet-Draft Teredo Extensions November 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Thaler Expires May 5, 2009 [Page 53]