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

[arno at natisbad.org (Arnaud Ebalard)]

Hi,

Vijay Devarapalli <vijay at wichorus.com> writes:

> Arnaud Ebalard wrote:
>
>>> 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. 
>
> No. The mobile node would send a BU to refresh an existing binding if
> the lifetime is about to expire, even if there is no change in
> CoA. Maybe this is not explicitly pointed out in section
> 10.3.1. Section 11.7.1 says
>
>    Also, if the mobile node wants the services of the home agent beyond
>    the current registration period, the mobile node should send a new
>    Binding Update to it well before the expiration of this period, even
>    if it is not changing its primary care-of address.

Sorry, I meant "the specific 'K' bit processing you describe for a
refresh w/o CoA change" does not exist. The processing (including K bit
one) is described for all kinds of BU, no matter if they create or
refresh a binding.

I obviously did not mean binding refresh is not defined. 

>> 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).
>
> So I am going to conclude that there is no need for any change in the
> MCoA document on this issue.

Right.

Cheers,

a+