Subject: [MEXT] WGLC for draft-ietf-monami6-multiplecoa-05.txt

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 3 Feb 2008 11:31:55 +0100

Hi,

With this email we issue the WGLC for draft-ietf-monami6- 
multiplecoa-05.txt
The WGLC will be open till the 11 of february.
We kindly ask the WG to review the document and provide comments.

Please note that a valid comment at this stage is positive feedback  
about the document being ready to be shipped.
So, please if you think the doc is ready, do express this to the ml  
(or to the chairs)

For you convenience, additional information about the document:

	Title           : Multiple Care-of Addresses Registration
	Author(s)       : R. Wakikawa, et al.
	Filename        : draft-ietf-monami6-multiplecoa-05.txt
	Pages           : 44
	Date            : 2008-01-27

http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-05.txt

Thanks, Julien and marcelo
_______________________________________________
MEXT mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/mext

---

From: Romain KUNTZ <[email-masked]>
Date: Wed, 6 Feb 2008 22:48:38 +0100

Hi Ryuji,

I have a couple more comments on some part of the draft:

- Section 4.2.1:
Why is the O flag stored in the Binding ID option, and not the BU?  
This would be more consistent in the case of the Bulk registration, as  
this flag is supposed to be shared among all the Binding ID options.

- Section 5.6.3
    "If the home agent receives the [MCOA RETURNHOME WO/NDP],"

Replace "home agent" with "mobile node"

- Section 5.10
   "For Correspondent nodes, the mobile node cannot use the O flag
    because of no bulk registration support.  Thus, if necessary, it  
MUST
    sends a regular binding first to overwrite the remaining bindings at
    the correspondent node.  Then, it can re-register the set of  
bindings
    by using Multiple Care-of Address Registration.

What is the problem to use the O flag with a single Binding ID option?  
This is not considered as bulk registration, so why the MN can't use O  
flag with CN?

- Section 6.3
"*  If the receiver has a regular binding which does not have BID
      for the mobile node, it de-registers the regular binding and
      registers a new binding including BID according to the Binding
      Update.  In this case, the receiver MUST return [MCOA BID
      CONFLICT]."

This IMHO contradicts what section 5.7 says:

"o  If [MCOA BID CONFLICT] is specified, the binding entry specified
       by the Binding Identifier mobility option is already registered  
as
       a regular binding.  In such case, the mobile node SHOULD stop
       sending Binding Updates with BID, or SHOULD use O flag for the
       peer to reset all the registered bindings."

because on the HA side, the new binding (with BID) is registered, but  
on the MN side it is advised to stop sending BU with BID option.

Note also that MCOA_BID_CONFLICT is considered as a status for an  
unsuccessful refistration (>128), so it also conflicts with the fact  
that the HA accepts the new binding.

- Section 6.3

   "If all the above operations are successfully finished, the Binding
    Acknowledgment containing the Binding Identifier mobility options
    MUST be replied to the mobile node if A flag is set in the Binding
    Acknowledgment."

The last "Binding Acknowledgment" should be instead "Binding Update"

   "Whenever a Binding Acknowledgment is returned, all
    the Binding Identifier mobility options stored in the Binding Update
    MUST be copied to the Binding Acknowledgment."

All the field must be copied EXCEPT the status field that must be set  
to the previously decided value.

Cheers,
-- 
Romain KUNTZ
[email-masked]
Louis Pasteur University - Networks and Protocols Team

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Thu, 7 Feb 2008 19:09:17 +0900

Hi Romain,

Thanks for comments.
Please my reply inline.

On 2008/02/07, at 6:48, Romain KUNTZ wrote:

> This would be more consistent in the case of the Bulk registration,  
> as this flag is supposed to be shared among all the Binding ID  
> options.

Try not to consume the reserved field in BU.

> Replace "home agent" with "mobile node"

right.

> What is the problem to use the O flag with a single Binding ID  
> option? This is not considered as bulk registration, so why the MN  
> can't use O flag with CN?

Correct. MN can send single binding with O flag set so that it can  
refresh the bindings on CN.

> because on the HA side, the new binding (with BID) is registered,  
> but on the MN side it is advised to stop sending BU with BID option.
>

right.. The home agent operation is wrong.
The HA should not accept the bindings and reply the error code [BID- 
CONFLICT].

> All the field must be copied EXCEPT the status field that must be  
> set to the previously decided value.

right. we will correct this.

Thanks for your comments again,
ryuji

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 07 Feb 2008 10:31:38 -0800

Hi George,

Thanks for the extensive review. It was very useful. I am adopting
most of the editorial changes you suggested. Only responding to
those that might need more discussion below.

George Tsirtsis wrote:

>       A mobile node MAY change the value of a BID at any time
>       according to its administrative policy, for instance to protect
>       its privacy.
> 
> GT> I do not understand this. If BID changes then it has to be updated
> at the HA side, so it has some impact in HA scalability. 

Yes, it would need to be updated on the home agent.

> It is also
> not clear what the privacy concern is here. The above is removed.

Perhaps a constant BID is one of those things you could use
to track a mobile node's communication. But I also think it
should be removed. Its not really a big concern unless you
are changing the home address also at the same time.

>    A new identification number (BID) is introduced to distinguish
>    multiple bindings pertaining to the same Home Address.  Once a mobile
>    node gets several IPv6 global addresses on one or more of its
>    interfaces, it can register these addresses with its home agent.  If
>    the mobile node wants to register multiple bindings, it MUST generate
>    a BID for each care-of address and record the BID into the binding
>    update list.  A mobile node can manipulate each binding independently
>    by using a BID.  The mobile node then registers its care-of addresses
>    by sending a Binding Update with a Binding Identifier mobility
>    option.  The BID MUST be included in the Binding Identifier mobility
>    option.  After receiving such Binding Update and Binding Identifier
>    mobility option, the home agent MUST copy the BID from the Binding
>    Identifier mobility option to the corresponding field in the binding
>    cache entry.  Even if there is already an entry for the mobile node's
>    home address, the home agent MUST register a new binding entry for
>    the BID stored in the Binding Identifier mobility option.
> 
> GT> Not clear

Re-wrote the paragraph.

    A new extension called the Binding identification number (BID) is
    introduced to distinguish multiple bindings pertaining to the same
    Home Address.  If a mobile node configures several IPv6 global
    addresses on one or more of its interfaces, it can register these
    addresses with its home agent as care-of addresses.  If the mobile
    node wants to register multiple bindings, it MUST generate a BID for
    each care-of address and store the BID in the binding update list.  A
    mobile node can manipulate each binding independently by using the
    BIDs.  The mobile node then registers its care-of addresses by
    sending a Binding Update with a Binding Identifier mobility option.
    The BID is included in the Binding Identifier mobility option.  After
    receiving the Binding Update with a Binding Identifier mobility
    option, the home agent MUST copy the BID from the Binding Identifier
    mobility option to the corresponding field in the binding cache
    entry.  If there is an existing binding cache entry for the mobile
    node, and the if the BID in the Binding Update does not match the one
    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
    register multiple care-of addresses either independently in
    individual Binding Updates or multiple at once in a single Binding
    Update.

>    The mobile
>    node registers multiple care-of addresses either independently in
>    individual Binding Updates or multiple at once in a single Binding
>    Update.
> 
>    If the mobile host wishes to register its binding with a
>    correspondent node, it must perform return routability operations.
>    The mobile host MUST manage a Care-of Keygen Token per care-of
>    address.  The mobile host exchanges CoTI and CoT for the
>    corresponding care-of addresses if necessary.  When the mobile host
>    registers several care-of addresses to a correspondent node, it uses
>    the same BID as the one generated for the home registration's
>    bindings.
> 
> GT> Why does the same BID have to be used in the HA and the CNs? It
> may make sense to implement it this way but why is this required?

Not sure why. I modified the text to say it is recommended. See
below for the entire paragraph.

>    The binding registration step is the same as for the home
>    registration except for calculating authenticator.
> 
> GT> What is different in the calculation of the authenticator?

I think the intention was to say that this BU is protected by
the Binding Authorization Data option. I think this sentence should
be removed. The protection for a BU sent to a CN is different from
the BU sent to a home agent. That is already known to the mobile node.
The new paragraph reads

    If the mobile host wishes to register its binding with a
    correspondent node, it must perform return routability operations.
    This includes managing a Care-of Keygen token per care-of address and
    exchanging CoTi and CoT message with the correspondent node for each
    care-of address.  It is RECOMMENDED that the mobile node uses the
    same BID that it used with the home agent for a particular care-of
    address.  For protocol simplicity, bulk registration to correspondent
    nodes is not supported in this document.  This is because the Return
    Routability mechanism introduced in [RFC-3775] cannot be easily
    extended to verify multiple care-of addresses stored in a single
    Binding Update.

>    When a home agent and a correspondent node check the binding cache
>    database for the mobile node, they search a corresponding binding
>    entry with the pair of Home Address and BID of the desired binding.
>    If necessary, a mobile node can use policy and filter information to
>    look up the best binding per sessions, flow, packets, but this is out
>    of scope in this document.  If there is no desired binding, it
>    searches the binding cache database with the Home Address as
>    specified in Mobile IPv6.  The first matched binding entry may be
>    found, although this is implementation dependent.
> 
> 
> GT> IMHO this whole paragraph should be removed. It is cinfusing and
> does not say anything useful.

I believe this is the paragraph that provides a description of how
binding cache lookup is done using the BID. So here is a re-write

    Binding cache lookup is done based on the Home Address and BID
    information.  This is different from RFC 3775, where only the home
    address is used for binding cache lookup.  The binding cache lookup
    may also involve policy or flow filters in cases where some policy or
    flow filters are used to direct certain packets or flows to a
    particular care-of address.  The binding cache lookup using policy or
    flow filters is out of scope for this document.  In case the binding
    cache lookup, using the combination of home address and BID, does not
    return a valid binding cache entry, the home agent MAY perform
    another lookup based on only the home address.  This is
    implementation dependent and configurable on the home agent.

>    Care-of address (C) flag
> 
>       When this flag is set, a mobile node can store a Care-of Address
>       corresponding to the BID in the Binding Identifier mobility
>       option.
> 
> GT> The above sentence make no sense to me. Assuming I understand what
> you mean. maybe you can use the following: "When this flag is set, BID
> Mobility Option includes a care-off address field."

See below for the re-written paragraph.

> 
>   This flag MUST be used whenever a mobile node sends
>       multiple care-of addresses in a single Binding Update, i.e. bulk
>       registration.  It MUST be also used for the independent binding
>       registration as a substitute for an alternate care-of address
>       option.  This flag is valid only for binding update sent to the
>       home agent.
> 
> GT> Several things are not clear. The C-flag must be set for
> individual as well as bulk binding registrations correct? 

It is a MUST for bulk registrations. Not for individual registrations.
I think the intention was to say that if the mobile node is going
to use the alt CoA option in a BU with the BID option, it can just
include the CoA in the BID option. Does not have to include the alt
CoA option.

If yes
> rephrase to make this clearer. Why is C-flag a substitute to the
> alt-CoA?? Is there a case where this option is included in a BU and
> C-flag is NOT set?

