Re: [MEXT] Review of draft-ietf-monami6-multiplecoa-13 + Proposals

[[e-mail] (Arnaud Ebalard)]

Hi Vijay,

Vijay Devarapalli <[e-mail]> writes:

> Arnaud Ebalard wrote:
>
>> The last point regarding the reuse of K bit was still open so I took a
>> new look at what is in the draft. I'd like to clarify the expected
>> behavior for the common case.
>>
>> The idea developed in section 9.1 of the draft is that the MN sends a
>> BU with K bit set *and* a single BID mobility option to update the CoA
>> which must be used by IKE. The HA receiving that BU will inform the IKE
>> daemon on its side with the CoA with the BID. 
>>
>> The thing is that if the IKE module on the MN supports movement, K bit
>> will be set in all BU. It would not make sense ("MCoA keeps backward
>> compatible with 3775") but it is probably worth asking the question
>> before going further: does MCoA draft change that behavior?
>
> With MCoA draft, the 'K' bit is set in a BU only if there is a change
> in the "primary CoA", i.e., the CoA with which the IKEv2 SA was
> created. All other BUs sent by the mobile node can have the 'K' bit
> unset.

At least, this clarifies the expectations of MCoA draft on the
topic. IMHO, this would have been better to state that explicitly but
considering previous discussions, I guess it is too late now :-b

> Even in RFC 3775, a mobile node can clear the 'K' bit in a BU sent for
> a binding refresh when there is no change in CoA. When the CoA
> changes, the MN can set the 'K' bit in the BU sent to update the CoA.

Rereading Section 10.3.1 of RFC 3775, the binding refresh case when
there is no change of CoA does not exist. As usual, the content of a new
BU basically replace the content of the previous one in the BCE. In
section 10.3.1, the processing performed by the HA is done *only* based
on the value of the K bit it sets *in its BA* (section 10.3.1). When the
K bit is 0, the action is to "discard the key management connections, if
any, to the old care-of address" (the one in the BCE).

What I say is that an implementation which *strictly* follows what is in
section 10.3.1 will just discard the key management connections to the
old CoA.

Nonetheless, I think what you describe is valid and it makes sense to
consider that *in all cases* implementations specifically handle the
binding refresh with no change of CoA (and not even look at K bit value
in that specific case).

Thanks for your thoughts,

Cheers,

a+