Re: Gen-art review of draft-ietf-monami6-multiplecoa-10.txt

Hi Elwyn

Thanks a lot for detailed reviews.
Please find my comments inline...

I fixed the most of comments and attach the -11.txt and diff files.
The updated version contains the modifications for Gerardo's comments,  
too.
On 2008/11/24, at 19:45, Elwyn Davies wrote:

> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft (for background on Gen-ART, please see
> _http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html_).
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
>
> Document: draft-ietf-monami6-multiplecoa-10.txt
> Reviewer: Elwyn Davies
> Review Date: 24 November 2008
> IETF LC End Date: 17 November 2008
> IESG Telechat date: (if known) -
>
> Summary:
> This document is almost ready for the IESG.  It has a number of minor
> issues plus a fair number of editorial nits.
>
> I am sending the editirial issues to the authors separately as there  
> are
> lots of acronyms needing expansion and minor english improvements that
> woild be tedious to transcribe.
>
> Apologies for the late review.
>
> Comments:
> Minor Issues:
>
> Backwards compatibility:   It would be helpful to explain in the
> introduction why this proposal is backwatds compatible with the RFC  
> 3775
> scheme.  The explanations are there but are buried in the error  
> cases of
> s5.7 and is easily mossed (as I did on early reading).
I added the following text in the Protocol Overview.

NEW
This specification keeps backwards compatibility with [RFC-3775].  If
  a receiver (either home agent or correspondent node) does not support
  this specification, it does not understand the binding identifier
  mobility option.  The receiver skip the unknown mobility option (i.e.
  Binding Identifier mobility option) and process the Binding Update as
  defined in [RFC-3775].  In order to keep the backward compatibility
  with [RFC-3775], when a mobile node sends a Binding Update message
  with extensions described in this document, the receiver needs to
  reflect the Binding Identifier mobility option in the Binding
  Acknowledgement.  If the mobile node finds no Binding Identifier
  mobility options in the received Binding Acknowledgement, it assumes
  the other end node does not support this specification.  In such
  case, the mobile node needs to fall back to the legacy RFC-3775
  compliant mobile node.  If it is the home registration, the mobile
  node MAY try to discover another home agent supporting BID mobility
  option for the home registration.



> Extension to IPv4 correspondents etc: Something about this in the
> ontroduction would also help.
OK

> s2 and several other places (s4.2, s5.1):  Use of zero as a binding ID
> (BID) is forbidden.  It is unclear why this value is not allowed - it
> does not AFAICS specify reversion to RFC 3775 behaviour or anything
> similar:  Forbidding it seems gratuitous.
zero BID might be used to specify some meaning to a binding.
For example, a binding using BID zero can be treated as a default  
binding.
The zero BID is not forbidden, but it's reserved.
I removed "MUST NOT" for using the zero BID.

OLD
  Binding ID (BID)
     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
     is a 16-bit unsigned integer.  The value of zero is reserved and
     MUST NOT be used.

NEW
  Binding ID (BID)
     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
     is a 16-bit unsigned integer.  The value of zero is reserved and
     may not be used without special purpose.


> s2: Specifying that the BID must not be negative is sloghtly confusing
> because the protocol is specified so that negative values cannot be  
> carried.
right. I erased this sentence.


> s4.2 (two places), s6.2 (2nd bullet), s6.2 (6th bullet, 1st sub- 
> bullet):
> The length of the Binding Address mobility option for the IPv4 case is
> specified inconsistently. Some places have been corrected from 12 to 8
> but several others remain.
thanks, we did fix these errors.

> s4.2: The Reserved fiels is normally specified as 'SHOULD be ignored  
> by
> the receiver'.  Makes it easier to cope with later changes.
fixed.

> s4.3 (MCOA NOTCOMPLETE) and elsewhere (s6.2):  I am dubious about the
> non-transactional nature of bulk registrations:  some additional
> discussion of why it should be reasonable that a bulk registration can
> fail in part would be useful
OK. see my comments to the same question at the end of this mail.


> s4.3 (MCOA MALFORNED): Some indoication of the circumstances under  
> which
> this can occur would be useful.
Added more texts in section 4.3

OLD
  MCOA MALFORMED (TBD more than 128)
     Registration failed because Binding Identifier mobility option was
     not formatted correctly.


NEW
  MCOA MALFORMED (TBD more than 128)
     Registration failed because Binding Identifier mobility option was
     not formatted correctly.  This value is used when the wrong length
     value is specified (neither 4, 8 nor 20) in the length field of
     the Binding Identifier mobility or when invalid address is
     specified in the care-of address field.

> s4.3 (MCOA BULK REGISTRATION PROHIBITED) and s5.3:  I think there is a
> 'crner case' in which a bulk registration is sent to a leagcay RFC  
> 3775
> node:  the node would not be capable of this response.  This corner  
> case
> is not described in s5.3
This comment is related to the Backwards compatibility.
If a legacy RFC-3775 node receives a BU in the bulk registration mode,
it can simply process only the BU and skip the binding identifier  
option.
It does not use this BULK REG PROHIBITED value in the BA status code.

The MN can distinguish whether the receiver of BU is legacy RFC-3775  
node or MCoA extended node by
checking Binding Acknowledgement.

See the second paragraph of section5.7.
" If a mobile node includes a Binding Identifier mobility option in a
  Binding Update with the 'A' flag set, a Binding Acknowledgement MUST
  carry a Binding Identifier mobility option.  According to [RFC-3775],
  the receiver of the Binding Update ignores unknown mobility options
  and process the Binding Update without the unknown mobility option.
  Therefore, if no such mobility option is included in the Binding
  Acknowledgement in response to a Binding Update for multiple care-of
  address registration, this indicates that the originating node of the
  Binding Acknowledgement does not support processing the Binding
  Identifier mobility option regardless of status value.  In such case,
  the receiver of the Binding Update may create a regular binding.  The
  mobile node then stop multiple care-of address registration with that
  node.  If it is home registration, the mobile node MAY attempt to
  discover another home agent supporting BID mobility option for the
  home registration."



> s5.3: What error status is sent if the user has an Alernate care-of
> address option with a bulk registration?
Very good comment.
I re-checked this parts and found this part is very unclear.

The reason of eliminating Alternate care-of address option is not only  
for bulk registration.
In RFC-3775, Alternate CoA is mandatory for home registration, but not  
for binding registration to correspondent node.
Alternate CoA mobility option is required when BU is protected with  
IPsec ESP.
Therefore, we clearly mention this point in the draft.

In section 5.2
OLD
When IPsec ESP is used for protecting the Binding Update,
  the care-of address can be carried in the Care-of Address field of
  the Binding Identifier mobility option.  If this is done, the
  alternate care-of address option MUST NOT be included in the Binding
  Update.

NEW
  When IPsec ESP is used for protecting the Binding Update, a care-of
  address MUST be carried in an alternate care-of address mobility
  option as described in [RFC-3776].  However, in this specfication,
  the care-of address MUST be carried in the Care-of Address field of
  the Binding Identifier mobility option.  In order to save bits of the
  Binding Update, the alternate care-of address option MUST NOT be
  included.

In section 5.3
OLD
The alternate care-of address option MUST NOT be used.

NEW
  When IPsec ESP is used for protecting the Binding Update, a care-of
  address MUST be carried in an alternate care-of address mobility
  option as described in [RFC-3776].  However, in the bulk
  registration, the care-of addresses are always carried in the Care-of
  Address field of the Binding Identifier mobility option.  In order to
  save bits of the Binding Update, the alternate care-of address option
  MUST NOT be included in such Binding Update.

In section 6.2
ADD
  o  If the Binding Update is protected with IPsec ESP, the care-of
     address MUST be appeared in the Binding Identfier mobility option.
     If no address is appeared in the care-of address field in that
     mobility option, it MUST reject the Binding Identifier mobility
     option and returns the status value set to [MCOA MALFORMED].

  o  If the care-of address is appeared in both the alternate care-of
     address mobility option and the BInding Identifier mobility option
     at the same time, it MUST ignore the alternate care-of address
     mobility option and can continue processing the Binding Update
     with the care-of address specified in the BInding Identifier
     mobility option.


> s5.5.2, last para: Arguably, if the interface is shut down the node os
> not (IP) connected to its home link!
right. This was discussed on the ML, too.
There is no specific description of returning home in this section,
but we explain how MN de-registers the binding of the shut-down  
interface from the active interface.
> s5.6.3 (2nd bullet) and s6.1 (para 2): Using 'ex.' is not good:  It is
> not a standard abbreviation.  I take it 'except' is meant.
fixed.

> s5.6.3 (3rd bullet):  'The mobile node SHOULD include the Link-layer
> Address (LLA) Option': I do not understand how the home agent would be
> able to send to the mobile node if the LLA option was omitted.  I  
> think
> this is a 'MUST' or maybe a 'needs to'.
If the link between HA and MN is P2P (example is 3GPP/WiMAX),
we expect HA might be able to get the LL address in the L2 mechanism.
Therefore, we use SHOULD instead of MUST.

> s5.6.4 (2nd top level bullet): 'the home agent SHOULD use the link- 
> layer
> address carried by the Link Layer Address option':  Again I am not  
> sure
> what alternative there is?  Replace with either 'MUST' or 'needs to'.
see above. A home link can be P2P link in some scenario.

> s5.7 (2nd bullet): s/SHOULD/needs to/:  This is not something sthat is
> an option in the protocol.  Also I think it should state that the  
> mobile
> node needs to assume that none of the attempted registrations were
> successful.
OLD
  o  If the Status value is [MCOA BULK REGISTRATION NOT SUPPORT], the
     mobile node SHOULD stop using bulk registrations with the node
     that sent the Binding Acknowledgement.
NEW

  o  If the Status value is [MCOA BULK REGISTRATION NOT SUPPORT], all
     the attemped registration in the bulk registration mode are
     failed.  Therefore, the mobile node MUST stop using bulk
     registrations with the node that sent the Binding Acknowledgement.
> s5.7 (3rd bullet): Explain what could cause the packet to be  
> malformed.
It is now explained in section 4.3.

> s5.7 (4th bullet):  Replace 1st instance of SHOULD with 'needs to'.
> Explain that the 2nd case can occur during 'bootsatrpa' (pointer to  
> s5.9).
fixed.

> s6.2 (para 2):  If bulk registrations are not transactional (which I
> would have preferred) need to make it clear what happens with the
> vrarious multiple mobility options when some are succcessful and  
> some fail.
It is not designed as transactional.
However, it might be a case when HA cannot accept more than two  
bindings, but MN sends 3 CoAs in bulk BU.
In such case, HA should accept two bindings and reject one. In the BA,  
HA should set  either one of those error codes for the rejected BID.
     128 Reason unspecified
     129 Administratively prohibited
     130 Insufficient resources

I didn't make any modification to this comments.
If this reason is reasonable and is worth to write in the draft,
I will add new texts.

> s6.2 (2nd bullet):  'When the Length value is either 8 or 20, the
> care-of address MUST be present in the Binding Identifier mobility
> option. If the valid care-of address is not present, the receiver MUST
> reject the Binding Identifier mobility option and returns the status
> value set to [MCOA MALFORMED].'  This is poorly phrased.  If the  
> length
> is set to 8 or 20, then there is space in the option for an address of
> some sort.  It sort of implies that the bit pattern can be tested to  
> see
> if it is a valid address - how is this done?
This address verification is mainly to check the CoA is truly unicast  
routable address or not.
The same verification is defined in RFC3775.

OLD
  o  When the Length value is either 8 or 20, the care-of address MUST
     be present in the Binding Identifier mobility option.  If the
     valid care-of address is not present, the receiver MUST reject the
     Binding Identifier mobility option and returns the status value
     set to [MCOA MALFORMED].

NEW
  o  When the Length value is either 8 or 20, the care-of address MUST
     be present in the Binding Identifier mobility option.  If the
     unicast routable address [RFC-3775] is not present in the care-of
     address field, the receiver MUST reject the Binding Identifier
     mobility option and returns the status value set to [MCOA
     MALFORMED].


> It strikes me tht it would
> simpler just to day that the address is ignored if present when not
> required (or, if being paranoid, must be the same as was previously
> registered (if present) when deleting a registration).

If the care-of address is not required, the length value must be 4.
There is no space to include the care-of address in the binding  
identifier option.

> s6.2 (1st para after lost of bullets): s/can be omitted/MAY be  
> omitted/
fixed.

> Editorial:
> I have sent a Word document with many nits marked up to the authors.
I have fixed all the editorial comments. Thanks!!!!

regards,
ryuji

