From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from chi.subsignal.org (cxd-2-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:ed::2]) by huchra.bufferbloat.net (Postfix) with ESMTP id C71BB21F104 for ; Sun, 5 May 2013 07:24:50 -0700 (PDT) Received: from [192.168.178.21] (unknown [212.255.39.241]) by chi.subsignal.org (Postfix) with ESMTPSA id 0B4AD126163; Sun, 5 May 2013 16:26:08 +0200 (CEST) Message-ID: <518679F3.8050509@openwrt.org> Date: Sun, 05 May 2013 17:25:39 +0200 From: Steven Barth User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130112 Icedove/17.0.2 MIME-Version: 1.0 To: Michael Richardson References: <29781.1367350165@sandelman.ca> <26206.1367413101@sandelman.ca> In-Reply-To: <26206.1367413101@sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: cerowrt-devel Subject: Re: [Cerowrt-devel] shaggy dog story on 3.8.8-4 experiences X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2013 14:24:52 -0000 Hi, I was on holiday until yesterday so my reply is a bit late. On 01.05.2013 14:58, Michael Richardson wrote: > > Entering (a) is good because it produces a: > ip -6 route add blackhole prefix/len > > which means that any subnet that isn't allocated anywhere does not > result in a routing loop. It also causes the 6relayd to assign prefixes > to each interface. > > I will see if I can hack on 6relayd, because I really like this. This is actually done by netifd, not 6relayd. 6relayd is the RA/DHCPv6-server used in OpenWrt trunk (CeroWrt uses dnsmasq here I think) and provides most of the homenet functionality (RFC 6204 should be pretty much covered by OpenWrt with very few exceptions - I think only one) > > >> At least one prefix is behind another router, so this router can not > >> see that prefix is already in use. Suggestion: start at highest > >> number available and work downwards. > > Dave> Two interior prefix allocation methods have been described by the > Dave> homenet and hipnet rfcs. openwrt follows neither at present. > > sure, that's not the point. The point is that the set of "prefixes in > use" is not limited to just those on local interfaces, but also ones > that might have a static route elsewhere. Yes, I agree that routing > protocols are important and useful... that's why I have 4x 3800 now for > play and testing :-) > > The incidence of conflict would be less if the auto-assigned numbers > started from highest number. At least for me, it would. That's imo not a good idea because it doesn't really solve the issue. I could modify the assignment logic in netifd to scan through all ip6addrs configured before distributing any prefixes and exclude ip6addr assigned prefix parts from being reassigned again. Regarding the other cases: It is possible to set ip6assign to something <64 so that a bigger prefix is assigned to a downstream-interface. With 6relayd as DHCPv6-server this automatically makes anything but the first /64 available on the interface to downstream routers via DHCPv6-PD (the first /64 is announced using RAs on the interface). At the moment you could simply use ip6hint with every ip6assign consequently on every interface and keep some prefix-parts from being used by the distribution logic. So this is all fine with static / 6in4 however the problem here is that we cannot guarantee anything when it comes to DHCPv6-PD: * We do not know beforehand how big the prefix from the ISP will be and if the reservation would fit. * We do not know beforehand if the ISP excludes a certain part of the prefix using the RFC 6603 method which would clash with the reservation. In cases of size issues or clashes with excluded prefixes the distribution logic might ignore the ip6assign / ip6hint values to get at least something working anyway. So with anything non-static like DHCPv6-PD it is in general not possible to define a reservation and just assume it will work. The technically better solution would be a mechanism where programs could request a prefix via some RPC-mechanism from netifd. However this would need synchronization and callback-mechanism to inform the routing daemon when a prefix is assigned / deassigned etc. Additionally this logic would need to be builtin into each individual routing daemon or at least we need to have some kind of hotplug-logic that triggers a reconfiguration and restart of such a daemon every time a prefix changes so that it doesn't use outdated information. This sounds all very painful to me. I'm a bit lost on this issue and don't really know how to proceed right now so any input on this matter is very much appreciated. Cheers, Steven