Hi Jari
Thanks for comments.
Please see my comments inline.
On 2006/10/27, at 22:27, Jari Arkko wrote:
> 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.
OK.
>> 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.
Yes.
>
>> 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.
This is just an example usage of MCoA.
We assume some other mechanism to detect failure.
> 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?
This is good point.
We basically allow single binding entry with BID.
> What is the means to delete binding entries
> 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.
> 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?
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.
>> 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?
I am not sure about a).
When multiple bindings are registered, MN can use both of
binding
simultaneously. (Not necessary always to use both)
>> 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.
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.
>
>> 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.
This can be solved by setting A flag in BU.
In BA, MCoA expects to carry a MCoA option in BA.
>> 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.
right. will remove this.
>> 8. IPsec and IKE interaction
>>
>> TBA
>>
> Some more work needed here.
We are working on this with Vijay.
>> 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?
This is wording problem. We will fix this.
We want to say that "Multiple home addresses assigned
to a node".
>
>> 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.
If old Care-of/Home keygen are valid, MN can skip those.
> 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.
WG have decided not to support bulk registration for CNs.
regards,
ryuji
> --Jari
>
>
> _______________________________________________
> Monami6 mailing list
> Monami6 ietf.org
> https:
//www1.ietf.org/mailman/listinfo/monami6
_______________________________________________
Monami6 mailing list
Monami6ietf.org
https:
//www1.ietf.org/mailman/listinfo/monami6
|