Hello Vincent, Vincent Truchseß <debian-u...@v-tr.org> writes:
> I've had the same Issue here delegating prefixes to my VPN-Gateway in my > home-hetwork. Good to know that it's not just me. For posterity, I did some further tests: * It does not matter if the router sets the "Other Configuration" or the "Managed" flags, as long as I use "ForceDHCPv6PDOtherInformation=yes" in systemd-networkd. The behavior is the same. * Playing around with tcpdump, I found that while a new prefix on my external interface enp3s0 is announced (and received) correctly via router advertisement, neither the ISP's router nor systemd-networkd trigger any DHCPv6 activity. I am not sure about the relevant RFCs and if a change in prefix should trigger a DHCPv6 Solicit or if the router has to send some other message, but as far as I understand, the router advertisement should be enough. The server *could* send Reconfigure messages, but my ISP's router does not seem to do it. * Nevertheless, when systemd-networkd sends out a solicit or renew and the DHCPv6 server answers with NoBinding, the client is supposed to send a request message to try to get another prefix in reply (at least that's how I read RFC 8415, Sec. 18.2.10.1). It does not do this. I also tried with the systemd-networkd from yesterday's git master of the systemd git repo, but it behaves the same in my limited testing. I strongly assume systemd-networkd is still buggy in this area. An additional problem is that the routes for old prefixes do not seem to be removed. That might also lead to problems. > My solution back then was to ditch systemd-networkd for this setup and > rely on configuring dhcpcd and radvd accordingly. Systemd's > DHCP-implementation seems to a little bit out of whack, depending on the > version. > > Unfortunately that VPN-Gateway got decommissioned and I don't have a > backup of those two config-files. If I remember right, I kept the config > close to what the ArchLinux-Wiki suggests. Thanks for the info, but I will rather contact systemd upstream about this, so that this software can be fixed. I found it to be a very pleasant network managing daemon with very clear configuration and otherwise quite a bit more reliable than NetworkManager or ifupdown, so I think improving it is the better long-term solution. Tobias