mesh portal discovery

[John Gilmore]

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

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.

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.

	John Gilmore