Subject: RE: [Mobike] Zero Address Set

From: Tschofenig Hannes <[email-masked]>
Date: Wed, 8 Dec 2004 11:33:35 +0100

hi jari, 

i am not sure that there is sufficient interest for this functionality. i am
still not quite sure that we properly understand this issue. i again thought
about it and think that technically we need to provide two things: 

- temporarily suspend dead peer detection (or path connectivity test) 
- drop traffic (since it cannot be delivered to the end host anyway) 

ciao
hannes

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Montag, 06. Dezember 2004 22:00
> To: Bill Sommerfeld; Tschofenig Hannes
> Cc: [email-masked]
> Subject: Re: [Mobike] Zero Address Set
> 
> I guess the key question here is whether there's enough "bang 
> for the buck" in this function for it to be included in 
> MOBIKE. Earlier we didn't see that many people interested, 
> but now we have some. In any case, we need to consider the following:
> 
> - The benefit this feature offers is about "being
>    a good citizen" (as you Bill put it) and not send
>    unnecessary packets when we know the other end
>    is down. Nevertheless, this is not a functional
>    benefit in the sense that nothing breaks if we
>    don't have it; just that extra packets are sent.
> 
> - We know we can not use this feature in all cases
>    when the other end is down. We don't always know
>    we are going outside coverage.
> 
> - We know there's some practical limits to how long
>    this condition can be held and still be considered
>    useful, such as applications on top starting to
>    get timeouts.
> 
> - There may be some additional complexity for MOBIKE.
>    For instance, assume A and B are talking to each other
>    and that A now informs B that its offline. Now,
>    normally in MOBIKE if B moves it can tell A immediately.
>    But if zero-address set is supported then B must
>    be able to queue this notification. And if all of
>    B's addresses got changed, the situation is not
>    recoverable.
> 
> --Jari
> 
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Jari Arkko <[email-masked]>
Date: Wed, 08 Dec 2004 12:42:32 +0200

> i am not sure that there is sufficient interest for this functionality. i am

I have the same doubt.

> - drop traffic (since it cannot be delivered to the end host anyway) 

These two and you also need to signal that it should be turned
on. I'm not too worried that we understand the basic scheme
here, but I'm more worried about how this interacts in more
complicated scenarios and with other features.

You could also see this function as orthogonal to MOBIKE, i.e.,
another IKEv2 feature that can be used to temporarily suspend
all IKE and payload packet flows.

--Jari

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 8 Dec 2004 14:18:07 +0200

> all IKE and payload packet flows.

As the device will quite likely have different IP-address etc when it
reconnects, it would not help that much in the base IKEv2. It is only
really useful with MOBIKE.
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 08 Dec 2004 23:19:26 -0500

> all IKE and payload packet flows.

I think the on-the-wire protocol representation falls out automatically
from whatever mobike-defined IKE extension is used to add or delete
addresses from the established IKE SA.

end systems which don't implement this would treat this as a tunnel
tear-down request.

end systems which do implement it would "cap" the tunnel until the peer
resumed, some implementation-specific timer expired, or administrative
action deleted the tunnel.

an end system implementing this would need to be able to cope with lost
state on the peer anyway.

							- Bill