Static IPv6 addresses#

Sat, 05 Dec 2020 22:00:48 +0000

Advent of Blog, day 5

Short one, today. After all that writing about airsonic and sniproxy the other day, I went to put some music on yesterday and found that it didn't work any more.

A series of suppositions

I broke my network significantly last week by switching from GNOME to KDE

... Let's just take a moment to reflect on how utterly bonkers it is that switching the desktop environment should break networking, but GNOME apparently has NetworkManager as a dependency, or possibly vice versa ...

and in the course of fixing that, I seem to have enabled systemd-networkd, which had changed the way that the machine was getting an IPv6 address. Where I previously had 2001:nnn:nnn:nnn::ed9, now I have 2001:nnn:nnn:nnn::148 and 2001:nnn:nnn:nnn:xxxx:xxxx:xxxx:xxxx.

IPv6 address allocation is simultaneously much simpler and much more complicated than IPv4 was, but the short form is: you can have a global address via SLAAC or via DHCPv6 or both. Addresses from SLAAC are 64 bits of prefix (here, 2001:nnn:nnn:nnn) plus 64 bits derived from your 48 bit MAC address. Addresses from DHCP are the prefix plus whatever the DHCP server gives you when you present it with a DUID, so I'm going to assume that these ::148 and ::ed9 are from DHCP - my MAC address isn't full of zeroes - and that networkd is presenting a different DUID than NetworkManager was.

There are, I guess, two possible routes to win here: find out how to make networkd present the same DUID as NetworkManager did, or reconfigure OpenWrt to accept the new one and give me the old address. I'm going for the latter approach, so, let's login to the router and use uci show dhcp to find the per-host setting

dhcp.@host[0]=host
dhcp.@host[0].name='loaclhost'
dhcp.@host[0].dns='1'
dhcp.@host[0].hostid='0:0:0:e9d'
dhcp.@host[0].leasetime='86400'
dhcp.@host[0].ip='192.168.8.148'
dhcp.@host[0].mac='fa:1e:9f:84:20:8e'
dhcp.@host[0].duid='0000ab11406665c3f2e752320000'

There are two things I now know to be wrong with this:

the duid in this configuration bears witness to my previous attempt to fix this problem, but it doesn't actually match what is presented. Although networkctl status vbridge0 on the client says From DUID-EN/Vendor:0000ab11406665c3f2e752320000, the duid that OpenWrt sees is 00020000ab11406665c3f2e75232. I don't know of another way to check this than by looking in the Luci web interface, in the "Active DHCPv6 Leases" section

the hostid is in the wrong format - I think OpenWrt doesn't like the colons

So we can fix them both:

uci set 'dhcp.@host[0].duid=00020000ab11406665c3f2e75232'
uci set 'dhcp.@host[0].hostid=0e9d'
/etc/init.d/odhcpd stop; /etc/init.d/odhcpd start

And down/up the interface on the client to make a new request (don't use renew, it doesn't help here)

sudo networkctl down vbridge0 ;sleep 1; sudo networkctl up vbridge0

and now I have my local services accessible again. Yay me.

You may be wondering why I have vbridge0 as my primary interface on that machine and not enp1 or en0s31f6 or en4s31f6z1q3zz9zzzα, and the answer is: it's a bridge between the ethernet interface and one or more tap devices for virtual hosts. I don't think anything I've described here would be different for a hardware ethernet, but don't quote me, I haven't tried it.