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

 Jari,

> > 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.)

It looks like the options are not very good :-) If we choose (1) then we
end up doing what MULTI6 (or something else) within MOBIKE. If we
choose (2), we don't know who will provide the information to MOBIKE.
Perhaps, option (1) seems to make more sense in the immediate term as
there is no other protocol or effort going on now.

-mohan

> 
> --Jari
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike