draft-ietf-hip-multihoming-03.txt		draft-ietf-hip-multihoming-04.txt
	Network Working Group T. Henderson, Ed.		Network Working Group T. Henderson, Ed.
	Internet-Draft The Boeing Company		Internet-Draft University of Washington
	Intended status: Standards Track C. Vogt		Intended status: Standards Track C. Vogt
	Expires: January 16, 2014 J. Arkko		Expires: May 16, 2015 J. Arkko
	Ericsson Research NomadicLab		Ericsson Research NomadicLab
	July 15, 2013		November 12, 2014
	Host Multihoming with the Host Identity Protocol		Host Multihoming with the Host Identity Protocol
	draft-ietf-hip-multihoming-03		draft-ietf-hip-multihoming-04
	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 16, 2014.		This Internet-Draft will expire on May 16, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2014 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 19		skipping to change at page 2, line 19
	modifications of such material outside the IETF Standards Process.		modifications of such material outside the IETF Standards Process.
	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 . . . . . . . . . . . . . . . . . . . . 3		1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 2
	2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4		2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4
	3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Operating Environment . . . . . . . . . . . . . . . . . . 5		3.1. Operating Environment . . . . . . . . . . . . . . . . . . 5
	3.2. Multihoming Overview . . . . . . . . . . . . . . . . . . . 7		3.2. Multihoming Overview . . . . . . . . . . . . . . . . . . 7
	4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7		4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
	4.1. Host Multihoming . . . . . . . . . . . . . . . . . . . . . 8		4.1. Host Multihoming . . . . . . . . . . . . . . . . . . . . 8
	4.2. Site Multihoming . . . . . . . . . . . . . . . . . . . . . 9		4.2. Site Multihoming . . . . . . . . . . . . . . . . . . . . 9
	4.3. Dual host multihoming . . . . . . . . . . . . . . . . . . 10		4.3. Dual host multihoming . . . . . . . . . . . . . . . . . . 10
	4.4. Combined Mobility and Multihoming . . . . . . . . . . . . 10		4.4. Combined Mobility and Multihoming . . . . . . . . . . . . 10
	4.5. Initiating the Protocol in R1 or I2 . . . . . . . . . . . 11		4.5. Initiating the Protocol in R1 or I2 . . . . . . . . . . . 11
	5. Other Considerations . . . . . . . . . . . . . . . . . . . . . 12		5. Other Considerations . . . . . . . . . . . . . . . . . . . . 12
	5.1. Address Verification . . . . . . . . . . . . . . . . . . . 12		5.1. Address Verification . . . . . . . . . . . . . . . . . . 12
	5.2. Preferred Locator . . . . . . . . . . . . . . . . . . . . 12		5.2. Preferred Locator . . . . . . . . . . . . . . . . . . . . 12
	5.3. Interaction with Security Associations . . . . . . . . . . 13		5.3. Interaction with Security Associations . . . . . . . . . 13
	6. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 15		6. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 15
	6.1. Sending LOCATORs . . . . . . . . . . . . . . . . . . . . . 15		6.1. Sending LOCATORs . . . . . . . . . . . . . . . . . . . . 15
	6.2. Handling Received LOCATORs . . . . . . . . . . . . . . . . 17		6.2. Handling Received LOCATORs . . . . . . . . . . . . . . . 17
	6.3. Verifying Address Reachability . . . . . . . . . . . . . . 19		6.3. Verifying Address Reachability . . . . . . . . . . . . . 19
	6.4. Changing the Preferred Locator . . . . . . . . . . . . . . 19		6.4. Changing the Preferred Locator . . . . . . . . . . . . . 19
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 20		7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
	9. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 20		9. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 20
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
	10.1. Normative references . . . . . . . . . . . . . . . . . . . 20		10.1. Normative references . . . . . . . . . . . . . . . . . . 20
	10.2. Informative references . . . . . . . . . . . . . . . . . . 21		10.2. Informative references . . . . . . . . . . . . . . . . . 21
	Appendix A. Document Revision History . . . . . . . . . . . . . . 21		Appendix A. Document Revision History . . . . . . . . . . . . . 22
	1. Introduction and Scope		1. Introduction and Scope
	The Host Identity Protocol [RFC4423] (HIP) supports an architecture		The Host Identity Protocol [I-D.ietf-hip-rfc4423-bis] (HIP) supports
	that decouples the transport layer (TCP, UDP, etc.) from the		an architecture that decouples the transport layer (TCP, UDP, etc.)
	internetworking layer (IPv4 and IPv6) by using public/private key		from the internetworking layer (IPv4 and IPv6) by using public/
	pairs, instead of IP addresses, as host identities. When a host uses		private key pairs, instead of IP addresses, as host identities. When
	HIP, the overlying protocol sublayers (e.g., transport layer sockets		a host uses HIP, the overlying protocol sublayers (e.g., transport
	and Encapsulating Security Payload (ESP) Security Associations (SAs))		layer sockets and Encapsulating Security Payload (ESP) Security
	are instead bound to representations of these host identities, and		Associations (SAs)) are instead bound to representations of these
	the IP addresses are only used for packet forwarding. However, each		host identities, and the IP addresses are only used for packet
	host must also know at least one IP address at which its peers are		forwarding. However, each host must also know at least one IP
	reachable. Initially, these IP addresses are the ones used during		address at which its peers are reachable. Initially, these IP
	the HIP base exchange [RFC5201].		addresses are the ones used during the HIP base exchange
			[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. Host		network-layer mobility and host multihoming are possible. 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 40		skipping to change at page 3, line 34
	Another variation of multihoming that has been heavily studied site		Another variation of multihoming that has been heavily studied site
	multihoming. Solutions for site multihoming in IPv6 networks have		multihoming. Solutions for site multihoming in IPv6 networks have
	been specified by the IETF shim6 working group. The shim6 protocol		been specified by the IETF shim6 working group. The shim6 protocol
	[RFC5533] bears many architectural similarities to HIP but there are		[RFC5533] bears many architectural similarities to HIP but there are
	differences in the security model and in the protocol. Future		differences in the security model and in the protocol. Future
	versions of this draft will summarize the differences more		versions of this draft will summarize the differences more
	completely.		completely.
	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 [RFC5202], this document largely assumes the use of		transport format [I-D.ietf-hip-rfc5202-bis], this document largely
	ESP and leaves other transport formats for further study.		assumes the use of ESP and leaves other transport formats for further
			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
	[RFC5204]. Such functionality is out of the scope of this document.		[I-D.ietf-hip-rfc5204-bis]. Such functionality is out of the scope
	Finally, making underlying IP multihoming transparent to the		of this document. Finally, making underlying IP multihoming
	transport layer has implications on the proper response of transport		transparent to the transport layer has implications on the proper
	congestion control, path MTU selection, and Quality of Service (QoS).		response of transport congestion control, path MTU selection, and
			Quality of Service (QoS). Transport-layer mobility triggers, and the
	Transport-layer mobility triggers, and the proper transport response		proper transport response to a HIP multihoming address change, are
	to a HIP multihoming address change, are outside the scope of this		outside the scope of this document.
	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].
	Terminology is copied from [I-D.ietf-hip-rfc5206-bis].		Terminology is copied from [I-D.ietf-hip-rfc5206-bis].
	LOCATOR. The name of a HIP parameter containing zero or more Locator		LOCATOR. The name of a HIP parameter containing zero or more Locator
	skipping to change at page 5, line 7		skipping to change at page 5, line 7
	This section is an overview; more detailed specification follows this		This section is an overview; more detailed specification follows this
	section.		section.
	The overall protocol model is the same as in Section 3 of		The overall protocol model is the same as in Section 3 of
	[I-D.ietf-hip-rfc5206-bis]; this section only highlights the		[I-D.ietf-hip-rfc5206-bis]; this section only highlights the
	differences.		differences.
	3.1. Operating Environment		3.1. Operating Environment
	The Host Identity Protocol (HIP) [RFC5201] is a key establishment and		The Host Identity Protocol (HIP) [I-D.ietf-hip-rfc5201-bis] is a key
	parameter negotiation protocol. Its primary applications are for		establishment and parameter negotiation protocol. Its primary
	authenticating host messages based on host identities, and		applications are for authenticating host messages based on host
	establishing security associations (SAs) for the ESP transport format		identities, and establishing security associations (SAs) for the ESP
	[RFC5202] and possibly other protocols in the future.		transport format [I-D.ietf-hip-rfc5202-bis] and possibly other
			protocols in the future.
	+--------------------+ +--------------------+		+--------------------+ +--------------------+
	| | | |		| | | |
	| +------------+ | | +------------+ |		| +------------+ | | +------------+ |
	| | Key | | HIP | | Key | |		| | Key | | HIP | | Key | |
	| | Management | <-+-----------------------+-> | Management | |		| | Management | <-+-----------------------+-> | Management | |
	| | Process | | | | Process | |		| | Process | | | | Process | |
	| +------------+ | | +------------+ |		| +------------+ | | +------------+ |
	| ^ | | ^ |		| ^ | | ^ |
	| | | | | |		| | | | | |
	skipping to change at page 6, line 21		skipping to change at page 6, line 21
	| ---------		| ---------
	| |		| |
	---- ---------		---- ---------
	| MH |-> | HIP | {HIT_s, HIT_d, SPI} <-> {IP_s, IP_d, SPI}		| MH |-> | HIP | {HIT_s, HIT_d, SPI} <-> {IP_s, IP_d, SPI}
	---- ---------		---- ---------
	|		|
	---------		---------
	| IP |		| IP |
	---------		---------
	Figure 2: Architecture for HIP Multihoming (MH)		Figure 2: Architecture for HIP Multihoming (MH)
	Figure 2 depicts a layered architectural view of a HIP-enabled stack		Figure 2 depicts a layered architectural view of a HIP-enabled stack
	using the ESP transport format. In HIP, upper-layer protocols		using the ESP transport format. In HIP, upper-layer protocols
	(including TCP and ESP in this figure) are bound to Host Identity		(including TCP and ESP in this figure) are bound to Host Identity
	Tags (HITs) and not IP addresses. The HIP sublayer is responsible		Tags (HITs) and not IP addresses. The HIP sublayer is responsible
	for maintaining the binding between HITs and IP addresses. The SPI		for maintaining the binding between HITs and IP addresses. The SPI
	is used to associate an incoming packet with the right HITs. The		is used to associate an incoming packet with the right HITs. The
	block labeled "MH" is introduced below.		block labeled "MH" is introduced below.
	Consider the case when a host is multihomed (has more than one		Consider the case when a host is multihomed (has more than one
	skipping to change at page 7, line 28		skipping to change at page 7, line 28
	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 [RFC5202], although other scenarios may be defined		the ESP transform [I-D.ietf-hip-rfc5202-bis], although other
	in the future. To understand these usage scenarios, the reader		scenarios may be defined in the future. To understand these usage
	should be at least minimally familiar with the HIP protocol		scenarios, the reader should be at least minimally familiar with the
	specification [RFC5201]. However, for the (relatively) uninitiated		HIP protocol specification [I-D.ietf-hip-rfc5201-bis]. However, for
	reader, it is most important to keep in mind that in HIP the actual		the (relatively) uninitiated reader, it is most important to keep in
	payload traffic is protected with ESP, and that the ESP SPI acts as		mind that in HIP the actual payload traffic is protected with ESP,
	an index to the right host-to-host context.		and that the ESP SPI acts as an index to the right host-to-host
			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 12, line 22		skipping to change at page 12, line 22
	<-----------------------------------		<-----------------------------------
	(process normally)		(process normally)
	Figure 6: LOCATOR Inclusion in I2		Figure 6: LOCATOR 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 parameter is present in R1. In this case, implementations		LOCATOR parameter is present in R1. In this case, implementations
	simultaneously using multiple pre-created R1s, indexed by Initiator		simultaneously using multiple pre-created R1s, indexed by Initiator
	IP addresses, may inadvertently fail the puzzle solution of I2		IP addresses, may inadvertently fail the puzzle solution of I2
	packets due to a perceived puzzle mismatch. See, for instance, the		packets due to a perceived puzzle mismatch. See, for instance, the
	example in Appendix A of [RFC5201]. As a solution, the Responder's		example in Appendix A of [I-D.ietf-hip-rfc5201-bis]. As a solution,
	puzzle indexing mechanism must be flexible enough to accommodate the		the Responder's puzzle indexing mechanism must be flexible enough to
	situation when R1 includes a LOCATOR parameter.		accommodate the situation when R1 includes a LOCATOR parameter.
	5. Other Considerations		5. Other Considerations
	5.1. Address Verification		5.1. Address Verification
	An address verification method is specified in		An address verification method is specified in
	[I-D.ietf-hip-rfc5206-bis]. It is expected that addresses learned in		[I-D.ietf-hip-rfc5206-bis]. It is expected that addresses learned in
	multihoming scenarios also are subject to the same verification		multihoming scenarios also are subject to the same verification
	rules.		rules.
	skipping to change at page 13, line 15		skipping to change at page 13, line 15
	5.3. Interaction with Security Associations		5.3. Interaction with Security Associations
	This document uses the HIP LOCATOR protocol parameter, specified in		This document uses the HIP LOCATOR protocol parameter, specified in
	[I-D.ietf-hip-rfc5206-bis]), that allows the hosts to exchange		[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 parameters		locator(s). The logical structure created with LOCATOR parameters
	has three levels: hosts, Security Associations (SAs) indexed by		has three levels: hosts, Security Associations (SAs) indexed by
	Security Parameter Indices (SPIs), and addresses.		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 [RFC5201] and ESP transform		defined in the base specification [I-D.ietf-hip-rfc5201-bis] and ESP
	[RFC5202] is illustrated in Figure 7.		transform [I-D.ietf-hip-rfc5202-bis] is illustrated in Figure 7.
	-<- SPI1a -- -- SPI2a ->-		-<- SPI1a -- -- SPI2a ->-
	host1 < > addr1a <---> addr2a < > host2		host1 < > addr1a <---> addr2a < > host2
	->- SPI2a -- -- SPI1a -<-		->- SPI2a -- -- SPI1a -<-
	Figure 7: Relation between Hosts, SPIs, and Addresses (Base		Figure 7: Relation between Hosts, SPIs, and Addresses (Base
	Specification)		Specification)
	In Figure 7, host1 and host2 negotiate two unidirectional SAs, and		In Figure 7, 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 20, line 35		skipping to change at page 20, line 37
	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-rfc5206-bis] Henderson, T., Vogt, C., and J. Arkko,		[I-D.ietf-hip-rfc5201-bis]
	"Host Mobility with the Host Identity		Moskowitz, R., Heer, T., Jokela, P., and T. Henderson,
	Protocol", draft-ietf-hip-rfc5206-bis-06		"Host Identity Protocol Version 2 (HIPv2)", draft-ietf-
	(work in progress), July 2013.		hip-rfc5201-bis-14 (work in progress), October 2013.
	[RFC2119] Bradner, S., "Key words for use in RFCs
	to Indicate Requirement Levels", BCP 14,
	RFC 2119, March 1997.
	[RFC3484] Draves, R., "Default Address Selection		[I-D.ietf-hip-rfc5202-bis]
	for Internet Protocol version 6 (IPv6)",		Jokela, P., Moskowitz, R., and J. Melen, "Using the
	RFC 3484, February 2003.		Encapsulating Security Payload (ESP) Transport Format with
			the Host Identity Protocol (HIP)", draft-ietf-hip-
			rfc5202-bis-05 (work in progress), November 2013.
	[RFC4303] Kent, S., "IP Encapsulating Security		[I-D.ietf-hip-rfc5206-bis]
	Payload (ESP)", RFC 4303, December 2005.		Henderson, T., Vogt, C., and J. Arkko, "Host Mobility with
			the Host Identity Protocol", draft-ietf-hip-rfc5206-bis-06
			(work in progress), July 2013.
	[RFC4423] Moskowitz, R. and P. Nikander, "Host		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Identity Protocol (HIP) Architecture",		Requirement Levels", BCP 14, RFC 2119, March 1997.
	RFC 4423, May 2006.
	[RFC5201] Moskowitz, R., Nikander, P., Jokela, P.,		[RFC3484] Draves, R., "Default Address Selection for Internet
	and T. Henderson, "Host Identity		Protocol version 6 (IPv6)", RFC 3484, February 2003.
	Protocol", RFC 5201, April 2008.
	[RFC5202] Jokela, P., Moskowitz, R., and P.		[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
	Nikander, "Using the Encapsulating		4303, December 2005.
	Security Payload (ESP) Transport Format
	with the Host Identity Protocol (HIP)",
	RFC 5202, April 2008.
	10.2. Informative references		10.2. Informative references
	[RFC5204] Laganier, J. and L. Eggert, "Host		[I-D.ietf-hip-rfc4423-bis]
	Identity Protocol (HIP) Rendezvous		Moskowitz, R. and M. Komu, "Host Identity Protocol
	Extension", RFC 5204, April 2008.		Architecture", draft-ietf-hip-rfc4423-bis-08 (work in
			progress), April 2014.
	[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6:		[I-D.ietf-hip-rfc5204-bis]
	Level 3 Multihoming Shim Protocol for		Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
	IPv6", RFC 5533, June 2009.		Rendezvous Extension", draft-ietf-hip-rfc5204-bis-04 (work
			in progress), June 2014.
			[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
			Shim Protocol for IPv6", RFC 5533, June 2009.
	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. |
			| | |
	| draft-01 | Document refresh; no other changes. |		| draft-01 | Document refresh; no other changes. |
			| | |
	| draft-02 | Document refresh; no other changes. |		| draft-02 | Document refresh; no other changes. |
			| | |
	| draft-03 | Document refresh; no other changes. |		| draft-03 | Document refresh; no other changes. |
			| | |
			| draft-04 | Document refresh; no other changes. |
	+----------+--------------------------------------------------------+		+----------+--------------------------------------------------------+
	Authors' Addresses		Authors' Addresses
	Thomas R. Henderson (editor)		Thomas R. Henderson (editor)
	The Boeing Company		University of Washington
	P.O. Box 3707		Campus Box 352500
	Seattle, WA		Seattle, WA
	USA		USA
	EMail: thomas.r.henderson@boeing.com		EMail: tomhend@u.washington.edu
	Christian Vogt		Christian Vogt
	Ericsson Research NomadicLab		Ericsson Research NomadicLab
	Hirsalantie 11		Hirsalantie 11
	JORVAS FIN-02420		JORVAS FIN-02420
	FINLAND		FINLAND
	Phone:
	EMail: christian.vogt@ericsson.com		EMail: christian.vogt@ericsson.com
	Jari Arkko		Jari Arkko
	Ericsson Research NomadicLab		Ericsson Research NomadicLab
	JORVAS FIN-02420		JORVAS FIN-02420
	FINLAND		FINLAND
	Phone: +358 40 5079256		Phone: +358 40 5079256
	EMail: jari.arkko@ericsson.com		EMail: jari.arkko@ericsson.com
End of changes. 30 change blocks.
	106 lines changed or deleted		114 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/