draft-ietf-hip-multihoming-06.txt		draft-ietf-hip-multihoming-07.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: January 23, 2016 J. Arkko		Expires: August 3, 2016 J. Arkko
	Ericsson Research NomadicLab		Ericsson Research NomadicLab
	July 22, 2015		January 31, 2016
	Host Multihoming with the Host Identity Protocol		Host Multihoming with the Host Identity Protocol
	draft-ietf-hip-multihoming-06		draft-ietf-hip-multihoming-07
	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 January 23, 2016.		This Internet-Draft will expire on August 3, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2016 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 26		skipping to change at page 2, line 26
	Table of Contents		Table of Contents
	1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 2		1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 2
	2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3		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 . . . . . . . . . . . . . . . . . . . . 6		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 . . . . . . . . . . . . 7
	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 . . . . . . . 9		4.6. Using LOCATOR_SETs across Addressing Realms . . . . . . . 9
	5. Other Considerations . . . . . . . . . . . . . . . . . . . . 9		5. Other Considerations . . . . . . . . . . . . . . . . . . . . 9
	5.1. Address Verification . . . . . . . . . . . . . . . . . . 9		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 . . . . . . . . . . . . . . . . . . . . . . 12		6. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 12
	6.1. Sending LOCATOR_SETs . . . . . . . . . . . . . . . . . . 12		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 . . . . . . . . . . . . . 16		6.4. Changing the Preferred Locator . . . . . . . . . . . . . 16
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 17		7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	9. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 17		9. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 17
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
	10.1. Normative references . . . . . . . . . . . . . . . . . . 17		10.1. Normative references . . . . . . . . . . . . . . . . . . 17
	10.2. Informative references . . . . . . . . . . . . . . . . . 18		10.2. Informative references . . . . . . . . . . . . . . . . . 18
	Appendix A. Document Revision History . . . . . . . . . . . . . 19		Appendix A. Document Revision History . . . . . . . . . . . . . 19
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 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 [RFC7401] (HIP) supports an architecture
	an architecture that decouples the transport layer (TCP, UDP, etc.)		that decouples the transport layer (TCP, UDP, etc.) from the
	from the internetworking layer (IPv4 and IPv6) by using public/		internetworking layer (IPv4 and IPv6) by using public/private key
	private key pairs, instead of IP addresses, as host identities. When		pairs, instead of IP addresses, as host identities. When a host uses
	a host uses HIP, the overlying protocol sublayers (e.g., transport		HIP, the overlying protocol sublayers (e.g., transport layer sockets
	layer sockets and Encapsulating Security Payload (ESP) Security		and Encapsulating Security Payload (ESP) Security Associations (SAs))
	Associations (SAs)) are instead bound to representations of these		are instead bound to representations of these host identities, and
	host identities, and the IP addresses are only used for packet		the IP addresses are only used for packet forwarding. However, each
	forwarding. However, each host must also know at least one IP		host must also know at least one IP address at which its peers are
	address at which its peers are reachable. Initially, these IP		reachable. Initially, these IP addresses are the ones used during
	addresses are the ones used during the HIP base exchange [RFC7401].		the HIP base exchange.
	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
	skipping to change at page 3, line 33		skipping to change at page 3, line 34
	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 [RFC7402], this document largely assumes the use of		transport format [RFC7402], this document largely assumes the use of
	ESP and leaves other transport formats for further study.		ESP and leaves other transport formats for further study.
	There are a number of situations where the simple end-to-end		Finally, making underlying IP multihoming transparent to the
	readdressing functionality defined herein is not sufficient. These		transport layer has implications on the proper response of transport
	include the initial reachability of a multihomed host, location		congestion control, path MTU selection, and Quality of Service (QoS).
	privacy, simultaneous mobility of both hosts, and some modes of NAT		Transport-layer mobility triggers, and the proper transport response
	traversal. In these situations, there is a need for some helper		to a HIP multihoming address change, are outside the scope of this
	functionality in the network, such as a HIP rendezvous server		document.
	[I-D.ietf-hip-rfc5204-bis]. Such functionality is out of the scope
	of this document. Finally, making underlying IP multihoming
	transparent to the transport layer has implications on the proper
	response of transport congestion control, path MTU selection, and
	Quality of Service (QoS). Transport-layer mobility triggers, and the
	proper transport response to a HIP multihoming address change, are
	outside the scope of this document.
	2. Terminology and Conventions		2. Terminology and Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	The following terms used in this document are defined in		The following terms used in this document are defined in
	[I-D.ietf-hip-rfc5206-bis]: LOCATOR_SET, Locator, Address, Preferred		[I-D.ietf-hip-rfc5206-bis]: LOCATOR_SET, Locator, Address, Preferred
	locator, and Credit Based Authorization.		locator, and Credit Based Authorization.
	skipping to change at page 18, line 6		skipping to change at page 18, line 6
	10. References		10. References
	10.1. Normative references		10.1. Normative references
	[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-09		the Host Identity Protocol", draft-ietf-hip-rfc5206-bis-09
	(work in progress), July 2015.		(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, DOI 10.17487/		Requirement Levels", BCP 14, RFC 2119,
	RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<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, DOI 10.17487/		Protocol version 6 (IPv6)", RFC 3484,
	RFC3484, February 2003,		DOI 10.17487/RFC3484, February 2003,
	<http://www.rfc-editor.org/info/rfc3484>.		<http://www.rfc-editor.org/info/rfc3484>.
	[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.		[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
	Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC		Henderson, "Host Identity Protocol Version 2 (HIPv2)",
	7401, DOI 10.17487/RFC7401, April 2015,		RFC 7401, DOI 10.17487/RFC7401, April 2015,
	<http://www.rfc-editor.org/info/rfc7401>.		<http://www.rfc-editor.org/info/rfc7401>.
	[RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the		[RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the
	Encapsulating Security Payload (ESP) Transport Format with		Encapsulating Security Payload (ESP) Transport Format with
	the Host Identity Protocol (HIP)", RFC 7402, DOI 10.17487/		the Host Identity Protocol (HIP)", RFC 7402,
	RFC7402, April 2015,		DOI 10.17487/RFC7402, April 2015,
	<http://www.rfc-editor.org/info/rfc7402>.		<http://www.rfc-editor.org/info/rfc7402>.
	10.2. Informative references		10.2. Informative references
	[I-D.ietf-hip-rfc4423-bis]
	Moskowitz, R. and M. Komu, "Host Identity Protocol
	Architecture", draft-ietf-hip-rfc4423-bis-12 (work in
	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-06 (work		Rendezvous Extension", draft-ietf-hip-rfc5204-bis-07 (work
	in progress), June 2015.		in progress), December 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, DOI 10.17487/RFC5533,		Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533,
	June 2009, <http://www.rfc-editor.org/info/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
	+----------+--------------------------------------------------------+		+----------+--------------------------------------------------------+
	skipping to change at page 19, line 28		skipping to change at page 19, line 28
	| | |		| | |
	| draft-03 | Document refresh; no other changes. |		| draft-03 | Document refresh; no other changes. |
	| | |		| | |
	| draft-04 | Document refresh; no other changes. |		| draft-04 | Document refresh; no other changes. |
	| | |		| | |
	| draft-05 | Move remaining multihoming material from RFC5206-bis |		| draft-05 | Move remaining multihoming material from RFC5206-bis |
	| | to this document |		| | to this document |
	| | |		| | |
	| | Update lingering references to LOCATOR parameter to |		| | Update lingering references to LOCATOR parameter to |
	| | LOCATOR_SET |		| | LOCATOR_SET |
			| | |
			| draft-06 | Document refresh with updated references. |
			| | |
			| draft-07 | Document refresh; no other changes. |
	+----------+--------------------------------------------------------+		+----------+--------------------------------------------------------+
	Authors' Addresses		Authors' Addresses
	Thomas R. Henderson (editor)		Thomas R. Henderson (editor)
	University of Washington		University of Washington
	Campus Box 352500		Campus Box 352500
	Seattle, WA		Seattle, WA
	USA		USA
End of changes. 16 change blocks.
	45 lines changed or deleted		38 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/