draft-ietf-monami6-multiplecoa-pre07-1.txt		draft-ietf-monami6-multiplecoa-pre07-2.txt
	MEXT Working Group R. Wakikawa (Editor)		MEXT Working Group R. Wakikawa (Editor)
	Internet-Draft Toyota ITC/Keio Univ.		Internet-Draft Toyota ITC/Keio Univ.
	Intended status: Standards Track T. Ernst		Intended status: Standards Track T. Ernst
	Expires: October 17, 2008 INRIA		Expires: October 24, 2008 INRIA
	K. Nagami		K. Nagami
	INTEC NetCore		INTEC NetCore
	V. Devarapalli		V. Devarapalli
	Azaire Networks		Azaire Networks
	April 15, 2008		April 22, 2008
	Multiple Care-of Addresses Registration		Multiple Care-of Addresses Registration
	draft-ietf-monami6-multiplecoa-pre07.txt		draft-ietf-monami6-multiplecoa-pre07-2.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 39		skipping to change at page 1, line 39
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on October 17, 2008.		This Internet-Draft will expire on October 24, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2008).		Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	According to the current Mobile IPv6 specification, a mobile node may		According to the current Mobile IPv6 specification, a mobile node may
	have several care-of addresses, but only one, called the primary		have several care-of addresses, but only one, called the primary
	care-of address, that can be registered with its home agent and the		care-of address, that can be registered with its home agent and the
	skipping to change at page 3, line 34		skipping to change at page 3, line 34
	5.4. Bulk Registration . . . . . . . . . . . . . . . . . . . . 18		5.4. Bulk Registration . . . . . . . . . . . . . . . . . . . . 18
	5.5. Binding De-Registration . . . . . . . . . . . . . . . . . 19		5.5. Binding De-Registration . . . . . . . . . . . . . . . . . 19
	5.6. Returning Home . . . . . . . . . . . . . . . . . . . . . . 19		5.6. Returning Home . . . . . . . . . . . . . . . . . . . . . . 19
	5.6.1. Using only Interface attached to the Home Link . . . . 20		5.6.1. Using only Interface attached to the Home Link . . . . 20
	5.6.2. Using only Interface attached to the Visited Link . . 20		5.6.2. Using only Interface attached to the Visited Link . . 20
	5.6.3. Simultaneous Home and Visited Link Operation . . . . . 20		5.6.3. Simultaneous Home and Visited Link Operation . . . . . 20
	5.7. Receiving Binding Acknowledgement . . . . . . . . . . . . 25		5.7. Receiving Binding Acknowledgement . . . . . . . . . . . . 25
	5.8. Receiving Binding Refresh Request . . . . . . . . . . . . 26		5.8. Receiving Binding Refresh Request . . . . . . . . . . . . 26
	5.9. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 26		5.9. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 26
	6. Home Agent and Correspondent Node Operation . . . . . . . . . 28		6. Home Agent and Correspondent Node Operation . . . . . . . . . 27
	6.1. Searching Binding Cache with Binding Identifier . . . . . 28		6.1. Searching Binding Cache with Binding Identifier . . . . . 27
	6.2. Receiving CoTI and Sending CoT . . . . . . . . . . . . . . 28		6.2. Receiving CoTI and Sending CoT . . . . . . . . . . . . . . 27
	6.3. Processing Binding Update . . . . . . . . . . . . . . . . 29		6.3. Processing Binding Update . . . . . . . . . . . . . . . . 28
	6.4. Sending Binding Refresh Request . . . . . . . . . . . . . 31		6.4. Sending Binding Refresh Request . . . . . . . . . . . . . 30
	6.5. Receiving Packets from Mobile Node . . . . . . . . . . . . 31		6.5. Receiving Packets from Mobile Node . . . . . . . . . . . . 30
	7. Network Mobility Applicability . . . . . . . . . . . . . . . . 32		7. Network Mobility Applicability . . . . . . . . . . . . . . . . 32
	8. DSMIPv6 Applicability . . . . . . . . . . . . . . . . . . . . 33		8. DSMIPv6 Applicability . . . . . . . . . . . . . . . . . . . . 33
	8.1. IPv4 Care-of Address Registration . . . . . . . . . . . . 33		8.1. IPv4 Care-of Address Registration . . . . . . . . . . . . 33
	8.2. IPv4 HoA Management . . . . . . . . . . . . . . . . . . . 34		8.2. IPv4 HoA Management . . . . . . . . . . . . . . . . . . . 34
	9. IPsec and IKEv2 interaction . . . . . . . . . . . . . . . . . 35		9. IPsec and IKEv2 interaction . . . . . . . . . . . . . . . . . 35
	9.1. Use of Care-of Address in the IKEv2 exchange . . . . . . . 35		9.1. Use of Care-of Address in the IKEv2 exchange . . . . . . . 35
	9.2. Transport Mode IPsec protected messages . . . . . . . . . 36		9.2. Transport Mode IPsec protected messages . . . . . . . . . 36
	skipping to change at page 6, line 43		skipping to change at page 6, line 43
	The Binding Identifier mobility option is used to carry the BID		The Binding Identifier mobility option is used to carry the BID
	information.		information.
	Bulk Registration		Bulk Registration
	A mobile node can register multiple bindings at once by sending a		A mobile node can register multiple bindings at once by sending a
	single Binding Update. A mobile node can also replace some or all		single Binding Update. A mobile node can also replace some or all
	the bindings available at the home agent with the new bindings by		the bindings available at the home agent with the new bindings by
	using the bulk registration. Bulk registration is supported only		using the bulk registration. Bulk registration is supported only
	with the home agent as explained in Section 5.5. A mobile node		for the home registration (i.e. with the home agent) as explained
	MUST NOT perform bulk registration with a correspondent node.		in Section 5.4. A mobile node MUST NOT perform bulk registration
			with a correspondent node.
	3. Protocol Overview		3. Protocol Overview
	A new extension called the Binding identification number (BID) is		A new extension called the Binding identification number (BID) is
	introduced to distinguish between multiple bindings pertaining to the		introduced to distinguish between multiple bindings pertaining to the
	same home address. If a mobile node configures several IPv6 global		same home address. If a mobile node configures several IPv6 global
	addresses on one or more of its interfaces, it can register these		addresses on one or more of its interfaces, it can register these
	addresses with its home agent as care-of addresses. If the mobile		addresses with its home agent as care-of addresses. If the mobile
	node wants to register multiple bindings, it MUST generate a BID for		node wants to register multiple bindings, it MUST generate a BID for
	each care-of address and store the BID in the binding update list. A		each care-of address and store the BID in the binding update list. A
	skipping to change at page 9, line 17		skipping to change at page 9, line 17
	1. The mobile node uses only the interface with which it attaches to		1. The mobile node uses only the interface with which it attaches to
	the home link illustrated in Figure 2. It de-registers all		the home link illustrated in Figure 2. It de-registers all
	bindings related to all care-of addresses to the home agent. The		bindings related to all care-of addresses to the home agent. The
	interfaces still attached to the visited link(s) are no longer		interfaces still attached to the visited link(s) are no longer
	going to be receiving any encapsulated traffic from the home		going to be receiving any encapsulated traffic from the home
	agent. On the other hand, the mobile node can continue		agent. On the other hand, the mobile node can continue
	communicating with the correspondent node from the other		communicating with the correspondent node from the other
	interfaces attached to foreign links by using route optimization.		interfaces attached to foreign links by using route optimization.
	Even if the mobile node is attached to the home link, it can		Even if the mobile node is attached to the home link, it can
	still send Binding Updates for other active care-of addresses		still send Binding Updates for other active care-of addresses
	(CoA2 and CoA3) to correspondent nodes. Since the correspondent		(CoA1 and CoA2) to correspondent nodes. Since the correspondent
	node has bindings, packets are routed to each Care-of Addresses		node has bindings, packets are routed to each Care-of Addresses
	directly.		directly.
	+----+		+----+
	| CN |		| CN |
	+--+-+		+--+-+
	|		|
	+---+------+ +----+		+---+------+ +----+
	+------+ Internet |----------+ HA |		+------+ Internet |----------+ HA |
	| +--------+-+ +--+-+		| +----+-----+ +--+-+
	CoA2| | | Home Link		CoA2| | | Home Link
	+--+--+ | --+---+------		+--+--+ | --+---+------
	| MN +========+ | |		| MN +========+ |
	+--+--+ | | |		+--+--+ CoA1 |
	CoA3| +---|-----------+		| |
	+---------------+		+---------------------------+
	Binding Cache Database:		Binding Cache Database:
	home agent's binding		home agent's binding
	none		none
	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 address2 BID2]		binding [a:b:c:d::EUI care-of address2 BID2]
	binding [a:b:c:d::EUI care-of address3 BID3]
	Figure 2: Using only Interface Attached to Home Link		Figure 2: Using only Interface Attached to Home Link
	2. The mobile node uses only the interfaces still attached to the		2. The mobile node uses only the interfaces still attached to the
	visited link(s) as shown in Figure 3. The interface with which		visited link(s) as shown in Figure 3. The interface with which
	the mobile node attaches to the home link is not used.		the mobile node attaches to the home link is not used.
	+----+		+----+
	| CN |		| CN |
	+--+-+		+--+-+
	skipping to change at page 10, line 39		skipping to change at page 10, line 39
	3. The mobile node may simultaneously use both the interface		3. The mobile node may simultaneously use both the interface
	attached to the home link and the interfaces still attached to		attached to the home link and the interfaces still attached to
	the visited link(s) as shown in Figure 4. There are two possible		the visited link(s) as shown in Figure 4. There are two possible
	topologies whether the home agent is single router at the home		topologies whether the home agent is single router at the home
	link or not. The operation of Neighbor Discovery [RFC-2461] is		link or not. The operation of Neighbor Discovery [RFC-2461] is
	different in the two topologies. The home agent and the		different in the two topologies. The home agent and the
	correspondent node have the binding entries listed in Figure 4 in		correspondent node have the binding entries listed in Figure 4 in
	their binding cache database in both topologies. The home agent		their binding cache database in both topologies. The home agent
	also knows that the mobile node has attached to the home link.		also knows that the mobile node has attached to the home link.
	All the traffic from the Internet are intercepted by the home		All the traffic from the Internet is intercepted by the home
	agent first and routed to either the interface attached to the		agent first and routed to either the interface attached to the
	home link or the one attached to the foreign links. How to make		home link or the one of the foreign links. How to make the
	the decision is out of scope in this document.		decision is out of scope in this document.
	Topology-a)		Topology-a)
	+----+		+----+
	| CN |		| CN |
	+--+-+		+--+-+
	|		|
	+---+------+ +----+		+---+------+ +----+
	+------+ Internet |----------+ HA |		+------+ Internet |----------+ HA |
	| +----+-----+ +--+-+		| +----+-----+ +--+-+
	CoA2| | | Home Link		CoA2| | | Home Link
	+--+--+ | --+---+------		+--+--+ | --+---+------
	| MN +========+ |		| MN +========+ |
	+--+--+ CoA1 |		+--+--+ CoA1 |
	CoA3 | |		| |
	+---------------------------+		+---------------------------+
	Topology-b)		Topology-b)
	+----+		+----+
	| CN |		| CN |
	+--+-+		+--+-+
	|		|
	+---+------+ Router +----+		+---+------+ Router +----+
	+------+ Internet |-------R | HA |		+------+ Internet |-------R | HA |
	| +----+-----+ | +--+-+		| +----+-----+ | +--+-+
	CoA2| | | | Home Link		CoA2| | | | Home Link
	+--+--+ | --+-+-------+------		+--+--+ | --+-+-------+------
	| MN +========+ |		| MN +========+ |
	+--+--+ CoA1 |		+--+--+ CoA1 |
	CoA3 | |		| |
	+---------------------------+		+---------------------------+
	Binding Cache Database:		Binding Cache Database:
	home agent's binding		home agent'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]
	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]
	skipping to change at page 12, line 17		skipping to change at page 12, line 17
	This section summarizes the extensions to Mobile IPv6 necessary for		This section summarizes the extensions to Mobile IPv6 necessary for
	manage multiple bindings.		manage multiple bindings.
	4.1. Binding Cache Structure and Binding Update List		4.1. Binding Cache Structure and Binding Update List
	The BID is required to be stored in the binding cache and binding		The BID is required to be stored in the binding cache and binding
	update list structure.		update list structure.
	The sequence number value SHOULD be shared among all the binding		The sequence number value SHOULD be shared among all the binding
	update list. Whenever a mobile node sends either individual or bulk		update list. Whenever a mobile node sends either individual or bulk
	binding update, the sequence number is incremented the value of the		binding update, the sequence number is incremented. On the other
	previous sequence number. On the other hand, if a mobile node		hand, if a mobile node manages an individual sequence value per
	manages an individual sequence value per binding update list, a		binding update list, a mobile node SHOULD carefully select the
	mobile node SHOULD carefully select the sequence number value for the		sequence number value for the bulk binding update. This is because
	bulk binding update. This is because all the bulk-registered		all the bulk-registered bindings use the same Sequence Number
	bindings use the same Sequence Number specified in the Binding		specified in the Binding Update. If each binding uses different
	Update. If each binding uses different sequence number, a mobile		sequence number, a mobile node MUST use the largest sequence number
	node MUST use the largest sequence number from the Binding Update		from the Binding Update list entries used for the bulk registration.
	list entries used for the bulk registration. If the mobile node		If the mobile node cannot select a sequence number for all the
	cannot select a sequence number for all the bindings due to sequence		bindings due to sequence number out of window, it MUST NOT use the
	number out of window, it MUST NOT use the bulk registration for the		bulk registration for the binding whose sequence number is out of
	binding whose sequence number is out of window. A separate Binding		window. A separate Binding Update should be sent for the binding.
	Update should be sent for the binding.
	4.2. Binding Identifier Mobility Option		4.2. Binding Identifier Mobility Option
	The Binding Identifier mobility option is included in the Binding		The Binding Identifier mobility option is included in the Binding
	Update, Binding Acknowledgement, Binding Refresh Request, and Care-of		Update, Binding Acknowledgement, Binding Refresh Request, and Care-of
	Test Init and Care-of Test message.		Test Init and Care-of Test message.
	1 2 3		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 |		| Type = TBD | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Binding ID (BID) | Status |C|O|H|D|Resrvd |		| Binding ID (BID) | Status |O|H| Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
	+ +		+ +
	: IPv4 or IPv6 care-of address (CoA) :		: IPv4 or IPv6 care-of address (CoA) :
	+ +		+ +
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	Figure 5: BID Mobility Option		Figure 5: BID Mobility Option
	Type		Type
	Type value for Binding Identifier is TBD		Type value for Binding Identifier is TBD
	Length		Length
	8-bit unsigned integer. Length of the option, in octets,		8-bit unsigned integer. Length of the option, in octets,
	excluding the Type and Length fields. It MUST be set to 4 when		excluding the Type and Length fields. It MUST be set to either 4,
	the 'C' flag is unset. Otherwise, the Length value MUST be set to		12, or 20 depending on the care-of address field. When the
	either 8 or 20 depending on the 'D' (DSMIPv6) flag.		care-of address is not carried by this option, the length value
			MUST be set to 4. If the IPv4 care-of address is stored in the
			care-of address field, the length MUST be 12. Otherwise, the
			Length value MUST be set to 20 for IPv6 care-of address.
	Binding ID (BID)		Binding ID (BID)
	The BID which is assigned to the binding indicated by the care-of		The BID which is assigned to the binding indicated by the care-of
	address in the Binding Update or the BID mobility option. The BID		address in the Binding Update or the BID mobility option. The BID
	is a 16-bit unsigned integer. The value of zero is reserved and		is a 16-bit unsigned integer. The value of zero is reserved and
	MUST NOT be used.		MUST NOT be used.
	Status		Status
	When the Binding Identifier mobility option is included in a		When the Binding Identifier mobility option is included in a
	Binding Acknowledgement, this field overwrites the status field in		Binding Acknowledgement, this field overwrites the status field in
	the Binding Acknowledgement. If this field is zero, the receiver		the Binding Acknowledgement. If this field is zero, the receiver
	MUST use the registration status stored in the Binding		MUST use the registration status stored in the Binding
	Acknowledgement message. This Status field is also used to carry		Acknowledgement message. This Status field is also used to carry
	error information related to the care-of address test in the		error information related to the care-of address test in the
	Care-of Test message. The status is 8-bit unsigned integer. The		Care-of Test message. The status is 8-bit unsigned integer. The
	possible status codes are the same as the status codes of Binding		possible status codes are the same as the status codes of Binding
	Acknowledgement.		Acknowledgement.
	Care-of address (C) flag
	When this flag is set, it indicates that a valid care-of address
	is present in the care-of address field in the BID mobility
	option. This flag MUST be set whenever the mobile node sends
	multiple care-of addresses in a single Binding Update, i.e., bulk
	registration. It MAY also used as a substitute for alternate
	care-of address option even for Binding Updates that are sent only
	for one care-of address. This flag is valid only for Binding
	Update sent to the home agent.
	Overwrite (O) flag		Overwrite (O) flag
	When this flag is set, a mobile node requests the recipient to		When this flag is set, a mobile node requests the recipient to
	replace all the bindings to binding entries stored in a Binding		replace all the bindings to binding entries stored in a Binding
	Update.		Update.
	Simultaneous Home and Foreign Binding (H) flag		Simultaneous Home and Foreign Binding (H) flag
	This flag indicates that the mobile node registers multiple		This flag indicates that the mobile node registers multiple
	bindings to the home agent while is attached to the home link.		bindings to the home agent while is attached to the home link.
	This flag is valid only for a Binding Update sent to the home		This flag is valid only for a Binding Update sent to the home
	agent.		agent.
	DSMIPv6 (D) flag
	This flag indicates that the care-of address is an IPv4 address.
	When this flag is set, the care-of address field MUST contain an
	IPv4 address.
	Reserved		Reserved
	5 bits Reserved field. The reserved field MUST be zero.		5 bits Reserved field. The reserved field MUST be zero.
	Care-of Address		Care-of Address
	This field has the variable length depending on the specified		This field has the variable length depending on the specified
	flags. When the 'C' flag is set and the 'D' flag is not, an IPv6		flags. Either IPv4 or IPv6 care-of address for the corresponding
	care-of address for the corresponding BID is stored in this field.		BID can be stored in this field. This field MUST NOT be used if a
	If both 'C' and 'D' flags are set, an IPv4 Care-of Address is		Binding Identifier mobility option is included in any other
	carried in this field. This field MUST NOT be used if a Binding		message other than a Binding Update.
	Identifier mobility option is included in any other message other
	than a Binding Update or if the 'C' flag is not set.
	4.3. New Status Values for Binding Acknowledgement		4.3. New Status Values for Binding Acknowledgement
	New status values for the status field in a Binding Acknowledgement		New status values for the status field in a Binding Acknowledgement
	are defined for handling the multiple Care-of Addresses registration:		are defined for handling the multiple Care-of Addresses registration:
	MCOA NOTCOMPLETE (TBD < 128)		MCOA NOTCOMPLETE (TBD < 128)
	In bulk registration, not all the binding identifier mobility		In bulk registration, not all the binding identifier mobility
	option are successfully registered. Some of them are rejected.		option are successfully registered. Some of them are rejected.
	skipping to change at page 15, line 32		skipping to change at page 15, line 18
	Bulk binding registration is not supported.		Bulk binding registration is not supported.
	4.4. Link Layer Address Mobility Option		4.4. Link Layer Address Mobility Option
	The Link Layer Address mobility option is included only in the		The Link Layer Address mobility option is included only in the
	deregistration Binding Update when a mobile node returns home with		deregistration Binding Update when a mobile node returns home with
	simultaneous home and foreign attachment support described in		simultaneous home and foreign attachment support described in
	Section 5.6.3. This option contains the link-layer address of the		Section 5.6.3. This option contains the link-layer address of the
	sender of the Binding Update (i.e. a mobile node). This option MUST		sender of the Binding Update (i.e. a mobile node). This option MUST
	be silently ignored for other mobility header messages.		be ignored for other mobility header messages.
			REMARK: This option might be removed. In the Proxy Mobile IPv6
			specification, the Mobile Node Identifier Option is also defined to
			carry the link-layer address. We may reuse their mobility option
			instead of defining new option here.
	1 2 3		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 |		| Type = TBD | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	+ +		+ +
	: Link Layer address :		: Link Layer address :
	+ +		+ +
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	Figure 6: BID Mobility Option		Figure 6: Link Layer Address Mobility Option
	Type		Type
	Type value for Link Layer Address is TBD		Type value for Link Layer Address is TBD
	Length		Length
	8-bit unsigned integer. Length of the option, in octets,		8-bit unsigned integer. Length of the option, in octets,
	excluding the Type and Length fields. It means the length of the		excluding the Type and Length fields. It means the length of the
	specified link-layer address.		specified link-layer address.
	Link-Layer Address		Link-Layer Address
	The variable length link-layer address. The content and format of		The variable length link-layer address. The content and format of
	this field (including byte and bit ordering) is expected to be		this field (including byte and bit ordering) is expected to be
	specified in specific documents that describe how IPv6 operates		specified in specific documents that describe how IPv6 operates
	over different link layers such as [RFC-2464].		over different link layers such as [RFC-2464].
	5. Mobile Node Operation		5. Mobile Node Operation
	5.1. Management of Care-of Address(es) and Binding Identifier(s)		5.1. Management of Care-of Address(es) and Binding Identifier(s)
	There are two cases when a mobile node might acquire several care-of		There are two cases when a mobile node might acquire several care-of
	skipping to change at page 18, line 47		skipping to change at page 18, line 47
	(for Route Optimization)		(for Route Optimization)
	Figure 7: Binding Update for Binding Registration		Figure 7: Binding Update for Binding Registration
	5.4. Bulk Registration		5.4. Bulk Registration
	Bulk registration is an optimization for binding multiple care-of		Bulk registration is an optimization for binding multiple care-of
	addresses to a home address using a single Binding Update. This is		addresses to a home address using a single Binding Update. This is
	very useful if the mobile node, for instance, does not want to send a		very useful if the mobile node, for instance, does not want to send a
	lot of signaling messages through an interface where the bandwidth is		lot of signaling messages through an interface where the bandwidth is
	scarce.		scarce. This specification support bulk registration only for the
			mobile node's home registration. A mobile node performing bulk
			registration with a correspondent node is out of scope.
	To use bulk registration, the mobile node includes a Binding		To use bulk registration, the mobile node includes a Binding
	Identifier Mobility option for each BID and Care-of address pair it		Identifier Mobility option for each BID and Care-of address pair it
	wants to register in the same Binding Update message. This is shown		wants to register in the same Binding Update message. This is shown
	in Figure 8. The rest of the fields and options in the Binding		in Figure 8. The rest of the fields and options in the Binding
	Update such as Lifetime, Sequence Number, the flags in the Binding		Update such as Lifetime, Sequence Number, the flags in the Binding
	Update are common across all care-of addresses. The alternate		Update are common across all care-of addresses. The alternate
	care-of address option MUST NOT be used.		care-of address option MUST NOT be used.
	IPv6 header (src=CoA, dst=HA)		IPv6 header (src=CoA, dst=HA)
	IPv6 Home Address Option		IPv6 Home Address Option
	ESP Header		ESP Header
	Mobility header		Mobility header
	-Binding Update		-Binding Update
	Mobility Options		Mobility Options
	- Binding Identifier mobility options		- Binding Identifier mobility options (CoA)
	(C flag is set, O flag is optional,
	BID and CoA are stored)
	Figure 8: Binding Update for Bulk Registration		Figure 8: Binding Update for Bulk Registration
	If the mobile node wants to replace existing registered bindings on		If the mobile node wants to replace existing registered bindings on
	the home agent with the bindings in the sent Binding Update, it sets		the home agent with the bindings in the sent Binding Update, it sets
	the 'O' flag. Section 6.3 describes this registration procedure in		the 'O' flag. Section 6.3 describes this registration procedure in
	detail.		detail.
	5.5. Binding De-Registration		5.5. Binding De-Registration
	skipping to change at page 19, line 50		skipping to change at page 19, line 50
	receiver. This is because the receiver will remove the binding that		receiver. This is because the receiver will remove the binding that
	matches the specified BID.		matches the specified BID.
	5.6. Returning Home		5.6. Returning Home
	The mobile node may return to the home link, by attaching to the home		The mobile node may return to the home link, by attaching to the home
	link through one of its interfaces. When the mobile node wants to		link through one of its interfaces. When the mobile node wants to
	return home, it should be configured with information on what		return home, it should be configured with information on what
	interface it needs to use. The mobile node may use only the		interface it needs to use. The mobile node may use only the
	interface with which it is attached to the home link, only the		interface with which it is attached to the home link, only the
	interfaces still attached to the visited link or use both interfaces		interfaces still attached to the visited link(s) or use both
	attached to the home link and visited link simultaneously. The		interfaces attached to the home link and visited link(s)
	following describes each option in more detail.		simultaneously. The following describes each option in more detail.
	5.6.1. Using only Interface attached to the Home Link		5.6.1. Using only Interface attached to the Home Link
	The mobile node returns home and de-registers all the bindings as		The mobile node returns home and de-registers all the bindings as
	shown in Figure 2 and as defined in [RFC-3775]. De-registering all		shown in Figure 2 and as defined in [RFC-3775]. De-registering all
	the bindings is the same as binding de-registration from foreign link		the bindings is the same as binding de-registration from foreign link
	described in Section 5.5. After the de-registration step, all the		described in Section 5.5. After the de-registration step, all the
	packets routed by the home agent are only forwarded to the interface		packets routed by the home agent are only forwarded to the interface
	attached to the home link, even if there are other active interfaces		attached to the home link, even if there are other active interfaces
	attached to the visited link. While the mobile node de-registers all		attached to the visited link(s). While the mobile node de-registers
	the bindings from the home agent, it may continue registering		all the bindings from the home agent, it may continue registering
	bindings for interface attached to visited link to the correspondent		bindings for interface(s) attached to visited link(s) to the
	node as shown in Figure 2.		correspondent node as shown in Figure 2.
	5.6.2. Using only Interface attached to the Visited Link		5.6.2. Using only Interface attached to the Visited Link
	The mobile node returns home and shuts down the interface attached to		The mobile node returns home and shuts down the interface attached to
	the home link as shown in Figure 3. Before shutting down the		the home link as shown in Figure 3. Before shutting down the
	interface, any binding for the care-of address previously associated		interface, any binding for the care-of address previously associated
	with the interface should be deleted. To delete the binding cache		with the interface should be deleted. To delete the binding cache
	entry, the mobile node SHOULD send a de-registration Binding Update		entry, the mobile node SHOULD send a de-registration Binding Update
	with the lifetime set to zero and include the corresponding BID		with the lifetime set to zero and include the corresponding BID
	information. If the mobile node does not send a de-registration		information. If the mobile node does not send a de-registration
	Binding Update, the binding for the care-of address previously		Binding Update, the binding for the care-of address previously
	assigned to the interface remains at the home agent. This binding is		assigned to the interface remains at the home agent until its
	deleted only when it expires. In order to avoid this, the mobile		lifetime expires.
	node SHOULD send a de-registration binding update for the interface
	attached to the home link.
	This scenario is not the most efficient because all the traffic to		In this scenario, despite the face that the mobile node is connected
	and from the mobile node is going through the bi-directional tunnel,		to its home link, all of its traffic is sent and received via the
	whereas the mobile node is now accessible at one hop on the home link		home agent and its foreign links.
	from its home agent.
	5.6.3. Simultaneous Home and Visited Link Operation		5.6.3. Simultaneous Home and Visited Link Operation
	[Problems of Simultaneous Home and Foreign Attachments]		[Problems of Simultaneous Home and Foreign Attachments]
	The mobile node returns home and continues using all the interfaces		The mobile node returns home and continues using all the interfaces
	attached to both foreign and home links as shown in Figure 4. The		attached to both foreign and home links as shown in Figure 4. The
	mobile node indicates this by setting the 'H' flag in the BID		mobile node indicates this by setting the 'H' flag in the BID
	mobility option as defined below. There are additional requirements		mobility option as defined below. There are additional requirements
	on the Returning Home procedures for possible Neighbor Discovery		on the Returning Home procedures for possible Neighbor Discovery
	skipping to change at page 21, line 32		skipping to change at page 21, line 29
	In this specification, the home agent MUST intercept all the packets		In this specification, the home agent MUST intercept all the packets
	meant for the mobile node and decide whether to send the traffic		meant for the mobile node and decide whether to send the traffic
	directly to the home address on the link or tunnel to the care-of		directly to the home address on the link or tunnel to the care-of
	address. The home agent intercepts all the packets even when the		address. The home agent intercepts all the packets even when the
	mobile node is attached to the home link through one of its		mobile node is attached to the home link through one of its
	interfaces. The home agent would make this decision based on the		interfaces. The home agent would make this decision based on the
	type of packets and flows. How to make this decision is out of scope		type of packets and flows. How to make this decision is out of scope
	in this document.		in this document.
	Even when the mobile node returns home, how can home agent intercept		Two scenarios are illustrated in Figure 4, depending on whether the
	the packets meant for the mobile node at the home link on behalf of		Home Agent is a single router at the home link or not. The
	the mobile node? We introduce two possible scenarios, illustrated in		difference is who will defend the home address by (Proxy) Neighbor
	Figure 4, depending on whether the Home Agent is a single router at		Discovery on the home link.
	the home link or not. The difference is who will defend the home
	address by (Proxy) Neighbor Discovery on the home link.
	1. Mobile node defends the home address by the regular Neighbor		1. Mobile node defends the home address by the regular Neighbor
	Discovery Protocol (illustrated as topology-a in Figure 4). The		Discovery Protocol (illustrated as topology-a in Figure 4). The
	home agent is the single router to the Internet on the home link.		home agent is the single router to the Internet on the home link.
	Therefore the home agent is capable of intercepting packets		Therefore the home agent is capable of intercepting packets
	without relying on the proxy Neighbor Discovery protocol and the		without relying on the proxy Neighbor Discovery protocol and the
	mobile node can manage the Neighbor Cache entry of the home		mobile node can manage the Neighbor Cache entry of the home
	address on the home link as a regular IPv6 node.		address on the home link as a regular IPv6 node.
	2. Home agent continue intercepting the mobile node's packets using		2. The home agent cannot naturally intercept all the packets meant
	proxy Neighbor Discovery even after the mobile node's returning		for the mobile node by IP routing due to multiple routers on the
	home (illustrated as topology-b in Figure 4). The home agent		home link. In this case, the mobile node MUST NOT operate
	cannot intercept all the packets meant for the mobile node by IP		Neighbor Discovery protocol for the home address on the home
	routing due to multiple routers on the home link. Due to the		link. This allows the home agent to keep using proxy neighbor
	possible competing neighbor cache state for the home address, the		discovery and thus it keeps receiving all the packets sent to the
	mobile node SHOULD NOT operate Neighbor Discovery protocol for		mobile node's home address. If the home agent, according to its
	the home address on the home link. The problem arises when the		local policy, needs to deliver packets to the mobile node over
	home agent perform the neighbor discovery to resolve the link-		the home link, an issue arises with respect to how the home agent
	layer address of the mobile node on the home link. Since the		discovers the mobile node's link local address. This
	mobile node never answers to the Neighbor Discovery packets for		specification introduces a new Link-Layer Address mobility option
	the home address, the home agent would need to know the Link-		carrying the mobile node's link-layer address in the Binding
	Layer address of the interface with which the mobile node is		Update. Likewise, the mobile node would also know the link-layer
	attached to the home link in other way. This specification		address of the default router address to send packets from the
	introduces a new Link-Layer Address mobility option carrying the		home link without Neighbor Discovery. The link-layer address is
	mobile node's link-layer address in the Binding Update.		used to transmit packets from and to the mobile node on the home
	Likewise, the mobile node would also know the link-layer address		link. The packets are transmitted without the Neighbor Discovery
	of the default router address to send packets from the home link
	without Neighbor Discovery. The link-layer address is used to
	transmit packets from and to the mobile node on the home link.
	The packets are transmitted without the Neighbor Discovery
	protocol by constructing the link-layer header manually. This		protocol by constructing the link-layer header manually. This
	operation is similar to Mobile IPv6 [RFC-3775] when a mobile node		operation is similar to Mobile IPv6 [RFC-3775] when a mobile node
	sends a deregistration binding update to the home agent's link-		sends a deregistration binding update to the home agent's link-
	layer address in returning home operation.		layer address in returning home operation.
	[Sending Deregistration Binding Update]		[Sending Deregistration Binding Update]
	o As soon as a mobile node returns home, it sends a de-registration		o As soon as a mobile node returns home, it sends a de-registration
	Binding Update to the home agent from the interface attached to		Binding Update to the home agent from the interface attached to
	the home link.		the home link.
	o The mobile node MUST include the BID mobility option specifying		o The mobile node MUST include the BID mobility option specifying
	the BID the mobile node had previously associated with the		the BID the mobile node had previously associated with the
	interface attached to the home link. The 'H' flag MUST be set in		interface attached to the home link. The 'H' flag MUST be set in
	the BID mobility option. The 'C' flag MUST NOT be set and the		the BID mobility option. Any address MUST NOT be set in the
	care-of address field MUST NOT be included. When the 'H' flag is		Care-of Address field in the BID mobility option. When the 'H'
	set, the home agent recognizes that the mobile node wants to		flag is set, the home agent recognizes that the mobile node wants
	continue using interfaces attached to both home and visited links.		to continue using interfaces attached to both home and visited
	Note that H flag MUST be set for all the binding updates sent from		links. Note that H flag MUST be set for all the binding updates
	the mobile node (ex. Binding Update for the interface attached to		sent from the mobile node (ex. Binding Update for the
	the foreign link).		interface(s) attached to the foreign link(s)).
	o The mobile node SHOULD include the Link-Layer address mobility		o The mobile node SHOULD include the Link-Layer address mobility
	option to notify the mobile node's link-layer address to the home		option to notify the mobile node's link-layer address to the home
	agent, too. This link-layer address is required for the home		agent, too. This link-layer address is required for the home
	agent to send the Binding Acknowledgement and to forward the		agent to send the Binding Acknowledgement and to forward the
	mobile node's packet.		mobile node's packet.
	o According to [RFC-3775], the mobile node MUST start responding to		o According to [RFC-3775], the mobile node MUST start responding to
	Neighbor Solicitation for its home address right after it sends		Neighbor Solicitation for its home address right after it sends
	the deregistration Binding Update to the home agent. However, in		the deregistration Binding Update to the home agent. However, in
	this specification, the mobile node MUST NOT respond to Neighbor		this specification, the mobile node MUST NOT respond to Neighbor
	Solicitation before receiving a Binding Acknowledgement, since the		Solicitation before receiving a Binding Acknowledgement, since the
	home agent may continue proxying for the home address.		home agent may continue proxying for the home address. If the
			mobile node receives [MCOA RETURNHOME WO/NDP (TBD)] status value
			in the received Binding Acknowledgment, it MUST NOT respond to
			Neighbor Solicitation even after the Binding Acknowledgement.
			Otherwise, the mobile node starts answering to Neighbor
			Solicitation.
	[Sending Binding Acknowledgement]		[Sending Binding Acknowledgement]
	o When the home agent sends the Binding Acknowledgement after		o When the home agent sends the Binding Acknowledgement after
	succeeding the binding de-registration, it MUST set the status		succeeding the binding de-registration, it MUST set the status
	value to either 0 [Binding Update Accepted] or to [MCOARETURNHOME		value to either 0 [Binding Update Accepted] or to [MCOARETURNHOME
	WO/NDP (TBD)] in the BID mobility option depending on home agent		WO/NDP (TBD)] in the Status field of the Binding Acknowledgment
	configuration at the home link. The new values are:		depending on home agent configuration at the home link. The new
			values are:
	* Binding Update Accepted (0): NDP is permitted for the home		* Binding Update Accepted (0): NDP is permitted for the home
	address at the home link. This is regular returning home		address at the home link. This is regular returning home
	operation of [RFC-3775]		operation of [RFC-3775]
	* MCOA RETURNHOME WO/NDP (TBD): NDP is prohibited for the home		* MCOA RETURNHOME WO/NDP (TBD): NDP is prohibited for the home
	address at the home link		address at the home link
	If the binding update is rejected, the appropriate error value		If the binding update is rejected, the appropriate error value
	MUST be set to the status field. In this case, the home agent		MUST be set to the status field. In this case, the home agent
	skipping to change at page 24, line 5		skipping to change at page 23, line 47
	o On the other hand, if the home agent is not the only router on the		o On the other hand, if the home agent is not the only router on the
	home link, it returns [MCOA RETURNHOME WO/NDP] value in the Status		home link, it returns [MCOA RETURNHOME WO/NDP] value in the Status
	field of the BID mobility option. The home agent learns the		field of the BID mobility option. The home agent learns the
	mobile node's link-layer address by receiving the link-layer		mobile node's link-layer address by receiving the link-layer
	address mobility option carried by the Binding Update. It stores		address mobility option carried by the Binding Update. It stores
	the link-layer address as a neighbor cache entry for the mobile		the link-layer address as a neighbor cache entry for the mobile
	node so that it can send the packets to the mobile node's link-		node so that it can send the packets to the mobile node's link-
	layer address.		layer address.
			o Note that the use of proxy Neighbor Discovery is easier way to
			intercept the mobile nodes' packets instead of IP routing in some
			deployment scenarios. Therefore, even if a home agent is the only
			router, it is an implementation and operational choice whether the
			home agent return [Binding Update Accepted] or [MCOA RETURNHOME
			WO/NDP].
	o If BID option is missed in the Binding Acknowledgement, the home		o If BID option is missed in the Binding Acknowledgement, the home
	agent might not recognize the simultaneous home and foreign		agent might not recognize the simultaneous home and foreign
	attachment. The home agent might process the de-registration		attachment. The home agent might process the de-registration
	Binding Update as one of [RFC-3775] and deletes all the registered		Binding Update as one of [RFC-3775] and deletes all the registered
	binding cache entries for the mobile node. Thus, the mobile node		binding cache entries for the mobile node. Thus, the mobile node
	SHOULD stop using the interface attached to foreign link and use		SHOULD stop using the interface attached to foreign link and use
	only the interface attached to the home link.		only the interface attached to the home link.
	[Sending Packets from the Home Link]		[Sending Packets from the Home Link]
	skipping to change at page 25, line 8		skipping to change at page 25, line 8
	o On the other hand, if the mobile node does not have any active		o On the other hand, if the mobile node does not have any active
	care-of address to send a Binding Update and leaves the home link		care-of address to send a Binding Update and leaves the home link
	(i.e. the mobile node is completely disconnected), the home agent		(i.e. the mobile node is completely disconnected), the home agent
	continues forwarding packets to the mobile node until the		continues forwarding packets to the mobile node until the
	expiration of all the binding cache entries for the home address.		expiration of all the binding cache entries for the home address.
	Once all the bindings are expired, the mobile node is assumed to		Once all the bindings are expired, the mobile node is assumed to
	be disconnected completely from networks.		be disconnected completely from networks.
	[Changing Behavior during the attachment to the home link]		[Changing Behavior during the attachment to the home link]
	When a mobile node would change the home operation to Section 5.6.1
	or Section 5.6.2, following procedure should be taken.
	If a mobile node decides to return home completely without any active		If a mobile node decides to return home completely without any active
	foreign link attachment, it simply sends a deregistration binding		foreign link attachment, it simply sends a deregistration binding
	update as described in Section 5.6.1. Once the home agent receives		update as described in Section 5.6.1. Once the home agent receives
	such de-registration binding update, the home agent clears all the		such de-registration binding update, the home agent clears all the
	binding and states for the mobile node.		binding and states for the mobile node.
	If a mobile node would stop using the interface attached to the home		If a mobile node decides to stop using the interface attached to the
	link, it simply sends a binding update from the one of active care-of		home link, it simply sends a binding update from the one of active
	address. In the Binding Update, the mobile node should include the		care-of address. In the Binding Update, the mobile node should
	BID option for the care-of address and unset the H flag of BID		include the BID option for the care-of address and unset the H flag
	option. The home agent clears the states of the mobile node for the		of BID option. The home agent clears the states of the mobile node
	interface attached to the home link and stop forwarding the packets		for the interface attached to the home link and stop forwarding the
	to the mobile node on the home link.		packets to the mobile node on the home link.
	5.7. Receiving Binding Acknowledgement		5.7. Receiving Binding Acknowledgement
	The verification of a Binding Acknowledgement is the same as Mobile		The verification of a Binding Acknowledgement is the same as Mobile
	IPv6 (section 11.7.3 of [RFC-3775]). The operation for sending a		IPv6 (section 11.7.3 of [RFC-3775]). The operation for sending a
	Binding Acknowledgement is described in Section 6.3.		Binding Acknowledgement is described in Section 6.3.
	If a mobile node includes a Binding Identifier mobility option in a		If a mobile node includes a Binding Identifier mobility option in a
	Binding Update with the 'A' flag set, a Binding Acknowledgement MUST		Binding Update with the 'A' flag set, a Binding Acknowledgement MUST
	carry a Binding Identifier mobility option. If no such mobility		carry a Binding Identifier mobility option. If no such mobility
	skipping to change at page 29, line 35		skipping to change at page 28, line 35
	receiver node MUST have only one binding cache entry for the mobile		receiver node MUST have only one binding cache entry for the mobile
	node. If the Binding Update is for de-registration, the receiver		node. If the Binding Update is for de-registration, the receiver
	MUST delete all existing bindings from its Binding Cache.		MUST delete all existing bindings from its Binding Cache.
	If the Binding Update contains a Binding Identifier mobility		If the Binding Update contains a Binding Identifier mobility
	option(s), it is first validated according to section 9.5.1 of [RFC-		option(s), it is first validated according to section 9.5.1 of [RFC-
	3775]. Then the receiver processes the Binding Identifier mobility		3775]. Then the receiver processes the Binding Identifier mobility
	option(s) as described in the following steps.		option(s) as described in the following steps.
	o The length value is examined. The length value MUST be either 4,		o The length value is examined. The length value MUST be either 4,
	8, or 20 depending on the 'C' and 'D' flags. If the length is		8, or 20 depending on the Care-of Address field. If the length is
	incorrect, the receiver MUST reject the Binding Update and returns		incorrect, the receiver MUST reject the Binding Update and returns
	the status value set to [MCOA MALFORMED].		the status value set to [MCOA MALFORMED].
	o When the 'C' flag is set, the care-of address MUST be present in		o When the Length value is either 12 or 20, the care-of address MUST
	the Binding Identifier mobility option. If the care-of address is		be present in the Binding Identifier mobility option. If the
	not present, the receiver MUST reject the Binding Identifier		care-of address is not present, the receiver MUST reject the
	mobility option and returns the status value set to [MCOA		Binding Identifier mobility option and returns the status value
	MALFORMED]. The operation of 'D' flag is described in Section 8		set to [MCOA MALFORMED]. If the Length value is 12, an IPv4 valid
			address MUST be present. Otherwise, an IPv6 address MUST be
			stored in the Binding Identifier mobility option.
	o When multiple Binding Identifier mobility options are present in		o When multiple Binding Identifier mobility options are present in
	the Binding Update, it is treated as bulk registration. If the		the Binding Update, it is treated as bulk registration. If the
	receiving node is a correspondent node, it MUST reject the Binding		receiving node is a correspondent node, it MUST reject the Binding
	Update and returns the status value in the binding acknowledgement		Update and returns the status value in the binding acknowledgement
	set to [MCOA BULK REGISTRATION NOT SUPPORT]		set to [MCOA BULK REGISTRATION NOT SUPPORT]
	o If the Lifetime field in the Binding Update is set to zero, the		o If the Lifetime field in the Binding Update is set to zero, the
	receiving node deletes the binding entry that corresponds to the		receiving node deletes the binding entry that corresponds to the
	BID in the Binding Identifier mobility option. If the receiving		BID in the Binding Identifier mobility option. If the receiving
	node does not have an appropriate binding for the BID, it MUST		node does not have an appropriate binding for the BID, it MUST
	reject the Binding Update and send a Binding Acknowledgement with		reject the Binding Update and send a Binding Acknowledgement with
	status set to 133 [not home agent for this mobile node].		status set to 133 [not home agent for this mobile node].
	o If the 'O' flag is set in the de-registering Binding Update, it is		o If the 'O' flag is set in the de-registering Binding Update, it is
	ignored. If the 'H' flag is set, the home agent stores a home		ignored. If the 'H' flag is set, the home agent stores a home
	address in the Care-of Address field of the binding cache entry.		address in the Care-of Address field of the binding cache entry.
	skipping to change at page 30, line 20		skipping to change at page 29, line 22
	ignored. If the 'H' flag is set, the home agent stores a home		ignored. If the 'H' flag is set, the home agent stores a home
	address in the Care-of Address field of the binding cache entry.		address in the Care-of Address field of the binding cache entry.
	The home agent also stops performing proxy ND for the mobile		The home agent also stops performing proxy ND for the mobile
	node's home address.		node's home address.
	o If the Lifetime field is not set to zero, the receiving node		o If the Lifetime field is not set to zero, the receiving node
	registers a binding with the specified BID as a mobile node's		registers a binding with the specified BID as a mobile node's
	binding. The Care-of address is obtained from the Binding Update		binding. The Care-of address is obtained from the Binding Update
	packet as follows:		packet as follows:
	* If the 'C' flag is set in the Binding Identifier mobility		* If the Length value of the Binding Identifier mobility option
	option, the care-of address is copied from the care-of address		is 20, the care-of address is copied the IPv6 address from the
	field in the Binding Identifier mobility option.		care-of address field in the Binding Identifier mobility
			option. When the Length value is 12, the address MUST be the
			IPv4 valid address. Detail information can be found in
			Section 8.
	* If the 'C' flag is not set in the Binding Identifier mobility		* If the Length value of the Binding Identifier mobility option
	option, the care-of address is copied from the source address		is 4, the care-of address is copied from the source address
	field of the IPv6 header.		field of the IPv6 header.
	* If the 'C' flag is not set and an alternate care-of address is		* If the Length value of the Binding Identifier mobility option
	present, the care-of address is copied from the Alternate		is 4 and an alternate care-of address is present, the care-of
	Care-of address mobility option.		address is copied from the Alternate Care-of address mobility
			option.
	o Once the care-of address(es) have been retrieved from the Binding		o Once the care-of address(es) have been retrieved from the Binding
	Update, the receiving nodes creates new binding(s).		Update, the receiving nodes creates new binding(s).
	* If only the 'O' flag is set in the Binding Identifier mobility		* If only the 'O' flag is set in the Binding Identifier mobility
	option, the home agent removes all the existing bindings and		option, the home agent removes all the existing bindings and
	registers the received bindings.		registers the received bindings.
	* If the receiver has a regular binding which does not have BID		* If the receiver has a regular binding which does not have BID
	for the mobile node, it must not process the binding update.		for the mobile node, it must not process the binding update.
	skipping to change at page 41, line 7		skipping to change at page 41, line 7
	* MCOA MALFORMED (TBD)		* MCOA MALFORMED (TBD)
	* MCOA BID CONFLICT (TBD)		* MCOA BID CONFLICT (TBD)
	* MCOA PROHIBITED(TBD)		* MCOA PROHIBITED(TBD)
	* MCOA BULK REGISTRATION NOT SUPPORTED (TBD)		* MCOA BULK REGISTRATION NOT SUPPORTED (TBD)
	12. Acknowledgements		12. Acknowledgements
	The authors would like to thank Masafumi Aramoto, George Tsirtsis,		The authors would like to special thank George Tsirtsis for thorough
	Keigo Aso, Julien Charbon, Tero Kauppinen, Benjamin Lim, Susumu		review and suggestions. The authors would also like to thank
	Koshiba, Martti Kuparinen, Romain Kuntz, Heikki Mahkonen, Hiroki		Masafumi Aramoto, Keigo Aso, Julien Charbon, Tero Kauppinen, Benjamin
	Matutani, Koshiro Mitsuya, Nicolas Montavont, Koji Okada, Keisuke		Lim, Martti Kuparinen, Romain Kuntz, Heikki Mahkonen, Nicolas
	Uehara, Masafumi Watari in alphabetical order, and the Jun Murai		Montavont for their discussions and inputs. Thanks to Susumu
	Laboratory at the KEIO University.		Koshiba, Hiroki Matutani, Koshiro Mitsuya, Koji Okada, Keisuke
			Uehara, Masafumi Watari and Jun Murai for earlier work on this
			subject.
	13. References		13. References
	13.1. Normative References		13.1. Normative References
	[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC-2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor		[RFC-2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
	Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.		Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
End of changes. 46 change blocks.
	154 lines changed or deleted		151 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/