Hi Debianites, tl;dr: ifupdown + dhcpcd-base in Trixie is broken in all but the most defaultest configurations, consequently isc-dhcp-client deprecation is a wash. It's a mess. Lets fix it.
Proposed ifupdown unstable upload: https://salsa.debian.org/debian/ifupdown/-/merge_requests/28 After a comprehensive review of the situation I see the following problems with ifupdown + dhcpcd-base: - [Independent control] over IPv6 and IPv4 operation from ifupdown is broken. A single `inet` stanza will enable both, so `inet6 static` also does SLAAC/DHCPv6. - Non-deterministic [daemon conflics] between ifup's dhcpcd instances and dhcpcd.service may cause boot or renew problems. - dhcpcd's [home grown IPv6 RA/SLAAC] client defies ifupdown assumptions, has [missing RA features] and integration holds [privacy surprises]. - interfaces(5) [settings not respected]: privext, autoconf, accept_ra, dhcp. I'm working on an ifupdown upload to fix most problems in unstable, but we also need to figure out what to do about Trixie and how much of the fixing should be ifupdown integration glue (which ened up being a good chunk of hairy code) vs dhcpcd patches (which would be **much** easier). ## What happened so far? As a reminder: starting with Trixie dhcpcd-base is now Priority:important (#1038882) instead of isc-dhcp-client. AFACT this only affects new installations, not upgrades so we've split the userbase. The ifupdown in Trixie and unstable still prefers dhclient over dhcpcd as #1006263 was never acted on. Therefore systems upgraded to Trixie continue to use dhclient unless the user manually replaced the isc-dhcp-client package based on advise from release-notes ("The isc-dhcp suite is deprecated upstream."). ## Users facing problems Since we released Trixie at least some users have actually attempted to switch to dhcpcd-base. Reports indicate a pattern of running into at least the [independent control] problem: - ifupdown: Stateful DHCPv6 with dhcpcd-base causes ifup to fail (#1110741) - ifupdown: Stateless DHCPv6 not working with dhcpd-base (#1110071) - ifupdown: dhclient not started after upgrading to Trixie (#1115725 msg#15). Before release we already had - ifupdown: ifup/down fail on inet6 interfaces with auto/dhcp method when using dhcpcd (#1065085) Unfortunately nobody uploaded the patch that was included. ## Implementation Context Before diving into details let's set the scene for those unfamilliar with these packages: The dhcpcd-base package provides the /usr/bin/dhcpcd binary, a combined DHCP client daemon and corresponding control interface, but no system service. ifupdown calls this binary when brining up/down an interface (see inet*.defn source files), A dhcpcd call will either connect to a running instance or start a fresh one. It has three daemonised modes of operation with separate control sockets: per-interface, per-interface-and-address-family and global "manager" mode. Several per-iface* and one global manager instance can end up running at the same time. A running per-iface instance shadows the global manager for control calls involving that interface. Currently ifupdown's dhcpcd integration uses per-iface instances, but when a global manager is running it connects to it instead see [daemon conflicts]. Each dhcpcd daemon can run with dual-stack (the implicit default), ipv6-only (-6) or ipv4-only (-4) enabled. The set of enabled address families cannot be changed once a daemon is running. This is important in the global manager case, however with per-iface instances distinct daemons handling 6/4/dual-stack can be started. The dhcpd *package* additionally provides a system service that will start dhcpcd in dual-stack global manager mode at boot. It will bring UP most interfaces automatically with IPv4 DHCP, IPv4-LL and IPv6 SLAAC and/or Stateful DHCPv6 as appropriate, but regardless of ifupdown configuration or whether a per-iface instance is already running(!), see [daemon conflicts]. ## Problem [Independent control] Currently ifupdown calls dhcpcd with dual-stack commands for the `inet` stanza. The `inet6` stanza otoh doesn't support dhcpcd at all. A /etc/network/interfaces that was working with dhclient such as: iface eth0 inet dhcp iface eth0 inet6 dhcp Will fail to ifup with dhcpd-base as `inet6 dhcp` doesn't support dhcpcd and it will bail with "No DHCPv6 client software found!". Not all users hit this problem as debian-installer is only capable of generating `inet6 auto` stanzas currently, and since dhcpcd's defaults (somewhat) match what you'd expect from that its not obviously broken. However this also implies ifupdown users have no control over whether IPv6 is brought up or not other than by fiddling with /etc/dhcpcd.conf. What's more concerning this /etc/network/interfaces will bring up SLAAC/DHCPv6 in addition to static addressess: iface eth0 inet dhcp iface eth0 inet6 static address 2001:db8::1/64 I doubt that's what anybody expects from this config. All this is clearly completely broken, it only superficially seems to work as our default config is dual-stack with `inet6 auto` which is what dhcpcd does by default. Action [dhcpcd per-af]: I'm switching ifupdown to calling dhcpcd such that address families are handled independently. ## Problem [daemon conflicts] The global manager started by dhcpcd.service has interface autodiscovery enabled. If it starts after a per-iface instance is already running the manager will also try to configure this interface i.e. we can end up with two DHCP daemons fighting over an interface. Clearly completely broken. In unstable dhcpcd.service starts After=networking.service (ifup) meaning it triggers this conflict reproducibly. In Trixie no Before/After on networking is declared so the conflict will happen non-deterministically -- oh joy. The design space of how to fix this is complicated. I've explored most of it and the current implementation is version four or so ;-). The main challanges are 1) --waitip doesn't always work, 2) instance selection is fickle, 3) changing instance type needs special handling. Brave souls wanting to know the details of all the frustrating quirks may consult my long string of upstream issues: https://github.com/NetworkConfiguration/dhcpcd/issues?q=is%3Aissue%20author%3ADanielG Long-term plan [dhcpcd interface conflict patch]: All we really need to do to fix this properly in dhcpcd is ignore interfaces that already have a daemon running during discovery. My code review suggests this would be a simple change of a couple of lines. A dhcpcd patch could be suitable for Trixie even, but so far dhcpd's maintainer has refused to consider downstream changes -- else I'd have fixed this well before Trixie already :-]. Truth be told I'm pretty annoyed I had to spend more than a full blown focused work week on designing, implementing, documenting this hacky fix on the ifupdown side instead of spinning a 10 LoC dhcpcd patch in half an hour, but here we are. Ugh. Anyway. Action [use global dhcpcd from ifupdown]: For now the ifupdown centric solution I came up with is to switch from per-interface instances to using the global manager (starting it from ifup as needed). This way ifupdown and dhcpcd.service interoperate nicely though the glue code need to make it work is substantial. ## Problem [home grown IPv6 RA/SLAAC] With dhclient we used to use the kernel's RA/SLAAC implementation. When dhcpcd starts IPv6 on an interface it disables these in favor of its own userspace implementation. Problem is ifupdown currently assumes it can control the kernel implementation using several sysctls which dhcpcd doesn't respect. Looking at dhcpcd's git history it seems it used to respect these years ago but not anymore. dhcpcd sets with the following sysctls: net.ipv6.conf.$IFACE.addr_gen_mode=1 (disables auto link-local address) net.ipv6.conf.$IFACE.autoconf=0 (disables SLAAC) net.ipv6.conf.$IFACE.accept_ra=0 (disables picking up (default) routes) Naturally it doesn't clean these up when releasing an interface so if you run into fun when you switch to static addressing at runtime. Gah. Obviously none of this works corretly anymore, but we can fix it with some more glue code :-). ## Problem [settings not respected] Action [dhcpd.sh wrapper]: To fix the impedance mismatch between ifupdown settings and dhcpcd I implemented a wrapper (dhcpcd.sh) that generates dhcpcd cmdline options. This works out well, except one particular configuration simply has no equivalent in dhcpcd settings: accept_ra=1. What this should do is only allow picking up routes on interfaces that aren't configured for forwarding. Right now my implementation errors in this case but since it's the default for `inet6 dhcp` that's not very satisfactory. Question [silently ignore accept_ra=1]?: Maybe we should accept the misconfiguration risk and silently do the equivalent of accept_ra=2 here instead? I've filed an upstream bug about it in any case: https://github.com/NetworkConfiguration/dhcpcd/issues/540 ## Problem [privacy surprises] In addition to RA/SLAAC options interfaces(5) also supports the `privext` option. Naturally this is also ignored by our current dhcpcd integration. Since the /etc/dhcpd.conf default to enable RFC 7217 privacy addressing (`slaac private`) is incongruent with the interfaces(5) default of privext=0 we cause nasty surprises for upgrading users that have hardcoded EUI/MAC based SLAAC addressess into DNS. ## Problem [missing RA features] Action: [Avoid dhcpcd in inet6/auto]: I think some users may need features only available in the of the kernel RA implementation (I do) so I'm including an escape hatch: dhcpcd is not used for `inet6 auto` unless dhcp=1 (non-default). Note: The noipv6rs option isn't good enough here as it will still addr_gen_mode=1 preventing link-local assignment entirely. There is an upstream PR for this one at least: https://github.com/NetworkConfiguration/dhcpcd/pull/380 ## Next steps As things stand dhcpcd integration with ifupdown has many problems. I'm planning to make an ifudown upload to unstable if there are no major objections. There are still a couple of TODOs (prefix delegation, RFC 7217, accept_ra=1 risk assessment) but the code should be good enough for unstable. That leaves us to think about what to do about current and future Trixie users: Retract the isc-dhcp-client deprecation? Fix it all in a stable update? Leave it broken-as-is and leave extra-fun^TM transition problems for Forky? Something inbetween? Thoughts? --Daniel
