< draft-ietf-shim6-failure-detection-10.txt		draft-ietf-shim6-failure-detection-11.txt >
	Network Working Group J. Arkko		Network Working Group J. Arkko
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Intended status: Standards Track I. van Beijnum		Intended status: Standards Track I. van Beijnum
	Expires: July 26, 2008 January 23, 2008		Expires: August 16, 2008 IMDEA Networks
			February 13, 2008
	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-10		draft-ietf-shim6-failure-detection-11
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 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 July 26, 2008.		This Internet-Draft will expire on August 16, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2008).		Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	This document specifies how the level 3 multihoming shim protocol		This document specifies how the level 3 multihoming shim protocol
	(SHIM6) detects failures between two communicating hosts. It also		(SHIM6) detects failures between two communicating hosts. It also
	specifies an exploration protocol for switching to another pair of		specifies an exploration protocol for switching to another pair of
	skipping to change at page 3, line 22 ¶		skipping to change at page 3, line 22 ¶
	3.3. Operational Address Pairs . . . . . . . . . . . . . . . 7		3.3. Operational Address Pairs . . . . . . . . . . . . . . . 7
	3.4. Primary Address Pair . . . . . . . . . . . . . . . . . . 9		3.4. Primary Address Pair . . . . . . . . . . . . . . . . . . 9
	3.5. Current Address Pair . . . . . . . . . . . . . . . . . . 9		3.5. Current Address Pair . . . . . . . . . . . . . . . . . . 9
	4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10		4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10
	4.1. Failure Detection . . . . . . . . . . . . . . . . . . . 10		4.1. Failure Detection . . . . . . . . . . . . . . . . . . . 10
	4.2. Full Reachability Exploration . . . . . . . . . . . . . 12		4.2. Full Reachability Exploration . . . . . . . . . . . . . 12
	4.3. Exploration Order . . . . . . . . . . . . . . . . . . . 13		4.3. Exploration Order . . . . . . . . . . . . . . . . . . . 13
	5. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 15		5. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 15
	5.1. Keepalive Message . . . . . . . . . . . . . . . . . . . 15		5.1. Keepalive Message . . . . . . . . . . . . . . . . . . . 15
	5.2. Probe Message . . . . . . . . . . . . . . . . . . . . . 16		5.2. Probe Message . . . . . . . . . . . . . . . . . . . . . 16
	5.3. Keepalive Timeout Option Format . . . . . . . . . . . . 21		5.3. Keepalive Timeout Option Format . . . . . . . . . . . . 20
	6. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . 22		6. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . 22
	6.1. Incoming payload packet . . . . . . . . . . . . . . . . 22		6.1. Incoming payload packet . . . . . . . . . . . . . . . . 22
	6.2. Outgoing payload packet . . . . . . . . . . . . . . . . 23		6.2. Outgoing payload packet . . . . . . . . . . . . . . . . 23
	6.3. Keepalive timeout . . . . . . . . . . . . . . . . . . . 23		6.3. Keepalive timeout . . . . . . . . . . . . . . . . . . . 23
	6.4. Send timeout . . . . . . . . . . . . . . . . . . . . . . 24		6.4. Send timeout . . . . . . . . . . . . . . . . . . . . . . 24
	6.5. Retransmission . . . . . . . . . . . . . . . . . . . . . 24		6.5. Retransmission . . . . . . . . . . . . . . . . . . . . . 24
	6.6. Reception of the Keepalive message . . . . . . . . . . . 24		6.6. Reception of the Keepalive message . . . . . . . . . . . 24
	6.7. Reception of the Probe message State=Exploring . . . . . 25		6.7. Reception of the Probe message State=Exploring . . . . . 25
	6.8. Reception of the Probe message State=InboundOk . . . . . 25		6.8. Reception of the Probe message State=InboundOk . . . . . 25
	6.9. Reception of the Probe message State=Operational . . . . 25		6.9. Reception of the Probe message State=Operational . . . . 25
	6.10. Graphical Representation of the State Machine . . . . . 26		6.10. Graphical Representation of the State Machine . . . . . 26
	7. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 27		7. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 27
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 28		8. Security Considerations . . . . . . . . . . . . . . . . . . . 28
	9. Operational Considerations . . . . . . . . . . . . . . . . . . 30		9. Operational Considerations . . . . . . . . . . . . . . . . . . 30
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
	11.1. Normative References . . . . . . . . . . . . . . . . . . 32		11.1. Normative References . . . . . . . . . . . . . . . . . . 33
	11.2. Informative References . . . . . . . . . . . . . . . . . 32		11.2. Informative References . . . . . . . . . . . . . . . . . 33
	Appendix A. Example Protocol Runs . . . . . . . . . . . . . . . . 34		Appendix A. Example Protocol Runs . . . . . . . . . . . . . . . . 35
	Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 39		Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 40
	Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 40		Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 41
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42
	Intellectual Property and Copyright Statements . . . . . . . . . . 42		Intellectual Property and Copyright Statements . . . . . . . . . . 43
	1. Introduction		1. Introduction
	The SHIM6 protocol [I-D.ietf-shim6-proto] extends IPv6 to support		The SHIM6 protocol [I-D.ietf-shim6-proto] extends IPv6 to support
	multihoming. It is an IP layer mechanism that hides multihoming from		multihoming. It is an IP layer mechanism that hides multihoming from
	applications. A part of the SHIM6 solution involves detecting when a		applications. A part of the SHIM6 solution involves detecting when a
	currently used pair of addresses (or interfaces) between two		currently used pair of addresses (or interfaces) between two
	communication hosts has failed, and picking another pair when this		communication hosts has failed, and picking another pair when this
	occurs. We call the former failure detection, and the latter locator		occurs. We call the former failure detection, and the latter locator
	pair exploration.		pair exploration.
	This document specifies the mechanisms and protocol messages to		This document specifies the mechanisms and protocol messages to
	achieve both failure detection and locator pair exploration. This		achieve both failure detection and locator pair exploration. This
	part of the SHIM6 protocol is called the REAchability Protocol		part of the SHIM6 protocol is called the REAchability Protocol
	(REAP).		(REAP).
			Failure detection is made as light weight as possible. Data traffic
			in both direction is observed, and in the case where there is no
			traffic because the communication is idle, failure detection is also
			idle and doesn't generate any packets. When data traffic is flowing
			in both directions, there is no need to send failure detection
			packets, either. Only when there is traffic in one direction, the
			failure detection mechanism generates keepalives in the other
			direction. As a result, whenever there is outgoing traffic and no
			incoming return traffic or keepalives, there must be failure, at
			which point the locator pair exploration is performed to find a
			working address pair for each direction.
	The document is structured as follows: Section 3 defines a set of		The document is structured as follows: Section 3 defines a set of
	useful terms, Section 4 gives an overview of REAP, and Section 5		useful terms, Section 4 gives an overview of REAP, and Section 5
	specifies the message formats and behaviour in detail. Section 8		specifies the message formats and behaviour in detail. Section 8
	discusses the security considerations of REAP.		discusses the security considerations of REAP.
	In this specification, we consider an address to be synonymous with a		In this specification, we consider an address to be synonymous with a
	locator. Other parts of the SHIM6 protocol ensure that the different		locator. Other parts of the SHIM6 protocol ensure that the different
	locators used by a node actually belong together. That is, REAP is		locators used by a node actually belong together. That is, REAP is
	not responsible for ensuring that it ends up with a legitimate		not responsible for ensuring that it ends up with a legitimate
	locator.		locator.
	skipping to change at page 8, line 11 ¶		skipping to change at page 8, line 11 ¶
	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. Unidirectionally 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 when packets sent with the first address as		operational address pair when 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 reaches the
	reach the destination.		destination.
	SHIM6 implementations MUST support the discovery of operational		SHIM6 implementations MUST support the discovery of operational
	address pairs through the use of explicit rechability tests and		address pairs through the use of explicit reachability tests and
	Forced Bidirectional Communication (FBD), described later in this		Forced Bidirectional Communication (FBD), described later in this
	specification. In addition, implementations MAY employ the following		specification. In addition, implementations MAY employ additional
	additional mechanisms:		mechanisms. Some ideas such mechanisms are listed below, but not
			fully specified in this document:
	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 [RFC4861].		bidirectional connectivity [RFC4861].
	In the case of unidirectional connectivity, the upper layer		In the case of unidirectional connectivity, the upper layer
	protocol responses come back using another address pair, but show		protocol responses come back using another address pair, but show
	that the messages sent using the first address pair have been		that the messages sent using the first address pair have been
	skipping to change at page 9, line 22 ¶		skipping to change at page 9, line 22 ¶
	3.5. Current Address Pair		3.5. Current Address Pair
	SHIM6 needs to avoid sending packets which belong to the same		SHIM6 needs to avoid sending packets which belong to the same
	transport connection concurrently over multiple paths. This is		transport connection concurrently over multiple paths. This is
	because congestion control in commonly used transport protocols is		because congestion control in commonly used transport protocols is
	based upon a notion of a single path. While routing can introduce		based upon a notion of a single path. While routing can introduce
	path changes as well and transport protocols have means to deal with		path changes as well and transport protocols have means to deal with
	this, frequent changes will cause problems. Effective congestion		this, frequent changes will cause problems. Effective congestion
	control over multiple paths is considered a research topic at the		control over multiple paths is considered a research topic at the
	time this specification is written.		time this specification is written. SHIM6 does not attempt to employ
			multiple paths simultaneously.
			Note: SCTP and future multipath transport protocols are likely to
			require interaction with SHIM6, at least to ensure that they do
			not employ SHIM6 unexpectedly.
	For these reasons it is necessary to choose a particular pair of		For these reasons it is necessary to choose a particular pair of
	addresses as the current address pair which is used until problems		addresses as the current address pair which is used until problems
	occur, at least for the same session.		occur, at least for the same session.
	It is theoretically possible to support multiple current address		It is theoretically possible to support multiple current address
	pairs for different transport sessions or SHIM6 contexts.		pairs for different transport sessions or SHIM6 contexts.
	However, this is not supported in this version of the SHIM6		However, this is not supported in this version of the SHIM6
	protocol.		protocol.
	skipping to change at page 11, line 27 ¶		skipping to change at page 11, line 27 ¶
	packets from its peer but not sending any of its own. The		packets from its peer but not sending any of its own. The
	keepalives are sent at certain intervals so that the other side		keepalives are sent at certain intervals so that the other side
	knows there is a reachability problem when it doesn't receive any		knows there is a reachability problem when it doesn't receive any
	incoming packets for its Send Timeout period. The host		incoming packets for its Send Timeout period. The host
	communicates its Send Timeout value to the peer as an Keepalive		communicates its Send Timeout value to the peer as an Keepalive
	Timeout Option (section 5.3) in the I2, I2bis, R2, or UPDATE		Timeout Option (section 5.3) in the I2, I2bis, R2, or UPDATE
	messages. The peer then maps this value to its Keepalive Timeout		messages. The peer then maps this value to its Keepalive Timeout
	value.		value.
	The interval after which keepalives are sent is named Keepalive		The interval after which keepalives are sent is named Keepalive
	Interval. This document doesn't specify a value for Keepalive		Interval. The RECOMMENDED approach is sending keepalives at one-
	Interval, but recognizes that an often used approach is sending		half to one-third of the Keepalive Timeout interval, so that
	keepalives at one-half to one-third of the Keepalive Timeout		multiple keepalives are generated and have time to reach the
	interval, so that multiple keepalives are generated and have time		correspondent before it times out.
	to reach the correspondent before it times out. An upper bound
	on this interval would be (Keepalive Timeout - 2) seconds, so
	that one keepalive has time to reach the other side, assuming a
	maximum one-way delay of 2 seconds.
	2. Whenever outgoing data packets are generated, a timer is started		2. Whenever outgoing data packets are generated, a timer is started
	to reflect the requirement that the peer should generate return		to reflect the requirement that the peer should generate return
	traffic from data packets. The timeout value is set to the value		traffic from data packets. The timeout value is set to the value
	of Send Timeout.		of Send Timeout.
	For the purposes of this specification, "data packet" refers to		For the purposes of this specification, "data packet" refers to
	any packet that is part of a SHIM6 context, including both upper		any packet that is part of a SHIM6 context, including both upper
	layer protocol packets and SHIM6 protocol messages except those		layer protocol packets and SHIM6 protocol messages except those
	defined in this specification.		defined in this specification.
	skipping to change at page 12, line 33 ¶		skipping to change at page 12, line 28 ¶
	until either a data packet in the SHIM6 context has been received		until either a data packet in the SHIM6 context has been received
	from the peer or the Keepalive Timeout expires. Keepalives are		from the peer or the Keepalive Timeout expires. Keepalives are
	not sent at all if data was sent within the keep-alive interval.		not sent at all if data was sent within the keep-alive interval.
	6. Send Timeout seconds after the transmission of a data packet with		6. Send Timeout seconds after the transmission of a data packet with
	no return traffic on this context, a full reachability		no return traffic on this context, a full reachability
	exploration is started.		exploration is started.
	Section 7 provides some suggested defaults for these timeout values.		Section 7 provides some suggested defaults for these timeout values.
	Experience from the deployment of the SHIM6 protocol is needed in		Experience from the deployment of the SHIM6 protocol is needed in
	order to determine what values are most suitable. The setting of		order to determine what values are most suitable.
	these values is also related to various parameters in transport
	protocols, such as TCP keepalive interval.
	4.2. Full Reachability Exploration		4.2. Full Reachability Exploration
	As explained in previous sections, the currently used address pair		As explained in previous sections, the currently used address pair
	may become invalid either through one of the addresses being becoming		may become invalid either through one of the addresses being becoming
	unavailable or inoperational, or the pair itself being declared		unavailable or nonoperational, or the pair itself being declared
	inoperational. An exploration process attempts to find another		nonoperational. 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.
	Instead, the party that first detects the problem starts a process		Instead, the party that first detects the problem starts a process
	where it tries each of the different address pairs in turn by sending		where it tries each of the different address pairs in turn by sending
	a message to its peer. These messages carry information about the		a message to its peer. These messages carry information about the
	state of connectivity between the peers, such as whether the sender		state of connectivity between the peers, such as whether the sender
	has seen any traffic from the peer recently. When the peer receives		has seen any traffic from the peer recently. When the peer receives
	skipping to change at page 13, line 24 ¶		skipping to change at page 13, line 18 ¶
	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, the network path traversed most		Upon changing to a new address pair, the network path traversed most
	likely has changed, so that the ULP SHOULD be informed. This can be		likely has changed, so that the ULP SHOULD be informed. This can be
	a signal for the ULP to adapt due to the change in path so that, for		a signal for the ULP to adapt due to the change in path so that, for
	example, TCP could initiate a slow start procedure, although it's		example, TCP could initiate a slow start procedure, although it's
	likely that the circumstances that led to the selection of a new path		likely that the circumstances that led to the selection of a new path
	already caused enough packet loss to trigger slow start.		already caused enough packet loss to trigger slow start.
	Similarly, one can also envision that applications would be able to
	tell the IP or transport layer that the current connection is
	unsatisfactory and an exploration for a better one would be
	desirable. This would require an inter-layer communication mechanism
	to be developed, however. In any case, this is another issue that we
	treat as being outside the scope of pure address exploration.
	REAP is designed to support failure recovery even in the case of		REAP is designed to support failure recovery even in the case of
	having only unidirectionally operational address pairs. However, due		having only unidirectionally operational address pairs. However, due
	to security concerns discussed in Section 8, the exploration process		to security concerns discussed in Section 8, the exploration process
	can typically be run only for a session that has already been		can typically be run only for a session that has already been
	established. Specifically, while REAP would in theory be capable of		established. Specifically, while REAP would in theory be capable of
	exploration even during connection establishment, its use within the		exploration even during connection establishment, its use within the
	SHIM6 protocol does not allow this.		SHIM6 protocol does not allow this.
	4.3. Exploration Order		4.3. Exploration Order
	skipping to change at page 14, line 17 ¶		skipping to change at page 14, line 4 ¶
	preferred over others, and try pairs containing such addresses first.		preferred over others, and try pairs containing such addresses first.
	The SHIM6 protocol also carries preference information in its		The SHIM6 protocol also carries preference information in its
	messages.		messages.
	Out of the set of possible candidate address pairs, nodes SHOULD		Out of the set of possible candidate address pairs, nodes SHOULD
	attempt to test through all of them until an operational pair is		attempt to test through all of them until an operational pair is
	found, and retrying the process as is necessary. However, all nodes		found, and retrying the process as is necessary. However, all nodes
	MUST perform this process sequentially and with exponential back-off.		MUST perform this process sequentially and with exponential back-off.
	This sequential process is necessary in order to avoid a "signaling		This sequential process is necessary in order to avoid a "signaling
	storm" when an outage occurs (particularly for a complete site).		storm" when an outage occurs (particularly for a complete site).
	However, it also limits the number of addresses that can in practice		However, it also limits the number of addresses that can in practice
	be used for multihoming, considering that transport and application		be used for multihoming, considering that transport and application
	layer protocols will fail if the switch to a new address pair takes		layer protocols will fail if the switch to a new address pair takes
	too long.		too long.
	Section 7 suggests default values for the timers associated with the		Section 7 suggests default values for the timers associated with the
	exploration process. The value Initial Probe Timeout (0.5 seconds)		exploration process. The value Initial Probe Timeout (0.5 seconds)
	specifies the interval between initial attempts to send probes;		specifies the interval between initial attempts to send probes;
	Number of Initial Probes (4) specifies how many initial probes can be		Number of Initial Probes (4) specifies how many initial probes can be
	sent before the exponential backoff procedure needs to be employed.		sent before the exponential backoff procedure needs to be employed.
	This process increases the time between every probe if there is no		This process increases the time between every probe if there is no
	response. Typically, each increase doubles the time but this		response. Typically, each increase doubles the time but this
	specification does not mandate a particular increase.		specification does not mandate a particular increase.
			Note: The rationale for sending four packets at a fixed rate
			before the exponential backoff is employed is to avoid having to
			send these packets excessively fast. Without this, having 0.5
			seconds between the third and fourth probe means that the time
			between the first and second probe would have to be 0.125 seconds,
			which gives very little time for a reply to the first packet to
			arrive. Also, this means that the first four packets are sent
			within 0.875 seconds rather than 2 seconds, increasing the
			potential for congestion if a large number of shim contexts need
			to send probes at the same time after a failure.
	Finally, Max Probe Timeout (60 seconds) specifies a limit beyond		Finally, Max Probe Timeout (60 seconds) specifies a limit beyond
	which the probe interval may not grow. If the exploration process		which the probe interval may not grow. If the exploration process
	reaches this interval, it will continue sending at this rate until a		reaches this interval, it will continue sending at this rate until a
	suitable response is triggered or the SHIM6 context is garbage		suitable response is triggered or the SHIM6 context is garbage
	collected, because upper layer protocols using the SHIM6 context in		collected, because upper layer protocols using the SHIM6 context in
	question are no longer attempting to send packets. Reaching the Max		question are no longer attempting to send packets. Reaching the Max
	Probe Timeout may also serve as a hint to the garbage collection		Probe Timeout may also serve as a hint to the garbage collection
	process that the context is no longer usable.		process that the context is no longer usable.
	5. Protocol Definition		5. Protocol Definition
	skipping to change at page 16, line 24 ¶		skipping to change at page 16, line 24 ¶
	no defined options that are useful in a Keepalive message. These		no defined options that are useful in a Keepalive message. These
	options are provided only for future extensibility reasons.		options are provided only for future extensibility reasons.
	A valid message conforms to the format above, has a Receiver Context		A valid message conforms to the format above, has a Receiver Context
	Tag that matches to context known by the receiver, is valid shim		Tag that matches to context known by the receiver, is valid shim
	control message as defined in Section 12.2 of the SHIM6 protocol		control message as defined in Section 12.2 of the SHIM6 protocol
	description [I-D.ietf-shim6-proto], and its shim context state is		description [I-D.ietf-shim6-proto], and its shim context state is
	ESTABLISHED. The receiver processes a valid message by inspecting		ESTABLISHED. The receiver processes a valid message by inspecting
	its options, and executing any actions specified for such options.		its options, and executing any actions specified for such options.
	Discussion: It may appear prudent to include additional fields
	that would provide at least a basic level of security, but since
	data packets also indicate ongoing reachability, just as
	keepalives, and those packets don't have such fields, there is
	little or no reason to include them in a keepalive.
	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.		Section 6.
	5.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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 19, line 33 ¶		skipping to change at page 19, line 28 ¶
	included in this probe message. The first set of probe fields		included in this probe message. The first set of probe fields
	pertains to the current message and MUST be present, so the		pertains to the current message and MUST be present, so the
	minimum value for this field is 1. Additional sent probe fields		minimum value for this field is 1. Additional sent probe fields
	are copies of the same fields sent in (recent) earlier probes and		are copies of the same fields sent in (recent) earlier probes and
	may be included or omitted as per any logic employed by the		may be included or omitted as per any logic employed by the
	implementation.		implementation.
	Precvd		Precvd
	This is a 4-bit field that indicates the number of received probes		This is a 4-bit field that indicates the number of received probes
	included in this probe messsage. Received probe fields are copies		included in this probe message. Received probe fields are copies
	of the same fields received in (recent) earlier probes and may be		of the same fields in earlier received probes that arrived since
	included or omitted as per any logic employed by the		the last transition from state Operational to state Exploring.
	implementation.		When a sender is in state InboundOk it MUST include copies of the
			fields of at least one of the inbound probes. A sender MAY
			include additional sets of these received probe fields in any
			state as per any logic employed by the implementation.
	The fields probe source, probe destination, probe nonce and probe		The fields probe source, probe destination, probe nonce and probe
	data may be repeated, depending on the value of Psent and		data may be repeated, depending on the value of Psent and
	Preceived.		Preceived.
	Sta (State)		Sta (State)
	This 2-bit State field is used to inform the peer about the state		This 2-bit State field is used to inform the peer about the state
	of the sender. It has three legal values:		of the sender. It has three legal values:
	skipping to change at page 20, line 30 ¶		skipping to change at page 20, line 29 ¶
	Probe destination		Probe destination
	This 128-bit field contains the destination IPv6 address used to		This 128-bit field contains the destination IPv6 address used to
	send the probe.		send the probe.
	Probe nonce		Probe nonce
	This is a 32-bit field that is initialized by the sender with a		This is a 32-bit field that is initialized by the sender with a
	value that allows it to determine which sent probes a received		value that allows it to determine which sent probes a received
	probe correlates with. It is highly recommeded that the nonce		probe correlates with. It is highly RECOMMENDED that the nonce
	field is at least moderately hard to guess so that even on-path		field is at least moderately hard to guess so that even on-path
	attackers can't deduce the next nonce value that will be used.		attackers can't deduce the next nonce value that will be used.
	This value SHOULD be generated using a random number generator		This value SHOULD be generated using a random number generator
	that is known to have good randomness properties as outlined in		that is known to have good randomness properties as outlined in
	RFC 4086 [RFC4086].		RFC 4086 [RFC4086].
	Probe data		Probe data
	This is a 32-bit field with no fixed meaning. The probe data		This is a 32-bit field with no fixed meaning. The probe data
	field is copied back with no changes. Future flags may define a		field is copied back with no changes. Future flags may define a
	use for this field.		use for this field.
	Discussion: One potential use of this field relates to
	communicating delays between reception of a probe and
	transmission of a reply to it.
	Options		Options
	For future extensions.		For future extensions.
	5.3. Keepalive Timeout Option Format		5.3. Keepalive Timeout Option Format
	Either side of a SHIM6 context can notify the peer of the value that		Either side of a SHIM6 context can notify the peer of the value that
	it would prefer the peer to use as its Keepalive Timeout value. If		it would prefer the peer to use as its Keepalive Timeout value. If
	the host is using a non-default Send Timeout value, it SHOULD		the host is using a non-default Send Timeout value, it SHOULD
	communicate this value as a Keepalive Timeout value to the peer in		communicate this value as a Keepalive Timeout value to the peer in
	skipping to change at page 27, line 9 ¶		skipping to change at page 27, line 9 ¶
	6.10. Graphical Representation of the State Machine		6.10. Graphical Representation of the State Machine
	In the PDF version of this specification, an informational drawing		In the PDF version of this specification, an informational drawing
	illustrates the state machine. Where the text and the drawing		illustrates the state machine. Where the text and the drawing
	differ, the text takes precedence.		differ, the text takes precedence.
	7. Protocol Constants		7. Protocol Constants
	The following protocol constants are defined:		The following protocol constants are defined:
	Send Timeout 10 seconds		Send Timeout 15 seconds
	Keepalive Interval Not specified here		Keepalive Interval X seconds, where X is
	Initial Probe Timeout 0.5 seconds		one third to one half of
	Number of Initial Probes 4 probes		the Keepalive Timeout value
	Max Probe Timeout 60 seconds		(see Section 4.1)
			Initial Probe Timeout 0.5 seconds
			Number of Initial Probes 4 probes
			Max Probe Timeout 60 seconds
	Alternate values of the Send Timeout may be selected by a host and		Alternate values of the Send Timeout may be selected by a host and
	communicated to the peer in the Keepalive Timeout Option.		communicated to the peer in the Keepalive Timeout Option. A very
			small value of Send Timeout may affect the ability to exchange
			keepalives over a path that has a long roundtrip delay. Similarly,
			it may cause SHIM6 to react temporary failures more often than
			necessary. As a result, it is RECOMMENDED that an alternate Send
			Timeout value not be under 10 seconds. Choosing a higher value than
			the one recommended above is also possible, but there is a
			relationship between Send Timeout and the ability of REAP to discover
			and correct errors in the communication path. In any case, in order
			for SHIM6 to be useful, it should detect and repair communication
			problems far before upper layers give up. For this reason, it is
			RECOMMENDED that Send Timeout be at most 100 seconds (default TCP R2
			timeout [RFC1122]).
			Note that it is not expected that the Send Timeout or other values
			need to be estimated based on experienced roundtrip times.
			Signaling exchanges are performed based on exponential backoff.
			The keepalive processes send packets only run in the relatively
			rare condition that all traffic is unidirectional. Finally,
			because Send Timeout is far greater than usual roundtrip times, it
			merely divides the traffic into periods that SHIM6 looks at to
			decide whether to act.
	8. Security Considerations		8. 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 operational. 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
	skipping to change at page 29, line 7 ¶		skipping to change at page 29, line 7 ¶
	send spoofed Keepalive messages once per Send Timeout interval, to		send spoofed Keepalive messages once per Send Timeout interval, to
	prevent two SHIM6 nodes from sending Keepalives themselves. This		prevent two SHIM6 nodes from sending Keepalives themselves. This
	vulnerability is only relevant to nodes involved in a one-way		vulnerability is only relevant to nodes involved in a one-way
	communication. The result of the attack is that the nodes enter the		communication. The result of the attack is that the nodes enter the
	exploration phase needlessly, but they should be able to confirm		exploration phase needlessly, but they should be able to confirm
	connectivity unless, of course, the attacker is able to prevent the		connectivity unless, of course, the attacker is able to prevent the
	exploration phase from completing. Off-path attackers may not be		exploration phase from completing. Off-path attackers may not be
	able to generate spoofed results, given that the context tags are 47-		able to generate spoofed results, given that the context tags are 47-
	bit random numbers.		bit random numbers.
			To protect against spoofed keepalive packets, a host implementing
			both shim6 and IPsec MAY ignore incoming REAP keepalives if it has
			good reason to assume that the other side will be sending IPsec-
			protected return traffic. I.e., if a host is sending TCP data, it
			can reasonably expect to receive TCP ACKs in return. If no IPsec-
			protected ACKs come back but unprotected keepalives do, this could be
			the result from an attacker trying to hide broken connectivity.
	The exploration phase is vulnerable to attackers that are on the		The exploration phase is vulnerable to attackers that are on the
	path. Off-path attackers would find it hard to guess either the		path. Off-path attackers would find it hard to guess either the
	context tag or the correct probe identifiers. Given that IPsec		context tag or the correct probe identifiers. Given that IPsec
	operates above the shim layer, it is not possible to protect the		operates above the shim layer, it is not possible to protect the
	exploration phase against on-path attackers. This is similar to the		exploration phase against on-path attackers. This is similar to the
	ability to protect other Shim6 control exchanges. There are		ability to protect other Shim6 control exchanges. There are
	mechanisms in place to prevent the redirection of communications to		mechanisms in place to prevent the redirection of communications to
	wrong addresses, but on-path attackers can cause denial-of-service,		wrong addresses, but on-path attackers can cause denial-of-service,
	move communications to less-preferred address pairs, and so on.		move communications to less-preferred address pairs, and so on.
	skipping to change at page 31, line 4 ¶		skipping to change at page 30, line 49 ¶
	specification may affect these properties. It is expected that		specification may affect these properties. It is expected that
	further revisions of this specification provide additional		further revisions of this specification provide additional
	information after sufficient deployment experience has been obtained		information after sufficient deployment experience has been obtained
	from different environments.		from different environments.
	Implementations may provide means to monitor their performance and		Implementations may provide means to monitor their performance and
	send alarms about problems. Their standardization is, however,		send alarms about problems. Their standardization is, however,
	subject of future specifications. In general, SHIM6 is most		subject of future specifications. In general, SHIM6 is most
	applicable for small sites and hosts, and it is expected that		applicable for small sites and hosts, and it is expected that
	monitoring requirements on such deployments are relatively modest.		monitoring requirements on such deployments are relatively modest.
			In any case, where the host is associated with a management system,
			it is RECOMMENDED that detected failures and failover events are
			reported via asynchronous notifications to the management system.
			Similarly, where logging mechanisms are available on the host, these
			events should be recorded in event logs.
			SHIM6 uses the same header for both signaling and the encapsulation
			of data packets after a rehoming event. This way, fate is shared
			between the two types of packets, so the situation where reachability
			probes or keepalives can be transmitted successfully, but data
			packets can not, is largely avoided: either all SHIM6 packets make it
			through, so SHIM6 functions as intended, or none do, and no SHIM6
			state is negotiated. Even in the situation where some packets make
			it through and other do not, SHIM6 will generally either work as
			intended or provide a service that is no worse than in the absense of
			SHIM6, apart from the possible generation a a small amount of
			signaling traffic.
			If data packets and possibly data packets encapsulated in the SHIM6
			header do not make it through, but signaling and keepalives do. This
			situation can occur when there is a path MTU discovery black hole on
			one of the paths. If only large packets are sent at some point, then
			reachability exploration will be turned on and REAP will likely
			select another path, which may or may not be affected by the PMTUD
			black hole.
	10. IANA Considerations		10. IANA Considerations
	No IANA actions are required. The number assignments necessary for		No IANA actions are required. The number assignments necessary for
	the messages defined in this document appear together with all the		the messages defined in this document appear together with all the
	other IANA assignments in the main SHIM6 specification		other IANA assignments in the main SHIM6 specification
	[I-D.ietf-shim6-proto].		[I-D.ietf-shim6-proto].
	11. References		11. References
	skipping to change at page 33, line 39 ¶		skipping to change at page 34, line 39 ¶
	[I-D.ietf-shim6-reach-detect]		[I-D.ietf-shim6-reach-detect]
	Beijnum, I., "Shim6 Reachability Detection",		Beijnum, I., "Shim6 Reachability Detection",
	draft-ietf-shim6-reach-detect-01 (work in progress),		draft-ietf-shim6-reach-detect-01 (work in progress),
	October 2005.		October 2005.
	[I-D.ietf-tcpm-icmp-attacks]		[I-D.ietf-tcpm-icmp-attacks]
	Gont, F., "ICMP attacks against TCP",		Gont, F., "ICMP attacks against TCP",
	draft-ietf-tcpm-icmp-attacks-02 (work in progress),		draft-ietf-tcpm-icmp-attacks-02 (work in progress),
	May 2007.		May 2007.
			[RFC1122] Braden, R., "Requirements for Internet Hosts -
			Communication Layers", STD 3, RFC 1122, October 1989.
	[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure		[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
	Neighbor Discovery (SEND)", RFC 3971, March 2005.		Neighbor Discovery (SEND)", RFC 3971, March 2005.
	[RFC4960] Stewart, R., "Stream Control Transmission Protocol",		[RFC4960] Stewart, R., "Stream Control Transmission Protocol",
	RFC 4960, September 2007.		RFC 4960, September 2007.
	Appendix A. Example Protocol Runs		Appendix A. Example Protocol Runs
	This appendix has examples of REAP protocol runs in typical		This appendix has examples of REAP protocol runs in typical
	scenarios. We start with the simplest scenario of two hosts, A and		scenarios. We start with the simplest scenario of two hosts, A and
	skipping to change at page 40, line 10 ¶		skipping to change at page 41, line 10 ¶
	Dawkins, and James Kempf, and HIP WG contributors such as Pekka		Dawkins, and James Kempf, and HIP WG contributors such as Pekka
	Nikander. This draft is also in debt to work done in the context of		Nikander. This draft is also in debt to work done in the context of
	SCTP [RFC4960] and HIP multihoming and mobility extension		SCTP [RFC4960] and HIP multihoming and mobility extension
	[I-D.ietf-hip-mm].		[I-D.ietf-hip-mm].
	Appendix C. Acknowledgements		Appendix C. Acknowledgements
	The authors would also like to thank Christian Huitema, Pekka Savola,		The authors would also like to thank Christian Huitema, Pekka Savola,
	John Loughney, Sam Xia, Hannes Tschofenig, Sebastian Barre, Thomas		John Loughney, Sam Xia, Hannes Tschofenig, Sebastian Barre, Thomas
	Henderson, Matthijs Mekking, Deguang Le, Eric Gray, Dan Romascanu,		Henderson, Matthijs Mekking, Deguang Le, Eric Gray, Dan Romascanu,
	Stephen Kent, and Tim Polk for interesting discussions in this		Stephen Kent, Alberto Garcia, Bernard Aboba, Lars Eggert, and Tim
	problem space, and for review of this specification.		Polk for interesting 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
			IMDEA Networks
			Avda. del Mar Mediterraneo, 22
			Leganes, Madrid 28918
			Spain
	Email: iljitsch@muada.com		Email: iljitsch@muada.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2008).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
End of changes. 27 change blocks.
	62 lines changed or deleted		138 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/