draft-ietf-v6ops-tunnel-loops-01.txt   draft-ietf-v6ops-tunnel-loops-02.txt 
Network Working Group G. Nakibly Network Working Group G. Nakibly
Internet-Draft National EW Research & Internet-Draft National EW Research &
Intended status: Informational Simulation Center Intended status: Informational Simulation Center
Expires: May 13, 2011 F. Templin Expires: July 28, 2011 F. Templin
Boeing Research & Technology Boeing Research & Technology
November 9, 2010 January 24, 2011
Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and
Proposed Mitigations Proposed Mitigations
draft-ietf-v6ops-tunnel-loops-01.txt draft-ietf-v6ops-tunnel-loops-02.txt
Abstract Abstract
This document is concerned with security vulnerabilities in IPv6-in- This document is concerned with security vulnerabilities in IPv6-in-
IPv4 automatic tunnels. These vulnerabilities allow an attacker to IPv4 automatic tunnels. These vulnerabilities allow an attacker to
take advantage of inconsistencies between the IPv4 routing state and take advantage of inconsistencies between the IPv4 routing state and
the IPv6 routing state. The attack forms a routing loop which can be the IPv6 routing state. The attack forms a routing loop which can be
abused as a vehicle for traffic amplification to facilitate DoS abused as a vehicle for traffic amplification to facilitate DoS
attacks. The first aim of this document is to inform on this attack attacks. The first aim of this document is to inform on this attack
and its root causes. The second aim is to present some possible and its root causes. The second aim is to present some possible
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 13, 2011. This Internet-Draft will expire on July 28, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. A Detailed Description of the Attack . . . . . . . . . . . . . 3 2. A Detailed Description of the Attack . . . . . . . . . . . . . 4
3. Proposed Mitigation Measures . . . . . . . . . . . . . . . . . 6 3. Proposed Mitigation Measures . . . . . . . . . . . . . . . . . 6
3.1. Destination and Source Address Checks . . . . . . . . . . 6 3.1. Destination and Source Address Checks . . . . . . . . . . 6
3.1.1. Known IPv6 Prefix Check . . . . . . . . . . . . . . . 7 3.1.1. Known IPv6 Prefix Check . . . . . . . . . . . . . . . 8
3.2. Verification of end point existence . . . . . . . . . . . 8 3.2. Verification of end point existence . . . . . . . . . . . 8
3.2.1. Neighbor Cache Check . . . . . . . . . . . . . . . . . 8 3.2.1. Neighbor Cache Check . . . . . . . . . . . . . . . . . 8
3.2.2. Known IPv4 Address Check . . . . . . . . . . . . . . . 9 3.2.2. Known IPv4 Address Check . . . . . . . . . . . . . . . 9
3.2.3. Neighbor Reachability Check . . . . . . . . . . . . . 9 3.3. Operational Measures . . . . . . . . . . . . . . . . . . . 9
3.3. Operational Measures . . . . . . . . . . . . . . . . . . . 10
3.3.1. Avoiding a Shared IPv4 Link . . . . . . . . . . . . . 10 3.3.1. Avoiding a Shared IPv4 Link . . . . . . . . . . . . . 10
3.3.2. A Single Border Router . . . . . . . . . . . . . . . . 10 3.3.2. A Single Border Router . . . . . . . . . . . . . . . . 10
4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 11 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
IPv6-in-IPv4 tunnels are an essential part of many migration plans IPv6-in-IPv4 tunnels are an essential part of many migration plans
for IPv6. They allow two IPv6 nodes to communicate over an IPv4-only for IPv6. They allow two IPv6 nodes to communicate over an IPv4-only
skipping to change at page 3, line 31 skipping to change at page 3, line 31
service risk as inconsistency between the IPv4 routing state and the service risk as inconsistency between the IPv4 routing state and the
IPv6 routing state allows a routing loop to be formed. IPv6 routing state allows a routing loop to be formed.
An attacker can exploit this vulnerability by crafting a packet which An attacker can exploit this vulnerability by crafting a packet which
is routed over a tunnel to a node that is not participating in that is routed over a tunnel to a node that is not participating in that
tunnel. This node may forward the packet out of the tunnel to the tunnel. This node may forward the packet out of the tunnel to the
native IPv6 network. There the packet is routed back to the ingress native IPv6 network. There the packet is routed back to the ingress
point that forwards it back into the tunnel. Consequently, the point that forwards it back into the tunnel. Consequently, the
packet loops in and out of the tunnel. The loop terminates only when packet loops in and out of the tunnel. The loop terminates only when
the Hop Limit field in the IPv6 header of the packet is decremented the Hop Limit field in the IPv6 header of the packet is decremented
to zero. to zero. This vulnerability can be abused as a vehicle for traffic
amplification to facilitate DoS attacks [RFC4732].
Without compensating security measures in place, all IPv6 automatic Without compensating security measures in place, all IPv6 automatic
tunnels that are based on protocol-41 encapsulation are vulnerable to tunnels that are based on protocol-41 encapsulation [RFC4213] are
such an attack including ISATAP [RFC5214], 6to4 [RFC3056] and 6rd vulnerable to such an attack including ISATAP [RFC5214], 6to4
[RFC5569]. [RFC3056] and 6rd [RFC5569]. It should be noted that this document
does not consider non-protocol-41 encapsulation attacks. In
particular, we do not address the Teredo [RFC4380] attacks described
in [USENIX09]. These attacks are considered in
[I-D.gont-6man-teredo-loops].
The aim of this document is to shed light on the routing loop attack The aim of this document is to shed light on the routing loop attack
and describe possible mitigation measures that should be considered and describe possible mitigation measures that should be considered
by operators of current IPv6 automatic tunnels and by designers of by operators of current IPv6 automatic tunnels and by designers of
future ones. We note that tunnels may be deployed in various future ones. We note that tunnels may be deployed in various
operational environments, e.g. service provider network, enterprise operational environments, e.g. service provider network, enterprise
network, etc. Specific issues related to the attack which are network, etc. Specific issues related to the attack which are
derived from the operational environment are not considered in this derived from the operational environment are not considered in this
document. document.
skipping to change at page 6, line 21 skipping to change at page 6, line 26
ISATAP router (R1) and 6to4 relay (R2), then the destination and ISATAP router (R1) and 6to4 relay (R2), then the destination and
source addresses of the attack packet would be 2002:IP1:* and Prf1:: source addresses of the attack packet would be 2002:IP1:* and Prf1::
0200:5EFE:IP2, respectively. 0200:5EFE:IP2, respectively.
3. Proposed Mitigation Measures 3. Proposed Mitigation Measures
This section presents some possible mitigation measures for the This section presents some possible mitigation measures for the
attack described above. For each measure we shall discuss its attack described above. For each measure we shall discuss its
advantages and disadvantages. advantages and disadvantages.
The proposed measures fall under the following two categories: The proposed measures fall under the following three categories:
o Destination and source addresses checks o Destination and source addresses checks
o Verification of end point existence o Verification of end point existence
o Operational measures o Operational measures
3.1. Destination and Source Address Checks 3.1. Destination and Source Address Checks
Tunnel routers can use a source address check mitigation when they Tunnel routers can use a source address check mitigation when they
skipping to change at page 7, line 20 skipping to change at page 7, line 23
prefix but embeds one of the router's configured IPv4 addresses. prefix but embeds one of the router's configured IPv4 addresses.
o When the router receives an IPv6 packet on a tunnel interface, it o When the router receives an IPv6 packet on a tunnel interface, it
discards the packet if the IPv6 destination address has an off- discards the packet if the IPv6 destination address has an off-
link prefix but embeds one of the router's configured IPv4 link prefix but embeds one of the router's configured IPv4
addresses. addresses.
This approach has the advantage that that no ancillary state is This approach has the advantage that that no ancillary state is
required, since checking is through static lookup in the lists of required, since checking is through static lookup in the lists of
IPv4 and IPv6 addresses belonging to the router. However, this IPv4 and IPv6 addresses belonging to the router. However, this
approach has some inherit limitations: approach has some inherent limitations
o The checks incur an overhead which is proportional to the number o The checks incur an overhead which is proportional to the number
of IPv4 addresses assigned to the router. If a router is assigned of IPv4 addresses assigned to the router. If a router is assigned
many addresses, the additional processing overhead for each packet many addresses, the additional processing overhead for each packet
may be considerable. may be considerable. Note that an unmitigated attack packet would
be repetitively processed by the router until the Hop Limit
expires, which may require as many as 255 iterations. Hence, an
unmitigated attack will consume far more aggregate processing
overhead than per-packet address checks even if the router assigns
a large number of addresses.
o The checks should be performed for the IPv6 address formats of o The checks should be performed for the IPv6 address formats of
every existing automatic IPv6 tunnel protocol (which uses every existing automatic IPv6 tunnel protocol (which uses
protocol-41 encapsulation). Hence, the checks must be updated as protocol-41 encapsulation). Hence, the checks must be updated as
new protocols are defined. new protocols are defined.
o Before the checks can be performed the format of the address must o Before the checks can be performed the format of the address must
be recognized. There is no guarantee that this can be generally be recognized. There is no guarantee that this can be generally
done. For example, one can not determine if an IPv6 address is a done. For example, one can not determine if an IPv6 address is a
6rd one, hence a configuration is needed at the router. 6rd one, hence the router would need to be configured with a list
of all applicable 6rd prefixes (which may be prohibitively large)
in order to unambiguously apply the checks.
o The checks cannot be performed if the embedded IPv4 address is a o The checks cannot be performed if the embedded IPv4 address is a
private one [RFC1918] since it is ambiguous in scope. Namely, the private one [RFC1918] since it is ambiguous in scope. Namely, the
private address may be legitimately allocated to another node in private address may be legitimately allocated to another node in
another routing region. another routing region.
The last limitation may be relieved if the router has some The last limitation may be relieved if the router has some
information that allows it to unambiguously determine the scope of information that allows it to unambiguously determine the scope of
the address. The check in the following subsection is one example the address. The check in the following subsection is one example
for this. for this.
skipping to change at page 8, line 38 skipping to change at page 8, line 50
The routing loop attack relies on the fact that a router does not The routing loop attack relies on the fact that a router does not
know whether there is an end point that can reached via its tunnel know whether there is an end point that can reached via its tunnel
that has the source or destination address of the packet. This that has the source or destination address of the packet. This
category includes mitigation measures which aim to verify that there category includes mitigation measures which aim to verify that there
is a node which participate in the tunnel and its address corresponds is a node which participate in the tunnel and its address corresponds
to the packet's destination or source addresses, as appropriate. to the packet's destination or source addresses, as appropriate.
3.2.1. Neighbor Cache Check 3.2.1. Neighbor Cache Check
One way to verify that an end point exists in a tunnel is by checking One way that the router can verify that an end host exists and can be
whether a valid entry exists for it in the Neighbor Cache of the reached via the tunnel is by checking whether a valid entry exists
corresponding tunnel interface. A valid entry may exist in the for it in the neighbor cache of the corresponding tunnel interface.
Neighbor Cache for legitimate end hosts if they generate traffic
towards the router upon startup. For example, an initial RS/RA
exchange to facilitate Stateless Address Auto configuration (as in
the ISATAP case). This allows the router to keep valid Neighbor
Cache entry for each legitimate end host in the tunnel.
By keeping track of the legitimate hosts in the tunnel via the
Neighbor Cache, a router can perform the following simple checks:
o When the router forwards a packet into the tunnel with an IPv6
destination address that matches an on-link prefix and that embeds
the IPv4 address IP1, it discards the packet if there is no
corresponding neighbor cache entry.
o When the router receives a packet on the tunnel's interface with The neighbor cache entry can be populated through, e.g., an initial
an IPv6 source address that matches an on-link prefix and that reachability check, receipt of neighbor discovery messages,
embeds the IPv4 address IP2, it discards the packet if there is no administrative configuration, etc.
corresponding neighbor cache entry.
This approach is easy to implement, and naturally leverages the fact When the router has a packet to send to a potential tunnel host for
that an end host must successively send RSs in order to refresh which there is no neighbor cache entry, it can perform an initial
configuration information as on-link prefix information. However, reachability check on the packet's destination address, e.g., as
this requires the router to retain entries for a duration that is at specified in the second paragraph of Section 8.4 of [RFC5214]. (The
least as long as the router's advertised prefix lifetimes. This may router can similarly perform a "reverse reachability" check on the
require an implementation to adjust its garbage-collection interval packet's source address when it receives a packet from a potential
for stale neighbor cache entries. tunnel host for which there is no neighbor cache entry.) This
reachability check parallels the address resolution specifications in
Section 7.2 of [RFC4861], i.e., the router maintains a small queue of
packets waiting for reachability confirmation to complete. If
confirmation succeeds, the router discovers that a legitimate tunnel
host responds to the address. Otherwise, the router discards
subseqent packets and returns ICMP destination unreachable
indications as specified in Section 7.2.2 of [RFC4861].
Finally, this approach assumes that the neighbor cache will remain Note that this approach assumes that the neighbor cache will remain
coherent and not subject to malicious attack, which must be confirmed coherent and not subject to malicious attack, which must be confirmed
based on specific deployment scenarios. One possible way for an based on specific deployment scenarios. One possible way for an
attacker to subvert the neighbor cache is to send false RS messages attacker to subvert the neighbor cache is to send false neighbor
with a spoofed source address. discovery messages with a spoofed source address.
3.2.2. Known IPv4 Address Check 3.2.2. Known IPv4 Address Check
Another approach that enables a router to verify that an end host Another approach that enables a router to verify that an end host
exists and can be reached via the tunnel is simply by pre-configuring exists and can be reached via the tunnel is simply by pre-configuring
the router with the set of IPv4 addresses that are authorized to use the router with the set of IPv4 addresses that are authorized to use
the tunnel. Upon this configuration the router can perform the the tunnel. Upon this configuration the router can perform the
following simple checks: following simple checks:
o When the router forwards an IPv6 packet into the tunnel interface o When the router forwards an IPv6 packet into the tunnel interface
with a destination address that matches an on-link prefix and that with a destination address that matches an on-link prefix and that
embeds the IPv4 address IP1, it discards the packet if IP1 does embeds the IPv4 address IP1, it discards the packet if IP1 does
not belong to the configured list of IPv4 addresses. not belong to the configured list of IPv4 addresses.
o When the router receives an IPv6 packet on the tunnel's interface o When the router receives an IPv6 packet on the tunnel's interface
with a source address that matches a on-link prefix and that with a source address that matches a on-link prefix and that
embeds the IPv4 address IP2, it discards the packet if IP2 does embeds the IPv4 address IP2, it discards the packet if IP2 does
not belong to the configured list of IPv4 addresses. not belong to the configured list of IPv4 addresses.
3.2.3. Neighbor Reachability Check
Yet another approach that allows a router to verify that an end host
exists and can be reached via the tunnel is by performing an initial
reachability confirmation, e.g., as specified in the second paragraph
of Section 8.4 of [RFC5214]. This procedure parallels the address
resolution specifications in Section 7.2 of [RFC4861], i.e., the
router maintains a small queue of packets waiting for reachability
confirmation to complete. If confirmation succeeds, the router
discovers that a legitimate neighbor responds to the address and
packets may be forwarded to it. Otherwise, the router returns ICMP
destination unreachable indications as specified in Section 7.2.2 of
[RFC4861].
3.3. Operational Measures 3.3. Operational Measures
The following measures can be taken by the network operator. Their The following measures can be taken by the network operator. Their
aim is to configure the network in such a way that the attacks can aim is to configure the network in such a way that the attacks can
not take place. not take place.
3.3.1. Avoiding a Shared IPv4 Link 3.3.1. Avoiding a Shared IPv4 Link
As noted above, the attack relies on having an IPv4 network as a As noted above, the attack relies on having an IPv4 network as a
shared link-layer between more than one tunnel. From this the shared link-layer between more than one tunnel. From this the
skipping to change at page 10, line 36 skipping to change at page 10, line 23
In this measure a tunnel router may drop all IPv4 protocol-41 packets In this measure a tunnel router may drop all IPv4 protocol-41 packets
received or sent over interfaces that are attached to an untrusted received or sent over interfaces that are attached to an untrusted
IPv4 network. This will cut-off any IPv4 network as a shared link. IPv4 network. This will cut-off any IPv4 network as a shared link.
This measure has the advantage of simplicity. However, such a This measure has the advantage of simplicity. However, such a
measure may not always be suitable for scenarios where IPv4 measure may not always be suitable for scenarios where IPv4
connectivity is essential on all interfaces. connectivity is essential on all interfaces.
3.3.1.2. Operational Avoidance of Multiple Tunnels 3.3.1.2. Operational Avoidance of Multiple Tunnels
This measure mitigates the attack by simply allowing for a single This measure mitigates the attack by simply allowing for a single
IPv6 tunnel to operate in a bounded IPv4 network (e.g., a small home IPv6 tunnel to operate in a bounded IPv4 network. For example, the
IPv4 network behind a residential gateway serving as a tunnel attack can not take place in broadband home networks. In such cases
router). In particular, if there are only one or a few tunnel there is a small home network having a single residential gateway
routers in the IPv4 network and all participate in the same tunnel which serves as a tunnel router. A tunnel router is vulnerable to
then there is no opportunity for perpetuating the loop. the attack only if it has at least two interfaces with a path to the
Internet: a tunnel interface and a native IPv6 interface (as depicted
in Figure 1). However, a residential gateway usually has only a
single interface to the Internet, therefore the attack can not take
place. Moreover, if there are only one or a few tunnel routers in
the IPv4 network and all participate in the same tunnel then there is
no opportunity for perpetuating the loop.
This approach has the advantage that it avoids the attack profile This approach has the advantage that it avoids the attack profile
altogether without need for explicit mitigations. However, it altogether without need for explicit mitigations. However, it
requires careful configuration management which may not be tenable in requires careful configuration management which may not be tenable in
large and/or unbounded IPv4 networks. large and/or unbounded IPv4 networks.
3.3.2. A Single Border Router 3.3.2. A Single Border Router
It is reasonable to assume that a tunnel router shall accept or It is reasonable to assume that a tunnel router shall accept or
forward tunneled packets only over its tunnel interface. It is also forward tunneled packets only over its tunnel interface. It is also
skipping to change at page 11, line 18 skipping to change at page 11, line 10
router. router.
The above condition ensures that an encapsulated packet which is The above condition ensures that an encapsulated packet which is
transmitted over the tunnel interface will not get to another tunnel transmitted over the tunnel interface will not get to another tunnel
router and from there to the IPv6 interface of the first router. The router and from there to the IPv6 interface of the first router. The
condition also ensures the reverse direction, i.e., an IPv6 packet condition also ensures the reverse direction, i.e., an IPv6 packet
which is transmitted over the IPv6 interface will not get to another which is transmitted over the IPv6 interface will not get to another
tunnel router and from there to the tunnel interface of the first tunnel router and from there to the tunnel interface of the first
router. This condition is essentially translated to a scenario in router. This condition is essentially translated to a scenario in
which the tunnel router is the only border router between the IPv6 which the tunnel router is the only border router between the IPv6
network and the IPv4 network to which it is attached. network and the IPv4 network to which it is attached (as in broadband
home network scenario mentioned above).
4. Recommendations 4. Recommendations
In light of the mitigation measures proposed above we make the In light of the mitigation measures proposed above we make the
following recommendations in decreasing order: following recommendations in decreasing order:
1. When possible, it is recommended that the attacks are 1. When possible, it is recommended that the attacks are
operationally eliminated (as per one of the measures proposed in operationally eliminated (as per one of the measures proposed in
Section 3.3). Section 3.3).
skipping to change at page 11, line 40 skipping to change at page 11, line 33
cache which includes all legitimate end-points of the tunnel, we cache which includes all legitimate end-points of the tunnel, we
recommend exercising the Neighbor Cache Check. recommend exercising the Neighbor Cache Check.
3. For tunnel routers that can implement the Neighbor Reachability 3. For tunnel routers that can implement the Neighbor Reachability
Check, we recommend exercising it. Check, we recommend exercising it.
4. For tunnels having small and static list of end-points we 4. For tunnels having small and static list of end-points we
recommend exercising Known IPv4 Address Check. recommend exercising Known IPv4 Address Check.
5. For all other cases we recommend the Destination and Source 5. For all other cases we recommend the Destination and Source
Address Checks. Address Checks. This is the least preferable measure since it
generally can not mitigate routing loops with 6rd routers.
As noted earlier, tunnels may be deployed in various operational As noted earlier, tunnels may be deployed in various operational
environments. There is a possibility that other mitigation measures environments. There is a possibility that other mitigations may be
may be allowed is specific deployment scenarios. The above feasible in specific deployment scenarios. The above recommendations
recommendations are general and do not attempt to cover such are general and do not attempt to cover such scenarios.
scenarios.
5. IANA Considerations 5. IANA Considerations
This document has no IANA considerations. This document has no IANA considerations.
6. Security Considerations 6. Security Considerations
This document aims at presenting possible solutions to the routing This document aims at presenting possible solutions to the routing
loop attack which involves automatic tunnels' routers. It contains loop attack which involves automatic tunnels' routers. It contains
various checks that aim to recognize and drop specific packets that various checks that aim to recognize and drop specific packets that
skipping to change at page 12, line 35 skipping to change at page 12, line 26
8.1. Normative References 8.1. Normative References
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001. via IPv4 Clouds", RFC 3056, February 2001.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
March 2008. March 2008.
[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd)", RFC 5569, January 2010. Infrastructures (6rd)", RFC 5569, January 2010.
8.2. Informative References 8.2. Informative References
[I-D.gont-6man-teredo-loops]
Gont, F., "Mitigating Teredo Rooting Loop Attacks",
draft-gont-6man-teredo-loops-00 (work in progress),
September 2010.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
February 2006.
[RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-
Service Considerations", RFC 4732, December 2006.
[USENIX09] [USENIX09]
Nakibly, G. and M. Arov, "Routing Loop Attacks using IPv6 Nakibly, G. and M. Arov, "Routing Loop Attacks using IPv6
Tunnels", USENIX WOOT, August 2009. Tunnels", USENIX WOOT, August 2009.
Authors' Addresses Authors' Addresses
Gabi Nakibly Gabi Nakibly
National EW Research & Simulation Center National EW Research & Simulation Center
P.O. Box 2250 (630) P.O. Box 2250 (630)
Haifa 31021 Haifa 31021
 End of changes. 27 change blocks. 
74 lines changed or deleted 86 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/