Needs to be re-written.

    Care-of address (C) flag

       When this flag is set, it indicates that a valid care-of address
       is present in the care-of address field in the BID mobility
       option.  This flag MUST be set whenever the mobile node sends
       multiple care-of addresses in a single Binding Update, i.e., bulk
       registration.  It MAY also used as a substitute for alternate
       care-of address option even for binding updates that are sent only
       for one care-of address.  This flag is valid only for binding
       update sent to the home agent.

> 5.  Mobile Node Operation
> 
> 5.1.  Management of Care-of Addresses and Binding Identifier
> 
>    There are two cases when a mobile node has several Care-of Addresses.
>    Note that a mixture of the two cases are possible.
> 
> 
>    1.  A mobile node uses several physical network interfaces and
>        acquires a care-of address on each of its interfaces.
> 
>    2.  A mobile node uses a single physical network interface, but
>        multiple prefixes are announced on the link the interface is
>        attached to.  Several global addresses are configured on this
>        interface for each of the announced prefixes.
> 
>    The difference between the above two cases is only a number of
>    physical network interfaces and therefore does not matter in this
>    document.
> 
> 
>    The Identification number is used to identify a binding.
>    To implement this, a mobile node MAY assign an identification number
>    for each care-of addresses.  How to assign an identification number
>    is implementation specific, but the following rules MUST be followed.
> 
> GT> IMHO the above 3 sentences are not useful and should be removed.
> If you want to keep them change "Identification" with "BID", otherwise
> they are confusing.

Removed.

> 5.4.  Binding Bulk Registration
> 
>    The bulk registration is an optimization for registering multiple
>    care-of addresses only to a home agent by using a single Binding
>    Update.
> 
> GT> More accurate: "The bulk registration is an optimization for
> binding multiple care-of addresses to a single home address by using a
> single Binding
>    Update."

Re-written as

    The bulk registration is an optimization for binding multiple care-of
    addresses to a home address by using a single Binding Update.  If a
    mobile node, for instance, does not want to send a lot of signaling
    messages through an interface where the bandwidth is scarce, it can
    use this bulk registration mechanism.

>    A mobile node sets the C flag in a Binding Identifier mobility option
>    and includes the particular care-of address in the Binding Identifier
>    mobility option.  The mobile node stores multiple sets of a Binding
>    Identifier mobility option in a Binding Update as shown in Figure 3.
> 
> GT> I am re-writing the above paragraph for clarity:
> "  To use bulk registration the mobile node includes a Binding
> Identifier Mobility option for each BID and Care-of address pair it
> wants to register in the same Binding Update message.
> 
>    In the bulk registration, all the other binding information such as
>    Lifetime, Sequence Number, binding Flags are shared among the bulked
>    Care-of Addresses.
> 
> GT> It is not clear what you mean here. Is this "other binding
> information" in the regular BU fields? or you mean something else?
> Please clarify.

re-wrote it

    To use bulk registration, the mobile node includes a Binding
    Identifier Mobility option for each BID and Care-of address pair it
    wants to register in the same binding update message.  This is shown
    in Figure 3.  The rest of the fiels and options in the binding update
    such as Lifetime, Sequence Number, the flags in the Binding Update
    are common across all care-of addresses.  The alternate care-of
    address option MUST NOT be used.

>     The receiver will remove only the care-of
>    address(es) that matches to the specified BID.  For the bulk de-
>    registration, the care-of addresses field of each mobility option
>    SHOULD be omitted, because the receiver will remove all the care-of
>    addresses matching the specified BID.
> 
> GT> Is the care-of address field required in the individual
> de-registrations? The BIDs should be sufficient to identify the
> bindings that need to be removed. If you agree please clarify.

I don't think the care-of address is needed. The BID should be
sufficient. Ryuji?

> 5.6.  Returning Home
> 
>    The mobile node may return to the home link, by attaching to the home
>    link through one of the interfaces on the mobile node.
> 
>    When the
>    mobile node wants to return home, it should be configured with what
>    interface it needs to use.
> 
> GT> Remove the above sentence. What 'home link' means and how it is
> defined is already described in RFC3775.

Not clear. There are two sentences aboves. One of them says that
the mobile node can return home by attaching to the home link
through *one* of the interfaces. The second one says, the mobile
node should be configure with the information on which interface
it should use to attach to the home link. Aren't both required?

>    These bindings at
>    correspondent node MUST be created before a mobile node returns home.
> 
> GT> Why? CN bindings do not affect and are not affected by the
> bindings at the HA. I would just remove this sentence.

Agreed. Nothing stops the mobile node from doing a care-of
address text or home address test.

> 
> 5.6.2.  Using only Interface attached to the Visited Link
> 
>    The mobile node returns home and shutdown the interface attached to
>    the home link as shown in Figure 10.  The binding of the home
>    attached interface MUST be deleted by sending a de-registration
>    binding update from one of active interface attached to the foreign
>    links.  This scenario is not the most efficient because all the
>    traffic from and to the mobile node is going through the bi-
>    directional tunnel, whereas the mobile node is now accessible at one
>    hop from its home agent.
> 
> 
> GT> This is badly written. This section describes procedures for
> returning home, in which case it makes no sense to de-register a
> binding to the home interface…which can not possibly exist. This
> scenario instead is one where when the MN detects that an interface is
> connected to the home link e.g., receives an RA including its HNP, it
> shuts down that interface. In other words, the MN chooses never to
> connect to its home link.

hmmm.. The above paragraph assumes that there was a care-of
address associated with that interface and there was
corresponding binding for that care-of address (and BID) on
the home agent. That binding would need to be deleted. Here
is the re-written paragraph.

    The mobile node returns home and shuts down the interface attached to
    the home link as shown in Figure 10.  Before shutting down the
    interface, any binding for the care-of address previously associated
    with the interface should be deleted.  To delete the binding cache
    entry, the mobile node MUST send a de-registration binding update
    with the lifetime set to zero and include the corresponding BID
    information.  This scenario is not the most efficient because all the
    traffic from and to the mobile node is going through the bi-
    directional tunnel, whereas the mobile node is now accessible at one
    hop from its home agent.

>    In this specification, the home agent MUST intercept all the packets
>    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
>    address.  The home agent would make this decision based on the type
>    of packets and flows.  How to make this decision is out of scope in
>    this document.  The delicate part would be to create a neighbor cache
>    entry for the mobile node so that the home agent can deliver the
>    packets on-link.
> 
>    The home agent would need to know the Layer-2
>    address of the interface with which the mobile node is attached to
>    the home link.
> 
> GT> Why is the L2 address necessary? This could be based on Interface
> ID or other information. I would remove the last sentence.

For constructing the ether header for example. Since the home agent
is still defending the home address, it cannot send a neighbor
solicitation and get a neighbor advertisement from the mobile node
to create a neighbor cache entry.

>    When the home agent sends the Binding Acknowledgment, it MUST store
>    one of two status values such as [Binding Update Accepted (0)] [MCOA
>    RETURNHOME WO/NDP (TBD)] in the BID mobility option depending on home
>    agent configuration at the home link.  The new values are:
> 
>    o  Binding Update Accepted (0): NDP is permitted for the home address
>       at the home link.  This is regular returning home operation of
>       [RFC3775]
> 
>    o  MCOA RETURNHOME WO/NDP (TBD): NDP is prohibited for the home
>       address at the home link
> 
>    When the home agent is the only router at the home link, it can
>    intercept all the packets by IP routing without proxy NDP.  It stops
>    proxy ND for the requested home address and replies the [Binding
>    Update Accepted] value to the mobile node.  The neighbor cache entry
>    for the mobile node is created by the regular NDP operation (i.e.
>    NS/NA exchange).  On the other hand, if the home agent is not the
>    only router, it MUST continue defending the home address by proxy NDP
>    to capture all the mobile node's traffic.  The home agent, then,
>    returns [MCOA RETURNHOME WO/NDP] value in the Status field of the BID
>    mobility option.  The home agent also learns the mobile node's
>    layer-2 address (i.e.  MAC address) during this binding de-
>    registration.  It keeps the learned layer-2 address as the neighbor
>    cache entry for the mobile node so that it can construct the layer-2
>    header for the packets meant for the mobile node and forwards them
>    directly to the mobile node's interface attached to the home link.
> 
>    According to [RFC3775], the mobile node MUST NOT assign the home
>    address to the interface attached to the home link and MUST NOT
>    attempt NDP operations for the home address before the completion of
>    binding de-registration.  It MUST NOT send and reply to Neighbor
>    Solicitation for the home address.  The home address MUST be
>    tentative address at this moment until it receives Binding
>    Acknowledgment with success status value.
> 
>    When the mobile node receives the binding acknowledgment and BID
>    mobility option, it assigns home address at the interface attached to
>    the home link according to the status field of the BID.  If the value
>    is [Binding Update Accepted], the mobile node can start defending the
>    home address using NDP.  The home agent can create neighbor cache
>    entry for the mobile node by NS and NA exchange as normal IPv6
>    operation.
> 
>    If the home agent receives the [MCOA RETURNHOME WO/NDP], it MUST NOT
>    defends its home address at the home link by NDP.  When the mobile
>    node sends packets from the interface attached to the home link, it
>    MUST learn the layer2 address (i.e.  MAC address) of the next hop
>    (i.e. default router, it can be home agent) during the binding de-
>    registration and construct the packet including layer 2 header with
>    the learned home agent's layer-2 address.
> 
> GT> This whole section is very badly written.

Will try to improve it in the next revision.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 08 Feb 2008 08:35:47 -0800

Hello,

There is a pre-06 version of this draft available at
http://dvijay.com/ietf/internet-drafts/mext/mcoa.txt

The draft has been cleaned up a bit. In case, you haven't reviewed
the document yet, please review the pre-06 version. In case you
have already reviewed version 05, please send your comments based
on version 05.

The diff between 05 and pre-06 can be found at
http://dvijay.com/ietf/internet-drafts/mext/diff-05-06.html

Vijay

---

From: "George Tsirtsis" <[email-masked]>
Date: Mon, 11 Feb 2008 15:07:55 +0000

Hi Vijay/Ryuji  et.al.,

This version (pre-6) is much improved so well done. There are still
several minor technical issues, unlear text, and nits, which I
indicate below, but I want to highlight a few more important technical
issues upfront:

1) Lifetime of BIDs: I think the relation between BIDs and BU Lifetime
field is not clear. I think the assumption has been that the Lifetime
is common across all BIDs. IMO there needs to be more explicit
language in the spec to make this clear..
- a BU with one or more BIDs, O=0, and Lifetime != 0, updates the
lifetime of all the BIDs in the binding cache. i.e., to maintain all
the BIDs you just need to send a Binding refresh including at least
BID.(right?)
- a BU with O=1 replaces all BIDs and associates them with lifetime in the BU
- a BU with one or more BIDs, O=0, and Lifetime = 0, removes only the
listed BIDs and does not affect the lifetime of other BIDs in the
binding cache
- a BU with lifetime=0 and H=1 indicates the MN is at home link, but
the lifetime of other BIDs  is not affected. How is the  home link
state maintained though? This looks like hard state at the moment and
I do not like it. Any ideas?

