[Mobike] New issue 16: No packets from other end?
vijayd at iprg.nokia.com
Wed Sep 8 15:31:03 EDT 2004
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.
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.
>> 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
>> Best regards,
>> Mobike mailing list
>> Mobike at machshav.com
> Mobike mailing list
> Mobike at machshav.com
More information about the Mobike