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

Vijay Devarapalli wrote:

> I am not sure how you can do that. what if the application
> prefers "failing" to using an expensive link?
> 
> for example, lets assume my mobile device has a low bandwidth
> GPRS link (address IP1 on that link) and a high bandwidth WLAN
> link (address IP2 on that link). I have set it up so that my
> email is downloaded only when I connect to my Enterprise
> through a VPN connection when I have the WLAN link. if the
> WLAN link is not available, I dont want the email client to
> download email. lets assume I am in the middle of downloading
> email. I lose WLAN coverage. with your proposal, the MOBIKE
> protocol switches to using IP1. I dont want that.

I agree with your scenario.

> IMHO, I prefer "something in the Mobile Node" telling MOBIKE,
> "switch to using this address with this VPN GW". then a MOBIKE
> update should be sent. this is the model I had in my mind.
> 
> for "something in the Mobile Node" I had assumed DNA, MIP6,
> Multi6, new address configuration, default router change, etc...

I believe there's two levels of issue involved here. On
the first level, I think we have consensus that "something
in the mobile node" should be able to tell MOBIKE that
there's a new address or that a particular interface and
its addresses are no longer usable because the router went
down. I also think that we have consensus that at least most
of this is outside MOBIKE protocol and WG scope. They are
better handled in IPv6/DNA/DHC/MIP6 WGs. Finally, I believe
your policy issue about which interface should be used
is also at this level. And like I said, I agree with your
requirement that it should be possible to express such
policies. I think the others will agree too.

However, that's the part that the rest of the stack is
telling MOBIKE. The second level is what happens after
MOBIKE has been told something. For instance, lets say
that it has been told that there's two usable addresses
at this end and one at the other end; that's two possible
address pairs. Now we get a problem -- ESP tells IKE
that there's no packets, IKE attempts DPD which fails.
There's no information coming from IPv6/DNA/DHC/MIP6
(and presumably there will not be any information coming
soon either, because the DPD process took a while).
Now what? Are people saying that

   (1) Its okay for the MOBIKE peers to attempt recovery
       at the MOBIKE level by switching to another address
       pair.

   (2) Its not okay. MOBIKE/IKEv2/IPsec should fail and
       wait for the rest of the stack to inform when there's
       again an operational address.

       If problems on the path need to be handled, this would
       imply the development of a new, separate protocol for
       testing paths. Note that ICMP/TCP/app may already have
       told us of a problem with the current communications just
       as DPD did. But what we need is finding _another_ pair
       that works. No protocol that I know does that right now.
       Most of what we have in IPv6/DNA etc is focused on local
       issues, such as availability of the router.

(Assuming the "first level" is handled as explained earlier --
outside MOBIKE -- my personal preference would be #1.)

--Jari