2) Changing BIDs. the draft indicates that BIDs can be changed for
privacy reasons. While I still do not understand what these reasons
are, I also do not see anywhere how BIDs can be changed. Is is done by
sending a BU with a new BID mapped to a CoA that is already in the
binding cache (but mapped to another BID)? I indicate that this could
be added somewhere inline,  but some additional care also needs to be
taken e.g., can you reuse the BID you are replacing in the same BU?

3) Section 5.6.2 (using only IF attached to visitied) is very
confusing: I copy here the comment I also placed inline below:
My understanding is that in this scenario the MN simply DOES NOT
connect to the home link. If the MN connected to a link which is
identified or detected to be its home link, it simply disconnects
without sending a BU to the HA. So, as far as the HA is concerned the
MN is NOT connected at its home link and operations continue as
normal. The text in this section, however, says something different
which does not match my understanding at all. Am I confused?

Thanks again for all the effort and see the rest of the detailed review below.

George

-------------------------------------------------------------------------------------------------------------------------------
1.  Introduction

...

   But assigning a single home address to a node is more
   advantageous than assigning multiple home addresses because
   applications do not need to be aware of the multiplicity of home
   addresses.

GT> I am not sure I agree with this statement. I think effective use
of multiple home addresses by applications is a better and more robust
technique but it does require applications to be written in a certain
way. Multiple CoAs allow multihoming awareness to be outsourced to a
different part of the IP stack but, especially when combined with per
flow bindings, it results in routing that is not purely destination
address based. This is not necessarily a good thing for Internet
routing as a whole and only acceptable because it is only confined in
HAs. I think we can have a bit better applicability statement that is
more objective and looks at the big picture. i.e., at the
architectural limitations of this approach.

...
3.  Protocol Overview

GT> I think the name of the extension is "Binding Identifier Mobility Option"?

   introduced to distinguish between multiple bindings pertaining to the
   same home address.  If a mobile node configures several IPv6 global

GT> // and the if/ and if

   address.

GT> I do not see why this is RECOMMENDED either :-).  At most this is
a MAY, since I can not think of any reason why this not totally an
implementation decision.

  For protocol simplicity, bulk registration to correspondent
   nodes is not supported in this document.  This is because the Return
   Routability mechanism introduced in [RFC-3775] cannot be easily
   extended to verify multiple care-of addresses stored in a single
   Binding Update.

   If the mobile node decides to act as a regular mobile node compliant
   with [RFC-3775], it sends a Binding Update without any Binding
   Identifier mobility options.  The receiver of the Binding Update
   deletes all the bindings registering with a BID and registers only a
   single binding for the mobile node.  Note that the mobile node can
   continue using BID even if only has a single binding is active.

GT> //BID even if only has a/BIDs even if it has only a/

   Binding cache lookup is done based on the home address and BID

   The mobile node may return to the home link through one of its
   interfaces.  There are three options possible for the mobile node
   when its returns home.

   1.  The mobile node uses only the interface with which it attaches to
       the home link.  It de-registers all bindings related to all
       care-of addresses.  The interfaces still attached to the visited
       link are no longer going to be receiving any encapsulated traffic

GT> //link/link(s)

       from the home agent.

   2.  The mobile node uses only the interfaces still attached to the
       visited link.

GT> //link/link(s)

The interface with which the mobile node attaches
       to the home link is not used.

   3.  The mobile node may simultaneously use both the interface
       attached to the home link and the interfaces still attached to
       the visited links.

GT> //links/link(s)

   ...

Wakikawa (Ed.), et al.   Expires August 11, 2008                [Page 8]

Internet-Draft                    MCoA                     February 2008

   Status

      When the Binding Identifier mobility option is included in a
      Binding Acknowledgement, this field overwrites the status field
      correspondent to each binding in the Binding Acknowledgement.  If
      this field is zero, the receiver MUST use the registration status
      stored in the Binding Acknowledgement message.  This Status field
      can be used to carry error information for a Care-of Test message.
      The status is 8-bit unsigned integer.

     The possible status codes
      are the same as the status codes of Binding Acknowledgement.

GT> This is not true, right? New values are defined in section 4.5.
   Care-of address (C) flag

      When this flag is set, it indicates that a valid care-of address
      is present in the care-of address field in the BID mobility
      option.  This flag MUST be set whenever the mobile node sends
      multiple care-of addresses in a single Binding Update, i.e., bulk
      registration.  It MAY also used as a substitute for alternate
      care-of address option even for Binding Updates that are sent only
      for one care-of address.  This flag is valid only for Binding
      Update sent to the home agent.

   Overwrite (O) flag

      When this flag is set, a mobile node requests the recipient to
      replace all the bindings to binding entries stored in a Binding
      Update.

   Simultaneous Home and Foreign Binding (H) flag

      This flag indicates that the mobile node registers multiple
      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
      agent.

   DSMIPv6 (D) flag

      This flag indicates that the care-of address is an IPv4 address.
      When this flag is set, the care-of address field MUST contain an
      IPv4 address.

   Reserved

      5 bits Reserved field.  The reserved field MUST be zero.

Wakikawa (Ed.), et al.   Expires August 11, 2008                [Page 9]

Internet-Draft                    MCoA                     February 2008

   Care-of Address

      This field has the variable length depending on the specified
      flags.  When the 'C' flag is set and the 'D' flag is not, an IPv6
      care-of address for the corresponding BID is stored in this field.
      If both 'C' and 'D' flags are set, an IPv4 Care-of Address is
      carried in this field.  This field MUST NOT be used if a Binding
      Identifier mobility option is included in any other message other
      than a Binding Update.

GT> For completeness you may want to add: "...or if the 'C' flag is not set."
...
5.  Mobile Node Operation

// Addresses and Binding Identifier/ Address(es) and Binding Identifier(s)

   There are two cases when a mobile node might acquire several care-of
   addresses.  Note that a mixture of the two cases are also possible.

GT> //are/is

   1.  A mobile node may be using several physical network interfaces
       and acquires a care-of address on each of its interfaces.

   2.  A mobile node uses a single physical network interface, but
       receives advertisements for multiple prefixes on the link the
       interface is attached to.  This will result in the mobile node
       configuring several global addresses on the interface from each
       of the announced prefixes.

   The difference between the above two cases is only in the number of
   physical network interfaces and therefore irrelevant in this
   document.  What is of significance is the fact that the mobile node
   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
   register them simultaneously with its home address.  The BID MUST be
   unique for a given home address and care-of address pair.  The value
   should be an integer between 1 and 65535.  Zero and negative values
   MUST NOT be used as a BID.  If a mobile node has only one care-of

GT> //as a BID/as BIDs

   address, the 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 MUST be mapped to BIDs.

5.2.  Return Routability: Sending CoTI and Receiving CoT

   When a mobile node wants to register multiple care-of address with a
   correspondent node, it MUST have the valid Care-of Keygen token per
   care-of address.

   For the Home Keygen, the mobile node needs only for
   the home address.

GT> Rephrase the above: "The mobile node needs only one Home Keygen
for its home address."

   The mobile node MUST include a Binding Identifier mobility option in
   the Care-of Test Init message.  It MUST NOT set any flags in the
   mobility option.  The receiver (i.e. correspondent node) will
   calculate a care-of Keygen token as specified in [RFC-3775] and reply
   with a Care-of Test message, with the Binding Identifier mobility
   option as described in Section 6.2.  When the mobile node receives
   the Care-of Test message, the message is verified as in [RFC-3775].
   If a Binding Identifier mobility option is not present in the CoT
   message in reply to the CoTI message that included a Binding
   Identifier mobility option, the mobile node must assume that the
   correspondent node does not support Multiple Care-of Address

Wakikawa (Ed.), et al.   Expires August 11, 2008               [Page 12]

Internet-Draft                    MCoA                     February 2008

   registration.  Thus, the mobile node MUST NOT use a Binding
   Identifier mobility option in any future Binding Updates to that
   correspondent node.  The mobile node MAY skip re-sending regular CoTI
   message and keep the received care-of Keygen token for the regular
   Binding Update.

GT> Should we also say anything about Enhanced RO based on RFC4866?

5.3.  Binding Registration

   For the multiple Care-of Addresses registration, the mobile node MUST
   include a Binding Identifier mobility option(s) in the Binding Update
   as shown in Figure 2.  The BID is copied from a corresponding Binding
   Update List entry to the BID field of the Binding Identifier mobility
   option.  When IPsec ESP is used for protecting the Binding Update,
   the care-of address cam be carried in the Care-of Address field of

GT> //cam/can

   the Binding Identifier mobility option.  If this is done, the
   alternate care-of address option MUST NOT be included in the Binding
   Update.
   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
   Binding Authorization Data mobility option that is placed after the
   Binding Identifier mobility option.

               IPv6 header (src=CoA, dst=HA)
                    IPv6 Home Address Option
                    ESP Header  (for home registration)
                    Mobility header
                        -BU
                       Mobility Options
                          - Binding Identifier mobility option
                          - Binding Authorization mobility option
                            (for Route Optimization)

             Figure 2: Binding Update for Binding Registration

5.4.  Bulk Registration

   Bulk registration is an optimization for binding multiple care-of
   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
   lot of signaling messages through an interface where the bandwidth is
   scarce.

   To use bulk registration, the mobile node includes a Binding
   Identifier Mobility option for each BID and Care-of address pair it
   wants to register in the same Binding Update message.  This is shown

Wakikawa (Ed.), et al.   Expires August 11, 2008               [Page 13]

Internet-Draft                    MCoA                     February 2008

   in Figure 3.  The rest of the fields and options in the Binding
   Update such as Lifetime, Sequence Number, the flags in the Binding
   Update are common across all care-of addresses.  The alternate
   care-of address option MUST NOT be used.

   In the bulk registration, the Sequence Number field of a Binding
   Update SHOULD be carefully configured.  This is because all the bulk-
   registered bindings uses the same Sequence Number specified in the

GT>//uses/use

   Binding Update.  If each binding uses different sequence number, a
   mobile node MUST use the largest sequence number from the Binding
   Update list entries used for the bulk registration.  If the mobile
   node cannot select a sequence number for all the bindings due to
   sequence number out of window, it MUST NOT use the bulk registration
   for the binding whose sequence number is out of window.  A separate
   Binding Update should be sent for the binding.

               IPv6 header (src=CoA, dst=HA)
                    IPv6 Home Address Option
                    ESP Header
                    Mobility header
                        -BU
                       Mobility Options
                          - Binding Identifier mobility options
                            (C flag is set, O flag is optional,
                             BID and CoA are stored)

              Figure 3: Binding Update for Bulk Registration

   If the mobile node wants to replace existing registered bindings on
   the home agent with the bindings in the sent Binding Update, it sets
   the 'O' flag.  Section 6.3 describes this registration procedure in
   detail.

5.5.  Binding De-Registration

   When a mobile node decides to delete all the bindings for its home
   address, it sends a regular de-registration Binding Update with
   lifetime set to zero as defined in [RFC-3775].  The Binding
   Identifier mobility option is not required.

   If a mobile node wants to delete a particular binding(s) from its
   home agent and correspondent nodes (e.g. from foreign link), the

