Subject: [Monami6] some comments on draft-ietf-monami6-multiplecoa-00.txt

From: Jari Arkko <[email-masked]>
Date: Fri, 27 Oct 2006 16:27:07 +0300

This is not a full review, but as I browsed through the
document I wanted to post some of the observations
that I had:

Introduction -- In general, I got the feeling that
less text here would be better. Leave the motivation
to the other documents. For instance, I'd delete:

  For example, TCP
  traffic should be transmitted over the wireless interface, whereas
  UDP traffic should be transmitted over the wired interface to avoid
  disturbing TCP connections.

     Unfortunately, there is no network interfaces
     assuring global scale connectivity.

> When the Home Agent
>    checks the binding cache database for the mobile node, it searches a
>    corresponding binding entry with the Home Address and BID of the
>    desired binding.
Presumably this applies to correspondent nodes as well.

>    If a node has multiple bindings and its packets meant for the mobile
>    node are not delivered correctly, the node can change the binding
>    entry for the mobile node so as to recover the connection
>    immediately.  The node can detect a binding invalidation by packets
>    loss or ICMP error messages such as ICMP_UNREACHABLE.  This provides
>    redundancy for Mobile IPv6.
>   
Handwaving. What does "not delivered correctly" mean? Who tracks
this and how? Is upper layer protocol feedback involved? What if
there is no current ULP traffic? Will you always believe an ICMP
error, or attempt some sort of verification.

See also draft-ietf-shim6-failure-detection.

>    If the mobile node decides to register only single binding, it just
>    sends a Binding Update without a Binding Unique Identifier sub-option
>    (i.e. normal Binding Update).  The receiver of the Binding Update
>    registers only a single binding for the mobile node.  If the receiver
>    has multiple bindings, one binding is registered without BID and the
>    rest of bindings are deleted.
>   
How does this work in the (rather likely) situation
where you have one interface always up, and now
and then can use another one? Will the mobile
node revert back to legacy BUs when it only
has one interface, or are you allowing a single
BID as well?

What is the means to delete binding entries
when multiple BIDs exist? What if the mobile
node reboots and forgets the BIDs it had --
does it have to send a legacy BU first to make
sure all binding entries are deleted? Even
if it is in a situation where it actually wants
to set up two?
>    Priority
>
>       MUST be set if the priority field of a Binding Unique Identifier
>       is valid.
>   
How much do you want to specify about priorities
or lack thereof? Wouldn't the real benefit from
multiple registrations come from either (a) having
a mechanism to know which registration actually
works currently and/or (b) flow specifications that
map to registrations?
>    Removable (R) flag: TBD
>
>       When this flag is set, a mobile node request a Home Agent to
>       remove the binding correspondent to BID, even if the binding
>       update is not for de-registration.  This flag is valid only when
>       bulk registration is used (C flag is set).  This option may be
>       obsolete in the future revision.
>   
Seems complicated. Do not optimize prematurely.

>    A Correspondent Node basically learns the BID when it receives a
>    Binding Unique Identifier sub-option.  At the time, the Correspondent
>    Node MUST look up its binding cache database with the Home Address
>    and the BID retrieved from Binding Update.  If the Correspondent Node
>    does not know the BID, it searches for a binding with only a Home
>    Address as performed in Mobile IPv6.  In such case, the first matched
>    binding is found.  But which binding entry is returned for the normal
>    search depends on implementations.  If the Correspondent Node does
>    not desire to use multiple bindings for a mobile node, it can simply
>    ignore the BID.
>   
Is there a mechanism to know if the correspondent supports
this extension? If I have a very good interface/address and
a backup very bad interface/address, I probably want to know
if the correspondent supports this extension. If it just
ignores the extension, I may end up registering the
wrong interface/address.

>    When a Correspondent Node sends a Binding Error with Status field set
>    to 2 (Unrecognized MH Type value), it MAY put a Binding Unique
>    Identifier sub-option into Mobility Options field if BID is available
>    in a received binding message.
>   
If the MH type of the received message is unknown, there is
no possibility for the receiver to see a BID.

