From: dxld@darkboxed.org 
  
 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 
  
 [continued in next message] 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2)