[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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