Re: New issue 16: No packets from other end?

This is a good summary, thanks Pasi.

I would add that in some cases we have also option 4:
wait until the local knowledge gets a chance to
be updated. For instance, even standard (not
RFC 3775 or DNA WG-enhanced) IPv6 neighbor discovery
will eventually detect a movement, even if this can
be slow. This also makes a feature interaction
possible where MOBIKE decides to do something (e.g.,
move to GPRS) while in fact we were still in the
DNA process and were going to tell MOBIKE to do
something else (e.g., move to this new local LAN
link).

But I personally would also like option 2, as long
as we also assume basic local link movement detection
from a non-MOBIKE mechanism.

Seems like most people want to rely on some sort of
standard movement detection process outside MOBIKE
(= the local knowledge). Question: how are we going
to specify this, just as an assumption that its outside
the MOBIKE protocol, or as a hard requirement to do
<something>? It seems that the former is the only
option, given that movement detection is somewhat of
a moving target (no pun intended). IPv4 and IPv6 have
different capabilities, several enhancements are being
worked in different places (MIP6/DHCP/DNA WGs), etc.

--Jari

> Those are the things Jari called "local knowledge": 
> something in the mobile node knows what should be done
> ("switch to this address"), based on information
> that's "local" in the sense that it's not a result
> of an end-to-end protocol between the IKEv2 nodes.
> 
> I don't think there's any disagreement about handling those: 
> we just assume that there's "something" in the mobile node 
> that triggers appropriate MOBIKE messages to be sent.
> 
> But issue 16 is more about what to do if we know there 
> is a problem (==we don't receive any replies to our IKE 
> requests, even after retransmissions), but we don't know 
> what address change would correct the situation (because
> the "local knowlege" is either not reliable enough,
> or the failure is in the "middle" where local knowledge
> does not reach).
> 
> Here the options seem to be: (1) fail, (2) send some 
> IKEv2 message(s), either new ones or the one we were 
> retransmitting, along some other path, and use information
> about their delivery to help deciding what should
> be done, or (3) send some non-IKEv2 message(s) along 
> some other path.
> 
> Now, option 1 would be the right choice only if we 
> assume that the "local knowledge" is reliable enough, 
> and we do not care about non-local failures. (Is this
> the choice you prefer?)
> 
> Option 3 means we don't have interoperability unless the
> nodes also agree what that non-IKEv2 end-to-end (between
> IKEv2 peers) protocol is. 
> 
> So my opinion is strongly something like option 2: if 
> we don't receive replies to our IKEv2 request(s), try 
> sending them along some other path (unless the current 
> path is the only one acceptable to us, of course).
> 
> Best regards,
> Pasi
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike
> 
>