< draft-jfaizan-mipv6-ha-reliability-00.txt		draft-jfaizan-mipv6-ha-reliability-01.txt >
	Mobile IP Working Group Jahanzeb Faizan		Mobile IP Working Group Jahanzeb Faizan
	Internet-Draft Hesham El-Rewini		Internet-Draft Hesham El-Rewini
	Expires: May, 2004 Southern Methodist University		Expires: August, 2004 Southern Methodist University
	Mohammad Khalil		Mohammad Khalil
	Nortel Networks		Nortel Networks
	November, 2003		February, 2004
	Problem Statement: Home Agent Reliability		Problem Statement: Home Agent Reliability
	draft-jfaizan-mipv6-ha-reliability-00.txt		draft-jfaizan-mipv6-ha-reliability-01.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	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 other		Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	skipping to change at page 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	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 http://		The list of current Internet-Drafts can be accessed at http://
	www.ietf.org/ietf/1id-abstracts.txt.		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 May, 2004.		This Internet-Draft will expire on August, 2004.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2003). All Rights Reserved.
	Abstract		Abstract
	In Mobile-IPv6, Mobile Node is dependent on a single Home Agent for		In Mobile IPv6, the Mobile Node is dependent on a single Home Agent
	the seamless roaming over the Internet. Mobile-IPv6 also allows		for the seamless roaming over the Internet. Mobile IPv6 also allows
	deployment of multiple Home Agents on the subnet for providing		deployment of multiple Home Agents on the home link for providing
	continuous service to Mobile Node in case of serving Home Agent		continuous service to Mobile Node in case of Home Agent failure. But
	failure. But switching of service from the failed Home Agent to		switching of service from the failed Home Agent to another functional
	another functional Home Agent on the Home Subnet is problematic and		Home Agent on the home link is problematic and the base Mobile IPv6
	the base Mobile-IPv6 specifications does not currently have		specifications does not currently have well-described solutions. This
	well-described solutions. This document aims to describe and		document aims to describe and illustrate these problems, and propose
	illustrate these problems, and propose some guidelines for possible		some guidelines for possible solutions.
	solutions.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1 Overview of the Problem . . . . . . . . . . . . . . . . . 3		1.1 Overview of the Problem . . . . . . . . . . . . . . . . . 3
	1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Mobile-IPv6 Deployment Scenario . . . . . . . . . . . . . . . .5
			2. Mobile IPv6 Deployment Scenario . . . . . . . . . . . . . . . .5
	3. Problem statement . . . . . . . . . . . . . . . . . . . . . . .5		3. Problem statement . . . . . . . . . . . . . . . . . . . . . . .5
	3.1 Failure Detection . . . . . . . . . . . . . . . . . . . . 5		3.1 Failure . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.2 IPsec Security Association with new Home Agent . . . . . .6		3.1.1 Home Agent Failure . . . . . . . . . . . . . . . . 6
	4. Solution Guidelines . . . . . . . . . . . . . . . . . . . . . .7		3.1.2 Home Link Failure . . . . . . . . . . . . . . . . .6
	4.1 Security Implications . . . . . . . . . . . . . . . . . . 7		3.2 Failure Detection . . . . . . . . . . . . . . . . . . . . 6
	4.2 IPsec Security with new Home Agent . . . . . . . . . . . .7		3.3 Recovery . . . . . . . . . . . . . . . . . . . . . . . . .7
	4.3 Seamless failure . . . . . . . . . . . . . . . . . . . . .7		3.4 IPsec Security Association with new Home Agent . . . . . .7
	4.4 Mobile Node functionality . . . . . . . . . . . . . . . . 7		3.4.1 Dynamic Keying . . . . . . . . . . . . . . . . . . 7
	4.5 Messages over air interface . . . . . . . . . . . . . . . 7		3.4.2 Manual Keying . . . . . . . . . . . . . . . . . . .7
	4.6 Home Agent addition and failure . . . . . . . . . . . . . 7		3.5 Correct Ordering . . . . . . . . . . . . . . . . . . . . .8
	4.7 Scalability . . . . . . . . . . . . . . . . . . . . . . . 8		3.6 Load Balancing . . . . . . . . . . . . . . . . . . . . . .8
	References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8		4. Solution Guidelines . . . . . . . . . . . . . . . . . . . . . .8
	Intellectual Property and Copyright Statements . . . . . . . . 9		4.1 Security Implications . . . . . . . . . . . . . . . . . . 8
	Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . .10		4.2 IPsec Security with new Home Agent . . . . . . . . . . . .8
			4.3 Seamless failure . . . . . . . . . . . . . . . . . . . . .8
			4.4 Mobile Node functionality . . . . . . . . . . . . . . . . 9
			4.5 Messages over air interface . . . . . . . . . . . . . . . 9
			4.6 Home Agent addition and failure . . . . . . . . . . . . . 9
			4.7 Load Balancing. . . . . . . . . . . . . . . . . . . . . . 9
			References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .10
			Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .10
			Intellectual Property and Copyright Statements . . . . . . . .10
			Appendix: Changes from the previous version. . . . . . . . . .11
	1. Introduction		1. Introduction
	Mobile-IPv6[1] is designed to allow a Mobile Node to change its point		Mobile IPv6[1] is designed to allow a Mobile Node(MN) to change its
	of IP subnet attachment in the Internet at the network or IP layer.		point of IP subnet attachment in the Internet at the network or IP
	The Mobile Node is always identified by it Home Address regardless		layer. MN is always identified by it Home Address regardless of its
	of its current network location. Its mobility is not limited by		current location. Its mobility is not limited by conventional IP
	conventional IP network boundaries. The Mobile-IPv6 system consists		network boundaries. In Mobile IPv6 system the Home Agent(HA) remains
	of Mobile Node and Home Agent. Home Agent remains at conventional		at conventional IPv6 subnet called the home link and when the MN is
	IPv6 subnet called the Home Subnet and when the Mobile Node is at the		at the home link then the packets sent to it are routed through
	Home Subnet then the packets sent to it are routed through		conventional IPv6[5] routing mechanisms. When the MN is not at home
	conventional IPv6[5] routing mechanism. When the Mobile Node is not		link it registers its remote point of attachment address called
	at Home Subnet it registers its remote point of attachment address		Care-of Address with the HA. This allows HA to forward packets,
	called Care of Address with the Home Agent. This allows Home		addressed to the MN at its home link, to its current location.
	Agent to forward packets, addressed to the Mobile Node at its Home
	Network, to its current location.
	In Mobile-IPv6 system, as currently specified, a single Home Agent		In Mobile IPv6 system, as currently specified, a single HA services
	services Mobile Node(s). Mobile-IPv6 also allows deployment of		multiple MNs. Mobile IPv6 also allows deployment of multiple HAs on
	multiple Home Agents on the same subnet so that if the serving		the same link so that if the serving HA fails then any other HA
	Home Agent fails then any other Home Agent on the subnet can provide		on the link can provide service to the MN.
	service to the Mobile Node.
	The goal of this draft is to:		The goal of this draft is to:
	o Articulate the problems resulting from the failure of a serving		o Articulate the problems resulting from the failure of a serving
	Home Agent and switching of service to another Home Agent.		HA and switching of service to another HA.
	o Specify a set of framework guidelines to evaluate proposed		o Specify a set of framework guidelines to evaluate proposed
	solutions.		solutions.
	1.1 Overview of the Problem		1.1 Overview of the Problem
	In Mobile-IPv6[1], Mobile Node registers and establish a connection		In Mobile IPv6, MN registers and establishes a connection with only
	with only one Home Agent which provides continuous service to it. The		one HA. The MN is reliant on this HA for its connectivity. Thus the
	Mobile Node is reliant on this Home Agent for its connectivity. Thus		HA represents the possibility of a single point of failure for Mobile
	the Home Agent represents the possibility of a single point of		IPv6. A HA may be responsible for multiple MNs on the home link. The
	failure for Mobile-IPv6. A Home Agent may be responsible for multiple		failure of a single HA may then result in the loss of connectivity
	Mobile Nodes on the Home Subnet. The failure of a single Home Agent		for numerous MNs located throughout the Internet. Thus the HA and MN
	may then result in the loss of connectivity for numerous Mobile Nodes		taken together have a shared fate. A MN cannot afford the loss of its
	located throughout the Internet. Thus the Home Agent and Mobile Node		HA. To overcome this problem Mobile IPv6 allows deployment of
	taken together have a shared fate. A Mobile Node cannot afford the		multiple HAs on the home link so that upon the failure of serving HA,
	loss of its Home Agent. To overcome this problem Mobile-IPv6 allows		another HA can take over the functions of failed HA and thus provide
	deployment of multiple Home Agents on the Home Subnet so that upon		continuous service to the MN(s) registered with failed HA. This
	the failure of serving Home Agent, another Home Agent can take over		transfer of service from the failed HA to a new working HA is
	the functions of failed Home Agent and thus provide continuous		problematic and the current specification of Mobile IPv6 does not
	service to the Mobile Node(s) registered with failed Home Agent. This		provide solution to these problems.
	transfer of service from the failed Home Agent to a new working Home
	Agent is problematic and the current specification of Mobile-IPv6 [1]
	does not provide solution to these problems.
	1.2 Terminology		1.2 Terminology
	Mobile-IPv6		Following terms are not re-defined. They are included for the
			convenience of the readers.
			Mobile IPv6
	Mobile IP for IPv6 [1]		Mobile IP for IPv6 [1]
	Mobile Node		Mobile Node (MN)
	A node that can change its point of attachment from one link		A node that can change its point of attachment from one link
	to another, while still being reachable via its home address.		to another, while still being reachable via its home address.
	IP		IP
	Internet Protocol Version 6 (IPv6).[5]		Internet Protocol Version 6 (IPv6).[5]
	Home Address		Home Address
			A unicast routable address assigned to a MN, used as the
			permanent address of the MN. This address is within the MN's
			home link. Standard IP routing mechanisms will deliver
			packets destined for a MN's home address to its home
			link.MNs can have multiple home addresses, for instance when
			there are multiple home prefixes on the home link.
	A unicast routable address assigned to a Mobile Node, used as		Home Link
	the permanent address of the Mobile Node. This address is		The link on which a MN's home subnet prefix is defined.
	within the Mobile Node's Home Subnet. Conventional IPv6
	routing mechanisms will deliver packets destined for a Mobile
	Node's Home Address to its Home Subnet.
	Home Network
	A network, possibly virtual, having a network prefix matching
	that of a Mobile Node's Home Address.
	Home Agent		Home Agent (HA)
	A router on a Mobile Node's Home Network which tunnels		A router on a MN's home link with which the MN has registered
	datagrams for delivery to the Mobile Node when it is away		its current Care-of address. While the MN is away from home,
	from home, and maintains current location information for the		the HA intercepts packets on the home link destined to the
	Mobile Node.		MN's home address, encapsulates them, and tunnels them to the
			MN's registered Ccare-of address.
	Care of Address		Care-of Address
	A unicast routable address associated with a Mobile Node		A unicast routable address associated with a MN while
	while visiting a foreign network.		visiting a foreign link; the subnet prefix of this IP address
			is a foreign subnet prefix. Among the multiple
			Care-of addresses that a MN may have at any given time (e.g.,
			with different subnet prefixes), the one registered with the
			MN's HA for a given home address is called its "primary"
			care-of address.
	IPsec Security Association		IPsec Security Association
	An IPSec security association is a cooperative relationship		An IPSec security association is a cooperative relationship
	formed by the sharing of cryptographic keying material and		formed by the sharing of cryptographic keying material and
	associated context. Security associations are simplex. That		associated context. Security associations are simplex. That
	is, two security associations are needed to protect		is, two security associations are needed to protect
	bidirectional traffic between two nodes, one for each		bidirectional traffic between two nodes, one for each
	direction.		direction.
	Registration		Home Registration
	The process during which a Mobile Node sends a Binding Update
	to its Home Agent causing a binding for the Mobile Node to be		A registration between the MN and its HA, authorized by the
	registered.		use of IPsec.
	The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The keywords "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 [6].		document are to be interpreted as described in RFC 2119 [6].
	2. Mobile-IPv6 Deployment Scenario		2. Mobile IPv6 Deployment Scenario
	This section describes a basic deployment scenario where multiple		This section describes a basic deployment scenario where multiple
	Home Agents, referred as HAs 1..n, have to coexist on the same		HAs, referred as HAs 1..n, have to coexist on the same home link to
	Home Subnet to provide continuous service to Mobile Node (MN) in case		provide continuous service to MN in case of failure of the serving
	of failure of the serving Home Agent. Mobile Node runs both		HA. MN runs Mobile IPv6 MN functionality with the mobility signaling
	Mobile-IPv6 Mobile Node functionality along with IPsec client		messages protected by IPsec. Also all the HAs 1..n run Mobile IPv6 HA
	software. Also all the HAs 1..n run Mobile-IPv6 Home Agent
	functionality along with IPsec server software. Initially MN is		functionality along with IPsec server software. Initially MN is
	registered and have IPv6 tunnel with HA_1.		registered and has IPv6 tunnel with HA_1.
	..Foreign Network.. ......Home Network............		..Foreign Network.. ......Home Network............
	. . . .		. . . .
	. +----+ . . +-------+ .		. +----+ . . +-------+ .
	. |MN | .<=========> . | HA_1 | .		. |MN | .<=========> . | HA_1 | .
	. | | . . +-------+ +-------+ .		. | | . . +-------+ +-------+ .
	. +----+ . . ..... | HA_n | .		. +----+ . . ..... | HA_n | .
	. . . +-------+ +-------+ .		. . . +-------+ +-------+ .
	. . . | HA_2 | .		. . . | HA_2 | .
	. . . +-------+ .		. . . +-------+ .
	skipping to change at page 5, line 30 ¶		skipping to change at page 5, line 34 ¶
	..Foreign Network.. ......Home Network............		..Foreign Network.. ......Home Network............
	. . . .		. . . .
	. +----+ . . +-------+ .		. +----+ . . +-------+ .
	. |MN | .<=========> . | HA_1 | .		. |MN | .<=========> . | HA_1 | .
	. | | . . +-------+ +-------+ .		. | | . . +-------+ +-------+ .
	. +----+ . . ..... | HA_n | .		. +----+ . . ..... | HA_n | .
	. . . +-------+ +-------+ .		. . . +-------+ +-------+ .
	. . . | HA_2 | .		. . . | HA_2 | .
	. . . +-------+ .		. . . +-------+ .
	................... ..............................		................... ..............................
	Figure 1		Figure 1
	3. Problem statement		3. Problem statement
	This section uses the scenario discussed in section 2 to describe		This section uses the scenario discussed in section 2 to describe the
	the problems associated with the failure of serving Home Agent and		problems associated with the failure of serving HA and as the result
	as the result of this switching of service to another Home Agent on		of this switching of service to another HA on the home link. Consider
	the subnet. Consider the failure of HA_1. and switching of service		the failure of HA_1. and switching of service to a new HA_x
	to a new HA_x (where x = 2..n) on the same subnet. This whole process		(where x = 2..n) on the same home link. This whole process of failure
	of failure and switching is problematic. The problems are discussed		detection and switching is problematic. The problems are discussed
	in the following sub-sections.		in the following sub-sections.
	3.1 Failure Detection		3.1 Failure
			The following sub-sections introduce two possible scenarios of
			failure.
			3.1.1 Home Agent Failure
			There could be single or multiple HAs failure on the home link. Since
			MN could register only with a single HA on the home link which is
			HA_1 in our scenario, so failure of multiple HAs is not going to
			effect the normal operation of Mobile IPv6. We are only concerned
			with the serving HA failure on the home link.
			3.1.2 Home Link Failure
			There could be failure of home link which will make it inaccessible
			to the MN. If this occurs then even the serving HA_1 is operational,
			to the MN it would appear that its serving HA_1 has failed.
			3.2 Failure Detection
	Transfer of service from the failed HA_1 to new HA_x will occur after		Transfer of service from the failed HA_1 to new HA_x will occur after
	the detection of failure by MN. MN could detect the failure of HA_1		the detection of failure by MN. MN could detect the failure of HA_1
	under certain conditions. These are listed below.		under certain conditions. These are listed below.
	o When MN sends Binding Update(BU) message to the failed HA_1 and		o When MN sends Binding Update(BU) message to the failed HA_1 and
	does not receive matching Binding Acknowledgment(BA) message, it		does not receive matching Binding Acknowledgment(BA) message, it
	will retransmit BUs until timeout occurs. Upon this MN will come to		will retransmit BUs until timeout occurs. Upon this MN will come to
	know about the failure of HA_1.		know about the failure of HA_1.
	o Similarly when MN sends Mobile Prefix Solicitation(PS) message to		o Similarly when MN sends Mobile Prefix Solicitation(MPS) message to
	the failed HA_1 and does not receive Mobile Prefix Advertisement,		the failed HA_1 and does not receive Mobile Prefix Advertisement,
	it will retransmit PSs until timeout occurs and that's how it will		it will retransmit MPSs until timeout occurs and that's how it will
	come to know that HA_1 has failed.		come to know that HA_1 has failed.
	According to Mobile-IPv6[1] MN after sending first BU or PS message		According to Mobile IPv6 MN after sending first BU or MPS message to
	to failed HA_1 will wait for a initial timeout period which is set to		failed HA_1 will wait for a initial timeout period which is set to
	INITIAL_BINDACK_TIMEOUT (1 second) in case of BU and		INITIAL_BINDACK_TIMEOUT (1 second) in case of BU and
	INITIAL_SOLICIT_TIMER (3 seconds) in case of PS. This timeout period		INITIAL_SOLICIT_TIMER (3 seconds) in case of MPS. This timeout period
	will be doubled for each subsequent BU or PS message until value of		will be doubled for each subsequent BU or MPS message until value of
	MAX_BINACK_TIMEOUT (32 seconds) is reached. MN MAY send infinite BUs		MAX_BINACK_TIMEOUT (32 seconds) is reached. MN MAY send infinite BUs
	or PSs to failed HA_1 before the final timeout occurs.		or MPSs to failed HA_1 before the final timeout occurs.
	So the detection of failed HA_1 will be delayed by a considerable		So the detection of failed HA_1 will be delayed by a considerable
	amount of time. Also there will be many useless messages transmitted		amount of time. Also there will be many messages transmitted over the
	over the air interface during this period. Moreover BU and PS are		air interface during this period. Moreover BU and MPS are not
	not periodic rather on demand. MN will send BU only to register		periodic rather on demand. MN will send BU only to register new
	new Care of Address or to extend the lifetime of existing		Care-of Address or to extend the lifetime of existing registration
	registration with its serving Home Agent. Similarly MN will send PS		with its serving HA. Similarly MN will send MPS only when its serving
	only when its serving Home Agent's address is about to become		HA's address is about to become invalid. As a result MN will suffer
	invalid. As a result MN will suffer packet loss and disconnectivity		packet loss and disconnectivity problems. This could have noticeable
	problems. This could have noticeable performance implications on		performance implications on real-time applications.
	real-time applications.
	3.2 IPsec Security Association with new Home Agent		3.3 Recovery
	Once the failure is detected, MN will try to register its Care of		Once the failure is detected, according to the current specifications
	Address with any other Home Agent on the subnet. For this MN must		of Mobile IPv6 MN will try to register its Care-of Address with any
	know which other Home Agents are available on the subnet. MN MAY		other HA on the home link. For this MN must know which other HAs are
	start Dynamic Home Agent Discovery(DHAD)[1] protocol and as the		available on the home link. MN MAY start Dynamic Home Agent
	result will get list of available Home Agents on the subnet. MN could		discovery(DHAD)[1] protocol and as a result will get a list of
	then select HA_x (in our scenario) on the list as its potential		available HAs on the home link. MN could then select HA_x (in our
	serving Home Agent. MN will send BU message to HA_x setting Home		scenario) on the list as its potential serving HA. MN will send BU
	Registration(H) bit.		message to HA_x setting Home Registration(H) bit.
	According to the base specification of Mobile-IPv6[1] MN and HA_x		But this recovery mechanism is problematic. If there is only one
			HA available on the home link then according to current
			specifications of Mobile IPv6 even if the retransmission parameter
			MAX_BINACK_TIMEOUT (32 seconds) is reached MN will continue to send
			BU messages to the HA_1 until it receives valid BA message and this
			will never happen because HA_1 has failed. This makes the MN enter
			into an endless loop.
			Even if there are multiple HAs exist (as in our scenario), besides
			failure detection, there is an extra burden on MN to perform
			Home Registration with the new HA and in some cases multiple
			Home Registrations if there are unsuccessful attempts. Also if there
			is no information about the available HAs on the home link then MN
			has to perform DHAD. All these factors together result in extra
			messages overhead on the air interface, service interruption and
			burden on MN.
			3.4 IPsec Security Association with new Home Agent
			According to the current specifications of Mobile IPv6 MN and HA_x
	MUST use IPsec Security Associations to protect the integrity and		MUST use IPsec Security Associations to protect the integrity and
	authenticity of the BUs and BAs. If there is no existing Security		authenticity of the BUs and BAs. There are two methods of
	Association to protect the BU, MN will initiate IKE[2] (referred as		establishing such Associations.
	Dynamic Keying) according to the guidelines defined in [3]. The
	latency casued by IKE transcations might cause performance		3.4.1 Dynamic Keying
	degradation.
			If MN and the new HA_x does not have existing Security Association to
			protect the BU, IKE[2] (referred as Dynamic Keying) will be
			initiated according to the guidelines defined in [3]. The latency
			caused by IKE transactions might cause performance degradation.
			3.4.2 Manual Keying
	The problem of Dynamic Keying can be avoided by Manual Keying. It		The problem of Dynamic Keying can be avoided by Manual Keying. It
	involves out-of-band entry of Security Associations in MN and Home		involves out-of-band entry of Security Associations in MN and HA. MN
	Agent. MN can be statically configured for a set of Home Agents among		can be statically configured for a set of HAs among HAs 1..n and
	HAs 1..n and corresponding Security Associations before launching		corresponding Security Associations before launching MN in the
	MN in the Mobile-IPv6 network. This will allow MN to register with		Mobile IPv6 network. This will allow MN to register with any other
	any other Home Agent and use appropriate Security Associations upon		HA and use appropriate Security Associations upon the failure of it's
	the failure of it's serving Home Agent. But this policy is not		serving HA. But this policy is not flexible enough to accommodate the
	flexible enough to accommodate the dynamic nature of subnets.		dynamic nature of home link.
			3.5 Correct Ordering
			Upon the HA_1 failure the sequence number information in the Binding
			Cache of HA_1 will also be lost. The new HA_x to which MN will switch
			will not have the knowledge about the sequence number of last sent BU
			by the MN. This introduces new security vulnerabilities to the
			Mobile IPv6.
			3.6 Load Balancing
			Mobile IPv6 does not include any specification about how the HAs
			on home link will do load balancing among them. This is important for
			utilizing the services of all HAs on the home link efficiently.
	4. Solution Guidelines		4. Solution Guidelines
	This section describes guidelines for a solution to the above		This section describes guidelines for a solution to the above
	mentioned problems. The subsections discuss the guidelines in a		mentioned problems. The sub-sections discuss the guidelines in a
	decreasing order of importance.		decreasing order of importance.
	4.1 Security Implications		4.1 Security Implications
	The solution MUST NOT introduce any new security vulnerabilities to		The solution MUST NOT introduce any new security vulnerabilities to
	the Mobile-IPv6[1].		the Mobile IPv6.
	4.2 IPsec Security with new Home Agent		4.2 IPsec Security with new Home Agent
	The solution SHOULD provide a mechanism to quickly establish IPsec		The solution SHOULD provide a mechanism to quickly establish IPsec
	Security Association between the Mobile Node and the new Home Agent		Security Association between the MN and the new HA such that the
	such that the service interruption is minimimal.		service interruption is minimal.
	4.3 Seamless failure		4.3 Seamless failure
	It is strongly recommendated that the failure of Home Agent should be		It is recommended that the failure of HA should be transparent from
	transparent from the Mobile Node. This will contribute in minimizing		the MN. This will contribute in minimizing the period of service
	the period of service interruption.		interruption.
	4.4 Mobile Node functionality		4.4 Mobile Node functionality
	The solution SHOULD cause minimal modification to the Mobile Node as		The solution SHOULD cause minimal modification to the MN operation
	it is defined by Mobile-IPv6[1].		as it is defined by Mobile IPv6.
	4.5 Messages over air interface		4.5 Messages over air interface
	The solution SHOULD avoid introducing new messages more than what has		The solution SHOULD use minimal new messages.
	been defined by Mobile-IPv6[1].
	4.6 Home Agent addition and failure		4.6 Home Agent addition and failure
	The solution SHOULD provide recovery mechanism for the failed Home		The solution SHOULD provide recovery mechanism for the failed HA.
	Agent. Also any new Home Agent added on the subnet SHOULD be ready to		Also any new HA added on the home link SHOULD be ready to serve in
	serve in minimum amount of time possible.		minimum amount of time possible.
	4.7 Scalability		4.7 Load Balancing
	The solution complexity MUST increase at most linearly with the		The solution SHOULD provide load balancing mechanism for the HAs on
	number of Mobile Nodes registered and Home Agents configured on the		the home link. It could be of centralized or distributed nature.
	subnet.
	References		References
	[1] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in		[1] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in
	IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), August		IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), August
	2003.		2003.
	[2] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",		[2] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
	RFC 2409, November 1998.		RFC 2409, November 1998.
	skipping to change at page 9, line 4 ¶		skipping to change at page 10, line 21 ¶
	Dallas, TX, 75205, USA		Dallas, TX, 75205, USA
	Phone +1 214-768-3712, Fax +1 214-768-3085		Phone +1 214-768-3712, Fax +1 214-768-3085
	EMail: jfaizan@smu.edu		EMail: jfaizan@smu.edu
	Hesham El-Rewini		Hesham El-Rewini
	Southern Methodist University		Southern Methodist University
	Computer Science and Engineering Department.		Computer Science and Engineering Department.
	6425 N Ownby Dr., SIC #306C		6425 N Ownby Dr., SIC #306C
	Dallas, TX, 75205, USA		Dallas, TX, 75205, USA
	Phone +1 214-768-3278, Fax +1 214-768-3085		Phone +1 214-768-3278, Fax +1 214-768-3085
	EMail: rewini@engr.smu.edu		EMail: rewini@engr.smu.edu
	Mohammad Khalil		Mohammad Khalil
	Nortel Networks		Nortel Networks
	Richardson, TX, USA		Richardson, TX, USA
	Phone: +1 972-685-0564		Phone: +1 972-685-0564
	EMail: mkhalil@nortelnetworks		EMail: mkhalil@nortelnetworks
			Acknowledgements
			The authors would like to thank Vijay Devarapalli and Ryuji Wakikawa
			for their continuous feedback and helping us improve this draft.
			Funding for the RFC Editor function is currently provided by the
			Internet Society.
	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 or other rights that might be claimed to		intellectual property 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
	might or might not be available; neither does it represent that it		might or might not be available; neither does it represent that it
	has made any effort to identify any such rights. Information on the		has made any effort to identify any such rights. Information on the
	IETF's procedures with respect to rights in standards-track and		IETF's procedures with respect to rights in standards-track and
	standards-related documentation can be found in BCP-11. Copies of		standards-related documentation can be found in BCP-11. Copies of
	skipping to change at page 10, line 16 ¶		skipping to change at page 11, line 42 ¶
	The limited permissions granted above are perpetual and will not be		The limited permissions granted above are perpetual and will not be
	revoked by the Internet Society or its successors or assignees.		revoked by the Internet Society or its successors or assignees.
	This document and the information contained herein is provided on an		This document and the information contained herein is provided on an
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION		BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF		HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Acknowledgment		Appendix: Changes from Previous Version
	Funding for the RFC Editor function is currently provided by the		The following changes have been made to this document from version
	Internet Society.		00:
			o Addition of types of failure, correct ordering and load balancing
			sections in the problem statement.
			o Also failure detection and recovery sections are explained in
			more detail in the problem statement.
			o IPsec Security Associations with the new Home Agent section is
			organized into Dynamic and Manual Keying sub-sections.
			o Load balancing requirement is added in the solution guidelines
			section.
End of changes. 48 change blocks.
	161 lines changed or deleted		241 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/