GT> Remove "(e.g. from foreign link)" it is not clear what it means.

   mobile node sends a Binding Update with lifetime set to zero and
   includes a Binding Identifier mobility option(s) with the BID(s) it
   wants to de-register.  The receiver will remove only the care-of
   address(es) that match(es) the specified BID(s).  The care-of
   addresses field of each mobility option SHOULD be omitted, because
   the receiver will remove the binding matching the specified BID.

GT> // SHOULD be omitted/ SHOULD be omitted by the sender and MUST be
ignored by the receiver/

Wakikawa (Ed.), et al.   Expires August 11, 2008               [Page 14]

Internet-Draft                    MCoA                     February 2008

5.6.  Returning Home

   The mobile node may return to the home link, by attaching to the home
   link through one of its interfaces.  When the mobile node wants to
   return home, it should be configured with information on what
   interface it needs to use.  The mobile node may use only the
   interface with which it is attached to the home link, only the
   interfaces still attached to the visited link or use both interfaces
   attached to the home link and visited link simultaneously.  The
   following describes each option in more detail.

5.6.1.  Using only Interface attached to the Home Link

   The mobile node returns home and de-registers all the bindings as
   shown in Figure 9.

GT> add: "...and as defined in [RFC3775].

  De-registering all the bindings is the same as
   binding de-registration from foreign link described in Section 5.5.
   After the de-registration step, all the 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 visited
   link.  While the mobile node de-registers all the bindings from the
   home agent, it may continue registering bindings for interface
   attached to visited link to the correspondent node as shown in
   Figure 9.

   The mobile node returns home and shuts down the interface attached to
   the home link as shown in Figure 10.  Before shutting down the
   interface, any binding for the care-of address previously associated
   with the interface should be deleted.  To delete the binding cache
   entry, the mobile node MUST send a de-registration Binding Update
   with the lifetime set to zero and include the corresponding BID
   information.  This scenario is not the most efficient because all the
   traffic to and from the mobile node is going through the bi-
   directional tunnel, whereas the mobile node is now accessible at one
   hop on the home link from its home agent.

GT> This scenario is still confusing to me. My understanding is that
in this scenario the MN simply DOES NOT connect to the home link. If
the MN connected to a link that is identified or detected to be its
home link, it simply disconnects without sending a BU to the HA. So,
as far as the HA is concerned the MN is NOT connected at its home link
and operations continue as normal. The paragraph above, however, says
something different which does not match my understanding at all. Am I
confused?

5.6.3.  Simultaneous Home and Visited Link Operation

   In this case, the mobile node returns home and continues using all
   the interfaces attached to both foreign and home links as shown in
   Figure 11.  The mobile node indicates this by setting the 'H' flag in
   the BID mobility option.

GT> Add: " ...as defined below."

 There are additional requirements on the
   Returning Home procedures for possible ND conflicts at the home link
   described below.

   In [RFC-3775], the home agent intercepts packets meant for the mobile
   node using proxy Neighbor Discovery while the mobile node is away

Wakikawa (Ed.), et al.   Expires August 11, 2008               [Page 15]

Internet-Draft                    MCoA                     February 2008

   from the home link.  When the mobile node returns home, the home
   agent deletes the binding cache and stops proxying for the home
   address so that a mobile node can configure its home address on the
   interface attached to the home link.  In this specification, a mobile
   node may return home, configure the home address on the interface
   attached to the home link, but still use the interfaces attached to
   the foreign links.  In this case, a possible conflict arises when the
   both the home agent and the mobile node try to defend the home
   address.  If the home agent stops proxying for the home address, the
   packets are always routed to the interface attached to the home link
   and are never routed to the interfaces attached to the visited links.
   It is required to avoid the conflict between the home agent and the
   mobile node, while still allowing the simultaneous use of home and
   foreign links.  The following describes the mechanism for achieving
   this.

   In this specification, the home agent MUST intercept all the packets
   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
   address.  The home agent intercepts all the packets even when the
   mobile node is attached to the home link through one of its
   interfaces.  The home agent would make this decision based on the
   type of packets and flows.  How to make this decision is out of scope
   in this document.  The critical part would be to create a neighbor
   cache entry for the mobile node so that the home agent can deliver
   the packets on-link.  The home agent would need to know the Layer-2
   address of the interface with which the mobile node is attached to
   the home link.  In order to create the neighbor cache entry for the
   mobile node, following operations are required.

   The mobile node sends a de-registration Binding Update to the home
   agent from the interface attached to the home link.  In the Binding
   Update, the BID mobility option must include the BID the mobile node
   had previously associated with the interface attached to the home
   link.

GT> When was this association done? What does "previously" refer to?

   The 'H' flag MUST be set in the BID mobility option.  The 'C'
   flag MUST NOT be set and the care-of address field MUST NOT be
   included.  When the 'H' flag is set, the home agent recognizes that
   the mobile node wants to continue using interfaces attached to both
   home and visited links.  If the 'H' flag is unset, the home agent
   deletes either all the bindings or the binding corresponding to the
   BID included in the Binding Identifier mobility option.

   When the home agent sends the Binding Acknowledgement, it MUST set
   the status value to either 0 [Binding Update Accepted] or to [MCOA
   RETURNHOME WO/NDP (TBD)] in the BID mobility option depending on home
   agent configuration at the home link.  The new values are:

Wakikawa (Ed.), et al.   Expires August 11, 2008               [Page 16]

Internet-Draft                    MCoA                     February 2008

      [RFC-3775]

   When the home agent is the only router at the home link, it can
   intercept all the packets by normal IP routing without using proxying
   for the home address.  It stops proxy ND for the requested home
   address and responds with the [Binding Update Accepted] status value
   to the mobile node.  The neighbor cache entry for the mobile node is
   created by the regular exchange of Neighbor Solicitation and Neighbor
   Advertisement.  If the home agent is not the only router on the home
   link, it MUST continue defending the home address by proxy neighbor
   discovery in order to intercept the mobile node's traffic.  The home
   agent, then, returns [MCOA RETURNHOME WO/NDP] value in the Status
   field of the BID mobility option.  The home agent also learns the
   mobile node's layer-2 address (i.e., MAC address) during this binding
   de-registration.  It stores the learnt layer-2 address in a neighbor
   cache entry for the mobile node so that it can construct the layer-2
   header for the packets meant for the mobile node and forwards them
   directly to the mobile node's interface attached to the home link.

   According to [RFC-3775], the mobile node MUST NOT assign the home
   address to the interface attached to the home link and MUST NOT
   attempt NDP operations for the home address before the completion of
   binding de-registration.  It MUST NOT send and reply to Neighbor
   Solicitation for the home address.  The home address MUST be
   tentative address at this moment until it receives Binding
   Acknowledgement with success status value.

   When the mobile node receives the Binding Acknowledgement and BID
   mobility option, it assigns home address to the interface attached to
   the home link according to the status field of the BID.  If the value
   is [Binding Update Accepted], the mobile node can start defending the
   home address using regular Neighbor Discovery.

   If the mobile node receives the [MCOA RETURNHOME WO/NDP], it MUST NOT
   defend its home address on the home link.  When the mobile node sends
   packets from the interface attached to the home link, it MUST learn
   the layer 2 address (i.e., MAC address) of the next hop (i.e. default
   router, it can be home agent) during the binding de- registration and
   construct the packet including layer 2 header with the learnt layer-2
   address of the default router or the home agent.

GT> Something needs to be said about the lifetime of the BU with 'H'
flag set. If the MN has to send a de-reg to the HA with Lifetime=0 and
'H' set, for how ling is this state valid? What happens to the
lifetime of the other bindings??

Wakikawa (Ed.), et al.   Expires August 11, 2008               [Page 17]

Internet-Draft                    MCoA                     February 2008

5.7.  Receiving Binding Acknowledgement

   The verification of a Binding Acknowledgement is the same as Mobile
   IPv6 (section 11.7.3 of [RFC-3775]).  The operation for sending a
   Binding Acknowledgement is described in Section 6.3.

   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.  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.
   The mobile node MUST then stop multiple care-of address registration
   with that node.

   If a Binding Identifier mobility option is present in the received
   Binding Acknowledgement, the mobile node checks the status field in
   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
   the Binding Acknowledgement.  Otherwise, it uses the value in the
   Status field of the Binding Identifier mobility option.

   If the status code is greater than or equal to 128, the mobile node
   starts relevant operations according to the error code.  Otherwise,
   the mobile node assumes that the originator (home agent or
   correspondent node) successfully registered the binding information
   and BID for the mobile node.

   o  If the Status value is [MCOA PROHIBITED], the mobile node MUST
      stop registering multiple bindings to the node that sent the
      Binding Acknowledgement.

   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.

   o  If [MCOA MALFORMED] is specified, it indicates that the binding
      identifier mobility option is formatted wrongly.  For example, if
      the 'C' flag is set, all mobility options MUST have 'C' flag.  It
      is same for 'O' flag.

GT> What do you mean here with the 'C' and 'O' flags? It is not clear.
Also it is not nice to find MUSTs with respect on how to use the flags
when talking about the error codes. These MUSTs, if needed, should be
moved elsewhere.

   o  If [MCOA BID CONFLICT] is specified, the binding entry specified
      by the Binding Identifier mobility option is already registered as
      a regular binding.  In such case, the mobile node SHOULD stop
      sending Binding Updates with BID, or SHOULD use the 'O' flag to
      reset all the registered bindings.

Wakikawa (Ed.), et al.   Expires August 11, 2008               [Page 18]

Internet-Draft                    MCoA                     February 2008

5.8.  Receiving Binding Refresh Request

   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
   a Binding Refresh Request is described in section Section 6.4.

   If a mobile node receives a Binding Refresh Request with a Binding
   Identifier mobility option, it indicates that the node sending the
   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
   Binding Update only for the respective binding.  The mobile node MUST
   include a Binding Identifier mobility option in the Binding Update.

   If no Binding Identifier mobility option is present in a Binding
   Refresh Request, the mobile node sends a Binding Update according to
   its Binding Update List.  On the other hand, if the mobile node does
   not have any Binding Update List entry for the requesting node, the
   mobile node needs to register either a single binding or multiple
   bindings depending on its binding management policy.

5.9.  Sending Packets to Home Agent

   When a multihomed mobile node sends packets to its home agent, there
   are conceptually two ways to construct packets.

   1.  Using Home Address Option. (required additional 24 bytes)

   2.  Using IPv6-IPv6 tunnel. (required additional 40 bytes)

GT> Remove the period or remove the ( ) and capitalize the R.

   Beside the difference in the size of packets, there is no difference
   between the two.  The routing path does not get affected.  With
   extensions specified in this document, the mobile node is capable of
   using multiple care-of addresses for outgoing packets.  This is a
   problem on the home agent side because it must verify the Care-of
   address for all the packets received from the mobile node (i.e.
   ingress filtering).  When the mobile node uses the Home Address
   option, the home agent MAY check the care-of address in the packet
   with the registered binding entries.  This causes additional overhead
   to the home agent.  Therefore, the mobile node SHOULD use the bi-
   directional tunnel even if it registers a binding(s) to the home
   agent.

