Dhcpcd replacing dhclient for Debian Trixie or perhaps networkd?
ISC's dhclient is being replaced by dhcpcd in Debian for stability. Debate on network configuration tools for Trixie favors networkd for IPv4 but raises privacy concerns and inefficiencies with default IPv6 settings. Networkd is criticized for IPv6 and dual-stack setups, lacking privacy emphasis.
Read original article
The article discusses the replacement of ISC's discontinued DHCP client, dhclient, with dhcpcd in Debian. The author mentions achieving stability in the package both upstream and in Debian, with some final adjustments needed. Additionally, there is a debate on which network configuration tool should be included in minimal installations for Trixie, with a focus on networkd due to its presence in most Debian ports with systemd. The author tests networkd for IPv4 configuration but highlights issues with its default IPv6 settings, citing privacy concerns and inefficiencies. Despite networkd's suitability for IPv4-only networks, it is deemed inadequate for IPv6 or dual-stack installations, especially on a distribution emphasizing privacy and network security. The article concludes with the author's critique of networkd's approach to address generation and privacy concerns.
7 commentsDHCP OPTIONS feature (that systemd-network does not have) still has major places within enterprise and homelab networks.
Example of Nintendo DHCP Workaround using ISC DHCP: https://github.com/egberts/isc-dhcp-server-nintendo
So, excuse me while I vehemently resist systemd-networkd.
Obviously, tailscale is in the wrong for trying to infer whether or not /etc/resolv.conf is under system control rather than just providing a knob to tune that behavior but that doesn't change the fact that my DNS gets subtly broken when using dhcpcd.
Great to see some sanity in Debian again. Now please also get rid of systemd altogether and generally simplify the IP address configuration and routing to the level of OpenBSD.
But this is a very good start.
- the assertion is made that networkd creates link local addresses - it does not, the kernel does.
- the assertion is made that configuring how the _kernel_ sets up link local addresses must automatically and silently affect how userspace network managers configure global addresses. This is of course not the case, and one might ask for such a feature, but its absence most definitely does not mean that it is "utterly inadequate for IPv6 or dual-stack installations".
- the assertion is made that userspace network managers independently listening on RA packets and creating SLAAC global addresses independently of the kernel must set the stable-privacy interface flag. This is not the case, such flags are owned by the kernel and cannot be set by userspace. Being absent does not mean the the addresses are not private or stable, it just means they are not kernel managed, and thus a different (RFC 7217 compliant) algorithm is used as explained on https://www.freedesktop.org/software/systemd/man/latest/syst...
- the assertion is made that the suffixes generated by the _kernel_ to set up link local addresses must automatically and silently be copied by userspace network managers to configure global addresses on the respective interfaces. This is also of course not the case, the algorithm is described in the link above, and again asking for such a new feature is fine, but its absence does not mean that it is "utterly inadequate for IPv6 or dual-stack installations".
- the assertion is made that certain defaults must be changed to meet the OP's personal preferences. This of course cannot really be done in a project like systemd, where we try our best to keep backward compatibility, even if we don't always succeed. The desired configuration is very easy to setup, for example this should suffice:
[Network] IPv6PrivacyExtensions=yes IPv6LinkLocalAddressGenerationMode=stable-privacy
[IPv6AcceptRA] Token=prefixstable
As usual, it would be best to ask clarification questions and investigate how things actually work _before_ making definitive assertions on a blog post about a component for which one has a cursory understanding at best, but that's not nearly as much fun as a good ol' systemd bashing blog post, right?
Yeah that's a hard pass.
> Adding IPv6PrivacyExtensions=yes to the above exposed another issue: instead of using the fe80 address generated by the kernel, networkd adds a new one.
But... I'm not sure this is a big problem? One of the big ideas of IPv6 is that you can have many IPs on an interface; throwing on one more isn't ideal, but I don't think it's a hard blocker.