On Thu, Jan 30, 2014 at 8:46 AM, Markus Stenberg <markus.stenb...@iki.fi> wrote: > 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 agreement 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, >> wireless, >> and the internet of things. >> >> I don't think anyone will ever agree to a single routing protocol decision >> 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 pretty >> 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 ). However, it > needs quite a bit of configuration on top of that that you can't squeeze in > easily; or at least, you wind up with either > > - configuration coming from some other protocol (like my old OSPF+SD draft), > or > - dns-updates + god DNS server + god DNS server replication within your home > > 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 > something 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 which >upstream DNS server to use? A and B source address won't help in this case, 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=2001:558:feed::1@260x:y:z::1 server=2001:558:feed::2@260x:y:z::1 Bind also can do the same, but the syntax is more involved. 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 >> anything. > > 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ä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