GT> This confuses me a bit. Is there anything different from RFC3775?
Why is this section needed?

5.10.  Bootstrapping

   When a mobile node bootstraps and registers multiple bindings for the
   first time, it SHOULD set the 'O' flag in the Binding Identifier
   mobility option.

GT> Should this be a MUST? Otherwise what is the behavior of the HA?

   If old bindings still exists at the home agent, the
   mobile node has no knowledge of which bindings still exist at the

Wakikawa (Ed.), et al.   Expires August 11, 2008               [Page 19]

Internet-Draft                    MCoA                     February 2008

   home agent.  This scenario happens when a mobile node reboots and
   looses state regarding the registrations.  If the 'O' flag is set,
   all the bindings are replaced by the new binding(s).  If the mobile
   node receives the Binding Acknowledgement with the status code set to
   135 [Sequence number out of window], it MUST retry sending a Binding
   Update with the last accepted sequence number indicated in the
   Binding Acknowledgement.

   The 'O' flag can also be used in individual Binding Updates sent to
   the correspondent nodes to override any existing binding cache
   entries at the correspondent node.

GT> Again the 'O' flag MUST be set the first time MCoA is used with a
CN I think.

Wakikawa (Ed.), et al.   Expires August 11, 2008               [Page 20]

Internet-Draft                    MCoA                     February 2008

6.  Home Agent and Correspondent Node Operation

6.1.  Searching Binding Cache with Binding Identifier

   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
   the bindings to communicate with the mobile node.  How to select the
   most suitable binding from the binding cache database is out of scope
   in this document.

   Whenever a correspondent node searches a binding cache for a home
   address, it SHOULD uses both the home address and the BID as the
   search key if it knows the corresponding BID.

GT> This is a bid strange. Why would the HA or CN use a BID as a key?
The HoA is used as a key because the HA/CN want to send a packet with
the HoA as destination address, which causes Mobile IP to use the HoA
as a key to find an appropriate CoA. I do not think that the BIDs are
needed for this. With MCoA, the only difference is that a lookup of
the HoA will return multiple CoAs; and which one is used is out of
scope for this document.

GT> So, the BIDs are only used as key when the receiver processes a BU
message including a BID Mobility option. Is this what this is about?

 In the example below,
   if a correspondent node searches the binding with the home address
   and BID2, it gets binding2 for this mobile node.

             binding1 [a:b:c:d::EUI,  care-of address1,  BID1]
             binding2 [a:b:c:d::EUI,  care-of address2,  BID2]
             binding3 [a:b:c:d::EUI,  care-of address3,  BID3]

                   Figure 4: Searching the Binding Cache

   A correspondent node earns the BID when it receives a Binding

GT> //earns/learns

   Identifier mobility option.  At the time, the correspondent node MUST

GT>//At the time/At that time

   look up its binding cache database with the home address and the BID
   retrieved from the Binding Update.  If the correspondent node does
   not know the BID, it searches for a binding with only the home
   address.  In such a case, the first matched binding is found.  If the
   correspondent node does not desire to use multiple bindings for a
   mobile node, it can simply ignore the BID.

GT> This whole section needs to be cleaned based on the comment above.

6.2.  Receiving CoTI and Sending CoT

   When a correspondent node receives a CoTI message which contains a
   Binding Identifier mobility option, it processes it as follows.

   First, the CoTI message is verified as specified in [RFC-3775].  The
   Binding Identifier mobility option is processed as follows:

   o  If a correspondent node does not understand a Binding Identifier
      mobility option, it just ignores and skips processing the option.
      The calculation of a care-of Keygen token will thus be done
      without a BID value.  The correspondent node returns a CoT message
      without a Binding Identifier mobility option.  The mobile node
      knows whether the correspondent supports processing the Binding
      Identifier mobility option, by checking if the option is present
      in the CoT message.

Wakikawa (Ed.), et al.   Expires August 11, 2008               [Page 21]

Internet-Draft                    MCoA                     February 2008

   o  If either the 'C' or the 'O' flag is set in the Binding Identifier
      mobility option, the correspondent Node SHOULD NOT calculate a
      care-of Keygen token, but MUST include a Binding Identifier
      mobility option with status value set to [MCOA MALFORMED] in the
      Care-of Test message.

   o  Otherwise, the correspondent node MUST include a Binding
      Identifier mobility option with status value set to zero (success)
      in the Care-of Test message.

   o  The Care-of address field of each Binding Identifier mobility
      option, can be omitted, because the mobile node can identify the
      corresponding Binding Update list entry using the BID.

6.3.  Processing Binding Update

   If a Binding Update does not contain a Binding Identifier mobility
   option, its processing is same as in [RFC-3775].  If the receiver
   already has multiple bindings for the home address, it MUST replace
   all the existing bindings by the received binding.  As a result, the
   receiver node MUST have only one binding cache entry for the mobile
   node.  If the Binding Update is for de-registration, the receiver
   MUST delete all existing bindings from its Binding Cache.

   If the Binding Update contains a Binding Identifier mobility
   option(s), it is validated according to section 9.5.1 of [RFC-3775]
   and the following steps.

   o  If the home registration flag is set in the Binding Update, the
      home agent MUST carefully operate Duplicate Address Detection
      (DAD) for the received home address.  If the home agent has
      already had a binding(s) for the mobile node, it MUST avoid
      running DAD for the home address on the home link when it receives
      the Binding Update.

GT> Why is this here? This is normal RFC3775 operation and should not
be affected by MCoA, no?

   The receiver MUST process the Binding Identifier mobility option(s)
   in the following steps.  When a correspondent node sends a Binding
   Acknowledgement, the status value MUST be always stored in the Status
   field of the Binding Acknowledgement and the Status field of Binding
   Identifier mobility option set to zero.

GT> The last sentence does not make sense. Please rephrase.

   For the home agent, the status value can be stored in the Status
   field of either a Binding Acknowledgement or a Binding Identifier
   mobility option.  If the status value is specific to one of bindings
   in the bulk registration, the status value MUST be stored in the
   Status field in the corresponding Binding Identifier mobility option.
   In this case, [MCOA NOTCOMPLETE] MUST be set to the Status field of
   the Binding Acknowledgement so that the receiver can examine the

Wakikawa (Ed.), et al.   Expires August 11, 2008               [Page 22]

Internet-Draft                    MCoA                     February 2008

   Status field of each Binding Identifier mobility option for further
   operations.

   o  The length value is examined.  The length value MUST be either 4,
      8, or 20 depending on the 'C' and 'D' flags.  If the length is
      incorrect, the receiver MUST reject the Binding Update and returns
      the status value set to [MCOA MALFORMED].

   o  When the 'C' flag is set, the care-of address MUST be present in
      the Binding Identifier mobility option.  Otherwise, the receiver

GT> It is not clear what "Otherwise" refers to. Replace with: "If the
care-of address is not present..."

      MUST reject the Binding Identifier mobility option and returns the
      status value set to [MCOA MALFORMED].  The operation of 'D' flag
      is described in Section 8

   o  When multiple Binding Identifier mobility options are present in
      the Binding Update, it is treated as bulk registration.  If the
      receiving node is a correspondent node, it MUST reject the Binding
      Update and returns the status value in the binding acknowledgement
      set to [MCOA BULK REGISTRATION NOT SUPPORT]

   o  If the Lifetime field in the Binding Update is set to zero, the
      receiving node deletes the binding entry that corresponds to the
      BID in the Binding Identifier mobility option.  If the receiving
      node does not have an appropriate binding for the BID, it MUST
      reject the Binding Update and send a Binding Acknowledgement with
      status set to 133 [not home agent for this mobile node].

GT>This does not make sense. If the BID does not exist then the
binding never existed or has already been deleted so I would send a BA
and BID Mobility option with status 0. Status 133 means that the HoA
is not valid...which is a different issue already covered in RFC3775.
Also please move this bullet one place down to be next to Lifetime !=
zero case.

   o  If the 'O' flag is set in the de-registering Binding Update, the
      receiver can ignore this flag for de-registration.

GT> This sentence is strange please rephrase.

      If the 'H'
      flag is set, the home agent stores a home address in the Care-of
      Address field of the binding cache entry.  The home agent also
      stops performing proxy ND for the mobile node's home address.

   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
      binding.  The Care-of address is obtained from the Binding Update
      packet as follows:

      *  If the 'C' flag is set in the Binding Identifier mobility
         option, the care-of address is copied from the care-of address
         field in the Binding Identifier mobility option.

      *  If the 'C' flag is not set in the Binding Identifier mobility
         option, the care-of address is copied from the source address
         field of the IPv6 header.

      *  If the 'C' flag is not set and an alternate care-of address is
         present, the care-of address is copied from the Alternate

Wakikawa (Ed.), et al.   Expires August 11, 2008               [Page 23]

Internet-Draft                    MCoA                     February 2008

         Care-of address mobility option.

   o  Once the care-of address(es) has been retrieved from the Binding

GT>//has/have

      Update, the receiving nodes creates new binding(s).

      *  If only 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
         for the mobile node, it must not process the binding update.
         The receiver should sent a binding acknowledgement with status
         set to [MCOA BID CONFLICT].

GT> This makes no sense. What do you mean?

      *  If the receiver already has a binding with the same BID, it

GT>// same BID, it/ same BID and different care-of address, it

         MUST update the binding and responds with a Binding

GT>//responds/respond

         Acknowledgement with status set to 0 [Binding Update accepted].

      *  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
         Acknowledgement with status set to 0 [Binding Update accepted].

GT> What happens if one receives a new BID mapped to a CoA already in
the binding cache (but mapped to different BID?) Is this allowed? Is
this how one can change the BIDs it is using?

   If all the above operations are successfully completed, a Binding
   Acknowledgement containing the Binding Identifier mobility options
   MUST be sent to the mobile node.  Whenever a Binding Acknowledgement
   is sent, all the Binding Identifier mobility options stored in the
   Binding Update MUST be copied to the Binding Acknowledgement except
   the status field.  The Care-of address field in each Binding
   Identifier mobility option, however, can be omitted, because the
   mobile node can match a corresponding binding update list entry using
   the BID.

GT> Something needs to be said about the lifetime of the bindings. I
assume that the Lifetime field of the BU updates the lifetime of all
the bindings, whether a regular or bulk MCoA registration is
performed.

6.4.  Sending Binding Refresh Request

   When a node (home agent or correspondent node) sends a Binding
   Refresh Request for a particular binding created with the BID, the
   node SHOULD include the Binding Identifier mobility option in the
   Binding Refresh Request.

GT> This needs a bit more...which BID mobility option is included?
Just one? All of them? Again we need to be clear what the lifetime
does and how it relates to each of the CoAs.

6.5.  Receiving Packets from Mobile Node

   When a node receives packets with a Home Address destination option
   from a mobile node, it MUST check that the care-of address that
   appears in the source address field of the IPv6 header MUST be equal
   to one of the care-of addresses in the binding cache entry.  If no
   binding is found, the packets MUST be silently discarded.

