Re: Comments to draft-ietf-mobike-protocol-00.txt

  
  > 
> If it was original responder who was initiating the IKE
> exchange, it does NOT do any updates itself, it simply assumes
> that original initiator seeing IKE packets coming from
> different address pair than current one is, initiates a DPD
> test itself to verify weather the operational address pair is
> working, and after that will fall back to another address
>
As the responder does not know whether there is a NAT
 in this new path, he can only hope that it works. 

> pairs, and result update to the operational address pair in
> initiator, it will then send N(CHANGE_PATH) notify to update
> the operational address pair.
> 
 > 
> In case NAT-T is enabled then implemenations MUST make sure
> that initiator does DPD in a way that will take care of the
> updating the other peers addresses in case the NAT mapping is
> lost. This means that when initiator who is behind NAT start
> DPD because of the lack of packets from the other peer, he

This step is confusing to me. I may want to test a new path
even when the current path is working. The usage of word
"DPD" is confusing here. The intiator just sends a message that
looks like DPD (we need to invent a better name for MOBIKE)
with new addresses.


> includes the N(CHANGE_PATH) to the exchange too, to make sure
> that the other peer will update its mapping. If it does not

Don't you have to first detect NAT in the new path ? The other end updates
only if the initiator is behind NAT.  As there are multiple paths and only
some paths may be behind a NAT, the initiator can update only if a NAT
was detected on this new path ?

So, i should be able to test new PATHs with NAT-D payloads without
using CHANGE_PATH message also ?

-mohan


> get reply back using operational address pair, it tries other
> address pairs, and if it does get reply back it does normal
> operation, i.e. restarts the N(CHANGE_PATH) for that new
> operational address pair.
>