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;
};
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.
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
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
