draft-ietf-v6ops-tunnel-loops-03.txt		draft-ietf-v6ops-tunnel-loops-04.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: Standards Track Simulation Center
	Expires: August 8, 2011 F. Templin		Expires: September 10, 2011 F. Templin
	Boeing Research & Technology		Boeing Research & Technology
	February 04, 2011		March 09, 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-03.txt		draft-ietf-v6ops-tunnel-loops-04.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 August 8, 2011.		This Internet-Draft will expire on September 10, 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 23		skipping to change at page 2, line 23
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. A Detailed Description of the Attack . . . . . . . . . . . . . 4		2. A Detailed Description of the Attack . . . . . . . . . . . . . 4
	3. Proposed Mitigation Measures . . . . . . . . . . . . . . . . . 6		3. Proposed Mitigation Measures . . . . . . . . . . . . . . . . . 6
	3.1. Verification of end point existence . . . . . . . . . . . 6		3.1. Verification of end point existence . . . . . . . . . . . 6
	3.1.1. Neighbor Cache Check . . . . . . . . . . . . . . . . . 6		3.1.1. Neighbor Cache Check . . . . . . . . . . . . . . . . . 6
	3.1.2. Known IPv4 Address Check . . . . . . . . . . . . . . . 7		3.1.2. Known IPv4 Address Check . . . . . . . . . . . . . . . 7
	3.2. Operational Measures . . . . . . . . . . . . . . . . . . . 7		3.2. Operational Measures . . . . . . . . . . . . . . . . . . . 7
	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 . . . . . . . . . . . . . . . . 8		3.2.2. A Single Border Router . . . . . . . . . . . . . . . . 8
	3.2.3. A Comprehensive List of Tunnel Routers . . . . . . . . 9		3.2.3. A Comprehensive List of Tunnel Routers . . . . . . . . 9
	3.3. Destination and Source Address Checks . . . . . . . . . . 9		3.2.4. Avoidance of On-link Prefixes . . . . . . . . . . . . 9
	3.3.1. Known IPv6 Prefix Check . . . . . . . . . . . . . . . 11		3.3. Destination and Source Address Checks . . . . . . . . . . 21
	4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 11		3.3.1. Known IPv6 Prefix Check . . . . . . . . . . . . . . . 22
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 23
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 12		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12		6. Security Considerations . . . . . . . . . . . . . . . . . . . 24
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 12		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
	8.2. Informative References . . . . . . . . . . . . . . . . . . 13		8.1. Normative References . . . . . . . . . . . . . . . . . . . 24
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13		8.2. Informative References . . . . . . . . . . . . . . . . . . 25
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
	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 use stateless address mapping		network. Automatic tunnels that assign non-link-local IPv6 prefixes
	(hereafter called "automatic tunnels") are a category of tunnels in		with stateless address mapping properties (hereafter called
	which a tunneled packet's egress IPv4 address is embedded within the		"automatic tunnels") are a category of tunnels in which a tunneled
	destination IPv6 address of the packet. An automatic tunnel's router		packet's egress IPv4 address is embedded within the destination IPv6
	is a router that respectively encapsulates and decapsulates the IPv6		address of the packet. An automatic tunnel's router is a router that
	packets into and out of the tunnel.		respectively encapsulates and decapsulates the IPv6 packets into and
			out of the 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 poses a denial of		the tunnel. The assumption of path validity poses a denial of
	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
	skipping to change at page 4, line 25		skipping to change at page 4, line 25
	The two victims of this attack are routers - R1 and R2 - of two		The two victims of this attack are routers - R1 and R2 - of two
	different tunnels - T1 and T2. Both routers have the capability to		different tunnels - T1 and T2. Both routers have the capability to
	forward IPv6 packets in and out of their respective tunnels. The two		forward IPv6 packets in and out of their respective tunnels. The two
	tunnels need not be based on the same tunnel protocol. The only		tunnels need not be based on the same tunnel protocol. The only
	condition is that the two tunnel protocols be based on protocol-41		condition is that the two tunnel protocols be based on protocol-41
	encapsulation. The IPv4 address of R1 is IP1, while the prefix of		encapsulation. The IPv4 address of R1 is IP1, while the prefix of
	its tunnel is Prf1. IP2 and Prf2 are the respective values for R2.		its tunnel is Prf1. IP2 and Prf2 are the respective values for R2.
	We assume that IP1 and IP2 belong to the same address realm, i.e.,		We assume that IP1 and IP2 belong to the same address realm, i.e.,
	they are either both public, or both private and belong to the same		they are either both public, or both private and belong to the same
	internal network. The following network diagram depicts the		internal network. The following network diagram depicts the
	locations of the two routers.		locations of the two routers. The numbers indicate the packets of
			the attack and the path they traverse as described below.
	#######		#######
	# R1 #		# R1 #
	#######		#######
	// \		// \
	T1 // \		T1 // 2 \ 1
	interface // \		interface // \
	_______________//_ __\________________		_______________//_ __\________________
	| | | |		| | | |
	| IPv4 Network | | IPv6 Network |		| IPv4 Network | | IPv6 Network |
	|__________________| |___________________|		|__________________| |___________________|
	\\ /		\\ /
	\\ /		\\ /
	T2 \\ /		T2 \\ 2 / 0,1
	interface \\ /		interface \\ /
	#######		#######
	# R2 #		# R2 #
	#######		#######
	Figure 1: The network setting of the attack		Figure 1: The network setting of the attack
	The attack is depicted in Figure 2. It is initiated by sending an		The attack is depicted in Figure 2. It is initiated by sending an
	IPv6 packet (packet 0 in Figure 2) destined to a fictitious end point		IPv6 packet (packet 0 in Figure 2) destined to a fictitious end point
	that appears to be reached via T2 and has IP1 as its IPv4 address,		that appears to be reached via T2 and has IP1 as its IPv4 address,
	skipping to change at page 7, line 17		skipping to change at page 7, line 18
	reachability check on the packet's destination address, e.g., as		reachability check on the packet's destination address, e.g., as
	specified in the second paragraph of Section 8.4 of [RFC5214]. (The		specified in the second paragraph of Section 8.4 of [RFC5214]. (The
	router can similarly perform a "reverse reachability" check on the		router can similarly perform a "reverse reachability" check on the
	packet's source address when it receives a packet from a potential		packet's source address when it receives a packet from a potential
	tunnel host for which there is no neighbor cache entry.) This		tunnel host for which there is no neighbor cache entry.) This
	reachability check parallels the address resolution specifications in		reachability check parallels the address resolution specifications in
	Section 7.2 of [RFC4861], i.e., the router maintains a small queue of		Section 7.2 of [RFC4861], i.e., the router maintains a small queue of
	packets waiting for reachability confirmation to complete. If		packets waiting for reachability confirmation to complete. If
	confirmation succeeds, the router discovers that a legitimate tunnel		confirmation succeeds, the router discovers that a legitimate tunnel
	host responds to the address. Otherwise, the router discards		host responds to the address. Otherwise, the router discards
	subseqent packets and returns ICMP destination unreachable		subsequent packets and returns ICMP destination unreachable
	indications as specified in Section 7.2.2 of [RFC4861].		indications as specified in Section 7.2.2 of [RFC4861].
	Note that 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 neighbor		attacker to subvert the neighbor cache is to send false neighbor
	discovery messages with a spoofed source address.		discovery messages with a spoofed source address.
	3.1.2. Known IPv4 Address Check		3.1.2. Known IPv4 Address Check
	skipping to change at page 9, line 32		skipping to change at page 9, line 32
	network.		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.
			3.2.4. Avoidance of On-link Prefixes
			The looping attack exploits the fact that a router is permitted to
			assign non-link-local IPv6 prefixes on its tunnel interfaces, which
			could cause it to send tunneled packets to other routers that do not
			configure an address from the prefix. Therefore, if the router does
			not assign non-link-local IPv6 prefixes on its tunnel interfaces
			there is no opportunity for it to initiate the loop. If the router
			further ensures that the routing state is consistent for the packets
			it receives on its tunnel interfaces there is no opportunity for it
			to propagate a loop initiated by a different router.
			This mitigation is available only to ISATAP routers, since the ISATAP
			stateless address mapping operates only on the Interface Identifier
			portion of the IPv6 address, and not on the IPv6 prefix. . The
			mitigation is also only applicable on ISATAP links on which IPv4
			source address spoofing is disabled. This section specifies new
			operational procedures and mechanisms needed to implement the
			mitigation; it therefore updates [RFC5214].
			3.2.4.1. ISATAP Router Interface Types
			ISATAP provides a Potential Router List (PRL) to further ensure a
			loop-free topology. Routers that are members of the provider network
			PRL configure their provider network ISATAP interfaces as advertising
			router interfaces (see: [RFC4861], Section 6.2.2), and therefore may
			send Router Advertisement (RA) messages that include non-zero Router
			Lifetimes. Routers that are not members of the provider network PRL
			configure their provider network ISATAP interfaces as non-advertising
			router interfaces.
			3.2.4.2. ISATAP Source Address Verification
			ISATAP nodes employ the source address verification checks specified
			in Section 7.3 of [RFC5214] as a prerequisite for decapsulation of
			packets received on an ISATAP interface. To enable the on-link
			prefix avoidance procedures outlined in this section, ISATAP nodes
			must employ an additional source address verification check; namely,
			the node also considers the outer IPv4 source address correct for the
			inner IPv6 source address if:
			o a forwarding table entry exists that lists the packet's IPv4
			source address as the link-layer address corresponding to the
			inner IPv6 source address via the ISATAP interface.
			3.2.4.3. ISATAP Host Behavior
			ISATAP hosts send Router Solicitation (RS) messages to obtain RA
			messages from an advertising ISATAP router. Whether or not non-link-
			local IPv6 prefixes are advertised, the host can acquire IPv6
			addresses, e.g., through the use of DHCPv6 stateful address
			autoconfiguration [RFC3315]. To acquire addresses, the host performs
			standard DHCPv6 exchanges while mapping the IPv6
			"All_DHCP_Relay_Agents_and_Servers" link-scoped multicast address to
			the IPv4 address of the advertising router (hence, the advertising
			router must configure either a DHCPv6 relay or server function). The
			host should also use DHCPv6 Authentication, and the DHCPv6 server
			should refuse to process requests from hosts that cannot be
			authenticated.
			After the host receives IPv6 addresses, it assigns them to its ISATAP
			interface and forwards any of its outbound IPv6 packets via the
			advertising router as a default router. The advertising router in
			turn maintains IPv6 forwarding table entries in the CURRENT state
			that list the IPv4 address of the host as the link-layer address of
			the delegated IPv6 addresses, and generates redirection messages to
			inform the host of a better next hop when appropriate.
			3.2.4.4. ISATAP Router Behavior
			In many use case scenarios (e.g., small enterprise networks, etc.),
			advertising and non-advertising ISATAP routers can engage in a full-
			or partial-topology dynamic IPv6 routing protocol, so that IPv6
			routing/forwarding tables can be populated and standard IPv6
			forwarding between ISATAP routers can be used. In other scenarios
			(e.g., large ISP networks, etc.) this might be impractical dues to
			scaling and security issues.
			When a dynamic routing protocol cannot be used, non-advertising
			ISATAP routers send RS messages to obtain RA messages from an
			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 the use of DHCPv6 Prefix
			Delegation [RFC3633] via an advertising router in the same fashion as
			described above for host-based DHCPv6 stateful address
			autoconfiguration.
			After the non-advertising router acquires IPv6 prefixes, it can sub-
			delegate them to routers and links within its attached IPv6 edge
			networks, then can forward any outbound IPv6 packets coming from its
			edge networks via the advertising router as a default router. The
			advertising router in turn maintains IPv6 forwarding table entries in
			the CURRENT state that list the IPv4 address of the non-advertising
			router as the link-layer address of the next hop toward the delegated
			IPv6 prefixes, and generates redirection messages to inform the non-
			advertising router of a better next hop when appropriate.
			This implies that the advertising router considers the delegated
			prefixes as identifying the non-advertising router as an on-link
			neighbor for the purpose of generating redirection messages, and that
			the non-advertising router accepts redirection messages coming from
			the advertising router as though its ISATAP interface were configured
			as a host interface.
			3.2.4.5. Reference Operational Scenario
			Figure 3 depicts a reference ISATAP network topology for operational
			avoidance of on-link non-link-local IPv6 prefixes. The scenario
			shows an advertising ISATAP router, a non-advertising ISATAP router,
			an ISATAP host and a non-ISATAP IPv6 host in a typical deployment
			configuration:
			.-(::::::::)
			.-(::: IPv6 :::)-.
			(:::: Internet ::::)
			`-(::::::::::::)-'
			`-(::::::)-'
			,-.
			,-----+-/-+--' \+------.
			/ ,~~~~~~~~~~~~~~~~~, :
			/ |companion gateway| |.
			,-' '~~~~~~~~~~~~~~~~~' `.
			; +--------------+ )
			: | Router A | /
			: | (isatap) | ;
			+- +--------------+ -+
			; fe80::5efe:192.0.2.1 :
			| ;
			: IPv4 Provider Network -+-'
			`-. (PRL: 192.0.2.1) .)
			\ _)
			`-----+--------)----+'----'
			fe80::5efe:192.0.2.2 fe80::5efe:192.0.2.3
			2001:db8:0:1::1 +--------------+
			+--------------+ | (isatap) |
			| (isatap) | | Router C |
			| Host B | +--------------+
			+--------------+ 2001:db8:2::/48
			.-.
			,-( _)-. +------------+
			.-(_ IPv6 )-. |(non-isatap)|
			(__Edge Network )--| Host D |
			`-(______)-' +------------+
			2001:db8:2:1::1
			Figure 3: Reference ISATAP Network Topology
			In Figure 3, router 'A' within the IPv4 provider network connects to
			the IPv6 Internet, either directly or via a companion gateway. 'A'
			configures a provider network IPv4 interface with address 192.0.2.1
			and arranges to add the address to the provider network PRL. 'A'
			next configures an advertising ISATAP router interface with link-
			local IPv6 address fe80::5efe:192.0.2.1 over the IPv4 interface.
			Host 'B' connects to the provider network via an IPv4 interface with
			address 192.0.2.2, and also configures an ISATAP host interface with
			link-local address fe80::5efe:192.0.2.2 over the IPv4 interface. 'B'
			next configures a default IPv6 route with next-hop address fe80::
			5efe:192.0.2.1 via the ISATAP interface, then receives the IPv6
			address 2001:db8:0:1::1 from a DHCPv6 address configuration exchange
			via 'A'. When 'B' receives the IPv6 address, it assigns the address
			to the ISATAP interface but does not assign a non-link-local IPv6
			prefix to the interface.
			Router 'C' connects to one or more IPv6 edge networks and also
			connects to the provider network via an IPv4 interface with address
			192.0.2.3, but does not add the address to the provider network PRL.
			'C' next configures a non-advertising ISATAP router interface with
			link-local address fe80::5efe:192.0.2.3 over the IPv4 interface, but
			does not engage in an IPv6 routing protocol over the interface. 'C'
			therefore configures a default IPv6 route with next-hop address
			fe80::5efe:192.0.2.1 via the ISATAP interface, and receives the IPv6
			prefix 2001:db8:2::/48 through a DHCPv6 prefix delegation exchange
			via 'A'. 'C' finally sub-delegates the prefix to its IPv6 edge
			networks and configures its IPv6 edge network interfaces as
			advertising router interfaces.
			In this example, when 'B' has an IPv6 packet to send to host 'D'
			within an IPv6 edge network connected by 'C', it prepares the IPv6
			packet with source address 2001:db8:0:1::1 and destination address
			2001:db8:2:1::1. 'B' then uses ISATAP encapsulation to forward the
			packet to 'A' as its default router. 'A' forwards the packet to 'C',
			and also sends redirection messages to inform 'B' that 'C' is a
			better next hop toward 'D'. Future packets sent from 'B' to 'D'
			therefore go directly to 'C' without involving 'A'. An analogous
			redirection exchange occurs in the reverse direction when 'D' has a
			packet to send to 'B' (via 'C'). Details of the redirection
			exchanges are described in Section 3.2.4.6
			3.2.4.6. ISATAP Predirection
			With respect to the reference operational scenario depicted in
			Figure 3, when ISATAP router 'A' receives an IPv6 packet on an
			advertising ISATAP interface that it will forward back out the same
			interface, 'A' must arrange to redirect the originating ISATAP node
			'B' to a better next hop ISATAP node 'C' that is closer to the final
			destination 'D'. First, however, 'A' must direct 'C' to establish a
			forwarding table entry in order to satisfy the source address
			verification check specified in Section 3.2.4.2. This process is
			accommodated via a unidirectional reliable exchange in which 'A'
			first informs 'C', then 'C' informs 'B' via 'A' as a trusted
			intermediary. 'B' therefore knows that 'C' will accept the packets
			it sends as long as 'C' retains the forwarding table entry. We call
			this process "predirection", which stands in contrast to ordinary
			IPv6 redirection.
			Consider the alternative in which 'A' informs both 'B' and 'C'
			separately via independent IPv6 Redirect messages (see: [RFC4861]).
			In that case, several conditions can occur that could result in
			communications failures. First, if 'B' receives the Redirect message
			but 'C' does not, subsequent packets sent by 'B' would disappear into
			a black hole since 'C' would not have a forwarding table entry to
			verify their source addresses. Second, if 'C' receives the Redirect
			message but 'B' does not, subsequent packets sent in the reverse
			direction by 'C' would be lost. Finally, timing issues surrounding
			the establishment and garbage collection of forwarding table entries
			at 'B' and 'C' could yield unpredictable behavior. For example,
			unless the timing were carefully coordinated through some form of
			synchronization loop, there would invariably be instances in which
			one node has the correct forwarding table state and the other node
			does not resulting in non-deterministic packet loss.
			The following subsections discuss the predirection steps that support
			the reference operational scenario:
			3.2.4.6.1. 'A' Sends Predirect Forward To 'C'
			When 'A' forwards an original IPv6 packet sent by 'B' out the same
			ISATAP interface that it arrived on, it sends a "Predirect" message
			forward toward 'C' instead of sending a Redirect message back to 'B'.
			The Predirect message is simply an ISATAP-specific version of an
			ordinary IPv6 Redirect message as depicted in Section 4.5 of
			[RFC4861], and is identified by two new backward-compatible bits
			taken from the Reserved field as shown in Figure 4:
			0 1 2 3
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Type (=137) | Code (=0) | Checksum |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			|I|P| Reserved |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			+ +
			| |
			+ Target Address +
			| |
			+ +
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			+ +
			| |
			+ Destination Address +
			| |
			+ +
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Options ...
			+-+-+-+-+-+-+-+-+-+-+-+-
			Figure 4: ISATAP-Specific IPv6 Redirect Message Format
			Where the new bits are defined as:
			I (1) the "ISATAP" bit. Set to 1 to indicate an ISATAP-specific
			Redirect message, and set to 0 to indicate an ordinary IPv6
			Redirect message.
			P (1) the "Predirect" bit. Set to 1 to indicate a Predirect
			message, and set to 0 to indicate a Redirect response to a
			Predirect message. (This bit is valid only when the I bit is set
			to 1.)
			Using this new Predirect message format, 'A' prepares the message in
			a similar fashion as for an ordinary ISATAP-encapsulated IPv6
			Redirect message as follows:
			o the outer IPv4 source address is set to 'A's IPv4 address.
			o the outer IPv4 destination address is set to 'C's IPv4 address.
			o the inner IPv6 source address is set to 'A's ISATAP link-local
			address.
			o the inner IPv6 destination address is set to 'C's ISATAP link-
			local address.
			o the Predirect Target and Destination Addresses are both set to
			'B's ISATAP link-local address.
			o the Predirect message includes a Route Information Option (RIO)
			[RFC4191] that encodes an IPv6 prefix taken from 'B's address/
			prefix delegations that covers the IPv6 source address of the
			originating IPv6 packet.
			o the Predirect message includes a Redirected Header Option (RHO)
			that contains at least the header of the originating IPv6 packet.
			o the I and P bits in the Predirect message header are both set to
			1.
			'A' then sends the Predirect message forward to 'C'.
			3.2.4.6.2. 'C' Processes the Predirect and Sends Redirect Back To 'A'
			When 'C' receives the Predirect message, it decapsulates the message
			according to Section 7.3 of [RFC5214] since the outer IPv4 source
			address is a member of the PRL.
			'C' then uses the message validation checks specified in Section 8.1
			of [RFC4861], except that instead of verifying that the "IP source
			address of the Redirect is the same as the current first-hop router
			for the specified ICMP Destination Address" (i.e., the 6th
			verification check), it accepts the message if the "outer IP source
			address of the Predirect is the same as the current first-hop router
			for the prefix specified in the RIO". (Note that this represents an
			ISATAP-specific adaptation of the verification checks.) Finally, 'C'
			only accepts the message if the destination address of the
			originating IPv6 packet encapsulated in the RHO is covered by one of
			its CURRENT delegated addresses/prefixes (see Section 3.2.4.9).
			'C' then either creates or updates an IPv6 forwarding table entry
			with the prefix encoded in the RIO option as the target prefix, and
			the IPv6 Target Address of the Predirect message (i.e., 'B's ISATAP
			link-local address) as the next hop. 'C' places the entry in the
			FILTERING state, then sets/resets a filtering expiration timer value
			of 40 seconds. If the filtering timer expires, the node clears the
			FILTERING state and deletes the forwarding table entry if it is not
			in the FORWARDING state. This suggests that 'C's ISATAP interface
			should maintain a private forwarding table separate from the common
			IPv6 forwarding table, since the entry must be managed by the ISATAP
			interface itself.
			After processing the Predirect message and establishing the
			forwarding table entry, 'C' prepares an ISATAP Redirect message in
			response to the Predirect as follows:
			o the outer IPv4 source address is set to 'C's IPv4 address.
			o the outer IPv4 destination address is set to 'A's IPv4 address.
			o the inner IPv6 source address, is set to 'C's ISATAP link-local
			address.
			o the inner IPv6 destination address is set to 'A's ISATAP link-
			local address.
			o the Redirect Target and the Redirect Destination Addresses are
			both set to 'C's ISATAP link-local address.
			o the Redirect message includes an RIO that encodes an IPv6 prefix
			taken from 'C's address/prefix delegations that covers the IPv6
			destination address of the originating IPv6 packet encapsulated in
			the Redirected Header option of the Predirect.
			o the Redirect message includes an RHO copied from the corresponding
			Predirect message.
			o the (I, P) bits in the Redirect message header are set to (1, 0).
			'C' then sends the Redirect message to 'A'.
			3.2.4.6.3. 'A' Processes the Redirect then Proxies it Back To 'B'
			When 'A' receives the Predirect message, it decapsulates the message
			according to Section 7.3 of [RFC5214] since the inner IPv6 source
			address embeds the outer IPv4 source address.
			'A' next accepts the message only if it satisfies the same message
			validation checks specified for Predirects in Section 3.2.4.6.2.
			'A' then locates a forwarding table entry that covers the IPv6 source
			address of the packet segment in the RHO (i.e., a forwarding table
			entry with next hop 'B'), then proxies the Redirect message back
			toward 'B'. Without decrementing the IPv6 hop limit in the Redirect
			message, 'A' next changes the IPv4 source address of the Redirect
			message to its own IPv4 address, changes the IPv4 destination address
			to 'B's IPv4 address, changes the IPv6 source address to its own IPv6
			link-local address, and changes the IPv6 destination address to 'B's
			IPv6 link-local address. 'A' then sends the proxied Redirect message
			to 'B'.
			3.2.4.6.4. 'B' Processes The Redirect Message
			When 'B' receives the Redirect message, it decapsulates the message
			according to Section 7.3 of [RFC5214] since the outer IPv4 source
			address is a member of the PRL.
			'B' next accepts the message only if it satisfies the same message
			validation checks specified for Predirects in Section 3.2.4.6.2.
			'B' then either creates or updates an IPv6 forwarding table entry
			with the prefix encoded in the RIO option as the target prefix, and
			the IPv6 Target Address of the Redirect message (i.e., 'C's ISATAP
			link-local address) as the next hop. 'B' places the entry in the
			FORWARDING state, then sets/resets a forwarding expiration timer
			value of 30 seconds. If the forwarding timer expires, the node
			clears the FORWARDING state and deletes the forwarding table entry if
			it is not in the FILTERING state. Again, this suggests that 'B's
			ISATAP interface should maintain a private forwarding table separate
			from the common IPv6 forwarding table, since the entry must be
			managed by the ISATAP interface itself.
			Now, 'B' has a forwarding table entry in the FORWARDING state, and
			'C' has a forwarding table entry in the FILTERING state. Therefore,
			'B' may send ordinary IPv6 data packets with destination addresses
			covered by 'C's prefix directly to 'C' without involving 'A'. 'C'
			will in turn accept the packets since they satisfy the source address
			verification rule specified in Section 3.2.4.2.
			To enable packet forwarding from 'C' directly to 'B', a reverse-
			predirection operation is required which is the mirror-image of the
			forward-predirection operation described above. Following the
			reverse predirection, both 'B' and 'C' will have forwarding table
			entries in the "(FORWARDING | FILTERING)" state, and IPv6 packets can
			be exchanged bidirectionally without involving 'A'.
			3.2.4.6.5. 'B' Sends Periodic Predirect Messages Forward to 'A'
			In order to keep forwarding table entries alive while data packets
			are actively flowing, 'B' can periodically send additional Predirect
			messages via 'A' to solicit Redirect messages from 'C'. When 'B'
			forwards an IPv6 packet via 'C', and the corresponding forwarding
			table entry FORWARDING state timer is nearing expiration, 'B' sends
			Predirect messages (subject to rate limiting) prepared as follows:
			o the outer IPv4 source address is set to 'B's IPv4 address.
			o the outer IPv4 destination address is set to 'A's IPv4 address.
			o the inner IPv6 source address is set to 'B's ISATAP link-local
			address.
			o the inner IPv6 destination address is set to 'A's ISATAP link-
			local address.
			o the Predirect Target and Destination Addresses are both set to
			'B's ISATAP link-local address.
			o the Predirect message includes an RIO that encodes an IPv6 prefix
			taken from 'B's address/prefix delegations that covers the IPv6
			source address of the originating IPv6 packet.
			o the Predirect message includes an RHO that contains at least the
			header of the originating IPv6 packet.
			o the I and P bits in the Predirect message header are both set to
			1.
			When 'A' receives the Predirect message, it decapsulates the message
			according to Section 7.3 of [RFC5214] since the inner IPv6 source
			address embeds the outer IPv4 source address.
			'A' next accepts the message only if it satisfies the same message
			validation checks specified for Predirects in Section 3.2.4.6.2.
			'A' then locates a forwarding table entry that covers the IPv6
			destination address of the packet segment in the RHO (in this case, a
			forwarding table entry with next hop 'C'). Without decrementing the
			IPv6 hop limit in the Redirect message, 'A' next changes the IPv4
			source address of the Predirect message to its own IPv4 address,
			changes the IPv4 destination address to 'C's IPv4 address, changes
			the IPv6 source address to its own IPv6 link-local address, and
			changes the IPv6 destination address to 'C's IPv6 link-local address.
			'A' then sends the proxied Predirect message to 'C'. When 'C'
			receives the proxied message, it processes the message the same as if
			it had originated from 'A' as described in Section 3.2.4.6.2.
			3.2.4.7. Scaling Considerations
			Figure 3 depicts an ISATAP network topology with only a single
			advertising ISATAP router within the provider network. In order to
			support larger numbers of non-advertising ISATAP routers and ISATAP
			hosts, the provider network can deploy more advertising ISATAP
			routers to support load balancing and generally shortest-path
			routing.
			Such an arrangement requires that the advertising ISATAP routers
			participate in an IPv6 routing protocol instance so that IPv6
			address/prefix delegations can be mapped to the correct router. The
			routing protocol instance can be configured as either a full mesh
			topology involving all advertising ISATAP routers, or as a partial
			mesh topology with each ISATAP router associating with one or more
			companion gateways and a full mesh between companion gateways.
			3.2.4.8. Proxy Chaining
			In large ISATAP deployments, there may be many advertising ISATAP
			routers, each serving many ISATAP clients (i.e., both non-advertising
			routers and simple hosts). The advertising ISATAP routers then
			either require full topology knowledge, or a default route to a
			companion gateway that does have full topology knowledge. For
			example, if Client 'A' connects to advertising ISATAP router 'B', and
			Client 'E' connects to advertising ISATAP router 'D', then 'B' and
			'D' must either have full topology knowledge or have a default route
			to a companion gateway (e.g., 'C') that does.
			In that case, when 'A' sends an initial packet to 'E', 'B' generates
			a Predirect message toward 'C', which proxies the message toward 'D'
			which finally proxies the message toward 'E'.
			In the reverse direction, when 'E' sends a Redirect response message
			to 'A', it first sends the message to 'D', which proxies the message
			toward 'C', which proxies the message toward 'B', which finally
			proxies the message toward 'A'.
			3.2.4.9. Mobility
			An ISATAP router 'A' can configure both a non-advertising ISATAP
			interface on a provider network and an advertising ISATAP interface
			on an edge network. In that case, 'A' can service ISATAP clients
			(i.e. both non-advertising routers and simple hosts) within the edge
			network by acting as a DHCPv6 relay. When a client 'B' in the edge
			network that has obtained IPv6 addresses/prefixes moves to a
			different edge network, however, 'B' can release its address/prefix
			delegations via 'A' and re-establish them via a different ISATAP
			router 'C' in the new edge network.
			When 'B' releases its address/prefix delegations via 'A', 'A' marks
			the IPv6 forwarding table entries that cover the addresses/prefixes
			as DEPARTED (i.e., it clears the CURRENT state). 'A' therefore
			ceases to respond to Predirect messages correlated with the DEPARTED
			entries, and also schedules a garbage-collection timer of 60 seconds,
			after which it deletes the DEPARTED entries.
			When 'A' receives IPv6 packets destined to an address covered by the
			DEPARTED IPv6 forwarding table entries, it forwards them to the last-
			known edge network link-layer address of 'B' as a means for avoiding
			mobility-related packet loss during routing changes. Eventually,
			correspondents will receive new Redirect messages from the network to
			discover that 'B' is now associated with 'C'.
			Note that this mobility management method works the same way when the
			edge networks comprise native IPv6 links (i.e., and not just for
			ISATAP links), however any IPv6 packets forwarded by 'A' via an IPv6
			forwarding table entry in the DEPARTED state may be lost if the
			mobile node moves off-link with respect to its previous edge network
			point of attachment. This should not be a problem for large links
			(e.g., large cellular network deployments, large ISP networks, etc.)
			in which all/most mobility events are intra-link.
	3.3. Destination and Source Address Checks		3.3. 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
	forward an IPv6 packet into a tunnel interface with an IPv6 source		forward an IPv6 packet into a tunnel interface with an IPv6 source
	address that embeds one of the router's configured IPv4 addresses.		address that embeds one of the router's configured IPv4 addresses.
	Similarly, tunnel routers can use a destination address check		Similarly, tunnel routers can use a destination address check
	mitigation when they receive an IPv6 packet on a tunnel interface		mitigation when they receive an IPv6 packet on a tunnel interface
	with an IPv6 destination address that embeds one of the router's		with an IPv6 destination address that embeds one of the router's
	configured IPv4 addresses. These checks should correspond to both		configured IPv4 addresses. These checks should correspond to both
	tunnels' IPv6 address formats, regardless of the type of tunnel the		tunnels' IPv6 address formats, regardless of the type of tunnel the
	skipping to change at page 13, line 5		skipping to change at page 24, line 40
	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.
			[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
			and M. Carney, "Dynamic Host Configuration Protocol for
			IPv6 (DHCPv6)", RFC 3315, July 2003.
			[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
			Host Configuration Protocol (DHCP) version 6", RFC 3633,
			December 2003.
			[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
			More-Specific Routes", RFC 4191, November 2005.
	[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms		[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
	for IPv6 Hosts and Routers", RFC 4213, October 2005.		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.
End of changes. 12 change blocks.
	25 lines changed or deleted		582 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/