< draft-wakikawa-mobileip-multiplecoa-03.txt		draft-wakikawa-mobileip-multiplecoa-04.txt >
	MIP6 Working Group Ryuji Wakikawa		MIP6 Working Group Ryuji Wakikawa
	INTERNET DRAFT Keisuke Uehara		INTERNET DRAFT Keisuke Uehara
	Category: Individual Thierry Ernst		Category: Individual Thierry Ernst
	19 Jun 2004 Keio Univ./WIDE		Expire:20 Dec 2005 Keio Univ./WIDE
	Kenichi Nagami		Kenichi Nagami
	INTEC Netcore		INTEC Netcore
			20 Jun 2005
	Multiple Care-of Addresses Registration		Multiple Care-of Addresses Registration
	draft-wakikawa-mobileip-multiplecoa-03.txt		draft-wakikawa-mobileip-multiplecoa-04.txt
	Status of This Memo		Status of This Memo
	By submitting this Internet-Draft, I certify that any applicable
	patent or other IPR claims of which I am aware have been disclosed,
	and any of which I become aware will be disclosed, in accordance with
	RFC 3668.
	This document is a submission to the MIP6 Working Group of the		This document is a submission to the MIP6 Working Group of the
	Internet Engineering Task Force (IETF). Comments should be submitted		Internet Engineering Task Force (IETF). Comments should be submitted
	to the mip6@ietf.org (mobile-ip@sunroof.eng.sun.com) mailing list.		to the mip6@ietf.org mailing list.
	Distribution of this memo is unlimited.		By submitting this Internet-Draft, each author represents that any
			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
			aware will be disclosed, in accordance with Section 6 of BCP 79.
	This document is an Internet-Draft and is in full conformance with		Internet-Drafts are working documents of the Internet Engineering
	all provisions of Section 10 of RFC2026. Internet-Drafts are working		Task Force (IETF), its areas, and its working groups. Note that
	documents of the Internet Engineering Task Force (IETF), its areas,		other groups may also distribute working documents as Internet-
	and its working groups. Note that other groups may also distribute		Drafts.
	working documents as Internet-Drafts.
	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		and may be updated, replaced, or obsoleted by other documents at
	any time. It is inappropriate to use Internet-Drafts as reference		any 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:
	http://www.ietf.org/shadow.html.		The list of Internet-Draft Shadow Directories can be accessed at
			http://www.ietf.org/shadow.html.
			This Internet-Draft will expire on December 20, 2005.
			Copyright Notice
			Copyright (C) The Internet Society (2005).
	Abstract		Abstract
	According to the current Mobile IPv6 specification, a mobile node		According to the current Mobile IPv6 specification, a mobile node
	may have several care-of addresses, but only one, termed the primary		may have several care-of addresses, but only one, termed the primary
	care-of address, can be registered with its home agent and the		care-of address, can be registered with its home agent and the
	correspondent nodes. However, for matters of cost, bandwidth, delay,		correspondent nodes. However, for matters of cost, bandwidth, delay,
	etc, it is useful for the mobile node to get Internet access through		etc, it is useful for the mobile node to get Internet access through
	multiple access media (i.e. interfaces) simultaneously, in which		multiple access media simultaneously, in which case multiple active
	case multiple active IPv6 care-of addresses would be assigned to		IPv6 care-of addresses would be assigned to the mobile node. We thus
	the mobile node. We thus propose Mobile IPv6 extensions designed		propose Mobile IPv6 extensions designed to register multiple care-of
	to register multiple care-of addresses bound to a single home		addresses bound to a single home address instead of the sole primary
	address instead of the sole primary care-of address. For doing so,		care-of address. For doing so, a new identification number must be
	a new identification number must be carried in each binding for the		carried in each binding for the receiver to distinguish between the
	receiver to distinguish between the bindings corresponding to the		bindings corresponding to the same home address. Those extensions
	same home address. Those extensions are targeted to NEMO (Network		are targeted to NEMO (Network Mobility) Basic Support as well as to
	Mobility) Basic Support as well as to Mobile IPv6.		Mobile IPv6.
	Contents		Contents
	Status of This Memo 1		Status of This Memo 1
	Abstract 1		Copyright Notice 1
			Abstract 2
	1. Introduction 4		1. Introduction 4
	2. Terminology 6		2. Terminology 6
	3. Protocol Overview 8		3. Protocol Overview 8
	3.1. Multiple Care-of Addresses Registration . . . . . . . . . 8		3.1. Multiple Care-of Addresses Registration . . . . . . . . . 8
	3.2. Multiple Bindings Management . . . . . . . . . . . . . . 9		3.2. Multiple Bindings Management . . . . . . . . . . . . . . 9
	3.3. Returning Home . . . . . . . . . . . . . . . . . . . . . 9		3.3. Returning Home . . . . . . . . . . . . . . . . . . . . . 9
	4. Mobile IPv6 Extensions 10		4. Mobile IPv6 Extensions 10
	4.1. Binding Cache Structure and Management . . . . . . . . . 10		4.1. Binding Cache Structure and Management . . . . . . . . . 10
	4.2. Binding Update Structure and Management . . . . . . . . . 10		4.2. Binding Update Structure and Management . . . . . . . . . 10
	4.3. Messages Format Changes . . . . . . . . . . . . . . . . . 11		4.3. Messages Format Changes . . . . . . . . . . . . . . . . . 11
	4.3.1. Binding Unique Identifier sub-option . . . . . . 11		4.3.1. Binding Unique Identifier sub-option . . . . . . 11
	4.3.2. Binding Update . . . . . . . . . . . . . . . . . 12		4.3.2. Binding Update . . . . . . . . . . . . . . . . . 12
	4.3.3. Binding Acknowledgment . . . . . . . . . . . . . 12		4.3.3. Binding Acknowledgment . . . . . . . . . . . . . 12
			4.4. Dynamic Home Agent Address Discovery . . . . . . . . . . 13
			4.4.1. DHAAD Request . . . . . . . . . . . . . . . . . . 13
			4.4.2. DHAAD Reply . . . . . . . . . . . . . . . . . . . 13
			4.4.3. Home Agent Information Option . . . . . . . . . . 14
	5. Mobile Node Operation 13		5. Mobile Node Operation 15
	5.1. Management of care-of addresses . . . . . . . . . . . . . 13		5.1. Management of care-of addresses and Binding Unique
	5.2. Sending Binding Update . . . . . . . . . . . . . . . . . 13		Identifier . . . . . . . . . . . . . . . . . . . . . . . . 15
	5.3. De-registration . . . . . . . . . . . . . . . . . . . . . 14		5.2. Sending Binding Update . . . . . . . . . . . . . . . . . 15
	5.4. Using Alternate Care-of Address . . . . . . . . . . . . . 15		5.3. De-registration . . . . . . . . . . . . . . . . . . . . . 16
	5.5. Receiving Binding Acknowledgment . . . . . . . . . . . . 16		5.4. Using Alternate Care-of Address . . . . . . . . . . . . . 17
	5.6. Receiving Binding Refresh Request . . . . . . . . . . . . 16		5.5. Receiving Binding Acknowledgment . . . . . . . . . . . . 17
	5.7. Receiving Binding Error . . . . . . . . . . . . . . . . . 17		5.6. Receiving Binding Refresh Request . . . . . . . . . . . . 18
			5.7. Receiving Binding Error . . . . . . . . . . . . . . . . . 18
	6. Home Agent and Correspondent Node Operation 17		6. Home Agent and Correspondent Node Operation 19
	6.1. Searching Binding Cache with Binding Unique Identification		6.1. Searching Binding Cache with Binding Unique Identification
	Number . . . . . . . . . . . . . . . . . . . . . . . . . . 17		Number . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	6.2. Receiving Binding Update . . . . . . . . . . . . . . . . 18		6.2. Receiving Binding Update . . . . . . . . . . . . . . . . 19
	6.3. Sending Binding Acknowledgment . . . . . . . . . . . . . 19		6.3. Sending Binding Acknowledgment . . . . . . . . . . . . . 21
	6.4. Sending Binding Refresh Request . . . . . . . . . . . . . 19		6.4. Sending Binding Refresh Request . . . . . . . . . . . . . 21
	6.5. Sending Binding Error . . . . . . . . . . . . . . . . . . 20		6.5. Sending Binding Error . . . . . . . . . . . . . . . . . . 21
	7. Network Mobility Applicability 20		7. Network Mobility Applicability 22
	Appendices 21		Appendices 23
	A. Example Configurations 21		A. A Scenario: Access both Carrier Packet Network and the Internet 23
	Example Configurations 21		B. Example Configurations 24
	Acknowledgments 24		C. Changes 27
	References 24		References 28
	Authors' Addresses 26		Authors' Addresses 29
	1. Introduction		1. Introduction
	Permanent Internet connectivity is required by some applications		Permanent Internet connectivity is required by some applications
	while a mobile node moves across several access networks (i.e.		while a mobile node moves across several access networks (i.e.
	ISPs, hotspots, etc). For example, it is desirable to maintain		ISPs, hotspots, etc). For example, it is desirable to maintain
	the Internet connectivity while an automobile running on a freeway		the Internet connectivity while an automobile running on a freeway
	receives voice or video streaming data from different access		receives voice or video streaming data from different access
	networks. Such motivations for multiple points of attachment, and		networks. Such motivations for multiple points of attachment, and
	benefits for doing it are discussed at large in [5].		benefits for doing it are discussed at large in [4]. The problem
			statement of multihomed mobile node is summarized in [7].
	Unfortunately, there is no network interfaces assuring global scale		Unfortunately, there is no network interfaces assuring global scale
	connectivity. Therefore, a mobile node should use various type of		connectivity. Therefore, a mobile node should use various type of
	network interfaces to obtain wide area network connectivity [8]. In		network interfaces to obtain wide area network connectivity [9]. In
	addition, users should select the most appropriate network interface		addition, users should select the most appropriate network interface
	depending on a visiting network environment, since wireless networks		depending on a visiting network environment, since wireless networks
	are mutable and less reliable than wired networks and since each		are mutable and less reliable than wired networks and since each
	network interface has different cost, performance, bandwidth, access		network interface has different cost, performance, bandwidth, access
	range, and reliability. Users should also be able to select the		range, and reliability. Users should also be able to select the
	most appropriate interface per communication type. For example, TCP		most appropriate interface per communication type. For example, TCP
	traffic should be transmitted over the wireless interface, whereas		traffic should be transmitted over the wireless interface, whereas
	UDP traffic should be transmitted over wired the interface to avoid		UDP traffic should be transmitted over the wired interface to avoid
	disturbing TCP connections.		disturbing TCP connections.
	Associating multiple care-of addresses to a single home address would		Associating multiple care-of addresses to a single home address would
	allow durable Internet connectivity [10] [1] [11]. For example,		allow durable Internet connectivity. For example, when a mobile node
	when a mobile node loses its Internet connectivity at one of its		loses its Internet connectivity at one of its interface, the second
	interface, the second interface can be used as a backup interface		interface can be used as a backup interface therefrom maintaining
	therefrom maintaining Internet connectivity. In addition, the		Internet connectivity. In addition, the mobile node can send each
	mobile node can send each communication flow to a distinct network		communication flow to a distinct network interface. This provides
	interface. This provides efficient network bandwidth consumption. A		efficient network bandwidth consumption. A user can select the most
	user can select the most suitable network interface per application.		suitable network interface per application. Correspondent nodes can
	Correspondent nodes can also re-select a binding of the mobile node		also re-select a binding of the mobile node to recover communication
	to recover communication when one of mobile node's bindings becomes		when one of mobile node's bindings becomes invalid. To enable a
	invalid. To enable a binding selection policy, a mobile node can		binding selection policy, a mobile node can use the particular
	use the particular binding for specified communication type. If a		binding for specified communication type. If a mobile node does
	mobile node does not have enough bandwidth for communications, it		not have enough bandwidth for communications, it can utilize both
	can utilize both bindings to gain network bandwidth. Furthermore,		bindings to gain network bandwidth. Furthermore, a mobile node may
	a mobile node may bicast packets of a particular flow through all		bicast packets of a particular flow through all available network
	available network interfaces.		interfaces.
	IPv6 [2] conceptually allows a node to have several addresses on a		IPv6 [1] conceptually allows a node to have several addresses on a
	given interface. Consequently, Mobile IPv6 [6] has mechanisms to		given interface. Consequently, Mobile IPv6 [5] has mechanisms to
	manage multiple ``home addresses'' based on home agent's managed		manage multiple ``home addresses'' based on home agent's managed
	prefixes such as mobile prefix solicitation and mobile prefix		prefixes such as mobile prefix solicitation and mobile prefix
	advertisement. But assigning a single home address to a given		advertisement. But assigning a single home address to a given
	network interface is more advantageous than assigning multiple		network interface is more advantageous than assigning multiple
	home addresses because applications do not need to be aware of the		home addresses because applications do not need to be aware of the
	multiplicity of home addresses. Of course, applications should be		multiplicity of home addresses. Of course, applications should be
	aware of the active home address to be used for communicating. At		aware of the active home address to be used for communicating. At
	the TCP layer, TCP holds the home address as a source address of the		the TCP layer, TCP holds the home address as a source address of
	communication for connection management. Thus, applications must be		the communication for connection management. Applications must be
	restarted to reset the connection information when the mobile node		restarted to reset the connection information when the mobile node
	changes its active network interface (i.e. change the home address).		changes its active network interface (i.e. change the home address).
	However, according to section 11.5.3 of the Mobile IPv6 specification		However, according to section 11.5.3 of the Mobile IPv6 specification
	[6], a mobile node is not allowed to register multiple care-of		[5], a mobile node is not allowed to register multiple care-of
	addresses bound to a single home address. If a mobile node sends		addresses bound to a single home address. If a mobile node sends
	Binding Updates for each care-of address, correspondent nodes would		Binding Updates for each care-of address, correspondent nodes would
	always overwrite the care-of address recorded in the binding cache		always overwrite the care-of address recorded in the binding cache
	with the one contained in the latest received binding update. It		with the one contained in the latest received binding update. It
	is thus impossible for a mobile node to register multiple care-of		is thus impossible for a mobile node to register multiple care-of
	addresses in the correspondent node's binding cache.		addresses in the correspondent node's binding cache.
	In this document, we thus propose a new identification number called		In this document, we thus propose a new identification number called
	Binding Unique Identification number (BID) for each binding cache		Binding Unique Identification number (BID) for each binding cache
	entry to accommodate multiple bindings registration. We also propose		entry to accommodate multiple bindings registration. We also propose
	skipping to change at page 6, line 7 ¶		skipping to change at page 6, line 7 ¶
	By using the BID, multiple bindings can then be distinguished.		By using the BID, multiple bindings can then be distinguished.
	A user of a mobile node may be able to bind some policies to a BID.		A user of a mobile node may be able to bind some policies to a BID.
	The policy is used to divide flows to multiple network interfaces		The policy is used to divide flows to multiple network interfaces
	by flow type, port number, or destination address, etc. How to		by flow type, port number, or destination address, etc. How to
	distribute or configure policies is not within the scope of this		distribute or configure policies is not within the scope of this
	document.		document.
	2. Terminology		2. Terminology
	Terms used in this draft are defined in [6] and [7]. We define or		Terms used in this draft are defined in [5] and [6]. We define or
	redefine the following ones:		redefine the following ones:
	Binding Unique Identification number (BID)		Binding Unique Identification number (BID)
	The BID is an identification number used to distinguish		The BID is an identification number used to distinguish
	multiple bindings registered by the mobile node. Assignment of		multiple bindings registered by the mobile node. Assignment of
	distinct BID allows a mobile node to register multiple binding		distinct BID allows a mobile node to register multiple binding
	cache entries for a given home address. The BID is generated		cache entries for a given home address. The BID is generated
	in a way it cannot be duplicated with another BID. The zero		to register multiple bindings in the binding cache for a given
	value and a negative value MUST NOT be used. After being		addess in a way it cannot be duplicated with another BID.
	generated, the BID is stored in the Binding Update List and is		The zero value and a negative value MUST NOT be used. After
	sent by the mobile node by means of a sub-option of a Binding		being generated by the mobile node, the BID is stored in the
	Update. A mobile node MAY change the value of a BID at any		Binding Update List and is sent by the mobile node by means of
	time according to its administrative policy, for instance to		a sub-option of a Binding Update. A mobile node MAY change
	protect its privacy.		the value of a BID at any time according to its administrative
			policy, for instance to protect its privacy.
	The BID can be assigned to either a care-of address or an		The BID can be assigned to either a care-of address or an
	interface depending on implementations so as to keep using		interface depending on implementation choices so as to keep
	the same BID for the same binding even when the status of the		using the same BID for the same binding even when the status
	binding is changed. More details can be found in Section 5.1.		of the binding is changed. More details can be found in
			Section 5.1.
	Primary care-of address		Primary care-of address
	In [6], the primary care-of address is defined as ``the care-of		In [5], the primary care-of address is defined as ``the care-of
	address registered with the mobile node's home agent is called		address registered with the mobile node's home agent is called
	its ``primary'' care-of address''. In this present document,		its ``primary'' care-of address''. In this present document,
	the term is refined as ``the care-of address which is primarily		the term is refined as ``the care-of address which is primarily
	associated with a home address''.		associated with a home address''.
	A mobile node MUST have a primary care-of address all the time.		A mobile node MUST have a primary care-of address all the time.
	Once the primary care-of address becomes invalid, the mobile		Once the primary care-of address becomes invalid, the mobile
	node MUST reselect a primary care-of-address from the multiple		node MUST reselect a primary care-of-address from the set of
	care-of addresses that a mobile node may have at any given		other care-of addresses that it may also own at that time.
	time.
	Primary Interface		Primary Interface
	The interface on which the primary care-of address is assigned.		The interface on which the primary care-of address is assigned.
	Once the primary interface becomes invalid due to movements,		Once the primary interface becomes invalid, the mobile node
	the mobile node MUST re-select a primary interface from the set		MUST re-select a primary interface from the set of interfaces
	of interfaces installed in the mobile node.		installed in the mobile node.
	Binding Unique Identifier sub-option		Binding Unique Identifier sub-option
	The Binding Unique Identifier sub-option is used to carry the		The Binding Unique Identifier sub-option is used to carry the
	BID.		BID.
	Multiple Care-of Addresses Flag (M flag)		Multiple Care-of Addresses Flag (B flag)
	This flag indicates that a Binding Unique Identifier sub-option		This flag indicates that a Binding Unique Identifier sub-option
	is included in the Binding Update Mobility Option field.		is included in the Binding Update Mobility Option field.
	3. Protocol Overview		3. Protocol Overview
	We propose a new identification number to distinguish multiple		We propose a new identification number to distinguish multiple
	bindings pertaining to the same home address. The procedures for		bindings pertaining to the same home address. The procedures for
	the mobile node to register multiple bindings are described in the		the mobile node to register multiple bindings are described in the
	paragraphs below.		paragraphs below.
	3.1. Multiple Care-of Addresses Registration		3.1. Multiple Care-of Addresses Registration
	Once a mobile node gets several IPv6 global addresses on distinct		Once a mobile node gets several IPv6 global addresses on distinct
	interfaces, it MUST select a primary care-of address from the active		interfaces, it MUST select a primary care-of address from the active
	addresses as specified in Section 11.5.3 [6]. After the selection,		addresses as specified in Section 11.5.3 [5]. After the selection,
	the interface which has the primary care-of address becomes the		the interface which has the primary care-of address becomes the
	primary interface for the mobile node.		primary interface for the mobile node.
	After selecting the primary care-of address, the mobile node MUST		After selecting the primary care-of address, the mobile node MUST
	register it with its home agent (home registration). If the mobile		register it with its home agent (home registration). If the mobile
	node wants to register multiple bindings to its home agent, it MUST		node wants to register multiple bindings to its home agent, it MUST
	generate a BID for the primary care-of address and record it into		generate a BID for the primary care-of address and record it into
	the binding update list entry. The mobile node then registers its		the binding update list entry. The mobile node then registers its
	primary care-of address by sending a Binding Update with a Binding		primary care-of address by sending a Binding Update with a Binding
	Unique Identifier sub-option. The M flag MUST be set in the Flag		Unique Identifier sub-option. The B flag MUST be set in the Flag
	field of the Binding Update and the BID MUST be put in the Binding		field of the Binding Update and the BID MUST be put in the Binding
	Unique Identifier sub-option. After receiving the Binding Update,		Unique Identifier sub-option. After receiving the Binding Update,
	the home agent verifies the request and records the binding in its		the home agent verifies the request and records the binding in its
	binding cache. If the newly defined sub-option is present in the		binding cache. If the newly defined sub-option is present in the
	Binding Update, the home agent MUST copy the BID from the Binding		Binding Update, the home agent MUST copy the BID from the Binding
	Update to the corresponding field in the binding entry.		Update to the corresponding field in the binding entry.
	After this home registration, the mobile node can register the rest		After this home registration, the mobile node SHOULD register the
	of care-of addresses to its Home Agent. Even if there is already		rest of care-of addresses to its Home Agent. Even if there is
	an entry for the mobile node, the home agent MUST registers a new		already an entry for the mobile node, the home agent MUST registers a
	binding entry for the BID stored in the Binding Unique Identifier		new binding entry for the BID stored in the Binding Unique Identifier
	sub-option. The registration process is the same as for the		sub-option. The registration process is the same as for the
	registration of the primary care-of address. The mobile node MUST		registration of the primary care-of address. The mobile node MUST
	register multiple care-of addresses respectively.		register multiple care-of addresses independently.
	If the mobile node wish to register its binding with a correspondent		If the mobile node wish to register its binding with a correspondent
	node, it MUST starts return routability operations before sending a		node, it MUST starts return routability operations before sending a
	Binding Update. The mobile node MUST sends CoTI for each care-of		Binding Update. The mobile node MUST sends CoTI for each care-of
	addresses and MUST receive CoT for each care-of addresses. The		addresses and MUST receive CoT for each care-of addresses. The
	mobile node also generates a BID for each care-of addresses to		mobile node also generates a BID for each care-of addresses to
	register them as individual bindings . The registration step		register them as individual bindings. The registration step
	is the same as for the home registration except for calculating		is the same as for the home registration except for calculating
	authenticator with Binding Unique Identifier sub-option as well as		authenticator by using Binding Unique Identifier sub-option as well
	the other sub-options specified in [6].		as the other sub-options specified in [5].
	3.2. Multiple Bindings Management		3.2. Multiple Bindings Management
	The BID is also used as a search key of the binding cache database as		The BID is used as a search key for a corresponding entry in the
	well as a home address. When the home agent checks the binding cache		binding cache in addition to the home address. When the home agent
	database for the mobile node, it searches a corresponding binding		checks the binding cache database for the mobile node, it searches
	entry with the home address and BID of the desired binding. The		a corresponding binding entry with the home address and BID of the
	desired binding can be selected with policy and filter information.		desired binding. The desired binding can be selected with policy
	The capability of searching the desired binding enables load-sharing		and filter information. The capability of searching the desired
	and QoS with flow separation. But this selection and flow separation		binding enables load-sharing and QoS with flow separation. But this
	are out of scope in this draft. If there is no desired binding,		selection and flow separation are out of scope in this draft. If
	it search the binding cache database with the home address as well		there is no desired binding, it search the binding cache database
	as Mobile IPv6. The first matched binding entry may be found, but		with the home address as well as Mobile IPv6. The first matched
	which binding entry is returned for the normal search depends on		binding entry may be found, but it searches the binding cache with
	implementations.		the home address as it would for Mobile IPv6
	If a node has multiple bindings and its packets meant for the		If a node has multiple bindings and its packets meant for the
	mobile node are not delivered correctly, the node can change the		mobile node are not delivered correctly, the node can change the
	binding entry for the mobile node so as to recover the connection		binding entry for the mobile node so as to recover the connection
	immediately. The node can detect a binding invalidation by packets		immediately. The node can detect a binding invalidation by packets
	loss or ICMP error messages such as ICMP_UNREACHABLE. This provides		loss or ICMP error messages such as ICMP_UNREACHABLE. This provides
	redundancy for Mobile IPv6.		redundancy for Mobile IPv6.
	When one of the care-of addresses is changed, the mobile node sends		When one of the care-of addresses is changed, the mobile node sends
	a Binding Update with the new care-of address and the corresponding		a Binding Update with the new care-of address and the corresponding
	BID. The receiver of the Binding Update updates the binding which		BID. The receiver of the Binding Update updates the binding which
	BID fits the BID contained in the received Binding Unique Identifier		BID fits the BID contained in the received Binding Unique Identifier
	sub-option. The mobile node can manage each binding independently		sub-option. The mobile node can manage each binding independently
	owing to BID.		owing to BID.
	Once the mobile node decides to register only one binding, it just		If the mobile node decides to register only one binding, it just
	sends a Binding Update without M flag and a Binding Unique Identifier		sends a Binding Update without B flag and without a Binding Unique
	sub-option (i.e. normal Binding Update). The receiver of the		Identifier sub-option (i.e. normal Binding Update). The receiver
	Binding Update registers only single binding for the mobile node.		of the Binding Update registers only a single binding for the
	If the receiver has multiple bindings, one bindings is registered		mobile node. If the receiver has multiple bindings, one binding is
	without BID and the rest of bindings are deleted.		registered without BID and the rest of bindings are deleted.
	3.3. Returning Home		3.3. Returning Home
	When the mobile node returns home, there are two situations. It is		When the mobile node returns home, there are two situations, since
	because the home agent defends the mobile node's home address by		the home agent defends the mobile node's home address by using
	using proxy neighbor advertisement. It is impossible to utilize		proxy neighbor advertisement. It is impossible to utilize all the
	all the interfaces when one interface is attached to home and the		interfaces when one interface is attached to the home link and the
	others are attached to foreign link. If proxy Neighbor Advertisement		others are attached to foreign link. If proxy Neighbor Advertisement
	for the home address is stopped, packets are always routed to the		for the home address is stopped, packets are always routed to the
	interface attached to the home link. If proxy is not stopped,		interface attached to the home link. If proxy is not stopped,
	packets are never routed to the interface attached to the home link.		packets are never routed to the interface attached to the home link.
	The first situation is when the primary interface is attached to the		The first situation is when the primary interface is attached to the
	home link. In this case, the mobile node MUST de-register all the		home link. In this case, the mobile node MUST de-register all the
	bindings by sending a Binding Update which lifetime set to zero. The		bindings by sending a Binding Update which lifetime set to zero. The
	mobile node MAY NOT put any Binding Unique Identifier sub-options		mobile node MAY NOT put any Binding Unique Identifier sub-options
	in this packet. Then, the receiver deletes all the bindings from		in this packet. Then, the receiver deletes all the bindings from
	skipping to change at page 11, line 5 ¶		skipping to change at page 11, line 5 ¶
	- BID of the binding cache entry. The BID is notified by the		- BID of the binding cache entry. The BID is notified by the
	mobile node by means of a Binding Update sub-option. The value		mobile node by means of a Binding Update sub-option. The value
	MUST be zero if the Binding Update does not contain a BID.		MUST be zero if the Binding Update does not contain a BID.
	4.2. Binding Update Structure and Management		4.2. Binding Update Structure and Management
	Additional items are required for the binding update structure, which		Additional items are required for the binding update structure, which
	are:		are:
	- BID: MUST be generated whenever the mobile node decides to		- BID: MUST be generated whenever the mobile node registers
	register multiple bindings for its home address.		multiple bindings for its home address.
	- Primary flag: MUST be set if the care-of address is primary.		- Primary flag: MUST be set if the care-of address is primary.
	4.3. Messages Format Changes		4.3. Messages Format Changes
	4.3.1. Binding Unique Identifier sub-option		4.3.1. Binding Unique Identifier sub-option
	The Binding Unique Identifier sub-option is included in Binding		The Binding Unique Identifier sub-option is included in Binding
	Update, Binding Acknowledgment, Binding Refresh Request, Binding		Update, Binding Acknowledgment, Binding Refresh Request, Binding
	Error if needed.		Error if needed.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type = TBD | Length = 4 |		| Type = TBD | Length = 4 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Binding Unique ID (BID) | P| Reserved |		| Binding Unique ID (BID) |P| Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
	Type		Type
	Type value for Binding Unique Identifier will be assigned		Type value for Binding Unique Identifier will be assigned
	later.		later.
	Length		Length
	The value MUST be always 4.		The value MUST be always 4.
	Binding Unique ID (BID)		Binding Unique ID (BID)
	skipping to change at page 11, line 48 ¶		skipping to change at page 11, line 48 ¶
	Flag		Flag
	Stop Proxy Neighbor Advertisement (P) Flag		Stop Proxy Neighbor Advertisement (P) Flag
	When this flag is set, the home agent MUST stop		When this flag is set, the home agent MUST stop
	proxy neighbor advertisement for a mobile node.		proxy neighbor advertisement for a mobile node.
	This flag is checked only when a Binding Update		This flag is checked only when a Binding Update
	is for de-registration and the destination of a		is for de-registration and the destination of a
	Binding Update is mobile node's home agent (i.e.		Binding Update is mobile node's home agent (i.e.
	home de-registration). Otherwise, this flag MUST be		home de-registration). Otherwise, this flag MUST be
	ignored.		ignored
	Reserved		Reserved
	15 bit Reserved field. Reserved field must be set with all		15 bit Reserved field. Reserved field must be set with all
	0.		0.
	4.3.2. Binding Update		4.3.2. Binding Update
	If a mobile node wants to register several care-of addresses which		The 'B' flag MUST be set and a Binding Unique Identifier sub-option
	would be bound to a home address, mobile node MUST set 'M' flag and		MUST be included if the mobile node wants to bind multiple care-of
	include a Binding Unique Identifier sub-option.		address to a given home address.
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sequence # |		| Sequence # |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|A|H|L|K|R|M| Reserved | Lifetime |		|A|H|L|K|M|R|B| Reserved | Lifetime |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	. .		. .
	. Mobility options .		. Mobility options .
	. .		. .
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Mobile Router Flag (R)		Multiple Care-of Addresses Flag (B)
	This flag is proposed by the NEMO working group [3].
	Multiple Care-of Addresses Flag (M)
	This flag is used for multiple care-of addresses		This flag is used for multiple care-of addresses
	registration.		registration.
	Reserved		Reserved
	Reserved field is reduced to 11 bits.		Reserved field is reduced to 9 bits.
	4.3.3. Binding Acknowledgment		4.3.3. Binding Acknowledgment
	The message format of Binding Acknowledgment is not changed, but		The message format of Binding Acknowledgment is not changed, but
	operations listed below are added in this draft.		operations listed below are added in this draft.
	A receiver who gets a Binding Update with the 'M' flag set MUST reply		A receiver who gets a Binding Update with the 'B' flag set MUST reply
	with a Binding Acknowledgment if the 'A' flag is also set or in		with a Binding Acknowledgment if the 'A' flag is also set or in
	case of a home registration. The receiver MUST also send a Binding		case of a home registration. The receiver MUST also send a Binding
	Acknowledgment with corresponding error codes if it finds an error		Acknowledgment with corresponding error codes if it finds an error
	while processing the Binding Update and its sub-option described in		while processing the Binding Update and its sub-option described in
	section 4.3.2.		section 4.3.2.
	If a Binding Update has the 'M' flag set and a Binding Unique		If a Binding Update has the 'B' flag set and a Binding Unique
	Identifier sub-option is present, the receiver node MUST reply with a		Identifier sub-option is present, the receiver node MUST reply with a
	Binding Acknowledgment containing the same Binding Unique Identifier		Binding Acknowledgment containing the same Binding Unique Identifier
	sub-option. The mobile node can process the Binding Acknowledgment		sub-option. The mobile node can process the Binding Acknowledgment
	for the particular care-of address identified by the BID set in the		for the particular care-of address identified by the BID set in the
	Binding Unique Identifier sub-option.		Binding Unique Identifier sub-option.
	A new number is defined for handling the 'M' flag:		A new number is defined for handling the 'B' flag:
	140 Conflicting a regular binding and a binding that has BID in		- TBD (144)
	binding cache. The regular binding indicates the binding that		It implies conflicting a regular binding and a binding that has
	does not have BID field. The number is TBD.		BID in binding cache. The regular binding indicates the binding
			that does not have BID field. The status value is TBD.
			4.4. Dynamic Home Agent Address Discovery
			The Dynamic Home Agent Address Discovery (DHAAD) defined in
			RFC3775 [5] is extended so that Mobile Nodes or Mobile Routers only
			register multiple care-of addresses with Home Agents that support
			multiple care-of addresses registration.
			However, we do not provide a solution for Mobile Nodes that would
			like to register multiple care-of addresses only with Correspondant
			Nodes that support multiple care-of addresses registration.
			4.4.1. DHAAD Request
			A new 'B' flag is introduced in the DHAAD Request message in order
			to discover Home Agents supporting the multiple care-of address
			registration.
			0 1 2 3
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Type | Code | Checksum |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Identifier |R|B| Reserved |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Multiple Care-of Addresses Flag (B)
			This flag is set when the mobile node wants to discover Home
			Agents that support multiple care-of addresses registration.
			4.4.2. DHAAD Reply
			A new 'B' flag is introduced in the DHAAD Reply message. When a Home
			Agent receives a DHAAD Request message with the Multiple Care-of
			Addresses support Flag set, it MUST reply with a list of Home Agents
			supporting the multiple care-of addresses registration. The 'B' flag
			MUST be set in the DHAAD Reply.
			0 1 2 3
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Type | Code | Checksum |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Identifier |R|B| Reserved |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			+ +
			. .
			. Home Agent Addresses .
			. .
			+ +
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Mobile Router Flag (R)
			This flag is proposed by the NEMO working group [2].
			Multiple Care-of Addresses Flag (B)
			This flag is set when the Home Agents listed in this message
			support the multiple care-of addresses registration.
			4.4.3. Home Agent Information Option
			A new 'B' flag is introduced in the Home Agent Information Option.
			The home agent SHOULD set the flag if it supports multiple care-of
			addresses registration.
			0 1 2 3
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Type | Length |R|B| Reserved |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Home Agent Preference | Home Agent Lifetime |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Mobile Router Flag (R)
			This flag is proposed by the NEMO working group [2].
			Multiple Care-of Addresses Flag (B)
			This flag is set when the Home Agent supports multiple
			care-of addresses registration.
	5. Mobile Node Operation		5. Mobile Node Operation
	5.1. Management of care-of addresses		5.1. Management of care-of addresses and Binding Unique Identifier
	There are two cases when a mobile node has several care-of addresses:		There are two cases when a mobile node has several care-of addresses:
	- A mobile node uses several physical network interfaces to acquire		- A mobile node uses several physical network interfaces and
	a care-of address.		acquires a care-of address on each of its interfaces.
	- A mobile node uses a single physical network interface, but it		- A mobile node uses a single physical network interface, but
	acquires several addresses from the attached network. Since IPv6		multiple prefixes are announced on the link the interface is
	allows to have several addresses on single network interface,		attached to. Several global addresses are configured on this
	it is possible to get several global address with a network		interface for each of the announced prefixes.
	interface at the attached network.
	The difference between the above two cases is only a number of		The difference between the above two cases is only a number of
	physical network interfaces and therefore does not matter. The		physical network interfaces and therefore does not matter. The
	Identification number is used to distinguish multiple bindings so		Identification number is used to distinguish multiple bindings so
	that the mobile node assigns an identification number for each		that the mobile node assigns an identification number for each
	care-of addresses. How to assign an identification number is up to		care-of addresses. How to assign an identification number is up to
	implementors.		implementors.
	A mobile node assigns a BID to each care-of address when it wants		A mobile node assigns a BID to each care-of address when it wants
	to simultaneously register with its home address. The value should		to simultaneously register with its home address. The value should
	skipping to change at page 13, line 49 ¶		skipping to change at page 15, line 39 ¶
	negative value can not be taken as a BID. If a mobile node has only		negative value can not be taken as a BID. If a mobile node has only
	one care-of address, the assignment of a BID is not needed until it		one care-of address, the assignment of a BID is not needed until it
	has multiple care-of addresses to register with.		has multiple care-of addresses to register with.
	5.2. Sending Binding Update		5.2. Sending Binding Update
	When a mobile node sends a Binding Update to its home agent (i.e.		When a mobile node sends a Binding Update to its home agent (i.e.
	home registration) and the Binding Update is aimed to de-register		home registration) and the Binding Update is aimed to de-register
	the binding, the mobile node MUST check whether the care-of address		the binding, the mobile node MUST check whether the care-of address
	contained in the Binding Update is primary or not. If the care-of		contained in the Binding Update is primary or not. If the care-of
	address is primary one, it MUST set the 'P' flag in the Binding		address is a primary one, it MUST set the 'P' flag in the Binding
	Unique Identifier sub-option. More description about the 'P' flag		Unique Identifier sub-option. More description about the 'P' flag
	can be found in Section 5.3.		can be found in Section 5.3.
	When a mobile node sends a Binding Update, it MUST decide whether it		When a mobile node sends a Binding Update, it MUST decide whether it
	registers multiple care-of addresses or not. However, this decision		registers multiple care-of addresses or not. However, this decision
	is out-of scope in this document. If a mobile node decides not to		is out-of scope in this document. If a mobile node decides not to
	register multiple care-of addresses, it completely follows standard		register multiple care-of addresses, it completely follows standard
	Mobile IPv6 [6].		Mobile IPv6 [5].
	On the other hand, if mobile node needs to register multiple care-of		On the other hand, if the mobile node needs to register multiple
	addresses, the mobile node MUST use BIDs for all care-of addresses		care-of addresses, it MUST use BIDs all the time. The mobile node
	all the time. The mobile node sets M flag in a Binding Update and		sets B flag in a Binding Update and puts a Binding Unique Identifier
	puts a Binding Unique Identifier sub-option into the Option field of		sub-option into the Option field of the Binding Update. The BID is
	the Binding Update. The BID is copied from a Binding Update List		copied from a Binding Update List to the Binding Unique Identifier
	to the Binding Unique Identifier sub-option. If the mobile node		sub-option. If the mobile node registers bindings to a correspondent
	registers bindings to a correspondent node, it MUST sends multiple		node, it MUST sends multiple CoTI for multiple care-of addresses.
	CoTI for multiple care-of addresses. After getting CoTs, it sends		After getting CoTs, it sends Binding Updates with the 'B' flag set
	Binding Updates with the 'M' flag set and a Binding Unique Identifier		and a Binding Unique Identifier sub-option for all care-of addresses,
	sub-option for all care-of addresses, one by one. In any case,		one by one. In any case, the mobile node MUST set the 'A' flag in
	the mobile node MUST set the 'A' flag in Binding Updates and MUST		Binding Updates and MUST wait for a Binding Acknowledgment to confirm
	wait for a Binding Acknowledgment to confirm the registration was		the registration was successful as described in section 5.5.
	successful as described in section 5.5.
	Note that there is no optimization such as registering multiple		Note that there is no optimization such as registering multiple
	care-of addresses by using a single Binding Update, because the		care-of addresses by using a single Binding Update, because the
	current Mobile IPv6 specification does not allow to send multiple		current Mobile IPv6 specification does not allow to send multiple
	bindings by means of a single Binding Update.		bindings by means of a single Binding Update.
	5.3. De-registration		5.3. De-registration
	When a mobile node decides to delete all bindings for its home		When a mobile node decides to delete all bindings for its home
	address, it sends a regular de-registration Binding Update (i.e.		address, it sends a regular de-registration Binding Update (i.e.
	unset of 'M' flag and exclusion of a Binding Unique Identifier		unset of 'B' flag and exclusion of a Binding Unique Identifier
	sub-option). See Section 6.2 for details.		sub-option). See Section 6.2 for details.
	If a mobile node wants to delete a particular binding from its home		If a mobile node wants to delete a particular binding from its home
	agent and correspondent nodes, it follows the operations below.		agent and correspondent nodes, it follows the operations below.
	When a mobile node is attached to its home link by one of its network		When a mobile node is attached to its home link by one of its network
	interfaces, it MUST de-register an appropriate binding. If a binding		interfaces, it MUST de-register an appropriate binding. If a binding
	of a primary care-of address becomes invalid in terms of the mobile		of a primary care-of address becomes invalid after the mobile node
	node's returning home, it MUST set the 'P' flag in a Binding Unique		returns home, it MUST set the 'P' flag in a Binding Unique Identifier
	Identifier sub-option. Otherwise, the 'P' flag MUST NOT be set. If		sub-option. Otherwise, the 'P' flag MUST NOT be set. If the 'P'
	the 'P' flag is set, the home agent stop proxy neighbor advertisement		flag is set, the home agent stop proxy neighbor advertisement for the
	for the mobile node. If the receiver is not the Home Agent but a		mobile node. The 'P' flag is ignored if the receiver is not the home
	Correspondent Node, it ignores the 'P' flag.		agent.
	When the mobile node's primary interface gets attached to the home		When the mobile node's primary interface gets attached to the home
	link by its primary (see Figure 2 and Figure 4 in Appendix A), the		link (see Figure 3 and Figure 5 in Appendix B), the Mobile Node MUST
	Mobile Node MUST start de-registration processing to its home agent		start de-registration processing to its home agent as indicated in
	as indicated in Mobile IPv6. The home agent deletes all bindings		Mobile IPv6. The home agent deletes all bindings for the mobile node
	for the mobile node and stops intercepting packets meant for the		and stops intercepting packets meant for the mobile node. Although
	mobile node. Although the mobile node MUST deletes the binding at		the mobile node MUST deletes the binding at correspondent nodes
	correspondent nodes as well, the node can still keep the binding of		as well, the node can still keep the binding of the non-primary
	the non-primary interface active at the correspondent nodes. In		interface active at the correspondent nodes. In such case, the
	such case, the mobile node still receives packets at a non-primary		mobile node still receives packets at a non-primary interface
	interface attached to a foreign link thanks to route optimization.		attached to a foreign link thanks to route optimization. The mobile
	The mobile node also receives packets at the primary interface		node also receives packets at the primary interface attached to the
	attached to the home link when correspondent nodes does not use route		home link when correspondent nodes does not use route optimization.
	optimization.
	On the other hand, when the mobile node's non-primary interface gets		On the other hand, when the mobile node's non-primary interface
	attached back to the home link (see Figure 3 in Appendix A), the		gets attached back to the home link (see Figure 4 in Appendix B),
	MN MUST delete only the particular binding from its home agent and		the mobile node MUST delete only the particular binding from its
	correspondent nodes. The home agent does not delete all bindings		home agent and correspondent nodes. The home agent does not delete
	and does not stop proxy neighbor advertisement for the mobile		all bindings and does not stop proxy neighbor advertisement for the
	node. Therefore, the mobile node no longer receives packets at the		mobile node. Therefore, the mobile node no longer receives packets
	non-primary interface attached to the home link. All packets are		at the non-primary interface attached to the home link. All packets
	routed to other interfaces attached to a foreign link. If the mobile		are routed to other interfaces attached to a foreign link. If the
	node is eager to receive packets at the non-primary interface at the		mobile node is eager to receive packets at the non-primary interface
	home link, it MUST re-select the interface as the primary one.		at the home link, it MUST re-select the interface as the primary one.
	5.4. Using Alternate Care-of Address		5.4. Using Alternate Care-of Address
	A mobile node can use an alternate care-of address in the following		A mobile node can use an alternate care-of address in the following
	situations.		situations.
	- One care-of address becomes invalid (.e.g because the link where		- One care-of address becomes invalid (e.g because the link where
	it is attached is no longer available) and MUST be deleted.		it is attached is no longer available) and MUST be deleted.
	In such case, the mobile node can not sends a Binding Update		In such case, the mobile node can not sends a Binding Update
	from the care-of address because the interface's link is lost.		from the care-of address because the interface's link is lost.
	The mobile node needs to de-register the remote binding of the		The mobile node needs to de-register the remote binding of the
	care-of address through one of its active care-of addresses.		care-of address through one of its active care-of addresses.
	- A mobile node has multiple interfaces, but it wants to sends		- A mobile node has multiple interfaces, but it wants to sends
	Binding Updates for all care-of addresses from a specific		Binding Updates for all care-of addresses from a specific
	interface which has wider bandwidth depending on interface's		interface which has wider bandwidth depending on interface's
	characteristics. A mobile node does not want to send a lot of		characteristics. A mobile node does not want to send a lot of
	skipping to change at page 16, line 10 ¶		skipping to change at page 17, line 42 ¶
	Alternate Care-of Address sub-option and Binding Unique Identifier		Alternate Care-of Address sub-option and Binding Unique Identifier
	sub-option. The processing of Alternate Care-of Address sub-option		sub-option. The processing of Alternate Care-of Address sub-option
	is described in the Mobile IPv6 specification. If there is an		is described in the Mobile IPv6 specification. If there is an
	Alternate Care-of Address sub-option, the BID in a Binding Unique		Alternate Care-of Address sub-option, the BID in a Binding Unique
	Identifier sub-option is assigned for the care-of address in the		Identifier sub-option is assigned for the care-of address in the
	Alternate Care-of Address sub-option.		Alternate Care-of Address sub-option.
	5.5. Receiving Binding Acknowledgment		5.5. Receiving Binding Acknowledgment
	The verification of a Binding Acknowledgment is the same as in Mobile		The verification of a Binding Acknowledgment is the same as in Mobile
	IPv6 (section 11.7.3 of [6]). The operation for sending a Binding		IPv6 (section 11.7.3 of [5]). The operation for sending a Binding
	Acknowledgment is described in 6.3.		Acknowledgment is described in 6.3.
	If a mobile node sends a Binding Update with a Binding Unique		If a mobile node sends a Binding Update with a Binding Unique
	Identifier sub-option, a Binding Acknowledgment MUST have a		Identifier sub-option, a Binding Acknowledgment MUST have a Binding
	Binding Unique Identifier sub-option in Mobility options field. If		Unique Identifier sub-option in the Mobility options field. If
	there is no such sub-option, the originator node of this Binding		there is no such sub-option, the originator node of this Binding
	Acknowledgment might not recognize the Binding Unique Identifier		Acknowledgment might not recognize the Binding Unique Identifier
	sub-option. The mobile node SHOULD stop registering multiple care-of		sub-option. The mobile node SHOULD stop registering multiple care-of
	addresses by using a Binding Unique Identifier sub-option.		addresses by using a Binding Unique Identifier sub-option. If the
			originator is the Home Agent, the mobile node MAY perform DHAAD to
			discover a new Home Agent supporting the multiple care-of address
			registration.
	If a Binding Unique Identifier sub-option is present, the mobile node		If a Binding Unique Identifier sub-option is present, the mobile
	checks the Status field of the Binding Acknowledgment. If the status		node checks the Status field of the Binding Acknowledgment. If
	code indicates successful registration (1), the originator registers		the status code indicates successful registration (below 128), the
	a binding information and BID for the mobile node successfully.		originator registers a binding information and BID for the mobile
			node successfully.
	If the status code is not zero regardless of Binding Unique		If the status code is not zero regardless of Binding Unique
	Identifier sub-option availability in BA, the mobile node proceeds an		Identifier sub-option availability in BA, the mobile node proceeds an
	appropriate operations according to the status code.		relevant operations according to the status code.
	If the status code is 140, the mobile node has already registered a		If the status code is 144, the mobile node has already registered a
	regular binding before sending a Binding Update with a Binding Unique		regular binding before sending a Binding Update with a Binding Unique
	Identifier sub-option. In such case, the mobile node SHOULD stop		Identifier sub-option. In such case, the mobile node SHOULD stop
	sending Binding Updates without BID.		sending Binding Updates without BID.
	5.6. Receiving Binding Refresh Request		5.6. Receiving Binding Refresh Request
	The verification of a Binding Refresh Request is the same as in		The verification of a Binding Refresh Request is the same as in
	Mobile IPv6 (section 11.7.4 of [6]). The operation of sending a		Mobile IPv6 (section 11.7.4 of [5]). The operation of sending a
	Binding Refresh Request is described in section 6.4.		Binding Refresh Request is described in section 6.4.
	If a mobile node receives a Binding Refresh Request with a Binding		If a mobile node receives a Binding Refresh Request with a Binding
	Unique Identifier sub-option, this Binding Refresh Request requests		Unique Identifier sub-option, this Binding Refresh Request requests
	a binding indicated by the BID. The mobile node SHOULD update only		a binding indicated by the BID. The mobile node SHOULD update only
	the respective binding. The mobile node MUST put a Binding Unique		the respective binding. The mobile node MUST put a Binding Unique
	Identifier sub-option into a Binding Update.		Identifier sub-option into a Binding Update.
	If no Binding Unique Identifier sub-option is present in a Binding		If no Binding Unique Identifier sub-option is present in a Binding
	Refresh Request, the mobile node sends a Binding Update according		Refresh Request, the mobile node sends a Binding Update according
	skipping to change at page 17, line 13 ¶		skipping to change at page 18, line 49 ¶
	hand, if the mobile node does not have any Binding Update List entry		hand, if the mobile node does not have any Binding Update List entry
	for the requesting node, the mobile node needs to register either		for the requesting node, the mobile node needs to register either
	a single binding or multiple bindings depending on its binding		a single binding or multiple bindings depending on its binding
	management policy.		management policy.
	5.7. Receiving Binding Error		5.7. Receiving Binding Error
	When a mobile node receives a Binding Error with a Binding Unique		When a mobile node receives a Binding Error with a Binding Unique
	Identifier sub-option, the message is for a binding indicated by the		Identifier sub-option, the message is for a binding indicated by the
	BID in the Binding Unique Identifier sub-option. Further operations		BID in the Binding Unique Identifier sub-option. Further operations
	except for the text below are identical as in [6]. The operation for		except for the text below are identical as in [5]. The operation for
	sending BE is described in the section 6.5.		sending BE is described in the section 6.5.
	When a mobile node receives a Binding Error with Status field set		When a mobile node receives a Binding Error with Status field set
	to 2 (unrecognized MH Type value) , it MAY stop trying to register		to 2 (unrecognized MH Type value) , it MAY stop trying to register
	multiple care-of addresses and registers only primary care-of address		multiple care-of addresses and registers only primary care-of address
	as performed in Mobile IPv6.		as performed in Mobile IPv6.
	6. Home Agent and Correspondent Node Operation		6. Home Agent and Correspondent Node Operation
	6.1. Searching Binding Cache with Binding Unique Identification		6.1. Searching Binding Cache with Binding Unique Identification
	skipping to change at page 17, line 46 ¶		skipping to change at page 19, line 35 ¶
	If a correspondent node searches the binding with the home address		If a correspondent node searches the binding with the home address
	and BID2, it gets binding2 for this mobile node.		and BID2, it gets binding2 for this mobile node.
	binding1 [a:b:c:d::EUI care-of address1 BID1]		binding1 [a:b:c:d::EUI care-of address1 BID1]
	binding2 [a:b:c:d::EUI care-of address2 BID2]		binding2 [a:b:c:d::EUI care-of address2 BID2]
	binding3 [a:b:c:d::EUI care-of address3 BID3]		binding3 [a:b:c:d::EUI care-of address3 BID3]
	A correspondent node basically learns the BID when it receives a		A correspondent node basically learns the BID when it receives a
	Binding Unique Identifier sub-option. At the time, the correspondent		Binding Unique Identifier sub-option. At the time, the correspondent
	node MUST look up its binding cache database with the home address		node MUST look up its binding cache database with the home address
	and the BID retrieved from Binding Update. If the correspondent node		and the BID retrieved from Binding Update. If the correspondent
	does not know the BID, it searches a binding with only a home address		node does not know the BID, it searches a binding with only a home
	as performed in Mobile IPv6. In such case, the first matched binding		address as performed in Mobile IPv6. In such case, the first matched
	MAY be found. But which binding entry is returned for the normal		binding is found. But which binding entry is returned for the normal
	search depends on implementations. If the correspondent node does		search depends on implementations. If the correspondent node does
	not desire to use multiple bindings for a mobile node, it can simply		not desire to use multiple bindings for a mobile node, it can simply
	ignore the BID.		ignore the BID.
	6.2. Receiving Binding Update		6.2. Receiving Binding Update
	If a Binding Update has neither 'M' flag set nor a Binding Unique		If a Binding Update has neither 'B' flag set nor a Binding Unique
	Identifier, the processing of the regular Binding Update is the same		Identifier, the processing of the regular Binding Update is the same
	as in [6]. But if the receiver already has multiple bindings for the		as in [5]. But if the receiver already has multiple bindings for the
	home address, it MUST overwrite existing bindings for the mobile node		home address, it MUST overwrite all existing bindings for the mobile
	with the received binding. As the result, the receiver node MUST		node with the received binding. As a result, the receiver node MUST
	have only a binding for the mobile node. If the Binding Update is		have only a binding for the mobile node. If the Binding Update is
	for de-registration, the receiver MUST delete all existing bindings		for de-registration, the receiver MUST delete all existing bindings
	for the mobile node.		for the mobile node.
	On the other hand, if a Binding Update contains a Binding Unique		On the other hand, if a Binding Update contains a Binding Unique
	Identifier sub-option or the 'M' flag is set, a receiver node MUST		Identifier sub-option or the 'B' flag is set, a receiver node MUST
	operate additional validations as follows:		operate additional validations as follows:
	- A receiver node MUST validate the Binding Update according to		- A receiver node MUST validate the Binding Update according to
	section 9.5.1 of [6].		section 9.5.1 of [5].
	- If the Binding Update has the 'M' flag set at the Flag field, a		- If the Binding Update has the 'B' flag set at the Flag field, a
	Binding Unique Identifier sub-option MUST be present in Mobility		Binding Unique Identifier sub-option MUST be present in Mobility
	options field of the Binding Update.		options field of the Binding Update.
	- If there is no Binding Unique Identifier sub-option with the		- If there is no Binding Unique Identifier sub-option with the
	'M' flag set, the receiver node MUST silently drop the Binding		'B' flag set, the receiver node MUST silently drop the Binding
	Update.		Update.
	- If the Binding Unique Identifier sub-option is present, the		- If the Binding Unique Identifier sub-option is present, the
	receiver node MUST process the Binding Update.		receiver node MUST process the Binding Update.
	- If the Lifetime field is not zero, the receiver node registers a		- If the Lifetime field is not zero, the receiver node registers a
	binding that includes the BID as a mobile node's binding.		binding that includes the BID as a mobile node's binding.
	* If the receiver does not have any binding for the mobile		* If the receiver does not have any binding for the mobile
	node, it registers a binding which includes BID field.		node, it registers a binding which includes BID field.
	* If the receiver has a regular binding which does not have		* If the receiver has a regular binding which does not have
	BID for the mobile node, it de-registers the regular binding		BID for the mobile node, it de-registers the regular binding
	and registers a new binding including BID according to the		and registers a new binding including BID according to the
	Binding Update. In this case, the receiver MUST send Binding		Binding Update. In this case, the receiver MUST send Binding
	Acknowledgment with status code set to 140.		Acknowledgment with status code set to 144.
	* If the receiver node has already registered the binding which		* If the receiver node has already registered the binding which
	BID is matched with requesting BID , then it MUST update		BID is matched with requesting BID , then it MUST update
	the binding up-to-date with the Binding Update. Meanwhile,		the binding up-to-date with the Binding Update. Meanwhile,
	if the receiver does not have a binding entry which BID is		if the receiver does not have a binding entry which BID is
	matched with the requesting BID, it registers a new binding		matched with the requesting BID, it registers a new binding
	for the BID.		for the BID.
	- If Lifetime field is zero, the receiver node deletes the		- If Lifetime field is zero, the receiver node deletes the
	registering binding entry which BID is same as BID sent by the		registering binding entry which BID is same as BID sent by the
	Binding Unique Identifier sub-option. If the receiver node		Binding Unique Identifier sub-option. If the receiver node
	does not have appropriate binding which BID is matched with the		does not have appropriate binding which BID is matched with the
	Binding Update, it ignores the Binding Update.		Binding Update, it MUST reject this de-registration Binding
			Update. If the receiver is a Home Agent, it SHOULD also return a
			Binding Acknowledgement to the mobile node, in which the Status
			field is set to 133 (not home agent for this mobile node).
	Note if the mobile node sends multiple Binding Updates with a		Note if the mobile node sends multiple Binding Updates with a
	different BID but for same care-of address (i.e. same home address,		different BID but for same care-of address (i.e. same home address,
	same care-of address, and different BID) , the receiver SHOULD		same care-of address, and different BID) , the receiver SHOULD
	register both bindings into its binding cache.		register both bindings into its binding cache.
	6.3. Sending Binding Acknowledgment		6.3. Sending Binding Acknowledgment
	If a Binding Update does not contain a Binding Unique Identifier		If a Binding Update does not contain a Binding Unique Identifier
	sub-option, the receiver, either a correspondent node or a home		sub-option, the receiver, either a correspondent node or a home
	agent, MUST reply with a Binding Acknowledgment according to section		agent, MUST reply with a Binding Acknowledgment according to section
	9.5.4 of [6]. Otherwise, whenever the BID sub-option, the receiver		9.5.4 of [5]. Otherwise, whenever the BID sub-option is present, the
	MUST follow the additional procedure below. The receiver MUST reply		receiver MUST follow the additional procedure below. The receiver
	with a Binding Acknowledgment whether the 'A' flag is set or not in		MUST reply with a Binding Acknowledgment whether the 'A' flag is set
	Binding Update.		or not in the Binding Update.
	If the receiver successfully registers a binding for the BID stored		If the receiver successfully registers a binding for the BID stored
	in a Binding Unique Identifier sub-option, it returns a Binding		in a Binding Unique Identifier sub-option, it returns a Binding
	Acknowledgment with Status field set to '0' (Successful registration)		Acknowledgment with Status field set to successful value (0 to 128)
	and a Binding Unique Identifier sub-option copied from the received		and a Binding Unique Identifier sub-option copied from the received
	Binding Update. If the receiver deletes the existing binding which		Binding Update. If the receiver deletes the existing binding which
	does not have a BID and registers a new binding for the BID, it MUST		does not have a BID and registers a new binding for the BID, it MUST
	return a Binding Acknowledgment with Status field set to '140'. On		return a Binding Acknowledgment with Status field set to '144'. On
	the other hand, if the node encounters an error during the processing		the other hand, if the node encounters an error during the processing
	of a Binding Update, it must return a Binding Acknowledgment with an		of a Binding Update, it must return a Binding Acknowledgment with an
	appropriate error number as described in [6]. The node SHOULD put a		appropriate error number as described in [5]. The node SHOULD put a
	Binding Unique Identifier sub-option if the BID is available for the		Binding Unique Identifier sub-option if the BID is available for the
	Binding Acknowledgment.		Binding Acknowledgment.
	6.4. Sending Binding Refresh Request		6.4. Sending Binding Refresh Request
	When either a correspondent node or Home Agent notices that		When either a correspondent node or Home Agent notices that
	a registered binding will be expired soon, it SHOULD send a		a registered binding will be expired soon, it SHOULD send a
	Binding Refresh Request. If the registered binding has BID, the		Binding Refresh Request. If the registered binding has BID, the
	correspondent node SHOULD contain a Binding Unique Identifier		correspondent node SHOULD contain a Binding Unique Identifier
	sub-option in the Binding Refresh Request. Then, the correspondent		sub-option in the Binding Refresh Request. Then, the correspondent
	node can receive a Binding Update with a Binding Unique Identifier		node can receive a Binding Update with a Binding Unique Identifier
	sub-option and can update only the particular binding. If the		sub-option and can update only the particular binding. If the
	registered binding does not have BID, then the correspondent node		registered binding does not have BID, then the correspondent node
	sends a Binding Refresh Request without the sub-option.		sends a Binding Refresh Request without the sub-option.
	6.5. Sending Binding Error		6.5. Sending Binding Error
	When a correspondent node sends a Binding Error with Status field		When a correspondent node sends a Binding Error with Status field
	set to 1 (Unrecognized MH Type value), it MAY put a Binding Unique		set to 2 (Unrecognized MH Type value), it MAY put a Binding Unique
	Identifier sub-option into Mobility Options field if BID is available		Identifier sub-option into Mobility Options field if BID is available
	in a received binding message.		in a received binding message.
	When a correspondent node receives data packets with a home address		When a correspondent node receives data packets with a home address
	destination option, it verifies the IPv6 source address field. If		destination option, it verifies the IPv6 source address field. If
	the source address is not registered in the correspondent node's		the source address is not registered in the correspondent node's
	binding cache, the correspondent node MUST return a Binding Error		binding cache, the correspondent node MUST return a Binding Error
	to the sender with the status set to zero (Unknown binding for Home		to the sender with the status set to zero (Unknown binding for Home
	Address destination option). The correspondent node can not put a		Address destination option). The correspondent node can not put a
	Binding Unique Identifier sub-option, because there is no binding		Binding Unique Identifier sub-option, because there is no binding
	cache entry for the source address.		cache entry for the source address.
	7. Network Mobility Applicability		7. Network Mobility Applicability
	Support of multihomed mobile routers is advocated in the NEMO working		Support of multihomed mobile routers is advocated in the NEMO working
	group (see R12 ``The solution MUST function for multihomed MR and		group (see R12 ``The solution MUST function for multihomed MR and
	multihomed mobile networks'' in [4]).		multihomed mobile networks'' in [3]).
			Issues regarding mobile routers with multiple interfaces and other
			multihoming configurations are documented in [8].
	Since the binding management mechanisms are the same for a mobile		Since the binding management mechanisms are the same for a mobile
	host operating Mobile IPv6 and for a mobile router operating NEMO		host operating Mobile IPv6 and for a mobile router operating NEMO
	Basic Support [3], our extensions can also be used to deal with		Basic Support [2], our extensions can also be used to deal with
	multiple care-of addresses registration sent from a multihomed mobile		multiple care-of addresses registration sent from a multihomed mobile
	router.		router.
	A mobile router MUST NOT use the 'P' flag when its home agent does		A mobile router MUST NOT use the 'P' flag when its home agent does
	not use proxy neighbor advertisement to intercept packets destined to		not use proxy neighbor advertisement to intercept packets destined
	the mobile router. This situation is occurred when the home link is		to the mobile router. This situation occurrs when the home link
	configured as a virtual home link in terms of extended home address		is configured as a virtual home link as detailed in extended home
	described in [9].		address described in [10].
	A. Example Configurations		A. A Scenario: Access both Carrier Packet Network and the Internet
	In this section, we describes typical scenarios when a mobile		This scheme can be applied to many scenarios such as described
	node has multiple network interfaces and acquires multiple care-of		in [4]. Additionally, there is a specific scenario where this scheme
	addresses bound to a home address.		is specially required.
			A carrier often provides an independent networks from the Internet.
			For example, a Japanese carrier, NTT, provides a Flet's network
			for ADSL and FTTH users. The Flet's network is isolated from the
			Internet and is independent from the ISP, but can be accessed only
			from the NTT's ADSL and the FTTH physical lines.
			Similar services are well expected to mobile wireless services. When
			a mobile node has a W-CDMA and a 802.11b interfaces with the network
			topology described in Figure 1, application servers limit connection
			only from the W-CDMA celluler network.
			In such case, even if a mobile node is armed with Mobile IPv6, the
			application servers will reject the connection from 802.11b. If the
			mobile node intelligently selects the W-CDMA for the application
			servers, the mobile node can use 802.11b for other traffic. The
			mobile node simply uses this scheme.
			+-------------------------+
			| +-------------+ |
			| |appl. servers| |
			| +------+------+ |
			+----+ | | |
			| CN | | service networks |
			+--+-+ | ---------------- |
			| | | |
			+---+------+ | +--+-+ |
			+------+ Internet |--+---+---+ HA +--+ |
			802.11b| +----------+ | | +----+ | |
			CoA2| | | Home Link |
			+--+--+ | + ---+------ |
			| MN +=============Access Servers |
			+-----+ CoA1 | |
			W-CDMA +-------------------------+
			W-CDMA Packet Network
			Figure 1: Service operated by a combination of a Packet
			Network and the Internet.
			B. Example Configurations
			In this section, we describe typical scenarios when a mobile node has
			multiple network interfaces and acquires multiple care-of addresses
			bound to a home address.
	The home address of the mobile node (MN in figures) is a:b:c:d::EUI.		The home address of the mobile node (MN in figures) is a:b:c:d::EUI.
	MN has 3 different interfaces and possibly acquires care-of addresses		MN has 3 different interfaces and possibly acquires care-of addresses
	1-3 (CoA1, CoA2, CoA3). The MN assigns BID1, BID2 and BID3 to each		1-3 (CoA1, CoA2, CoA3). The MN assigns BID1, BID2 and BID3 to each
	care-of addresses.		care-of addresses.
	Figure 1 depicts the scenario where all interfaces of the mobile node		Figure 2 depicts the scenario where all interfaces of the mobile node
	are attached to foreign links. After binding registrations, the home		are attached to foreign links. After binding registrations, the home
	agent (HA) and the correspondent node (CN) have the binding entries		agent (HA) and the correspondent node (CN) have the binding entries
	listed in Figure 1 in their binding cache database. The mobile node		listed in Figure 2 in their binding cache database. The mobile node
	can utilize all the interfaces.		can utilize all the interfaces.
	+----+		+----+
	| CN |		| CN |
	+--+-+		+--+-+
	|		|
	+---+------+ +----+		+---+------+ +----+
	+------+ Internet |----------+ HA |		+------+ Internet |----------+ HA |
	| +----+---+-+ +--+-+		| +----+---+-+ +--+-+
	CoA2| | | | Home Link		CoA2| | | | Home Link
	skipping to change at page 21, line 46 ¶		skipping to change at page 24, line 46 ¶
	Binding Cache Database:		Binding Cache Database:
	Home Agent's binding (Proxy neighbor advertisement is active)		Home Agent's binding (Proxy neighbor advertisement is active)
	binding [a:b:c:d::EUI care-of address1 BID1]		binding [a:b:c:d::EUI care-of address1 BID1]
	binding [a:b:c:d::EUI care-of address2 BID2]		binding [a:b:c:d::EUI care-of address2 BID2]
	binding [a:b:c:d::EUI care-of address3 BID3]		binding [a:b:c:d::EUI care-of address3 BID3]
	Correspondent Node's binding		Correspondent Node's binding
	binding [a:b:c:d::EUI care-of address1 BID1]		binding [a:b:c:d::EUI care-of address1 BID1]
	binding [a:b:c:d::EUI care-of address2 BID2]		binding [a:b:c:d::EUI care-of address2 BID2]
	binding [a:b:c:d::EUI care-of address3 BID3]		binding [a:b:c:d::EUI care-of address3 BID3]
	Figure 1: Multiple Interfaces are attached to Foreign Link		Figure 2: Multiple Interfaces are attached to Foreign Link
	Figure 2 depicts the scenario where the primary interface of MN is		Figure 3 depicts the scenario where the primary interface of MN is
	attached to the home link.		attached to the home link.
	After bindings registration, HA and CN have the binding entries		After the successful registration of the binding, HA and CN have the
	listed in Figure 2 in their binding cache database. MN can		binding entries listed in Figure 3 in their binding cache database.
	communicate with the HA through only the primary interface attached		MN can communicate with the HA through only the primary interface
	to the home link. On the other hand, the mobile node can communicate		attached to the home link. On the other hand, the mobile node can
	with CN by using route optimization. Even when MN is attached to the		communicate with CN by using route optimization. Even when MN is
	home link, it can still send Binding Updates for other active care-of		attached to the home link, it can still send Binding Updates for
	addresses (CoA2 and CoA3). If CN has bindings, packets are routed		other active care-of addresses (CoA2 and CoA3). If CN has bindings,
	to each care-of addresses directly. Any packets arrived at HA are		packets are routed to each care-of addresses directly. Any packet
	routed to the primary interface.		arrived at HA are routed to the primary interface.
	+----+		+----+
	| CN |		| CN |
	+--+-+		+--+-+
	|		|
	+---+------+ +----+		+---+------+ +----+
	+------+ Internet |----------+ HA |		+------+ Internet |----------+ HA |
	| +--------+-+ +--+-+		| +--------+-+ +--+-+
	CoA2| | | Home Link		CoA2| | | Home Link
	+--+--+ | --+---+------		+--+--+ | --+---+------
	skipping to change at page 22, line 36 ¶		skipping to change at page 25, line 36 ¶
	CoA3| +---|-----------+		CoA3| +---|-----------+
	+---------------+		+---------------+
	Binding Cache Database:		Binding Cache Database:
	Home Agent's binding (Proxy neighbor advertisement is inactive)		Home Agent's binding (Proxy neighbor advertisement is inactive)
	none		none
	Correspondent Node's binding		Correspondent Node's binding
	binding [a:b:c:d::EUI care-of address2 BID2]		binding [a:b:c:d::EUI care-of address2 BID2]
	binding [a:b:c:d::EUI care-of address3 BID3]		binding [a:b:c:d::EUI care-of address3 BID3]
	Figure 2: Primary Interface is attached to Home Link		Figure 3: Primary Interface is attached to Home Link
	Figure 3 depicts the scenario where a non-primary interface of a MN		Figure 4 depicts the scenario where a non-primary interface of a MN
	is attached to the home link.		is attached to the home link.
	The HA and the CN have the binding entries listed in Figure 3 in		The HA and the CN have the binding entries listed in Figure 4 in
	their binding cache database. MN can not utilize the non-primary		their binding cache database. MN can not utilize the non-primary
	interface attached to the home link, because the HA still defends the		interface attached to the home link, because the HA still defends the
	home address of the MN by proxy neighbor advertisements. All packets		home address of the MN by proxy neighbor advertisements. All packets
	routed to the home link are intercepted by the HA and tunneled to		routed to the home link are intercepted by the HA and tunneled to
	the other interfaces attached to the foreign link according to the		the other interfaces attached to the foreign link according to the
	binding entries.		binding entries.
	Figure 4 depicts the scenario where primary and a non-primary		Figure 5 depicts the scenario where primary and a non-primary
	interface of MN are attached to the home link. The HA and the CN		interface of MN are attached to the home link. The HA and the CN
	+----+		+----+
	| CN |		| CN |
	+--+-+		+--+-+
	|		|
	+---+------+ +----+		+---+------+ +----+
	+------+ Internet |----------+ HA |		+------+ Internet |----------+ HA |
	| +----+-----+ +--+-+		| +----+-----+ +--+-+
	CoA2| | | Home Link		CoA2| | | Home Link
	+--+--+ | --+---+------		+--+--+ | --+---+------
	skipping to change at page 23, line 26 ¶		skipping to change at page 26, line 26 ¶
	+---------------------------+		+---------------------------+
	Binding Cache Database:		Binding Cache Database:
	Home Agent's binding (Proxy neighbor advertisement is active)		Home Agent's binding (Proxy neighbor advertisement is active)
	binding [a:b:c:d::EUI care-of address1 BID1]		binding [a:b:c:d::EUI care-of address1 BID1]
	binding [a:b:c:d::EUI care-of address2 BID2]		binding [a:b:c:d::EUI care-of address2 BID2]
	Correspondent Node's binding		Correspondent Node's binding
	binding [a:b:c:d::EUI care-of address1 BID1]		binding [a:b:c:d::EUI care-of address1 BID1]
	binding [a:b:c:d::EUI care-of address2 BID2]		binding [a:b:c:d::EUI care-of address2 BID2]
	Figure 3: One of Non-Primary Interfaces is attached to Home Link		Figure 4: One of Non-Primary Interfaces is attached to Home Link
	have the binding entries listed in Figure 4 in their binding cache		have the binding entries listed in Figure 5 in their binding cache
	database. The MN can not use the non-primary interface attached to a		database. The MN can not use the non-primary interface attached to a
	foreign link unless a CN has a binding for the non-primary interface.		foreign link unless a CN has a binding for the non-primary interface.
	All packets which arrive at the HA are routed to one of interfaces		All packets which arrive at the HA are routed to one of interfaces
	attached to the MN. The HA decides an interface anyway, for example,		attached to the MN. The HA decides an interface anyway, for example,
	by using policy and filters.		by using policy and filters.
	+----+		+----+
	| CN |		| CN |
	+--+-+		+--+-+
	|		|
	skipping to change at page 24, line 25 ¶		skipping to change at page 27, line 25 ¶
	+--+--+ |		+--+--+ |
	| |		| |
	+---------------------------+		+---------------------------+
	Binding Cache Database:		Binding Cache Database:
	Home Agent's binding (Proxy neighbor advertisement is inactive)		Home Agent's binding (Proxy neighbor advertisement is inactive)
	none		none
	Correspondent Node's binding		Correspondent Node's binding
	binding [a:b:c:d::EUI care-of address2 BID2]		binding [a:b:c:d::EUI care-of address2 BID2]
	Figure 4: Primary and Non-Primary Interfaces are		Figure 5: Primary and Non-Primary Interfaces are
	attached to Home Link		attached to Home Link
			C. Changes
			- Updating packet formats. M flag is re-named to B flag as
			suggested by [11].
			- Adding extended operations for DHAAD packets in terms of finding
			Home Agent supporting multiple CoAs registration.
	Acknowledgments		Acknowledgments
	The authors would like to thank Julien Charbon, Susumu Koshiba,		The authors would like to thank Julien Charbon, Susumu Koshiba,
	Hiroki Matutani, Koshiro Mitsuya, Nicolas Montavont, Koji Okada,		Hiroki Matutani, Koshiro Mitsuya, Nicolas Montavont, Koji Okada,
	Masafumi Watari (in alphabetical order), the nacm group at KEIO		Masafumi Watari (in alphabetical order), the Jun Murai Lab. at KEIO
	University, and WIDE project for their contributions.		University, and WIDE project for their contributions.
	References		The authors acknowledge Romain Kuntz from Keio University and WIDE
			for providing the texts of the DHAAD operation and reviewing this
			draft.
	[1] M. Baker, X. Zhao, S. Cheshire, and J. Stone. Supporting		References
	mobility in mosquitonet. In Proceedings of the 1996 USENIX
	Conference, Jan. 1996.
	[2] S. Deering and R. Hinden. Internet Protocol, Version 6 (ipv6)		[1] S. Deering and R. Hinden. Internet Protocol, Version 6 (ipv6)
	Specification. Request for Comments (Draft Standard) 2460,		Specification. Request for Comments (Draft Standard) 2460,
	Internet Engineering Task Force, December 1998.		Internet Engineering Task Force, December 1998.
	[3] V. Devarapalli, R. Wakikawa, A. Petrescu, and P. Thubert. Nemo		[2] V. Devaraplli, R. Wakikawa, A. Petrescu, and P. Thubert.
	Basic Support Protocol (work in progress). Internet Draft		Network Mobility (NEMO) Basic Support Protocol. Request for
	(draft-ietf-nemo-basic-support-02), Internet Engineering Task		Comments (Standards Track) 3963, Internet Engineering Task
	Force, December 2003.		Force, January 2005.
	[4] T. Ernst. Nemo Mobility Support Goals and Requirements (work in		[3] T. Ernst. Network Mobility Support Goals and Requirements (work
	progress). Internet Draft (draft-ietf-nemo-requirements-01),		in progress). Internet Draft (draft-ietf-nemo-requirements-04),
	Internet Engineering Task Force, May 2003.		Internet Engineering Task Force, February 2005.
	[5] Thierry Ernst, Nicolas Montavont, and Ryuji Wakikawa.		[4] T. Ernst, N. Montavont, R. Wakikawa, E. Paik, C. Ng,
	Goals and Benefits of Multihoming. Internet Draft		K. Kuladinithi, and T. Noel. Goals and Benefits of Multihoming
	draft-multihoming-generic-goals-and-benefits-01, Internet		(work in progress, draft-ernst-generic-goals-and-benefits-01).
	Engineering Task Force, April 2004. Work in progress.		Internet Draft, Internet Engineering Task Force, February 2005.
	[6] David B. Johnson, C. Perkins, and Jari Arkko. Mobility Support		[5] D. Johnson, C. Perkins, and J. Arkko. Mobility support in
	in IPv6. Request For Comments 3775, Internet Engineering Task		IPv6. Request for Comments (Standards Track) 3775, Internet
			Engineering Task Force, June 2004.
			[6] J. Manner and M. Kojo. Mobility Related Terminology. Request
			for Comments (Informational) 3753, Internet Engineering Task
	Force, June 2004.		Force, June 2004.
	[7] J. Manner and M. Kojo. Mobility Related Terminology. Request		[7] N. Montavont, R. Wakikawa, T. Ernst, T. Noel, and C. Ng.
	For Comments RFC3753, Internet Engineering Task Force, June		Problem Statement for multihomed Mobile Nodes (work in progress,
	2004.		draft-montavont-mobileip-multihoming-pb-statement-03.txt).
			Internet Draft, Internet Engineering Task Force, January 2005.
	[8] M. Stemm and R. H. Katz. Vertical handoffs in wireless overlay		[8] C. Ng, E. Paik, and T. Ernst. Analysis of Multihoming
			in Network Mobility Support (work in progress,
			draft-ietf-nemo-multihoming-issues-xx.txt). Internet
			Draft, Internet Engineering Task Force, July 2004.
			[9] M. Stemm and R. H. Katz. Vertical handoffs in wireless overlay
	networks. Mobile Networks and Applications, 3(4):335--350,		networks. Mobile Networks and Applications, 3(4):335--350,
	1998.		1998.
	[9] P. Thubert, R. Wakikawa, and V. Devarapalli. NEMO Home		[10] P. Thubert, R. Wakikawa, and V. Devarapalli. NEMO Home
	Network models (work in progress). Internet Draft		Network models (work in progress). Internet Draft
	(draft-ietf-nemo-home-network-models-00.txt), Internet		(draft-ietf-nemo-home-network-models-03.txt), Internet
	Engineering Task Force, May 2003.		Engineering Task Force, March 2005.
	[10] R. Wakikawa, K. Uehara, and J. Murai. Multiple Network
	Interfaces Support by Policy-Based Routing on Mobile IPv6.
	In The 2002 International Conference on Wireless Networks,
	ICWN2002, Jul. 2002.
	[11] X. Zhao, C. Castelluccia, and M. Baker. Flexible network		[11] P. Valitalo. Multihoming of (1,1,*) configured
	support for mobility. In The Second Annual International		networks in Network Mobility Support (work in progress,
	Conference on Mobile Computing and Networking, Nov. 1998.		draft-valitalo-nemo-multihoming-00.txt). Internet Draft,
			Internet Engineering Task Force, March 2005.
	Authors' Addresses		Authors' Addresses
	Ryuji Wakikawa Thierry Ernst		Ryuji Wakikawa Thierry Ernst
	Keio University and WIDE Keio University and WIDE		Keio University and WIDE Keio University and WIDE
	5322 Endo Fujisawa Kanagawa 5322 Endo Fujisawa Kanagawa		5322 Endo Fujisawa Kanagawa 5322 Endo Fujisawa Kanagawa
	252 JAPAN 252 JAPAN		252 JAPAN 252 JAPAN
	Phone: +81-466-49-1394 Phone: +81-466-49-1394		Phone: +81-466-49-1394 Phone: +81-466-49-1394
	EMail: ryuji@sfc.wide.ad.jp EMail: ernst@sfc.wide.ad.jp		EMail: ryuji@sfc.wide.ad.jp EMail: ernst@sfc.wide.ad.jp
	Fax: +81-466-49-1395 Fax: +81-466-49-1395		Fax: +81-466-49-1395 Fax: +81-466-49-1395
	skipping to change at page 27, line 13 ¶		skipping to change at page 30, line 13 ¶
	Fax: +81-466-49-1395 FAX : +81-3-5665-5094		Fax: +81-466-49-1395 FAX : +81-3-5665-5094
	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
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the IETF's procedures with respect to rights in IETF Documents can		on the procedures with respect to rights in RFC documents can be
	be found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any		Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an		assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the		attempt made to obtain a general license or permission for the
	use of such proprietary rights by implementers or users of this		use of such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Disclaimer of Validity		Disclaimer of Validity
	``This document and the information contained herein are provided		This document and the information contained herein are provided on
	on an ``AS IS'' basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE		an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
	REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE		REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
	INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR		INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
	IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		THE 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 (2004). This document is		Copyright (C) The Internet Society (2005). This document is subject
	subject to the rights, licenses and restrictions contained in BCP		to the rights, licenses and restrictions contained in BCP 78, and
	78, and except as set forth therein, the authors retain all their		except as set forth therein, the authors retain all their rights.
	rights.''
	Acknowledgement		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. 125 change blocks.
	304 lines changed or deleted		461 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/