ps. I'm away from the office on a business trip for two weeks.
I am now in New Orleans, but will catch flights to Spain this morning.

	draft-ietf-monami6-multiplecoa-10.txt		draft-ietf-monami6-multiplecoa-11.txt
	MEXT Working Group R. Wakikawa (Ed.)		MEXT Working Group R. Wakikawa (Ed.)
	Internet-Draft Toyota ITC/Keio Univ.		Internet-Draft Toyota ITC/Keio Univ.
	Intended status: Standards Track V. Devarapalli (Ed.)		Intended status: Standards Track V. Devarapalli (Ed.)
	Expires: May 8, 2009 Wichorus		Expires: June 8, 2009 Wichorus
	T. Ernst		T. Ernst
	INRIA		INRIA
	K. Nagami		K. Nagami
	INTEC NetCore		INTEC NetCore
	November 4, 2008		December 5, 2008
	Multiple Care-of Addresses Registration		Multiple Care-of Addresses Registration
	draft-ietf-monami6-multiplecoa-10.txt		draft-ietf-monami6-multiplecoa-11-20081205.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 May 8, 2009.		This Internet-Draft will expire on June 8, 2009.
	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 2, line 27		skipping to change at page 2, line 27
	Mobility) Basic Support protocol as well.		Mobility) Basic Support protocol as well.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6		3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
	4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 11		4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 12
	4.1. Binding Cache Structure and Binding Update List . . . . . 11		4.1. Binding Cache Structure and Binding Update List . . . . . 12
	4.2. Binding Identifier Mobility Option . . . . . . . . . . . . 11		4.2. Binding Update Message . . . . . . . . . . . . . . . . . . 12
	4.3. New Status Values for Binding Acknowledgement . . . . . . 13		4.3. Binding Identifier Mobility Option . . . . . . . . . . . . 13
			4.4. New Status Values for Binding Acknowledgement . . . . . . 14
	5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 15		5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 17
	5.1. Management of Care-of Address(es) and Binding		5.1. Management of Care-of Address(es) and Binding
	Identifier(s) . . . . . . . . . . . . . . . . . . . . . . 15		Identifier(s) . . . . . . . . . . . . . . . . . . . . . . 17
	5.2. Binding Registration . . . . . . . . . . . . . . . . . . . 15		5.2. Binding Registration . . . . . . . . . . . . . . . . . . . 17
	5.3. Bulk Registration . . . . . . . . . . . . . . . . . . . . 16		5.3. Bulk Registration . . . . . . . . . . . . . . . . . . . . 18
	5.4. Binding De-Registration . . . . . . . . . . . . . . . . . 17		5.4. Binding De-Registration . . . . . . . . . . . . . . . . . 19
	5.5. Returning Home: Using Single Interface . . . . . . . . . . 17		5.5. Returning Home: Using Single Interface . . . . . . . . . . 19
	5.5.1. Using only Interface attached to the Home Link . . . . 17		5.5.1. Using only Interface attached to the Home Link . . . . 19
	5.5.2. Using only Interface attached to the Visited Link . . 17		5.5.2. Using only Interface attached to the Visited Link . . 20
	5.6. Returning Home: Simultaneous Home and Visited Link		5.6. Returning Home: Simultaneous Home and Visited Link
	Operation . . . . . . . . . . . . . . . . . . . . . . . . 18		Operation . . . . . . . . . . . . . . . . . . . . . . . . 20
	5.6.1. Problems of Simultaneous Home and Foreign		5.6.1. Problems of Simultaneous Home and Foreign
	Attachments . . . . . . . . . . . . . . . . . . . . . 18		Attachments . . . . . . . . . . . . . . . . . . . . . 20
	5.6.2. Overview and Approach . . . . . . . . . . . . . . . . 18		5.6.2. Overview and Approach . . . . . . . . . . . . . . . . 21
	5.6.3. Sending Deregistration Binding Update . . . . . . . . 20		5.6.3. Sending Deregistration Binding Update . . . . . . . . 22
	5.6.4. Sending Binding Acknowledgement . . . . . . . . . . . 20		5.6.4. Sending Binding Acknowledgement . . . . . . . . . . . 23
	5.6.5. Sending Packets from the Home Link . . . . . . . . . . 22		5.6.5. Sending Packets from the Home Link . . . . . . . . . . 24
	5.6.6. Leaving from the Home Link . . . . . . . . . . . . . . 22		5.6.6. Leaving from the Home Link . . . . . . . . . . . . . . 25
	5.7. Receiving Binding Acknowledgement . . . . . . . . . . . . 23		5.7. Receiving Binding Acknowledgement . . . . . . . . . . . . 25
	5.8. Receiving Binding Refresh Request . . . . . . . . . . . . 24		5.8. Receiving Binding Refresh Request . . . . . . . . . . . . 26
	5.9. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 24		5.9. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 27
	6. Home Agent and Correspondent Node Operation . . . . . . . . . 25		6. Home Agent and Correspondent Node Operation . . . . . . . . . 28
	6.1. Searching Binding Cache with Binding Identifier . . . . . 25		6.1. Searching Binding Cache with Binding Identifier . . . . . 28
	6.2. Processing Binding Update . . . . . . . . . . . . . . . . 25		6.2. Processing Binding Update . . . . . . . . . . . . . . . . 28
	6.3. Sending Binding Refresh Request . . . . . . . . . . . . . 28		6.3. Sending Binding Refresh Request . . . . . . . . . . . . . 31
	6.4. Receiving Packets from Mobile Node . . . . . . . . . . . . 28		6.4. Receiving Packets from Mobile Node . . . . . . . . . . . . 31
	7. Network Mobility Applicability . . . . . . . . . . . . . . . . 29		7. Network Mobility Applicability . . . . . . . . . . . . . . . . 32
	8. DSMIPv6 Applicability . . . . . . . . . . . . . . . . . . . . 30		8. DSMIPv6 Applicability . . . . . . . . . . . . . . . . . . . . 33
	8.1. IPv4 Care-of Address Registration . . . . . . . . . . . . 30		8.1. IPv4 Care-of Address Registration . . . . . . . . . . . . 33
	8.2. IPv4 HoA Management . . . . . . . . . . . . . . . . . . . 31		8.2. IPv4 Home Address Management . . . . . . . . . . . . . . . 34
	9. IPsec and IKEv2 interaction . . . . . . . . . . . . . . . . . 32		9. IPsec and IKEv2 interaction . . . . . . . . . . . . . . . . . 35
	9.1. Use of Care-of Address in the IKEv2 exchange . . . . . . . 32		9.1. Use of Care-of Address in the IKEv2 exchange . . . . . . . 35
	9.2. Transport Mode IPsec protected messages . . . . . . . . . 33		9.2. Transport Mode IPsec protected messages . . . . . . . . . 36
	9.3. Tunnel Mode IPsec protected messages . . . . . . . . . . . 33		9.3. Tunnel Mode IPsec protected messages . . . . . . . . . . . 36
	9.3.1. Tunneled HoTi and HoT messages . . . . . . . . . . . . 33		9.3.1. Tunneled Home Test Init and Home Test messages . . . . 36
	9.3.2. Tunneled Payload Traffic . . . . . . . . . . . . . . . 34		9.3.2. Tunneled Payload Traffic . . . . . . . . . . . . . . . 37
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 35		10. Security Considerations . . . . . . . . . . . . . . . . . . . 38
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38		13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
	13.1. Normative References . . . . . . . . . . . . . . . . . . . 38		13.1. Normative References . . . . . . . . . . . . . . . . . . . 41
	13.2. Informative References . . . . . . . . . . . . . . . . . . 38		13.2. Informative References . . . . . . . . . . . . . . . . . . 41
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
	Intellectual Property and Copyright Statements . . . . . . . . . . 41		Intellectual Property and Copyright Statements . . . . . . . . . . 44
	1. Introduction		1. Introduction
	A mobile node may use various types of network interfaces to obtain		A mobile node may use various types of network interfaces to obtain
	durable and wide area network connectivity. This is increasingly		durable and wide area network connectivity. This has increasingly
	become true with mobile nodes having multiple interfaces such as		become true with mobile nodes having multiple interfaces such as
	802.2, 802.11, 802.16, cellular radios, etc.. The motivations for		802.2, 802.11, 802.16, cellular radios, etc. The motivations for and
	and benefits of using multiple points of attachment are discussed in		benefits of using multiple points of attachment are discussed in [ID-
	[ID-MOTIVATION]. When a mobile node with multiple interfaces uses		MOTIVATION]. When a mobile node with multiple interfaces uses Mobile
	Mobile IPv6 [RFC-3775] for mobility management, it cannot use its		IPv6 [RFC-3775] for mobility management, it cannot use its multiple
	multiple interfaces to send and receive packets while taking		interfaces to send and receive packets while taking advantage of
	advantage of session continuity provided by Mobile IPv6. This is		session continuity provided by Mobile IPv6. This is because Mobile
	because Mobile IPv6 allows the mobile node to only bind one care-of		IPv6 allows the mobile node to only bind one care-of address at a
	address at a time with its home address. See [ID-MIP6ANALYSIS] on a		time with its home address. See [ID-MIP6ANALYSIS] for a further
	further analysis of using multiple interfaces and addresses with		analysis of using multiple interfaces and addresses with Mobile IPv6.
	Mobile IPv6.
	This document proposes extensions to Mobile IPv6 to allow a mobile		This document proposes extensions to Mobile IPv6 to allow a mobile
	node to register multiple care-of addresses for a home address and		node to register multiple care-of addresses for a home address and
	create multiple binding cache entries. A new Binding Identification		create multiple binding cache entries. A new Binding Identification
	(BID) number is created for each binding the mobile node wants to		(BID) number is created for each binding the mobile node wants to
	create and sent in the binding update. The home agent that receives		create and sent in the binding update. The home agent that receives
	this Binding Update creates separate binding for each BID. The BID		this Binding Update creates a separate binding for each BID. The BID
	information is stored in the corresponding binding cache entry. The		information is stored in the corresponding binding cache entry. The
	BID information can now be used to identify individual bindings. The		BID information can now be used to identify individual bindings. The
	same extensions can also be used in Binding Updates sent to the		same extensions can also be used in Binding Updates sent to the
	correspondent nodes.		correspondent nodes.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC-2119].		document are to be interpreted as described in [RFC-2119].
	Terms used in this draft are defined in [RFC-3775], [RFC-3753] and		Terms used in this draft are defined in [RFC-3775], [RFC-3753] and
	[RFC-4885]. In addition or in replacement of these, the following		[RFC-4885]. In addition to or as a replacement of these, the
	terms are defined or redefined:		following terms are defined or redefined:
	Binding Identification number (BID)		Binding Identification number (BID)
	The BID is an identification number used to distinguish multiple		The BID is an identification number used to distinguish multiple
	bindings registered by the mobile node. Assignment of distinct		bindings registered by the mobile node. Assignment of distinct
	BIDs allows a mobile node to register multiple binding cache		BIDs allows a mobile node to register multiple binding cache
	entries for a given home address. The BIDs assigned to a same		entries for a given home address. The BIDs assigned to a same
	home address MUST NOT be duplicated at a time. Zero and negative		home address must not be duplicated at a time. Zero value is
	values MUST NOT be used. Each BID is generated and managed by a		reserved for future extension. Each BID is generated and managed
	mobile node. The BID is stored in the Binding Update List and is		by a mobile node. The BID is stored in the Binding Update List
	sent by the mobile node in the Binding Update. A mobile node MAY		and is sent by the mobile node in the Binding Update. A mobile
	change the value of a BID at any time according to its		node may change the value of a BID at any time according to its
	administrative policy, for instance to protect its privacy. An		administrative policy, for instance to protect its privacy. An
	implementation must carefully assign the BID so as to keep using		implementation must carefully assign the BID so as to keep using
	the same BID for the same binding even when the status of the		the same BID for the same binding even when the status of the
	binding is changed. More details can be found in Section 5.1.		binding is changed. More details can be found in Section 5.1.
	Binding Identifier Mobility Option		Binding Identifier Mobility Option
	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
	for home registration (i.e. with the home agent) as explained in		for home registration (i.e. with the home agent) as explained in
	Section 5.3. A mobile node MUST NOT perform bulk registration		Section 5.3. A mobile node must not perform bulk registration
	mechanism described in this specification with a correspondent		mechanism described in this specification with a correspondent
	node.		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
	skipping to change at page 6, line 32		skipping to change at page 6, line 32
	node, and if the BID in the Binding Update does not match the one		node, and if the BID in the Binding Update does not match the one
	with the existing entry, the home agent MUST create a new binding		with the existing entry, the home agent MUST create a new binding
	cache entry for the new care-of address and BID. The mobile node can		cache entry for the new care-of address and BID. The mobile node can
	register multiple care-of addresses either independently in		register multiple care-of addresses either independently in
	individual Binding Updates or multiple at once in a single Binding		individual Binding Updates or multiple at once in a single Binding
	Update.		Update.
	If the mobile host wishes to register its binding with a		If the mobile host wishes to register its binding with a
	correspondent node, it must perform return routability operations as		correspondent node, it must perform return routability operations as
	described in [RFC-3775]. This includes managing a Care-of Keygen		described in [RFC-3775]. This includes managing a Care-of Keygen
	token per care-of address and exchanging CoTi and CoT message with		token per care-of address and exchanging Care-of Test Init and
	the correspondent node for each care-of address. The mobile node MAY		Care-of Test message with the correspondent node for each care-of
	use the same BID that it used with the home agent for a particular		address. The mobile node MAY use the same BID that it used with the
	care-of address. For protocol simplicity, bulk registration to		home agent for a particular care-of address. For protocol
	correspondent nodes is not supported in this document. This is		simplicity, bulk registration to correspondent nodes is not supported
	because the Return Routability mechanism introduced in [RFC-3775]		in this document. This is because the Return Routability mechanism
	cannot be easily extended to verify multiple care-of addresses stored		introduced in [RFC-3775] cannot be easily extended to verify multiple
	in a single Binding Update.		care-of addresses stored in a single Binding Update.
	Figure 1 illustrates the configuration where the mobile node obtains		Figure 1 illustrates the configuration where the mobile node obtains
	multiple care-of addresses at foreign links. The mobile node can		multiple care-of addresses at foreign links. The mobile node can
	utilize all the care-of addresses. In Figure 1, the home address of		utilize all the care-of addresses. In Figure 1, the home address of
	the mobile node (MN) is 2001:db8::EUI. The mobile node has 3		the mobile node (MN) is 2001:db8::EUI. The mobile node has 3
	different interfaces and possibly acquires care-of addresses 1-3		different interfaces and possibly acquires care-of addresses 1-3
	(CoA1, CoA2, CoA3). The mobile node assigns BID1, BID2 and BID3 to		(CoA1, CoA2, CoA3). The mobile node assigns BID1, BID2 and BID3 to
	each care-of address.		each care-of address.
	+----+		+----+
	| CN |		| CN |
	+--+-+		+--+-+
	|		|
	+---+------+ +----+		+---+------+ +----+
	+------+ Internet |----------+ HA |		+------+ Internet |----------+ HA |
	| +----+---+-+ +--+-+		| +----+---+-+ +--+-+
	CoA2| | | | Home Link		CoA2| | | | Home Link
	+--+--+ | | ------+------		+--+--+ | | ------+------
	| MN +========+ |		| MN +--------+ |
	+--+--+ CoA1 |		+--+--+ CoA1 |
	CoA3| |		CoA3| |
	+---------------+		+---------------+
	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 [2001:db8::EUI care-of address1 BID1]		binding [2001:db8::EUI care-of address1 BID1]
	binding [2001:db8::EUI care-of address2 BID2]		binding [2001:db8::EUI care-of address2 BID2]
	binding [2001:db8::EUI care-of address3 BID3]		binding [2001:db8::EUI care-of address3 BID3]
	correspondent node's binding		correspondent node's binding
	skipping to change at page 8, line 12		skipping to change at page 8, line 12
	particular care-of address. However, the binding cache lookup using		particular care-of address. However, the binding cache lookup using
	policy or flow filters is out of scope for this document. If no such		policy or flow filters is out of scope for this document. If no such
	mechanism is available and no BID is found for a packet, a node		mechanism is available and no BID is found for a packet, a node
	SHOULD use the binding which was last verified by receiving data		SHOULD use the binding which was last verified by receiving data
	packets or signaling from the mobile node. In case the binding cache		packets or signaling from the mobile node. In case the binding cache
	lookup for data packets, using the combination of home address and		lookup for data packets, using the combination of home address and
	BID, does not return a valid binding cache entry, the home agent		BID, does not return a valid binding cache entry, the home agent
	SHOULD perform the lookup based on only the home address as described		SHOULD perform the lookup based on only the home address as described
	in [RFC-3775].		in [RFC-3775].
			In any case, to avoid problems with upper layer protocols and TCP in
			particular, a single packet flow as identified by the 5-tuple SHOULD
			only be sent to a single care-of address at a time.
	The mobile node may return to the home link through one of its		The mobile node may return to the home link through one of its
	interfaces. There are two options possible for the mobile node when		interfaces. There are two options possible for the mobile node when
	its returns home. Section 5.6 and Section 5.5.1 describe the		its returns home. Section 5.6 and Section 5.5.1 describe the
	returning home procedures in more detail.		returning home procedures in more detail.
	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. This is illustrated in Figure 2. It de-registers		the home link. This is illustrated in Figure 2. It de-registers
	all bindings with the home agent related to all care-of		all bindings with the home agent related to all care-of
	addresses. The interfaces still attached to the visited link(s)		addresses. The interfaces still attached to the visited link(s)
	are no longer going to be receiving any encapsulated traffic from		are no longer going to be receiving any encapsulated traffic from
	skipping to change at page 8, line 40		skipping to change at page 9, line 14
	+----+		+----+
	| CN |		| CN |
	+--+-+		+--+-+
	|		|
	+---+------+ +----+		+---+------+ +----+
	+------+ Internet |----------+ HA |		+------+ Internet |----------+ HA |
	| +----+-----+ +--+-+		| +----+-----+ +--+-+
	CoA2| | | Home Link		CoA2| | | Home Link
	+--+--+ | --+---+------		+--+--+ | --+---+------
	| MN +========+ |		| MN +--------+ |
	+--+--+ CoA1 |		+--+--+ CoA1 |
	| |		| |
	+---------------------------+		+---------------------------+
	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 [2001:db8::EUI care-of address1 BID1]		binding [2001:db8::EUI care-of address1 BID1]
	binding [2001:db8::EUI care-of address2 BID2]		binding [2001:db8::EUI care-of address2 BID2]
	skipping to change at page 9, line 4		skipping to change at page 9, line 25
	+--+--+ CoA1 |		+--+--+ CoA1 |
	| |		| |
	+---------------------------+		+---------------------------+
	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 [2001:db8::EUI care-of address1 BID1]		binding [2001:db8::EUI care-of address1 BID1]
	binding [2001:db8::EUI care-of address2 BID2]		binding [2001:db8::EUI care-of address2 BID2]
	Figure 2: Using only Interface Attached to Home Link		Figure 2: Using only Interface Attached to Home Link
	2. The mobile node may simultaneously use both the interface		2. 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 3. There are two possible		the visited link(s) as shown in Figure 3. There are two possible
	topologies depending on whether the home agent is only router on		topologies depending on whether the home agent is the only router
	the home link or not. The operation of Neighbor Discovery [RFC-		on the home link or not. The operation of Neighbor Discovery
	4861] is different in the two topologies. More details can be		[RFC-4861] is different in the two topologies. More details can
	found in Section 5.6. The home agent and the correspondent node		be found in Section 5.6. The home agent and the correspondent
	have the binding entries listed in Figure 3 in their binding		node have the binding entries listed in Figure 3 in their binding
	cache database in both topologies. The home agent also knows		cache database in both topologies. The home agent also knows
	that the mobile node is attached to the home link. All the		that the mobile node is attached to the home link. All the
	traffic from the Internet is intercepted by the home agent first		traffic from the Internet is intercepted by the home agent first
	and routed to either the interface attached to the home link or		and routed to either the interface attached to the home link or
	the one of the foreign links. How the home agent decides to		the one of the foreign links. How the home agent decides to
	route a particular flow to the interface attached to the home		route a particular flow to the interface attached to the home
	link or foreign link is out of scope in this document.		link or foreign link 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 |
	| |		| |
	+---------------------------+		+---------------------------+
	Topology-b)		Topology-b)
	+----+		+----+
	| CN |		| CN |
	+--+-+		+--+-+
	|		|
	+---+------+ Router +----+		+---+------+ Router +----+
	+------+ Internet |-------R | HA |		+------+ Internet |-------R | HA |
	| +----+-----+ | +--+-+		| +----+-----+ | +--+-+
	CoA2| | | | Home Link		CoA2| | | | Home Link
	+--+--+ | --+-+-------+------		+--+--+ | --+-+-------+------
	| MN +========+ |		| MN +--------+ |
	+--+--+ CoA1 |		+--+--+ CoA1 |
	| |		| |
	+---------------------------+		+---------------------------+
	Binding Cache Database:		Binding Cache Database:
	home agent's binding		home agent's binding
	binding [2001:db8::EUI care-of address1 BID1]		binding [2001:db8::EUI care-of address1 BID1]
	binding [2001:db8::EUI care-of address2 BID2]		binding [2001:db8::EUI care-of address2 BID2]
	correspondent node's binding		correspondent node's binding
	binding [2001:db8::EUI care-of address1 BID1]		binding [2001:db8::EUI care-of address1 BID1]
	binding [2001:db8::EUI care-of address2 BID2]		binding [2001:db8::EUI care-of address2 BID2]
	Figure 3: Simultaneous Home and Visited Link Operation		Figure 3: Simultaneous Home and Visited Link Operation
			This specification keeps backwards compatibility with [RFC-3775]. If
			a receiver (either home agent or correspondent node) does not support
			this specification, it does not understand the binding identifier
			mobility option. The receiver skip the unknown mobility option (i.e.
			Binding Identifier mobility option) and process the Binding Update as
			defined in [RFC-3775]. In order to keep the backward compatibility
			with [RFC-3775], when a mobile node sends a Binding Update message
			with extensions described in this document, the receiver needs to
			reflect the Binding Identifier mobility option in the Binding
			Acknowledgement. If the mobile node finds no Binding Identifier
			mobility options in the received Binding Acknowledgement, it assumes
			the other end node does not support this specification. In such
			case, the mobile node needs to fall back to the legacy RFC-3775
			compliant mobile node. If it is the home registration, the mobile
			node MAY try to discover another home agent supporting BID mobility
			option for the home registration.
	4. Mobile IPv6 Extensions		4. Mobile IPv6 Extensions
	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 MUST be shared among all the binding update		The sequence number value MUST be shared among all the binding update
	list entries related to binding updates sent to a particular home		list entries related to binding updates sent to a particular home
	agent or correspondent node. Whenever a mobile node sends either		agent or correspondent node. Whenever a mobile node sends either an
	individual or bulk binding update, the sequence number is		individual or a bulk binding update, the sequence number is
	incremented. When a home agent receives an individual BU, it should		incremented. When a home agent receives an individual BU, it should
	update the sequence number for all the bindings for a particular		update the sequence number for all the bindings for a particular
	mobile node with the sequence number in the received BU.		mobile node with the sequence number in the received BU.
	4.2. Binding Identifier Mobility Option		4.2. Binding Update Message
			This specification extends the Binding Update message with a new
			flag. The flag is shown and described below.
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Sequence # |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			|A|H|L|K|M|R|P|F|T|O| Reserved | Lifetime |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			. .
			. Mobility options .
			. .
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 4: Binding Update message
			Overwrite (O) flag
			When this flag is set, all the binding cache entries for a mobile
			node are replaced by new entries registering with this binding
			update message. This flag is only used when BID Mobility Option
			is carried with Binding Update.
			Reserved
			6 bits Reserved field.
			4.3. 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. The Binding Identifier Mobility		Test Init and Care-of Test message. The Binding Identifier Mobility
	Option has an alignment requirement of 2n if the Care-of Address		Option has an alignment requirement of 2n if the Care-of Address
	field is not present. Otherwise, it has the alignment requirement of		field is not present. Otherwise, it has the alignment requirement of
	8n + 2.		8n + 2.
	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 |O|H| Reserved |		| Binding ID (BID) | Status |H| Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
	+ +		+ +
	: IPv4 or IPv6 care-of address (CoA) :		: IPv4 or IPv6 care-of address (CoA) :
	+ +		+ +
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	Figure 4: 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 either 4,		excluding the Type and Length fields. It MUST be set to either 4,
	12, or 20 depending on the care-of address field. When the		8, or 20 depending on the care-of address field. When the care-of
	care-of address is not carried by this option, the length value		address is not carried by this option, the length value MUST be
	MUST be set to 4. If the IPv4 care-of address is stored in the		set to 4. If the IPv4 care-of address is stored in the care-of
	care-of address field, the length MUST be 12. Otherwise, the		address field, the length MUST be 8. Otherwise, the Length value
	Length value MUST be set to 20 for IPv6 care-of address.		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.		SHOULD NOT be used.
	Status		Status
	The Status field is an 8-bit unsigned integer. When the Binding		The Status field is an 8-bit unsigned integer. When the Binding
	Identifier mobility option is included in a Binding		Identifier mobility option is included in a Binding
	Acknowledgement, this field overwrites the status field in the		Acknowledgement, this field overwrites the status field in the
	Binding Acknowledgement only for this BID. If this field is set		Binding Acknowledgement only for this BID. If this field is set
	to zero, the receiver ignores this field and uses the registration		to zero, the receiver ignores this field and uses the registration
	status stored in the Binding Acknowledgement message. The		status stored in the Binding Acknowledgement message. The
	receiver MUST ignore this field if the Binding Identifier mobility		receiver MUST ignore this field if the Binding Identifier mobility
	option is not carried within either the Binding Acknowledgement or		option is not carried within either the Binding Acknowledgement or
	the Care-of Test messages. The possible status codes are the same		the Care-of Test messages. The possible status codes are the same
	as the status codes of Binding Acknowledgement. This Status field		as the status codes of Binding Acknowledgement. This Status field
	is also used to carry error information related to the care-of		is also used to carry error information related to the care-of
	address test in the Care-of Test message.		address test in the Care-of Test message.
	Overwrite (O) flag
	When this flag is set, all the binding cache entries for a mobile
	node are replaced by new entries registering with this binding
	update message. This flag is only used when BID Mobility Option
	is carried with Binding 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.
	Reserved		Reserved
	5 bits Reserved field. The value MUST be initialized to zero by		7 bits Reserved field. The value MUST be initialized to zero by
	the sender, and MUST be ignored by the receiver.		the sender, and SHOULD be ignored by the receiver.
	Care-of Address		Care-of Address
	If a Binding Identifier mobility option is included in a Binding		If a Binding Identifier mobility option is included in a Binding
	Update, either IPv4 or IPv6 care-of address for the corresponding		Update, either IPv4 or IPv6 care-of address for the corresponding
	BID can be stored in this field. If no address is specified in		BID can be stored in this field. If no address is specified in
	this field, the length of this field MUST be zero (i.e. not		this field, the length of this field MUST be zero (i.e. not
	appeared in the option). If no address is specified in this		appeared in the option). If no address is specified in this
	field, a care-of address is taken from the source address of the		field, a care-of address is taken from the source address of the
	IPv6 header. If the option is included in any other messages than		IPv6 header. If the option is included in any other messages than
	a Binding Update, the length of this field MUST be also zero.		a Binding Update, the length of this field MUST be also zero.
	4.3. New Status Values for Binding Acknowledgement		4.4. 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 less than 128)		MCOA NOTCOMPLETE (TBD less than 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.		options were successfully registered. Some of them were rejected.
	The error status value of the failed mobility option is		The error status value of the failed mobility option is
	individually stored in the status field of the binding identifier		individually stored in the status field of the binding identifier
	mobility option.		mobility option.
	MCOA RETURNHOME WO/NDP (TBD less than 128)		MCOA RETURNHOME WO/NDP (TBD less than 128)
	When a mobile node returns home, it MUST NOT use NDP for the home		When a mobile node returns home, it MUST NOT use Neighbor
	address on the home link. This is explained in more detail in		Discovery Protocol for the home address on the home link. This is
	Section 5.6		explained in more detail in Section 5.6
	MCOA MALFORMED (TBD more than 128)		MCOA MALFORMED (TBD more than 128)
	Registration failed because Binding Identifier mobility option was		Registration failed because Binding Identifier mobility option was
	not formatted correctly.		not formatted correctly. This value is used in the following
			cases.
			* when the wrong length value is specified (neither 4, 8 nor 20)
			in the length field of the Binding Identifier mobility option.
			* when a unicast routable address is not specified in the care-of
			address field of the Binding Identifier mobility option.
			* when a care-of address is not appeared in the care-of address
			field of the Binding Identifier mobility option stored in an
			IPsec ESP protected Binding Update.
	MCOA BID CONFLICT (TBD more than 128)		MCOA BID CONFLICT (TBD more than 128)
	The home agent cannot cache both a regular binding and a BID		The home agent cannot cache both a regular binding and a BID
	extended binding simultaneously. It returns this status value		extended binding simultaneously. It returns this status value
	when the received binding conflicts with the existing binding		when the received binding conflicts with the existing binding
	cache entry(ies).		cache entry(ies).
	MCOA PROHIBITED(TBD more than 128)		MCOA PROHIBITED(TBD more than 128)
	It implies the multiple care-of address registration is		It implies the multiple care-of address registration is
	administratively prohibited.		administratively prohibited.
	MCOA BULK REGISTRATION PROHIBITED(TBD more than 128)		MCOA BULK REGISTRATION PROHIBITED(TBD more than 128)
	Bulk binding registration is not either permitted or supported.		Bulk binding registration is not either permitted or supported.
	Note that the bulk registration is optional procedure and might		Note that the bulk registration is an optional procedure and might
	not be available on a home agent.		not be available on a home agent.
	MCOA SIMULTANEOUS HOME AND FOREIGN PROHIBITED (TBD more than 128)		MCOA SIMULTANEOUS HOME AND FOREIGN PROHIBITED (TBD more than 128)
	Simultaneous home and foreign attachment is neither supported nor		Simultaneous home and foreign attachment is neither supported nor
	permitted.		permitted.
	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)
	skipping to change at page 15, line 32		skipping to change at page 17, line 32
	of the announced prefixes.		of the announced prefixes.
	The difference between the above two cases is only in the number of		The difference between the above two cases is only in the number of
	physical network interfaces and therefore irrelevant in this		physical network interfaces and therefore irrelevant in this
	document. What is of significance is the fact that the mobile node		document. What is of significance is the fact that the mobile node
	has several addresses it can use as care-of addresses.		has several addresses it can use as care-of addresses.
	A mobile node assigns a BID to each care-of address when it wants to		A mobile node assigns a BID to each care-of address when it wants to
	register them simultaneously with its home address. The BID MUST be		register them simultaneously with its home address. The BID MUST be
	unique for a given home address and care-of address pair. The value		unique for a given home address and care-of address pair. The value
	should be an integer between 1 and 65535. Zero value MUST NOT be		should be an integer between 1 and 65535. Zero value SHOULD NOT be
	used as BIDs. If a mobile node has only one care-of address, the		used as BIDs. If a mobile node has only one care-of address, the
	assignment of a BID is not needed until it has multiple care-of		assignment of a BID is not needed until it has multiple care-of
	addresses to register with, at which time all of the care-of		addresses to register with, at which time all of the care-of
	addresses MUST be mapped to BIDs.		addresses MUST be mapped to BIDs.
	5.2. Binding Registration		5.2. Binding Registration
	For the multiple Care-of Addresses registration, the mobile node MUST		For the multiple Care-of Addresses registration, the mobile node MUST
	include a Binding Identifier mobility option(s) in the Binding Update		include a Binding Identifier mobility option(s) in the Binding Update
	as shown in Figure 5. The BID is copied from a corresponding Binding		as shown in Figure 6. The BID is copied from a corresponding Binding
	Update List entry to the BID field of the Binding Identifier mobility		Update List entry to the BID field of the Binding Identifier mobility
	option. When IPsec ESP is used for protecting the Binding Update,		option.
	the care-of address can be carried in the Care-of Address field of
	the Binding Identifier mobility option. If this is done, the		When IPsec ESP is used for protecting the Binding Update, a care-of
	alternate care-of address option MUST NOT be included in the Binding		address MUST be carried in an alternate care-of address mobility
	Update. For binding registration to a correspondent node, the mobile		option as described in [RFC-4877]. However, in this specification,
	node MUST have both active Home and Care-of Keygen tokens for Kbm		the care-of address MUST be carried in the Care-of Address field of
	(see Section 5.2.5 of [RFC-3775]) before sending the Binding Update.		the Binding Identifier mobility option. In order to save bits of the
	The care-of Keygen tokens MUST be maintained for each care-of address		Binding Update, the alternate care-of address option MUST NOT be
	that the mobile node wants to register to the correspondent node.		included.
			For binding registration to a correspondent node, the mobile node
			MUST have both active Home and Care-of Keygen tokens for Kbm (see
			Section 5.2.5 of [RFC-3775]) before sending the Binding Update. The
			care-of Keygen tokens MUST be maintained for each care-of address
			that the mobile node wants to register to the correspondent node.
	The Binding Update to the correspondent node is protected by the		The Binding Update to the correspondent node is protected by the
	Binding Authorization Data mobility option that is placed after the		Binding Authorization Data mobility option that is placed after the
	Binding Identifier mobility option.		Binding Identifier mobility option.
	IPv6 header (src="" class="delete">oA, dst=HA)		IPv6 header (src="" class="insert">are-of Address, dst=Home Agent Address)
	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 option		Binding Identifier mobility option
	Binding Authorization mobility option+		Binding Authorization mobility option+
	(*) if necessary, for home registration		(*) if necessary, for home registration
	(+) if necessary, for route optimization		(+) if necessary, for route optimization
	Figure 5: Binding Update for Binding Registration		Figure 6: Binding Update for Binding 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 single binding in the sent Binding Update, it		the home agent with the single binding in the sent Binding Update, it
	sets the 'O' flag. Section 6.2 describes this registration procedure		sets the 'O' flag. Section 6.2 describes this registration procedure
	in detail.		in detail.
	5.3. Bulk Registration		5.3. 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. This document specifies bulk registration only for the		scarce. This document specifies bulk registration only for the
	mobile node's home registration. A mobile node performing bulk		mobile node's home registration. A mobile node performing bulk
	registration with a correspondent node is out of scope.		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 6. The rest of the fields and options in the Binding		in Figure 7. The rest of the fields and options in the Binding
	Update such as Lifetime, Sequence Number, and the flags in the		Update such as Lifetime, Sequence Number, and the flags in the
	Binding Update are common across all care-of addresses. The		Binding Update are common across all care-of addresses.
	alternate care-of address option MUST NOT be used.
	IPv6 header (src="" dst=HA)		When IPsec ESP is used for protecting the Binding Update, a care-of
			address MUST be carried in an alternate care-of address mobility
			option as described in [RFC-4877]. However, in the bulk
			registration, the care-of addresses are always carried in the Care-of
			Address field of the Binding Identifier mobility option. In order to
			save bits of the Binding Update, the alternate care-of address option
			MUST NOT be included in such Binding Update.
			IPv6 header (src="" Address, dst=Home Agent Address)
	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 (CoA)		Binding Identifier (including Care-of Address)
	Figure 6: Binding Update for Bulk Registration
			Figure 7: 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 multiple bindings in the sent Binding Update,		the home agent with the multiple bindings in the sent Binding Update,
	it sets the 'O' flag.		it sets the 'O' flag in the Binding Update.
	5.4. Binding De-Registration		5.4. Binding De-Registration
	When a mobile node decides to delete all the bindings for its home		When a mobile node decides to delete all the bindings for its home
	address, it sends a regular de-registration Binding Update with		address, it sends a regular de-registration Binding Update with
	lifetime set to zero as defined in [RFC-3775]. The Binding		lifetime set to zero as defined in [RFC-3775]. The Binding
	Identifier mobility option is not required.		Identifier mobility option is not required.
	If a mobile node wants to delete a particular binding(s) from its		If a mobile node wants to delete a particular binding(s) from its
	home agent and correspondent nodes, the mobile node sends a Binding		home agent and correspondent nodes, the mobile node sends a Binding
	skipping to change at page 17, line 50		skipping to change at page 20, line 14
	described in Section 5.4. After the de-registration step, all the		described in Section 5.4. 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(s). While the mobile node de-registers		attached to the visited link(s). While the mobile node de-registers
	all the bindings from the home agent, it may continue registering		all the bindings from the home agent, it may continue registering
	bindings for interface(s) attached to visited link(s) to the		bindings for interface(s) attached to visited link(s) to the
	correspondent node as shown in Figure 2.		correspondent node as shown in Figure 2.
	5.5.2. Using only Interface attached to the Visited Link		5.5.2. Using only Interface attached to the Visited Link
	The mobile node returns home in physically and shuts down the		The mobile node returns home physically but shuts down the interface
	interface attached to the home link. As a result, a mobile node does		attached to the home link. As a result, a mobile node does not
	not return home even though it attaches to the home link by one of		return home even though it attaches to the home link by one of
	interfaces. Following procedures should be taken by the mobile node.		interfaces. Following procedures should be taken by the mobile node.
	Before shutting down the interface, any binding for the care-of		Before shutting down the interface, any binding for the care-of
	address previously associated with the interface should be deleted.		address previously associated with the interface should be deleted.
	To delete the binding cache entry, the mobile node SHOULD send a de-		To delete the binding cache entry, the mobile node SHOULD send a de-
	registration Binding Update with the lifetime set to zero and include		registration Binding Update with the lifetime set to zero and include
	the corresponding BID information. If the mobile node does not send		the corresponding BID information. If the mobile node does not send
	a de-registration Binding Update, the binding for the care-of address		a de-registration Binding Update, the binding for the care-of address
	previously assigned to the interface remains at the home agent until		previously assigned to the interface remains at the home agent until
	its lifetime expires.		its lifetime expires.
	skipping to change at page 18, line 28		skipping to change at page 20, line 40
	5.6. Returning Home: Simultaneous Home and Visited Link Operation		5.6. Returning Home: Simultaneous Home and Visited Link Operation
	5.6.1. Problems of Simultaneous Home and Foreign Attachments		5.6.1. 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 3. The		attached to both foreign and home links as shown in Figure 3. 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
	states conflicts at the home link.		state conflicts at the home link.
	In [RFC-3775], the home agent intercepts packets meant for the mobile		In [RFC-3775], the home agent intercepts packets meant for the mobile
	node using the Proxy Neighbor Discovery [RFC-4861] while the mobile		node using Proxy Neighbor Discovery [RFC-4861] while the mobile node
	node is away from the home link. When the mobile node returns home,		is away from the home link. When the mobile node returns home, the
	the home agent deletes the binding cache and stops proxying for the		home agent deletes the binding cache and stops proxying for the home
	home address so that a mobile node can configure its home address on		address so that a mobile node can configure its home address on the
	the interface attached to the home link. In this specification, a		interface attached to the home link. In this specification, a mobile
	mobile node may return home, configure the home address on the		node may return home, configure the home address on the interface
	interface attached to the home link, but still use the interfaces		attached to the home link, but still use the interfaces attached to
	attached to the foreign links. In this case, a possible conflict		the foreign links. In this case, a possible conflict arises when the
	arises when the both the home agent and the mobile node try to defend		both the home agent and the mobile node try to defend the home
	the home address. If the home agent stops proxying for the home		address. If the home agent stops proxying for the home address, the
	address, the packets are always routed to the interface attached to		packets are always routed to the interface attached to the home link
	the home link and are never routed to the interfaces attached to the		and are never routed to the interfaces attached to the visited links.
	visited links. It is required to avoid the conflict between the home		It is required to avoid the conflict between the home agent and the
	agent and the mobile node, while still allowing the simultaneous use		mobile node, while still allowing the simultaneous use of home and
	of home and foreign links. The following describes the mechanism for		foreign links. The following describes the mechanism for achieving
	achieving this.		this.
	5.6.2. Overview and Approach		5.6.2. Overview and Approach
	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 flow. How to make this decision is out of scope in this		type of flow. How to make this decision is out of scope in this
	skipping to change at page 19, line 22		skipping to change at page 21, line 34
	Home Agent is the only router at the home link or not. The		Home Agent is the only router at the home link or not. The
	difference is on who defends the home address by (Proxy) Neighbor		difference is on who defends the home address by (Proxy) Neighbor
	Discovery on the home link.		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 3). The		Discovery Protocol (illustrated as topology-a in Figure 3). The
	home agent is the only router on the home link. Therefore the		home agent is the only router on the home link. Therefore the
	home agent is capable of intercepting packets without relying on		home agent is capable of intercepting packets without relying on
	the proxy Neighbor Discovery protocol and the mobile node can		the proxy Neighbor Discovery protocol and the mobile node can
	manage the Neighbor Cache entry of the home address on the home		manage the Neighbor Cache entry of the home address on the home
	link as a regular IPv6 node.　However, there is one		link as a regular IPv6 node. However, there is one limitation of
	limitation of this scenario. If a correspondent node is located		this scenario. If a correspondent node is located at the home
	at the home link, the home agent may not intercept the packets		link, the home agent may not intercept the packets destined to
	destined to the mobile node. These packets are routed only via		the mobile node. These packets are routed only via the home
	the home link, but this is most optimized path for the mobile		link, but this is the most optimal path for the mobile node to
	node to communicate with nodes on the home link.		communicate with nodes on the home link.
	2. If there are other routers on the home link apart from the home		2. If there are other routers on the home link apart from the home
	agent, then it cannot be guaranteed that all packets meant for		agent, then it cannot be guaranteed that all packets meant for
	the mobile node are routed to the home agent. In this case, the		the mobile node are routed to the home agent. In this case, the
	mobile node MUST NOT operate Neighbor Discovery protocol for the		mobile node MUST NOT operate the Neighbor Discovery protocol for
	home address on the home link. This allows the home agent to		the home address on the home link. This allows the home agent to
	keep using proxy neighbor discovery and thus it keeps receiving		keep using proxy neighbor discovery and thus it keeps receiving
	all the packets sent to the mobile node's home address. If the		all the packets sent to the mobile node's home address. If the
	home agent, according to its local policy, needs to deliver		home agent, according to its local policy, needs to deliver
	packets to the mobile node over the home link, an issue arises		packets to the mobile node over the home link, an issue arises
	with respect to how the home agent discovers the mobile node's		with respect to how the home agent discovers the mobile node's
	link local address. This specification uses Link-layer Address		link local address. This specification uses the Link-layer
	(LLA) Option defined in [RFC-5268] in order to carry the mobile		Address (LLA) Option defined in [RFC-5268] in order to carry the
	node's link-layer address in the Binding Update. Likewise, the		mobile node's link-layer address in the Binding Update.
	mobile node would also know the link-layer address of the default		Likewise, the mobile node would also know the link-layer address
	router address to send packets from the home link without		of the default router address to send packets from the home link
	Neighbor Discovery. The link-layer address is used to transmit		without Neighbor Discovery. The link-layer address is used to
	packets from and to the mobile node on the home link. The		transmit packets from and to the mobile node on the home link.
	packets are transmitted without the Neighbor Discovery protocol		The packets are transmitted without the Neighbor Discovery
	by constructing the link-layer header manually. This operation		protocol by constructing the link-layer header manually. This
	is similar to Mobile IPv6 [RFC-3775] when a mobile node sends a		operation is similar to Mobile IPv6 [RFC-3775] when a mobile node
	deregistration binding update to the home agent's link-layer		sends a deregistration binding update to the home agent's link-
	address in returning home operation.		layer address in the operation for returning home.
	5.6.3. Sending Deregistration Binding Update		5.6.3. 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. For the binding deregistration, a mobile		the BID mobility option. For the binding deregistration, a mobile
	node SHOULD NOT store a care-of address in the Care-of Address		node SHOULD NOT store a care-of address in the Care-of Address
	field of the BID mobility option. The receive, the home agent,		field of the BID mobility option. The receive, the home agent,
	can match the removed binding with BID value in the BID mobility		can match the removed binding with BID value in the BID mobility
	option. If the mobile node has to remove multiple bindings		option. If the mobile node has to remove multiple bindings
	simultaneously, it contains multiple BID mobility options with O		simultaneously, it contains multiple BID mobility options and sets
	flag set. When the 'H' flag is set, the home agent recognizes		'O' flag in the Binding Update message. When the 'H' flag is set,
	that the mobile node wants to continue using interfaces attached		the home agent recognizes that the mobile node wants to continue
	to both home and visited links. Note that H flag MUST be set for		using interfaces attached to both home and visited links. Note
	all the binding updates sent from the mobile node (ex. Binding		that H flag MUST be set for the subsequent binding updates sent
	Update for the interface(s) attached to the foreign link(s)). If		from the mobile node (ex. Binding Update for the interface(s)
	the home agent does not allow this scenario, it MUST send a		attached to the foreign link(s)). If the home agent does not
	Binding Acknowledgement with the status code [MCOA SIMULTANEOUS		allow this scenario, it MUST send a Binding Acknowledgement with
	HOME AND FOREIGN PROHIBITED] set.		the status code [MCOA SIMULTANEOUS HOME AND FOREIGN PROHIBITED]
			set.
	o The mobile node SHOULD include the Link-layer Address (LLA) Option		o The mobile node SHOULD include the Link-layer Address (LLA) Option
	[RFC-5268] to notify the mobile node's link-layer address to the		[RFC-5268] to notify the mobile node's link-layer address to the
	home agent, too. The option code of the Link-layer Address (LLA)		home agent, too. The option code of the Link-layer Address (LLA)
	option MUST be set to '2' (Link-layer Address of the mobile node).		option MUST be set to '2' (Link-layer Address of the mobile node).
	This link-layer address is required for the home agent to send the		This link-layer address is required for the home agent to send the
	Binding Acknowledgement and to forward the mobile node's packet.		Binding Acknowledgement and to forward the 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. If the		home agent may continue proxying for the home address. If the
	mobile node receives [MCOA RETURNHOME WO/NDP (TBD)] status value		mobile node receives [MCOA RETURNHOME WO/NDP (TBD)] status value
	in the received Binding Acknowledgment, it MUST NOT respond to		in the received Binding Acknowledgment, it MUST NOT respond to
	Neighbor Solicitation even after the Binding Acknowledgement.		Neighbor Solicitation even after the Binding Acknowledgement.
	5.6.4. Sending Binding Acknowledgement		5.6.4. Sending Binding Acknowledgement
			The operations described in this section is for Home Agent and not
			for Mobile Node. However, the Home Agent operations described in
			this section are related to the returning home using simultaneous use
			of home and foreign links.
	o When the home agent sends the Binding Acknowledgement after		o When the home agent sends the Binding Acknowledgement after
	successfully processing the binding de-registration, it MUST set		successfully processing the binding de-registration, it MUST set
	the status value to either 0 [Binding Update Accepted] or to [MCOA		the status value to either 0 [Binding Update Accepted] or to [MCOA
	RETURNHOME WO/NDP (TBD)] in the Status field of the Binding		RETURNHOME WO/NDP (TBD)] in the Status field of the Binding
	Acknowledgment depending on home agent configuration at the home		Acknowledgment depending on home agent configuration at the home
	link. The new values are:		link. The new values are:
	* Binding Update Accepted (0): NDP is permitted for the home		* Binding Update Accepted (0): Neighbor Discovery Protocol is
	address at the home link. This is regular returning home		permitted for the home address at the home link. This is
	operation of [RFC-3775]		regular returning home operation of [RFC-3775]
	* MCOA RETURNHOME WO/NDP (TBD): NDP is prohibited for the home		* MCOA RETURNHOME WO/NDP (TBD): Neighbor Discovery Protocol is
	address at the home link		prohibited for the home address at the home link
	If the binding update is rejected, the appropriate error value		The respective Binding Identifier mobility options need to be
	MUST be set to the status field. In this case, the home agent		included in the Binding Acknowledgement.
	operation is same as [RFC-3775].
			o If the binding update is rejected, the appropriate error value
			MUST be set in the status field. In this case, the home agent
			operation is the same as [RFC-3775].
	o Only if the home agent is certainly the only router in the home		o Only if the home agent is certainly the only router in the home
	link, it MAY turn off Neighbor Discovery for the requested home		link, it MAY turn off Neighbor Discovery for the requested home
	address and responds with the [Binding Update Accepted] status		address and responds with the [Binding Update Accepted] status
	value to the mobile node. Since the mobile node will not reply to		value to the mobile node. Since the mobile node will not reply to
	Neighbor Solicitation for the home address before receiving the		Neighbor Solicitation for the home address before receiving the
	Binding Acknowledgement, the home agent SHOULD use the link-layer		Binding Acknowledgement, the home agent SHOULD use the link-layer
	address carried by the Link Layer Address option [RFC-5268] in the		address carried by the Link Layer Address option [RFC-5268] in the
	received Binding Update. After the completion of the binding		received Binding Update. After the completion of the binding
	deregistration, the mobile node starts regular Neighbor Discovery		deregistration, the mobile node starts regular Neighbor Discovery
	skipping to change at page 21, line 38		skipping to change at page 24, line 13
	exchange of Neighbor Solicitation and Neighbor Advertisement.		exchange of Neighbor Solicitation and Neighbor Advertisement.
	o On the other hand, the home agent returns [MCOA RETURNHOME WO/NDP]		o On the other hand, the home agent returns [MCOA RETURNHOME WO/NDP]
	value in the Status field of the BID mobility option. The home		value in the Status field of the BID mobility option. The home
	agent learns the mobile node's link-layer address by receiving the		agent learns the mobile node's link-layer address by receiving the
	link-layer address option carried by the Binding Update. It		link-layer address option carried by the Binding Update. It
	stores the link-layer address as a neighbor cache entry for the		stores 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		mobile node so that it can send the packets to the mobile node's
	link-layer address.		link-layer address.
	o Note that the use of proxy Neighbor Discovery is easier way to		o Note that the use of proxy Neighbor Discovery is an easier way to
	intercept the mobile nodes' packets instead of IP routing in some		intercept the mobile nodes' packets instead of IP routing in some
	deployment scenarios. Therefore, even if a home agent is the only		deployment scenarios. Therefore, even if a home agent is the only
	router, it is an implementation and operational choice whether the		router, it is an implementation and operational choice whether the
	home agent returns [Binding Update Accepted] or [MCOA RETURNHOME		home agent returns [Binding Update Accepted] or [MCOA RETURNHOME
	WO/NDP].		WO/NDP].
	o If BID option is not included in the Binding Acknowledgement, the		o If BID option is not included in the Binding Acknowledgement, the
	home agent might not recognize the simultaneous home and foreign		home agent might not recognize the simultaneous home and foreign
	attachment. The home agent might have processed the de-		attachment. The home agent might have processed the de-
	registration Binding Update as a regular de-registration as		registration Binding Update as a regular de-registration as
	skipping to change at page 22, line 30		skipping to change at page 25, line 4
	of the mobile node). A mobile node learns the default router's		of the mobile node). A mobile node learns the default router's
	link-layer address from a Source Link-Layer Address option in		link-layer address from a Source Link-Layer Address option in
	Router Advertisements. The mobile node sends packets directly to		Router Advertisements. The mobile node sends packets directly to
	the default router's link-layer address. This is done by		the default router's link-layer address. This is done by
	constructing the packet including link-layer header with the		constructing the packet including link-layer header with the
	learned link-layer address of the default router. The home agent		learned link-layer address of the default router. The home agent
	also forwards the packet to the mobile node on the home link by		also forwards the packet to the mobile node on the home link by
	using the mobile node's link-layer address. The link-layer		using the mobile node's link-layer address. The link-layer
	address SHOULD be cached when the home agent received the		address SHOULD be cached when the home agent received the
	deregistration Binding Update message. Note that the default		deregistration Binding Update message. Note that the default
	router MUST NOT cache the mobile node's link-layer address as a		router MUST NOT cache the mobile node's link-layer address in the
	neighbor cache when it forwards the packet from the mobile node to		neighbor cache when it forwards the packet from the mobile node to
	the home agent.		the home agent.
	5.6.6. Leaving from the Home Link		5.6.6. Leaving from the Home Link
	o When the mobile node detaches from the home link, it SHOULD		o When the mobile node detaches from the home link, it SHOULD
	immediately send a binding update for one of active care-of		immediately send a binding update for one of active care-of
	address with H flag unset. When the 'H' flag of BID option is		address with H flag unset. When the 'H' flag of BID option is
	unset in any Binding Update, the home agent stop forwarding the		unset in any Binding Update, the home agent stop forwarding the
	mobile node's packet to the home link.		mobile node's packets to the home link.
	5.6.6.1. Changing Behavior during the attachment to the home link		5.6.6.1. Changing Behavior during the attachment to the home link
	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.5.1. Once the home agent receives		update as described in Section 5.5.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(s) and state for the mobile node.
	If a mobile node decides to stop using the interface attached to the		If a mobile node decides to stop using the interface attached to the
	home link, it simply sends a binding update from the one of active		home link, it simply sends a binding update from one of the active
	care-of address. In the Binding Update, the mobile node should		care-of addresses. In the Binding Update, the mobile node should
	include the BID option for the care-of address and unset the H flag		include the BID option for the care-of address and unset the H flag
	of BID option. The home agent clears the states of the mobile node		of the BID option. The home agent clears the state of the mobile
	for the interface attached to the home link and stop forwarding the		node for the interface attached to the home link and stops forwarding
	packets to the mobile node on the home link.		the 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.2.		Binding Acknowledgement is described in Section 6.2.
	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. According to [RFC-3775],		carry a Binding Identifier mobility option. According to [RFC-3775],
	the receiver of the Binding Update ignores unknown mobility options		the receiver of the Binding Update ignores unknown mobility options
	and process the Binding Update without the unknown mobility option.		and processes the Binding Update without the unknown mobility option.
	Therefore, if no such mobility option is included in the Binding		Therefore, if no such mobility option is included in the Binding
	Acknowledgement in response to a Binding Update for multiple care-of		Acknowledgement in response to a Binding Update for multiple care-of
	address registration, this indicates that the originating node of the		address registration, this indicates that the originating node of the
	Binding Acknowledgement does not support processing the Binding		Binding Acknowledgement does not support processing the Binding
	Identifier mobility option regardless of status value. In such case,		Identifier mobility option regardless of status value. In such case,
	the receiver of the Binding Update may create a regular binding. The		the receiver of the Binding Update may create a regular binding. The
	mobile node then stop multiple care-of address registration with that		mobile node then no longer attempts multiple care-of address
	node. If it is home registration, the mobile node MAY attempt to		registration with that node. If this occurs with home registration
	discover another home agent supporting BID mobility option for the		the mobile node MAY attempt to discover another home agent supporting
	home registration.		BID mobility option for the home registration.
	If a Binding Identifier mobility option is present in the received		If a Binding Identifier mobility option is present in the received
	Binding Acknowledgement, the mobile node checks the status field in		Binding Acknowledgement, the mobile node checks the status field in
	the option. If the status value in the Binding Identifier mobility		the option. If the status value in the Binding Identifier mobility
	option is zero, the mobile node uses the value in the Status field of		option is zero, the mobile node uses the value in the Status field of
	the Binding Acknowledgement. Otherwise, it uses the value in the		the Binding Acknowledgement. Otherwise, it uses the value in the
	Status field of the Binding Identifier mobility option.		Status field of the Binding Identifier mobility option.
	If the status code is greater than or equal to 128, the mobile node		If the status code is greater than or equal to 128, the mobile node
	starts relevant operations according to the error code. Otherwise,		starts relevant operations according to the error code. Otherwise,
	the mobile node assumes that the originator (home agent or		the mobile node assumes that the originator (home agent or
	correspondent node) successfully registered the binding information		correspondent node) successfully registered the binding information
	and BID for the mobile node.		and BID for the mobile node.
	o If the Status value is [MCOA PROHIBITED], the mobile node MUST		o If the Status value is [MCOA PROHIBITED], the mobile node MUST
	stop registering multiple bindings to the node that sent the		stop registering multiple bindings with the node that sent the
	Binding Acknowledgement.		Binding Acknowledgement.
	o If the Status value is [MCOA BULK REGISTRATION NOT SUPPORT], the		o If the Status value is [MCOA BULK REGISTRATION NOT SUPPORT], the
	mobile node SHOULD stop using bulk registrations with the node		mobile node needs to stop using bulk registrations with the node
	that sent the Binding Acknowledgement.		that sent the Binding Acknowledgement. It should assume that none
			of the attempted registrations were successful.
	o If [MCOA MALFORMED] is specified, it indicates that the binding		o If [MCOA MALFORMED] is specified, it indicates that the binding
	identifier mobility option is formatted wrongly.		identifier mobility option is formatted wrongly presumably due to
			a programming error or major packet corruption. .
	o If [MCOA BID CONFLICT] is specified, the binding entry specified		o If [MCOA BID CONFLICT] is specified, the binding entry specified
	by the Binding Identifier mobility option is already registered as		by the Binding Identifier mobility option is already registered as
	a regular binding. In such case, the mobile node SHOULD stop		a regular binding. In such case, the mobile node needs to stop
	sending Binding Updates with BID, or SHOULD use the 'O' flag to		sending Binding Updates with BID, or SHOULD use the 'O' flag to
	reset all the registered bindings.		reset all the registered bindings as described in Section 5.9.
	5.8. Receiving Binding Refresh Request		5.8. 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 [RFC-3775]). The operation of sending		Mobile IPv6 (section 11.7.4 of [RFC-3775]). The operation of sending
	a Binding Refresh Request is described in section Section 6.3.		a Binding Refresh Request is described in Section 6.3.
	If a mobile node receives a Binding Refresh Request with a Binding		If a mobile node receives a Binding Refresh Request with a Binding
	Identifier mobility option, it indicates that the node sending the		Identifier mobility option, it indicates that the node sending the
	Binding Refresh Request message is requesting the mobile node to send		Binding Refresh Request message is requesting the mobile node to send
	a new Binding Update for the BID. The mobile node SHOULD then send a		a new Binding Update for the BID. The mobile node SHOULD then send a
	Binding Update at least for the respective binding. The mobile node		Binding Update at least for the respective binding. The mobile node
	MUST include a Binding Identifier mobility option in the Binding		MUST include a Binding Identifier mobility option in the Binding
	Update.		Update.
	5.9. Bootstrapping		5.9. Bootstrapping
	When a mobile node bootstraps and registers multiple bindings for the		When a mobile node bootstraps and registers multiple bindings for the
	first time, it MUST set the 'O' flag in the Binding Identifier		first time, it MUST set the 'O' flag in the Binding Update message.
	mobility option. If old bindings still exists at the home agent, the		If old bindings still exists at the home agent, the mobile node has
	mobile node has no knowledge of which bindings still exist at the		no knowledge of which bindings still exist at the home agent. This
	home agent. This scenario happens when a mobile node reboots and		scenario happens when a mobile node reboots and loses state regarding
	looses state regarding the registrations. If the 'O' flag is set,		the registrations. If the 'O' flag is set, all the bindings are
	all the bindings are replaced by the new binding(s). If the mobile		replaced by the new binding(s). If the mobile node receives the
	node receives the Binding Acknowledgement with the status code set to		Binding Acknowledgement with the status code set to 135 [Sequence
	135 [Sequence number out of window], it MUST follow the operations		number out of window], it MUST follow the operations described in
	described in [RFC-3775].		[RFC-3775].
	The 'O' flag can also be used in individual Binding Updates sent to		The 'O' flag can also be used in individual Binding Updates sent to
	the correspondent nodes to override any existing binding cache		the correspondent nodes to override any existing binding cache
	entries at the correspondent node.		entries at the correspondent node.
	6. Home Agent and Correspondent Node Operation		6. Home Agent and Correspondent Node Operation
	6.1. Searching Binding Cache with Binding Identifier		6.1. Searching Binding Cache with Binding Identifier
	If either a correspondent node or a home agent has multiple bindings		If either a correspondent node or a home agent has multiple bindings
	for a mobile node in their binding cache database, it can use any of		for a mobile node in their binding cache database, it can use any of
	the bindings to communicate with the mobile node. This section		the bindings to communicate with the mobile node. This section
	explains how to retrieve the desired binding for the binding		explains how to retrieve the desired binding for the binding
	management. This document does not provide any mechanism to select		management. This document does not provide any mechanism to select
	the suitable binding for forwarding data packets.		the suitable binding for forwarding data packets.
	A node which is either a correspondent node or a home agent SHOULD		A node which is either a correspondent node or a home agent SHOULD
	use both the home address and the BID as the search key of the		use both the home address and the BID as the search key of the
	binding cache if it knows the corresponding BID (ex. when processing		binding cache if it knows the corresponding BID (example: when
	signaling messages). In the example below, if a node searches the		processing signaling messages). In the example below, if a node
	binding with the home address and BID2, it gets binding2 for this		searches the binding with the home address and BID2, it gets binding2
	mobile node.		for this mobile node.
	binding1 [2001:db8::EUI, care-of address1, BID1]		binding1 [2001:db8::EUI, care-of address1, BID1]
	binding2 [2001:db8::EUI, care-of address2, BID2]		binding2 [2001:db8::EUI, care-of address2, BID2]
	binding3 [2001:db8::EUI, care-of address3, BID3]		binding3 [2001:db8::EUI, care-of address3, BID3]
	Figure 7: Searching the Binding Cache		Figure 8: Searching the Binding Cache
	The node learns the BID when it receives a Binding Identifier		The node learns the BID when it receives a Binding Identifier
	mobility option. At that time, the node MUST look up its binding		mobility option. At that time, the node MUST look up its binding
	cache database with the home address and the BID retrieved from the		cache database with the home address and the BID retrieved from the
	Binding Update. If the node does not know the BID, it searches for a		Binding Update. If the node does not know the BID, it searches for a
	binding with only the home address. In such a case, the first		binding with only the home address. In such a case, the first
	matched binding is found. If the node does not desire to use		matched binding is found. If the node does not desire to use
	multiple bindings for a mobile node, it can simply ignore the BID.		multiple bindings for a mobile node, it can simply ignore the BID.
	6.2. Processing Binding Update		6.2. Processing Binding Update
	If a Binding Update does not contain a Binding Identifier mobility		If a Binding Update does not contain a Binding Identifier mobility
	option, its processing is same as in [RFC-3775]. If the receiver		option, its processing is the same as in [RFC-3775]. If the receiver
	already has multiple bindings for the home address, it MUST replace		already has multiple bindings for the home address, it MUST replace
	all the existing bindings by the received binding. As a result, the		all the existing bindings by the received binding. As a result, the
	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 Care-of Address field. 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 Length value is either 12 or 20, the care-of address MUST		o When the Length value is either 8 or 20, the care-of address MUST
	be present in the Binding Identifier mobility option. If the		be present in the Binding Identifier mobility option. If the
	valid care-of address is not present, the receiver MUST reject the		unicast routable address [RFC-3775] is not present in the care-of
	Binding Identifier mobility option and returns the status value		address field, the receiver MUST reject the Binding Identifier
	set to [MCOA MALFORMED].		mobility option and returns the status value set to [MCOA
			MALFORMED].
			o If the Binding Update is protected with IPsec ESP, the care-of
			address MUST be appeared in the Binding Identifier mobility
			option. If no address is appeared in the care-of address field in
			that mobility option, it MUST reject the Binding Identifier
			mobility option and returns the status value set to [MCOA
			MALFORMED].
			o If the care-of address is appeared in both the alternate care-of
			address mobility option and the Binding Identifier mobility option
			at the same time, it MUST ignore the alternate care-of address
			mobility option and can continue processing the Binding Update
			with the care-of address specified 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
	skipping to change at page 26, line 43		skipping to change at page 30, line 9
	Section 5.6.		Section 5.6.
	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 Length value of the Binding Identifier mobility option		* If the Length value of the Binding Identifier mobility option
	is 20, the care-of address is copied the IPv6 address from the		is 20, the care-of address is copied the IPv6 address from the
	care-of address field in the Binding Identifier mobility		care-of address field in the Binding Identifier mobility
	option. When the Length value is 12, the address MUST be the		option. When the Length value is 8, the address MUST be the
	IPv4 valid address. Detail information can be found in		IPv4 valid address. Detail information can be found in
	Section 8.		Section 8.
	* If the Length value of the Binding Identifier mobility option		* If the Length value of the Binding Identifier mobility option
	is 4, 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 Length value of the Binding Identifier mobility option		* If the Length value of the Binding Identifier mobility option
	is 4 and an alternate care-of address is present, the care-of		is 4 and an alternate care-of address is present, the care-of
	address is copied from the Alternate Care-of address mobility		address is copied from the Alternate Care-of address mobility
	option.		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 'O' flag is not set in all the Binding Identifier options,		* If the 'O' flag is set in the Binding Update, the home agent
	the home agent MUST return the status value [MCOA MALFORMED] by		removes all the existing bindings and registers the received
	Binding Acknowledgement.		bindings.
	* If the 'O' flag is set in the Binding Identifier mobility
	option, the home agent removes all the existing bindings and
	registers the received bindings.
	* If the receiver has a regular binding which does not have BID		* If the 'O' flag is unset in the Binding Update and the receiver
	for the mobile node, it must not process the binding update.		has a regular binding which does not have BID for the mobile
	The receiver should sent a binding acknowledgement with status		node, it must not process the Binding Update. The receiver
	set to [MCOA BID CONFLICT].		should sent a binding Acknowledgement with status set to [MCOA
			BID CONFLICT].
	* If the receiver already has a binding with the same BID but		* If the receiver already has a binding with the same BID but
	different care-of address, it MUST update the binding and		different care-of address, it MUST update the binding and
	respond with a Binding Acknowledgement with status set to 0		respond with a Binding Acknowledgement with status set to 0
	[Binding Update accepted].		[Binding Update accepted].
	* If the receiver does not have a binding entry for the BID, it		* If the receiver does not have a binding entry for the BID, it
	registers a new binding for the BID and responds with a Binding		registers a new binding for the BID and responds with a Binding
	Acknowledgement with status set to 0 [Binding Update accepted].		Acknowledgement with status set to 0 [Binding Update accepted].
	If all the above operations are successfully completed, a Binding		If all the above operations are successfully completed, a Binding
	Acknowledgement containing the Binding Identifier mobility options		Acknowledgement containing the Binding Identifier mobility options
	MUST be sent to the mobile node. Whenever a Binding Acknowledgement		MUST be sent to the mobile node. Whenever a Binding Acknowledgement
	is sent, all the Binding Identifier mobility options stored in the		is sent, all the Binding Identifier mobility options stored in the
	Binding Update MUST be copied to the Binding Acknowledgement except		Binding Update MUST be copied to the Binding Acknowledgement except
	the status field. The Care-of address field in each Binding		the status field. The Care-of address field in each Binding
	Identifier mobility option, however, can be omitted, because the		Identifier mobility option, however, MAY be omitted, because the
	mobile node can match a corresponding binding update list entry using		mobile node can match a corresponding binding update list entry using
	the BID.		the BID.
	When a correspondent node sends a Binding Acknowledgement, the status		When a correspondent node sends a Binding Acknowledgement, the status
	value MUST be always stored in the Status field of the Binding		value MUST be always stored in the Status field of the Binding
	Acknowledgement and the Status field of Binding Identifier mobility		Acknowledgement and the Status field of Binding Identifier mobility
	option MUST be always set to zero.		option MUST be always set to zero.
	When the home agent sends a Binding Acknowledgement, the status value		When the home agent sends a Binding Acknowledgement, the status value
	can be stored in the Status field of either a Binding Acknowledgement		can be stored in the Status field of either a Binding Acknowledgement
	or a Binding Identifier mobility option. If the status value is		or a Binding Identifier mobility option. If the status value is
	specific to one of bindings in the bulk registration, the status		specific to one of bindings in the bulk registration, the status
	value MUST be stored in the Status field in the corresponding Binding		value MUST be stored in the Status field in the corresponding Binding
	Identifier mobility option. In this case, [MCOA NOTCOMPLETE] MUST be		Identifier mobility option. In this case, [MCOA NOTCOMPLETE] MUST be
	set to the Status field of the Binding Acknowledgement so that the		set in the Status field of the Binding Acknowledgement so that the
	receiver can examine the Status field of each Binding Identifier		receiver will examine the Status field of each Binding Identifier
	mobility option for further operations. Otherwise, the status field		mobility option for further operations. Otherwise, the status field
	of the Binding Identifier mobility option MUST be set to zero and the		of the Binding Identifier mobility option MUST be set to zero and the
	home agent status field of the Binding Acknowledgement is used.		home agent status field of the Binding Acknowledgement is used.
	6.3. Sending Binding Refresh Request		6.3. Sending Binding Refresh Request
	When a node (home agent or correspondent node) sends a Binding		When a node (home agent or correspondent node) sends a Binding
	Refresh Request for a particular binding created with the BID, the		Refresh Request for a particular binding created with the BID, the
	node SHOULD include the Binding Identifier mobility option in the		node SHOULD include the Binding Identifier mobility option in the
	Binding Refresh Request. The node MAY include multiple Binding		Binding Refresh Request. The node MAY include multiple Binding
	skipping to change at page 30, line 23		skipping to change at page 33, line 23
	registration works with IPv4 care-of and home addresses.		registration works with IPv4 care-of and home addresses.
	8.1. IPv4 Care-of Address Registration		8.1. IPv4 Care-of Address Registration
	The mobile node can use the extensions described in the document to		The mobile node can use the extensions described in the document to
	register multiple care-of addresses, even if some of the care-of		register multiple care-of addresses, even if some of the care-of
	addresses are IPv4 address.		addresses are IPv4 address.
	Bulk registration MUST NOT be used for the initial binding from an		Bulk registration MUST NOT be used for the initial binding from an
	IPv4 care-of address. This is because, the Binding Update and		IPv4 care-of address. This is because, the Binding Update and
	binding acknowledgement exchange is used to detect NAT on the path		Binding Acknowledgement exchange is used to detect NAT on the path
	between the mobile node and the home agent. So the mobile node needs		between the mobile node and the home agent. So the mobile node needs
	to check for a NAT between each IPv4 care-of address and the home		to check for a NAT between each IPv4 care-of address and the home
	agent.		agent.
	The Binding Update MUST be sent to the IPv4 home agent address by		The Binding Update MUST be sent to the IPv4 home agent address by
	using UDP and IPv4 headers as shown in Figure 8. It is similar to		using UDP and IPv4 headers as shown in Figure 9. It is similar to
	[ID-DSMIPv6] except that the IPv4 care-of address option MUST NOT be		[ID-DSMIPv6] except that the IPv4 care-of address option MUST NOT be
	used when the BID mobility option is used.		used when the BID mobility option is used.
	IPv4 header (src="" dst=HA_V4ADDR)		IPv4 header (src="" dst=HA_V4ADDR)
	UDP Header		UDP Header
	IPv6 header (src="" dst=HAADDR)		IPv6 header (src="" dst=HAADDR)
	ESP Header		ESP Header
	Mobility header		Mobility header
	-Binding Update		-Binding Update
	Mobility Options		Mobility Options
	- Binding Identifier (IPv4 CoA)		- Binding Identifier (IPv4 CoA)
			*V4ADDR, HA_V4ADDR, V6HOA, HAADDR are defined in [ID-DSMIPv6]
	Figure 8: Initial Binding Update for IPv4 Care-of Address		Figure 9: Initial Binding Update for IPv4 Care-of Address
	If a NAT is not detected, the mobile node can update the IPv4 care-of		If a NAT is not detected, the mobile node can update the IPv4 care-of
	address by using bulk registration. The mobile node can register the		address by using bulk registration. The mobile node can register the
	IPv4 care-of address along with other IPv4 and IPv6 care-of		IPv4 care-of address along with other IPv4 and IPv6 care-of
	addresses. Figure 9 shows the Binding Update format when the mobile		addresses. Figure 10 shows the Binding Update format when the mobile
	node sends a Binding Update from one of its IPv6 care-of addresses.		node sends a Binding Update from one of its IPv6 care-of addresses.
	If the mobile node sends a Binding Update from IPv4 care-of address,		If the mobile node sends a Binding Update from IPv4 care-of address,
	it MUST follow the format described in Figure 8. Note that the IPv4		it MUST follow the format described in Figure 9. Note that the IPv4
	Care-of Address must be registered by non bulk Binding registration,		Care-of Address must be registered by non bulk Binding registration,
	whenever it is changed.		whenever it is changed.
	IPv6 header (src="" dst=HAADDR)		IPv6 header (src="" Address, dst=Home Agent Address)
	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 (IPv6/v4 CoA)		- Binding Identifier (IPv6/v4 CoA)
	- Binding Identifier (IPv6/v4 CoA)		- Binding Identifier (IPv6/v4 CoA)
	- ...		- ...
	Figure 9: Binding Bulk Registration for IPv4 care-of address		Figure 10: Binding Bulk Registration for IPv4 care-of address
	If the home agent rejects the IPv4 care-of address, it MUST store the		If the home agent rejects the IPv4 care-of address, it MUST store the
	error code value in the Status field of the BID mobility option.		error code value in the Status field of the BID mobility option.
	8.2. IPv4 HoA Management		8.2. IPv4 Home Address Management
	When the mobile node wants to configure an IPv4 home address in		When the mobile node wants to configure an IPv4 home address in
	addition to the IPv6 home address, it can request for one using the		addition to the IPv6 home address, it can request for one using the
	IPv4 Home Address option in the Binding Update. If the home agent		IPv4 Home Address option in the Binding Update. If the home agent
	accepts the Binding Update, the mobile node can now register multiple		accepts the Binding Update, the mobile node can now register multiple
	care-of addresses for the IPv4 home address in addition to the IPv6		care-of addresses for the IPv4 home address in addition to the IPv6
	home address. The same set of care-of addresses will be registered		home address. The same set of care-of addresses will be registered
	for both IPv6 and IPv4 home addresses. The mobile node cannot bind		for both IPv6 and IPv4 home addresses. The mobile node cannot bind a
	different set of care-of addresses to each home address.		different set of care-of addresses to each home address.
	According to [ID-DSMIPv6], the home agent includes the IPv4 address		According to [ID-DSMIPv6], the home agent includes the IPv4 address
	acknowledgement option in the Binding Acknowledgement only if the		acknowledgement option in the Binding Acknowledgement only if the
	mobile node had requested for an IPv4 home address in the		mobile node had requested for an IPv4 home address in the
	corresponding Binding Update. The IPv4 address acknowledgement		corresponding Binding Update. The IPv4 address acknowledgement
	option MUST be present before any BID option. The status field of		option MUST be present before any BID option. The status field of
	the IPv4 address acknowledgement option contains only the error code		the IPv4 address acknowledgement option contains only the error code
	corresponding to the IPv4 home address management. The error values		corresponding to the IPv4 home address management. The error values
	related to the IPv4 care-of address registration MUST be stored in		related to the IPv4 care-of address registration MUST be stored in
	the BID mobility option.		the BID mobility option.
	9. IPsec and IKEv2 interaction		9. IPsec and IKEv2 interaction
	Mobile IPv6 [RFC-3775] and the NEMO protocol [RFC-3963] require the		Mobile IPv6 [RFC-3775] and the NEMO protocol [RFC-3963] require the
	use of IPsec to protect signaling messages like Binding Updates,		use of IPsec to protect signaling messages including Binding Updates,
	Binding Acknowledgements and return routability messages. IPsec may		Binding Acknowledgements and return routability messages. IPsec may
	also be used protect all tunneled data traffic. The Mobile IPv6-		also be used protect all tunneled data traffic. The Mobile IPv6-
	IKEv2 specification [RFC-4877] specifies how IKEv2 can be used to		IKEv2 specification [RFC-4877] specifies how IKEv2 can be used to
	setup the required IPsec security associations. The following		setup the required IPsec security associations. The following
	assumptions were made in [RFC-3775], [RFC-3963] and [RFC-4877] with		assumptions were made in [RFC-3775], [RFC-3963] and [RFC-4877] with
	respect to the use of IKEv2 and IPsec.		respect to the use of IKEv2 and IPsec.
	o There is only one primary care-of address per mobile node.		o There is only one primary care-of address per mobile node.
	o The primary care-of address is stored in the IPsec database for		o The primary care-of address is stored in the IPsec database for
	tunnel encapsulation and decapsulation.		tunnel encapsulation and decapsulation.
	o When the home agent receives a packet from the mobile node, the		o When the home agent receives a packet from the mobile node, the
	source address is verified against the care-of address in the		source address is verified against the care-of address in the
	corresponding binding cache entry. If the packet is a reverse		corresponding binding cache entry. If the packet is a reverse
	tunneled packet from the mobile node, the care-of address check is		tunneled packet from the mobile node, the care-of address check is
	done against the source address on the outer IPv6 header. The		done against the source address on the outer IPv6 header. The
	reverse tunnel packet could either be a tunneled HoTi message or		reverse tunnel packet could either be a tunneled Home Test Init
	tunneled data traffic to the correspondent node.		message or tunneled data traffic to the correspondent node.
	o The mobile node runs IKEv2 (or IKEv1) with the home agent using		o The mobile node runs IKEv2 (or IKEv1) with the home agent using
	the care-of address. The IKE SA is based on the care-of address		the care-of address. The IKE SA is based on the care-of address
	of the mobile node.		of the mobile node.
	The above assumptions may not be valid when multiple care-of		The above assumptions may not be valid when multiple care-of
	addresses are used by the mobile node. In the following sections,		addresses are used by the mobile node. In the following sections,
	the main issues with the use of multiple care-of address with IPsec		the main issues with the use of multiple care-of address with IPsec
	are addressed.		are addressed.
	skipping to change at page 33, line 23		skipping to change at page 36, line 23
	The home agent processes Mobile Prefix Discovery messages with the		The home agent processes Mobile Prefix Discovery messages with the
	same rules of data packets described in Section 6.4.		same rules of data packets described in Section 6.4.
	9.3. Tunnel Mode IPsec protected messages		9.3. Tunnel Mode IPsec protected messages
	The use of IPsec in tunnel mode with multiple care-of address		The use of IPsec in tunnel mode with multiple care-of address
	introduces a few issues that require changes to how the mobile node		introduces a few issues that require changes to how the mobile node
	and the home agent send and receive tunneled traffic. The route		and the home agent send and receive tunneled traffic. The route
	optimization mechanism described in [RFC-3775] mandates the use of		optimization mechanism described in [RFC-3775] mandates the use of
	IPsec protection in tunnel mode for the HoTi and HoT messages. The		IPsec protection in tunnel mode for the Home Test Init and Home Test
	mobile node and the home agent may also choose to protect all reverse		messages. The mobile node and the home agent may also choose to
	tunneled payload traffic with IPsec in tunnel mode. The following		protect all reverse tunneled payload traffic with IPsec in tunnel
	sections address multiple care-of address support for these two types		mode. The following sections address multiple care-of address
	of messages.		support for these two types of messages.
	9.3.1. Tunneled HoTi and HoT messages		9.3.1. Tunneled Home Test Init and Home Test messages
	The mobile node MAY use the same care-of address for all HoTi		The mobile node MAY use the same care-of address for all Home Test
	messages sent reverse tunneled through the home agent. The mobile		Init messages sent reverse tunneled through the home agent. The
	node may use the same care-of address irrespective of which		mobile node may use the same care-of address irrespective of which
	correspondent node the HoTi message is being sent. RFC 3775 requires		correspondent node the Home Test Init message is being sent. RFC
	the home agent to verify that the mobile node is using the care-of		3775 requires the home agent to verify that the mobile node is using
	address that is in the binding cache entry, when it receives a		the care-of address that is in the binding cache entry, when it
	reverse tunneled HoTi message. If a different address is used as the		receives a reverse tunneled Home Test Init message. If a different
	source address, the message is silently dropped by the home agent.		address is used as the source address, the message is silently
	This document requires the home agent implementation to decapsulate		dropped by the home agent. This document requires the home agent
	and forward the HoTi message as long as the source address is one of		implementation to decapsulate and forward the Home Test Init message
	the care-of addresses in the binding cache entry for the mobile node.		as long as the source address is one of the care-of addresses in the
			binding cache entry for the mobile node.
	When the home agent tunnels a HoT message to the mobile node, the		When the home agent tunnels a Home Test message to the mobile node,
	care-of address used in the outer IPv6 header is not relevant to the		the care-of address used in the outer IPv6 header is not relevant to
	HoT message. So regular IPsec tunnel encapsulation with the care-of		the Home Test message. So regular IPsec tunnel encapsulation with
	address known to the IPsec implementation on the home agent is		the care-of address known to the IPsec implementation on the home
	sufficient.		agent is sufficient.
	9.3.2. Tunneled Payload Traffic		9.3.2. Tunneled Payload Traffic
	When the mobile sends and receives multiple traffic flows protected		When the mobile sends and receives multiple traffic flows protected
	by IPsec to different care-of addresses, the use of the correct		by IPsec to different care-of addresses, the use of the correct
	care-of address for each flow becomes important. Support for this		care-of address for each flow becomes important. Support for this
	requires the following two considerations on the home agent.		requires the following two considerations on the home agent.
	o When the home agent receives a reverse tunneled payload message		o When the home agent receives a reverse tunneled payload message
	protected by IPsec in tunnel mode, it must check that the care-of		protected by IPsec in tunnel mode, it still needs to be aware of
	address is one of the care-of addresses in the binding cache		which care-of address is being used. According to RFC 4306, the
	entry. According to RFC 4306, the IPsec implementation on the		IPsec implementation on the home agent does not check the source
	home agent does not check the source address on the outer IPv6		address on the outer IPv6 header. However, the stack on the home
	header. Therefore the care-of address used in the reverse		agent MUST still be informed about the source address in order to
	tunneled traffic can be different from the care-of address used as		choose the most recently used care-of address, as discussed in
	the source address in the IKEv2 exchange. However, the Mobile		Section 3 (in the absence of a user-supplied policy).
	IPv6 stack on the home agent MUST verify that the source address
	is one of the care-of addresses registered by the mobile node
	before decapsulating and forwarding the payload traffic towards
	the correspondent node.
	o For tunneled IPsec traffic from the home agent to the mobile node,		o For tunneled IPsec traffic from the home agent to the mobile node,
	The IPsec implementation on the home agent may not be aware of		The IPsec implementation on the home agent may not be aware of
	which care-of address to use when performing IPsec tunnel		which care-of address to use when performing IPsec tunnel
	encapsulation. The Mobile IP stack on the home agent must specify		encapsulation. The Mobile IP stack on the home agent must specify
	the tunnel end point for the IPsec tunnel. This may require tight		the tunnel end point for the IPsec tunnel. This may require tight
	integration between the IPsec and Mobile IP implementations on the		integration between the IPsec and Mobile IP implementations on the
	home agent.		home agent.
	10. Security Considerations		10. Security Considerations
	skipping to change at page 35, line 25		skipping to change at page 38, line 25
	With simultaneous binding support, it is possible for a malicious		With simultaneous binding support, it is possible for a malicious
	mobile node to successfully bind a number of victims' addresses as		mobile node to successfully bind a number of victims' addresses as
	valid care-of addresses for the mobile node with its home agent.		valid care-of addresses for the mobile node with its home agent.
	Once these addresses have been bound, the malicious mobile node can		Once these addresses have been bound, the malicious mobile node can
	perform a re-direction attack by instructing the home agent (e.g.		perform a re-direction attack by instructing the home agent (e.g.
	setting filtering rules to direct a large file transfer) to tunnel		setting filtering rules to direct a large file transfer) to tunnel
	packets to the victims' addresses. Such risk is highlighted in [ID-		packets to the victims' addresses. Such risk is highlighted in [ID-
	MIP6ANALYSIS]. These attacks are possible because the care-of		MIP6ANALYSIS]. These attacks are possible because the care-of
	addresses sent by the mobile node in the Binding Update messages are		addresses sent by the mobile node in the Binding Update messages are
	not verified by home agent, i.e., the home agent does not check if		not verified by the home agent, i.e., the home agent does not check
	the mobile node is at the care-of address it is claiming to be. The		if the mobile node is at the care-of address it is claiming to be.
	security model for Mobile IPv6 assumes that there is a trust		The security model for Mobile IPv6 assumes that there is a trust
	relationship between the mobile node and its home agent. Any		relationship between the mobile node and its home agent. Any
	malicious attack by the mobile node is traceable by the home agent.		malicious attack by the mobile node is traceable by the home agent.
	This acts as a deterrent for the mobile node to launch such attacks.		This acts as a deterrent for the mobile node to launch such attacks.
	Although such risk exists in Mobile IPv6, the risk level is escalated		Although such a risk exists in Mobile IPv6, the risk level is
	when simultaneous multiple care-of address bindings are performed.		increased when simultaneous multiple care-of address bindings are
	In Mobile IPv6, a mobile node can only have a single care-of address		performed. In Mobile IPv6, a mobile node can only have a single
	binding per home address at a given time. However, for simultaneous		care-of address binding per home address at a given time. However,
	multiple care-of address bindings, a mobile node can have more than		for simultaneous multiple care-of address bindings, a mobile node can
	one care-of address binding per home address at a given time. This		have more than one care-of address binding per home address at a
	implies that a mobile node using simultaneous binding support can		given time. This implies that a mobile node using simultaneous
	effectively bind more than a single victim's address. Another		binding support can effectively bind more than a single victim's
	difference is the degree of risk involved. In the single care-of		address. Another difference is the degree of risk involved. In the
	address binding case, once the re-direction attack is initiated, a		single care-of address binding case, once the re-direction attack is
	malicious mobile node would be unable to use its home address for		initiated, a malicious mobile node would be unable to use its home
	communications (such as to receive control packets pertaining to the		address for communications (such as to receive control packets
	file transfer). However, in the simultaneous binding support case, a		pertaining to the file transfer). However, in the simultaneous
	malicious mobile node could bind a valid care-of address in addition		binding support case, a malicious mobile node could bind a valid
	to multiple victims addresses. This valid care-of address could then		care-of address in addition to multiple victims addresses. This
	be used by the malicious mobile node to set up flow filtering rules		valid care-of address could then be used by the malicious mobile node
	at its home agent, thereby controlling and/or launching new re-		to set up flow filtering rules at its home agent, thereby controlling
	direction attacks.		and/or launching new re-direction attacks.
	Thus, in view of such risks, it is advisable for a home agent to		Thus, in view of such risks, it is advisable for a home agent to
	employ some form of care-of address verification mechanism before		employ some form of care-of address verification mechanism before
	using the care-of addresses as a valid routing path to a mobile node.		using the care-of addresses as a valid routing path to a mobile node.
	These mechanisms are out-of scope for this document. The home agent		These mechanisms are out-of scope for this document. The home agent
	can also choose to reject bulk registration by using [MCOA BULK		can also choose to reject bulk registration by using [MCOA BULK
	REGISTRATION PROHIBITED] in a Binding Acknowledgement.		REGISTRATION PROHIBITED] in a Binding Acknowledgement.
	11. IANA Considerations		11. IANA Considerations
	skipping to change at page 38, line 30		skipping to change at page 41, line 30
	[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-4861] Narten, T., Nordmark, E., W. Simpson, and H. Soliman,		[RFC-4861] Narten, T., Nordmark, E., W. Simpson, and H. Soliman,
	"Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, September		"Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, September
	2007..		2007..
	[RFC-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support		[RFC-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
	in IPv6", RFC 3775, June 2004.		in IPv6", RFC 3775, June 2004.
			[RFC-4877] V. Devarapalli, F. Dupont, "Mobile IPv6 Operation with
			IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007.
	[RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.		[RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
	Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,		Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
	January 2005.		January 2005.
	[RFC-4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with		[RFC-4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
	IKEv2 and the revised IPsec Architecture", RFC 4877, April 2007.		IKEv2 and the revised IPsec Architecture", RFC 4877, April 2007.
			[ID-DSMIPv6] Soliman, H., "Mobile IPv6 support for dual stack Hosts
			and Routers (DSMIPv6)", draft-ietf-mext-nemo-v4traversal-05 (work in
			progress), July 2008.
			[RFC-5268] R. Koodli, "Mobile IPv6 Fast Handovers", RFC 5268, June
			2008.
	13.2. Informative References		13.2. Informative References
	[ID-MOTIVATION] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and		[ID-MOTIVATION] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and
	K. Kuladinithi, "Motivations and Scenarios for Using Multiple		K. Kuladinithi, "Motivations and Scenarios for Using Multiple
	Interfaces and Global Addresses",		Interfaces and Global Addresses",
	draft-ietf-monami6-multihoming-motivation-scenario-03 (work in		draft-ietf-monami6-multihoming-motivation-scenario-03 (work in
	progress), May 2008.		progress), May 2008.
	[RFC-4980] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of		[RFC-4980] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of
	Multihoming in Network Mobility Support", RFC 4980, October 2007.		Multihoming in Network Mobility Support", RFC 4980, October 2007.
	skipping to change at page 39, line 11		skipping to change at page 43, line 5
	[ID-MIP6ANALYSIS] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and		[ID-MIP6ANALYSIS] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and
	K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6",		K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6",
	draft-ietf-monami6-mipv6-analysis-05 (Work in progress), May 2008.		draft-ietf-monami6-mipv6-analysis-05 (Work in progress), May 2008.
	[RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology",		[RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
	RFC 3753, June 2004.		RFC 3753, June 2004.
	[RFC-4885] Ernst, T. and H. Lach, "Network Mobility Support		[RFC-4885] Ernst, T. and H. Lach, "Network Mobility Support
	Terminology", RFC 4885, July 2007.		Terminology", RFC 4885, July 2007.
	[ID-DSMIPv6] Soliman, H., "Mobile IPv6 support for dual stack Hosts
	and Routers (DSMIPv6)", draft-ietf-mext-nemo-v4traversal-05 (work in
	progress), July 2008.
	[RFC-5268] R. Koodli, "Mobile IPv6 Fast Handovers", RFC 5268, June
	2008.
	Authors' Addresses		Authors' Addresses
	Ryuji Wakikawa		Ryuji Wakikawa
	Toyota ITC / Keio University		Toyota ITC / Keio University
	6-6-20 Akasaka, Minato-ku		6-6-20 Akasaka, Minato-ku
	Tokyo 107-0052		Tokyo 107-0052
	Japan		Japan
	Phone: +81-3-5561-8276		Phone: +81-3-5561-8276
	Fax: +81-3-5561-8292		Fax: +81-3-5561-8292
End of changes. 118 change blocks.
	320 lines changed or deleted		412 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/

draft-ietf-monami6-multiplecoa-11.txt
Description: Text document

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf