RFC 6081
Teredo Extensions
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 Section 5.2.1 of [RFC4380]. 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). 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.
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
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.
Hence, it remembers that the peer is positioned behind a
symmetric NAT so that data packets will be sent to the mapped
address/port embedded in A's Teredo IPv6 address, rather than the
mapped address/port from which the direct bubble was received.
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
the packet is received is different from the mapped address/port
embedded in B's Teredo IPv6 address. Hence, it remembers that
the peer is positioned behind a symmetric NAT so that data
packets will be sent to the mapped address/port embedded in B's
Teredo IPv6 address, rather than the mapped address/port from
which the direct bubble was received. 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.
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.
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.
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.
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.
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 Client A receives a
response from the Teredo Server, it compares the Port value in
the Origin indication with the Local Port value. Since they are
different, it concludes that it is not behind a port-preserving
NAT, and so assumes 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
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
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 (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 Section 5.2.1 of [RFC4380].
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.
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
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 Section 5.2
of [RFC4380]. Also, the mapped address status field (as
specified in Section 5.2.3 of [RFC4380]) is changed to
"trusted". At this point, communication in one direction (A to
B) is now possible, but not vice versa because B has not yet
marked A as trusted.
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 re-established because A
wants to send a data packet to B.
The following packet exchange helps A re-establish 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 re-
established.
7. Security Considerations
Security considerations are the same as those specified in Section 7
of [RFC4380].
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.3 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.2.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. See [RFC4086]
for further discussion of randomness requirements.
8. Acknowledgements
Thanks to Gurpreet Virdi and Poorna Gaddehosur for technical
contributions to this document, and to the V6OPS WG and Jari Arkko
for their helpful reviews.
9. IANA Considerations
IANA has created a new trailer Type registry. Requests for new
trailer Type values are made through Specification Required
[RFC5226]. Initial values are listed below.
Trailer Type Usage Reference
------------ --------------------------------- ---------
0x01 Nonce Trailer RFC 6081
0x02 Random Port Trailer RFC 6081
0x03 Alternate Address Trailer RFC 6081
0x04 Neighbor Discovery Option Trailer RFC 6081
10. References
10.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. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [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. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [UPNPWANIP] UPnP Forum, "WANIPConnection:1", November 2001, <http://www.upnp.org/standardizeddcps/documents/ UPnP_IGD_WANIPConnection%201.0.pdf>.10.2. Informative References
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.Author's Address
Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA Phone: +1 425 703 8835 EMail: dthaler@microsoft.com