mesh portal discovery

[Dan Williams]

On Wed, 2008-01-09 at 15:59 -0500, John Watlington wrote:
> 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.

- DHCP did what we needed back then, namely
    1) a robust discovery mechanism
    2) well-tested backoff mechanisms
    3) well-known and standardized behavior and packet format
    4) well-tested and security audited server and client

In the School Server case, using DHCP as the allowed us to collapse two
steps of the connection process into one.  With the previous method, you
would have to _both_ find the MPP using the non-standard MPP discovery
method, and second do a DHCP run to get your address from the school
server.  Using DHCP here _already_ can provide the address of your
gateway.

You could conceivably do both these operations in parallel but since you
have to do DHCP anyway, it's pointless to do some other MPP discovery
mechanism.  In a school setting autoip might work, but might mean more
traffic because of potential address conflicts and the resolution
process.  So if you want dynamic addressing in the school, DHCP is about
the only easy way to do that, and once you're using DHCP the old MPP
discovery mechanism is pointless.

The above benefit does not apply in the XO-as-MPP case because autoip
addressing is used, however the same codepath is used in NetworkManager
as the school server case, and therefore there is less code to maintain,
and fewer codepaths to test, and fewer opportunities for stuff to go
wrong.

The only real solution to this problem that doesn't suck is to use IPv6
auto addressing for everything.

Dan