[Cerowrt-devel] shaggy dog story on 3.8.8-4 experiences

[Steven Barth]

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