mesh portal discovery

[John Watlington]

On Jan 9, 2008, at 2:08 PM, David Woodhouse wrote:

>
> On Wed, 2008-01-09 at 11:34 -0500, John Watlington wrote:
>>
>> Right now we have a problem with mesh portal discovery.
>>
>> The DHCP procedure currently being used only discovers
>> the nearest mesh portal when it is first run (DHCP_DISCOVER),
>> not when it tries to renew (DHCP_REQUEST).   Furthermore,
>> as the address previously assigned indicates which mesh portal
>> was selected, it seems like we should always be discovering, not
>> renewing...
>
> Legacy IP doesn't work well and doesn't really give us what we need in
> the long term... or even the medium term. We've known that all along.
>
> What do you propose to do about it? Throw away pointless engineering
> into cobbling together some way of making Legacy IP work a bit  
> better? I
> seriously hope not. Just switch off the Legacy IP, as we should have
> done months ago, and get on with making things work properly. Anything
> else is a distraction.

Unsolicited RAs for IPv6 mean that IPv6 isn't the panacea to this  
problem.
It's easy to discover the shortest way out of the mesh (nearest mesh  
portal),
but setting up the larger mesh networkl infrastucture means you also  
need to
provide a way to route packets back INTO the mesh through the MPP  
nearest
the destination laptop.

I have yet to see a good description of how to make IPv6 work right  
on a mesh
with multiple portals.    One would be welcome!

I have such a method for IPv4 defined, but due to an error in  
modifying the DHCP
client, it doesn't handle laptops moving around in the mesh once they've
chosen an MPP.   (BTW, the error was mine)

wad