> 8.  IPsec and IKE interaction
>
>    TBA
>   
Some more work needed here.

> But assigning a single Home Address to a given
>    network interface is more advantageous than assigning multiple Home
>    Addresses because applications do not need to be aware of the
>    multiplicity of Home Addresses. 
Home addresses assigned to an interface?

>    If the mobile node wishes to register its binding with a
>    Correspondent Node, it MUST start return routability operations
>    before sending a Binding Update.  The mobile node MUST sends CoTI for
>    each Care-of Addresses and MUST receive CoT for each Care-of
>    Addresses.  The mobile node also uses a BID generated for the home
>    registration to register them as individual bindings. 
It appears unnecessary to start *all* RR operations
before sending *any* BU. Or are you planning to
bind the different addresses together somehow?
I'm not sure that is necessary.

Also, I don't see the above changing at all the rules in
RFC 3775 -- do not respecify if there's no change.
>  The
>    registration step is the same as for the home registration except for
>    calculating authenticator by using Binding Unique Identifier sub-
>    option as well as the other sub-options specified in RFC 3775.  Since
>    return routability cannot be verified with multiple care-of addresses
>    in a binding update, bulk registration is not supported with
>    Correspondent Nodes in this document.
>   
If you really wanted, you *could* design a scheme which
allows you to carry all the required care-of tokens and
the one home token, and define the way that the
MAC needs to be calculated. Probably not worth it.

--Jari

_______________________________________________
Monami6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/monami6

---

From: Vijay Devarapalli <[email-masked]>
Date: Sat, 28 Oct 2006 13:13:23 -0700

> Some more work needed here.

my fault here. I was supposed to provide some
text for this section. I had presented a bunch
of scenarios at IETF 64. I need to write up some
text for these scenarios.

Vijay

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Tue, 31 Oct 2006 23:44:46 +0900

Hi Jari

Thanks for comments.
Please see my comments inline.

>      assuring global scale connectivity.

OK.

> Presumably this applies to correspondent nodes as well.

Yes.

> error, or attempt some sort of verification.

This is just an example usage of MCoA.
We assume some other mechanism to detect failure.

> has one interface, or are you allowing a single

This is good point.
We basically allow single binding entry with BID.

> when multiple BIDs exist? What if the mobile

If a normal BU is arrived, the receiver should process this BU as  
regular processing of RFC3775.
No more multiple bindings, but only single binding must be kept in BC.

> if it is in a situation where it actually wants

Ideally, MN should check the availability of old bindings.

However, RFC3775 does not specify when the MN crashed and boots up.
MN does not need to check the old bindings, but it simply overwrite  
the old binding by sending BU.
However, there is no way to know the old binding of CNs, unless it  
sends a BU to CN or it waits for BC expiration at CN.

One way to avoid this scenario is that MN must sends the first BU  
with MCoA options in bulk registration mode.
In bulk registration mode, the HA can replace the old bindings with  
the new bindings.
For correspondent node, the MN still need to wait to expire the old  
bindings.

> works currently and/or (b) flow specifications that

I am not sure about a).
When multiple bindings are registered, MN can use both of binding  
simultaneously. (Not necessary always to use both)

> Seems complicated. Do not optimize prematurely.

In bulk registration, multiple CoAs are updated by a single BU.
There is the request from WG that removing a CoA can be piggybacked  
to a home registration BU.
MN does not need to send two BU: one for CoA registration and another  
for de-registration.

> ignores the extension, I may end up registering the

This can be solved by setting A flag in BU.
In BA, MCoA expects to carry a MCoA option in BA.

> no possibility for the receiver to see a BID.

right. will remove this.

> Some more work needed here.

We are working on this with Vijay.

> Home addresses assigned to an interface?

This is wording problem. We will fix this.
We want to say that "Multiple home addresses assigned to a node".

> I'm not sure that is necessary.

If old Care-of/Home keygen are valid, MN can skip those.

> MAC needs to be calculated. Probably not worth it.

WG have decided not to support bulk registration for CNs.

regards,
ryuji