6. Further Study, Use of Teredo to Implement a Tunnel Service
Teredo defines a NAT traversal solution that can be provided using
very little resource at the server. Ongoing IETF discussions have
outlined the need for both a solution like Teredo and a more
controlled NAT traversal solution, using configured tunnels to a
service provider [RFC3904]. This section provides a tentative
analysis of how Teredo could be extended to also support a configured
It may be possible to design a tunnel server protocol that is
compatible with Teredo, in the sense that the same client could be
used either in the Teredo service or with a tunnel service. In fact,
this could be done by configuring the client with:
- The IPv4 address of a Teredo server that acts as a tunnel broker
- A client identifier
- A shared secret with that server
- An agreed-upon authentication algorithm.
The Teredo client would use the secure qualification procedure, as
specified in Section 5.2.2. Instead of returning a Teredo prefix in
the router advertisement, the server would return a globally routable
IPv6 prefix; this prefix could be permanently assigned to the client,
which would provide the client with a stable address. The server
would have to keep state, i.e., memorize the association between the
prefix assigned to the client and the mapped IPv4 address and mapped
UDP port of the client.
The Teredo server would advertise reachability of the client prefix
to the IPv6 Internet. Any packet bound to that prefix would be
transmitted to the mapped IPv4 address and mapped UDP port of the
The Teredo client, when it receives the prefix, would notice that
this prefix is a global IPv6 prefix, not in the form of a Teredo
prefix. The client would at that point recognize that it should
operate in tunnel mode. A client that operates in tunnel mode would
execute a much simpler transmission procedure: it would forward any
packet sent to the Teredo interface to the IPv4 address and Teredo
UDP port of the server.
The Teredo client would have to perform the maintenance procedure
described in Section 5.2.5. The server would receive the router
solicitation, and could notice a possible change of mapped IPv4
address and mapped UDP port that could result from the
reconfiguration of the mappings inside the NAT. The server should
continue advertising the same IPv6 prefix to the client, and should
update the mapped IPv4 address and mapped UDP port associated to this
prefix, if necessary.
There is as yet no consensus that a tunnel-mode extension to Teredo
should be developed. This section is only intended to provide
suggestions to the future developers of such services. Many details
would probably have to be worked out before a tunnel-mode extension
would be agreed upon.
7. Security Considerations
The main objective of Teredo is to provide nodes located behind a NAT
with a globally routable IPv6 address. The Teredo nodes can use IP
security (IPsec) services such as Internet Key Exchange (IKE),
Authentication Header (AH), or Encapsulation Security Payload (ESP)
[RFC4306, RFC4302, RFC4303], without the configuration restrictions
still present in "Negotiation of NAT-Traversal in the IKE" [RFC3947].
As such, we can argue that the service has a positive effect on
network security. However, the security analysis must also envisage
the negative effects of the Teredo services, which we can group in
four categories: security risks of directly connecting a node to the
IPv6 Internet, spoofing of Teredo servers to enable a man-in-the-
middle attack, potential attacks aimed at denying the Teredo service
to a Teredo client, and denial of service attacks against non-Teredo
participating nodes that would be enabled by the Teredo service.
In the following, we review in detail these four types of issues, and
we present mitigating strategies for each of them.
7.1. Opening a Hole in the NAT
The very purpose of the Teredo service is to make a machine reachable
through IPv6. By definition, the machine using the service will give
up whatever firewall service was available in the NAT box, however
limited this service may be [RFC2993]. The services that listen to
the Teredo IPv6 address will become the potential target of attacks
from the entire IPv6 Internet. This may sound scary, but there are
three mitigating factors.
The first mitigating factor is the possibility to restrict some
services to only accept traffic from local neighbors, e.g., using
link-local addresses. Teredo does not support communication using
link-local addresses. This implies that link-local services will not
be accessed through Teredo, and will be restricted to whatever other
IPv6 connectivity may be available, e.g., direct traffic with
neighbors on the local link, behind the NAT.
The second mitigating factor is the possible use of a "local
firewall" solution, i.e., a piece of software that performs locally
the kind of inspection and filtering that is otherwise performed in a
perimeter firewall. Using such software is recommended.
The third mitigating factor is the availability of IP security
(IPsec) services such as IKE, AH, or ESP [RFC4306, RFC4302, RFC4303].
Using these services in conjunction with Teredo is a good policy, as
it will protect the client from possible attacks in intermediate
servers such as the NAT, the Teredo server, or the Teredo relay.
(However, these services can be used only if the parties in the
communication can negotiate a key, which requires agreeing on some
credentials; this is known to be a hard problem.)
7.2. Using the Teredo Service for a Man-in-the-Middle Attack
The goal of the Teredo service is to provide hosts located behind a
NAT with a globally reachable IPv6 address. There is a possible
class of attacks against this service in which an attacker somehow
intercepts the router solicitation, responds with a spoofed router
advertisement, and provides a Teredo client with an incorrect
address. The attacker may have one of two objectives: it may try to
deny service to the Teredo client by providing it with an address
that is in fact unreachable, or it may try to insert itself as a
relay for all client communications, effectively enabling a variety
of "man-in-the-middle" attack.
7.2.1. Attacker Spoofing the Teredo Server
The simple nonce verification procedure described in Section 5.2.2
provides a first level of protection against attacks in which a third
party tries to spoof the server. In practice, the nonce procedure
can be defeated only if the attacker is "on path".
If client and server share a secret and agree on an authentication
algorithm, the secure qualification procedure described in Section
5.2.2 provides further protection. To defeat this protection, the
attacker could try to obtain a copy of the secret shared between
client and server. The most likely way to obtain the shared secret
is to listen to the traffic and mount an offline dictionary attack;
to protect against this attack, the secret shared between client and
server should contain sufficient entropy. (This probably requires
some automated procedure for provisioning the shared secret and the
If the shared secret contains sufficient entropy, the attacker would
have to defeat the one-way function used to compute the
authentication value. This specification suggests a default
algorithm combining HMAC and MD5. If the protection afforded by MD5
was not deemed sufficient, clients and servers can agree to use a
different algorithm, e.g., SHA1.
Another way to defeat the protection afforded by the authentication
procedure is to mount a complex attack, as follows:
1) Client prepares router solicitation, including authentication
2) Attacker intercepts the solicitation, and somehow manages to
prevent it from reaching the server, for example, by mounting a
short-duration DoS attack against the server.
3) Attacker replaces the source IPv4 address and source UDP port of
the request by one of its own addresses and port, and forwards the
modified request to the server.
4) Server dutifully notes the IPv4 address from which the packet is
received, verifies that the Authentication encapsulation is correct,
prepares a router advertisement, signs it, and sends it back to the
incoming address, i.e., the attacker.
5) Attacker receives the advertisement, takes note of the mapping,
replaces the IPv4 address and UDP port by the original values in the
intercepted message, and sends the response to the client.
6) Client receives the advertisement, notes that the authentication
header is present and is correct, and uses the proposed prefix and
the mapped addresses in the origin indication encapsulation.
The root cause of the problem is that the NAT is, in itself, a man-
in-the-middle attack. The Authentication encapsulation covers the
encapsulated IPv6 packet, but does not cover the encapsulating IPv4
header and UDP header. It is very hard to devise an effective
authentication scheme, since the attacker does not do anything else
than what the NAT legally does!
However, there are several mitigating factors that lead us to avoid
worrying too much about this attack. In practice, the gain from the
attack is either to deny service to the client or to obtain a "man-
in-the-middle" position. However, in order to mount the attack, the
attacker must be able to suppress traffic originating from the
client, i.e., have denial of service capability; the attacker must
also be able to observe the traffic exchanged between client and
inject its own traffic in the mix, i.e., have man-in-the-middle
capacity. In summary, the attack is very hard to mount, and the gain
for the attacker in terms of "elevation of privilege" is minimal.
A similar attack is described in detail in the security section of
7.2.2. Attacker Spoofing a Teredo Relay
An attacker may try to use Teredo either to pass itself for another
IPv6 host or to place itself as a man-in-the-middle between a Teredo
host and a native IPv6 host. The attacker will mount such attacks by
spoofing a Teredo relay, i.e., by convincing the Teredo host that
packets bound to the native IPv6 host should be relayed to the IPv4
address of the attacker.
The possibility of the attack derives from the lack of any
algorithmic relation between the IPv4 address of a relay and the
native IPv6 addresses served by these relay. A Teredo host cannot
decide just by looking at the encapsulating IPv4 and UDP header
whether or not a relay is legitimate. If a Teredo host decided to
simply trust the incoming traffic, it would easily fall prey to a
The attack is mitigated by the "direct IPv6 connectivity test"
specified in Section 5.2.9. The test specifies a relay discovery
procedure secured by a nonce. The nonce is transmitted from the
Teredo host to the destination through Teredo server, which the
client normally trusts. The response arrives through the "natural"
relay, i.e., the relay closest to the IPv6 destination. Sending
traffic to this relay will place it out of reach of attackers that
are not on the direct path between the Teredo host and its IPv6 peer.
End-to-end security protections are required to defend against
spoofing attacks if the attacker is on the direct path between the
Teredo host and its peer.
7.2.3. End-to-End Security
The most effective line of defense of a Teredo client is probably not
to try to secure the Teredo service itself: even if the mapping can
be securely obtained, the attacker would still be able to listen to
the traffic and send spoofed packets. Rather, the Teredo client
should realize that, because it is located behind a NAT, it is in a
situation of vulnerability; it should systematically try to encrypt
its IPv6 traffic, using IPsec. Even if the IPv4 and UDP headers are
vulnerable, the use of IPsec will effectively prevent spoofing and
listening of the IPv6 packets by third parties. By providing each
client with a global IPv6 address, Teredo enables the use of IPsec
without the configuration restrictions still present in "Negotiation
of NAT-Traversal in the IKE" [RFC3947] and ultimately enhances the
security of these clients.
7.3. Denial of the Teredo service
Our analysis outlines five ways to attack the Teredo service. There
are countermeasures for each of these attacks.
7.3.1. Denial of Service by a Rogue Relay
An attack can be mounted on the IPv6 side of the service by setting
up a rogue relay and letting that relay advertise a route to the
Teredo IPv6 prefix. This is an attack against IPv6 routing, which
can also be mitigated by the same kind of procedures used to
eliminate spurious route advertisements. Dual-stack nodes that
implement "host local" Teredo relays are impervious to this attack.
7.3.2. Denial of Service by Server Spoofing
In Section 7.2, we discussed the use of spoofed router advertisements
to insert an attacker in the middle of a Teredo conversation. The
spoofed router advertisements can also be used to provision a client
with an incorrect address, pointing to either a non-existing IPv4
address or the IPv4 address of a third party.
The Teredo client will detect the attack when it fails to receive
traffic through the newly acquired IPv6 address. The attack can be
mitigated by using the authentication encapsulation.
7.3.3. Denial of Service by Exceeding the Number of Peers
A Teredo client manages a cache of recently used peers, which makes
it stateful. It is possible to mount an attack against the client by
provoking it to respond to packets that appear to come from a large
number of Teredo peers, thus trashing the cache and effectively
denying the use of direct communication between peers. The effect
will last only as long as the attack is sustained.
7.3.4. Attacks against the Local Discovery Procedure
There is a possible denial of service attack against the local peer
discovery procedure, if attackers can manage to send spoofed local
discovery bubbles to a Teredo client. The checks described in
Section 5.2.8 mitigate this attack. Clients who are more interested
in security than in performance could decide to disable the local
discovery procedure; however, if local discovery is disabled, traffic
between local nodes will end up being relayed through a server
external to the local network, which has questionable security
7.3.5. Attacking the Teredo Servers and Relays
It is possible to mount a brute force denial of service attack
against the Teredo servers by sending them a very large number of
packets. This attack will have to be brute force, since the servers
are stateless, and can be designed to process all the packets that
are sent on their access line.
The brute force attack against the Teredo servers is mitigated if
clients are ready to "failover" to another server. Bringing down the
servers will, however, force the clients that change servers to
renumber their Teredo address.
It is also possible to mount a brute force attack against a Teredo
relay. This attack is mitigated if the relay under attack stops
announcing the reachability of the Teredo service prefix to the IPv6
network: the traffic will be picked up by the next relay.
An attack similar to that described in Section 7.3.2 can be mounted
against a relay. An IPv6 host can send IPv6 packets to a large
number of Teredo destinations, forcing the relay to establish state
for each of these destinations. Teredo relays can obtain some
protection by limiting the range of IPv6 clients that they serve, and
by limiting the amount of state used for "new" peers.
7.4. Denial of Service against Non-Teredo Nodes
There is a widely expressed concern that transition mechanisms such
as Teredo can be used to mount denial of service attacks, by
injecting traffic at locations where it is not expected. These
attacks fall in three categories: using the Teredo servers as a
reflector in a denial of service attack, using the Teredo server to
carry a denial of service attack against IPv6 nodes, and using the
Teredo relays to carry a denial of service attack against IPv4 nodes.
The analysis of these attacks follows. A common mitigating factor in
all cases is the "regularity" of the Teredo traffic, which contains
highly specific patterns such as the Teredo UDP port, or the Teredo
IPv6 prefix. In case of attacks, these patterns can be used to
quickly install filters and remove the offending traffic.
We should also note that none of the listed possibilities offer any
7.4.1. Laundering DoS attacks from IPv4 to IPv4
An attacker can use the Teredo servers as reflectors in a denial of
service attack aimed at an IPv4 target. The attacker can do this in
one of two ways. The first way is to construct a Router Solicitation
message and post it to a Teredo server, using as IPv4 source address
the spoofed address of the target; the Teredo server will then send a
Router advertisement message to the target. The second way is to
construct a Teredo IPv6 address using the Teredo prefix, the address
of a selected server, the IPv4 of the target, and an arbitrary UDP
port, and to then send packets bound to that address to the selected
Reflector attacks are discussed in [REFLECT], which outlines various
mitigating techniques against such attacks. One of these mitigations
is to observe that "the traffic generated by the reflectors [has]
sufficient regularity and semantics that it can be filtered out near
the victim without the filtering itself constituting a denial-of-
service to the victim ('collateral damage')". The traffic reflected
by the Teredo servers meets this condition: it is clearly
recognizable, since it originates from the Teredo UDP port; it can be
filtered out safely if the target itself is not a Teredo user. In
addition, the packets relayed by servers will carry an Origin
indication encapsulation, which will help determine the source of the
7.4.2. DoS Attacks from IPv4 to IPv6
An attacker may use the Teredo servers to launch a denial of service
attack against an arbitrary IPv6 destination. The attacker will
build an IPv6 packet bound for the target and will send that packet
to the IPv4 address and UDP port of a Teredo server, to be relayed
from there to the target over IPv6.
The address checks specified in Section 5.3.1 provide some protection
against this attack, as they ensure that the IPv6 source address will
be consistent with the IPv4 source address and UDP source port used
by the attacker: if the attacker cannot spoof the IPv4 source
address, the target will be able to determine the origin of the
The address checks ensure that the IPv6 source address of packets
forwarded by servers will start with the IPv6 Teredo prefix. This is
a mitigating factor, as sites under attack could use this to filter
out all packets sourced from that prefix during an attack. This will
result in a partial loss of service, as the target will not be able
to communicate with legitimate Teredo hosts that use the same prefix.
However, the communication with other IPv6 hosts will remain
unaffected, and the communication with Teredo hosts will be able to
resume when the attack has ceased.
7.4.3. DoS Attacks from IPv6 to IPv4
An attacker with IPv6 connectivity may use the Teredo relays to
launch a denial of service attack against an arbitrary IPv4
destination. The attacker will compose a Teredo IPv6 address using
the Teredo prefix, a "cone" flag set to 1, the IPv4 address of the
target, and an arbitrary UDP port.
In the simplest variation of this attack, the attacker sends IPv6
packets to the Teredo destination using regular IPv6 routing. The
packets are picked by the nearest relay, which will forward them to
the IPv4 address of the target. In a more elaborate variant, the
attacker tricks a Teredo into sending packets to the target, either
by sending a first packet with a spoofed IPv6 address and letting the
Teredo host reply or by publishing a spoofed IPv6 address in a name
There are three types of IPv4 addresses that an attacker may embed in
the spoofed Teredo address. It may embed a multicast or broadcast
address, an local unicast address, or a global unicast address.
With multicast or broadcast addresses, the attacker can use the
multiplying effect of multicast routing. By sending a single packet,
it can affect a large number of hosts, in a way reminiscent of the
By using local addresses, the attacker can reach hosts that are not
normally reachable from the Internet, for example, hosts connected to
the a Teredo relay by a private subnet. This creates an exposure
for, at a minimum, a denial of service attack against these otherwise
protected hosts. This is similar to attack variants using source
routing to breach a perimeter.
The address checks specified in Section 5.2.4, 5.3.1, and 5.4.1
verify that packets are relayed only to a global IPv4 address. They
are designed to eliminate the possibility of using broadcast,
multicast or local addresses in denial of service or other attacks.
In what follows, we will only consider attacks targeting globally
reachable unicast addresses.
The attacks can be targeted at arbitrary UDP ports, such as, for
example, the DNS port of a server. The UDP payload must be a well-
formed IPv6 packet, and is thus unlikely to be accepted by any well-
written UDP service; in most case, the only effect of the attack will
be to overload the target with random traffic.
A special case occurs if the attack is directed to an echo service.
The service will echo the packets. Since the echo service sees the
request coming from the IPv4 address of the relay, the echo replies
will be sent back to the same relay. According to the rules
specified in Section 5.4, these packets will be discarded by the
Teredo relay. This is not a very efficient attack against the Teredo
relays -- establishing a legitimate session with an actual Teredo
host would create more traffic.
The IPv6 packets sent to the target contain the IPv6 address used by
the attacker. If ingress filtering is used in the IPv6 network, this
address will be hard to spoof. If ingress filtering is not used, the
attacker can be traced if the IPv6 routers use a mechanism similar to
ICMP Traceback. The ICMP messages will normally be collected by the
same relays that forward the traffic from the attacker; the relays
can use these messages to identify the source of an ongoing attack.
The details of this solution will have to be developed in further
8. IAB Considerations
The IAB has studied the problem of "Unilateral Self Address Fixing"
(UNSAF), which is the general process by which a client attempts to
determine its address in another realm on the other side of a NAT
through a collaborative protocol reflection mechanism [RFC3424].
Teredo is an example of a protocol that performs this type of
function. The IAB has mandated that any protocols developed for this
purpose document a specific set of considerations. This section
meets those requirements.
8.1. Problem Definition
From [RFC3424], any UNSAF proposal must provide a precise definition
of a specific, limited-scope problem that is to be solved with the
UNSAF proposal. A short-term fix should not be generalized to solve
other problems; this is why "short term fixes usually aren't".
The specific problem being solved by Teredo is the provision of IPv6
connectivity for hosts that cannot obtain IPv6 connectivity natively
and cannot make use of 6to4 because of the presence of a NAT between
them and the 6to4 relays.
8.2. Exit Strategy
From [RFC3424], any UNSAF proposal must provide the description of an
exit strategy/transition plan. The better short term fixes are the
ones that will naturally see less and less use as the appropriate
technology is deployed.
Teredo comes with its own built-in exit strategy: as soon as a client
obtains IPv6 connectivity by other means, either 6to4 or native IPv6,
it can cease using the Teredo service. In particular, we expect that
the next generation of home routers will provide an IPv6 service in
complement to the current IPv4 NAT service, e.g., by relaying
connectivity obtained from the ISP, or by using a configured or
automatic tunnel service.
As long as Teredo is used, there will be a need to support Teredo
relays so that the remaining Teredo hosts can communicate with native
IPv6 hosts. As Teredo usage declines, the traffic load on the relays
will decline. Over time, managers will observe a reduced traffic
load on their relays and will turn them off, effectively increasing
the pressure on the remaining Teredo hosts to upgrade to another form
The exit strategy is facilitated by the nature of Teredo, which
provides an IP-level solution. IPv6-aware applications do not have
to be updated to use or not use Teredo. The absence of impact on the
applications makes it easier to migrate out of Teredo: network
There would appear to be reasons why a Teredo implementation might
decide to continue usage of the Teredo service even if it already has
obtained connectivity by some other means, for example:
1. When a client is dual homed, and it wishes to improve the service
when communicating with other Teredo hosts that are "nearby" on the
IPv4 network. If the client only used its native IPv6 service, the
Teredo hosts would be reached only through the relay. By maintaining
Teredo, the Teredo hosts can be reached by direct transmission over
2. If, for some reason, the Teredo link is providing the client with
better service than the native IPv6 link, in terms of bandwidth,
packet loss, etc.
The design of Teredo mitigates the dual-homing reason. A host that
wishes to communicate with Teredo peers can implement a "host-based
relay", which is effectively an unnumbered Teredo interface. As
such, the dual-homed host will obtain Teredo connectivity with those
hosts that must use Teredo, but will not inadvertently encourage
other dual-homed hosts to keep using the Teredo service.
The bubbles and the UDP encapsulation used by Teredo introduce a
significant overhead. It would take exceptional circumstances for
native technologies to provide a lesser service than Teredo. These
exceptional circumstances, or other unforeseen reasons, may induce
hosts to keep using the Teredo service despite the availability of
native IPv6 connectivity. However, these circumstances are likely to
be rare and transient. Moreover, if the primary reason to use Teredo
fades away, one can expect that Teredo relays will be progressively
turned off and that the quality of the Teredo service will
progressively degrade, reducing the motivation to use the Teredo
8.3. Brittleness Introduced by Teredo
From [RFC3424], any UNSAF proposal must provide a discussion of
specific issues that may render systems more "brittle". For example,
approaches that involve using data at multiple network layers create
more dependencies, increase debugging challenges, and make it harder
Teredo introduces brittleness into the system in several ways: the
discovery process assumes a certain classification of devices based
on their treatment of UDP; the mappings need to be continuously
refreshed; and addressing structure may cause some hosts located
behind a common NAT to be unreachable from each other.
There are many similarities between these points and those introduced
by Simple Traversal of the UDP Protocol through NAT (STUN) [RFC3489];
however, Teredo is probably somewhat less brittle than STUN. The
reason is that all Teredo packets are sent from the local IPv4 Teredo
service port, including discovery, bubbles, and actual encapsulated
packets. This is different from STUN, where NAT type detection and
binding allocation use different local ports (ephemeral, in both
Teredo assumes a certain classification of devices based on their
treatment of UDP (e.g., cone, protected cone and symmetric). There
could be devices that would not fit into one of these molds, and
hence would be improperly classified by Teredo.
The bindings allocated from the NAT need to be continuously
refreshed. Since the timeouts for these bindings are very
implementation specific, the refresh interval cannot easily be
determined. When the binding is not being actively used to receive
traffic, but to wait for an incoming message, the binding refresh
will needlessly consume network bandwidth.
The use of the Teredo server as an additional network element
introduces another point of potential security attack. These attacks
are largely prevented by the security measures provided by Teredo,
but not entirely.
The use of the Teredo server as an additional network element
introduces another point of failure. If the client cannot locate a
Teredo server, or if the server should be unavailable due to failure,
the Teredo client will not be able to obtain IPv6 connectivity.
The communication with non-Teredo hosts relies on the availability of
Teredo relays. The Teredo design assumes that there are multiple
Teredo relays; the Teredo service will discover the relay closest to
the non-Teredo peer. If that relay becomes unavailable, or is
misbehaving, communication between the Teredo hosts and the peers
close to that relay will fail. This reliability issue is somewhat
mitigated by the possibility to deploy many relays, arbitrarily close
from the native IPv6 hosts that require connectivity with Teredo
Teredo imposes some restrictions on the network topologies for proper
operation. In particular, if the same NAT is on the path between two
clients and the Teredo server, these clients will only be able to
interoperate if they are connected to the same link, or if the common
NAT is capable of "hairpinning", i.e., "looping" packets sent by one
client to another.
There are also additional points of brittleness that are worth
- Teredo service will not work through NATs of the symmetric variety.
- Teredo service depends on the Teredo server running on a network
that is a common ancestor to all Teredo clients; typically, this is
the public Internet. If the Teredo server is itself behind a NAT,
Teredo service will not work to certain peers.
- Teredo introduces jitter into the IPv6 service it provides, due to
the queuing of packets while bubble exchanges take place. This
jitter can negatively impact applications, particularly latency
sensitive ones, such as Voice over IP (VoIP).
8.4. Requirements for a Long-Term Solution
From [RFC3424], any UNSAF proposal must identify requirements for
longer-term, sound technical solutions -- contribute to the process
of finding the right longer-term solution.
Our experience with Teredo has led to the following requirements for
a long-term solution to the NAT problem: the devices that implement
the IPv4 NAT services should in the future also become IPv6 routers.
9. IANA Considerations
This memo documents a request to IANA to allocate a 32-bit Teredo
IPv6 service prefix, as specified in Section 2.6, and a Teredo IPv4
multicast address, as specified in Section 2.17.
Many of the ideas in this memo are the result of discussions between
the author and Microsoft colleagues, notably Brian Zill, John Miller,
Mohit Talwar, Joseph Davies, and Rick Rashid. Several encapsulation
details are inspired from earlier work by Keith Moore. The example
in Section 5.1 and a number of security precautions were suggested by
Pekka Savola. The local discovery procedure was suggested by Richard
Draves and Dave Thaler. The document was reviewed by members of the
NGTRANS and V6OPS working groups, including Brian Carpenter, Cyndi
Jung, Keith Moore, Thomas Narten, Anssi Porttikivi, Pekka Savola, Eng
Soo Guan, and Eiffel Wu. Eric Klein, Karen Nielsen, Francis Dupont,
Markku Ala-Vannesluoma, Henrik Levkowetz, and Jonathan Rosenberg
provided detailed reviews during the IETF last call.
11.1. Normative References
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
[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.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002.
[RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm
and Its Use With IPsec", RFC 3566, September 2003.
[FIPS-180] "Secure Hash Standard", Computer Systems Laboratory,
National Institute of Standards and Technology, U.S.
Department Of Commerce, May 1993.
11.2. Informative References
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy.
"STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489,
[RFC3904] Huitema, C., Austein, R., Satapati, S., and R. van der
Pol, "Evaluation of IPv6 Transition Mechanisms for
Unmanaged Networks", RFC 3904, September 2004.
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
"Negotiation of NAT-Traversal in the IKE", RFC 3947,
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005.
[REFLECT] V. Paxson, "An analysis of using reflectors for
distributed denial of service attacks", Computer
Communication Review, ACM SIGCOMM, Volume 31, Number 3,
July 2001, pp 38-47.
One Microsoft Way
Redmond, WA 98052-6399
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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 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.
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
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
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).