mesh portal discovery

[John Watlington]

On Jan 9, 2008, at 3:47 PM, Michail Bletsas wrote:

>> The MPP discovery mechanism originally proposed worked great for  
>> getting
>> packets out of the mesh through the shortest path.   The problem was
>> that outside of running NAT on each MPP, there wasn't a good way  
>> to ensure
>> that packets sent to that laptop entered the mesh through the same  
>> MPP.

> The only reason that I can see to use DHCP is if you want to  
> distribute
> routable IPv4 addresses, something that would be glorious if it could
> happen but  which I don't see happening very often.

Neither do I.  But I don't want to impose a NAT between two laptops  
in the
same school.   It will break P2P applications.

> If you are not running NAT on the MPPs and you have multiple MPPs  
> per mesh
> and the external routing protocol decided that packets should return
> through a different portal, what much do you think you are gaining by
> using the same path inside the mesh (which b.t.w. is different in each
> direction anyway!)?

I don't care about using the "same" path, but sending packets for six  
hops
through the mesh when proper routing can reduce it to a single hop seems
like piss-poor design.  And it makes the mesh interfaces on a single  
server
serve the entire school.  Why bother with multiple MPPs at all ?

>> We briefly discussed using a different autoIP range, and decided  
>> it was
>> difficult to implement.
>>
> Again fail to see why - it can be non-standard but definitely not
> difficult to implement.

IIRC, Dan Williams was the person looking into it.  It wasn't a  
Network Manager
change, it was a change to Avahi, and would either have to be pushed  
upstream
or maintained indefinitely by us.  Plus, AutoIP addresses aren't EVER  
supposed
to be routed --- they are strictly link local due to the assignment  
process.

Thanks for the discussion --- we need to figure out a solution for  
IPv6 going forward,
as none of the current approaches will absolutely not extend to IPv6.

wad