On Thu, Jan 30, 2014 at 6:14 PM, Mark Andrews <ma...@isc.org> wrote: > > In message > <caa93jw6wcx2fgu9ftji+ndaar4cve2dzf-emuwyyt2jmhom...@mail.gmail.com> > , Dave Taht writes: >> On Thu, Jan 30, 2014 at 8:46 AM, Markus Stenberg <markus.stenb...@iki.fi> w= >> rote: >> > On 30.1.2014, at 17.50, Dave Taht <dave.t...@gmail.com> wrote: >> >> don't want it in the routing protocol. >> > >> > Why not? You can stick in kitchen sink there! ;-) >> > >> >>>> of routing protocols for that branch. I have assumed there is agreemen= >> t to >> >>>> have a single routing protocol in the home, and not support multiple. >> >> I'm interested only in a routing protocol that works well with wired, wi= >> reless, >> >> and the internet of things. >> >> >> >> I don't think anyone will ever agree to a single routing protocol decisi= >> on >> >> unless the protocol meets those requirements well, and is battle tested >> >> to meet those requirements well. And none do. >> > >> > The definition of 'works' varies by people, so by that definition, I don'= >> t think there is much to see here. >> >> Much work is required here, and co-ordination with the wgs on internet >> of things would make sense. >> >> And running code, in upstream versions of the relevant daemons. >> >> >>> So question if we don't use the routing protocol for prefix assignment,= >> what >> >>> should go in there? Should we have a new protocol for service discovery? >> >> It is my hope that hybrid-proxy-mdns solves this. Certainly mdns is pret= >> ty >> >> good about picking up dynamically changed >> > >> > hybrid proxy fixes some things ( see https://github.com/sbyx/ohybridproxy= >> for a minimalist implementation that seems to work, more or less ). Howeve= >> r, it needs quite a bit of configuration on top of that that you can't sque= >> eze in easily; or at least, you wind up with either >> > >> > - configuration coming from some other protocol (like my old OSPF+SD draf= >> t), or >> > - dns-updates + god DNS server + god DNS server replication within your h= >> ome >> > >> > I'm not sure which is worse, but neither sounds very appealing. >> >> Yep, we need a replacement for dns, that is replicable (uses a dht?), >> robust, and secure. Anyone? >> >> >> It still seems that being able to distribute and route between /128s is = >> needed, >> >> and nd proxying for folk that are only doing a /64 and have subnets. >> > >> > Lots of nodes still don't do stateful DHCPv6 (and even fewer do AHCP or s= >> omething else); obviously, we could just ignore them and point at RFC6434? = >> Hmm. >> >> I don't mind pushing people at the standards at all :) I never grokked >> much of the overall emphasis on distributing /64s everywhere though. >> >> the problem I've long had to deal with is only getting a single /64 at >> best in a routed network (and /60 doesn't help much either). >> >> ahcp has and has been for 6 years on linux >> >> apt-get install babeld # pulls in ahcp >> edit /etc/default/ahcpd to add your interfaces and specify -6 only >> edit /etc/ahcp/ahcp-script.sh # to more sanely add servers >> >> walla. you get /128s. >> >> dhcpv6 is similar, of course. Presently openwrt is handing out /128s >> for stateful dhcpv6, I don't know if that's intended. >> >> >> 1) in the multi-homing case you want requests from a local dns server >> >> to be sourced >> >> from the right network to the right ISP-provided forwarder. (think >> >> I have a fix for >> >> that but it involves abandoning resolv.conf for specific dnsmasq >> >> configuration. >> > >> > Does it really work without host changes? Let's assume you have prefixes = >> A and B from ISPs ISP_A, >> >> yes. >> >> >ISP_B. You have host that has addresses in A and B. It chooses to point it= >> 's upstream resolver at your dnsmasq on your router. How do you figure whic= >> h upstream DNS server to use? A and B source address won't help in this cas= >> e, as DNS resolution is done with 'point SOMETHING at configured DNS server= >> ' in most current hosts. >> >> in-home hosts can point to any local dns server over any ip address >> type, be it ipv4, link local, ula, or some set of ISP provided >> address. >> >> on the gateway the local dns server needs to distinguish from what ISP >> was derived the relevant source >> addresses, so it can issue queries to an upstream dns server, which >> involves abandoning leveraging >> /etc/resolv.conf.auto, for a dnsmasq specific configuration: >> >> cat /tmp/dnsmasq.d/comcast.conf >> server=3D2001:558:feed::1@260x:y:z::1 >> server=3D2001:558:feed::2@260x:y:z::1 >> >> Bind also can do the same, but the syntax is more involved. > > forwarders { > 2001:558:feed::1; 2001:6000:feed::2; > }; > > server 2001:558:feed::1 { > query-source 2001:558:xxxx::2; > }; > > server 2001:6000:feed::2 { > query-source 2001:6000:xxxx::2; > };
excellent. > The server clauses could be removed if there was a way for the ISP > to say which prefixes it has so that the stack's source address > selection rules picked the prefix from that ISP for those addresses. How about reverse lookups? > Presumably the ISP's recursive servers arn't open to the world. > >> The in-home dns server also needs to ensure it only responds to >> queries from internal hosts (so as not to become a open resolver), >> presently that's done by ignoring queries from the external >> interface(s). It would >> be nice if queries from external hosts for the AAAA records for your >> in-home domain worked. Are there >> any dynamic dns providers working with AAAAs yet? >> >> incidentally one thing that could be used specifically for dns is to >> give the server it's own ipv6 >> address to play in, thus freeing up all ports to protect against >> things like the kaminsky attack, and >> better being able to correctly handle queries from the universe. >> Another option is run dns on >> a separate box, which conceptually hands the address awareness problem >> back to some sort of protocol. >> >> (Personally I see a lot of homes not running a local dns server and >> relying on mdns internally instead.) >> >> I was very happy to start routing all my dns traffic over ipv6 >> recently, in saving udp4 ports for >> other uses. The impact of running a local dnsrbl can drop >> significantly if NXDOMAIN is honored >> by the upstream server. I merely turned off getting ISP nameservers >> via dhcp4 and get them from >> dhcpv6 on the gateway. >> >> I have proposed syntax for dealing with reverse lookups to the >> dnsmasq-discuss list. >> >> > >> >> 4) the vast increase in ipv6 related multicast led me to finally >> >> violate the 802.11 standard and >> >> fix wireless multicast rates to 9mbits. So far that hasn't broken any= >> thing. >> > >> > Oho. Do you have concrete numbers on how much multicast you're seeing in = >> and what sort of topology? Just base IPv6 stuff or e.g. mdns? >> >> What I have at the moment is indirectly observable effects >> >> > >> > Cheers, >> > >> > -Markus >> >> >> >> -- = >> >> Dave T=E4ht >> >> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= >> html >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