GT> Why don't we just point to RFC3775 and say that the exact same
processing is used here?

  The node
   MUST also send a Binding Error message as specified in [RFC-3775].
   This verification MUST NOT be done for a Binding Update.

Wakikawa (Ed.), et al.   Expires August 11, 2008               [Page 24]

Internet-Draft                    MCoA                     February 2008

7.  Network Mobility Applicability

   The binding management mechanisms are the same for a mobile host that
   uses Mobile IPv6 and for a mobile router that is using the NEMO Basic
   Support protocol [RFC-3963].  Therefore the extensions described in
   this document can also be used to support a mobile router with
   multiple care-of addresses.  Figure 5 shows an example format of a
   Binding Update sent by a mobile router.

               IPv6 header (src=CoA, dst=HA)
                    IPv6 Home Address Option
                    ESP Header
                    Mobility header
                        -BU
                       Mobility Options
                          - Binding Identifier
                          - Mobile Network Prefix

                       Figure 5: NEMO Binding Update

GT> Why is this example here? I would remove it together with the last sentence.

Wakikawa (Ed.), et al.   Expires August 11, 2008               [Page 25]

Internet-Draft                    MCoA                     February 2008

8.  DSMIPv6 Applicability

   Dual Stack Mobile IPv6 (DSMIPv6) [ID-DSMIPv6] extends Mobile IPv6 to
   register an IPv4 care-of address instead of the IPv6 care-of address
   when the mobile node is attached to an IPv4-only access network.  It
   also allows the mobile node to acquire an IPv4 home address in
   addition to an IPv6 home address for use with IPv4-only correspondent
   nodes.  This section describes how multiple care-of address
   registration works with IPv4 care-of and home addresses.

8.1.  IPv4 Care-of Address Registration

   The mobile node can use the extensions described in the document to
   register multiple care-of addresses, even if some of the care-of
   addresses are IPv4 address.

   Bulk registration MUST NOT be used for the initial binding from an
   IPv4 care-of address.  This is because, the Binding Update and
   binding acknowledgement exchange is used to detect NAT on the path
   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
   agent.

   The Binding Update MUST be sent to the IPv4 home agent address by
   using UDP and IPv4 headers as shown in Figure 6.  It is similar to
   [ID-DSMIPv6] except that the IPv4 care-of address option MUST NOT be
   used when the BID mobility option is used.

              IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
                UDP Header
                  IPv6 header (src=V6HoA, dst=HAADDR)
                       ESP Header
                       Mobility header
                           -BU
                          Mobility Options
                            - Binding Identifier (IPv4 CoA)

         Figure 6: Initial Binding Update for IPv4 Care-of Address

   Whenever a NAT is detected, mobile node MUST NOT use bulk
   registration for the IPv4 care-of address.

GT> This was repeated above. Delete.

If a NAT is not detected,
   the mobile node can update the IPv4 care-of address by using BULK

GT>//BULK/bulk

   registration.  The mobile node can register the IPv4 care-of address
   along with other care-of addresses.  Figure 7 shows the Binding

GT>// other care-of addresses/ other IPv4 and IPv6 care-of addresses

   Update format when the mobile node sends a Binding Update from one of
   its IPv6 care-of addresses.  If the mobile node sends a BU from IPv4
   care-of address, it MUST follow the format described in Figure 6.
   Note that the IPv4 Care-of Address must be registered by non bulk

Wakikawa (Ed.), et al.   Expires August 11, 2008               [Page 26]

Internet-Draft                    MCoA                     February 2008

   Binding registration, whenever it is changed.

  NAT detection MUST be
   carried out for every new IPv4 addresses.

GT> Again, this was repeated above. Delete.

              IPv6 header (src=V6CoA, dst=HAADDR)
                    IPv6 Home Address Option
                    ESP Header
                    Mobility header
                        -BU
                       Mobility Options
                          - Binding Identifier (IPv6/v4 CoA)
                          - Binding Identifier (IPv6/v4 CoA)
                          - ...

       Figure 7: Binding Bulk Registration for IPv4 care-of address

   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.  The
   home agent MUST send the Binding Acknowledgement and all the received
   BID mobility options to the mobile node.

GT> This has already been explained in other sections. It is not good
to repeat MUST statements about the same thing. Delete the whole
paragraph….or just point to HA processing section.

8.2.  IPv4 HoA Management

   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
   IPv4 Home Address option in the Binding Update.  If the home agent
   accepts the Binding Update, the mobile node can now register multiple
   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
   for both IPv6 and IPv4 home addresses.  The mobile node cannot bind
   different set of care-of addresses to each home address.

   The home agent includes the IPv4 address acknowledgement option in
   the Binding Acknowledgement only if the mobile node had requested for
   the IPv4 home address.

GT> Rephrase: "According to [DSMIPv6], the home agent includes the
IPv4 address acknowledgement option in the Binding Acknowledgement
only if the mobile node requests an IPv4 home address in the
corresponding Binding Update. "

 The IPv4 address acknowledgement option MUST
   be present before any BID option.  The status field of the IPv4
   address acknowledgement option contains only the error code regarding
   IPv4 home address management.

GT>// the error code regarding IPv4 home address management/ the error
code corresponding to the IPv4 home address.

The error values related to the IPv4
   care-of address registration MUST be stored in the BID mobility
   option.

Wakikawa (Ed.), et al.   Expires August 11, 2008               [Page 27]

Internet-Draft                    MCoA                     February 2008

9.  IPsec and IKEv2 interaction

   Mobile IPv6 [RFC-3775] and the NEMO protocol [RFC-3963] require the
   use of IPsec to protect signaling messages like Binding Updates,
   Binding Acknowledgements and return routability messages.  IPsec may
   also be used protect all reverse tunneled data traffic.  The Mobile

GT> //used protect all reverse tunneled data / used to protect all
tunneled data/

   IPv6-IKEv2 specification [RFC-4877] specifies how IKEv2 can be used
   to setup the required IPsec security associations.  The following
   assumptions were made in [RFC-3775], [RFC-3963] and the MIP6-IKEv2
   specification with respect to the use of IKEv2 and IPsec.

GT> Why is MIP6-IKEv2 not properly referenced?

   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
      tunnel encapsulation and decapsulation.

   o  When the home agent receives a packet from the mobile node, the
      source address is verified against the care-of address in the
      corresponding binding cache entry.  If the packet is a reverse
      tunneled packet from the mobile node, the care-of address check is
      done against the source address on the outer IPv6 header.  The
      reverse tunnel packet could either be a tunneled HoTi message or
      tunneled data traffic to the correspondent node.

   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
      of the mobile node.

   The above assumptions may not be valid when multiple care-of
   addresses are used by the mobile node.  In the following sections,
   the main issues with the use of multiple care-of address with IPsec
   are addressed.

9.1.  Use of Care-of Address in the IKEv2 exchange

   For each home address the mobile node sets up security associations
   with the home agent, the mobile node must pick one care-of address
   and use that as the source address for all IKEv2 messages exchanged
   to create and maintain the IPsec security associations associated
   with the home address.  The resultant IKEv2 security association is
   created based on this care-of address.

GT> Add "according to MIP6-IKEv2 ..." until you have something new.

   If the mobile node needs to change the care-of address, it just sends
   a Binding Update with the care-of address it wants to use, with the
   corresponding Binding Identifier mobility option, and with the 'K'
   bit set.  This will force the home agent to update the IKEv2 security
   association to use the new care-of address.  If the 'K' bit is not
   supported on the mobile node or the home agent, the mobile node MUST

Wakikawa (Ed.), et al.   Expires August 11, 2008               [Page 28]

Internet-Draft                    MCoA                     February 2008

   re-establish the IKEv2 security association with the new care-of
   address.  This will also result in new IPsec security associations
   being setup for the home address.

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Tue, 12 Feb 2008 09:07:55 +0900

Hi George,

Thanks a  lot for comments, please find my reply inline.

On 2008/02/12, at 0:07, George Tsirtsis wrote:

> is common across all BIDs.

Yes. This is because BID option does not have lifetime field.

> IMO there needs to be more explicit

OK

> listed BIDs and does not affect the lifetime of other BIDs in the

All you mentioned above are correct.

> the lifetime of other BIDs  is not affected.

right.

> How is the  home link

I might miss your question.

HA should verify the reachability of the mobile node at the home link.
If the reachability is missed, the HA should clean up the all the home  
link states.

> are,

The point is not privacy or security reason, but MN can always pick a  
new BID.

> I also do not see anywhere how BIDs can be changed. Is is done by
> binding cache (but mapped to another BID)?

yes.

> I indicate that this could

This seems to be corner-case, but we will clarify it.

> which does not match my understanding at all. Am I confused?

We need one more operation here.

What about the binding cache for the CoA previously assigned to the  
interface(which is now disconnected)?
The interface is now disconnected, but the old binding cache for the  
previous CoA assigned to that interface
might be still active at the home agent.
It should explicitly send de-registration BU for that binding cache,  
since
MN has other active interfaces to send that BU.

We will revise the texts of section 5.6.2.

thanks
ryuji

---

From: "George Tsirtsis" <[email-masked]>
Date: Tue, 12 Feb 2008 13:22:46 +0000

Ryuji, thanks for your responses. Some comments inline...

> If the reachability is missed, the HA should clean up the all the home

GT> Yes, this is what I think is not ideal. Mobile IP, as most well
designed IP protocols, is a soft state protocol, and all of its state
is associated with lifetimes which are maintained by signaling. We are
now seem to be saying that when you have a home link, and although the
HA must maintain state for that fact, that state is "hard" and can
only be cleared by mechanisms that are outside protocol itself e.g.,
L2 triggers indicating the link is down.

GT> I think a possible alternative which is even implied (but not
clearly stated) by the current draft, is to use the lifetime
maintained by the visited links. In other words, in the H=1 scenario,
the MN has at least one other binding corresponding to a visited link.
That visited link CoA is associated in the HA with a Lifetime. This
same Lifetime value should be what maintains the home link state. The
difference is that the MN does not maintain the home link state
directly (i.e., it only has to send a BU with H=1 once) and then the
state is maintained by the Lifetime associated with visited link BIDs.
The implication is that if the MN deregisters all of its visited link
CoAs the home link state is automatically removed i.e., it is as if
the MN sent a BU with Lifetime=0 and no BID extensions.
Does this make sense?

> The point is not privacy or security reason, but MN can always pick a

GT> But for what reason? the draft somehow implies that this is a good
practice....while I think it is rather dangerous practice since it
would cause uneccessary and difficult to dimension for BU signaling
traffic.

> This seems to be corner-case, but we will clarify it.

GT> Yes, do. But also I would warn against doing this for no particular reason.

> MN has other active interfaces to send that BU.

GT> What CoA previously assigned are you talking about? At a home or a
visited link? We do not use CoAs in home links (are we?), and CoAs on
visited links are normal case in this scenario. I do not understand.

\> We will revise the texts of section 5.6.2.

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 21 Feb 2008 15:11:13 -0800

Hi George,

Thanks again for a very detailed review.

