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

[Vijay Devarapalli <[e-mail]>]

Hi Arnaud,

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.

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.

> Now, let's consider a MN whose IKE module supports movement (its HA
> too). It will have K-bit set in all its BU. Let's say the MN currently 
> has two CoA on different interfaces: CoA1 and CoA2 registered with its
> HA. Each one is associated with a given BID. Let's consider CoA1 is
> currently used for IKE traffic to the HA. Now, due to a handover, the MN
> configures a new address instead of CoA2. CoA1 had not been modified so
> the MN does not have to request an update of IKE address to the HA. But
> the MN needs to warn its HA about the address change. It cannot send a
> BU with K bit set and only the BID mobility option with the updated CoA2
> value. How is this handled?

It would send a BU with the 'K' bit unset, CoA2 information and the BID 
associated with CoA2. It can also include CoA1 information and the BID 
associated with CoA1 in the BU.

 From the beginning our goal was to avoid creating a new mechanism to 
update the care-of address information in the IKEv2 and IPsec SAs. We 
are trying to re-use what is there in RFC 3775.

Vijay