In message <[email protected]> David Täht writes: > In reviewing this enormous thread it appears to have got off-track > again, discussing esoterica of various routing protocols and not focused > on the big picture. > > There's been too many comments for me to comment individually on the > messages. > > However, overall trends on this list are discouraging. > > 1) Getting IPv6 working well inside the home is a hard problem! It helps > to actually try to make something work, to see the relevant details. I'd > like it very much if at an upcomin > > I've built 3 such networks, and am in the process of building several > more - as well as making available code on a cheap, 120 dollar, platform > to make it possible to actually go and set one up yourself to play with, > so the more devilish, detailed problems become apparent. I've done my > best to make sure 6to4, at least, works right out of the box. Native (no > PD yet!) works pretty well, too - but getting the 6to4/ipv6 native to > co-exist better is going to take slightly more work. > > http://www.bufferbloat.net/projects/cerowrt/wiki/OCEAN_CITY_INSTALLATION_GUIDE > > There's babel, batman, rip, radvd, ospf, ospfv6, is-is, and bgp all > available. Go play. > > I'd like it very much if at an upcoming meeting or event someone or > someones were to demonstrate working code... > > 2) Now, in reviewing this thread, I was disappointed to see that my ipv6 > routing protocol of choice (babel) has not been discussed so far to any > extent. While this protocol is somewhat new, an rfc and working code > both exist, and working code has existed for several years. > > http://tools.ietf.org/html/rfc6126 > http://www.pps.jussieu.fr/~jch/software/babel/ > > Of late there has been a great deal of work on creating a metric that > does diversity routing - accounting for the differences in performance > between contested wireless channels and ethernet to some extent. > > It seems to me that that babel has got lumped in a mental catagory of > 'mesh networking protocol' - which it is - but it is better described as > 'rip on speed' as it works across normal wired, wireless, AND mesh > networks - something no other routing protocol does well (IMHO!). Things > like 802.11s are targetted at wireless only. > > The future inside the home is mostly wireless, not wired... and as many > of the assumptions built into ipv6, dhcp, dhcpv6, ra announcements, etc > completely predate the rise of wireless everywhere, they tend to be, > well... wrong. > > Here are the current routing tables from bloatlab #1 > > http://www.bufferbloat.net/projects/cerowrt/wiki/BloatLab_1 > > http://www.teklibre.com/~d/labroutes/ > > I am using CIDR networks (/27 netmasks) on the ipv4 side to reduce the > broadcast/multicast problem that wireless-n has, and a variety of IP > address distribution mechanisms on the ipv6 side - autoconfig/ra and ahcp. > > Some notes: > > 0) It took me multiple years of fiddling with the ipv6 routing protocols > available to settle on babel. Babel is definitely not finished or > perfect, but thankfully it has a pluggable metric. > > 1) Babel treats IPv6 as a first class object - ipv4 and ipv6 routes are > distributed in the same message - and within the same daemon and > configuration files. I had used olsr in an earlier attempt at convincing > ipv6 to work well on a previously pure ipv4 - the size of the 2 daemons > required, the doubling of packets sent, and the complexity of the conf > files all deterred me. > > 2) Setup is devestatingly simple compared to any other routing protocol > I've tried. For example, it uses a EUI-64 equivalent as a router-id, no > setup required. > > Now I actually use, in the home, a setup that dumps dhcp, dhcpv6, and ra > entirely, replacing them with a combination of AHCP and babel - AHCP > also distributes ipv4 and ipv6 in the same message, and also (when done > right) gives the ability to transparently move between wired and > multiple wireless links without dropping connections. Stepping back into > what others think as the real world... in the office - is often a shock > - I unplug and... "oh damn, I just lost 20+ windows and the movie I was > streaming..." where that *doesn't happen* when using the above two > protocols at home.... > > AHCP uses /128 netmasks which makes subnetting a single ipv6/64 > allocation a breeze. > > I can think of a few more compelling advantages for considering new > ideas such as these protocols inside the home, but this is almost enough > for today. > > I'll talk to the more generic problems with prefix based routing in a > mixed 6to4 and native scenario, the dns naming problem, and the ip > address expiry problem some other day... > > but you can see those for yourself with a little investment of time and > hardware in trying to actually make something - anything! - actually work. > > > -- > Dave Täht
All very impressive. You still have quite a few routes for a network with very few hosts. At some point you have to wonder whether it might be better to arrange a OSPF style bcast network for mesh that turns out to be a cluster of many routers within a given very close range. IF the AP style (infrastructure bss) is used rather than mesh (MBSS) then this is a natural fit. DR election isn't all that painful and as long as the DR remains stable (hint: give the AP a high number in the DR election) then adding is fine. Multicast from the DR would be nice rather than multiple unicast. For now we have OSPF and ISIS (and BGP) running the global Internet on the one hand. They are well proven, but these may or may not be applicable to the homenet. On the other hand we (or you) have lots of promising work and some running code that isn't quite a mature and isn't (afaik) widely deployed. I don't think we should rule out either one. Protocols that are only applicable to specific circumstances tend to go away. I'm not yet convinced either way on the staying power of babel and AHCP. Perhaps I have a bias for link state protocols that has set in over the last nearly 20 years of using them. But it is hard to argue with running code once a lot of people are running with it. Curtis
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
