draft-ietf-v6ops-tunnel-loops-06.txt   draft-ietf-v6ops-tunnel-loops-07.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: October 1, 2011 F. Templin Expires: November 8, 2011 F. Templin
Boeing Research & Technology Boeing Research & Technology
March 30, 2011 May 7, 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-06.txt draft-ietf-v6ops-tunnel-loops-07.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
mitigation measures. mitigation measures. It should be noted that at the time of this
writing there are no known reports of malicious attacks exploiting
these vulnerabilities. Nonetheless, these vulnerabilities can be
activated by accidental misconfiguarion.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 October 1, 2011. This Internet-Draft will expire on November 8, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
skipping to change at page 2, line 27 skipping to change at page 2, line 31
3.1.1. Neighbor Cache Check . . . . . . . . . . . . . . . . . 7 3.1.1. Neighbor Cache Check . . . . . . . . . . . . . . . . . 7
3.1.2. Known IPv4 Address Check . . . . . . . . . . . . . . . 8 3.1.2. Known IPv4 Address Check . . . . . . . . . . . . . . . 8
3.2. Operational Measures . . . . . . . . . . . . . . . . . . . 8 3.2. Operational Measures . . . . . . . . . . . . . . . . . . . 8
3.2.1. Avoiding a Shared IPv4 Link . . . . . . . . . . . . . 8 3.2.1. Avoiding a Shared IPv4 Link . . . . . . . . . . . . . 8
3.2.2. A Single Border Router . . . . . . . . . . . . . . . . 9 3.2.2. A Single Border Router . . . . . . . . . . . . . . . . 9
3.2.3. A Comprehensive List of Tunnel Routers . . . . . . . . 9 3.2.3. A Comprehensive List of Tunnel Routers . . . . . . . . 9
3.2.4. Avoidance of On-link Prefixes . . . . . . . . . . . . 10 3.2.4. Avoidance of On-link Prefixes . . . . . . . . . . . . 10
3.3. Destination and Source Address Checks . . . . . . . . . . 15 3.3. Destination and Source Address Checks . . . . . . . . . . 15
3.3.1. Known IPv6 Prefix Check . . . . . . . . . . . . . . . 16 3.3.1. Known IPv6 Prefix Check . . . . . . . . . . . . . . . 16
4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 17 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 17
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . . 19 8.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
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
network. Automatic tunnels that assign non-link-local IPv6 prefixes network. Automatic tunnels that assign IPv6 prefixes with stateless
with stateless address mapping properties (hereafter called address mapping properties (hereafter called "automatic tunnels") are
"automatic tunnels") are a category of tunnels in which a tunneled a category of tunnels in which a tunneled packet's egress IPv4
packet's egress IPv4 address is embedded within the destination IPv6 address is embedded within the destination IPv6 address of the
address of the packet. An automatic tunnel's router is a router that packet. An automatic tunnel's router is a router that respectively
respectively encapsulates and decapsulates the IPv6 packets into and encapsulates and decapsulates the IPv6 packets into and out of the
out of the tunnel. tunnel.
Ref. [USENIX09] pointed out the existence of a vulnerability in the Ref. [USENIX09] pointed out the existence of a vulnerability in the
design of IPv6 automatic tunnels. Tunnel routers operate on the design of IPv6 automatic tunnels. Tunnel routers operate on the
implicit assumption that the destination address of an incoming IPv6 implicit assumption that the destination address of an incoming IPv6
packet is always an address of a valid node that can be reached via packet is always an address of a valid node that can be reached via
the tunnel. The assumption of path validity can introduce routing the tunnel. The assumption of path validity can introduce routing
loops as the inconsistency between the IPv4 routing state and the loops as the inconsistency between the IPv4 routing state and the
IPv6 routing state allows a routing loop to be formed. Although IPv6 routing state allows a routing loop to be formed. Although
those loops will not trap normal data, they will catch traffic those loops will not trap normal data, they will catch traffic
targeted at addresses that have become unavailable, and misconfigured targeted at addresses that have become unavailable, and misconfigured
skipping to change at page 6, line 30 skipping to change at page 6, line 30
Figure 2: Routing loop attack between two tunnels' routers Figure 2: Routing loop attack between two tunnels' routers
The crux of the attack is as follows. The attacker exploits the fact The crux of the attack is as follows. The attacker exploits the fact
that R2 does not know that R1 does not configure addresses from Prf2 that R2 does not know that R1 does not configure addresses from Prf2
and that R1 does not know that R2 does not configure addresses from and that R1 does not know that R2 does not configure addresses from
Prf1. The IPv4 network acts as a shared link layer for the two Prf1. The IPv4 network acts as a shared link layer for the two
tunnels. Hence, the packet is repeatedly forwarded by both routers. tunnels. Hence, the packet is repeatedly forwarded by both routers.
It is noted that the attack will fail when the IPv4 network can not It is noted that the attack will fail when the IPv4 network can not
transport packets between the tunnels. For example, when the two transport packets between the tunnels. For example, when the two
routers belong to different IPv4 address realms or when ingress/ routers belong to different IPv4 address realms or when ingress/
egress filtering is exercised between the routes. egress filtering is exercised between the routers.
The loop will stop when the Hop Limit field of the packet reaches The loop will stop when the Hop Limit field of the packet reaches
zero. After a single loop the Hop Limit field is decreased by the zero. After a single loop the Hop Limit field is decreased by the
number of IPv6 routers on path from R1 to R2. Therefore, the number number of IPv6 routers on path from R1 to R2. Therefore, the number
of loops is inversely proportional to the number of IPv6 hops between of loops is inversely proportional to the number of IPv6 hops between
R1 and R2. R1 and R2.
The tunnels used by R1 and R2 may be any combination of automatic The tunnels used by R1 and R2 may be any combination of automatic
tunnel types, e.g., ISATAP, 6to4 and 6rd. This has the exception tunnel types, e.g., ISATAP, 6to4 and 6rd. This has the exception
that both tunnels can not be of type 6to4, since two 6to4 routers that both tunnels can not be of type 6to4, since two 6to4 routers
skipping to change at page 8, line 42 skipping to change at page 8, line 42
shared link-layer between more than one tunnel. From this the shared link-layer between more than one tunnel. From this the
following two mitigation measures arise: following two mitigation measures arise:
3.2.1.1. Filtering IPv4 Protocol-41 Packets 3.2.1.1. Filtering IPv4 Protocol-41 Packets
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. Most notably, filtering
of IPv4 protocol-41 packets that belong to a 6to4 tunnel can have
real adverse affects on unsuspecting users
[I-D.ietf-v6ops-6to4-advisory].
3.2.1.2. Operational Avoidance of Multiple Tunnels 3.2.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. For example, the IPv6 tunnel to operate in a bounded IPv4 network. For example, the
attack can not take place in broadband home networks. In such cases attack can not take place in broadband home networks. In such cases
there is a small home network having a single residential gateway there is a small home network having a single residential gateway
which serves as a tunnel router. A tunnel router is vulnerable to which serves as a tunnel router. A tunnel router is vulnerable to
the attack only if it has at least two interfaces with a path to the 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 Internet: a tunnel interface and a native IPv6 interface (as depicted
skipping to change at page 9, line 42 skipping to change at page 9, line 45
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 (as in broadband network and the IPv4 network to which it is attached (as in broadband
home network scenario mentioned above). home network scenario mentioned above).
3.2.3. A Comprehensive List of Tunnel Routers 3.2.3. A Comprehensive List of Tunnel Routers
If a tunnel router can be configured with a comprehensive list of If a tunnel router can be configured with a comprehensive list of
IPv4 addresses of all other tunnel routers in the network, then the IPv4 addresses of all other tunnel routers in the network, then the
router can use the list as a filter to discard any tunneled packets router can use the list as a filter to discard any tunneled packets
coming from other routers. For example, a tunnel router can use the coming from or destined to other routers. For example, a tunnel
network's ISATAP Potential Router List (PRL) [RFC5214] as a filter as router can use the network's ISATAP Potential Router List (PRL)
long as there is operational assurance that all ISATAP routers are [RFC5214] as a filter as long as there is operational assurance that
listed and that no other types of tunnel routers are present in the all ISATAP routers are listed and that no other types of tunnel
network. routers are present in the network.
This measure parallels the one proposed for 6rd in [RFC5969] where This measure parallels the one proposed for 6rd in [RFC5969] where
the 6rd BR filters all known relay addresses of other tunnels inside the 6rd BR filters all known relay addresses of other tunnels inside
the ISP's network. the ISP's network.
This measure is especially useful for intra-site tunneling This measure is especially useful for intra-site tunneling
mechanisms, such as ISATAP and 6rd, since filtering can be exercised mechanisms, such as ISATAP and 6rd, since filtering can be exercised
on well-defined site borders. on well-defined site borders. A specific ISATAP operational scenario
for which this mitigation applies is described in Section 3 of
[I-D.templin-v6ops-isops].
3.2.4. Avoidance of On-link Prefixes 3.2.4. Avoidance of On-link Prefixes
The looping attack exploits the fact that a router is permitted to The looping attack exploits the fact that a router is permitted to
assign non-link-local IPv6 prefixes on its tunnel interfaces, which assign non-link-local IPv6 prefixes on its tunnel interfaces, which
could cause it to send tunneled packets to other routers that do not could cause it to send tunneled packets to other routers that do not
configure an address from the prefix. Therefore, if the router does configure an address from the prefix. Therefore, if the router does
not assign non-link-local IPv6 prefixes on its tunnel interfaces not assign non-link-local IPv6 prefixes on its tunnel interfaces
there is no opportunity for it to initiate the loop. If the router there is no opportunity for it to initiate the loop. If the router
further ensures that the routing state is consistent for the packets further ensures that the routing state is consistent for the packets
it receives on its tunnel interfaces there is no opportunity for it it receives on its tunnel interfaces there is no opportunity for it
to propagate a loop initiated by a different router. to propagate a loop initiated by a different router.
This mitigation is available only to ISATAP routers, since the ISATAP This mitigation is available only to ISATAP routers, since the ISATAP
stateless address mapping operates only on the Interface Identifier stateless address mapping operates only on the Interface Identifier
portion of the IPv6 address, and not on the IPv6 prefix. . The portion of the IPv6 address, and not on the IPv6 prefix. The
mitigation is also only applicable on ISATAP links on which IPv4 mitigation is also only applicable on ISATAP links on which IPv4
source address spoofing is disabled. The following sections discuss source address spoofing is disabled. The following sections discuss
the operational configurations necessary to implement the mitigation. the operational configurations necessary to implement the mitigation.
3.2.4.1. ISATAP Router Interface Types 3.2.4.1. ISATAP Router Interface Types
ISATAP provides a Potential Router List (PRL) to further ensure a ISATAP provides a Potential Router List (PRL) to further ensure a
loop-free topology. Routers that are members of the provider network loop-free topology. Routers that are members of the PRL for the site
PRL configure their provider network ISATAP interfaces as advertising configure their site-facing ISATAP interfaces as advertising router
router interfaces (see: [RFC4861], Section 6.2.2), and therefore may interfaces (see: [RFC4861], Section 6.2.2), and therefore may send RA
send Router Advertisement (RA) messages that include non-zero Router messages that include non-zero Router Lifetimes. Routers that are
Lifetimes. Routers that are not members of the provider network PRL not members of the PRL for the site configure their site-facing
configure their provider network ISATAP interfaces as non-advertising ISATAP interfaces as non-advertising router interfaces.
router interfaces.
3.2.4.2. ISATAP Source Address Verification 3.2.4.2. ISATAP Source Address Verification
ISATAP nodes employ the source address verification checks specified ISATAP nodes employ the source address verification checks specified
in Section 7.3 of [RFC5214] as a prerequisite for decapsulation of in Section 7.3 of [RFC5214] as a prerequisite for decapsulation of
packets received on an ISATAP interface. To enable the on-link packets received on an ISATAP interface. To enable the on-link
prefix avoidance procedures outlined in this section, ISATAP nodes prefix avoidance procedures outlined in this section, ISATAP nodes
must employ an additional source address verification check; namely, must employ an additional source address verification check; namely,
the node also considers the outer IPv4 source address correct for the the node also considers the outer IPv4 source address correct for the
inner IPv6 source address if: inner IPv6 source address if:
o a forwarding table entry exists that lists the packet's IPv4 o a forwarding table entry exists that lists the packet's IPv4
source address as the link-layer address corresponding to the source address as the link-layer address corresponding to the
inner IPv6 source address via the ISATAP interface. inner IPv6 source address via the ISATAP interface.
3.2.4.3. ISATAP Host Behavior 3.2.4.3. ISATAP Host Behavior
ISATAP hosts send Router Solicitation (RS) messages to obtain RA ISATAP hosts send RS messages to obtain RA messages from an
messages from an advertising ISATAP router. Whether or not non-link- advertising ISATAP router. Whether or not non-link-local IPv6
local IPv6 prefixes are advertised, the host can acquire IPv6 prefixes are advertised, the host can acquire IPv6 addresses, e.g.,
addresses, e.g., through the use of DHCPv6 stateful address through the use of DHCPv6 stateful address autoconfiguration
autoconfiguration [RFC3315]. [RFC3315].
To acquire addresses, the host performs standard DHCPv6 exchanges To acquire addresses, the host performs standard DHCPv6 exchanges
while mapping the IPv6 "All_DHCP_Relay_Agents_and_Servers" link- while mapping the IPv6 "All_DHCP_Relay_Agents_and_Servers" link-
scoped multicast address to the IPv4 address of the advertising scoped multicast address to the IPv4 address of the advertising
router (hence, the advertising router must configure either a DHCPv6 router (hence, the advertising router must configure either a DHCPv6
relay or server function). The host should also use DHCPv6 relay or server function). The host should also use DHCPv6
Authentication in environments where authentication of the DHCPv6 Authentication in environments where authentication of the DHCPv6
exchanges is required. exchanges is required.
After the host receives IPv6 addresses, it assigns them to its ISATAP After the host receives IPv6 addresses, it assigns them to its ISATAP
skipping to change at page 11, line 33 skipping to change at page 11, line 37
advertising router as a default router. The advertising router in advertising router as a default router. The advertising router in
turn maintains IPv6 forwarding table entries that list the IPv4 turn maintains IPv6 forwarding table entries that list the IPv4
address of the host as the link-layer address of the delegated IPv6 address of the host as the link-layer address of the delegated IPv6
addresses. addresses.
3.2.4.4. ISATAP Router Behavior 3.2.4.4. ISATAP Router Behavior
In many use case scenarios (e.g., enterprise networks, MANETs, etc.), In many use case scenarios (e.g., enterprise networks, MANETs, etc.),
advertising and non-advertising ISATAP routers can engage in a advertising and non-advertising ISATAP routers can engage in a
proactive dynamic IPv6 routing protocol (e.g., OSPFv3, RIPng, etc.) proactive dynamic IPv6 routing protocol (e.g., OSPFv3, RIPng, etc.)
so that IPv6 routing/forwarding tables can be populated and standard over their ISATAP interfaces so that IPv6 routing/forwarding tables
IPv6 forwarding between ISATAP routers can be used. In other can be populated and standard IPv6 forwarding between ISATAP routers
scenarios (e.g., large ISP networks, etc.), this might be impractical can be used. In other scenarios (e.g., large enterprise networks,
dues to scaling issues. When a proactive dynamic routing protocol etc.), this might be impractical due to scaling issues. When a
cannot be used, non-advertising ISATAP routers send RS messages to proactive dynamic routing protocol cannot be used, non-advertising
obtain RA messages from an advertising ISATAP router, i.e., they act ISATAP routers send RS messages to obtain RA messages from an
as "hosts" on their non-advertising ISATAP interfaces. advertising ISATAP router, i.e., they act as "hosts" on their non-
advertising ISATAP interfaces.
Non-advertising routers can also acquire IPv6 prefixes, e.g., through Non-advertising ISATAP routers can also acquire IPv6 prefixes, e.g.,
the use of DHCPv6 Prefix Delegation [RFC3633] via an advertising through the use of DHCPv6 Prefix Delegation [RFC3633] via an
router in the same fashion as described above for host-based DHCPv6 advertising router in the same fashion as described above for host-
stateful address autoconfiguration. The advertising router in turn based DHCPv6 stateful address autoconfiguration. The advertising
maintains IPv6 forwarding table entries that list the IPv4 address of router in turn maintains IPv6 forwarding table entries that list the
the non-advertising router as the link-layer address of the next hop IPv4 address of the non-advertising router as the link-layer address
toward the delegated IPv6 prefixes. of the next hop toward the delegated IPv6 prefixes.
After the non-advertising router acquires IPv6 prefixes, it can sub- After the non-advertising router acquires IPv6 prefixes, it can sub-
delegate them to routers and links within its attached IPv6 edge delegate them to routers and links within its attached IPv6 edge
networks, then can forward any outbound IPv6 packets coming from its networks, then can forward any outbound IPv6 packets coming from its
edge networks via other ISATAP nodes on the link. edge networks via other ISATAP nodes on the link.
3.2.4.5. Reference Operational Scenario 3.2.4.5. Reference Operational Scenario
Figure 3 depicts a reference ISATAP network topology for operational Figure 3 depicts a reference ISATAP network topology for operational
avoidance of on-link non-link-local IPv6 prefixes. The scenario avoidance of on-link non-link-local IPv6 prefixes. The scenario
shows an advertising ISATAP router ('A'), two non-advertising ISATAP shows two advertising ISATAP routers ('A', 'B'), two non-advertising
routers ('B', 'D'), an ISATAP host ('F'), and three ordinary IPv6 ISATAP routers ('C', 'E'), an ISATAP host ('G'), and three ordinary
hosts ('C', 'E', 'G') in a typical deployment configuration: IPv6 hosts ('D', 'F', 'H') in a typical deployment configuration:
.-(::::::::) 2001:db8:3::1
.-(::: IPv6 :::)-. +-------------+
(:::: Internet ::::) | IPv6 Host G |
`-(::::::::::::)-' +-------------+
`-(::::::)-'
,-.
,-----+-/-+--' \+------.
/ ,~~~~~~~~~~~~~~~~~, :
/ |companion gateway| |.
,-' '~~~~~~~~~~~~~~~~~' `.
; +--------------+ )
: | Router A | / fe80::5efe:192.0.2.4
: | (isatap) | ; 2001:db8:2::1
+- +--------------+ -+ +--------------+
; fe80::5efe:192.0.2.1 : | (isatap) |
| ; | Host F |
: IPv4 Provider Network -+-' +--------------+
`-. (PRL: 192.0.2.1) .)
\ _)
`-----+--------)----+'----'
fe80::5efe:192.0.2.2 fe80::5efe:192.0.2.3 .-.
+--------------+ +--------------+ ,-( _)-.
| (isatap) | | (isatap) | .-(_ IPv6 )-.
| Router B | | Router D |--(__Edge Network )
+--------------+ +--------------+ `-(______)-'
2001:db8::/48 2001:db8:1::/48 |
| 2001:db8:1::1
.-. +-------------+
,-( _)-. 2001:db8::1 | IPv6 Host E |
.-(_ IPv6 )-. +-------------+ +-------------+
(__Edge Network )--| IPv6 Host C |
`-(______)-' +-------------+
.-(::::::::) 2001:db8:3::1
.-(::: IPv6 :::)-. +-------------+
(:::: Internet ::::) | IPv6 Host H |
`-(::::::::::::)-' +-------------+
`-(::::::)-'
,~~~~~~~~~~~~~~~~~,
,----|companion gateway|--.
/ '~~~~~~~~~~~~~~~~~' :
/ |.
,-' `.
; +------------+ +------------+ )
: | Router A | | Router B | / fe80::*192.0.2.5
: | (isatap) | | (isatap) | ; 2001:db8:2::1
+ +------------+ +------------+ \ +--------------+
; fe80::*192.0.2.1 fe80::*192.0.2.2 : | (isatap) |
| ; | Host G |
: IPv4 Site -+-' +--------------+
`-. (PRL: 192.0.2.1, 192.0.2.2) .)
\ _)
`-----+--------)----+'----'
fe80::*192.0.2.3 fe80::*192.0.2.4 .-.
+--------------+ +--------------+ ,-( _)-.
| (isatap) | | (isatap) | .-(_ IPv6 )-.
| Router C | | Router E |--(__Edge Network )
+--------------+ +--------------+ `-(______)-'
2001:db8:0::/48 2001:db8:1::/48 |
| 2001:db8:1::1
.-. +-------------+
,-( _)-. 2001:db8::1 | IPv6 Host F |
.-(_ IPv6 )-. +-------------+ +-------------+
(__Edge Network )--| IPv6 Host D |
`-(______)-' +-------------+
(* == "5efe:")
Figure 3: Reference ISATAP Network Topology Figure 3: Reference ISATAP Network Topology
In Figure 3, advertising ISATAP router 'A' within the IPv4 provider In Figure 3, advertising ISATAP routers 'A' and 'B' within the IPv4
network connects to the IPv6 Internet, either directly or via a site connect to the IPv6 Internet, either directly or via a companion
companion gateway. 'A' configures a provider network IPv4 interface gateway. 'A' configures a provider network IPv4 interface with
with address 192.0.2.1 and arranges to add the address to the address 192.0.2.1 and arranges to add the address to the provider
provider network PRL. 'A' next configures an advertising ISATAP network PRL. 'A' next configures an advertising ISATAP router
router interface with link-local IPv6 address fe80::5efe:192.0.2.1 interface with link-local IPv6 address fe80::5efe:192.0.2.1 over the
over the IPv4 interface. IPv4 interface. In the same fashion, 'B' configures the IPv4
interface address 192.0.2.2, adds the address to the PRL, then
configures the IPv6 ISATAP interface link-local address fe80::5efe:
192.0.2.2.
Non-advertising ISATAP router 'B' connects to one or more IPv6 edge Non-advertising ISATAP router 'C' connects to one or more IPv6 edge
networks and also connects to the provider network via an IPv4 networks and also connects to the site via an IPv4 interface with
interface with address 192.0.2.2, but it does not add the IPv4 address 192.0.2.3, but it does not add the IPv4 address to the site's
address to the provider network PRL. 'B' next configures a non- PRL. 'C' next configures a non-advertising ISATAP router interface
advertising ISATAP router interface with link-local address fe80:: with link-local address fe80::5efe:192.0.2.3, then receives the IPv6
5efe:192.0.2.2, then receives the IPv6 prefix 2001:db8::/48 through a prefix 2001:db8::/48 through a DHCPv6 prefix delegation exchange via
DHCPv6 prefix delegation exchange via 'A'. 'B' then engages in an one of 'A' or 'B'. 'C' then engages in an IPv6 routing protocol over
IPv6 routing protocol over its ISATAP interface and announces the its ISATAP interface and announces the delegated IPv6 prefix. 'C'
delegated IPv6 prefix. 'B' finally sub-delegates the prefix to its finally sub-delegates the prefix to its attached edge networks, where
attached edge networks, where IPv6 host 'C' autoconfigures the IPv6 host 'D' autoconfigures the address 2001:db8::1.
address 2001:db8::1.
Non-advertising ISATAP router 'D' connects to the provider network, Non-advertising ISATAP router 'E' connects to the site, configures
configures its ISATAP interface, receives a DHCPv6 prefix delegation, its ISATAP interface, receives a DHCPv6 prefix delegation, and
and engages in the IPv6 routing protocol the same as for router 'B'. engages in the IPv6 routing protocol the same as for router 'C'. In
In particular, 'D' configures the IPv4 address 192.0.2.3, the ISATAP particular, 'E' configures the IPv4 address 192.0.2.4, the ISATAP
link-local address fe80::5efe:192.0.2.3, and the delegated IPv6 link-local address fe80::5efe:192.0.2.4, and the delegated IPv6
prefix 2001:db8:1::/48. 'D' finally sub-delegates the prefix to its prefix 2001:db8:1::/48. 'E' finally sub-delegates the prefix to its
attached edge networks, where IPv6 host 'E' autoconfigures IPv6 attached edge networks, where IPv6 host 'F' autoconfigures IPv6
address 2001:db8:1::1. address 2001:db8:1::1.
ISATAP host 'F' connects to the provider network via an IPv4 ISATAP host 'G' connects to the site via an IPv4 interface with
interface with address 192.0.2.4, and also configures an ISATAP host address 192.0.2.5, and also configures an ISATAP host interface with
interface with link-local address fe80::5efe:192.0.2.4 over the IPv4 link-local address fe80::5efe:192.0.2.5 over the IPv4 interface. 'G'
interface. 'F' next configures a default IPv6 route with next-hop next configures a default IPv6 route with next-hop address fe80::
address fe80::5efe:192.0.2.1 via the ISATAP interface, then receives 5efe:192.0.2.2 via the ISATAP interface, then receives the IPv6
the IPv6 address 2001:db8:2::1 from a DHCPv6 address configuration address 2001:db8:2::1 from a DHCPv6 address configuration exchange
exchange via 'A'. When 'F' receives the IPv6 address, it assigns the via 'B'. When 'G' receives the IPv6 address, it assigns the address
address to the ISATAP interface but does not assign a non-link-local to the ISATAP interface but does not assign a non-link-local IPv6
IPv6 prefix to the interface. prefix to the interface.
Finally, IPv6 host 'G' connects to an IPv6 network outside of the Finally, IPv6 host 'H' connects to an IPv6 network outside of the
ISATAP domain. 'G' configures its IPv6 interface in a manner ISATAP domain. 'H' configures its IPv6 interface in a manner
specific to its attached IPv6 link, and autoconfigures the IPv6 specific to its attached IPv6 link, and autoconfigures the IPv6
address 2001:db8:3::1. address 2001:db8:3::1.
Following this autoconfiguration, when host 'C' has an IPv6 packet to Following this autoconfiguration, when host 'D' has an IPv6 packet to
send to host 'E', it prepares the packet with source address 2001: send to host 'F', it prepares the packet with source address 2001:
db8::1 and destination address 2001:db8:1::1, then sends the packet db8::1 and destination address 2001:db8:1::1, then sends the packet
into the edge network where it will eventually be forwarded to router into the edge network where it will eventually be forwarded to router
'B'. 'B' then uses ISATAP encapsulation to forward the packet to 'C'. 'C' then uses ISATAP encapsulation to forward the packet to
router 'D', since it has discovered a route to 2001:db8:1::/48 with router 'E', since it has discovered a route to 2001:db8:1::/48 with
next hop 'D' via dynamic routing over the ISATAP interface. Router next hop 'E' via dynamic routing over the ISATAP interface. Router
'D' finally forwards the packet to host 'E'. 'E' finally forwards the packet to host 'F'.
In a second scenario, when 'C' has a packet to send to ISATAP host In a second scenario, when 'D' has a packet to send to ISATAP host
'F', it prepares the packet with source address 2001:db8::1 and 'G', it prepares the packet with source address 2001:db8::1 and
destination address 2001:db8:2::1, then sends the packet into the destination address 2001:db8:2::1, then sends the packet into the
edge network where it will eventually be forwarded to router 'B' the edge network where it will eventually be forwarded to router 'C' the
same as above. 'B' then uses ISATAP encapsulation to forward the same as above. 'C' then uses ISATAP encapsulation to forward the
packet to router 'A' (i.e., a router that advertises "default"), packet to router 'A' (i.e., a router that advertises "default"),
which in turn forwards the packet to 'F'. Note that this operation which in turn forwards the packet to 'G'. Note that this operation
entails two hops across the ISATAP link (i.e., one from 'B' to 'A', entails two hops across the ISATAP link (i.e., one from 'C' to 'A',
and a second from 'A' to 'F'). If 'F' also participates in the and a second from 'A' to 'G'). If 'G' also participates in the
dynamic IPv6 routing protocol, however, 'B' could instead forward the dynamic IPv6 routing protocol, however, 'C' could instead forward the
packet directly to 'F' without involving 'A'. packet directly to 'G' without involving 'A'.
In a final scenario, when 'C' has a packet to send to host 'G' in the In a third scenario, when 'D' has a packet to send to host 'H' in the
IPv6 Internet, the packet is forwarded to 'B' the same as above. 'B' IPv6 Internet, the packet is forwarded to 'C' the same as above. 'C'
then forwards the packet to 'A', which forwards the packet into the then forwards the packet to 'A', which forwards the packet into the
IPv6 Internet. IPv6 Internet.
In a final scenario, when 'G' has a packet to send to host 'H' in the
IPv6 Internet, the packet is forwarded directly to 'B', which
forwards the packet into the IPv6 Internet.
3.2.4.6. Scaling Considerations 3.2.4.6. Scaling Considerations
Figure 3 depicts an ISATAP network topology with only a single Figure 3 depicts an ISATAP network topology with only two advertising
advertising ISATAP router within the provider network. In order to ISATAP routers within the provider network. In order to support
support larger numbers of non-advertising ISATAP routers and ISATAP larger numbers of non-advertising ISATAP routers and ISATAP hosts,
hosts, the provider network can deploy more advertising ISATAP the provider network can deploy more advertising ISATAP routers to
routers to support load balancing and generally shortest-path support load balancing and generally shortest-path routing.
routing.
Such an arrangement requires that the advertising ISATAP routers Such an arrangement requires that the advertising ISATAP routers
participate in an IPv6 routing protocol instance so that IPv6 participate in an IPv6 routing protocol instance so that IPv6
address/prefix delegations can be mapped to the correct router. The address/prefix delegations can be mapped to the correct router. The
routing protocol instance can be configured as either a full mesh routing protocol instance can be configured as either a full mesh
topology involving all advertising ISATAP routers, or as a partial topology involving all advertising ISATAP routers, or as a partial
mesh topology with each advertising ISATAP router associating with mesh topology with each advertising ISATAP router associating with
one or more companion gateways and a full mesh between companion one or more companion gateways. Each such companion gateway would in
gateways. turn participate in a full mesh between all companion gateways.
3.2.4.7. On-Demand Dynamic Routing 3.2.4.7. On-Demand Dynamic Routing
With respect to the reference operational scenario depicted in With respect to the reference operational scenario depicted in
Figure 3, there will be many use cases in which a proactive dynamic Figure 3, there will be many use cases in which a proactive dynamic
IPv6 routing protocol cannot be used. For example, in large ISP IPv6 routing protocol cannot be used. For example, in large
network deployments it would be impractical for all Customer-Edge and enterprise network deployments it would be impractical for all
Provider-Edge routers to engage in a common routing protocol instance routers to engage in a common routing protocol instance due to
due to scaling considerations. scaling considerations.
In those cases, an on-demand routing capability can be enabled in In those cases, an on-demand routing capability can be enabled in
which ISATAP nodes send initial packets via an advertising ISATAP which ISATAP nodes send initial packets via an advertising ISATAP
router and receive redirection messages back. For example, when a router and receive redirection messages back. For example, when a
non-advertising ISATAP router 'B' has a packet to send to a host non-advertising ISATAP router 'B' has a packet to send to a host
located behind non-advertising ISATAP router 'D', it can send the located behind non-advertising ISATAP router 'D', it can send the
initial packets via advertising router 'A' which will return initial packets via advertising router 'A' which will return
redirection messages to inform 'B' that 'D' is a better first hop. redirection messages to inform 'B' that 'D' is a better first hop.
Protocol details for this ISATAP redirection are specified in Protocol details for this ISATAP redirection are specified in
[I-D.templin-aero]. [I-D.templin-aero].
skipping to change at page 15, line 46 skipping to change at page 16, line 13
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 no ancillary state is required, This approach has the advantage that no ancillary state is required,
since checking is through static lookup in the lists of IPv4 and IPv6 since checking is through static lookup in the lists of IPv4 and IPv6
addresses belonging to the router. However, this approach has some addresses belonging to the router. However, this approach has some
inherent limitations 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. Note that an unmitigated attack packet would may be considerable. Note that an unmitigated attack packet would
be repetitively processed by the router until the Hop Limit be repetitively processed by the router until the Hop Limit
expires, which may require as many as 255 iterations. Hence, an expires, which may require as many as 255 iterations. Hence, an
unmitigated attack will consume far more aggregate processing unmitigated attack will consume far more aggregate processing
overhead than per-packet address checks even if the router assigns overhead than per-packet address checks even if the router assigns
a large number of addresses. a large number of addresses.
skipping to change at page 19, line 16 skipping to change at page 19, line 27
Infrastructures (6rd) -- Protocol Specification", Infrastructures (6rd) -- Protocol Specification",
RFC 5969, August 2010. RFC 5969, August 2010.
8.2. Informative References 8.2. Informative References
[I-D.gont-6man-teredo-loops] [I-D.gont-6man-teredo-loops]
Gont, F., "Mitigating Teredo Rooting Loop Attacks", Gont, F., "Mitigating Teredo Rooting Loop Attacks",
draft-gont-6man-teredo-loops-00 (work in progress), draft-gont-6man-teredo-loops-00 (work in progress),
September 2010. September 2010.
[I-D.ietf-v6ops-6to4-advisory]
Carpenter, B., "Advisory Guidelines for 6to4 Deployment",
draft-ietf-v6ops-6to4-advisory-01 (work in progress),
April 2011.
[I-D.templin-aero] [I-D.templin-aero]
Templin, F., "Asymmetric Extended Route Optimization Templin, F., "Asymmetric Extended Route Optimization
(AERO)", draft-templin-aero-00 (work in progress), (AERO)", draft-templin-aero-00 (work in progress),
March 2011. March 2011.
[I-D.templin-v6ops-isops]
Templin, F., "Operational Guidance for IPv6 Deployment in
IPv4 Sites using ISATAP", draft-templin-v6ops-isops-00
(work in progress), May 2011.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380, Network Address Translations (NATs)", RFC 4380,
February 2006. February 2006.
[RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-
Service Considerations", RFC 4732, December 2006. 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.
 End of changes. 37 change blocks. 
150 lines changed or deleted 175 lines changed or added

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