draft-ietf-hip-multihoming-05.txt		draft-ietf-hip-multihoming-06.txt
	Network Working Group T. Henderson, Ed.		Network Working Group T. Henderson, Ed.
	Internet-Draft University of Washington		Internet-Draft University of Washington
	Intended status: Standards Track C. Vogt		Intended status: Standards Track C. Vogt
	Expires: July 16, 2015 J. Arkko		Expires: January 23, 2016 J. Arkko
	Ericsson Research NomadicLab		Ericsson Research NomadicLab
	January 12, 2015		July 22, 2015
	Host Multihoming with the Host Identity Protocol		Host Multihoming with the Host Identity Protocol
	draft-ietf-hip-multihoming-05		draft-ietf-hip-multihoming-06
	Abstract		Abstract
	This document defines host multihoming extensions to the Host		This document defines host multihoming extensions to the Host
	Identity Protocol (HIP), by leveraging protocol components defined		Identity Protocol (HIP), by leveraging protocol components defined
	for host mobility.		for host mobility.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 34		skipping to change at page 1, line 34
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on July 16, 2015.		This Internet-Draft will expire on January 23, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 20		skipping to change at page 2, line 20
	Without obtaining an adequate license from the person(s) controlling		Without obtaining an adequate license from the person(s) controlling
	the copyright in such materials, this document may not be modified		the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may		outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format		not be created outside the IETF Standards Process, except to format
	it for publication as an RFC or to translate it into languages other		it for publication as an RFC or to translate it into languages other
	than English.		than English.
	Table of Contents		Table of Contents
	1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 2		1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 2
	2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4		2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3
	3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 4		3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4		4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
	4.1. Host Multihoming . . . . . . . . . . . . . . . . . . . . 5		4.1. Host Multihoming . . . . . . . . . . . . . . . . . . . . 5
	4.2. Site Multihoming . . . . . . . . . . . . . . . . . . . . 7		4.2. Site Multihoming . . . . . . . . . . . . . . . . . . . . 6
	4.3. Dual host multihoming . . . . . . . . . . . . . . . . . . 7		4.3. Dual host multihoming . . . . . . . . . . . . . . . . . . 7
	4.4. Combined Mobility and Multihoming . . . . . . . . . . . . 8		4.4. Combined Mobility and Multihoming . . . . . . . . . . . . 8
	4.5. Initiating the Protocol in R1 or I2 . . . . . . . . . . . 8		4.5. Initiating the Protocol in R1 or I2 . . . . . . . . . . . 8
	4.6. Using LOCATOR_SETs across Addressing Realms . . . . . . . 10		4.6. Using LOCATOR_SETs across Addressing Realms . . . . . . . 9
	5. Other Considerations . . . . . . . . . . . . . . . . . . . . 10		5. Other Considerations . . . . . . . . . . . . . . . . . . . . 9
	5.1. Address Verification . . . . . . . . . . . . . . . . . . 10		5.1. Address Verification . . . . . . . . . . . . . . . . . . 9
	5.2. Preferred Locator . . . . . . . . . . . . . . . . . . . . 10		5.2. Preferred Locator . . . . . . . . . . . . . . . . . . . . 10
	5.3. Interaction with Security Associations . . . . . . . . . 10		5.3. Interaction with Security Associations . . . . . . . . . 10
	6. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 13		6. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 12
	6.1. Sending LOCATOR_SETs . . . . . . . . . . . . . . . . . . 13		6.1. Sending LOCATOR_SETs . . . . . . . . . . . . . . . . . . 12
	6.2. Handling Received LOCATOR_SETs . . . . . . . . . . . . . 14		6.2. Handling Received LOCATOR_SETs . . . . . . . . . . . . . 14
	6.3. Verifying Address Reachability . . . . . . . . . . . . . 16		6.3. Verifying Address Reachability . . . . . . . . . . . . . 16
	6.4. Changing the Preferred Locator . . . . . . . . . . . . . 17		6.4. Changing the Preferred Locator . . . . . . . . . . . . . 16
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 17		7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	9. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 18		9. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 17
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
	10.1. Normative references . . . . . . . . . . . . . . . . . . 18		10.1. Normative references . . . . . . . . . . . . . . . . . . 17
	10.2. Informative references . . . . . . . . . . . . . . . . . 18		10.2. Informative references . . . . . . . . . . . . . . . . . 18
	Appendix A. Document Revision History . . . . . . . . . . . . . 20		Appendix A. Document Revision History . . . . . . . . . . . . . 19
	1. Introduction and Scope		1. Introduction and Scope
	The Host Identity Protocol [I-D.ietf-hip-rfc4423-bis] (HIP) supports		The Host Identity Protocol [I-D.ietf-hip-rfc4423-bis] (HIP) supports
	an architecture that decouples the transport layer (TCP, UDP, etc.)		an architecture that decouples the transport layer (TCP, UDP, etc.)
	from the internetworking layer (IPv4 and IPv6) by using public/		from the internetworking layer (IPv4 and IPv6) by using public/
	private key pairs, instead of IP addresses, as host identities. When		private key pairs, instead of IP addresses, as host identities. When
	a host uses HIP, the overlying protocol sublayers (e.g., transport		a host uses HIP, the overlying protocol sublayers (e.g., transport
	layer sockets and Encapsulating Security Payload (ESP) Security		layer sockets and Encapsulating Security Payload (ESP) Security
	Associations (SAs)) are instead bound to representations of these		Associations (SAs)) are instead bound to representations of these
	host identities, and the IP addresses are only used for packet		host identities, and the IP addresses are only used for packet
	forwarding. However, each host must also know at least one IP		forwarding. However, each host must also know at least one IP
	address at which its peers are reachable. Initially, these IP		address at which its peers are reachable. Initially, these IP
	addresses are the ones used during the HIP base exchange		addresses are the ones used during the HIP base exchange [RFC7401].
	[I-D.ietf-hip-rfc5201-bis].
	One consequence of such a decoupling is that new solutions to		One consequence of such a decoupling is that new solutions to
	network-layer mobility and host multihoming are possible. Basic host		network-layer mobility and host multihoming are possible. Basic host
	mobility is defined in [I-D.ietf-hip-rfc5206-bis] and covers the case		mobility is defined in [I-D.ietf-hip-rfc5206-bis] and covers the case
	in which a host has a single address and changes its network point-		in which a host has a single address and changes its network point-
	of-attachment while desiring to preserve the HIP-enabled security		of-attachment while desiring to preserve the HIP-enabled security
	association. Host multihoming is somewhat of a dual case to host		association. Host multihoming is somewhat of a dual case to host
	mobility, in that a host may simultaneously have more than one		mobility, in that a host may simultaneously have more than one
	network point-of-attachment. There are potentially many variations		network point-of-attachment. There are potentially many variations
	of host multihoming possible. The scope of this document encompasses		of host multihoming possible. The scope of this document encompasses
	messaging and elements of procedure for some basic host multihoming		messaging and elements of procedure for some basic host multihoming
	scenarios of interest.		scenarios of interest.
	Another variation of multihoming that has been heavily studied is		Another variation of multihoming that has been heavily studied is
	site multihoming. Solutions for site multihoming in IPv6 networks		site multihoming. Solutions for site multihoming in IPv6 networks
	have been specified by the IETF shim6 working group. The shim6		have been specified by the IETF shim6 working group. The shim6
	protocol [RFC5533] bears many architectural similarities to HIP but		protocol [RFC5533] bears many architectural similarities to HIP but
	there are differences in the security model and in the protocol.		there are differences in the security model and in the protocol.
	While HIP can potentially be used with transports other than the ESP		While HIP can potentially be used with transports other than the ESP
	transport format [I-D.ietf-hip-rfc5202-bis], this document largely		transport format [RFC7402], this document largely assumes the use of
	assumes the use of ESP and leaves other transport formats for further		ESP and leaves other transport formats for further study.
	study.
	There are a number of situations where the simple end-to-end		There are a number of situations where the simple end-to-end
	readdressing functionality defined herein is not sufficient. These		readdressing functionality defined herein is not sufficient. These
	include the initial reachability of a multihomed host, location		include the initial reachability of a multihomed host, location
	privacy, simultaneous mobility of both hosts, and some modes of NAT		privacy, simultaneous mobility of both hosts, and some modes of NAT
	traversal. In these situations, there is a need for some helper		traversal. In these situations, there is a need for some helper
	functionality in the network, such as a HIP rendezvous server		functionality in the network, such as a HIP rendezvous server
	[I-D.ietf-hip-rfc5204-bis]. Such functionality is out of the scope		[I-D.ietf-hip-rfc5204-bis]. Such functionality is out of the scope
	of this document. Finally, making underlying IP multihoming		of this document. Finally, making underlying IP multihoming
	transparent to the transport layer has implications on the proper		transparent to the transport layer has implications on the proper
	skipping to change at page 4, line 42		skipping to change at page 4, line 36
	such as which locators to choose when more than one pair is		such as which locators to choose when more than one pair is
	available, the operation of simultaneous mobility and multihoming,		available, the operation of simultaneous mobility and multihoming,
	source address selection policies (beyond those specified in		source address selection policies (beyond those specified in
	[RFC3484]), and the implications of multihoming on transport		[RFC3484]), and the implications of multihoming on transport
	protocols and ESP anti-replay windows.		protocols and ESP anti-replay windows.
	4. Protocol Overview		4. Protocol Overview
	In this section, we briefly introduce a number of usage scenarios for		In this section, we briefly introduce a number of usage scenarios for
	HIP multihoming. These scenarios assume that HIP is being used with		HIP multihoming. These scenarios assume that HIP is being used with
	the ESP transform [I-D.ietf-hip-rfc5202-bis], although other		the ESP transform [RFC7402], although other scenarios may be defined
	scenarios may be defined in the future. To understand these usage		in the future. To understand these usage scenarios, the reader
	scenarios, the reader should be at least minimally familiar with the		should be at least minimally familiar with the HIP protocol
	HIP protocol specification [I-D.ietf-hip-rfc5201-bis]. However, for		specification [RFC7401]. However, for the (relatively) uninitiated
	the (relatively) uninitiated reader, it is most important to keep in		reader, it is most important to keep in mind that in HIP the actual
	mind that in HIP the actual payload traffic is protected with ESP,		payload traffic is protected with ESP, and that the ESP SPI acts as
	and that the ESP SPI acts as an index to the right host-to-host		an index to the right host-to-host context.
	context.
	The scenarios below assume that the two hosts have completed a single		The scenarios below assume that the two hosts have completed a single
	HIP base exchange with each other. Both of the hosts therefore have		HIP base exchange with each other. Both of the hosts therefore have
	one incoming and one outgoing SA. Further, each SA uses the same		one incoming and one outgoing SA. Further, each SA uses the same
	pair of IP addresses, which are the ones used in the base exchange.		pair of IP addresses, which are the ones used in the base exchange.
	The readdressing protocol is an asymmetric protocol where a mobile or		The readdressing protocol is an asymmetric protocol where a mobile or
	multihomed host informs a peer host about changes of IP addresses on		multihomed host informs a peer host about changes of IP addresses on
	affected SPIs. The readdressing exchange is designed to be		affected SPIs. The readdressing exchange is designed to be
	piggybacked on existing HIP exchanges. The majority of the packets		piggybacked on existing HIP exchanges. The majority of the packets
	skipping to change at page 9, line 48		skipping to change at page 9, line 24
	<-----------------------------------		<-----------------------------------
	(process normally)		(process normally)
	Figure 4: LOCATOR_SET Inclusion in I2		Figure 4: LOCATOR_SET Inclusion in I2
	The I1 and I2 may be arriving from different source addresses if the		The I1 and I2 may be arriving from different source addresses if the
	LOCATOR_SET parameter is present in R1. In this case,		LOCATOR_SET parameter is present in R1. In this case,
	implementations simultaneously using multiple pre-created R1s,		implementations simultaneously using multiple pre-created R1s,
	indexed by Initiator IP addresses, may inadvertently fail the puzzle		indexed by Initiator IP addresses, may inadvertently fail the puzzle
	solution of I2 packets due to a perceived puzzle mismatch. See, for		solution of I2 packets due to a perceived puzzle mismatch. See, for
	instance, the example in Appendix A of [I-D.ietf-hip-rfc5201-bis].		instance, the example in Appendix A of [RFC7401]. As a solution, the
	As a solution, the Responder's puzzle indexing mechanism must be		Responder's puzzle indexing mechanism must be flexible enough to
	flexible enough to accommodate the situation when R1 includes a		accommodate the situation when R1 includes a LOCATOR_SET parameter.
	LOCATOR_SET parameter.
	4.6. Using LOCATOR_SETs across Addressing Realms		4.6. Using LOCATOR_SETs across Addressing Realms
	It is possible for HIP associations to migrate to a state in which		It is possible for HIP associations to migrate to a state in which
	both parties are only using locators in different addressing realms.		both parties are only using locators in different addressing realms.
	For example, the two hosts may initiate the HIP association when both		For example, the two hosts may initiate the HIP association when both
	are using IPv6 locators, then one host may loose its IPv6		are using IPv6 locators, then one host may loose its IPv6
	connectivity and obtain an IPv4 address. In such a case, some type		connectivity and obtain an IPv4 address. In such a case, some type
	of mechanism for interworking between the different realms must be		of mechanism for interworking between the different realms must be
	employed; such techniques are outside the scope of the present text.		employed; such techniques are outside the scope of the present text.
	skipping to change at page 11, line 6		skipping to change at page 10, line 31
	5.3. Interaction with Security Associations		5.3. Interaction with Security Associations
	This document uses the HIP LOCATOR_SET protocol parameter, specified		This document uses the HIP LOCATOR_SET protocol parameter, specified
	in [I-D.ietf-hip-rfc5206-bis]), that allows the hosts to exchange		in [I-D.ietf-hip-rfc5206-bis]), that allows the hosts to exchange
	information about their locator(s) and any changes in their		information about their locator(s) and any changes in their
	locator(s). The logical structure created with LOCATOR_SET		locator(s). The logical structure created with LOCATOR_SET
	parameters has three levels: hosts, Security Associations (SAs)		parameters has three levels: hosts, Security Associations (SAs)
	indexed by Security Parameter Indices (SPIs), and addresses.		indexed by Security Parameter Indices (SPIs), and addresses.
	The relation between these levels for an association constructed as		The relation between these levels for an association constructed as
	defined in the base specification [I-D.ietf-hip-rfc5201-bis] and ESP		defined in the base specification [RFC7401] and ESP transform
	transform [I-D.ietf-hip-rfc5202-bis] is illustrated in Figure 5.		[RFC7402] is illustrated in Figure 5.
	-<- SPI1a -- -- SPI2a ->-		-<- SPI1a -- -- SPI2a ->-
	host1 < > addr1a <---> addr2a < > host2		host1 < > addr1a <---> addr2a < > host2
	->- SPI2a -- -- SPI1a -<-		->- SPI2a -- -- SPI1a -<-
	Figure 5: Relation between Hosts, SPIs, and Addresses (Base		Figure 5: Relation between Hosts, SPIs, and Addresses (Base
	Specification)		Specification)
	In Figure 5, host1 and host2 negotiate two unidirectional SAs, and		In Figure 5, host1 and host2 negotiate two unidirectional SAs, and
	each host selects the SPI value for its inbound SA. The addresses		each host selects the SPI value for its inbound SA. The addresses
	skipping to change at page 18, line 25		skipping to change at page 17, line 47
	of the security section, and Petri Jokela was a co-author of the		of the security section, and Petri Jokela was a co-author of the
	initial individual submission.		initial individual submission.
	The authors thank Miika Komu, Mika Kousa, Jeff Ahrenholz, and Jan		The authors thank Miika Komu, Mika Kousa, Jeff Ahrenholz, and Jan
	Melen for many improvements to the document.		Melen for many improvements to the document.
	10. References		10. References
	10.1. Normative references		10.1. Normative references
	[I-D.ietf-hip-rfc5201-bis]
	Moskowitz, R., Heer, T., Jokela, P., and T. Henderson,
	"Host Identity Protocol Version 2 (HIPv2)", draft-ietf-
	hip-rfc5201-bis-20 (work in progress), October 2014.
	[I-D.ietf-hip-rfc5202-bis]
	Jokela, P., Moskowitz, R., and J. Melen, "Using the
	Encapsulating Security Payload (ESP) Transport Format with
	the Host Identity Protocol (HIP)", draft-ietf-hip-
	rfc5202-bis-07 (work in progress), September 2014.
	[I-D.ietf-hip-rfc5206-bis]		[I-D.ietf-hip-rfc5206-bis]
	Henderson, T., Vogt, C., and J. Arkko, "Host Mobility with		Henderson, T., Vogt, C., and J. Arkko, "Host Mobility with
	the Host Identity Protocol", draft-ietf-hip-rfc5206-bis-07		the Host Identity Protocol", draft-ietf-hip-rfc5206-bis-09
	(work in progress), December 2014.		(work in progress), July 2015.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
			RFC2119, March 1997,
			<http://www.rfc-editor.org/info/rfc2119>.
	[RFC3484] Draves, R., "Default Address Selection for Internet		[RFC3484] Draves, R., "Default Address Selection for Internet
	Protocol version 6 (IPv6)", RFC 3484, February 2003.		Protocol version 6 (IPv6)", RFC 3484, DOI 10.17487/
			RFC3484, February 2003,
			<http://www.rfc-editor.org/info/rfc3484>.
			[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
			Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC
			7401, DOI 10.17487/RFC7401, April 2015,
			<http://www.rfc-editor.org/info/rfc7401>.
			[RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the
			Encapsulating Security Payload (ESP) Transport Format with
			the Host Identity Protocol (HIP)", RFC 7402, DOI 10.17487/
			RFC7402, April 2015,
			<http://www.rfc-editor.org/info/rfc7402>.
	10.2. Informative references		10.2. Informative references
	[I-D.ietf-hip-rfc4423-bis]		[I-D.ietf-hip-rfc4423-bis]
	Moskowitz, R. and M. Komu, "Host Identity Protocol		Moskowitz, R. and M. Komu, "Host Identity Protocol
	Architecture", draft-ietf-hip-rfc4423-bis-09 (work in		Architecture", draft-ietf-hip-rfc4423-bis-12 (work in
	progress), October 2014.		progress), June 2015.
	[I-D.ietf-hip-rfc5204-bis]		[I-D.ietf-hip-rfc5204-bis]
	Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)		Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
	Rendezvous Extension", draft-ietf-hip-rfc5204-bis-05 (work		Rendezvous Extension", draft-ietf-hip-rfc5204-bis-06 (work
	in progress), December 2014.		in progress), June 2015.
	[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming		[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
	Shim Protocol for IPv6", RFC 5533, June 2009.		Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533,
			June 2009, <http://www.rfc-editor.org/info/rfc5533>.
	Appendix A. Document Revision History		Appendix A. Document Revision History
	To be removed upon publication		To be removed upon publication
	+----------+--------------------------------------------------------+		+----------+--------------------------------------------------------+
	| Revision | Comments |		| Revision | Comments |
	+----------+--------------------------------------------------------+		+----------+--------------------------------------------------------+
	| draft-00 | Initial version with multihoming text imported from |		| draft-00 | Initial version with multihoming text imported from |
	| | RFC5206. |		| | RFC5206. |
End of changes. 23 change blocks.
	56 lines changed or deleted		57 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/