draft-ietf-hip-multihoming-08.txt		draft-ietf-hip-multihoming-09.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: October 9, 2016 J. Arkko		Expires: December 2, 2016 Independent
	Ericsson Research NomadicLab		J. Arkko
	April 7, 2016		Ericsson
			May 31, 2016
	Host Multihoming with the Host Identity Protocol		Host Multihoming with the Host Identity Protocol
	draft-ietf-hip-multihoming-08		draft-ietf-hip-multihoming-09
	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 35 ¶
	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 October 9, 2016.		This Internet-Draft will expire on December 2, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	This document may contain material from IETF Documents or IETF
	Contributions published or made publicly available before November
	10, 2008. The person(s) controlling the copyright in some of this
	material may not have granted the IETF Trust the right to allow
	modifications of such material outside the IETF Standards Process.
	Without obtaining an adequate license from the person(s) controlling
	the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format
	it for publication as an RFC or to translate it into languages other
	than English.
	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 . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4		4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
	4.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4		4.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4
	4.2. Multiple Addresses . . . . . . . . . . . . . . . . . . . 6		4.2. Multiple Addresses . . . . . . . . . . . . . . . . . . . 5
	4.3. Multiple Security Associations . . . . . . . . . . . . . 6		4.3. Multiple Security Associations . . . . . . . . . . . . . 6
	4.4. Host Multihoming for Fault Tolerance . . . . . . . . . . 7		4.4. Host Multihoming for Fault Tolerance . . . . . . . . . . 7
	4.5. Host Multihoming for Load Balancing . . . . . . . . . . . 8		4.5. Host Multihoming for Load Balancing . . . . . . . . . . . 8
	4.6. Site Multihoming . . . . . . . . . . . . . . . . . . . . 9		4.6. Site Multihoming . . . . . . . . . . . . . . . . . . . . 9
	4.7. Dual Host Multihoming . . . . . . . . . . . . . . . . . . 10		4.7. Dual Host Multihoming . . . . . . . . . . . . . . . . . . 10
	4.8. Combined Mobility and Multihoming . . . . . . . . . . . . 11		4.8. Combined Mobility and Multihoming . . . . . . . . . . . . 10
	4.9. Initiating the Protocol in R1, I2, or R2 . . . . . . . . 11		4.9. Initiating the Protocol in R1, I2, or R2 . . . . . . . . 11
	4.10. Using LOCATOR_SETs across Addressing Realms . . . . . . . 12		4.10. Using LOCATOR_SETs across Addressing Realms . . . . . . . 12
	4.11. Interaction with Security Associations . . . . . . . . . 13		4.11. Interaction with Security Associations . . . . . . . . . 13
	5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 13		5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 13
	5.1. Sending LOCATOR_SETs . . . . . . . . . . . . . . . . . . 13		5.1. Sending LOCATOR_SETs . . . . . . . . . . . . . . . . . . 13
	5.2. Handling Received LOCATOR_SETs . . . . . . . . . . . . . 15		5.2. Handling Received LOCATOR_SETs . . . . . . . . . . . . . 15
	5.3. Verifying Address Reachability . . . . . . . . . . . . . 17		5.3. Verifying Address Reachability . . . . . . . . . . . . . 17
	5.4. Changing the Preferred Locator . . . . . . . . . . . . . 18		5.4. Changing the Preferred Locator . . . . . . . . . . . . . 17
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 18		6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	8. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 19		8. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 18
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
	9.1. Normative references . . . . . . . . . . . . . . . . . . 19		9.1. Normative references . . . . . . . . . . . . . . . . . . 19
	9.2. Informative references . . . . . . . . . . . . . . . . . 20		9.2. Informative references . . . . . . . . . . . . . . . . . 19
	Appendix A. Document Revision History . . . . . . . . . . . . . 21		Appendix A. Document Revision History . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
	1. Introduction and Scope		1. Introduction and Scope
	The Host Identity Protocol [RFC7401] (HIP) supports an architecture		The Host Identity Protocol [RFC7401] (HIP) supports an architecture
	that decouples the transport layer (TCP, UDP, etc.) from the		that decouples the transport layer (TCP, UDP, etc.) from the
	internetworking layer (IPv4 and IPv6) by using public/private key		internetworking layer (IPv4 and IPv6) by using public/private key
	pairs, instead of IP addresses, as host identities. When a host uses		pairs, instead of IP addresses, as host identities. When a host uses
	HIP, the overlying protocol sublayers (e.g., transport layer sockets		HIP, the overlying protocol sublayers (e.g., transport layer sockets
	and Encapsulating Security Payload (ESP) Security Associations (SAs))		and Encapsulating Security Payload (ESP) Security Associations (SAs))
	are instead bound to representations of these host identities, and		are instead bound to representations of these host identities, and
	skipping to change at page 4, line 28 ¶		skipping to change at page 4, line 20 ¶
	LOCATOR_SET parameter defined in [I-D.ietf-hip-rfc5206-bis], a host		LOCATOR_SET parameter defined in [I-D.ietf-hip-rfc5206-bis], a host
	can inform its peers of additional (multiple) locators at which it		can inform its peers of additional (multiple) locators at which it
	can be reached. When multiple locators are available and announced		can be reached. When multiple locators are available and announced
	to the peer, a host can designate a particular locator as a		to the peer, a host can designate a particular locator as a
	"preferred" locator, meaning that the host prefers that its peer send		"preferred" locator, meaning that the host prefers that its peer send
	packets to the designated address before trying an alternative		packets to the designated address before trying an alternative
	address. Although this document defines a basic mechanism for		address. Although this document defines a basic mechanism for
	multihoming, it does not define all possible policies and procedures,		multihoming, it does not define all possible policies and procedures,
	such as which locators to choose when more than one is available, the		such as which locators to choose when more than one is available, the
	operation of simultaneous mobility and multihoming, source address		operation of simultaneous mobility and multihoming, source address
	selection policies (beyond those specified in [RFC3484]), and the		selection policies (beyond those specified in [RFC6724]), and the
	implications of multihoming on transport protocols.		implications of multihoming on transport protocols.
	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 [RFC7402], although other scenarios may be defined		the ESP transform [RFC7402], although other scenarios may be defined
	in the future. To understand these usage scenarios, the reader		in the future. To understand these usage scenarios, the reader
	should be at least minimally familiar with the HIP protocol		should be at least minimally familiar with the HIP protocol
	specification [RFC7401], the use of the ESP transport format		specification [RFC7401], the use of the ESP transport format
	skipping to change at page 19, line 25 ¶		skipping to change at page 19, line 13 ¶
	Melen for many improvements to the document. Concepts from a paper		Melen for many improvements to the document. Concepts from a paper
	on host multihoming across address families, by Samu Varjonen, Miika		on host multihoming across address families, by Samu Varjonen, Miika
	Komu, and Andrei Gurtov, contributed to this revised version.		Komu, and Andrei Gurtov, contributed to this revised version.
	9. References		9. References
	9.1. Normative references		9.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-10		the Host Identity Protocol", draft-ietf-hip-rfc5206-bis-11
	(work in progress), January 2016.		(work in progress), May 2016.
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/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		[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
	Protocol version 6 (IPv6)", RFC 3484,		"Default Address Selection for Internet Protocol Version 6
	DOI 10.17487/RFC3484, February 2003,		(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
	<http://www.rfc-editor.org/info/rfc3484>.		<http://www.rfc-editor.org/info/rfc6724>.
	[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)",		Henderson, "Host Identity Protocol Version 2 (HIPv2)",
	RFC 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,		the Host Identity Protocol (HIP)", RFC 7402,
	DOI 10.17487/RFC7402, April 2015,		DOI 10.17487/RFC7402, April 2015,
	skipping to change at page 21, line 41 ¶		skipping to change at page 20, line 41 ¶
	| draft-07 | Document refresh; no other changes. |		| draft-07 | Document refresh; no other changes. |
	| | |		| | |
	| draft-08 | issues 3 and 11: Address complaints of complexity due |		| draft-08 | issues 3 and 11: Address complaints of complexity due |
	| | to full mesh of SAs for multihoming. |		| | to full mesh of SAs for multihoming. |
	| | |		| | |
	| | issue 5: Improve draft based on recommendations for |		| | issue 5: Improve draft based on recommendations for |
	| | cross-family handovers in paper by Varjonen et. al. |		| | cross-family handovers in paper by Varjonen et. al. |
	| | |		| | |
	| | issue 7: Clarify and distinguish between load |		| | issue 7: Clarify and distinguish between load |
	| | balancing and fault tolerance use cases. |		| | balancing and fault tolerance use cases. |
			| | |
			| draft-09 | Update author affiliations, IPR boilerplate to |
			| | trust200902, and one stale reference. |
	+----------+--------------------------------------------------------+		+----------+--------------------------------------------------------+
	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
	EMail: tomhend@u.washington.edu		EMail: tomhend@u.washington.edu
	Christian Vogt		Christian Vogt
	Ericsson Research NomadicLab		Independent
	Hirsalantie 11		3473 North First Street
	JORVAS FIN-02420		San Jose, CA 95134
	FINLAND		USA
	EMail: christian.vogt@ericsson.com		EMail: mail@christianvogt.net
	Jari Arkko		Jari Arkko
	Ericsson Research NomadicLab		Ericsson
	JORVAS FIN-02420		JORVAS FIN-02420
	FINLAND		FINLAND
	Phone: +358 40 5079256		Phone: +358 40 5079256
	EMail: jari.arkko@ericsson.com		EMail: jari.arkko@piuha.net
End of changes. 20 change blocks.
	39 lines changed or deleted		31 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/