draft-ietf-shim6-failure-detection-12.txt		faildet.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: December 8, 2008 IMDEA Networks		Expires: February 2, 2009 IMDEA Networks
	June 6, 2008		August 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-12		draft-ietf-shim6-failure-detection-14
	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 December 8, 2008.		This Internet-Draft will expire on February 2, 2009.
	Abstract		Abstract
	This document specifies how the level 3 multihoming shim protocol		This document specifies how the level 3 multihoming shim protocol
	(SHIM6) detects failures between two communicating hosts. It also		(SHIM6) detects failures between two communicating hosts. It also
	specifies an exploration protocol for switching to another pair of		specifies an exploration protocol for switching to another pair of
	interfaces and/or addresses between the same hosts if a failure		interfaces and/or addresses between the same hosts if a failure
	occurs and an operational pair can be found.		occurs and an operational pair can be found.
	Table of Contents		Table of Contents
	skipping to change at page 3, line 19		skipping to change at page 3, line 19
	3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7		3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.1. Available Addresses . . . . . . . . . . . . . . . . . . 7		3.1. Available Addresses . . . . . . . . . . . . . . . . . . 7
	3.2. Locally Operational Addresses . . . . . . . . . . . . . 8		3.2. Locally Operational Addresses . . . . . . . . . . . . . 8
	3.3. Operational Address Pairs . . . . . . . . . . . . . . . 8		3.3. Operational Address Pairs . . . . . . . . . . . . . . . 8
	3.4. Primary Address Pair . . . . . . . . . . . . . . . . . . 10		3.4. Primary Address Pair . . . . . . . . . . . . . . . . . . 10
	3.5. Current Address Pair . . . . . . . . . . . . . . . . . . 10		3.5. Current Address Pair . . . . . . . . . . . . . . . . . . 10
	4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 11		4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 11
	4.1. Failure Detection . . . . . . . . . . . . . . . . . . . 11		4.1. Failure Detection . . . . . . . . . . . . . . . . . . . 11
	4.2. Full Reachability Exploration . . . . . . . . . . . . . 13		4.2. Full Reachability Exploration . . . . . . . . . . . . . 13
	4.3. Exploration Order . . . . . . . . . . . . . . . . . . . 14		4.3. Exploration Order . . . . . . . . . . . . . . . . . . . 14
	5. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 16		5. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 17
	5.1. Keepalive Message . . . . . . . . . . . . . . . . . . . 16		5.1. Keepalive Message . . . . . . . . . . . . . . . . . . . 17
	5.2. Probe Message . . . . . . . . . . . . . . . . . . . . . 17		5.2. Probe Message . . . . . . . . . . . . . . . . . . . . . 18
	5.3. Keepalive Timeout Option Format . . . . . . . . . . . . 21		5.3. Keepalive Timeout Option Format . . . . . . . . . . . . 22
	6. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . 23		6. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . 24
	6.1. Incoming payload packet . . . . . . . . . . . . . . . . 23		6.1. Incoming payload packet . . . . . . . . . . . . . . . . 24
	6.2. Outgoing payload packet . . . . . . . . . . . . . . . . 24		6.2. Outgoing payload packet . . . . . . . . . . . . . . . . 25
	6.3. Keepalive timeout . . . . . . . . . . . . . . . . . . . 24		6.3. Keepalive timeout . . . . . . . . . . . . . . . . . . . 25
	6.4. Send timeout . . . . . . . . . . . . . . . . . . . . . . 25		6.4. Send timeout . . . . . . . . . . . . . . . . . . . . . . 26
	6.5. Retransmission . . . . . . . . . . . . . . . . . . . . . 25		6.5. Retransmission . . . . . . . . . . . . . . . . . . . . . 26
	6.6. Reception of the Keepalive message . . . . . . . . . . . 25		6.6. Reception of the Keepalive message . . . . . . . . . . . 26
	6.7. Reception of the Probe message State=Exploring . . . . . 26		6.7. Reception of the Probe message State=Exploring . . . . . 27
	6.8. Reception of the Probe message State=InboundOk . . . . . 26		6.8. Reception of the Probe message State=InboundOk . . . . . 27
	6.9. Reception of the Probe message State=Operational . . . . 26		6.9. Reception of the Probe message State=Operational . . . . 27
	6.10. Graphical Representation of the State Machine . . . . . 27		6.10. Graphical Representation of the State Machine . . . . . 28
	7. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 28		7. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 29
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 29		8. Security Considerations . . . . . . . . . . . . . . . . . . . 30
	9. Operational Considerations . . . . . . . . . . . . . . . . . . 31		9. Operational Considerations . . . . . . . . . . . . . . . . . . 32
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
	11.1. Normative References . . . . . . . . . . . . . . . . . . 34		11.1. Normative References . . . . . . . . . . . . . . . . . . 35
	11.2. Informative References . . . . . . . . . . . . . . . . . 34		11.2. Informative References . . . . . . . . . . . . . . . . . 35
	Appendix A. Example Protocol Runs . . . . . . . . . . . . . . . . 36		Appendix A. Example Protocol Runs . . . . . . . . . . . . . . . . 38
	Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 41		Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 43
	Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 42		Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 44
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45
	Intellectual Property and Copyright Statements . . . . . . . . . . 44		Intellectual Property and Copyright Statements . . . . . . . . . . 46
	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.
	skipping to change at page 9, line 17		skipping to change at page 9, line 17
	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 reaches the		the source and the second address as the destination reaches 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 reachability 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 additional		specification. Future extensions of SHIM6 may specify additional
	mechanisms. Some ideas of such mechanisms are listed below, but not		mechanisms. Some ideas of such mechanisms are listed below, but not
	fully specified in this document:		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
	skipping to change at page 9, line 39		skipping to change at page 9, line 39
	that the messages sent using the first address pair have been		that the messages sent using the first address pair have been
	received.		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 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. One
	suggestion is to use ICMP error messages only as a hint to perform		approach would be to use ICMP error messages only as a hint to
	an explicit reachability test or move an address pair to a lower		perform an explicit reachability test or move an address pair to a
	place in the list of address pairs to be probed, but not as a		lower place in the list of address pairs to be probed, but not as
	reason to disrupt ongoing communications without other indications		a reason to disrupt ongoing communications without other
	of problems. The situation may be different when certain		indications of problems. The situation may be different when
	verifications of the ICMP messages are being performed, as		certain verifications of the ICMP messages are being performed, as
	explained by Gont in [I-D.ietf-tcpm-icmp-attacks]. These		explained by Gont in [I-D.ietf-tcpm-icmp-attacks]. These
	verifications can ensure that (practically) only on-path attackers		verifications can ensure that (practically) only on-path attackers
	can spoof the messages.		can spoof the messages.
	3.4. Primary Address Pair		3.4. Primary Address Pair
	The primary address pair consists of the addresses that upper layer		The primary address pair consists of the addresses that upper layer
	protocols use in their interaction with the SHIM6 layer. Use of the		protocols use in their interaction with the SHIM6 layer. Use of the
	primary address pair means that the communication is compatible with		primary address pair means that the communication is compatible with
	regular non-SHIM6 communication and no context ID needs to be		regular non-SHIM6 communication and no context ID needs to be
	skipping to change at page 14, line 32		skipping to change at page 14, line 32
	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
	The exploration process assumes an ability to choose address pairs		The exploration process assumes an ability to choose address pairs
	for testing, in some sequence. This process may result in a		for testing. An overview of the choosing process used by REAP is as
	combinatorial explosion when there are many addresses on both sides,		follows:
	but a back-off procedure is employed to avoid a "signaling storm".
	Nodes first consult the RFC 3484 default address selection rules		o As an input to start the process, the node has knowledge of its
	[RFC3484] to determine what combinations of addresses are allowed		own addresses and has been told via SHIM6 protocol messages what
	from a local point of view, as this reduces the search space. RFC		the addresses of the peer are. A list of possible pairs of
	3484 also provides a priority ordering among different address pairs,		addresses can be constructed by combining the two pieces of
	making the search possibly faster. (Additional mechanisms may be		information.
	defined in the future for arriving at an initial ordering of address
	pairs before testing starts [I-D.ietf-shim6-locator-pair-selection].)		o By employing standard IPv6 address selection rules, the list is
	Nodes may also use local information, such as known quality of		pruned by removing combinations that are inappropriate, such as
	service parameters or interface types to determine what addresses are		attempting to use a link local address when contacting a peer that
	preferred over others, and try pairs containing such addresses first.		uses an off-link global unicast address.
	The SHIM6 protocol also carries preference information in its
	messages.		o Similarly, standard IPv6 address selection rules provide a basic
			priority order for the pairs.
			o Local preferences may be applied for some additional tuning of the
			order in the list. The mechanisms for local preference settings
			are not specified, but can involve, for instance, configuration
			that sets the preference for using one interface over another.
			o As a result, the node has a prioritized list of address pairs to
			try. However, the list may still be long, as there may be a
			combinatorial explosion when there are many addresses on both
			sides. REAP employs these pairs sequentially, however, and uses a
			back-off procedure is to avoid a "signaling storm". This ensures
			that the exploration process is relatively conservative or "safe".
			The tradeoff is that finding a working path may take time if there
			are many addresses on both sides.
			In more detail, the process is as follows. Nodes first consult the
			RFC 3484 default address selection rules [RFC3484] to determine what
			combinations of addresses are allowed from a local point of view, as
			this reduces the search space. RFC 3484 also provides a priority
			ordering among different address pairs, making the search possibly
			faster. (Additional mechanisms may be defined in the future for
			arriving at an initial ordering of address pairs before testing
			starts [I-D.ietf-shim6-locator-pair-selection].) Nodes may also use
			local information, such as known quality of service parameters or
			interface types to determine what addresses are preferred over
			others, and try pairs containing such addresses first. The SHIM6
			protocol also carries preference information in its 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
	skipping to change at page 35, line 5		skipping to change at page 36, line 5
	environments", draft-bagnulo-shim6-addr-selection-00 (work		environments", draft-bagnulo-shim6-addr-selection-00 (work
	in progress), October 2005.		in progress), October 2005.
	[I-D.huitema-multi6-addr-selection]		[I-D.huitema-multi6-addr-selection]
	Huitema, C., "Address selection in multihomed		Huitema, C., "Address selection in multihomed
	environments", draft-huitema-multi6-addr-selection-00		environments", draft-huitema-multi6-addr-selection-00
	(work in progress), October 2004.		(work in progress), October 2004.
	[I-D.ietf-bfd-base]		[I-D.ietf-bfd-base]
	Katz, D. and D. Ward, "Bidirectional Forwarding		Katz, D. and D. Ward, "Bidirectional Forwarding
	Detection", draft-ietf-bfd-base-06 (work in progress),		Detection", draft-ietf-bfd-base-08 (work in progress),
	March 2007.		March 2008.
	[I-D.ietf-dna-cpl]		[I-D.ietf-dna-cpl]
	Nordmark, E. and J. Choi, "DNA with unmodified routers:		Nordmark, E. and J. Choi, "DNA with unmodified routers:
	Prefix list based approach", draft-ietf-dna-cpl-02 (work		Prefix list based approach", draft-ietf-dna-cpl-02 (work
	in progress), January 2006.		in progress), January 2006.
	[I-D.ietf-dna-protocol]		[I-D.ietf-dna-protocol]
	Kempf, J., "Detecting Network Attachment in IPv6 Networks		Narayanan, S., Kempf, J., Nordmark, E., Pentland, B.,
	(DNAv6)", draft-ietf-dna-protocol-06 (work in progress),		Choi, J., Daley, G., and N. Montavont, "Detecting Network
	June 2007.		Attachment in IPv6 Networks (DNAv6)",
			draft-ietf-dna-protocol-07 (work in progress),
			February 2008.
	[I-D.ietf-hip-mm]		[I-D.ietf-hip-mm]
	Henderson, T., "End-Host Mobility and Multihoming with the		Henderson, T., "End-Host Mobility and Multihoming with the
	Host Identity Protocol", draft-ietf-hip-mm-05 (work in		Host Identity Protocol", draft-ietf-hip-mm-05 (work in
	progress), March 2007.		progress), March 2007.
	[I-D.ietf-shim6-locator-pair-selection]		[I-D.ietf-shim6-locator-pair-selection]
	Bagnulo, M., "Default Locator-pair selection algorithm for		Bagnulo, M., "Default Locator-pair selection algorithm for
	the SHIM6 protocol",		the SHIM6 protocol",
	draft-ietf-shim6-locator-pair-selection-02 (work in		draft-ietf-shim6-locator-pair-selection-03 (work in
	progress), July 2007.		progress), February 2008.
	[I-D.ietf-shim6-proto]		[I-D.ietf-shim6-proto]
	Bagnulo, M. and E. Nordmark, "Shim6: Level 3 Multihoming		Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
	Shim Protocol for IPv6", draft-ietf-shim6-proto-09 (work		Shim Protocol for IPv6", draft-ietf-shim6-proto-10 (work
	in progress), November 2007.		in progress), February 2008.
	[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-03 (work in progress),
	May 2007.		March 2008.
	[RFC1122] Braden, R., "Requirements for Internet Hosts -		[RFC1122] Braden, R., "Requirements for Internet Hosts -
	Communication Layers", STD 3, RFC 1122, October 1989.		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.
End of changes. 13 change blocks.
	66 lines changed or deleted		95 lines changed or added
This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/