Posted: Sun Apr 22, 2018 15:50 Post subject: IPv6 dhcpc issues?
Hello,
I have a Dlink DIR-882A running (currently) build v3.0-r35767 std (04/19/18).
My ISP supports IPv6 DHCP with prefix delegation.
I enabled "DHCPv6 with Prefix Delegation" in Basic > IPv6, set the appropriate prefix length (48), enabled radvd, and disabled "dhcp6c custom" and "dhcp6s".
I find that the router itself does not normally receive IPv6 routes from the ISP (and consequently clients on the LAN cannot talk to the outside world via IPv6).
Code:
# ip -6 a
1: lo: <LOOPBACK,MULTICAST,UP,LOWER_UP> mtu 65536
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 fe80::7a32:1bff:fe6c:607e/64 scope link
valid_lft forever preferred_lft forever
5: vlan1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
inet6 fe80::7a32:1bff:fe6c:607e/64 scope link
valid_lft forever preferred_lft forever
6: vlan2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
inet6 <my public prefix>:7a32:1bff:fe6c:607f/64 scope global dynamic
valid_lft 2591472sec preferred_lft 604272sec
inet6 fe80::7a32:1bff:fe6c:607f/64 scope link
valid_lft forever preferred_lft forever
9: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
inet6 <my transfer prefix>::200:ff:fe00:0/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::7a32:1bff:fe6c:607e/64 scope link
valid_lft forever preferred_lft forever
37: ra0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 3000
inet6 fe80::7a32:1bff:fe6c:607e/64 scope link
valid_lft forever preferred_lft forever
38: ba0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 3000
inet6 fe80::7a32:1bff:fe6c:607f/64 scope link
valid_lft forever preferred_lft forever
# ip -6 r
<my public prefix>::/64 dev vlan2 metric 256 expires 0sec
<my transfer prefix>::/64 dev br0 metric 256
fe80::/64 dev eth0 metric 256
fe80::/64 dev br0 metric 256
fe80::/64 dev vlan1 metric 256
fe80::/64 dev ra0 metric 256
fe80::/64 dev ba0 metric 256
fe80::/64 dev vlan2 metric 256
default via fe80::8a43:e1ff:feca:733f dev vlan2 metric 1024 expires 0sec
unreachable default dev lo metric -1 error -128
ff00::/8 dev eth0 metric 256
ff00::/8 dev br0 metric 256
ff00::/8 dev vlan1 metric 256
ff00::/8 dev ra0 metric 256
ff00::/8 dev ba0 metric 256
ff00::/8 dev vlan2 metric 256
unreachable default dev lo metric -1 error -128
I thought there was something wrong with the ISP's DHCP leases, so I spent some time mucking about with dhcp6c trying to add -D flags so I could debug leases. Despite killing and restarting dhcp6c with the -D flag, I never see info in syslog (???), but after some time mucking with that and killing udhcpc (which I see only does IPv4 anyway) I did manage to, temporarily, pick up a lease that worked. (It had usable routes, and IPv6 connections to the outside world worked both from the router and clients on the LAN.)
This led me to think there's something wrong with udhcpc. I stumbled upon https://patchwork.openembedded.org/patch/146750/, which made me think some versions of udhcpc are clearing IPv6 settings when refreshing IPv4 leases.
Any ideas? I could be barking up entirely the wrong tree, but I'm at a loss to explain why the router is not getting any usable routes from the ISP.
(I'm also interested in suggestions for inspecting the received DHCP leases. Why does "dhcp6c -D" not work?)
Sort of correct. br0 has an IP within the assigned /48 prefix. I believe this is WAI.
Quote:
I use dnsmasq instead of radvd.
I am not sure that's relevant. The router itself has no usable (IPv6) routes. If the router had usable routes but LAN clients did not, I could imagine it's an radvd or dnsmasq issue, but I don't think we're even there yet--the router itself can't talk IPv6 to the outside world!
Hmm, what do you mean, you don't have a public IP on the WAN interface? The whole point of the WAN interface is to have a public IP. :)
In any event, your dhcp6c.conf is very close to the default--I'm not very familiar with all of these options, but I'm not sure any of them are responsible for not setting up routing information (though they may be).
I may be totally confused, but isn't the point of a delegated prefix that the router can hand out public (routable) IPs within that prefix range to DHCP clients on the LAN, allowing traffic on the LAN to use routable IPs rather than NAT?
If clients are routing traffic via fe80, then you'd still need to be doing some form of NAT in the gateway, which defeats the whole purpose of getting a large prefix!
Nonetheless, I don't believe this is in any way relevant to my problem. Even if there were no delegated prefix (and the ISP issued only a single full /64), the problem of the router itself not having any routing table entries for public IPv6 addresses would remain. :-/
Hmm. One more question, because this would make debugging a lot easier:
Shouldn't "dhcp6c -D -T LL" log a fair amount of the DHCP request and response to syslog? I see _nothing_ from dhcp6c in syslog. Bug? Does Busybox dhcp6c not support logging?
I no longer have this problem. I frankly stopped paying attention to it, and noticed--some time and some firmware updates later--that it appeared fixed.
I suspect my ISP changed something, and that this had nothing to do with the firmware version, but I have not bothered to A/B test to confirm.