mesh portal discovery

[Dan Williams]

On Thu, 2008-01-10 at 14:00 -0800, david at lang.hm wrote:
> 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?

Because there are a finite number of IPv4 addresses.  Assume there are
two mesh portals, P1 and P2.  Your XO can't see P2 yet.  Your XO
connects to the internet through P1, and gets address A1.  Suddenly, P1
goes away, or you walk out of range of P1.  Your laptop starts the
discovery process and finds P2.

What guarantee is there that P2 has not given address A1 to some other
XO already?  What happens if you now have an IP address conflict?  P2
already has NAT tables that map address A1 to some other XO that's not
your XO, and you can't find P1 any more, so you can only tear down the
old IP address and try to acquire a new one.

This doesn't get any better with autoip v4, because you still have
address conflicts with autoip v4, and when you have a conflict (somebody
walked into range of your little mesh cloud) _somebody_ has to give up
the IP address and get another one.

When you mix mobility with IPv4 without infrastructure, you simply
cannot hold IP addresses over the long term.  And the whole point of the
XO is to _not_ build up lots of infrastructure.

Dan

> 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
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel