dhcpcd-discuss

Hi Roy,

thanks for your reply. No worries, I'm not in a hurry.

I have a few more remarks after I spend some time yesterday to dig into this deeper:

1) I'm not so sure whether that's really what happens in my case. I added some more debugging info to my hook script and dumpend the output of `ip -6 -o addr` and `ip -6 -o route` along with the environment whenever the hook is executed.
It turns out, the delegated addresses and routes are already configured on all interfaces when the hooks are called with the reason BOUND6. I tested that many times with the machine rebooting, bringing the interface down and up manually, restarting dhcpcd, etc. In every case the addresses were already added to the interfaces that I delegate to. If that's always the case (and not just a coincidence), that simplifies my script a bit, because then I don't need to wait for the DELEGATED6 events and simply can restart my firewall when BOUND6, etc. occurs.

2) That'd be great!

3) I'm not sure anymore whether that would really make things easier. Bascially, for the actions I perform, I need to know the obtained prefix along with all the subnets that are being created. So, even if the obtained prefix would be in the environment, I'd need to process all DELEGATED6 events and store that information. But now that I found out that the addresses are already configured when the lease is obtained, I went a somewhat different road with my script. Since I already had a small shell function to calculate the n-th /64-subnet in a given prefix (which I needed when I was doing the delegation on my own with ISC dhcp), I simply added that code to my hook script and when the lease is obtained (e.g. when BOUND6 happens), I take the prefix, read my dhcpcd.conf file to see how many subnets are being delegated and calculate as many subnets with said function. This way, I have all the information that I need in one run of the hook script and don't have to wait for every single DE
 LEGATED6 event (and somehow determine which DELEGATED6 event was the last one). Currently, my script also checks whether the calculated subnets are actually found on the interfaces I delegate to and so far everything looks good. I still want to do further testing with this in a lab environment, especially to see how dhcpcd and the hook behave when a) multiple prefixes are offered by the DHCPv6 server and b) the preferred lifetime of an old prefix expires (but not the valid lifetime) and a new prefix is offered by the DHCPv6 server.

In case you're wondering what I do with the prefix and the subnet prefixes: This is information I use for the configuration of my DNS resolver on the same system. First, I declare the obtained prefix local or private address space for the purpose of DNS rebind protection. Second, I allow each subnet prefixes to connect to my DNS resolver.

And about the Debian package. Yeah, I was wondering if I should aim for a non-maintainer upload especially since dhcpcd5 was removed from testing recently. But I'd still have to sort some more things out before making this public (e.g. I'd like to add a systemd unit to the package as well, and then there is the question what to do with the dhcpcd5 package and executable name, etc.). In any case, I will first build that for my own purposes and then see where to go from there.

Regards,

Timo

Roy Marples schrieb am 08.08.2018 11:11:

> Hi Timo
> 
> I'm currently away from a computer until next week. The best answers I can give
> right now are
> 
> 1) the order also depends on carrier state. If an interface is down, it won't
> apply the delegation until it comes back up. This can happen outside of the
> delegation received being initially applied so there is currently no way of
> saying that the delegation as a whole is applied.
> 
> 2) I can work on adding a way to distinguish a delegation changing or renewing
> when I get back
> 
> 3) I can add this as well.
> 
> On a side note, I don't have the patience to maintain dhcpcd package on Debian
> so any updates to it there are very much appreciated.
> 
> Roy
> 
> On 5 August 2018 16:24:46 CEST, Timo Sigurdsson <public_timo.s@xxxxxxxxxxxxxx>
> wrote:
>>Hi,
>>
>>as I recently moved from a cable based internet connection to a PPPoE
>>connection, I also switched from ISC dhcp client to dhcpcd because ISC
>>dhcp client won't operate on ppp interfaces.
>>
>>The transition has been fairly easy, especially since dhcpcd makes
>>prefix delegation quite simple compared to ISC dhcp (which will request
>>a prefix but leave the delegation part up to you).
>>
>>Nevertheless, I have a few questions about how to handle things cleanly
>>and reliably in hook scripts:
>>
>>1) I need to restart my firewall whenever prefix delegation is
>>completed, i.e. after the last interface has been assigned a subnet of
>>the new prefix. Currently, I do that when reason=DELEGATED6 and
>>interface matches the last interfaces that I assign a delegated prefix
>>to. But I noticed that the order in which the hooks are executed
>>doesn't always seem to be the same. Imagine this configuration:
>>  interface ppp0
>>    ia_pd 1 enp2s0/1/64 enp3s0/2/64 enp4s0/3/64
>>Usually the hooks are called in the order enp2s0 enp3s0 and enp4s0. But
>>for some reason, one time hooks on enp4s0 were executed before enp3s0
>>even though the order in interface_order was correct (for debugging
>>purposes I logged the environment in my hook script upon each call and
>>noticed that in the log that the order of execution was different one
>>time).
>>
>>Therefore, I'm looking for a way to reliably execute an action whenever
>>the delegation is finished. Is there a good way to achieve this?
>>
>>2) One of the few things that was nice about ISC's dhcp client was the
>>fact that the environment of the hooks not only included the new
>>delegated prefix, but it also included the previous prefix. That made
>>it easier to distinguish the cases in which the prefix actually changed
>>(and was not simply renewed). Since the actions I need to execute only
>>need to be executed when a prefix actually changed, I'd like to know
>>whether it's possible to get that information in the environment of the
>>dhcpcd-hooks. I could of course write the prefix to a lease file and
>>compare them upon each invocation, but I was wondering if there is a
>>simpler way?
>>
>>3) In addition, when the hooks are executed with the reason DELEGATED6,
>>the environment only contains the subnet prefix which is assigned to
>>one of the interfaces configured for delegation but not the full prefix
>>which was obtained via DHCPv6. Is there a way to keep that in the
>>environment for all delegated interfaces? Again, I can write it to a
>>file and read it from there, but if there is a simpler way that doesn't
>>require additional files, I'd prefer that.
>>
>>FYI, I currently use dhcpcd 6.10.1 on Debian Stretch, but I'll package
>>the latest release for myself in the next few days if it makes any
>>difference.
>>
>>
>>Thanks and regards,
>>
>>Timo
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.