mesh portal discovery

[david at lang.hm]

On Thu, 10 Jan 2008, John Gilmore wrote:

>>> IP addresses are going to change; that's a fact of life.
>
>> I know nothing about routing, but if a participant's IP address is about to
>> change, perhaps the change should be broadcast over the network, so that
>> Telepathy knows who to handoff the connection to.
>
> To re-ground this discussion, if two mesh portals appear on the
> network, at different IP addresses, a laptop can continue to use the
> old one for its existing connections, yet switch its primary address
> to a new ("better") one for new connections.

why is it that the laptop needs to switch IP addresses?

is it that the new portal won't talk to the old IP address?

or is it that outbound traffic could go out either portal, but inbound 
traffic would still go to the old portal and make more hops over the radio 
then is nessasary?

or something else?

> IPv6 includes host-based tools for making IP address changes easier.
> In particular, it requires the kernel to be able to process several
> global IP addresses for a given hardware interface.  The latest is
> marked "preferred", the rest are marked "deprecated".  When creating
> new connections, it normally uses the preferred address.  But
> communication over all of the addresses continues to work (as long
> as the network outside the kernel has connectivity at that address).
>
> Linux implements all of this for IPv6.  I don't know if the Linux kernel
> can do the same for IPv4, but it would be a natural extension.
>
> Some applications care what IP address they are using; bind (DNS) in
> particular watches for interfaces to go up or down, or to change.  If
> Telepathy wants to do the same, yet there is no low-overhead way to do
> it, then another natural extension would be to extend inotify (or raw
> sockets, or some other kernel mechanism) to report such changes.
> This would avoid polling for them.

but is it really the right thing to try and do this on the laptops (in the 
OS and all the software), or should we do it in the portal boxes instead?

> As long as the previous mesh portal continues to work for a short
> while, there should be no need for nonstandard mechanisms to "let
> applications know that the IP address is *about* to change".  Instead
> they will naturally find out after it *does* change.

this gets back to my question about exactly why the change is a problem.

David Lang