I am not responding to your high level comments on this email. I
will respond to those on the thread between you and Ryuji. For
the comments you made inline in the text, please see below.

I think the paragraph about advantages of using one home address
over multiple home addresses should be removed. Using multiple
home address is really out of scope for this document. This
document should only talk about the advantages of being able to
use multiple interfaces (care-of addresses) for connectivity.

Re-wrote the Introduction section.

    A mobile node may use various types of network interfaces to obtain
    durable and wide area network connectivity.  This is increasingly
    become true with mobile nodes having multiple interfaces such as
    802.2, 802.11, 802.16, cellular radios, etc..  The motivations for
    and benefits of using multiple points of attachment are discussed in
    [ID-MOTIVATION].  When a mobile node with multiple interfaces uses
    Mobile IPv6 [RFC-3775] for mobility management, it cannot use its
    multiple interfaces to send and receive packets while taking
    advantage of session continuity provided by Mobile IPv6.  This is
    because Mobile IPv6 allows the mobile node to only bind one care-of
    address at a time with its home address.

    This document proposes extensions to Mobile IPv6 to allow a mobile
    node to register multiple care-of addresses for a home address and
    create multiple binding cache entries.  A new Binding Identification
    (BID) number is created for each binding the mobile node wants to
    create and sent in the binding update.  The home agent that receives
    this Binding Update creates separate binding for each BID.  The BID
    information is stored in the corresponding binding cache entry.  The
    BID information can now be used to identify individual bindings.  The
    same extensions can also be used in Binding Updates sent to the
    correspondent nodes.

> GT> I think the name of the extension is "Binding Identifier Mobility 

The extension is the use of a binding identification number with
each binding. The mobility option is just carrying the binding
identification number.

> a MAY, since I can not think of any reason why this not totally an

Changed it to 'MAY'.

> GT> This is not true, right? New values are defined in section 4.5.

I think the intention here is to say that we are not creating
a new IANA registry. We are re-using the Binding Ack status
code registry.

> GT> Should we also say anything about Enhanced RO based on RFC4866?

No opinion on this.

> something different which does not match my understanding at all. Am I

No. It is possible for the mobile node to just shut down the
interface with which it is attached to the home link. But there
is still a binding at the home agent that binds the home address
to the care-of address previously associated with this interface.
The above paragraph, I think, describes how to delete that
binding.

> GT> When was this association done? What does "previously" refer to?

When this interface was attached to the visited link previously
it had a care-of address and a BID associated with it.

> lifetime of the other bindings??

Needs to be discussed as part of overall binding lifetime issue.

> when talking about the error codes. These MUSTs, if needed, should be

I think the example needs to be deleted. Other sections in the
document describe why the status MCOA_MALFORMED is returned in
a binding ack (or the status field in the BID option).

> Why is this section needed?

I think it should be deleted. When packets are tunneled to the
home agent, the home agent checks if the source address on the
outer IPv6 header matches the care-of address in the binding
cache entry. The only exception is when the packet contains
a binding update. So the sentence in the above paragraph is
actually not valid.

> GT> Should this be a MUST? Otherwise what is the behavior of the HA?

Not necessary, since we have a recovery mechanism (Status code
135, sequence number out of window) in RFC 3775. The binding
ack will tell the mobile node which sequence number to use.

> message including a BID Mobility option. Is this what this is about?

I think the text here assumes that the HA or the CN when
trying to send/forward a packet, the packet gets mapped (based
on the source/destination IP, source/destination port, and
protocol) to a particular BID. Then the BID is used as a key
along with the home address.

This needs some more discussion, before we can decide what
text goes into this section.

> GT> Why is this here? This is normal RFC3775 operation and should not

I think the difference is that in RFC 3775, if there is a valid
binding cache entry for the home address already, the new BU
would be for just refreshing the binding. In MCoA case, the
new BU could be for adding another care-of address. But in both
cases, the home agent MUST NOT run DAD again for the home
address. So the behavior the same. The paragraph can be removed.

> GT> The last sentence does not make sense. Please rephrase.

The last sentence and the next paragraph are in the wrong place.
Moving them to the end of section after the BID option processing
steps.

> Also please move this bullet one place down to be next to Lifetime !=

No. This is required from RFC 3775. If a mobile node sends a
de-registration BU (with lifetime 0) and if the home agent
does not have a binding, it must send a binding ack with
status 133. Sending a binding ack with status 0 would tell
the mobile node that the de-registration BU was successfully
processed and the corresponding binding cache entry was
deleted. This is not the case.

> GT> This makes no sense. What do you mean?

This is to handle the case where the home agent has a binding
cache entry with no BID information, but receives a binding
update with a BID option. The home agent does not know what
BID to assign to the CoA in the binding cache entry. So
instead it sends an error with status BID_CONFLICT.

> this how one can change the BIDs it is using?

I think the mobile node has to delete the earlier one and
then create new bindings.

> does and how it relates to each of the CoAs.

Tied to the lifetime issue again.

> GT> Why don't we just point to RFC3775 and say that the exact same

There is a minor difference. The source address in the IPv6
header can match "any" care-of address in the binding cache
entry. In RFC 3775, there was only care-of address in the
binding cache and that had to match with the source address in
the IPv6 header.

> GT> Why is this example here? I would remove it together with the last 

I think it just shows the use of a BID option in a BU sent
by a mobile router. The BU sent by the mobile router has the
Mobile Network Prefix option, which isn't there in a normal
BU. But I agree this example is not required. Will remove it.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 21 Feb 2008 15:26:20 -0800

>> I might miss your question.

I am a bit confused. A BU with the 'H' flag set is used only for
simultaneous home and visited link operation. Why would the
lifetime be zero in this BU? In fact the mobile node is requesting
the home agent to intercept all packets even though it is attached
to the home link through one of its interfaces. There should be a
lifetime associated with the kind of home agent behavior.

George, I agree we shouldn't create some state on the home agent
that might not expire because there is a Mobile IP signaling
message that does not explicitly delete it.

However, we might still have to explain how the home agent handles
a BU with lifetime set to zero and the 'H' flag set to 1.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 22 Feb 2008 11:11:57 -0800

Ryuji Wakikawa wrote:

> We should treat the lifetime of  that home state and the other real 
> bindings separately.
> 
> When the MN sends a BU with H flag set, it should not use bulk 
> registration and send it as an individual BU.
> The lifetime field MUST be set to the appropriate lifetime for that home 
> state.
> HA can always treat this BU as de-registration BU because the source 
> address and home address are same.
> In addition to that, H flag can also tell this is deregistration BU.
> MN should renew the home state while it is at the home link.
> 
> If you are fine with this, I will prepare for additional texts.

This would mean that a BU with the 'H' flag set is a special
de-registration BU that deletes the binding cache entry but
creates some special state that says certain flows can be
delivered directly over the home link. What is the lifetime
in this BU?

How do we delete this state later on? Does the mobile node
send a BU with lifetime set to 0 and 'H' flag set to '1'?
This needs more discussion. It might be better not to add
any text to the draft right now.

> When MN establishes a tunnel with its HA and sends packets to the HA,
> will MN should send packets with HoA option (RO) or IP-in-IP (non RO)?
> RFC3775 does not clearly explain this. HA can be treated as a CN.
> The way of address verification is slightly different between
> packets sent with HoA option and with IP-in-IP.
> 
>> cache entry.
> Most of implementation verifies the source address
> with the tunnel states (Not with BC database)
> 
>> The only exception is when the packet contains
> This check MUST be done with the binding cache database.
> 
> 
> This paragraph is to explain how to avoid the overhead of the address 
> verification in MCoA.
> 
> If the BC database is used for source address verification,
> HA might search the BC database recursively to match the CoA and the 
> source address.
> It is because BID (to match the exact BC) is not stored in the data 
> packets.
> The cost can be O-(n) if 'n' bindings are registered.
> 
> Therefore, HA should verify the address validity with the tunnel states.
> HA can verify the packets with the tunnel states by comparing the source 
> and destination pair.
> The cost can be decreased to O-(1).
> 
> HA MUST check all the packets from MNs, this additional overhead of MCoA 
> is not negligible.
> It might be implementation issue though.

Ryuji, the mobile node uses the home address option for only
the signaling messages that are sent to the home agent. I
don't see that as a lot of traffic that needs an optimization
in terms of source address check. I think we stick to what we
have in RFC 3775 (i.e., the mobile node can either tunnel
or send packets with home address option to the HA). We
should not recommend one over the other in the MCoA draft. I
still think we should delete this paragraph.

Vijay

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Sat, 23 Feb 2008 14:42:31 +0900

Hi Vijay,

On 2008/02/23, at 4:11, Vijay Devarapalli wrote:

>> The lifetime field MUST be set to the appropriate lifetime for that  
>> home state.
>> HA can always treat this BU as de-registration BU because the  
>> source address and home address are same.

The H-flag indicates to HA that MN is at home.
The state is not something link binding cache.
I mean that state is the information of MN existence at the home link.
When MN sends de-registration BU with H flag, HA will start special  
operation for that MN.

> any text to the draft right now.

right.
If HA can detect the MN's existence at the home link without any states,
we don't need this operation.
HA can delete the state as soon as MR leaves the home link.

>> This paragraph is to explain how to avoid the overhead of the  
>> address verification in MCoA.
>> HA might search the BC database recursively to match the CoA and  
>> the source address.
>> HA can verify the packets with the tunnel states by comparing the  
>> source and destination pair.
>> HA MUST check all the packets from MNs, this additional overhead of  
>> MCoA is not negligible.
> the signaling messages that are sent to the home agent.
> I don't see that as a lot of traffic that needs an optimization
> in terms of source address check.

How can you say so?
RFC3775 does support tunneled packets and RO-packets between MN and HA.
If we can fix to use either tunnel or hoa option for data packets in  
RFC3775-bis,
i am fine to remove this text.

> I think we stick to what we

OK. I think we should discuss this possible issue in the 3775-bis  
discussion.
I don't see any strong reasons to have two way to send packets from MN  
to HA.

ryuji

---

From: "George Tsirtsis" <[email-masked]>
Date: Mon, 25 Feb 2008 13:48:35 +0000

Hi Vijay/Ryuji,

Thanks again for revising the document. I have not read the latest
version yet but by looking at your replies I think we are getting
there. A few issues, however, still remain which you indicate in your
e-mails. Would it be possible to summarize these separately so we can
resolve them? Anything we can not resolve on the list we can then
discuss in the IETF meeting; hopefully you have requested a slot for
this?

In the mean time I will also try to go over the new draft.

Thanks again
George

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 25 Feb 2008 14:32:55 -0800

I think, there are three issues we haven't addressed yet.

- Lifetime for the bindings. Should we maintain the lifetime for
each binding separately or do all the bindings have the same
lifetime.

- In the simultaneous home and visited link operation, how does
the HA delete the state about forwarding packets to the mobile
node's home address on the home link? When the does the state
expire. We added some text, but might require further discussion.

- On whether we should consider enhanced RO for this draft. Not
sure if there are any issues.

Ryuji, anything else?

Vijay

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Tue, 26 Feb 2008 10:26:50 +0900

