< draft-ietf-shim6-failure-detection-06.txt		draft-ietf-shim6-failure-detection-07.txt >
	Network Working Group J. Arkko		Network Working Group J. Arkko
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Intended status: Informational I. van Beijnum		Expires: June 16, 2007 I. van Beijnum
	Expires: March 27, 2007 September 23, 2006		December 13, 2006
	Failure Detection and Locator Pair Exploration Protocol for IPv6		Failure Detection and Locator Pair Exploration Protocol for IPv6
	Multihoming		Multihoming
	draft-ietf-shim6-failure-detection-06		draft-ietf-shim6-failure-detection-07
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on March 27, 2007.		This Internet-Draft will expire on June 16, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The IETF Trust (2006).
	Abstract		Abstract
	This document specifies how the level 3 multihoming shim protocol		This document specifies how the level 3 multihoming shim protocol
	(SHIM6) detects failures between two communicating hosts. It also		(SHIM6) detects failures between two communicating hosts. It also
	specifies an exploration protocol for switching to another pair of		specifies an exploration protocol for switching to another pair of
	interfaces and/or addresses between the same hosts if a failure		interfaces and/or addresses between the same hosts if a failure
	occurs and an operational pair can be found.		occurs and an operational pair can be found.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Requirements language . . . . . . . . . . . . . . . . . . . . 4		2. Requirements language . . . . . . . . . . . . . . . . . . . . 5
	3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.1. Available Addresses . . . . . . . . . . . . . . . . . . 5		3.1. Available Addresses . . . . . . . . . . . . . . . . . . 6
	3.2. Locally Operational Addresses . . . . . . . . . . . . . 6		3.2. Locally Operational Addresses . . . . . . . . . . . . . 7
	3.3. Operational Address Pairs . . . . . . . . . . . . . . . 6		3.3. Operational Address Pairs . . . . . . . . . . . . . . . 7
	3.4. Primary Address Pair . . . . . . . . . . . . . . . . . . 8		3.4. Primary Address Pair . . . . . . . . . . . . . . . . . . 9
	3.5. Current Address Pair . . . . . . . . . . . . . . . . . . 8		3.5. Current Address Pair . . . . . . . . . . . . . . . . . . 9
	4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9		4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10
	4.1. Failure Detection . . . . . . . . . . . . . . . . . . . 9		4.1. Failure Detection . . . . . . . . . . . . . . . . . . . 10
	4.2. Alternative Address Pair Exploration . . . . . . . . . . 11		4.2. Full Reachability Exploration . . . . . . . . . . . . . 12
	4.3. Exploration Order . . . . . . . . . . . . . . . . . . . 12		4.3. Exploration Order . . . . . . . . . . . . . . . . . . . 13
	5. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 14		5. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 15
	5.1. Keepalive Message . . . . . . . . . . . . . . . . . . . 14		5.1. Keepalive Message . . . . . . . . . . . . . . . . . . . 15
	5.2. Probe Message . . . . . . . . . . . . . . . . . . . . . 15		5.2. Probe Message . . . . . . . . . . . . . . . . . . . . . 16
	6. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . 20		5.3. Keepalive Timeout Option Format . . . . . . . . . . . . 21
	7. Example Protocol Runs . . . . . . . . . . . . . . . . . . . . 24		6. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . 22
	8. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 29		6.1. Incoming payload packet . . . . . . . . . . . . . . . . 22
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 30		6.2. Outgoing payload packet . . . . . . . . . . . . . . . . 23
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32		6.3. Keepalive timeout . . . . . . . . . . . . . . . . . . . 23
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33		6.4. Send timeout . . . . . . . . . . . . . . . . . . . . . . 24
	11.1. Normative References . . . . . . . . . . . . . . . . . . 33		6.5. Retransmission . . . . . . . . . . . . . . . . . . . . . 24
	11.2. Informative References . . . . . . . . . . . . . . . . . 33		6.6. Reception of the Keepalive message . . . . . . . . . . . 24
	Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 35		6.7. Reception of the Probe message State=Exploring . . . . . 25
	Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 36		6.8. Reception of the Probe message State=InboundOk . . . . . 25
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37		6.9. Reception of the Probe message State=Operational . . . . 25
	Intellectual Property and Copyright Statements . . . . . . . . . . 38		6.10. Graphical Representation of the State Machine . . . . . 26
			7. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 27
			8. Security Considerations . . . . . . . . . . . . . . . . . . . 28
			9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
			10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
			10.1. Normative References . . . . . . . . . . . . . . . . . . 31
			10.2. Informative References . . . . . . . . . . . . . . . . . 31
			Appendix A. Example Protocol Runs . . . . . . . . . . . . . . . . 33
			Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 38
			Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 39
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
			Intellectual Property and Copyright Statements . . . . . . . . . . 41
	1. Introduction		1. Introduction
	The SHIM6 protocol [I-D.ietf-shim6-proto] extends IPv6 to support		The SHIM6 protocol [I-D.ietf-shim6-proto] extends IPv6 to support
	multihoming. It is an IP layer mechanism that hides multihoming from		multihoming. It is an IP layer mechanism that hides multihoming from
	applications. A part of the SHIM6 solution involves detecting when a		applications. A part of the SHIM6 solution involves detecting when a
	currently used pair of addresses (or interfaces) between two		currently used pair of addresses (or interfaces) between two
	communication hosts has failed, and picking another pair when this		communication hosts has failed, and picking another pair when this
	occurs. We call the former failure detection, and the latter locator		occurs. We call the former failure detection, and the latter locator
	pair exploration.		pair exploration.
	This document specifies the mechanisms and protocol messages to		This document specifies the mechanisms and protocol messages to
	achieve both failure detection and locator pair exploration. This		achieve both failure detection and locator pair exploration. This
	part of the SHIM6 protocol is called the REAchability Protocol		part of the SHIM6 protocol is called the REAchability Protocol
	(REAP).		(REAP).
	The document is structured as follows: Section 3 defines a set of		The document is structured as follows: Section 3 defines a set of
	useful terms, Section 4 gives an overview of REAP, and Section 5		useful terms, Section 4 gives an overview of REAP, and Section 5
	specifies the message formats and behaviour in detail. Section 9		specifies the message formats and behaviour in detail. Section 8
	discusses the security considerations of REAP.		discusses the security considerations of REAP.
	In this specification, we consider an address to be synonymous with a		In this specification, we consider an address to be synonymous with a
	locator. Other parts of the SHIM6 protocol ensure that the different		locator. Other parts of the SHIM6 protocol ensure that the different
	locators used by a node actually belong together. That is, REAP is		locators used by a node actually belong together. That is, REAP is
	not responsible for ensuring that it ends up with a legitimate		not responsible for ensuring that it ends up with a legitimate
	locator.		locator.
	2. Requirements language		2. Requirements language
	skipping to change at page 7, line 49 ¶		skipping to change at page 9, line 5 ¶
	suggestion is to use ICMP error messages only as a hint to perform		suggestion is to use ICMP error messages only as a hint to perform
	an explicit reachability test or move an address pair to a lower		an explicit reachability test or move an address pair to a lower
	place in the list of address pairs to be probed, but not as a		place in the list of address pairs to be probed, but not as a
	reason to disrupt ongoing communications without other indications		reason to disrupt ongoing communications without other indications
	of problems. The situation may be different when certain		of problems. The situation may be different when certain
	verifications of the ICMP messages are being performed, as		verifications of the ICMP messages are being performed, as
	explained by Gont in [I-D.ietf-tcpm-icmp-attacks]. These		explained by Gont in [I-D.ietf-tcpm-icmp-attacks]. These
	verifications can ensure that (practically) only on-path attackers		verifications can ensure that (practically) only on-path attackers
	can spoof the messages.		can spoof the messages.
	Note SHIM6 needs to perform a return routability test of an address
	before it is taken into use. The purpose of this test is to ensure
	that fraudulent peers do not trick others into redirecting traffic
	streams onto innocent victims. For a discussion of such attacks, see
	Aura et al [AURA02]. The test can at the same time work as a means
	to ensure that an address pair is operational, as discussed in
	Section 4.2.
	3.4. Primary Address Pair		3.4. Primary Address Pair
	The primary address pair consists of the ULID addresses that upper		The primary address pair consists of the addresses that upper layer
	layer protocols use in their interaction with the SHIM6 layer. Use		protocols use in their interaction with the SHIM6 layer. Use of the
	of the primary address pair means that the communication is		primary address pair means that the communication is compatible with
	compatible with regular non-SHIM6 communication and no context ID		regular non-SHIM6 communication and no context ID needs to be
	needs to be present.		present.
	3.5. Current Address Pair		3.5. Current Address Pair
	SHIM6 needs to avoid sending packets concurrently over multiple		SHIM6 needs to avoid sending packets which belong to the same
	paths, because congestion control in commonly used transport		transport connection concurrently over multiple paths. This is
	protocols is based upon a notion of a single path. While routing can		because congestion control in commonly used transport protocols is
	introduce path changes as well and transport protocols have means to		based upon a notion of a single path. While routing can introduce
	deal with this, frequent changes will cause problems. Efficient		path changes as well and transport protocols have means to deal with
	congestion control over multible paths is a considered research at		this, frequent changes will cause problems. Efficient congestion
	the time this specification is written.		control over multiple paths is a considered research at the time this
			specification is written.
	For these reasons it is necessary to choose a particular pair of		For these reasons it is necessary to choose a particular pair of
	addresses as the current address pair which is used until problems		addresses as the current address pair which is used until problems
	occur, at least for the same session.		occur, at least for the same session.
			It is theoretically possible to support multiple current address
			pairs for different transport sessions or SHIM6 contexts.
			However, this is not supported in this version of the SHIM6
			protocol.
	A current address pair need not be operational at all times. If		A current address pair need not be operational at all times. If
	there is no traffic to send, we may not know if the primary address		there is no traffic to send, we may not know if the primary address
	pair is operational. Nevertheless, it makes sense to assume that the		pair is operational. Nevertheless, it makes sense to assume that the
	address pair that worked in some time ago continues to be operational		address pair that worked in some time ago continues to be operational
	for new communications as well.		for new communications as well.
	4. Protocol Overview		4. Protocol Overview
	This section discusses the design of the reachability detection and		This section discusses the design of the reachability detection and
	address pair exploration mechanisms, and gives on overview of the		full reachability exploration mechanisms, and gives on overview of
	REAP protocol.		the REAP protocol.
	Exploring the full set of communication options between two hosts		Exploring the full set of communication options between two hosts
	that both have two or more addresses is an expensive operation as the		that both have two or more addresses is an expensive operation as the
	number of combinations to be explored increases very quickly with the		number of combinations to be explored increases very quickly with the
	number of addresses. For instance, with two addresses on both sides,		number of addresses. For instance, with two addresses on both sides,
	there are four possible address pairs. Since we can't assume that		there are four possible address pairs. Since we can't assume that
	reachability in one direction automatically means reachability for		reachability in one direction automatically means reachability for
	the complement pair in the other direction, the total number of two-		the complement pair in the other direction, the total number of two-
	way combinations is eight. (Combinations = nA * nB * 2.)		way combinations is eight. (Combinations = nA * nB * 2.)
	skipping to change at page 9, line 37 ¶		skipping to change at page 10, line 37 ¶
	4.1. Failure Detection		4.1. Failure Detection
	Failure detection consists of three parts: tracking local		Failure detection consists of three parts: tracking local
	information, tracking remote peer status, and finally verifying		information, tracking remote peer status, and finally verifying
	reachability. Tracking local information consists of using, for		reachability. Tracking local information consists of using, for
	instance, reachability information about the local router as an		instance, reachability information about the local router as an
	input. Nodes SHOULD employ techniques listed in Section 3.1 and		input. Nodes SHOULD employ techniques listed in Section 3.1 and
	Section 3.2 to be track the local situation. It is also necessary to		Section 3.2 to be track the local situation. It is also necessary to
	track remote address information from the peer. For instance, if the		track remote address information from the peer. For instance, if the
	peer's currently used address is no longer in use, mechanism to relay		peer's currently used address is no longer in use, mechanism to relay
	that information is needed. The Update message in the SHIM6 protocol		that information is needed. The Update Request message in the SHIM6
	is used for this purpose [I-D.ietf-shim6-proto]. Finally, when the		protocol is used for this purpose [I-D.ietf-shim6-proto]. Finally,
	local and remote information indicates that communication should be		when the local and remote information indicates that communication
	possible and there are upper layer packets to be sent, reachability		should be possible and there are upper layer packets to be sent,
	verification is necessary to ensure that the peers actually have an		reachability verification is necessary to ensure that the peers
	operational pair.		actually have an operational pair.
	A technique called Forced Bidirectional Detection (FBD, originally		A technique called Forced Bidirectional Detection (FBD, originally
	defined in an earlier SHIM6 document [I-D.ietf-shim6-reach-detect])		defined in an earlier SHIM6 document [I-D.ietf-shim6-reach-detect])
	is employed for the reachability verification. Reachability for the		is employed for the reachability verification. Reachability for the
	currently used address pair in a shim context is determined by making		currently used address pair in a SHIM6 context is determined by
	sure that whenever there is data traffic in one direction, there is		making sure that whenever there is data traffic in one direction,
	also traffic in the other direction. This can be data traffic as		there is also traffic in the other direction. This can be data
	well, but also transport layer acknowledgments or a REAP reachability		traffic as well, but also transport layer acknowledgments or a REAP
	keepalive if there is no other traffic. This way, it is no longer		reachability keepalive if there is no other traffic. This way, it is
	possible to have traffic in only one direction, so whenever there is		no longer possible to have traffic in only one direction, so whenever
	data traffic going out, but there are no return packets, there must		there is data traffic going out, but there are no return packets,
	be a failure, so the full exploration mechanism is started.		there must be a failure, so the full exploration mechanism is
			started.
	A more detailed description of the current pair reachability		A more detailed description of the current pair reachability
	evaluation mechanism:		evaluation mechanism:
	1. To avoid the other side from concluding there is a reachability		1. To avoid the other side from concluding there is a reachability
	failure, it's necessary for a host implementing the failure		failure, it's necessary for a host implementing the failure
	detection mechanism to generate periodic keepalives when there is		detection mechanism to generate periodic keepalives when there is
	no other traffic.		no other traffic.
	FBD works by generating REAP keepalives if the node is receiving		FBD works by generating REAP keepalives if the node is receiving
	packets from its peer but not sending any of its own. The		packets from its peer but not sending any of its own. The
	keepalives are sent at certain intervals so that the other side		keepalives are sent at certain intervals so that the other side
	knows there is a reachability problem when it doesn't receive any		knows there is a reachability problem when it doesn't receive any
	incoming packets for 10 seconds, the Keepalive Timeout.		incoming packets for its Send Timeout period. The host
	(Mechanisms to negotiate an alternative Keepalive Timeout may be		communicates its Send Timeout value to the peer as an Keepalive
	provided in the future.)		Timeout Option (section 5.3) in the I2, I2bis, R2, or UPDATE
			messages. The peer then maps this value to its Keepalive Timeout
			value.
	The interval after which keepalives are sent is named Keepalive		The interval after which keepalives are sent is named Keepalive
	Interval. This document doesn't specify a value for Keepalive		Interval. This document doesn't specify a value for Keepalive
	Interval, but recognizes that an often used approach is sending		Interval, but recognizes that an often used approach is sending
	keepalives at three times the timeout interval, which would be 3		keepalives at one-half to one-third of the Keepalive Timeout
	seconds here, and suggest a possible alternative of 4 seconds so		interval, so that multiple keepalives are generated and have time
	that two keepalives are generated and have time to reach the		to reach the correspondent before it times out. An upper bound
	correspondent. An upper bound would be 8 seconds, so that one		on this interval would be (Keepalive Timeout - 2) seconds, so
	keepalive has time to reach the other side, assuming a maximum		that one keepalive has time to reach the other side, assuming a
	one-way delay of 2 seconds.		maximum one-way delay of 2 seconds.
	2. Whenever outgoing data packets are generated, a timer is started		2. Whenever outgoing data packets are generated, a timer is started
	to reflect the requirement that the peer should generate return		to reflect the requirement that the peer should generate return
	traffic from data packets.		traffic from data packets. The timeout value is set to the value
			of Send Timeout.
	For the purposes of this specification, "data packet" refers to		For the purposes of this specification, "data packet" refers to
	any packet that is part of a shim context, including both upper		any packet that is part of a SHIM6 context, including both upper
	layer protocol packets and SHIM6 protocol messages except those		layer protocol packets and SHIM6 protocol messages except those
	defined in this specification.		defined in this specification.
	3. Whenever incoming data packets are received, the timer associated		3. Whenever incoming data packets are received, the timer associated
	with the return traffic from the peer is stopped, and another		with the return traffic from the peer is stopped, and another
	timer is started to reflect the requirement for this node to		timer is started to reflect the requirement for this node to
	generate return traffic.		generate return traffic. This timeout value is set to the value
			of Keepalive Timeout.
			These two timers are mutually exclusive. In other words, either
			the node is expecting to see traffic from the peer based the
			traffic that the node sent earlier or the node is expecting to
			respond to the peer based on the traffic that the peer sent
			earlier (or the node is in an idle state).
	4. The reception of a REAP keepalive packet leads to stopping the		4. The reception of a REAP keepalive packet leads to stopping the
	timer associated with the return traffic from the peer.		timer associated with the return traffic from the peer.
	5. Keepalive Interval seconds after the last data packet has been		5. Keepalive Interval seconds after the last data packet has been
	received for a context, and if no other packet has been sent		received for a context, and if no other packet has been sent
	within this context since the data packet has been received, a		within this context since the data packet has been received, a
	REAP keepalive packet is generated for the context in question		REAP keepalive packet is generated for the context in question
	and transmitted to the correspondent. A host may send the		and transmitted to the correspondent. A host may send the
	keepalive sooner than Keepalive Interval seconds if		keepalive sooner than Keepalive Interval seconds if
	implementation considerations warrant this, but should take care		implementation considerations warrant this, but should take care
	to avoid sending keepalives at an excessive rate. After sending		to to avoid sending keepalives at an excessive rate. REAP
	a single keepalive message, no additional keepalive messages are		keepalive packets SHOULD continue to be sent at the Keepalive
	sent until a data packet is received within this shim context.		Interval until either a data packet in the SHIM6 context has been
			received from the peer or the Keepalive Timeout expires.
	Keepalives are not sent at all when a data packet was sent since		Keepalives are not sent at all when a data packet was sent since
	the last received data packet.		the last received data packet.
	6. Send Timeout seconds (10 seconds; see Section 8) after the		6. Send Timeout seconds after the transmission of a data packet with
	transmission of a data packet with no return traffic on this		no return traffic on this context, a full reachability
	context, a full reachability exploration is started.		exploration is started.
	Note that the above timeout values are suggestions to be used as		Section 7 provides some suggested defaults for these timeout values.
	defaults. Experience from the deployment of the SHIM6 protocol is		Experience from the deployment of the SHIM6 protocol is needed in
	needed in order to determine what values are most suitable. The		order to determine what values are most suitable. The setting of
	setting of these values is also related to various parameters in		these values is also related to various parameters in transport
	transport protocols, such as TCP keepalive interval.		protocols, such as TCP keepalive interval.
	4.2. Alternative Address Pair Exploration		4.2. Full Reachability Exploration
	As explained in previous section, the currently used address pair may		As explained in previous section, the currently used address pair may
	become invalid either through one of the addresses being becoming		become invalid either through one of the addresses being becoming
	unavailable or inoperational, or the pair itself being declared		unavailable or inoperational, or the pair itself being declared
	inoperational. An exploration process attempts to find another		inoperational. An exploration process attempts to find another
	operational pair so that communications can resume.		operational pair so that communications can resume.
	What makes this process hard is the requirement to support		What makes this process hard is the requirement to support
	unidirectionally operational address pairs. It is insufficient to		unidirectionally operational address pairs. It is insufficient to
	probe address pairs by a simple request - response protocol.		probe address pairs by a simple request - response protocol.
	skipping to change at page 12, line 22 ¶		skipping to change at page 13, line 34 ¶
	Similarly, one can also envision that applications would be able to		Similarly, one can also envision that applications would be able to
	tell the IP or transport layer that the current connection in		tell the IP or transport layer that the current connection in
	unsatisfactory and an exploration for a better one would be		unsatisfactory and an exploration for a better one would be
	desirable. This would require an inter-layer communication mechanism		desirable. This would require an inter-layer communication mechanism
	to be developed, however. In any case, this is another issue that we		to be developed, however. In any case, this is another issue that we
	treat as being outside the scope of pure address exploration.		treat as being outside the scope of pure address exploration.
	REAP is designed to support failure recovery even in the case of		REAP is designed to support failure recovery even in the case of
	having only unidirectionally operational address pairs. However, due		having only unidirectionally operational address pairs. However, due
	to security concerns discussed in Section 9, the exploration process		to security concerns discussed in Section 8, the exploration process
	can typically be run only for a session that has already been		can typically be run only for a session that has already been
	established. Specifically, while REAP would in theory be capable of		established. Specifically, while REAP would in theory be capable of
	exploration even during connection establishment, its use within the		exploration even during connection establishment, its use within the
	SHIM6 protocol does not allow this.		SHIM6 protocol does not allow this.
	4.3. Exploration Order		4.3. Exploration Order
	The exploration process assumes an ability to choose address pairs		The exploration process assumes an ability to choose address pairs
	for testing, in some sequence. This process may result in a		for testing, in some sequence. This process may result in a
	combinatorial explosion when there are many addresses on both sides,		combinatorial explosion when there are many addresses on both sides,
	skipping to change at page 13, line 19 ¶		skipping to change at page 14, line 30 ¶
	attempt to test through all of them until an operational pair is		attempt to test through all of them until an operational pair is
	found, and retrying the process as is necessary. However, all nodes		found, and retrying the process as is necessary. However, all nodes
	MUST perform this process sequentially and with exponential back-off.		MUST perform this process sequentially and with exponential back-off.
	This sequential process is necessary in order to avoid a "signaling		This sequential process is necessary in order to avoid a "signaling
	storm" when an outage occurs (particularly for a complete site).		storm" when an outage occurs (particularly for a complete site).
	However, it also limits the number of addresses that can in practice		However, it also limits the number of addresses that can in practice
	be used for multihoming, considering that transport and application		be used for multihoming, considering that transport and application
	layer protocols will fail if the switch to a new address pair takes		layer protocols will fail if the switch to a new address pair takes
	too long.		too long.
	Section 8 suggests default values for the timers associated with the		Section 7 suggests default values for the timers associated with the
	exploration process. The value Initial Probe Timeout (0.5 seconds)		exploration process. The value Initial Probe Timeout (0.5 seconds)
	specifies the interval between initial attempts to send probes;		specifies the interval between initial attempts to send probes;
	Number of Initial Probes (4) specifies how many initial probes can be		Number of Initial Probes (4) specifies how many initial probes can be
	sent before the exponential backoff procedure needs to be employed.		sent before the exponential backoff procedure needs to be employed.
	This process increases the time between every probe if there is no		This process increases the time between every probe if there is no
	response. Typically, each increase doubles the time but this		response. Typically, each increase doubles the time but this
	specification does not mandate a particular increase.		specification does not mandate a particular increase.
	Finally, Max Probe Timeout (60 seconds) specifies a limit beyond		Finally, Max Probe Timeout (60 seconds) specifies a limit beyond
	which the probe interval may not grow. If the exploration process		which the probe interval may not grow. If the exploration process
	skipping to change at page 14, line 14 ¶		skipping to change at page 15, line 14 ¶
	5. Protocol Definition		5. Protocol Definition
	5.1. Keepalive Message		5.1. Keepalive Message
	The format of the keepalive message is as follows:		The format of the keepalive message is as follows:
	0 1 2 3		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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Next Header | Hdr Ext Len |0| Type = 66 | Reserved |0|		| Next Header | Hdr Ext Len |0| Type = 66 | Reserved1 |0|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Checksum |R| |		| Checksum |R| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| Receiver Context Tag |		| Receiver Context Tag |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Reserved2 |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ Options +		+ Options +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Next Header, Hdr Ext Len, 0, 0, Checksum		Next Header, Hdr Ext Len, 0, 0, Checksum
	These are as specified in Section 5.3 of the SHIM6 protocol		These are as specified in Section 5.3 of the SHIM6 protocol
	description [I-D.ietf-shim6-proto].		description [I-D.ietf-shim6-proto].
	Type		Type
	This field identifies the Probe message and MUST be set to 66		This field identifies the Probe message and MUST be set to 66
	(Keepalive).		(Keepalive).
	Reserved		Reserved1
	This is a 7-bit field reserved for future use. It is set to zero		This is a 7-bit field reserved for future use. It is set to zero
	on transmit, and MUST be ignored on receipt.		on transmit, and MUST be ignored on receipt.
	R		R
	This is a 1-bit field reserved for future use. It is set to zero		This is a 1-bit field reserved for future use. It is set to zero
	on transmit, and MUST be ignored on receipt.		on transmit, and MUST be ignored on receipt.
	Receiver Context Tag		Receiver Context Tag
	This is a 47-bit field for the Context Tag the receiver has		This is a 47-bit field for the Context Tag the receiver has
	allocated for the context.		allocated for the context.
			Reserved2
			This is a 32-bit field reserved for future use. It is set to zero
			on transmit, and MUST be ignored on receipt.
	Options		Options
	This MAY contain one or more SHIM6 options.The inclusion of the		This MAY contain one or more SHIM6 options.The inclusion of the
	latter options is not necessary, however, as there are currently		latter options is not necessary, however, as there are currently
	no defined options that are useful in a Keepalive message. These		no defined options that are useful in a Keepalive message. These
	options are provided only for future extensibility reasons.		options are provided only for future extensibility reasons.
	A valid message conforms to the format above, has a Receiver Context		A valid message conforms to the format above, has a Receiver Context
	Tag that matches to context known by the receiver, is valid shim		Tag that matches to context known by the receiver, is valid shim
	control message as defined in Section 12.2 of the SHIM6 protocol		control message as defined in Section 12.2 of the SHIM6 protocol
	skipping to change at page 16, line 13 ¶		skipping to change at page 17, line 18 ¶
	| |		| |
	+ First probe sent +		+ First probe sent +
	| |		| |
	+ Destination address +		+ Destination address +
	| |		| |
	+ +		+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| First probe nonce |		| First probe nonce |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| First probe option |		| First probe data |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	/ /		/ /
	/ Nth probe sent /		/ Nth probe sent /
	| |		| |
	+ Source address +		+ Source address +
	| |		| |
	+ +		+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ Nth probe sent +		+ Nth probe sent +
	| |		| |
	+ Destination address +		+ Destination address +
	| |		| |
	+ +		+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Nth probe nonce |		| Nth probe nonce |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Nth probe option |		| Nth probe data |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ First probe received +		+ First probe received +
	| |		| |
	+ Source address +		+ Source address +
	| |		| |
	+ +		+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ First probe received +		+ First probe received +
	| |		| |
	+ Destination address +		+ Destination address +
	| |		| |
	+ +		+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| First probe nonce |		| First probe nonce |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| First probe option |		| First probe data |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ Nth probe received +		+ Nth probe received +
	| |		| |
	+ Source address +		+ Source address +
	| |		| |
	+ +		+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ Nth probe received +		+ Nth probe received +
	| |		| |
	+ Destination address +		+ Destination address +
	| |		| |
	+ +		+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Nth probe nonce |		| Nth probe nonce |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Nth probe option |		| Nth probe data |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ Options +		+ Options +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ Options +		+ Options +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 18, line 34 ¶		skipping to change at page 19, line 39 ¶
	Precvd		Precvd
	This is a 4-bit field that indicates the number of received probes		This is a 4-bit field that indicates the number of received probes
	included in this probe messsage. Received probe fields are copies		included in this probe messsage. Received probe fields are copies
	of the same fields received in (recent) earlier probes and may be		of the same fields received in (recent) earlier probes and may be
	included or omitted as per any logic employed by the		included or omitted as per any logic employed by the
	implementation.		implementation.
	The fields probe source, probe destination, probe nonce and probe		The fields probe source, probe destination, probe nonce and probe
	option may be repeated, depending on the value of Psent and		data may be repeated, depending on the value of Psent and
	Preceived.		Preceived.
	Sta (State)		Sta (State)
	This 2-bit State field is used to inform the peer about the state		This 2-bit State field is used to inform the peer about the state
	of the sender. It has three legal values:		of the sender. It has three legal values:
	0 (Operational) implies that the sender both (a) believes it has		0 (Operational) implies that the sender both (a) believes it has
	no problem communicating and (b) believes that the recipient also		no problem communicating and (b) believes that the recipient also
	has no problem communicating.		has no problem communicating.
	1 (Exploring) implies that the sender has a problem communicating		1 (Exploring) implies that the sender has a problem communicating
	with the recipient, e.g., it has not seen any traffic from the		with the recipient, e.g., it has not seen any traffic from the
	recipient even when it expected some.		recipient even when it expected some.
	2 (ExploringOk) implies that the sender believes it has no problem		2 (InboundOk) implies that the sender believes it has no problem
	communicating, but that the recipient either has a problem or has		communicating, i.e., it at least sees packets from the recipient,
	not yet confirmed the sender that the problem has been solved.		but that the recipient either has a problem or has not yet
			confirmed to the sender that the problem has been solved.
	Reserved2		Reserved2
	MUST be set to 0 upon transmission and MUST be ignored upon		MUST be set to 0 upon transmission and MUST be ignored upon
	reception.		reception.
	Probe source		Probe source
	This 128-bit field contains the source IPv6 address used to send		This 128-bit field contains the source IPv6 address used to send
	the probe.		the probe.
	skipping to change at page 19, line 31 ¶		skipping to change at page 20, line 37 ¶
	This is a 32-bit field that is initialized by the sender with a		This is a 32-bit field that is initialized by the sender with a
	value that allows it to determine which sent probes a received		value that allows it to determine which sent probes a received
	probe correlates with. It is highly recommeded that the nonce		probe correlates with. It is highly recommeded that the nonce
	field is at least moderately hard to guess so that even on-path		field is at least moderately hard to guess so that even on-path
	attackers can't deduce the next nonce value that will be used.		attackers can't deduce the next nonce value that will be used.
	This value SHOULD be generated using a random number generator		This value SHOULD be generated using a random number generator
	that is known to have good randomness properties as outlined in		that is known to have good randomness properties as outlined in
	RFC 1750 [RFC1750].		RFC 1750 [RFC1750].
	Probe option		Probe data
	This is a 32-bit field with no fixed meaning. The probe option		This is a 32-bit field with no fixed meaning. The probe data
	field is copied back with no changes. Future flags may define a		field is copied back with no changes. Future flags may define a
	use for this field.		use for this field.
	Discussion: One potential use of this field relates to		Discussion: One potential use of this field relates to
	communicating delays between reception of a probe and		communicating delays between reception of a probe and
	transmission of a reply to it.		transmission of a reply to it.
	Options		Options
	For future extensions.		For future extensions.
			5.3. Keepalive Timeout Option Format
			Either side of a SHIM6 context can notify the peer of the value that
			it would prefer the peer to use as its Keepalive Timeout value. If
			the host is using a non-default Send Timeout value, it SHOULD
			communicate this value as a Keepalive Timeout value to the peer in
			the below option. This option MAY be sent in the I2, I2bis, R2, or
			UPDATE messages. The option SHOULD only need to be sent once in a
			given shim6 association. If a host receives this option it SHOULD
			update its Keepalive Timeout value for the correspondent.
			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 = 10 |0| Length = 4 |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			+ Reserved | Keepalive Timeout |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Fields:
			Type
			This field identifies the option and MUST be set to 10 (Keepalive
			Timeout).
			Length
			This field MUST be set as specified in Section 5.14 of the SHIM6
			protocol description [I-D.ietf-shim6-proto]. That is, it is set
			to 4.
			Reserved
			16-bit field reserved for future use. Set to zero upon transmit
			and MUST be ignored upon receipt.
			Keepalive Timeout
			Value in seconds corresponding to suggested Keepalive Timeout
			value for the peer.
	6. Behaviour		6. Behaviour
	The required behaviour of REAP nodes is specified below in the form		The required behaviour of REAP nodes is specified below in the form
	of a state machine. The externally observable behaviour of an		of a state machine. The externally observable behaviour of an
	implementation MUST conform to this state machine, but there is no		implementation MUST conform to this state machine, but there is no
	requirement that the implementation actually employs a state machine.		requirement that the implementation actually employs a state machine.
	Intermixed with the following description we also provide a state		Intermixed with the following description we also provide a state
	machine description in a tabular form. That form is only		machine description in a tabular form. That form is only
	informational, however.		informational, however.
	On a given context with a given peer, the node can be in one of three		On a given context with a given peer, the node can be in one of three
	states: Operational, Exploring, or ExploringOK. In the Operational		states: Operational, Exploring, or InboundOK. In the Operational
	state the underlying address pairs are assumed to be operational. In		state the underlying address pairs are assumed to be operational. In
	the Exploring state this node has observed a problem and has		the Exploring state this node has observed a problem and has
	currently not seen any traffic from the peer. Finally, in the		currently not seen any traffic from the peer. Finally, in the
	ExploringOK state this node sees traffic from the peer, but peer may		InboundOK state this node sees traffic from the peer, but peer may
	not yet see any traffic from this node so that the exploration		not yet see any traffic from this node so that the exploration
	process needs to continue.		process needs to continue.
	The node maintains also the Send timer (Send Timeout seconds) and		The node maintains also the Send timer (Send Timeout seconds) and
	Keepalive timer (Keepalive Timeout seconds). The Send timer reflects		Keepalive timer (Keepalive Timeout seconds). The Send timer reflects
	the requirement that when this node sends a payload packet there		the requirement that when this node sends a payload packet there
	should be some return traffic (either payload packets or Keepalive		should be some return traffic (either payload packets or Keepalive
	messages) within Send Timeout seconds. The Keepalive timer reflects		messages) within Send Timeout seconds. The Keepalive timer reflects
	the requirement that when this node receives a payload packet there		the requirement that when this node receives a payload packet there
	should a similar response towards the peer. The Keepalive timer is		should a similar response towards the peer. The Keepalive timer is
	only used within the Operational state, and the Send timer in the		only used within the Operational state, and the Send timer in the
	Operational and ExploringOK states. No timer is running in the		Operational and InboundOK states. No timer is running in the
	Exploring state.		Exploring state. As explained in Section 4.1, the two timers are
			mutually exclusive. That is, either the Keepalive timer is running
			or the Send timer is running (or no timer is running).
			Note that Appendix A gives some examples of typical protocol runs to
			illustrate the behaviour.
			6.1. Incoming payload packet
	Upon the reception of a payload packet in the Operational state, the		Upon the reception of a payload packet in the Operational state, the
	node starts the Keepalive timer if it is not yet running, and stops		node starts the Keepalive timer if it is not yet running, and stops
	the Send timer if it was running. If the node is in the Exploring		the Send timer if it was running.
	state it transitions to the ExploringOK state, sends a Probe message,
	and starts the Send timer. In the ExploringOK state the node stops
	the Send timer if it was running, but does not do anything else. The
	reception of SHIM6 control messages other than the Keepalive and
	Probe messages are treated similarly with payload packets.
	When sending a Probe message, the State field MUST be set to a value		If the node is in the Exploring state it transitions to the InboundOK
	that matches the conceptual state of the sender after sending the		state, sends a Probe message, and starts the Send timer. It fills
	Probe.		the Psent and corresponding Probe source address, Probe destination
			address, Probe nonce, and Probe data fields with information about
			recent Probe messages that have not yet been reported as seen by the
			peer. It also fills the Precvd and corresponding Probe source
			address, Probe destination address, Probe nonce, and Probe data
			fields with information about recent Probe messages it has seen from
			the peer. When sending a Probe message, the State field MUST be set
			to a value that matches the conceptual state of the sender after
			sending the Probe. In this case the node therefore sets the Sta
			field to 2 (InboundOk). The IP source and and destination addresses
			for sending the Probe message are selected as discussed in
			Section 4.3.
	1. EVENT: Incoming payload packet		In the InboundOK state the node stops the Send timer if it was
	=================================		running, but does not do anything else.
	Operational Exploring ExploringOk		The reception of SHIM6 control messages other than the Keepalive and
			Probe messages are treated similarly with payload packets.
			While the Keepalive timer is running, the node SHOULD send Keepalive
			messages to the peer with an interval of Keepalive Interval seconds.
			Conceptually, a separate timer is used to distinguish between the
			interval between Keepalive messages and the overall Keepalive Timeout
			interval. However, this separate timer is not modelled in the
			tabular or graphical state machines. When sent, the Keepalive
			message is constructed as described in Section 5.1. It is sent using
			the current address pair.
			Operational Exploring InboundOk
	-------------------------------------------------------------		-------------------------------------------------------------
	STOP Send; SEND Probe ExploringOk; STOP Send		STOP Send; SEND Probe InboundOk; STOP Send
	START Keepalive START Send;		START Keepalive START Send;
	GOTO ExploringOk		GOTO InboundOk
			6.2. Outgoing payload packet
	Upon sending a payload packet in the Operational state, the node		Upon sending a payload packet in the Operational state, the node
	stops the Keepalive timer if it was running and starts the Send timer		stops the Keepalive timer if it was running and starts the Send timer
	if it was not running. In the Exploring state there is no effect,		if it was not running. In the Exploring state there is no effect,
	and in the ExploringOK state the node simply starts the Send timer if		and in the InboundOK state the node simply starts the Send timer if
	it was not yet running. (The sending of SHIM6 control messages is		it was not yet running. (The sending of SHIM6 control messages is
	again treated similarly here.)		again treated similarly here.)
	2. EVENT: Outgoing payload packet		Operational Exploring InboundOk
	=================================
	Operational Exploring ExploringOk
	-----------------------------------------------------------		-----------------------------------------------------------
	START Send; - START Send		START Send; - START Send
	STOP Keepalive		STOP Keepalive
	Upon a timeout on the Keepalive timer the node sends a Keepalive		6.3. Keepalive timeout
	message. This can only happen in the Operational state.
	3. EVENT: Keepalive timeout		Upon a timeout on the Keepalive timer, the node sends one last
			Keepalive message and cancels the timer governing the sending of the
			next Keepalive message. This can only happen in the Operational
			state.
	Operational Exploring ExploringOk		The Keepalive message is constructed as described in Section 5.1. It
			is sent using the current address pair.
			Operational Exploring InboundOk
	-----------------------------------------------------------		-----------------------------------------------------------
	SEND Keepalive - -		SEND Keepalive; - -
			STOP Keepalive
	Upon a timeout on the Send timer, the node enters the Exploring		6.4. Send timeout
	state, sends a Probe, and stops the Keepalive timer if it was
	running.
	4. EVENT: Send timeout		Upon a timeout on the Send timer, the node enters the Exploring
	======================		state, sends a Probe message, and stops the Keepalive timer if it was
			running. The Probe message is constructed as explained in
			Section 6.1, except that the Sta field is set to 1 (Exploring).
	Operational Exploring ExploringOk		Operational Exploring InboundOk
	-----------------------------------------------------------		-----------------------------------------------------------
	SEND Probe Exploring; - SEND Probe Exploring;		SEND Probe Exploring; - SEND Probe Exploring;
	STOP Keepalive; GOTO Exploring		STOP Keepalive; GOTO Exploring
	GOTO Exploring		GOTO Exploring
			6.5. Retransmission
	While in the Exploring state the node keeps retransmitting its Probe		While in the Exploring state the node keeps retransmitting its Probe
	messages to different (or same) addresses as defined in Section 4.3.		messages to different (or same) addresses as defined in Section 4.3.
			A similar process is employed in the InboundOk state, except that
	A similar process is employed in the ExploringOk state, except that
	upon such retransmission the Send timer is started if it was not		upon such retransmission the Send timer is started if it was not
	running already.		running already.
	5. EVENT: Retransmission		The Probe messages are constructed as explained in Section 6.1,
	========================		except that the Sta field is set to 1 (Exploring) or 2 (InboundOk),
			depending on which state the sender is in.
	Operational Exploring ExploringOk		Operational Exploring InboundOk
	----------------------------------------------------------		----------------------------------------------------------
	- SEND Probe Exploring SEND Probe ExploringOk		- SEND Probe Exploring SEND Probe InboundOk
	START Send		START Send
			6.6. Reception of the Keepalive message
	Upon the reception of a Keepalive message in the Operational state,		Upon the reception of a Keepalive message in the Operational state,
	the node stops the Send timer, if it was running. If the node is in		the node stops the Send timer, if it was running. If the node is in
	the Exploring state it transitions to the ExploringOK state, sends a		the Exploring state it transitions to the InboundOK state, sends a
	Probe message, and starts the Send timer. In the ExploringOK state		Probe message, and starts the Send timer. The Probe message is
	the Send timer is stopped, if it was running.		constructed as explained in Section 6.1.
	6. EVENT: Reception of the Keepalive message		In the InboundOK state the Send timer is stopped, if it was running.
	============================================
	Operational Exploring ExploringOk		Operational Exploring InboundOk
	-----------------------------------------------------------		-----------------------------------------------------------
	STOP Send SEND Probe ExploringOk; STOP Send		STOP Send SEND Probe InboundOk; STOP Send
	START Send;		START Send;
	GOTO ExploringOk		GOTO InboundOk
	Upon receiving a Probe with State set to Exploring, the node enters		6.7. Reception of the Probe message State=Exploring
	the ExploringOK state, sends a Probe, stops the Keepalive timer if it
	was running, and restarts the Send timer.
	7. EVENT: Reception of the Probe message State=Exploring		Upon receiving a Probe with State set to Exploring, the node enters
	========================================================		the InboundOK state, sends a Probe as described in Section 6.1, stops
			the Keepalive timer if it was running, and restarts the Send timer.
	Operational Exploring ExploringOk		Operational Exploring InboundOk
	-----------------------------------------------------------		-----------------------------------------------------------
	SEND Probe ExploringOk; SEND Probe ExploringOk; SEND Probe		SEND Probe InboundOk; SEND Probe InboundOk; SEND Probe
	STOP Keepalive; START Send; ExploringOk;		STOP Keepalive; START Send; InboundOk;
	RESTART Send; GOTO ExploringOk RESTART Send		RESTART Send; GOTO InboundOk RESTART Send
	GOTO ExploringOk		GOTO InboundOk
	Upon the reception of a Probe message with State set to ExploringOk,		6.8. Reception of the Probe message State=InboundOk
			Upon the reception of a Probe message with State set to InboundOk,
	the node sends a Probe message, restarts the Send timer, stops the		the node sends a Probe message, restarts the Send timer, stops the
	Keepalive timer if it was running, and transitions to the Operational		Keepalive timer if it was running, and transitions to the Operational
	state.		state.
	8. EVENT: Reception of the Probe message State=ExploringOk		The Probe message is constructed as explained in Section 6.1, except
	==========================================================		that the Sta field is set to 0 (Operational).
	Operational Exploring ExploringOk		Operational Exploring InboundOk
	-------------------------------------------------------------		-------------------------------------------------------------
	SEND Probe Operational; SEND Probe Operational; SEND Probe		SEND Probe Operational; SEND Probe Operational; SEND Probe
	RESTART Send; RESTART Send; Operational;		RESTART Send; RESTART Send; Operational;
	STOP Keepalive GOTO Operational RESTART Send;		STOP Keepalive GOTO Operational RESTART Send;
	GOTO Operational		GOTO Operational
			6.9. Reception of the Probe message State=Operational
	Upon the reception of a Probe message with State set to Operational,		Upon the reception of a Probe message with State set to Operational,
	the node stops the Send timer if it was running, starts the Keepalive		the node stops the Send timer if it was running, starts the Keepalive
	timer if it was not yet running, and transitions to the Operational		timer if it was not yet running, and transitions to the Operational
	state.		state. The Probe message is constructed as explained in Section 6.1,
			except that the Sta field is set to 0 (Operational).
	Note: This terminates the exploration process when both parties		Note: This terminates the exploration process when both parties
	are happy and know that their peer is happy as well.		are happy and know that their peer is happy as well.
	9. EVENT: Reception of the Probe message State=Operational		Operational Exploring InboundOk
	==========================================================
	Operational Exploring ExploringOk
	-----------------------------------------------------------		-----------------------------------------------------------
	STOP Send STOP Send; STOP Send;		STOP Send STOP Send; STOP Send;
	START Keepalive START Keepalive START Keepalive		START Keepalive START Keepalive START Keepalive
	GOTO Operational GOTO Operational		GOTO Operational GOTO Operational
	The reachability detection and exploration process has no effect on		The reachability detection and exploration process has no effect on
	payload communications until a new operational address pairs have		payload communications until a new operational address pairs have
	actually been confirmed. Prior to that the payload packets continue		actually been confirmed. Prior to that the payload packets continue
	to be sent to the previously used addresses.		to be sent to the previously used addresses.
			6.10. Graphical Representation of the State Machine
	In the PDF version of this specification, an informational drawing		In the PDF version of this specification, an informational drawing
	illustrates the state machine. Where the text and the drawing		illustrates the state machine. Where the text and the drawing
	differ, the text takes precedence.		differ, the text takes precedence.
	7. Example Protocol Runs		7. Protocol Constants
	This section has examples of REAP protocol runs in typical scenarios.		The following protocol constants are defined:
	We start with the simplest scenario of two hosts, A and B, that have
	a SHIM6 connection with each other but are not currently sending any		Send Timeout 10 seconds
	data. As neither side sends anything, they also do not expect		Keepalive Interval Not specified here
	anything back, so there are no messages at all:		Initial Probe Timeout 0.5 seconds
			Number of Initial Probes 4 probes
			Max Probe Timeout 60 seconds
			Alternate values of the Send Timeout may be selected by a host and
			communicated to the peer in the Keepalive Timeout Option.
			8. Security Considerations
			Attackers may spoof various indications from lower layers and the
			network in an effort to confuse the peers about which addresses are
			or are not operational. For example, attackers may spoof ICMP error
			messages in an effort to cause the parties to move their traffic
			elsewhere or even to disconnect. Attackers may also spoof
			information related to network attachments, router discovery, and
			address assignments in an effort to make the parties believe they
			have Internet connectivity when in reality they do not.
			This may cause use of non-preferred addresses or even denial-of-
			service.
			This protocol does not provide any protection of its own for
			indications from other parts of the protocol stack. Unprotected
			indications SHOULD NOT be taken as a proof of connectivity problems.
			However, REAP has weak resistance against incorrect information even
			from unprotected indications in the sense that it performs its own
			tests prior to picking a new address pair. Denial-of- service
			vulnerabilities remain, however, as do vulnerabilities against on
			path attackers.
			Some aspects of these vulnerabilities can be mitigated through the
			use of techniques specific to the other parts of the stack, such as
			properly dealing with ICMP errors [I-D.ietf-tcpm-icmp-attacks], link
			layer security, or the use of SEND [RFC3971] to protect IPv6 Router
			and Neighbor Discovery.
			Other parts of the SHIM6 protocol ensure that the set of addresses we
			are switching between actually belong together. REAP itself provides
			no such assurances. Similarly, REAP provides some protection against
			third party flooding attacks [AURA02]; when REAP is run its Probe
			nonces can be used as a return routability check that the claimed
			address is indeed willing to receive traffic. However, this needs to
			be complemented with another mechanism to ensure that the claimed
			address is also the correct host. SHIM6 does this by performing
			binding of all operations to context tags.
			The keepalive mechanism in this specification is vulnerable to
			spoofing. On path-attackers that can see a SHIM6 context tag can
			send spoofed Keepalive messages once per Send Timeout interval, to
			prevent two SHIM6 nodes from sending Keepalives themselves. This
			vulnerability is only relevant to nodes involved in a one-way
			communication. The result of the attack is that the nodes enter the
			exploration phase needlessly, but they should be able to confirm
			connectivity unless, of course, the attacker is able to prevent the
			exploration phase from completing. Off-path attackers may not be
			able to generate spoofed results, given that the context tags are 47-
			bit random numbers.
			The exploration phase is vulnerable to attackers that are on the
			path. Off-path attackers would find it hard to guess either the
			context tag or the correct probe identifiers. Given that IPsec
			operates above the shim layer, it is not possible to protect the
			exploration phase against on-path attackers. This is similar to the
			ability to protect other Shim6 control exchanges. There are
			mechanisms in place to prevent the redirection of communications to
			wrong addresses, but on-path attackers can cause denial-of-service,
			move communications to less-preferred address pairs, and so on.
			Finally, the exploration itself can cause a number of packets to be
			sent. As a result it may be used as a tool for packet amplification
			in flooding attacks. In order to prevent this it is required that
			the protocol employing REAP has built-in mechanisms to prevent this.
			For instance, in SHIM6 contexts are created only after a relatively
			large number of packets has been exchanged, a cost which reduces the
			attractiveness of using SHIM6 and REAP for amplification attacks.
			However, such protections are typically not present at connection
			establishment time. When exploration would be needed for connection
			establishment to succeed, its usage would result in an amplification
			vulnerability. As a result, SHIM6 does not support the use of REAP
			in connection establishment stage.
			9. IANA Considerations
			No IANA actions are required.
			10. References
			10.1. Normative References
			[RFC1750] Eastlake, D., Crocker, S., and J. Schiller, "Randomness
			Recommendations for Security", RFC 1750, December 1994.
			[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", BCP 14, RFC 2119, March 1997.
			[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
			Discovery for IP Version 6 (IPv6)", RFC 2461,
			December 1998.
			[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
			Autoconfiguration", RFC 2462, December 1998.
			[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.
			[RFC3484] Draves, R., "Default Address Selection for Internet
			Protocol version 6 (IPv6)", RFC 3484, February 2003.
			[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
			Addresses", RFC 4193, October 2005.
			[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)
			for IPv6", RFC 4429, April 2006.
			10.2. Informative References
			[AURA02] Aura, T., Roe, M., and J. Arkko, "Security of Internet
			Location Management", In Proceedings of the 18th Annual
			Computer Security Applications Conference, Las Vegas,
			Nevada, USA., December 2002.
			[I-D.bagnulo-shim6-addr-selection]
			Bagnulo, M., "Address selection in multihomed
			environments", draft-bagnulo-shim6-addr-selection-00 (work
			in progress), October 2005.
			[I-D.huitema-multi6-addr-selection]
			Huitema, C., "Address selection in multihomed
			environments", draft-huitema-multi6-addr-selection-00
			(work in progress), October 2004.
			[I-D.ietf-dna-cpl]
			Nordmark, E. and J. Choi, "DNA with unmodified routers:
			Prefix list based approach", draft-ietf-dna-cpl-02 (work
			in progress), January 2006.
			[I-D.ietf-dna-protocol]
			Kempf, J., "Detecting Network Attachment in IPv6 Networks
			(DNAv6)", draft-ietf-dna-protocol-01 (work in progress),
			June 2006.
			[I-D.ietf-hip-mm]
			Nikander, P., "End-Host Mobility and Multihoming with the
			Host Identity Protocol", draft-ietf-hip-mm-04 (work in
			progress), June 2006.
			[I-D.ietf-shim6-locator-pair-selection]
			Bagnulo, M., "Default Locator-pair selection algorithm for
			the SHIM6 protocol",
			draft-ietf-shim6-locator-pair-selection-01 (work in
			progress), October 2006.
			[I-D.ietf-shim6-proto]
			Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim
			protocol", draft-ietf-shim6-proto-07 (work in progress),
			December 2006.
			[I-D.ietf-shim6-reach-detect]
			Beijnum, I., "Shim6 Reachability Detection",
			draft-ietf-shim6-reach-detect-01 (work in progress),
			October 2005.
			[I-D.ietf-tcpm-icmp-attacks]
			Gont, F., "ICMP attacks against TCP",
			draft-ietf-tcpm-icmp-attacks-00 (work in progress),
			February 2006.
			[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
			Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
			Zhang, L., and V. Paxson, "Stream Control Transmission
			Protocol", RFC 2960, October 2000.
			[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
			Neighbor Discovery (SEND)", RFC 3971, March 2005.
			Appendix A. Example Protocol Runs
			This appendix has examples of REAP protocol runs in typical
			scenarios. We start with the simplest scenario of two hosts, A and
			B, that have a SHIM6 connection with each other but are not currently
			sending any data. As neither side sends anything, they also do not
			expect anything back, so there are no messages at all:
	EXAMPLE 1: No communications		EXAMPLE 1: No communications
	Peer A Peer B		Peer A Peer B
	| |		| |
	| |		| |
	| |		| |
	| |		| |
	| |		| |
	| |		| |
	skipping to change at page 26, line 9 ¶		skipping to change at page 35, line 9 ¶
	| |		| |
	| (A,B1) payload packet |		| (A,B1) payload packet |
	|----------------------------------------/ |		|----------------------------------------/ |
	| |		| |
	| (B1,A) payload packet |		| (B1,A) payload packet |
	| /-----------------------------------------|		| /-----------------------------------------|
	| |		| |
	| (A,B1) payload packet |		| (A,B1) payload packet |
	|----------------------------------------/ |		|----------------------------------------/ |
	| |		| |
	| |		| | Send Timeout
	| | 10 seconds after		| | seconds after
	| (B1,A) Probe id=p, | T1, sends a com-		| | T1, B happens to
	| state=exploring | plaint that		| | see the problem
			| (B1,A) Probe id=p, | first and sends a
			| state=exploring | complaint that
	| /-----------------------------------------| it is not rec-		| /-----------------------------------------| it is not rec-
	| | eiving anything		| | eiving anything
	| | State:		| | State:
	| | Exploring		| | Exploring
	| |		| |
	| (B2,A) Probe id=q, |		| (B2,A) Probe id=q, |
	| state=exploring | But its lost,		| state=exploring | But its lost,
	|<--------------------------------------------| retransmission		|<--------------------------------------------| retransmission
	| | uses another pair		| | uses another pair
	A realizes |		A realizes |
	that it needs |		that it needs |
	to start the |		to start the |
	exploration. It |		exploration. It |
	picks B2 as the |		picks B2 as the |
	most likely candidate, |		most likely candidate, |
	as it appeared in the |		as it appeared in the |
	Probe |		Probe |
	State: ExploringOk |		State: InboundOk |
	| |		| |
	| (A, B2) Probe id=r, |		| (A, B2) Probe id=r, |
	| state=exploringok, |		| state=inboundok, |
	| received probe q | This one gets		| received probe q | This one gets
	|-------------------------------------------->| through.		|-------------------------------------------->| through.
	| | State:		| | State:
	| | Operational		| | Operational
	| |		| |
	| |		| |
	| (B2,A) Probe id=s, |		| (B2,A) Probe id=s, |
	| state=operational, | B now knows		| state=operational, | B now knows
	| received probe r | that A has no		| received probe r | that A has no
	|<--------------------------------------------| problem to receive		|<--------------------------------------------| problem to receive
	skipping to change at page 27, line 39 ¶		skipping to change at page 36, line 41 ¶
	| |		| |
	| (A1,B1) payload packet |		| (A1,B1) payload packet |
	|----------------------------------------/ |		|----------------------------------------/ |
	| |		| |
	| (B1,A1) payload packet |		| (B1,A1) payload packet |
	|<--------------------------------------------|		|<--------------------------------------------|
	| |		| |
	| (A1,B1) payload packet |		| (A1,B1) payload packet |
	|----------------------------------------/ |		|----------------------------------------/ |
	| |		| |
	| | 10 seconds after		| | Send Timeout
	| (B1,A1) Probe id=p, | T1, B sends a com-		| | seconds after
			| | T1, B notices
			| | the problem and
			| (B1,A1) Probe id=p, | sends a com-
	| state=exploring | plaint that		| state=exploring | plaint that
	|<--------------------------------------------| it is not rec-		|<--------------------------------------------| it is not rec-
	| | eiving anything		| | eiving anything
	A responds | State: Exploring		A responds | State: Exploring
	State: ExploringOk |		State: InboundOk |
	| |		| |
	| (A1, B1) Probe id=q, |		| (A1, B1) Probe id=q, |
	| state=exploringok, |		| state=inboundok, |
	| received payload, |		| received payload, |
	| received probe q |		| received probe q |
	|----------------------------------------/ | But A's response		|----------------------------------------/ | But A's response
	| | is lost		| | is lost
	| (B2,A2) Probe id=r, |		| (B2,A2) Probe id=r, |
	| state=exploring | Next try different		| state=exploring | Next try different
	|<--------------------------------------------| locator pair		|<--------------------------------------------| locator pair
	| |		| |
	| (A2, B2) Probe id=s, |		| (A2, B2) Probe id=s, |
	| state=exploringok, |		| state=inboundok, |
	| received payload, |		| received payload, |
	| received probes p, r | This one gets		| received probes p, r | This one gets
	|-------------------------------------------->| through		|-------------------------------------------->| through
	| | State: Operational		| | State: Operational
	| |		| |
	| | B now knows		| | B now knows
	| | that A has no		| | that A has no
	| (B2,A2) Probe id=t, | problem to receive		| (B2,A2) Probe id=t, | problem to receive
	| state=operational, | its packets, and		| state=operational, | its packets, and
	| received probe s | that A's probe		| received probe s | that A's probe
	|<--------------------------------------------| gets to B. It		|<--------------------------------------------| gets to B. It
	| | sends a		| | sends a
	State: Operational | confirmation to A		State: Operational | confirmation to A
	| |		| |
	| (A2,B2) payload packet |		| (A2,B2) payload packet |
	|-------------------------------------------->| Payload packets		|-------------------------------------------->| Payload packets
	| | flow again		| | flow again
	| (B1,A1) payload packet |		| (B1,A1) payload packet |
	|<--------------------------------------------|		|<--------------------------------------------|
	8. Protocol Constants		Appendix B. Contributors
	The following protocol constants are defined:
	Send Timeout 10 seconds
	Keepalive Interval Not specified here
	Initial Probe Timeout 0.5 seconds
	Number of Initial Probes 4 probes
	Max Probe Timeout 60 seconds
	9. Security Considerations
	Attackers may spoof various indications from lower layers and the
	network in an effort to confuse the peers about which addresses are
	or are not operational. For example, attackers may spoof ICMP error
	messages in an effort to cause the parties to move their traffic
	elsewhere or even to disconnect. Attackers may also spoof
	information related to network attachments, router discovery, and
	address assignments in an effort to make the parties believe they
	have Internet connectivity when in reality they do not.
	This may cause use of non-preferred addresses or even denial-of-
	service.
	This protocol does not provide any protection of its own for
	indications from other parts of the protocol stack. Unprotected
	indications SHOULD NOT be taken as a proof of connectivity problems.
	However, REAP has weak resistance against incorrect information even
	from unprotected indications in the sense that it performs its own
	tests prior to picking a new address pair. Denial-of- service
	vulnerabilities remain, however, as do vulnerabilities against on
	path attackers.
	Some aspects of these vulnerabilities can be mitigated through the
	use of techniques specific to the other parts of the stack, such as
	properly dealing with ICMP errors [I-D.ietf-tcpm-icmp-attacks], link
	layer security, or the use of SEND [RFC3971] to protect IPv6 Router
	and Neighbor Discovery.
	Other parts of the SHIM6 protocol ensure that the set of addresses we
	are switching between actually belong together. REAP itself provides
	no such assurances. Similarly, REAP provides only minimal protection
	against third party flooding attacks; when REAP is run its Probe
	identifiers can be used as a return routability check that the
	claimed address is indeed willing to receive traffic. However, this
	needs to be complemented with another mechanism to ensure that the
	claimed address is also the correct host. SHIM6 does this by
	performing binding of all operations to context tags.
	The keepalive mechanism in this specification is vulnerable to
	spoofing. On path-attackers that can see a SHIM6 context tag can
	send spoofed Keepalive messages once per Send Timeout interval, to
	prevent two SHIM6 nodes from sending Keepalives themselves. This
	vulnerability is only relevant to nodes involved in a one-way
	communication. The result of the attack is that the nodes enter the
	exploration phase needlessly, but they should be able to confirm
	connectivity unless, of course, the attacker is able to prevent the
	exploration phase from completing. Off-path attackers may not be
	able to generate spoofed results, given that the context tags are 47-
	bit random numbers.
	The exploration phase is vulnerable to attackers that are on the
	path. Off-path attackers would find it hard to guess either the
	context tag or the correct probe identifiers. Given that IPsec
	operates above the shim layer, it is not possible to protect the
	exploration phase against on-path attackers. This is similar to the
	ability to protect other Shim6 control exchanges. There are
	mechanisms in place to prevent the redirection of communications to
	wrong addresses, but on-path attackers can cause denial-of-service,
	move communications to less-preferred address pairs, and so on.
	Finally, the exploration itself can cause a number of packets to be
	sent. As a result it may be used as a tool for packet amplification
	in flooding attacks. In order to prevent this it is required that
	the protocol employing REAP has built-in mechanisms to prevent this.
	For instance, in SHIM6 contexts are created only after a relatively
	large number of packets has been exchanged, a cost which reduces the
	attractiveness of using SHIM6 and REAP for amplification attacks.
	However, such protections are typically not present at connection
	establishment time. When exploration would be needed for connection
	establishment to succeed, its usage would result in an amplification
	vulnerability. As a result, SHIM6 does not support the use of REAP
	in connection establishment stage.
	10. IANA Considerations
	No IANA actions are required.
	11. References
	11.1. Normative References
	[RFC1750] Eastlake, D., Crocker, S., and J. Schiller, "Randomness
	Recommendations for Security", RFC 1750, December 1994.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
	Discovery for IP Version 6 (IPv6)", RFC 2461,
	December 1998.
	[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
	Autoconfiguration", RFC 2462, December 1998.
	[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.
	[RFC3484] Draves, R., "Default Address Selection for Internet
	Protocol version 6 (IPv6)", RFC 3484, February 2003.
	[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
	Addresses", RFC 4193, October 2005.
	[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)
	for IPv6", RFC 4429, April 2006.
	11.2. Informative References
	[AURA02] Aura, T., Roe, M., and J. Arkko, "Security of Internet
	Location Management", In Proceedings of the 18th Annual
	Computer Security Applications Conference, Las Vegas,
	Nevada, USA., December 2002.
	[I-D.bagnulo-shim6-addr-selection]
	Bagnulo, M., "Address selection in multihomed
	environments", draft-bagnulo-shim6-addr-selection-00 (work
	in progress), October 2005.
	[I-D.huitema-multi6-addr-selection]
	Huitema, C., "Address selection in multihomed
	environments", draft-huitema-multi6-addr-selection-00
	(work in progress), October 2004.
	[I-D.ietf-dna-cpl]
	Nordmark, E. and J. Choi, "DNA with unmodified routers:
	Prefix list based approach", draft-ietf-dna-cpl-02 (work
	in progress), January 2006.
	[I-D.ietf-dna-protocol]
	Kempf, J., "Detecting Network Attachment in IPv6 Networks
	(DNAv6)", draft-ietf-dna-protocol-01 (work in progress),
	June 2006.
	[I-D.ietf-hip-mm]
	Nikander, P., "End-Host Mobility and Multihoming with the
	Host Identity Protocol", draft-ietf-hip-mm-04 (work in
	progress), June 2006.
	[I-D.ietf-shim6-locator-pair-selection]
	Bagnulo, M., "Default Locator-pair selection algorithm for
	the SHIM6 protocol",
	draft-ietf-shim6-locator-pair-selection-00 (work in
	progress), May 2006.
	[I-D.ietf-shim6-proto]
	Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim
	protocol", draft-ietf-shim6-proto-05 (work in progress),
	May 2006.
	[I-D.ietf-shim6-reach-detect]
	Beijnum, I., "Shim6 Reachability Detection",
	draft-ietf-shim6-reach-detect-01 (work in progress),
	October 2005.
	[I-D.ietf-tcpm-icmp-attacks]
	Gont, F., "ICMP attacks against TCP",
	draft-ietf-tcpm-icmp-attacks-00 (work in progress),
	February 2006.
	[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
	Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
	Zhang, L., and V. Paxson, "Stream Control Transmission
	Protocol", RFC 2960, October 2000.
	[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
	Neighbor Discovery (SEND)", RFC 3971, March 2005.
	Appendix A. Contributors
	This draft attempts to summarize the thoughts and unpublished		This draft attempts to summarize the thoughts and unpublished
	contributions of many people, including the MULTI6 WG design team		contributions of many people, including the MULTI6 WG design team
	members Marcelo Bagnulo Braun, Erik Nordmark, Geoff Huston, Kurtis		members Marcelo Bagnulo Braun, Erik Nordmark, Geoff Huston, Kurtis
	Lindqvist, Margaret Wasserman, and Jukka Ylitalo, the MOBIKE WG		Lindqvist, Margaret Wasserman, and Jukka Ylitalo, the MOBIKE WG
	contributors Pasi Eronen, Tero Kivinen, Francis Dupont, Spencer		contributors Pasi Eronen, Tero Kivinen, Francis Dupont, Spencer
	Dawkins, and James Kempf, and HIP WG contributors such as Pekka		Dawkins, and James Kempf, and HIP WG contributors such as Pekka
	Nikander. This draft is also in debt to work done in the context of		Nikander. This draft is also in debt to work done in the context of
	SCTP [RFC2960] and HIP multihoming and mobility extension		SCTP [RFC2960] and HIP multihoming and mobility extension
	[I-D.ietf-hip-mm].		[I-D.ietf-hip-mm].
	Appendix B. Acknowledgements		Appendix C. Acknowledgements
	The authors would also like to thank Christian Huitema, Pekka Savola,		The authors would also like to thank Christian Huitema, Pekka Savola,
	John Loughney, Sam Xia, and Hannes Tschofenig for interesting		John Loughney, Sam Xia, Hannes Tschofenig, Sebastian Barre, Thomas
	discussions in this problem space, and for review of this		Henderson, and Deguang Le for interesting discussions in this problem
	specification.		space, and for review of this specification.
	Authors' Addresses		Authors' Addresses
	Jari Arkko		Jari Arkko
	Ericsson		Ericsson
	Jorvas 02420		Jorvas 02420
	Finland		Finland
	Email: jari.arkko@ericsson.com		Email: jari.arkko@ericsson.com
	Iljitsch van Beijnum		Iljitsch van Beijnum
	Email: iljitsch@muada.com		Email: iljitsch@muada.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2006).		Copyright (C) The IETF Trust (2006).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Intellectual Property		Intellectual Property
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
End of changes. 90 change blocks.
	383 lines changed or deleted		498 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/