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

Jari Arkko wrote:
> 
> 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, 

it should be outside the scope of MOBIKE protocol.

Vijay

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
>>
>>
> 
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike