Subject: RE: [Mip6] [issue68] The use of K bit

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 6 Mar 2006 18:08:49 -0800

Hi Francis, 

Please see comments below.  

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, March 06, 2006 12:09 PM
> To: Narayanan, Vidya
> Cc: Vijay Devarapallli; Mip6 issue tracker; [email-masked]
> Subject: Re: [Mip6] [issue68] The use of K bit 
> 
>  In your previous mail you wrote:
> 
>    In general, having the K bit makes sense to me. Is there 
> any reason why
>    MOBIKE would be precluded by the presence of the K bit?
> 
> => I don't think so: we can't get two signalings for the same 
> thing, i.e., we have to run either MOBIKE or MIP6, but *not* 
> both at the same time.
> 

I am concerned about precluding MOBIKE in the presence of MIP6. Note
that you should not get two signalings for the same thing. If MOBIKE and
MIP6 are both used, the MN would have to update the IKEv2 SA endpoint
using MOBIKE first and then send a BU with K=0. Actually, if K is set to
1 here, there will be nothing to udpate - since MOBIKE already updated
the SA, MIP6 won't find an SA tied to the old CoA. 

We could also achieve this by removing the K bit and saying that MOBIKE
must be used if the IKEv2 SA endpoint needs to be updated. But, I don't
really like this - since this implies that an MN must support MOBIKE in
order to prevent re-establishment of the IKE SA upon every move. 

>    I would think that the K bit can be set to 0 to use MOBIKE with
>    MIP6 if someone wants to do that.
> 
> => this doesn't make sense.
> 

In light of the explanation above, why doesn't this make sense? 

The use of MOBIKE simply to update the IKEv2 SA associated with MIP6
does not make sense. However, there are potentially other uses of MOBIKE
that we should not prevent here. 

Vidya

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