< draft-devarapalli-mip6-nemo-local-haha-00.txt		draft-devarapalli-mip6-nemo-local-haha-01.txt >
	MIP6/NEMO Working Group V. Devarapalli		MIP6/NEMO Working Group V. Devarapalli
	Internet-Draft Nokia		Internet-Draft Nokia
	Expires: January 2, 2006 R. Wakikawa		Expires: September 6, 2006 R. Wakikawa
	Keio University and WIDE		WIDE
	P. Thubert		P. Thubert
	Cisco Systems		Cisco
	July 1, 2005		March 5, 2006
	Local HA to HA protocol		Local HA to HA protocol
	draft-devarapalli-mip6-nemo-local-haha-00		draft-devarapalli-mip6-nemo-local-haha-01.txt
	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 37 ¶		skipping to change at page 1, line 37 ¶
	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 January 2, 2006.		This Internet-Draft will expire on September 6, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	This document describes the use of an Inter Home Agents protocol		This document describes the use of an Inter Home Agents protocol
	(HAHA) to achieve Home Agent reliability and load balancing. The		(HAHA) to achieve Home Agent reliability and load balancing. The
	protocol allows Home Agents serving the same home link to share the		protocol allows Home Agents serving the same home link to share the
	binding cache contents, and switch a mobile node from one home agent		binding cache contents, and switch a mobile node from one home agent
	to another. It also allows a mobile node to utilize multiple Home		to another. It also allows a mobile node to utilize multiple Home
	Agents simultaneously. A mobile node picks one Home Agent as its		Agents simultaneously. A mobile node picks one Home Agent as its
	primary Home Agent and registers with it. The primary Home Agent		primary Home Agent and registers with it. The primary Home Agent
	synchronizes the binding cache information with other Home Agents.		synchronizes the binding cache information with other Home Agents.
	Any of Home Agents can intercept a packet meant for the mobile node		Any of Home Agents can intercept a packet meant for the mobile node
	and tunnel the packet directly to its current Care-of address.		and tunnel the packet directly to its current Care-of address.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 4		3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 4
	3.1 Home Agent List Management . . . . . . . . . . . . . . . . 4		3.1. Home Agent List Management . . . . . . . . . . . . . . . . 4
	3.2 Home Agent Failure Detection . . . . . . . . . . . . . . . 4		3.2. Home Agent Failure Detection . . . . . . . . . . . . . . . 5
	3.3 Binding Synchronization . . . . . . . . . . . . . . . . . 5		3.3. Binding Synchronization . . . . . . . . . . . . . . . . . 5
	3.4 Home Agent Switching . . . . . . . . . . . . . . . . . . . 6		3.4. Home Agent Switching . . . . . . . . . . . . . . . . . . . 6
	4. Interworking with VRRP for IPv6 . . . . . . . . . . . . . . . 6		4. Interworking with VRRP for IPv6 . . . . . . . . . . . . . . . 6
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 7		5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	7.1 Normative References . . . . . . . . . . . . . . . . . . . 8		7.1. Normative References . . . . . . . . . . . . . . . . . . . 8
	7.2 Informative References . . . . . . . . . . . . . . . . . . 8		7.2. Informative References . . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
	Intellectual Property and Copyright Statements . . . . . . . . 10		Intellectual Property and Copyright Statements . . . . . . . . . . 10
	1. Introduction		1. Introduction
	Mobile nodes [3] and mobile routers [5] may use a bi-directional		Mobile nodes [3] and mobile routers [5] may use a bi-directional
	tunnel with their Home Agents for all traffic with the correspondent		tunnel with their Home Agents for all traffic with the correspondent
	nodes. Note that in this document, the term mobile node refers to		nodes. Note that in this document, the term mobile node refers to
	both a mobile node and a mobile router. A Home Agent on the home		both a mobile node and a mobile router. A Home Agent on the home
	link maintains a binding cache entry for each mobile node and uses		link maintains a binding cache entry for each mobile node and uses
	the binding cache entry to route any traffic meant for the mobile		the binding cache entry to route any traffic meant for the mobile
	node or the mobile network. If the mobile node does not have a		node or the mobile network. If the mobile node does not have a
	skipping to change at page 4, line 11 ¶		skipping to change at page 4, line 11 ¶
	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 [1].		document are to be interpreted as described in [1].
	For the HAHA protocol related terminology, please see [4]		For the HAHA protocol related terminology, please see [4]
	3. Protocol Operation		3. Protocol Operation
	The following sections describe the local HAHA protocol.		The following sections describe the local HAHA protocol.
	3.1 Home Agent List Management		3.1. Home Agent List Management
	RFC 3775 defines a mechanism for maintaining a home agent list when		RFC 3775 defines a mechanism for maintaining a home agent list when
	there are multiple home agents present on a link. It is based on		there are multiple home agents present on a link. It is based on
	each Home Agent sending a router advertisement periodically on the		each Home Agent sending a router advertisement periodically on the
	home link with a Home Address Information option [3]. However, this		home link with a Home Address Information option [3]. However, this
	mechanism is governed by how a router sends a router advertisement as		mechanism is governed by how a router sends a router advertisement as
	defined in [8]. There are restrictions on how often a router		defined in [8]. There are restrictions on how often a router
	advertisement can be sent and on how they are processed by routers		advertisement can be sent and on how they are processed by routers
	that receive them. Moreover, the router advertisements are not sent		that receive them. Moreover, the router advertisements are not sent
	frequently enough to rely on the absence of the router advertisement		frequently enough to rely on the absence of the router advertisement
	skipping to change at page 4, line 50 ¶		skipping to change at page 5, line 5 ¶
	If the home agent lifetime field in the Hello message is set to 0,		If the home agent lifetime field in the Hello message is set to 0,
	the Home Agent removes the Home Agent that sent the Hello message		the Home Agent removes the Home Agent that sent the Hello message
	from the Home Agents list.		from the Home Agents list.
	This mechanism should be used only when all the Home Agents on a		This mechanism should be used only when all the Home Agents on a
	particular link support sending and receiving these Hello messages.		particular link support sending and receiving these Hello messages.
	When the Hello messages are used for maintaining the Home Agents		When the Hello messages are used for maintaining the Home Agents
	list, the Home Agent MUST NOT use the Home Agent Information option		list, the Home Agent MUST NOT use the Home Agent Information option
	in the router advertisements to manage the Home Agents list.		in the router advertisements to manage the Home Agents list.
	3.2 Home Agent Failure Detection		3.2. Home Agent Failure Detection
	Failure detection is based on Hello messages [4]. Each Home Agent is		Failure detection is based on Hello messages [4]. Each Home Agent is
	expected to send the Hello message periodically. This interval is		expected to send the Hello message periodically. This interval is
	indicated by the Hello interval field in the Hello message. If a		indicated by the Hello interval field in the Hello message. If a
	Hello message is not received from a Home Agent within a multiple of		Hello message is not received from a Home Agent within a multiple of
	the interval value, then the Home Agent is considered to have failed.		the interval value, then the Home Agent is considered to have failed.
	A Home Agent that is designated as a backup for the failed Home Agent		A Home Agent that is designated as a backup for the failed Home Agent
	takes over and sends a Home Agent Switch Request (Section 3.4)		takes over and sends a Home Agent Switch Request (Section 3.4)
	message to all the mobile nodes that were being served by the failed		message to all the mobile nodes that were being served by the failed
	Home Agent to switch to it.		Home Agent to switch to it.
	VRRP for IPv6 can also be used for detecting a Home Agent failure.		VRRP for IPv6 can also be used for detecting a Home Agent failure.
	The operation of local HAHA with VRRP is explained in Section 4.		The operation of local HAHA with VRRP is explained in Section 4.
	3.3 Binding Synchronization		3.3. Binding Synchronization
	Binding cache entries are synchronized between all the Home Agents on		Binding cache entries are synchronized between all the Home Agents on
	the home link. The Home Agent that had actually processed the		the home link. The Home Agent that had actually processed the
	Binding Update from the mobile node is considered the primary Home		Binding Update from the mobile node is considered the primary Home
	Agent for a particular mobile node. Each Home Agent sends a Binding		Agent for a particular mobile node. Each Home Agent sends a Binding
	Information Update message, gratuitously, whenever it creates or		Information Update message, gratuitously, whenever it creates or
	updates a binding cache entry for a mobile node. The Binding		updates a binding cache entry for a mobile node. The Binding
	Information Update message is sent unicast to all the Home Agents in		Information Update message is sent unicast to all the Home Agents in
	the home agents list. A Home Agent can send information on multiple		the home agents list. A Home Agent can send information on multiple
	binding cache entries in a Binding Information Update message by		binding cache entries in a Binding Information Update message by
	skipping to change at page 6, line 5 ¶		skipping to change at page 6, line 7 ¶
	Information Request Message [4]. If a Home Agents wants the Binding		Information Request Message [4]. If a Home Agents wants the Binding
	Cache Information for a particular mobile node it includes a Home		Cache Information for a particular mobile node it includes a Home
	Address mobility option, defined in [4], to carry the home address of		Address mobility option, defined in [4], to carry the home address of
	the mobile node. If a Home Agent wants to know the forwarding state		the mobile node. If a Home Agent wants to know the forwarding state
	setting up for a particular Mobile Network Prefix, it includes the		setting up for a particular Mobile Network Prefix, it includes the
	Mobile Network Prefix Option, defined in [2]. When a Home Agent		Mobile Network Prefix Option, defined in [2]. When a Home Agent
	receives a Binding Information Request message, it responds with a		receives a Binding Information Request message, it responds with a
	Binding Information Update message for the corresponding binding		Binding Information Update message for the corresponding binding
	cache entry.		cache entry.
	3.4 Home Agent Switching		3.4. Home Agent Switching
	If a Home Agent is no longer able to provide service to a particular		If a Home Agent is no longer able to provide service to a particular
	mobile node, due to excessive load or due to an administrative		mobile node, due to excessive load or due to an administrative
	reason, it can tell the mobile node to use another Home Agent on the		reason, it can tell the mobile node to use another Home Agent on the
	home link by sending a Home Agent Switch Request message. This		home link by sending a Home Agent Switch Request message. This
	message is defined in [4]. The Home Agent MAY include the IP address		message is defined in [4]. The Home Agent MAY include the IP address
	of another Home Agent in the Home Agent Switch Request message. The		of another Home Agent in the Home Agent Switch Request message. The
	request message MUST only be sent to mobile nodes that are not on the		request message MUST only be sent to mobile nodes that are not on the
	home link.		home link.
	skipping to change at page 8, line 4 ¶		skipping to change at page 8, line 6 ¶
	6. IANA Considerations		6. IANA Considerations
	The Home Agent Hello messages are sent to an IPv6 link-local scope		The Home Agent Hello messages are sent to an IPv6 link-local scope
	multicast address. This needs to be assigned by the IANA. The		multicast address. This needs to be assigned by the IANA. The
	address should be of the following form:		address should be of the following form:
	FF02:0:0:0:0:0:XXXX:XXXX		FF02:0:0:0:0:0:XXXX:XXXX
	7. References		7. References
	7.1 Normative References
			7.1. Normative References
	[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[2] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,		[2] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
	"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,		"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
	January 2005.		January 2005.
	[3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in		[3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
	IPv6", RFC 3775, June 2004.		IPv6", RFC 3775, June 2004.
	[4] Wakikawa, R., "Inter Home Agents Protocol Specification",		[4] Wakikawa, R., "Inter Home Agents Protocol Specification",
	draft-wakikawa-mip6-nemo-haha-spec-00 (work in progress),		draft-wakikawa-mip6-nemo-haha-spec-00 (work in progress),
	October 2004.		October 2004.
	7.2 Informative References		7.2. Informative References
	[5] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to		[5] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
	Protect Mobile IPv6 Signaling Between Mobile Nodes and Home		Protect Mobile IPv6 Signaling Between Mobile Nodes and Home
	Agents", RFC 3776, June 2004.		Agents", RFC 3776, June 2004.
	[6] Thubert, P., "Global HA to HA protocol",		[6] Thubert, P., "Global HA to HA protocol",
	draft-thubert-nemo-global-haha-00 (work in progress),		draft-thubert-nemo-global-haha-01 (work in progress),
	October 2004.		October 2005.
	[7] Hinden, R., "Virtual Router Redundancy Protocol for IPv6",		[7] Hinden, R., "Virtual Router Redundancy Protocol for IPv6",
	draft-ietf-vrrp-ipv6-spec-07 (work in progress), October 2004.		draft-ietf-vrrp-ipv6-spec-07 (work in progress), October 2004.
	[8] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery		[8] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
	for IP Version 6 (IPv6)", RFC 2461, December 1998.		for IP Version 6 (IPv6)", RFC 2461, December 1998.
	[9] El-Rewini, H., Khalil, M., and J. Faizan, "Virtual Home Agent		[9] El-Rewini, H., Khalil, M., and J. Faizan, "Virtual Home Agent
	Reliability Protocol (VHAR)", draft-jfaizan-mipv6-vhar-02 (work		Reliability Protocol (VHAR)", draft-jfaizan-mipv6-vhar-02 (work
	in progress), April 2004.		in progress), April 2004.
	Authors' Addresses		Authors' Addresses
	Vijay Devarapalli		Vijay Devarapalli
	Nokia Research Center		Nokia Research Center
	313 Fairchild Drive		313 Fairchild Drive
	Mountain View, CA 94043		Mountain View, CA 94043
	USA		USA
	Email: vijay.devarapalli@nokia.com		Email: dvijay@gmail.com
	Ruyji Wakikawa
			Ryuji Wakikawa
	Keio University and WIDE		Keio University and WIDE
	5322 Endo Fujisawa Kanagawa		5322 Endo Fujisawa Kanagawa
	252-8520		252-8520
	Japan		Japan
	Email: ryuji@sfc.wide.ad.jp		Email: ryuji@sfc.wide.ad.jp
	Pascal Thubert		Pascal Thubert
	Cisco Systems		Cisco Systems
	Village d'Entreprises Green Side		Village d'Entreprises Green Side
	400, Avenue de Roumanille		400, Avenue de Roumanille
	Batiment T3		Batiment T3, Biot - Sophia Antipolis 06410
	Biot - Sophia Antipolis 06410
	France		France
	Email: pthubert@cisco.com		Email: pthubert@cisco.com
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	skipping to change at page 10, line 41 ¶		skipping to change at page 10, line 41 ¶
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement		Copyright Statement
	Copyright (C) The Internet Society (2005). This document is subject		Copyright (C) The Internet Society (2006). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and		to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		except as set forth therein, the authors retain all their rights.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes. 17 change blocks.
	28 lines changed or deleted		29 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/