draft-ietf-shim6-failure-detection-03.txt		faildet.txt
	Network Working Group J. Arkko		Network Working Group J. Arkko
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Expires: June 24, 2006 I. Beijnum		Intended status: Informational I. Beijnum
	Muada		Expires: December 28, 2006 Muada
	December 21, 2005		June 26, 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-03		draft-ietf-shim6-failure-detection-05
	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 36		skipping to change at page 1, line 36
	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 June 24, 2006.		This Internet-Draft will expire on December 28, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	This document defines a mechanism for the detection of communication		This document specifies how the level 3 multihoming shim protocol
	failures between two communicating hosts at IP layer, and an		(SHIM6) detects failures between two communicating hosts. It also
	exploration protocol for switching to another pair of interfaces		specifies an exploration protocol for switching to another pair of
	and/or addresses between the same hosts if a working pair can be		interfaces and/or addresses between the same hosts if a failure
	found. The draft also discusses the roles of a multihoming protocol		occurs and an operational pair can be found.
	versus network attachment functions at IP and link layers.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Requirements language . . . . . . . . . . . . . . . . . . . . 4		2. Requirements language . . . . . . . . . . . . . . . . . . . . 4
	3. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7		3.1. Available Addresses . . . . . . . . . . . . . . . . . . 5
	4.1. Available Addresses . . . . . . . . . . . . . . . . . . 7		3.2. Locally Operational Addresses . . . . . . . . . . . . . 6
	4.2. Locally Operational Addresses . . . . . . . . . . . . . 7		3.3. Operational Address Pairs . . . . . . . . . . . . . . . 6
	4.3. Operational Address Pairs . . . . . . . . . . . . . . . 8		3.4. Current Address Pair . . . . . . . . . . . . . . . . . . 8
	4.4. Current Address Pair . . . . . . . . . . . . . . . . . . 9		4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9
	4.5. Miscellaneous . . . . . . . . . . . . . . . . . . . . . 10		4.1. Failure Detection . . . . . . . . . . . . . . . . . . . 9
	5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 11		4.2. Alternative Address Pair Exploration . . . . . . . . . . 11
	5.1. Failure Detection . . . . . . . . . . . . . . . . . . . 11		4.3. Exploration Order . . . . . . . . . . . . . . . . . . . 11
	5.2. Alternative Address Pair Exploration . . . . . . . . . . 13		4.4. Protocol Design . . . . . . . . . . . . . . . . . . . . 12
	5.3. Exploration Order . . . . . . . . . . . . . . . . . . . 14		4.5. Example Protocol Runs . . . . . . . . . . . . . . . . . 13
	5.4. Protocol Design . . . . . . . . . . . . . . . . . . . . 14		4.6. Limitations . . . . . . . . . . . . . . . . . . . . . . 19
	5.5. Example Protocol Runs . . . . . . . . . . . . . . . . . 15		5. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 20
	5.6. Limitations . . . . . . . . . . . . . . . . . . . . . . 21		5.1. Keepalive Message . . . . . . . . . . . . . . . . . . . 20
	6. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 22		5.1.1. Keepalive Option . . . . . . . . . . . . . . . . 21
	6.1. Keepalive Message . . . . . . . . . . . . . . . . . . . 22		5.2. Probe Message . . . . . . . . . . . . . . . . . . . . . 22
	6.1.1. Keepalive Option . . . . . . . . . . . . . . . . 23		5.2.1. Probe Option . . . . . . . . . . . . . . . . . . 24
	6.2. Probe Message . . . . . . . . . . . . . . . . . . . . . 24		5.3. Reachability Option . . . . . . . . . . . . . . . . . . 25
	6.2.1. Probe Option . . . . . . . . . . . . . . . . . . 25		5.3.1. Payload Reception Report . . . . . . . . . . . . 26
	6.3. Reachability Option . . . . . . . . . . . . . . . . . . 26		5.3.2. Probe Reception Report . . . . . . . . . . . . . 26
	6.3.1. Payload Reception Report . . . . . . . . . . . . 27		5.4. Behaviour . . . . . . . . . . . . . . . . . . . . . . . 27
	6.3.2. Probe Reception Report . . . . . . . . . . . . . 28		5.5. Protocol Constants . . . . . . . . . . . . . . . . . . . 31
	6.4. Behaviour . . . . . . . . . . . . . . . . . . . . . . . 29		6. Security Considerations . . . . . . . . . . . . . . . . . . . 32
	6.5. Protocol Constants . . . . . . . . . . . . . . . . . . . 33		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 34		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36		8.1. Normative References . . . . . . . . . . . . . . . . . . 35
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37		8.2. Informative References . . . . . . . . . . . . . . . . . 35
	9.1. Normative References . . . . . . . . . . . . . . . . . . 37		Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 37
	9.2. Informative References . . . . . . . . . . . . . . . . . 37		Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 38
	Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 39		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
	Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 40		Intellectual Property and Copyright Statements . . . . . . . . . . 40
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
	Intellectual Property and Copyright Statements . . . . . . . . . . 42
	1. Introduction		1. Introduction
	The SHIM6 protocol extends IPv6 to support multihoming. This		The SHIM6 protocol [I-D.ietf-shim6-proto] extends IPv6 to support
	protocol is an IP layer mechanism that hides multihoming from		multihoming. It is an IP layer mechanism that hides multihoming from
	applications [18]. A part of the SHIM6 solution involves detecting		applications. A part of the SHIM6 solution involves detecting when a
	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 draft defines the mechanism and protocol to achieve both failure		This document specifies the mechanisms and protocol messages to
	detection and locator pair exploration. This protocol is called		achieve both failure detection and locator pair exploration. This
	REAchability Protocol (REAP). It designed to be carried within the		part of the SHIM6 protocol is called the REAchability Protocol
	SHIM6 protocol, but may also be used in other contexts.		(REAP).
	The draft is structured as follows: Section 3 discusses prior work in		The document is structured as follows: Section 3 defines a set of
	this space, Section 4 defines a set of useful terms, Section 5 gives		useful terms, Section 4 gives an overview of REAP, and Section 5
	an overview of REAP, and Section 6 specifies the message formats and		specifies the message formats and behaviour in detail. Section 6
	behaviour in detail. Section 7 discusses the security considerations		discusses the security considerations of REAP.
	of REAP.
	For the purposes of this draft, we consider an address to be		In this specification, we consider an address to be synonymous with a
	synonymous with a locator. We assume that there are other, higher		locator. Other parts of the SHIM6 protocol ensure that the different
	level identifiers such as CGA public keys or HBA bindings that tie		locators used by a node actually belong together. That is, REAP is
	the different locators used by a node together [17].		not responsible for ensuring that it ends up with a legitimate
			locator.
	2. Requirements language		2. Requirements language
	In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	described in [2].		document are to be interpreted as described in [RFC2119].
	3. Related Work
	In SCTP [10], the addresses of the endpoints are learned in the
	connection setup phase either through listing them explicitly or via
	giving a DNS name that points to them. In order to provide a
	failover mechanism between multihomed hosts, SCTP selects one of the
	peer's addresses as the primary address by the application running on
	top of SCTP. All data packets are sent to this address until there
	is a reason to choose another address, such as the failure of the
	primary address.
	SCTP also tests the reachability of the peer endpoint's addresses.
	This is done both via observing the data packets sent to the peer or
	via a periodic heartbeat when there is no data packets to send. Each
	time data packet retransmission is initiated (or when a heartbeat is
	not answered within the estimated round-trip time) an error counter
	is incremented. When a configured error limit is reached, the
	particular destination address is marked as inactive. The reception
	of an acknowledgement or heartbeat response clears the counter.
	Retransmission: When retransmitting the endpoint attempts pick the
	most "divergent" source-destination pair from the original source-
	destination pair to which the packet was transmitted. Rules for such
	selection are, however, left as implementation decisions in SCTP.
	SCTP does not define how local knowledge (such as information learned
	from the link layer) should be used. SCTP also has no mechanism to
	deal with dynamic changes to the set of available addresses, although
	mechanisms for that are being developed [20].
	The MOBIKE protocol [15] provides multihoming and mobility for VPN
	connections. Its failure detection and locator pair exploration is
	designed to work across mixed IPv4/IPv6 environments and NATs, as
	long as a path that allows bidirectional communication can be found.
	Existing mechanisms at lower layers or in IKEv2 are used to detect
	failures, and upon failure MOBIKE attempts to explore all
	combinations of addresses to find a working pair. Such exploration
	is necessary when a problem affects both nodes. For instance, two
	nodes connected by two separate point-to-point links will be unable
	to switch to the other link if a failure occurs on the first one.
	While both communicating hosts are aware of each others' addresses,
	only one end of the communication is in charge of deciding what
	address pair to use, however.
	The mobility and multihoming specification for the HIP protocol [14]
	leaves the determination of when address updates are sent to a local
	policy, but suggests the use of local information and ICMP error
	messages.
	Network attachment procedures are also relevant for multihoming. The
	IPv6 and MIP6 working groups have standardized mechanisms to learn
	about networks that a node has attached to. Basic IPv6 Neighbor
	Discovery was, however, designed primarily for static situations.
	The fully dynamic detection procedure has turned out to be a
	relatively complex procedure for mobile hosts, and it was not fully
	anticipated at the time IPv6 Neighbor Discovery or DHCP were being
	designed. As a result, enhanced or optimized mechanisms are being
	designed in the DHC and DNA working groups [13] [7].
	ICE [16], STUN [11], and TURN [24] are also related mechanisms. They
	are primarily used for NAT detection and communication through NATs
	in IPv4 environment, for application such as as voice over IP. STUN
	uses a server in the Internet to discover the presence and type of
	NATs and the client's public IP addresses and ports. TURN makes it
	possible to receive incoming connections in hosts behind NATs. ICE
	makes use of these protocols in peer-to-peer cooperative fashion,
	allowing participants to discover, create and verify mutual
	connectivity, and then use this connectivity for multimedia streams.
	While these mechanisms are not designed for dynamic and failure
	situations, they have many of the same requirements for the
	exploration of connectivity, as well as the requirement to deal with
	middleboxes.
	Related work in the IPv6 area includes RFC 3484 [6] which defines
	source and destination address selection rules for IPv6 in situations
	where multiple candidate address pairs exist. RFC 3484 considers
	only a static situation, however, and does not take into account the
	effect of failures. Reference [23] considers how applications can
	re-initiate connections after failures in the best way. This work
	differs from the shim-layer approach selected for further development
	in the working group with respect to the timing of the address
	selection. In the shim-layer approach failure detection and the
	selection of new addresses happens at any time, while [23] considers
	only the case when an application re-establishes connections.
	An earlier SHIM6 document [19] discussed what kind of mechanisms can
	be used to detect whether the peer is still reachable at the
	currently used address. Two proposed mechanisms, Correspondent
	Unreachability Detection (CUD) and Forced Bidirectional Communication
	(FBD) were presented. CUD is based on getting upper layer positive
	feedback, and IPv6 NUD-like probing if there is no feedback. FBD is
	based on forcing bidirectional communication by adding keepalive
	messages when there is no other, payload traffic. FBD is the chosen
	mechanism in this document.
	4. Definitions		3. Definitions
	This section defines terms useful in discussing the problem space.		This section defines terms useful for discussing failure detection
			and locator pair exploration.
	4.1. Available Addresses		3.1. Available Addresses
	Multihoming nodes need to be aware of what addresses they themselves		SHIM6 nodes need to be aware of what addresses they themselves have.
	have. If a node loses the address it is currently using for		If a node loses the address it is currently using for communications,
	communications, another address must replace this address. And if a		another address must replace this address. And if a node loses an
	node loses an address that the node's peer knows about, the peer must		address that the node's peer knows about, the peer must be informed.
	be informed. Similarly, when a node acquires a new address it may		Similarly, when a node acquires a new address it may generally wish
	generally wish the peer to know about it.		the peer to know about it.
	Definition. Available address. An address is said to be available		Definition. Available address. An address is said to be available
	if the following conditions are fulfilled:		if the following conditions are fulfilled:
	o The address has been assigned to an interface of the node.		o The address has been assigned to an interface of the node.
	o If the address is an IPv6 address, we additionally require that		o The address is valid in the sense of RFC 2461 [RFC2461].
	(a) the address is valid in the sense of RFC 2461 [3], and that
	(b) the address is not tentative in the sense of RFC 2462 [4]. In		o The address is not tentative in the sense of RFC 2462 [RFC2462].
	other words, the address assignment is complete so that		In other words, the address assignment is complete so that
	communications can be started.		communications can be started.
	Note that this explicitly allows an address to be optimistic in		Note that this explicitly allows an address to be optimistic in
	the sense of [8] even though implementations are probably better		the sense of Optimistic DAD [RFC4429] even though implementations
	off using other addresses as long as there is an alternative.		may prefer using other addresses as long as there is an
			alternative.
	o The address is a global unicast, unique local address [9], or an		o The address is a global unicast, unique local address [RFC4193],
	unambiguous IPv6 link-local address. That is, it is not an IPv6		or an unambiguous IPv6 link-local address. That is, it is not an
	site-local address. Where IPv6 link-local addresses are used,		IPv6 site-local address.
	their use needs to be unambiguous as follows. At most one link-
	local address may be used per node within the same connection		Where IPv6 link-local addresses are used, their use needs to be
	between two peers.		unambiguous as follows. At most one link-local address may be
			used per node within the same connection between two peers.
	o The address and interface is acceptable for use according to a		o The address and interface is acceptable for use according to a
	local policy.		local policy.
	Available addresses are discovered and monitored through mechanisms		Available addresses are discovered and monitored through mechanisms
	outside the scope of the protocol described here. These mechanisms		outside the scope of SHIM6. SHIM6 implementations MUST be able to
	include IPv6 Neighbor Discovery and Address Autoconfiguration [3]		employ information provided by IPv6 Neighbor Discovery [RFC2461],
	[4], DHCP [5], and DNA mechanisms [7].		Address Autoconfiguration [RFC2462], and DHCP [RFC3315]. This
			information includes the availability of a new address and status
			changes of existing addresses (such as when an address becomes
			invalid).
	4.2. Locally Operational Addresses		3.2. Locally Operational Addresses
	Two different granularity levels are needed for failure detection.		Two different granularity levels are needed for failure detection.
	The coarser granularity is for individual addresses:		The coarser granularity is for individual addresses:
	Definition. Locally Operational Address. An available address is		Definition. Locally Operational Address. An available address is
	said to be locally operational when its use is known to be possible		said to be locally operational when its use is known to be possible
	locally: the interface is up, at least one default router (if		locally: the interface is up, a default router (if needed) suitable
	applicable) that could be used to send a packet with this address as		for this address is known to be reachable, and no other local
	a source address is known to be reachable, and no other local
	information points to the address being unusable.		information points to the address being unusable.
	Locally operational addresses are discovered and monitored through		Locally operational addresses are discovered and monitored through
	mechanisms outside the protocol described here. These mechanisms		mechanisms outside the SHIM6 protocol. SHIM6 implementations MUST be
	include IPv6 Neighbor Discovery [3] and link layer specific		able to employ information provided from Neighbor Unreachability
	mechanisms.		Detection [RFC2461]. Implementations MAY also employ additional,
			link layer specific mechanisms.
	It is also possible for hosts to learn about routing failures for a		Note 1: A part of the problem in ensuring that an address is
	particular selected source prefix, if suitable protocols for this		operational is making sure that after a change in link layer
	purpose exist. Some proposals in this space have been made, see, for		connectivity we are still connected to the same IP subnet.
	instance [21] and [23]. Potential approaches include overloading		Mechanisms such as DNA CPL [I-D.ietf-dna-cpl] or DNAv6
	information in current IPv6 Router Advertisement or adding some new		[I-D.ietf-dna-protocol] can be used to ensure this.
	information in them. Similarly, hosts could learn information from
	servers that query the BGP routing tables.
	4.3. Operational Address Pairs		Note 2: In theory, it would also be possible for hosts to learn
			about routing failures for a particular selected source prefix, if
			only suitable protocols for this purpose existed. Some proposals
			in this space have been made, see, for instance
			[I-D.bagnulo-shim6-addr-selection] and
			[I-D.huitema-multi6-addr-selection], but none have been
			standardized to date.
			3.3. Operational Address Pairs
	The existence of locally operational addresses are not, however, a		The existence of locally operational addresses are not, however, a
	guarantee that communications can be established with the peer. A		guarantee that communications can be established with the peer. A
	failure in the routing infrastructure can prevent the sent packets		failure in the routing infrastructure can prevent packets from
	from reaching their destination. For this reason we need the		reaching their destination. For this reason we need the definition
	definition of a second level of granularity, for pairs of addresses:		of a second level of granularity, for pairs of addresses:
	Definition. Bidirectionally operational address pair. A pair of		Definition. Bidirectionally operational address pair. A pair of
	locally operational addresses are said to be an operational address		locally operational addresses are said to be an operational address
	pair, iff bidirectional connectivity can be shown between the		pair, iff bidirectional connectivity can be shown between the
	addresses. That is, a packet sent with one of the addresses in the		addresses. That is, a packet sent with one of the addresses in the
	source field and the other in the destination field reaches the		source field and the other in the destination field reaches the
	destination, and vice versa.		destination, and vice versa.
	Unfortunately, there are scenarios where bidirectionally operational		Unfortunately, there are scenarios where bidirectionally operational
	address pairs do not exist. For instance, ingress filtering or		address pairs do not exist. For instance, ingress filtering or
	network failures may result in one address pair being operational in		network failures may result in one address pair being operational in
	one direction while another one is operational from the other		one direction while another one is operational from the other
	direction. The following definition captures this general situation:		direction. The following definition captures this general situation:
	Definition. Undirectionally operational address pair. A pair of		Definition. Unidirectionally operational address pair. A pair of
	locally operational addresses are said to be an unidirectionally		locally operational addresses are said to be an unidirectionally
	operational address pair, iff packets sent with the first address as		operational address pair, iff packets sent with the first address as
	the source and the second address as the destination can be shown to		the source and the second address as the destination can be shown to
	reach the destination.		reach the destination.
	Both types of operational pairs could be discovered and monitored		SHIM6 implementations MUST support the discovery of operational
	through the following mechanisms:		address pairs through the use of explicit rechability tests and
			Forced Bidirectional Communication (FBD), described later in this
			specification. In addition, implementations MAY employ the following
			additional mechanisms:
	o Positive feedback from upper layer protocols. For instance, TCP		o Positive feedback from upper layer protocols. For instance, TCP
	can indicate to the IP layer that it is making progress. This is		can indicate to the IP layer that it is making progress. This is
	similar to how IPv6 Neighbor Unreachability Detection can in some		similar to how IPv6 Neighbor Unreachability Detection can in some
	cases be avoided when upper layers provide information about		cases be avoided when upper layers provide information about
	bidirectional connectivity [3]. In the case of unidirectional		bidirectional connectivity [RFC2461].
	connectivity, the upper layer protocol responses come back using
	another address pair, but show that the messages sent using the		In the case of unidirectional connectivity, the upper layer
	first address pair have been received.		protocol responses come back using another address pair, but show
			that the messages sent using the first address pair have been
			received.
	o Negative feedback from upper layer protocols. It is conceivable		o Negative feedback from upper layer protocols. It is conceivable
	that upper layer protocols give an indication of a problem to the		that upper layer protocols give an indication of a problem to the
	multihoming layer. For instance, TCP could indicate that there's		multihoming layer. For instance, TCP could indicate that there's
	either congestion or lack of connectivity in the path because it		either congestion or lack of connectivity in the path because it
	is not getting ACKs.		is not getting ACKs.
	o Explicit reachability tests, such as keepalives or probes added
	when there's only unidirectional payload traffic.
	o ICMP error messages. Given the ease of spoofing ICMP messages,		o ICMP error messages. Given the ease of spoofing ICMP messages,
	one should be careful to not trust these blindly, however. Our		one should be careful to not trust these blindly, however. Our
	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, but not as a reason to disrupt		an explicit reachability test, but not as a reason to disrupt
	ongoing communications without other indications of problems. The		ongoing communications without other indications of problems. The
	situation may be different when certain verifications of the ICMP		situation may be different when certain verifications of the ICMP
	messages are being performed [22]. These verifications can ensure		messages are being performed, as explained by Gont in
	that (practically) only on-path attackers can spoof the messages.		[I-D.ietf-tcpm-icmp-attacks]. These verifications can ensure that
			(practically) only on-path attackers can spoof the messages.
	Note a multihoming protocol needs to perform a return routability		Note SHIM6 needs to perform a return routability test of an address
	test of an address before it is taken into use. The purpose of this		before it is taken into use. The purpose of this test is to ensure
	test is to ensure that fraudulent peers do not trick others into		that fraudulent peers do not trick others into redirecting traffic
	redirecting traffic streams onto innocent victims [25]. This test		streams onto innocent victims. For a discussion of such attacks, see
	can at the same time work as a means to ensure that an address pair		Aura et al [AURA02]. The test can at the same time work as a means
	is operational, as discussed in Section 5.2.		to ensure that an address pair is operational, as discussed in
			Section 4.2.
	4.4. Current Address Pair		3.4. Current Address Pair
	IP-layer solutions need to avoid sending packets concurrently over		SHIM6 needs to avoid sending packets concurrently over multiple
	multiple paths; TCP behaves rather poorly in such circumstances. For		paths, because congestion control in commonly used transport
	this reason it is necessary to choose a particular pair of addresses		protocols is based upon a notion of a single path. While routing can
	as the current address pair which is used until problems occur, at		introduce path changes as well and transport protocols have means to
	least for the same session.		deal with this, frequent changes will cause problems. Efficient
			congestion control over multible paths is a considered research at
			the time this specification is written.
			For these reasons it is necessary to choose a particular pair of
			addresses as the current address pair which is used until problems
			occur, at least for the same session.
	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 work for new		address pair that worked in some time ago continues to be operational
	communications as well.		for new communications as well.
	4.5. Miscellaneous
	Addresses can become deprecated [3]. When other operational
	addresses exist, nodes generally wish to move their communications
	away from the deprecated addresses.
	Similarly, IPv6 source address selection [6] may guide the selection
	of a particular source address - destination address pair.
	5. 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		address pair exploration mechanisms, and gives on overview of the
	REAP protocol.		REAP protocol.
	A naive implementation of an (un)reachability detection mechanism
	could just probe all possible paths between two hosts periodically.
	A "path" is defined as a combination of a source address for host A
	and a destination address for host B. In hop-by-hop forwarding the
	source address has no effect on reachability, but in the presence of
	filters or source address based routing, it may. And although links
	almost always work in two directions, routing protocols and filters
	only work in one direction so unidirectional reachability is
	possible. Without additional mechanisms, the practice of ingress
	filtering by ISPs makes unidirectional connectivity likely. Being
	able to use the working leg in a unidirectional path is useful, it's
	not an essential requirement. It is essential, however, to avoid
	assuming bidirectional connectivity when there is in fact a
	unidirectional failure.
	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.)
	An important observation in multihoming is that failures are		An important observation in multihoming is that failures are
	relatively infrequent, so that a path that worked a few seconds ago		relatively infrequent, so that an operational pair that worked a few
	is very likely to work now as well. So it makes sense to have a		seconds ago is very likely to be still operational. So it makes
	light-weight protocol that confirms existing reachability, and only		sense to have a light-weight protocol that confirms existing
	invoke heavier exploration when a there is a suspected failure.		reachability, and only invoke heavier exploration when a there is a
			suspected failure.
	5.1. Failure Detection
	This process consists of three tasks. First, it is necessary to
	track local information from lower and upper layers. For instance,
	when link layer informs that we have no connection then we know there
	is a failure. Nodes SHOULD employ techniques listed in Section 4.1
	and Section 4.2 to be aware of the local situation.
	Similarly, it is necessary to track remote address information from		4.1. Failure Detection
	the peer. For instance, the peer may inform that its currently used
	address is no longer in use. Techniques outside the scope of this
	document are used for this, for further information see [18].
	The third task is to ensure verify reachability with the peer when		Failure detection consists of three parts: tracking local
	the local and remote information indicates that communication should		information, tracking remote peer status, and finally verifying
	be possible. This needs to be performed only if there's upper layer		reachability. Tracking local information consists of using, for
	packets to be sent, however.		instance, reachability information about the local router as an
			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
			track remote address information from the peer. For instance, if the
			peer's currently used address is no longer in use, mechanism to relay
			that information is needed. The Update message in the SHIM6 protocol
			is used for this purpose [I-D.ietf-shim6-proto]. Finally, when the
			local and remote information indicates that communication should be
			possible and there are upper layer packets to be sent, reachability
			verification is necessary to ensure that the peers actually have an
			operational pair.
	This document defines the protocol mechanisms only for the third		A technique called Forced Bidirectional Detection (FBD, originally
	task. We employ a technique called Forced Bidirectional Detection		defined in an earlier SHIM6 document [I-D.ietf-shim6-reach-detect])
	(FBD). Reachability for the currently used address pair in a shim		is employed for the reachability verification. Reachability for the
	context is determined by making sure that whenever there is data		currently used address pair in a shim context is determined by making
	traffic in one direction, there is also traffic in the other		sure that whenever there is data traffic in one direction, there is
	direction. This can be data traffic as well, but also transport		also traffic in the other direction. This can be data traffic as
	layer acknowledgments or a REAP reachability keepalive if there is no		well, but also transport layer acknowledgments or a REAP reachability
	other traffic. This way, it is no longer possible to have traffic in		keepalive if there is no other traffic. This way, it is no longer
	only one direction, so whenever there is data traffic going out, but		possible to have traffic in only one direction, so whenever there is
	there are no return packets, there must be a failure, so the full		data traffic going out, but there are no return packets, there must
	path exploration mechanism is started.		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. The base timing unit for this mechanism is named Keepalive		1. The base timing unit for this mechanism is named Keepalive
	Timeout. Until a negotiation mechanism to negotiate different		Timeout. Until a negotiation mechanism to negotiate different
	values for this timer becomes available, the value (3 seconds)		values for this timer becomes available, the value (3 seconds)
	specified in Section 6.5 SHOULD be used.		specified in Section 5.5 SHOULD be used.
	2. Whenever outgoing data packets are generated that are part of a		2. Whenever outgoing data packets are generated, a timer is started
	shim context, a timer is started to reflect the requirement that		to reflect the requirement that the peer should generate return
	the peer should generate return traffic from data packets.		traffic from data packets.
	3. Whenever incoming data packets are received that are part of a		For the purposes of this specification, "data packet" refers to
	shim context, the timer associated with the return traffic from		any packet that is part of a shim context, including both upper
	the peer is stopped, and another timer is started to reflect the		layer protocol packets and SHIM6 protocol messages except those
	requirement for this node to generate return traffic.		defined in this specification.
			3. Whenever incoming data packets are received, the timer associated
			with the return traffic from the peer is stopped, and another
			timer is started to reflect the requirement for this node to
			generate return traffic.
	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 Timeout seconds after the last data packet has been		5. Keepalive Timeout 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 Timeout seconds if implementation		keepalive sooner than Keepalive Timeout seconds if implementation
	considerations warrant this. The average time after which		considerations warrant this. The average time after which
	keepalives are sent MUST be at least Keepalive Timeout / 2		keepalives are sent MUST be at least Keepalive Timeout / 2
	seconds. After sending a single keepalive message, no additional		seconds. After sending a single keepalive message, no additional
	keepalive messages are sent until a data packet is received		keepalive messages are sent until a data packet is received
	within this shim context. Keepalives are not sent at all when a		within this shim context. Keepalives are not sent at all when a
	data packet was sent since the last received data packet.		data packet was sent since the last received data packet.
	6. Send Timeout seconds (10 s; see Section 6.5) after the		6. Send Timeout seconds (10 s; see Section 5.5) after the
	transmission of a data packet with no return traffic on this		transmission of a data packet with no return traffic on this
	context, a full reachability exploration is started. This		context, a full reachability exploration is started. This
	timeout period is larger than the Keepalive Timeout to		timeout period is larger than the Keepalive Timeout to
	accommodate for lost keepalives and regular variations in round		accommodate for lost keepalives and regular variations in round
	trip times.		trip times.
	5.2. Alternative Address Pair Exploration		4.2. Alternative Address Pair 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 13, line 42		skipping to change at page 11, line 34
	signaling messages.		signaling messages.
	Specifically, when A decides that it needs to explore for an		Specifically, when A decides that it needs to explore for an
	alternative address pair to B, it will initiate a set of Probe		alternative address pair to B, it will initiate a set of Probe
	messages, in sequence, until it gets an Probe message from B		messages, in sequence, until it gets an Probe message from B
	indicating that (a) B has received one of A's messages and,		indicating that (a) B has received one of A's messages and,
	obviously, (b) that B's Probe message gets back to A. B uses the same		obviously, (b) that B's Probe message gets back to A. B uses the same
	algorithm, but starts the process from the reception of the first		algorithm, but starts the process from the reception of the first
	Probe message from A.		Probe message from A.
	Upon changing to a new address pair, transport layer protocol needs		Upon changing to a new address pair, the network path traversed most
	to be informed so that it can perform a slow start, or some other		likely has changed, so that the ULP SHOULD be informed. This can be
	form of adaptation to the possibly changed conditions. However, this		a signal for the ULP to adapt due to the change in path so that, for
	functionality is outside the scope of REAP and is rather seen as a		example, TCP could initiate a slow start procedure.
	general multihoming issue.
	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 API to be developed, however. In		desirable. This would require an API to be developed, however. In
	any case, this is another issue that we treat as being outside the		any case, this is another issue that we treat as being outside the
	scope of pure address exploration.		scope of pure address exploration.
	5.3. Exploration Order		4.3. Exploration Order
	The exploration process assumes an ability to pick current and		The exploration process assumes an ability to choose address pairs
	alternative address pairs. 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,
	but a back-off procedure is employed to avoid a "signaling storm".		but a back-off procedure is employed to avoid a "signaling storm".
	Nodes MUST first consult RFC 3484 [6] Section 4 rules to determine		Nodes first consult the RFC 3484 default address selection rules
	what combinations of addresses are allowed from a local point of		[RFC3484] Section 4 rules to determine what combinations of addresses
	view, as this reduces the search space. RFC 3484 also provides a		are allowed from a local point of view, as this reduces the search
	priority ordering among different address pairs, making the search		space. RFC 3484 also provides a priority ordering among different
	possibly faster. Nodes MAY also use local information, such as known		address pairs, making the search possibly faster. Nodes may also use
	quality of service parameters or interface types to determine what		local information, such as known quality of service parameters or
	addresses are preferred over others, and try pairs containing such		interface types to determine what addresses are preferred over
	addresses first. The multihoming protocol also carries preference		others, and try pairs containing such addresses first. The SHIM6
	information in its messages [18].		protocol also carries preference information in its messages.
	Discussion note: The preferences may either be learned dynamically		Discussion note: The preferences may either be learned dynamically
	or be configured. It is believed, however, that dynamic learning		or be configured. It is believed, however, that dynamic learning
	based purely on the multihoming protocol is too hard and not the		based purely on the multihoming protocol is too hard and not the
	task this layer should do. Solutions where multiple protocols		task this layer should do. Solutions where multiple protocols
	share their information in a common pool of locators could provide		share their information in a common pool of locators could provide
	this information from transport protocols, however.		this information from transport protocols, however.
	One suggested good implementation strategy is to record the
	reachability test result (an on/off value) and multiply this by the
	age of the information. This allows recently tested address pairs to
	be chosen before old ones.
	Out of the set of possible candidate address pairs, nodes SHOULD		Out of the set of possible candidate address pairs, nodes SHOULD
	attempt a test through all of them until a working pair is found, and		attempt to test through all of them until an operational pair is
	retrying the process as is necessary. However, all nodes MUST		found, and retrying the process as is necessary. However, all nodes
	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.
	5.4. Protocol Design		Section 5.5 suggests default values for the timers associated with
			the exploration process. The value Initial Probe Timeout (0.5 s)
			specifies the interval between initial attempts to send probes;
			Number of Initial Probes (4) specifies how many initial probes can be
			sent before the exponential backoff procedure needs to be employed.
			This process duplicates the time between every probe if there is no
			response. Finally, Max probe Timeout (60 s) specifies a limit beyond
			which the probe interval may not grow. If the exploration process
			reaches this interval, it will continue sending at this rate until a
			suitable response is triggered or the SHIM6 context is garbage
			collected.
			4.4. Protocol Design
	REAP is designed as a modular part of SHIM6 in the hopes that it may		REAP is designed as a modular part of SHIM6 in the hopes that it may
	also be useful in other contexts. This document defines how it is		also be useful in other contexts. This document defines how it is
	carried within SHIM6, but the actual protocol messages are self-		carried within SHIM6, but the actual protocol messages are self-
	contained so that it could be carried by other protocols as well.		contained so that it could be carried by other protocols as well.
	The REAP design allows performing both failure detection and address		The REAP design allows performing both failure detection and address
	pair exploration in the same sequence of messages, without a need to		pair exploration in the same sequence of messages, without a need to
	designate a specific point when the current address pair is declared		designate a specific point when the current address pair is declared
	inoperational and the search for a new pair begins. This is useful,		inoperational and the search for a new pair begins. This is useful,
	as the loss of a small number of packets is not a proof that a		as the loss of a small number of packets is not a proof that a
	problem exists. Integrated failure detection and exploration allows		problem exists. Integrated failure detection and exploration allows
	us to test multiple address pairs simultaneously, including the		us to test multiple address pairs simultaneously, including the
	current pair in case it starts working again. For instance, the		current pair in case it becomes operational again. For instance, the
	exploration process can refer to keepalive message that succeeded in		exploration process can refer to keepalive message that succeeded in
	getting to the peer during the reachability testing phase.		getting to the peer during the reachability testing phase.
	REAP also integrates a return routability function, making it		REAP also integrates a return routability function, making it
	unnecessary to perform another roundtrip before a newly discovered		unnecessary to perform another roundtrip before a newly discovered
	address can be taken into use.		address can be taken into use.
	This document defines a minimal set of parameters that are carried by		This document defines a minimal set of parameters that are carried by
	the messages of the protocol. Specifically, we have limited the		the messages of the protocol. Specifically, we have limited the
	parameters to those that are necessary to find a working path. We		parameters to those that are necessary to find an operational address
	note there may be extensions that are needed in the future for		pair. We note there may be extensions that are needed in the future
	various reasons, such as the desire to support load balancing or		for various reasons, such as the desire to support load balancing or
	finding best paths. An option format has been specified to allow		finding best pairs. An option format has been specified to allow
	this.		this.
	5.5. Example Protocol Runs		4.5. Example Protocol Runs
	This section has examples of REAP protocol runs in typical scenarios.		This section has examples of REAP protocol runs in typical scenarios.
	We start with the simplest scenario of two hosts, A and B, that have		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		a SHIM6 connection with each other but are not currently sending any
	data. As neither side sends anything, they also do not expect		data. As neither side sends anything, they also do not expect
	anything back, so there are no messages at all:		anything back, so there are no messages at all:
			EXAMPLE 1: No communications
	Peer A Peer B		Peer A Peer B
	| |		| |
	| |		| |
	| |		| |
	| |		| |
	| |		| |
	| |		| |
	| |		| |
	| |		| |
	Our second example involves an active connection with bidirectional		Our second example involves an active connection with bidirectional
	payload packet flows. Here the reception of data from the peer is		payload packet flows. Here the reception of data from the peer is
	taken as an indication of reachability, so again there are no extra		taken as an indication of reachability, so again there are no extra
	packes:		packes:
			EXAMPLE 2: Bidirectional communications
	Peer A Peer B		Peer A Peer B
	| |		| |
	| payload packet |		| payload packet |
	|-------------------------------------------->|		|-------------------------------------------->|
	| |		| |
	| payload packet |		| payload packet |
	|<--------------------------------------------|		|<--------------------------------------------|
	| |		| |
	| payload packet |		| payload packet |
	|-------------------------------------------->|		|-------------------------------------------->|
	| |		| |
	| |		| |
	The third example is the first one that involves an actual REAP		The third example is the first one that involves an actual REAP
	message. Here the hosts communicate in just one direction, so REAP		message. Here the hosts communicate in just one direction, so REAP
	messages are needed to indicate to the peer that sends payload		messages are needed to indicate to the peer that sends payload
	packets that its packets are getting through:		packets that its packets are getting through:
			EXAMPLE 3: Unidirectional communications
	Peer A Peer B		Peer A Peer B
	| |		| |
	| payload packet |		| payload packet |
	|-------------------------------------------->|		|-------------------------------------------->|
	| |		| |
	| payload packet |		| payload packet |
	|-------------------------------------------->|		|-------------------------------------------->|
	| |		| |
	| payload packet |		| payload packet |
	|-------------------------------------------->|		|-------------------------------------------->|
	| |		| |
	| Keepalive id=p |		| Keepalive id=p |
	|<--------------------------------------------|		|<--------------------------------------------|
	| |		| |
	| payload packet |		| payload packet |
	|-------------------------------------------->|		|-------------------------------------------->|
	| |		| |
	| |		| |
	Finally, our last example involves a failure scenario. Here A has		The next example involves a failure scenario. Here A has addresses
	addresses A1 and A2 and B has addresses B1 and B2. The currently		A1 and A2 and B has addresses B1 and B2. The currently used address
	used address pairs are (A1, B1) and (B1, A1). The first of these		pairs are (A1, B1) and (B1, A1). The first of these becomes broken,
	becomes broken, which leads to an exploration process:		which leads to an exploration process:
			EXAMPLE 4: Failure scenario
	Peer A Peer B		Peer A Peer B
	| |		| |
	| (A1,B1) payload packet |		| (A1,B1) payload packet |
	|-------------------------------------------->|		|-------------------------------------------->|
	| |		| |
	| (B1,A1) payload packet |		| (B1,A1) payload packet |
	|<--------------------------------------------| Time T1		|<--------------------------------------------| Time T1
	| | Path A1->B1		| | Path A1->B1
	| (A1,B1) payload packet | is now		| (A1,B1) payload packet | is now
	|----------------------------------------/ | broken		|----------------------------------------/ | broken
	skipping to change at page 17, line 46		skipping to change at page 16, line 4
	|-------------------------------------/ | due to broken path		|-------------------------------------/ | due to broken path
	| |		| |
	Retransmission |		Retransmission |
	to a different |		to a different |
	address |		address |
	| |		| |
	| (A1, B2) Probe id=r, |		| (A1, B2) Probe id=r, |
	| iseeyou=yes |		| iseeyou=yes |
	| payload reception rep |		| payload reception rep |
	| probe reception rep(p) | This one gets		| probe reception rep(p) | This one gets
	|-------------------------------------------->| through		|-------------------------------------------->| through. Note
			| | that B would also
			| | have retransmitted
			| | soon, but in this
			| | example A got
			| | through first
	| |		| |
	| |		| |
	| | B now knows		| | B now knows
	| | that A has no		| | that A has no
	| (B1,A1) Probe id=p, | problem to receive		| (B1,A1) Probe id=p, | problem to receive
	| iseeyou=yes, | its packets and		| iseeyou=yes, | its packets and
	| probe reception rep(r) | This one gets		| probe reception rep(r) | This one gets
	|<--------------------------------------------| that A has found		|<--------------------------------------------| that A has found
	| | a new path to B		| | a new path to B
	| |		| |
	| (A1,B2) payload packet |		| (A1,B2) payload packet |
	|-------------------------------------------->| Payload packets		|-------------------------------------------->| Payload packets
	| | flow again		| | flow again
	| (B1,A1) payload packet |		| (B1,A1) payload packet |
	|<--------------------------------------------|		|<--------------------------------------------|
	The next example shows when the failure for the current locator pair		The next example shows when the failure for the current locator pair
	is in the other direction:		is in the other direction:
			EXAMPLE 5: One-way failure
	Peer A Peer B		Peer A Peer B
	| |		| |
	| (A1,B1) payload packet |		| (A1,B1) payload packet |
	|-------------------------------------------->|		|-------------------------------------------->|
	| |		| |
	| (B1,A1) payload packet |		| (B1,A1) payload packet |
	| /-----------------------------------------| Time T1		| /-----------------------------------------| Time T1
	| | Path B1->A1		| | Path B1->A1
	| | is now		| | is now
	| | broken		| | broken
	skipping to change at page 19, line 51		skipping to change at page 18, line 4
	| iseeyou=yes, | its packets and		| iseeyou=yes, | its packets and
	| probe reception rep(r) | This one gets		| probe reception rep(r) | This one gets
	|<--------------------------------------------| that A has found		|<--------------------------------------------| that A has found
	| | a new path to B		| | a new path to B
	| |		| |
	| (A2,B2) payload packet |		| (A2,B2) payload packet |
	|-------------------------------------------->| Payload packets		|-------------------------------------------->| Payload packets
	| | flow again		| | flow again
	| (B2,A2) payload packet |		| (B2,A2) payload packet |
	|<--------------------------------------------|		|<--------------------------------------------|
	In the next case we have even less luck. The response to the REAP		In the next case we have even less luck. The response to the REAP
	probe doesn't make it in the reverse direction, so both ends end up		probe doesn't make it in the reverse direction, so both ends end up
	exploring indepedently:		exploring independently:
			EXAMPLE 6: Independent exploration
	Peer A Peer B		Peer A Peer B
	| |		| |
	| (A1,B1) payload packet |		| (A1,B1) payload packet |
	|-------------------------------------------->|		|-------------------------------------------->|
	| |		| |
	| (B1,A1) payload packet |		| (B1,A1) payload packet |
	| /-----------------------------------------| Time T1		| /-----------------------------------------| Time T1
	| | Path B1->A1		| | Path B1->A1
	| | is now		| | is now
	skipping to change at page 21, line 15		skipping to change at page 19, line 18
	| probe reception rep(r) | This one gets		| probe reception rep(r) | This one gets
	|<--------------------------------------------| that A has found		|<--------------------------------------------| that A has found
	| | a new path to B		| | a new path to B
	| |		| |
	| (A1,B1) payload packet |		| (A1,B1) payload packet |
	|-------------------------------------------->| Payload packets		|-------------------------------------------->| Payload packets
	| | flow again		| | flow again
	| (B2,A2) payload packet |		| (B2,A2) payload packet |
	|<--------------------------------------------|		|<--------------------------------------------|
	5.6. Limitations		4.6. Limitations
	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 7, the exploration process		to security concerns discussed in Section 6, 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.
	6. Protocol Definition		5. Protocol Definition
	6.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 | Reserved |0|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Checksum |R| |		| Checksum |R| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	skipping to change at page 22, line 29		skipping to change at page 20, line 29
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ Options +		+ Options +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Next Header		Next Header
	This value MUST be set to NO_NXT_HDR (59).		This value MUST be set to NO_NXT_HDR (59).
			Hdr Ext Len
			This is an 8-bit unsigned integer field, calculated as specified
			in Section 5.3 of the SHIM6 protocol 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		Reserved
	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.
			Checksum
			This is a 16-bit field, calculated as specified in Section 5.3 of
			the SHIM6 protocol description [I-D.ietf-shim6-proto].
	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.
	Options		Options
	This MUST contain at least the Keepalive option and MAY contain		This MUST contain at least the Keepalive option and MAY contain
	one or more Reachability options.The inclusion of the latter		one or more Reachability options.The inclusion of the latter
	options is not necessary, however, as there are currenly no		options is not necessary, however, as there are currently no
	defined options that are useful in a Keepalive message. These		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 [18], and its shim		control message as defined in Section 12.2 of the SHIM6 protocol
	context state is ESTABLISHED. The receiver processes a valid message		description [I-D.ietf-shim6-proto], and its shim context state is
	by inspecting its options, and executing any actions specified for		ESTABLISHED. The receiver processes a valid message by inspecting
	such options.		its options, and executing any actions specified for such options.
	The processing rules for this message are the given in more detail in		The processing rules for this message are the given in more detail in
	Section 6.4.		Section 5.4.
	6.1.1. Keepalive Option		5.1.1. Keepalive Option
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type = 10 |0| Length |		| Type = 10 |0| Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Res | Identifier |		| Res | Identifier |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type		Type
	This value MUST be set to 10 (Keepalive Option).		This value MUST be set to 10 (Keepalive Option).
	0		0
	This value MUST be set to 0, as in other SHIM6 options.		This value MUST be set to 0, as in other SHIM6 options.
	Length		Length
	This is the length of the option and MUST be calculated as		This is the length of the option and MUST be calculated as
	specified in Section 5.14 of [18].		specified in Section 5.14 of the SHIM6 protocol description
			[I-D.ietf-shim6-proto].
	Res		Res
	This 4-bit reserved field MUST be set to zero when sending, and		This 4-bit reserved field MUST be set to zero when sending, and
	ignored on receipt.		ignored on receipt.
	Identifier		Identifier
	This 28-bit field identifies this particular instance of an		This 28-bit field identifies this particular instance of an
	Keepalive message. This value SHOULD be generated using a random		Keepalive message. This value SHOULD be generated using a random
	number generator that is known to have good randomness properties		number generator that is known to have good randomness properties
	[1]. Upon reception, Identifier values from both Keepalive and		as outlined in RFC 1750 [RFC1750]. Upon reception, Identifier
	Probe messages may be copied onto Probe Reception Report options.		values from both Keepalive and Probe messages may be copied onto
	This allows them to be used for both identifying which packets		Probe Reception Report options. This allows them to be used for
	were received as well as for performing a return routability test.		both identifying which packets were received as well as for
			performing a return routability test.
	The processing rules for this option are the given in more detail in		The processing rules for this option are the given in more detail in
	Section 6.4.		Section 5.4.
	6.2. Probe Message		5.2. Probe Message
	This message performs REAP exploration. Its format is as follows:		This message performs REAP exploration. Its format 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 = 67 | Reserved |0|		| Next Header | Hdr Ext Len |0| Type = 67 | Reserved |0|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Checksum |R| |		| Checksum |R| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	skipping to change at page 24, line 33		skipping to change at page 23, line 5
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ Options +		+ Options +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Next Header		Next Header
	This value MUST be set to NO_NXT_HDR (59).		This value MUST be set to NO_NXT_HDR (59).
			Hdr Ext Len
			This is an 8-bit unsigned integer field, calculated as specified
			in Section 5.3 of the SHIM6 protocol description
			[I-D.ietf-shim6-proto].
	Type		Type
	This field identifies the Probe message and MUST be set to 67		This field identifies the Probe message and MUST be set to 67
	(Probe).		(Probe).
	Reserved		Reserved
	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.
			Checksum
			This is a 16-bit field, calculated as specified in Section 5.3 of
			the SHIM6 protocol description [I-D.ietf-shim6-proto].
	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.
	Options		Options
	This MUST contain at least the Probe option and MAY contain one or		This MUST contain at least the Probe option and MAY contain one or
	more Reachability options.		more Reachability options.
	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 a context known by the receiver, is valid shim		Tag that matches to a context known by the receiver, is valid shim
	control message as defined in Section 12.2 of [18], and its shim		control message as defined in Section 12.2 of the SHIM6 protocol
	context state is ESTABLISHED. The receiver processes a valid message		description [I-D.ietf-shim6-proto], and its shim context state is
	by inspecting its options, and executing any actions specified such		ESTABLISHED. The receiver processes a valid message by inspecting
	options. This includes the SHIM6 Probe option found within the		its options, and executing any actions specified such options. This
	options.		includes the SHIM6 Probe option found within the options.
	The processing rules for this message are the given in more detail in		The processing rules for this message are the given in more detail in
	Section 6.4.		Section 5.4.
	6.2.1. Probe Option		5.2.1. Probe Option
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type = 11 |0| Length |		| Type = 11 |0| Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Y| Res | Identifier |		|Y| Res | Identifier |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type		Type
	This value MUST be set to 11 (Probe Option).		This value MUST be set to 11 (Probe Option).
	0		0
	This value MUST be set to 0, as in other SHIM6 options.		This value MUST be set to 0, as in other SHIM6 options.
	Length		Length
	This is the length of the option and MUST be calculated as		This is the length of the option and MUST be calculated as
	specified in Section 5.14 of [18].		specified in Section 5.14 of the SHIM6 protocol description
			[I-D.ietf-shim6-proto].
	Y (The "I See You" flag)		Y (The "I See You" flag)
	This flag is set to 1 if the sender receives either payload		This flag is set to 1 if the sender receives either payload
	packets or REAP messages from the peer, and 0 otherwise. The		packets or REAP messages from the peer, and 0 otherwise. The
	determination of when the sender receives something is made during		determination of when the sender receives something is made during
	the last Send Timeout seconds (see Section 6.5) when traffic was		the last Send Timeout seconds (see Section 5.5) when traffic was
	expected, i.e., when there was either payload traffic or REAP		expected, i.e., when there was either payload traffic or REAP
	messages.		messages.
	Upon reception, a value of 1 indicates that the receiver does not		Upon reception, a value of 1 indicates that the receiver does not
	need to change its behaviour as the sender is already seeing its		need to change its behaviour as the sender is already seeing its
	packets. A value of 0 indicates that the receiver MUST explore		packets. A value of 0 indicates that the receiver MUST explore
	different outgoing address pairs.		different outgoing address pairs.
	Res		Res
	This 3-bit reserved field MUST be set to zero when sending, and		This 3-bit reserved field MUST be set to zero when sending, and
	ignored on receipt.		ignored on receipt.
	Identifier		Identifier
	This 28-bit field identifies this particular instance of an Probe		This 28-bit field identifies this particular instance of an Probe
	message. This value SHOULD be generated using a random number		message. This value SHOULD be generated using a random number
	generator that is known to have good randomness properties [1].		generator that is known to have good randomness properties. Upon
	Upon reception, Identifier values are copied onto Probe Reception		reception, Identifier values are copied onto Probe Reception
	Report options. This allows them to be used for both identifying		Report options. This allows them to be used for both identifying
	which Probes were received as well as for performing a return		which Probes were received as well as for performing a return
	routability test.		routability test.
	The processing rules for this option are the given in more detail in		The processing rules for this option are the given in more detail in
	Section 6.4.		Section 5.4.
	6.3. Reachability Option		5.3. Reachability Option
	Additional information can be included in Keepalive and Probe		Additional information can be included in Keepalive and Probe
	messages by the inclusion of the Reachability Options. Their format		messages by the inclusion of the Reachability Options. Their format
	is as follows:		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type = 12 |0| Length |		| Type = 12 |0| Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 27, line 8		skipping to change at page 25, line 39
	This value MUST be set to 12 (Reachability option).		This value MUST be set to 12 (Reachability option).
	0		0
	This value MUST be set to 0, as in other SHIM6 options.		This value MUST be set to 0, as in other SHIM6 options.
	Length		Length
	This is the length of the option and MUST be calculated as		This is the length of the option and MUST be calculated as
	specified in Section 5.14 of [18].		specified in Section 5.14 of the SHIM6 protocol description
			[I-D.ietf-shim6-proto].
	Option Type		Option Type
	This value identifies the option.		This value identifies the option.
	Option Data		Option Data
	Option-specific content.		Option-specific content.
	Unrecognized options MUST be ignored upon receipt. All		Unrecognized options MUST be ignored upon receipt. All
	implementations MUST support the options defined in this		implementations MUST support the options defined in this
	specification, however.		specification, however.
	6.3.1. Payload Reception Report		5.3.1. Payload Reception Report
	This option SHOULD be included in all Probe messages when the sender		This option SHOULD be included in all Probe messages when the sender
	has recently (within the last Send Timeout seconds) received payload		has recently (within the last Send Timeout seconds) received payload
	packets from the peer. Its format is as follows:		packets from the peer. Its format 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type = 11 |0| Length |		| Type = 12 |0| Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Option Type = 1 | Reserved |		| Option Type = 1 | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ Suboptions ~		~ Suboptions ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type, 0, and Length		Type, 0, and Length
	These are as specified above.		These are as specified above.
	skipping to change at page 28, line 5		skipping to change at page 26, line 38
	This is a 16-bit field reserved for future use. It is set to zero		This is a 16-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.
	Suboptions		Suboptions
	This field is reserved for possible future Reachability options		This field is reserved for possible future Reachability options
	that are carried (recursively) within this option. Unrecognized		that are carried (recursively) within this option. Unrecognized
	options MUST be ignored upon receipt. Currently there are no		options MUST be ignored upon receipt. Currently there are no
	defined options that can be carried here.		defined options that can be carried here.
	6.3.2. Probe Reception Report		5.3.2. Probe Reception Report
	This option MUST be included in any Probe message when the sender has		This option MUST be included in any Probe message when the sender has
	recently (within the last Send Timeout seconds) received Probe or		recently (within the last Send Timeout seconds) received Probe or
	Keepalieve messages from the peer. Depending on MTU and timing		Keepalive messages from the peer. Depending on MTU and timing
	considerations, the sender MAY, however, include options for only		considerations, the sender MAY, however, include options for only
	some of the received Probe messages. All implementations MUST		some of the received Probe messages. All implementations MUST
	support sending of at least five such options, however.		support sending of at least five such options, however.
	The format of this option is as follows:		The format of this option 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type = 11 |0| Length |		| Type = 12 |0| Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Option Type = 2 | Reserved |		| Option Type = 2 | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Res | Identifier |		| Res | Identifier |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ Suboptions ~		~ Suboptions ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type, 0, and Length		Type, 0, and Length
	skipping to change at page 29, line 12		skipping to change at page 27, line 48
	This 32 bit field carries the identifier of the Probe message that		This 32 bit field carries the identifier of the Probe message that
	was recently received.		was recently received.
	Suboptions		Suboptions
	This field is reserved for possible future Reachability options		This field is reserved for possible future Reachability options
	that are carried (recursively) within this option. Unrecognized		that are carried (recursively) within this option. Unrecognized
	options MUST be ignored upon receipt. Currently there are no		options MUST be ignored upon receipt. Currently there are no
	defined options that can be carried here.		defined options that can be carried here.
	6.4. Behaviour		5.4. 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
			machine description in a tabular form. That form is only
			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 ExploringOK. 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		ExploringOK 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 and Keepalive timers. The Send		The node maintains also the Send and Keepalive timers. The Send
	timer reflects the requirement that when this node sends a payload		timer reflects the requirement that when this node sends a payload
	packet there should be some return traffic (either payload packets or		packet there should be some return traffic (either payload packets or
	Keepalive messages) within Keepalive Timeout seconds. The Keepalive		Keepalive messages) within Send Timeout seconds. The Keepalive timer
	timer reflects the requirement that when this node receives a payload		reflects the requirement that when this node receives a payload
	packet there should a similar response towards the peer. The		packet there should a similar response towards the peer. The
	Keepalive timer is only used within the Operational state, and the		Keepalive timer is only used within the Operational state, and the
	Send timer in the Operational and ExploringOK states. No timer is		Send timer in the Operational and ExploringOK states. No timer is
	running in the Exploring state.		running in the Exploring state.
	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. If the node is in the Exploring
	state it transitions to the ExploringOK state, sends a Probe message		state it transitions to the ExploringOK state, sends a Probe message
	with the I See You flag set to 1 (Yes), and starts the Send timer.		with the I See You flag set to 1 (Yes), and starts the Send timer.
	In the ExploringOK state the node stops the Send timer if it was		In the ExploringOK state the node stops the Send timer if it was
	running, but does not do anything else. The reception of SHIM6		running, but does not do anything else. The reception of SHIM6
	control messages other than the Keepalive and Probe messages are		control messages other than the Keepalive and Probe messages are
	treated similarly with payload packets.		treated similarly with payload packets.
			1. EVENT: Incoming payload packet
			=================================
			Operational Exploring ExploringOk
			-------------------------------------------------------------
			STOP Send; SEND Probe Y=Yes; STOP Send
			START Keepalive START Send;
			GOTO ExploringOk
	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 ExploringOK 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 ExploringOk
			-------------------------------------------------------------
			START Send; - START Send
			STOP Keepalive
	Upon a timeout on the Keepalive timer the node sends a Keepalive		Upon a timeout on the Keepalive timer the node sends a Keepalive
	message. This can only happen in the Operational state.		message. This can only happen in the Operational state.
			3. EVENT: Keepalive timeout
			Operational Exploring ExploringOk
			-------------------------------------------------------------
			SEND Keepalive - -
	Upon a timeout on the Send timer, the node enters the Exploring state		Upon a timeout on the Send timer, the node enters the Exploring state
	and sends a Probe with I See You set to 0 (No) and stops the		and sends a Probe with I See You set to 0 (No) and stops the
	Keepalive timer if it was running.		Keepalive timer if it was running.
			4. EVENT: Send timeout
			======================
			Operational Exploring ExploringOk
			-------------------------------------------------------------
			SEND Probe Y=No; - SEND Probe Y=No
			STOP Keepalive; GOTO Exploring
			GOTO Exploring
	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 5.3.		messages to different (or same) addresses as defined in Section 4.3.
	A similar process is employed in the ExploringOk 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
			========================
			Operational Exploring ExploringOk
			-------------------------------------------------------------
			- SEND Probe Y=No SEND Probe Y=Yes
			START Send
	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 ExploringOK state, sends a
	Probe message with the I See You flag set to 1 (Yes), and starts the		Probe message with the I See You flag set to 1 (Yes), and starts the
	Send timer. In the ExploringOK state the Send timer is stopped, if		Send timer. In the ExploringOK state the Send timer is stopped, if
	it was running.		it was running.
	Upon receiving a Probe with I See You set to 0 (No) the node enters		6. EVENT: Reception of the Keepalive message
	the ExploringOK state, sends a Probe with I See You set to 1 (Yes),
	stops the Keepalive timer if it was running, and restarts the Send
	timer.
	The behavior upon the reception of a Probe message with I see You set
	to 1 (Yes) depends on whether it contains a Probe Reception Report
	that refers to a Probe that this node has sent to the peer such that
	the I See You was set to 1 in that message. If not, the node sends a
	Probe message with I See You set to 1 (Yes), restarts the Send timer,
	stops the Keepalive timer if it was running, and transitions to the
	Operational state.
	If there was no such Probe Reception Report, the stops the Send timer
	if it was running, starts the Keepalive timer if it was not yet
	running, and transitions to the Operational state.
	Note: This check is necessary in order to terminate the
	exploration process when both parties are happy and know that
	their peers are happy as well.
	The reachability detection and exploration process has no effect on
	payload communications until a new working address pairs have
	actually been confirmed. Prior to that the payload packets continue
	to be sent to the previously used addresses.
	Garbage collection of SHIM6 contexts terminates contexts that are
	either unused or have failed due to the inability of the exploration
	process to find a working pair.
	In the PDF version of this specification, an informational drawing
	illustrates the state machine. Where the text and the drawing
	differ, the text takes precedence.
	A tabular representation of the state machine is shown below. Like
	the drawing, this representation is only informational.
	1. EVENT: Incoming payload packet
	=================================
	Operational Exploring ExploringOk
	---------------------------------------------------------------
	STOP Send; SEND Probe Y=Yes; STOP Send
	START Keepalive START Send;
	GOTO ExploringOk
	2. EVENT: Outgoing payload packet
	=================================
	Operational Exploring ExploringOk
	---------------------------------------------------------------
	START Send; - START Send
	STOP Keepalive
	3. EVENT: Keepalive timeout
	Operational Exploring ExploringOk
	---------------------------------------------------------------
	SEND Keepalive - -
	4. EVENT: Send timeout
	======================
	Operational Exploring ExploringOk
	---------------------------------------------------------------
	SEND Probe Y=No; - SEND Probe Y=No
	STOP Keepalive; GOTO EXPLORING
	GOTO EXPLORING
	5. EVENT: Reception of the Keepalive message
	============================================		============================================
	Operational Exploring ExploringOk		Operational Exploring ExploringOk
	---------------------------------------------------------------		-------------------------------------------------------------
	STOP Send SEND Probe Y=Yes; STOP Send		STOP Send SEND Probe Y=Yes; STOP Send
	START Send;		START Send;
	GOTO ExploringOk		GOTO ExploringOk
	6. EVENT: Reception of the Probe message with Y=No		Upon receiving a Probe with I See You set to 0 (No) the node enters
			the ExploringOK state, sends a Probe with I See You set to 1 (Yes),
			stops the Keepalive timer if it was running, and restarts the Send
			timer.
			7. EVENT: Reception of the Probe message with Y=No
	==================================================		==================================================
	Operational Exploring ExploringOk		Operational Exploring ExploringOk
	---------------------------------------------------------------		-------------------------------------------------------------
	SEND Probe Y=Yes SEND Probe Y=Yes; SEND Probe Y=Yes;		SEND Probe Y=Yes SEND Probe Y=Yes; SEND Probe Y=Yes;
	STOP Keepalive; START Send; RESTART Send		STOP Keepalive; START Send; RESTART Send
	RESTART Send; GOTO EXPLORINGOK		RESTART Send; GOTO ExploringOk
	GOTO EXPLORINGOK		GOTO ExploringOk
	7. EVENT: Reception of the Probe message with Y=Yes		The behavior upon the reception of a Probe message with I see You set
			to 1 (Yes) depends on whether it contains a Probe Reception Report
			that refers to a Probe that this node has sent to the peer such that
			the I See You was set to 1 in that message. If it does, the node
			sends a Probe message with I See You set to 1 (Yes), restarts the
			Send timer, stops the Keepalive timer if it was running, and
			transitions to the Operational state.
			8. EVENT: Reception of the Probe message with Y=Yes
	(peer reports not seeing yet a Probe with Y=Yes)		(peer reports not seeing yet a Probe with Y=Yes)
	==========================================================		==========================================================
	Operational Exploring ExploringOk		Operational Exploring ExploringOk
	---------------------------------------------------------------		-------------------------------------------------------------
	SEND Probe Y=Yes; SEND Probe Y=Yes; SEND Probe Y=Yes;		SEND Probe Y=Yes; SEND Probe Y=Yes; SEND Probe Y=Yes;
	RESTART Send; RESTART Send; RESTART Send;		RESTART Send; RESTART Send; RESTART Send;
	STOP Keepalive GOTO OPERATIONAL GOTO OPERATIONAL		STOP Keepalive GOTO Operational GOTO Operational
	8. EVENT: Reception of the Probe message with Y=Yes		If there was no such Probe Reception Report, the stops the Send timer
			if it was running, starts the Keepalive timer if it was not yet
			running, and transitions to the Operational state.
			Note: This check is necessary in order to terminate the
			exploration process when both parties are happy and know that
			their peers are happy as well.
			9. EVENT: Reception of the Probe message with Y=Yes
	(peer reports seeing a Probe with Y=Yes)		(peer reports seeing a Probe with Y=Yes)
	===================================================		===================================================
	Operational Exploring ExploringOk		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
	9. EVENT: Retransmission		The reachability detection and exploration process has no effect on
	========================		payload communications until a new operational address pairs have
			actually been confirmed. Prior to that the payload packets continue
			to be sent to the previously used addresses.
	Operational Exploring ExploringOk		Garbage collection of SHIM6 contexts terminates contexts that are
	---------------------------------------------------------------		either unused or have failed due to the inability of the exploration
	- SEND Probe Y=No SEND Probe Y=Yes		process to find an operational pair.
	START Send
	6.5. Protocol Constants		In the PDF version of this specification, an informational drawing
			illustrates the state machine. Where the text and the drawing
			differ, the text takes precedence.
			5.5. Protocol Constants
	The following protocol constants are defined:		The following protocol constants are defined:
	Send Timeout 10 seconds		Send Timeout 10 seconds
	Keepalive Timeout 3 seconds		Keepalive Timeout 3 seconds
			Initial Probe Timeout 0.5 seconds
			Number of Initial Probes 4 probes
			Max Probe Timeout 60 seconds
	7. Security Considerations		6. Security Considerations
	Attackers may spoof various indications from lower layers and the		Attackers may spoof various indications from lower layers and the
	network in an effort to confuse the peers about which addresses are		network in an effort to confuse the peers about which addresses are
	or are not working. For example, attackers may spoof ICMP error		or are not operational. For example, attackers may spoof ICMP error
	messages in an effort to cause the parties to move their traffic		messages in an effort to cause the parties to move their traffic
	elsewhere or even to disconnect. Attackers may also spoof		elsewhere or even to disconnect. Attackers may also spoof
	information related to network attachments, router discovery, and		information related to network attachments, router discovery, and
	address assignments in an effort to make the parties believe they		address assignments in an effort to make the parties believe they
	have Internet connectivity when in reality they do not.		have Internet connectivity when in reality they do not.
	This may cause use of non-preferred addresses or even denial-of-		This may cause use of non-preferred addresses or even denial-of-
	service.		service.
	This protocol does not provide any protection of its own for		This protocol does not provide any protection of its own for
	indications from other parts of the protocol stack. However, this		indications from other parts of the protocol stack. Unprotected
	protocol has weak resistance against incorrect information from these		indications SHOULD NOT be taken as a proof of connectivity problems.
	sources in the sense that it performs its own tests prior to picking		However, REAP has weak resistance against incorrect information even
	a new address pair. Denial-of- service vulnerabilities remain,		from unprotected indications in the sense that it performs its own
	however, as do vulnerabilities against on path attackers.		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		Some aspects of these vulnerabilities can be mitigated through the
	use of techniques specific to the other parts of the stack, such as		use of techniques specific to the other parts of the stack, such as
	properly dealing with ICMP errors [22], link layer security, or the		properly dealing with ICMP errors [I-D.ietf-tcpm-icmp-attacks], link
	use of [12] to protect IPv6 Router and Neighbor Discovery.		layer security, or the use of SEND [RFC3971] to protect IPv6 Router
			and Neighbor Discovery.
	This protocol is designed to be used in situations where other parts		Other parts of the SHIM6 protocol ensure that the set of addresses we
	of the stack have ensured that a set of addresses belong together,		are switching between actually belong together. REAP itself provides
	such as via SHIM6 HBAs [17]. That is, REAP itself provides no		no such assurances. Similarly, REAP provides only minimal protection
	assurance that a set of addresses belongs to the same host.		against third party flooding attacks; when REAP is run its Probe
	Similarly, REAP provides only minimal protection against third party		identifiers can be used as a return routability check that the
	flooding attacks; when REAP is run its Probe identifiers can be used		claimed address is indeed willing to receive traffic. However, this
	as a return routability check that the claimed address is indeed		needs to be complemented with another mechanism to ensure that the
	willing to receive traffic. However, this needs to be complemented		claimed address is also the correct host. SHIM6 does this by
	with another mechanism to ensure that the claimed address is also the		performing binding of all operations to context tags.
	correct host. In SHIM6 this is performed by binding 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		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		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		in flooding attacks. In order to prevent this it is required that
	the protocol employing REAP has built-in mechanisms to prevent this.		the protocol employing REAP has built-in mechanisms to prevent this.
	For instance, in SHIM6 contexts are created only after a relatively		For instance, in SHIM6 contexts are created only after a relatively
	large number of packets has been exchanged, a cost which reduces the		large number of packets has been exchanged, a cost which reduces the
	attractiveness of using SHIM6 and REAP for amplification attacks.		attractiveness of using SHIM6 and REAP for amplification attacks.
	However, such protections are typically not present at connection		However, such protections are typically not present at connection
	establishment time. When exploration would be needed for connection		establishment time. When exploration would be needed for connection
	establishment to succeed, its usage would result in an amplification		establishment to succeed, its usage would result in an amplification
	vulnerability. As a result, SHIM6 does not support the use of REAP		vulnerability. As a result, SHIM6 does not support the use of REAP
	in connection establishment stage.		in connection establishment stage.
	8. IANA Considerations		7. IANA Considerations
	This document creates one new name spaces under the new SHIM6		This document creates one new name spaces under the new SHIM6
	Reachability Protocol repository. The name space is for Reachability		Reachability Protocol repository. The name space is for Reachability
	Option Type (Section 6.3) and it has one reserved value (0) and two		Option Type (Section 5.3) and it has one reserved value (0) and two
	defined values, 1 (Payload Reception Report defined in Section 6.3.1)		defined values, 1 (Payload Reception Report defined in Section 5.3.1)
	and 2 (Probe Reception Report defined in Section 6.3.2). Further		and 2 (Probe Reception Report defined in Section 5.3.2). Further
	allocations within this 16-bit field can be made through		allocations within this 16-bit field can be made through
	Specification Required. The range from 65000 to 65535 is reserved		Specification Required. The range from 65000 to 65535 is reserved
	for experimental use.		for experimental use.
	9. References		8. References
	9.1. Normative References		8.1. Normative References
	[1] Eastlake, D., Crocker, S., and J. Schiller, "Randomness		[RFC1750] Eastlake, D., Crocker, S., and J. Schiller, "Randomness
	Recommendations for Security", RFC 1750, December 1994.		Recommendations for Security", RFC 1750, December 1994.
	[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery		[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
	for IP Version 6 (IPv6)", RFC 2461, December 1998.		Discovery for IP Version 6 (IPv6)", RFC 2461,
			December 1998.
	[4] Thomson, S. and T. Narten, "IPv6 Stateless Address		[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
	Autoconfiguration", RFC 2462, December 1998.		Autoconfiguration", RFC 2462, December 1998.
	[5] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.		[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
	Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",		and M. Carney, "Dynamic Host Configuration Protocol for
	RFC 3315, July 2003.		IPv6 (DHCPv6)", RFC 3315, July 2003.
	[6] Draves, R., "Default Address Selection for Internet Protocol
	version 6 (IPv6)", RFC 3484, February 2003.
	[7] Choi, J., "Detecting Network Attachment in IPv6 Goals",
	draft-ietf-dna-goals-00 (work in progress), June 2004.
	[8] Moore, N., "Optimistic Duplicate Address Detection for IPv6",
	draft-ietf-ipv6-optimistic-dad-01 (work in progress), June 2004.
	[9] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
	Addresses", draft-ietf-ipv6-unique-local-addr-05 (work in
	progress), June 2004.
	9.2. Informative References
	[10] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,		[RFC3484] Draves, R., "Default Address Selection for Internet
	H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V.		Protocol version 6 (IPv6)", RFC 3484, February 2003.
	Paxson, "Stream Control Transmission Protocol", RFC 2960,
	October 2000.
	[11] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN		[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
	- Simple Traversal of User Datagram Protocol (UDP) Through		Addresses", RFC 4193, October 2005.
	Network Address Translators (NATs)", RFC 3489, March 2003.
	[12] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure		[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)
	Neighbor Discovery (SEND)", RFC 3971, March 2005.		for IPv6", RFC 4429, April 2006.
	[13] Aboba, B., "Detection of Network Attachment (DNA) in IPv4",		8.2. Informative References
	draft-ietf-dhc-dna-ipv4-08 (work in progress), July 2004.
	[14] Nikander, P., "End-Host Mobility and Multi-Homing with Host		[AURA02] Aura, T., Roe, M., and J. Arkko, "Security of Internet
	Identity Protocol", draft-ietf-hip-mm-00 (work in progress),		Location Management", In Proceedings of the 18th Annual
	October 2004.		Computer Security Applications Conference, Las Vegas,
			Nevada, USA., December 2002.
	[15] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)",		[I-D.bagnulo-shim6-addr-selection]
	draft-ietf-mobike-protocol-03 (work in progress),		Bagnulo, M., "Address selection in multihomed
	September 2005.		environments", draft-bagnulo-shim6-addr-selection-00 (work
			in progress), October 2005.
	[16] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A		[I-D.huitema-multi6-addr-selection]
	Methodology for Network Address Translator (NAT) Traversal for		Huitema, C., "Address selection in multihomed
	Multimedia Session Establishment Protocols",		environments", draft-huitema-multi6-addr-selection-00
	draft-ietf-mmusic-ice-02 (work in progress), July 2004.		(work in progress), October 2004.
	[17] Bagnulo, M., "Hash Based Addresses (HBA)",		[I-D.ietf-dna-cpl]
	draft-ietf-shim6-hba-00 (work in progress), July 2005.		Nordmark, E. and J. Choi, "DNA with unmodified routers:
			Prefix list based approach", draft-ietf-dna-cpl-02 (work
			in progress), January 2006.
	[18] Nordmark, E., "Level 3 multihoming shim protocol",		[I-D.ietf-dna-protocol]
	draft-ietf-shim6-proto-00 (work in progress), October 2005.		Kempf, J., "Detecting Network Attachment in IPv6 Networks
			(DNAv6)", draft-ietf-dna-protocol-00 (work in progress),
			February 2006.
	[19] Beijnum, I., "Shim6 Reachability Detection",		[I-D.ietf-hip-mm]
	draft-ietf-shim6-reach-detect-00 (work in progress), July 2005.		Nikander, P., "End-Host Mobility and Multihoming with the
			Host Identity Protocol", draft-ietf-hip-mm-03 (work in
			progress), March 2006.
	[20] Stewart, R., "Stream Control Transmission Protocol (SCTP)		[I-D.ietf-shim6-proto]
	Dynamic Address Reconfiguration",		Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim
	draft-ietf-tsvwg-addip-sctp-10 (work in progress),		protocol", draft-ietf-shim6-proto-05 (work in progress),
	January 2005.		May 2006.
	[21] Bagnulo, M., "Address selection in multihomed environments",		[I-D.ietf-shim6-reach-detect]
	draft-bagnulo-shim6-addr-selection-00 (work in progress),		Beijnum, I., "Shim6 Reachability Detection",
			draft-ietf-shim6-reach-detect-01 (work in progress),
	October 2005.		October 2005.
	[22] Gont, F., "ICMP attacks against TCP",		[I-D.ietf-tcpm-icmp-attacks]
	draft-gont-tcpm-icmp-attacks-00 (work in progress),		Gont, F., "ICMP attacks against TCP",
	August 2004.		draft-ietf-tcpm-icmp-attacks-00 (work in progress),
			February 2006.
	[23] Huitema, C., "Address selection in multihomed environments",
	draft-huitema-multi6-addr-selection-00 (work in progress),
	October 2004.
	[24] Rosenberg, J., "Traversal Using Relay NAT (TURN)",		[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
	draft-rosenberg-midcom-turn-05 (work in progress), July 2004.		Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
			Zhang, L., and V. Paxson, "Stream Control Transmission
			Protocol", RFC 2960, October 2000.
	[25] Aura, T., Roe, M., and J. Arkko, "Security of Internet Location		[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
	Management", In Proceedings of the 18th Annual Computer		Neighbor Discovery (SEND)", RFC 3971, March 2005.
	Security Applications Conference, Las Vegas, Nevada, USA.,
	December 2002.
	Appendix A. Contributors		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, Iljitsch van Beijnum, Erik Nordmark,		members Marcelo Bagnulo Braun, Iljitsch van Beijnum, Erik Nordmark,
	Geoff Huston, Margaret Wasserman, and Jukka Ylitalo, the MOBIKE WG		Geoff Huston, 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 my colleague Pekka Nikander at		Dawkins, and James Kempf, and my colleague Pekka Nikander at
	Ericsson. This draft is also in debt to work done in the context of		Ericsson. This draft is also in debt to work done in the context of
	SCTP [10] and HIP [14].		SCTP [RFC2960] and HIP [I-D.ietf-hip-mm].
	Appendix B. Acknowledgements		Appendix B. Acknowledgements
	The author would also like to thank Christian Huitema, Pekka Savola,		The authors would also like to thank Christian Huitema, Pekka Savola,
	and Hannes Tschofenig for interesting discussions in this problem		John Loughney, Sam Xia, and Hannes Tschofenig for interesting
	space, and for their comments on earlier versions of this draft.		discussions in this problem 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
	Muada		Muada
	The Netherlands		The Netherlands
	Email: iljitsch@muada.com		Email: iljitsch@muada.com
	Intellectual Property Statement		Full Copyright Statement
			Copyright (C) The Internet Society (2006).
			This document is subject to the rights, licenses and restrictions
			contained in BCP 78, and except as set forth therein, the authors
			retain all their rights.
			This document and the information contained herein are provided on an
			"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
			OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
			ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
			INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
			INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
			WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
			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
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
	skipping to change at page 42, line 29		skipping to change at page 40, line 45
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Disclaimer of Validity
	This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement
	Copyright (C) The Internet Society (2005). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is provided by the IETF
	Internet Society.		Administrative Support Activity (IASA).
End of changes. 152 change blocks.
	578 lines changed or deleted		546 lines changed or added
This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/