dhcpcd-discuss

Hi Roy,

when I tested my prefix delegation hook script, I stumbled over a few things, some of which I think could be suggestions for enhancement in dhcpcd and some of which might even be bugs.

So, here we go:

1) Some difficulty in dealing with prefix changes lies in determining which subnet addresses belong to a prefix. This is especially evident in the case of lease expiration. Say I made configuration changes based on each subnet address that is assigned by dhcpcd to other network interfaces and which I can learn e.g. from the DELEGATED6 events. When the lease expires, I have no hint which subnet addresses were associated with this prefix and which configuration changes I need to undo. Things would become much simpler if dhcpcd could also set a variable that holds a space separated list of subnet addresses that are associated with a prefix (so, if you configure dhcpcd to assign two /64 subnets from a /60 prefix, that list would contain the two /64 subnet addresses, not all 16 possible /64 subnets in the /60 prefix). Then there would be no need to determine that programmatically.

Now, if such a variable were added, there might be different opinions on whether it should hold all the different subnet addresses for which dhcpcd is configured to create and assign or only thos that are actually assigned already when the BOUND6 event is triggered. But whatever it is, I think it would be an improvement over the current situation.

2) Kind of similar is the fact that there is no counterpart for the DELEGATED6 event in case of lease expiration. If you, unlike me, don’t care how often services are restarted and wanted to keep your hook script very simple and just react to each of the DELEGATED6 events, then undoing changes when the lease expires becomes a problem as there is no such thing as “UNDELEGATED6” or so. I think adding such an event would be useful.

By the way: The same applies to SLAAC prefix changes. You have ROUTERADVERT to process new prefixes, but handling a prefix change or expiration is not as straightforward...

3) In my lab setups, I observed scenarios in which the lease could not be renewed and dhcpcd removed the expired prefix and subnet addresses, but did not run dhcpcd-run-hooks with the reason EXPIRE6. I don’t know whether that is by design, but it was the main reason I implemented the check for “orphaned” leases in my script. The simplest scenario in which I can observe this if I simply stop the DHCPv6 server, so dhcpcd doesn’t receive a reply to its requests anymore. When the lifetime of the prefix expires, dhcpcd will remove the prefix/subnets, but dhcpcd-run-hooks is not executed. Another example is this: After dhcpcd obtained a prefix from the DHCPv6 server, I change the server’s configuration to serve prefixes from a different range and restart the server. When dhcpcd sends the RENEW6 request, the server will reply with “Prefix not bound to this interface.” dhcpcd then solicits a new lease and deletes the old prefix and addresses, but doesn’t execute dhcpcd-run-ho
 oks with the reason EXPIRE6. If this behavior is not intended by design, I would suggest to trigger the EXPIRE6 event in such cases.

4) The last issue I observed might be a regression in dhcpcd 7.0.8. The reason I think so is that this does not occur anymore when I replace dhcpcd 7.0.8 with version 6.10.1 (Debian’s default version in the current stable distribution) without any further changes to the test setup. I’ve actually tried that multiple times (switching from 6.10.1 to 7.0.8 forth and back), and I can always trigger this issue with 7.0.8 but not with 6.10.1. Now, the issue manifests itself in the manner that dhcpcd "locks up" while it assigns a subnet address for a newly obtained prefix with the following messages being logged over and over again:
Jan 14 23:13:39 debian-lab-client dhcpcd[4833]: enp0s9: adding address 2002:db9:7000:2::1/64
Jan 14 23:13:39 debian-lab-client dhcpcd[4833]: enp0s9: pltime 270 seconds, vltime 450 seconds
Jan 14 23:13:39 debian-lab-client dhcpcd[4833]: enp0s9: adding address 2002:db9:7000:2::1/64
Jan 14 23:13:39 debian-lab-client dhcpcd[4833]: enp0s9: pltime 270 seconds, vltime 450 seconds

I’ve seen dhcpcd write hundreds of megabytes of such data within minutes until I either killed it or until the disk is full. Now, the server (dhcpy6d) might not be well configured in this test scenario, but considering that the older release 6.10.1 handles it well, I don’t think it’s the culprit here. 

Roy, do you have any idea what might be going on in this case?

If you need more log context, let me know. I could also provide the package or configuration and so on. My 7.0.8 build is a local backport of the dhcpcd package from Debian Testing to Debian Stable. I haven’t patched it in any way or so, but simply build the sources in a Debian Stable environment. I should also add that I only observed this issue in a virtualized lab setup. I have the very same binary package running on my router for 3 months now and haven’t had any issues with it.

Thanks and regards,

Timo