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