[continued from previous message] 
  
 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%3Aiss 
 e%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 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2)