Aftter assigning IA_PD, odhcp starts believing local interfaces lack public prefixes

[toreanderson]

After having assigned an IA_PD lease to a node on a local interface, odhcpd starts believing multiple local interfaces do not have any public prefixes, including interfaces on which it has never received any IA_PD request. This causes it to send RAs with a router lifetime of 0, breaking connectivity for the hosts. As shown in logread:

DHCPV6 SOLICIT IA_PD from 000100011e9b70e9525400bc653e on eth0.5: ok 2a02:fe0:c420:57ea::/64 fd65:557c:6f31:5c::/62
DHCPV6 REQUEST IA_PD from 000100011e9b70e9525400bc653e on eth0.5: no prefix available 2a02:fe0:c420:57ea::/64 fd65:557c:6f31:5c::/62
DHCPV6 SOLICIT IA_PD from 000100011e9b70e9525400bc653e on eth0.5: ok 2a02:fe0:c420:57ea::/64 fd65:557c:6f31:5c::/62
A default route is present but there is no public prefix on wlan1 thus we don't announce a default route!
A default route is present but there is no public prefix on eth0.2 thus we don't announce a default route!
A default route is present but there is no public prefix on eth0.3 thus we don't announce a default route!
A default route is present but there is no public prefix on eth0.4 thus we don't announce a default route!
A default route is present but there is no public prefix on eth0.5 thus we don't announce a default route!

The claim that there is no public prefix on the interfaces in question is easily disproved with ifstatus <if> and/or ip -6 address show scope global dev <dev>.

The second line also claims that there is no prefix available. That also seems bogus and a symptom of the bug. There's just no way the entire ULA /48 has been assigned, and the public /64 has only been assigned to that particular IA_PD client.

As mentioned, the bug only appears after having received an IA_PD request. It seems that the number of interfaces impacted varies a bit, however if I send several IA_PD requests (e.g., by restarting the DHCPv6 client a couple of time), every single interface on the box will be impacted.

Restarting odhcpd gets me back to a functional state, but only until the next IA_PD request shows up.

I bisected the issue, and it appears to have been introduced in commit 10fc566. Up until commit 8348741 the default route is present but there is no public prefix on and the no prefix available errors simply do not appear, even if I continuously restart the DHCPv6 client on the node.

[toreanderson]

For what it's worth, this bug appearst to have been included in the 15.05.1 point release of OpenWrt Chaos Calmer.

[timcoote]

Is it likely that this bug will surface if I merely reset a downstream router, which then solicits and IA_PD. odhcpd then will not respond and logs:

Sun Aug  7 09:46:26 2016 daemon.warn odhcpd[971]: DHCPV6 SOLICIT IA_NA from 0003000108002742210c on br-lan: no addresses available 
Sun Aug  7 09:46:26 2016 daemon.warn odhcpd[971]: DHCPV6 SOLICIT IA_PD from 0003000108002742210c on br-lan: no prefix available 
Sun Aug  7 09:46:27 2016 daemon.warn odhcpd[971]: A default route is present but there is no public prefix on br-lan thus we don't announce a default route!
Sun Aug  7 09:46:27 2016 daemon.warn odhcpd[971]: DHCPV6 SOLICIT IA_PD from 0003000108002742210c on br-lan: no prefix available 

meanwhile on the same, upstream, router:

root@OpenWrt:~# ip -6 address show scope global dev br-lan
6: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 
    inet6 2a02:c7d:1d31:a600::1/56 scope global noprefixroute dynamic 
       valid_lft 5494sec preferred_lft 1894sec

[toreanderson]

Your ip -6 address show output indicates that the address has been configured with a 56-bit prefix length. That's invalid and indicates there's another bug involved. I've never seen this one before. Did you manually configure your br-lan interface? Is it set up with option proto 'hnet' or something else?

[timcoote]

I thought that I'd taken and used the stock image (http://bit.ly/2aEyKqd), so that the ipv4 address was fixed. I did move that address. I also had to faff a bit to get the router to get the subnet delegation from Sky. It looks like I also added hnet control to the lan interface: and this could be the wrong thing to do. The relevant uci stanzas look like this:

config interface 'inhnet'
    option 'ifname' 'eth1'
    option 'proto' 'hnet'

config interface 'lan'
    option ifname 'eth1'
    option force_link '1'
    option type 'bridge'
    option proto 'static'
    option netmask '255.255.255.0'
    option ipaddr '192.168.1.254'
    option ip6assign '56'

I do want a downstream router to get a subnet from this router. Should I have configured that differently?

[toreanderson]

I think your problem is option ip6assign '56'. I think that tells OpenWrt to assign a /56 directly onto eth1, which probably is the entire prefix you got delegated from your ISP. Thus it makes sense perfect sense for odhcpd to say that there's no prefix available, because you've assigned all of your 256 available /64s to eth1.

So I think you'll want to change that to say option ip6assign '64' instead.

Another thing that seems a little bit strange to me is to have both option proto 'static' and option proto 'hnet' on the same interface. hnetd will take care of assigning IPv4 addresses to links, there's no need to do it statically. It might be that doing both works without issue, but if I were you I'd try collapsing the two interface definitions into one, something à la:

config interface 'hnet-lan'
    option ifname 'eth1'
    option force_link '1'
    option type 'bridge'
    option proto 'hnet'
    option mode 'auto'
    option ip6assign '64'
    option ip4assign '24'

This would be more similar to what I have on my routers. I'm not using any bridges though, so no guarantees it works without modifications.

[dtaht]

This appears to be the same bug as #388. I can reproduce it easily now.

https://bugs.lede-project.org/index.php?do=details&task_id=388

In my case, I am allocating out of 61. 3 dhcp pd attempts, and boom

[OopsPwnedUAgain]

In my experience this problem happens if there's a lan interface which has dhcpv6 enabled but no ipv6 blocks assigned. Unfortunately this causes other lan interfaces to have their routes revoked.

I suppose one could say that having dhcpv6 enabled on an interface without a public address available is an incorrect configuration, but it can happen without users intentionally configuring.