Hi George and Vijay,

Yes, the below three issues must be addressed.
I'll summarize the issues and provide possible solutions per issue.

ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Fri, 22 Feb 2008 11:16:19 +0900

Hi George and Vijay,

I add my comments inline.
I deleted some paragraph which I agreed with George and/or Vijay.

> the comments you made inline in the text, please see below.

<SNIP>

>> GT> Should we also say anything about Enhanced RO based on RFC4866?

I don't have opinion neither.

> The above paragraph, I think, describes how to delete that

As soon as the interface is attached to the home link,
the MN should explicitly delete the previous binding of that interface  
if necessary.

<SNIP>

> Needs to be discussed as part of overall binding lifetime issue.

good point.

>> message including a BID Mobility option. Is this what this is about?

Yes, this was my intention.
This document does not deal with flow distribution (i.e. how to decide  
which CoA is used for data packets).
> along with the home address.

We should not assume any flow distribution scheme in the MCoA.

> text goes into this section.

I will clarify that the BID is used as a key only for signaling.

OK
<SNIP>
> then create new bindings.

My answer is that the mobile node creates two bindings for the same CoA.
The HA/CN uses the HoA and BID as the search key.

If MN want to renew the BID value, it should de-register the older one
and register a new binding with a new BID value.

> Tied to the lifetime issue again.

HA/CN should send BRR with all the BID options only if the bulk  
registration is used by MN.
The same lifetime is used only in the bulk registration.
If MN uses separate BUs, the binding lifetime can be managed  
independently.

thanks
ryuji

_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Benjamin Lim" <[email-masked]>
Date: Thu, 28 Feb 2008 22:47:35 +0800

Hi Ryuji,

Pls see inline. 

=8==8<=8==
> >> flag set. If the MN has to send a de-reg to the HA with Lifetime=0 
> >> and 'H' set, for how ling is this state valid? What happens to the 
> We should treat the lifetime of  that home state and the 
> other real bindings separately.
> 
> When the MN sends a BU with H flag set, it should not use 
> bulk registration and send it as an individual BU.
> The lifetime field MUST be set to the appropriate lifetime 
> for that home state.
[Ben] You are giving a lifetime to home state. Can it now called home
binding? If so, why should it be treated differently from other bindings?
Furthermore, you mention below that MN must renew this 'home state', isn't
this like renewing normal bindings? If this is so, I cannot see why bulk
registration cannot be used. The only reason I see bulk reg not use
previously is because of lifetime == 0 and if bulk reg is use, this implies
all CoAs specified in the BU will have lifetime == 0. But now, since you
assign a lifetime to 'home state', then what is the reason of restricting
bulk reg?

Regards,
Benjamin Lim

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Fri, 29 Feb 2008 22:56:36 +0900

Hi Benjamin,

> Pls see inline.

The above text is my personal answer to George.
The latest document does not use home binding and
does not treat this state as a binding (home binding).

> this like renewing normal bindings? If this is so, I cannot see why  

The question should be that "do we really need to treat this state as  
a binding?"
My first thought is NO. This is too much, because the home agent can  
always
detects the MN's existence at the home link.
Since the MN sends a deregistration BU to the home agent,
home agent can records the mac address or wireless association, etc.
(i.e. any mechanism to detect the node availability at the link).

Do we really need to control this state at L3 ?

> assign a lifetime to 'home state', then what is the reason of  

Right, if we use the lifetime for home binding, we can use the bulk  
registration.

regards,
ryuji

ps. Mobicom08 and Mobiarch08 CFP are attached below!!!!

-------------------------------------------------------------------------
                        CALL FOR PAPERS

                           MobiCom 2008
            The Fourteenth Annual International Conference
                on Mobile Computing and Networking

                        September 14-19, 2007
             	   San Francisco Bay Area, CA, USA
              http://www.sigmobile.org/mobicom/2008/
                    Sponsored by ACM SIGMOBILE
-------------------------------------------------------------------------
ACM MobiCom is the premier international conference dedicated to
addressing the challenges in the areas of mobile computing and
wireless and mobile networking.  It has served as an exciting
international forum since 1995, addressing networks, systems,
algorithms, and applications that support the symbiosis of mobile
computers and wireless networks. This year, we will continue
this tradition, but we especially encourage the submission of papers
in the experimental systems area.  This area has seen exciting
developments in recent years and explicit efforts will be taken to
represent it strongly at MobiCom this year.

Authors are invited to submit full papers, challenges papers, student
posters, and research demos and exhibits, presenting new research
related to the theory or practice of mobile computing and/or wireless
and mobile networking. All submissions must describe original research,
not published or currently under review for another conference or
journal. Areas of interest include, but are not limited to:

  * Operating system and middleware support for mobile computing and
    networking
  * Architectures, protocols, and algorithms to cope with mobility,
    limited bandwidth, limited power and/or intermittent connectivity
  * Fundamental understanding of mobile computing and wireless  
networking
  * Wireless and mobile techniques for delay tolerant, mobile ad hoc,
    and wireless sensor networks
  * Security, privacy, and trustworthiness of mobile and wireless  
systems
  * Wireless access technologies (e.g. mesh systems, PANs)
  * Integration and interworking of wired and wireless networks
  * Protocols exploiting novel technologies such as UWB, MIMO,
    directional antennas, and software radios
  * Techniques for dynamic spectrum use
  * Architectures, algorithms and protocols for cognitive wireless
    networks and their integration in the Internet
  * Modeling, measurement and simulation of mobile networks
  * Experimental test-beds for mobile/wireless networks
  * Performance evaluation of mobile and wireless networks, protocols,
    and systems
  * Next generation (beyond 802.11) wireless technologies and related
    systems and protocols

Submission Instructions
Detailed instructions on how and where to submit your paper can be
found at http://www.sigmobile.org/mobicom/2008/cfp.pdf

IMPORTANT DATES:
Abstracts submission due: March 7, 2008
Paper submission due: March 14, 2008
Notification of acceptance: June 19, 2008
Camera-ready version due: July 7, 2008

General Chair - [email-masked]:
J.J. Garcia-Luna-Aceves, UC Santa Cruz and PARC

Technical Co-Chairs - [email-masked]:
Raghupathy (Siva) Sivakumar, Georgia Tech
Peter Steenkiste, Carnegie Mellon University

FOR MORE INFORMATION: Please contact the General Chair or Program
Co-Chairs for more information.  For information on ACM SIGMOBILE and  
the
MobiCom series of conferences, see http://www.sigmobile.org/ or contact
[email-masked].

-------------------------------------------------------------------------
                          CALL FOR PAPERS

                         ACM MobiArch 2008
                   An ACM SIGCOMM 2008 Workshop
                 Seattle, WA, USA, August 22, 2008

               The 3rd ACM International Workshop on
           Mobility in the Evolving Internet Architecture
              Paper registration deadline: March 17, 2008
-------------------------------------------------------------------------

       http://www.sigcomm.org/sigcomm2008/workshops/mobiarch/

Recent developments in wireless access technologies and mobile devices
are beginning to make widespread user, terminal and network mobility a
reality in the commercial Internet. At the same time, the Internet
architecture struggles to incorporate the functionality that will  
sustain
this increasingly more mobile and more dynamic Internet use. Efficient
mobility management and mobility optimizations, locator-identifier
splits, multihoming, security and related network operation and
management functions are still in the early stages of development. It  
is,
however, already clear that supporting widespread mobility poses to
significantly impact the original end-to-end design of the Internet.

At the same time, critical momentum is building to significantly revise
or even replace the current Internet architecture. Several substantial
Future Internet initiatives have started in Europe, the US and Asia, and
the topic is also actively being discussed in the vendor and network
operator communities. These Future Internet efforts offer the exciting
opportunity to design radically different approaches to supporting host
and network mobility and multihoming, and may eventually lead to an
internetwork architecture with significantly more advanced mobility
features than those that the piecemeal extensions of the current  
Internet
protocols result in.

MobiArch'08 welcomes submissions from both researchers and practitioners
that explore recent advances in architectures, protocols and emerging
technologies to enable mobility and multihoming in the Internet, as well
as concepts and designs to support widespread mobility and multihoming  
in
future internetworks.  Early results, position papers, systems and
measurement papers are particularly welcome.

TOPICS
MobiArch'08 covers all aspects related to mobility in the current and
future Internet, including, but not limited to:

  * Architectures and protocols for mobility support at all layers
    of the Internet protocol stack, as well as cross-layer approaches
  * Novel concepts to support widespread mobility and multihoming
    in a Future Internet
  * Routing and addressing issues (including locator/identifier
    splits) and their impact on the Internet architecture
  * Multihoming, including flow distribution and load-sharing for
    wireless and mobility
  * Performance evaluation, experimentation and modeling of
    Internet mobility
  * Models for mobility patterns and their experimental validation
  * New wireless technologies and services and their impact on the
    Internet architecture
  * Location management, positioning and data management for
    wireless and mobility
  * Accounting, access control, security and privacy issues and
    their impact on the Internet architecture
  * Social, economic, scalability and deployment issues

SUBMISSION GUIDELINES
Submissions must be no longer than six pages, including all figures and
references, must be in PDF format, and must follow the ACM formatting
guidelines (http://www.acm.org/sigs/publications/proceedings-templates).
Submissions that do not adhere to these requirements will be rejected
without further review.
Peer review is single-blind; the authors names and affiliations are to  
be
included on the submission. Submissions cannot be previously published  
or
be under concurrent review elsewhere. The submission of position papers
is encouraged; please clearly identify position papers as such when
submitting.
Papers may be submitted at http://edas.info/newPaper.php?c=6140

IMPORTANT DATES
  March 17, 2008        Registration of paper abstract
  March 24, 2008        Submissions due
  May 1, 2008           Notification of acceptance
  June 9, 2008          Camera ready version due
  August 22, 2008       Workshop date

TECHNICAL PROGRAM COMMITTEE
  Lars Eggert           (co-chair, Nokia Research Center, FI)
  Linda Doyle           (co-chair, Trinity College, IE)
  Rui Aguiar            (Universidade de Aveiro, PT)
  Bengt Ahlgren         (Swedish Institute of Computer Science, SE)
  Jari Arkko            (Ericsson, FI)
  Marcelo Bagnulo       (University Carlos III of Madrid, ES)
  Olivier Bonaventure   (Université Catholique de Louvain, BE)
  Wesley Eddy           (NASA/Verizon (US)
  Joseph Evans          (University of Kansas, US)
  Ted Faber             (USC Information Sciences Institute, US)
  Stephen Hailes        (University College London, UK)
  Roger Karrer          (T-Labs, DE)
  Rajeev Koodli         (Nokia Research Center, US)
  Donal O'Mahony        (Trinity College, IE)
  Jörg Ott              (Helsinki University of Technology, FI)
  Guru Parulkar         (Stanford University, US)
  Dipankar Raychaudhuri (Rutgers University, US)
  Dave Thaler           (Microsoft, US)
  Ryuji Wakikawa        (Keio University, JP)
  Klaus Wehrle          (RWTH Aachen University, DE)
  Lixia Zhang           (UCLA, US)