[continued from previous message] 
  
 I understand your concern and I share the goal of having IPv6 just 
 work. What I'm proposing here is in fact in service of that ideal: 
  
 My goal is for systems currently defaulted to using IPv6 via the kernel to 
 transition to respecting RA M/O flags too -- by launching dhcpcd when 
 appropriate. 
  
 To get there without hacks or re-architecting ifupdown I see a need to 
 transition such systems to having `inet6 auto` lines in /e/n/interfaces so 
 that ifupdown can come in and decide to launch the DHCPv6 client. 
  
 My off-the-cuff solution was to add inet6 lines from postinst when 
 appropriate along with a NEWS entry to make sure at least people that are 
 paying attention know what's going on. 
  
 Perhaps a more implicit approach, "just pretend inet6 auto is there", would 
 be less disruptive and it's what I ended up implementing now, but since 
 ifupdown people agree we should be moving in the direction of ifupdown-ng I 
 don't want to spend cycles on changing ifupdown's internals to do this 
 without hacks. 
  
  
 On Thu, Oct 23, 2025 at 10:19:44PM +0200, Thorsten Glaser wrote: 
 > So, I gave it a spin and had to fix up something already ;) 
  
 Applied your suggestions. Force pushed. Lintian nits will come when this 
 gets closer to uploading. 
  
 > With this, the interface does indeed come up, wait, and 
 > I get the expected IPv4 address… but not the expected IPv6 
 > address: 
  
 Hmm. I think I know whats going on but can you post output for: 
  
     $ ps fax | grep dhcpcd   # to see which instance types are active 
     $ sysctl net.ipv6.conf | grep -E 'accept_ra |autoconf' 
  
 to make sure and confirm you were using dhcpcd before switching to my code? 
  
 I think dhcpcd was running in dual-stack mode previously, then if you 
 ifdown;ifup with my code (without rebooting) the ipv6 sysctls won't get 
 reset to defaults (remember: dhcpcd mangles them and doesn't clean them up) 
 and that's why SLAAC is no longer working. Lacking an inet6 line ifup wont 
 (re)set accept_ra/autoconf. 
  
 I knew dhcpcd not cleaning up its sysctls was an issue but hadn't quite 
 figured out why. Now we can see the problem clearly. 
  
 I've added more hacks to make this work. See 
 https://salsa.debian.org/debian/ifupdown/-/merge_re 
 quests/28/diffs?commit_id=acc9455eef698b4d51f08c3dfa87e31bdcc1147e 
  
 To test it you have to either revert to ifupdown=0.8.44 before upgrading or 
 touch /run/network/dhcpcd-inet6-stanza-hack.needed to get the equivalent 
 behaviour. LMK how that works out on your machine. 
  
 On Thu, Oct 23, 2025 at 10:23:46PM +0200, Thorsten Glaser wrote: 
 > >With this, the interface does indeed come up, wait, and 
 > >I get the expected IPv4 address… but not the expected IPv6 
 > 
 > Perhaps it makes sense to run dhcpcd per-interface with only 
 > the expected address families enabled and convince upstream 
 > that this is the necessary way forward for it to become viable. 
  
 I am still hoping we can show upstream the right path here, but that's an 
 ongoing effort everyone's welcome to help with on the upstream issue 
 tracker :-). 
  
 > It just cannot be that a DHCP client fucks up my IPv6 rtsol, 
 > when not configured to touch IPv6 it should keep its hands 
 > off it. 
  
 That's not what's happening, my transition handling is clearly just not 
 complete yet. 
  
 > And because we need to have the ability to use a configuration where one 
 > interface has DHCP on IPv4 only but the other on IPv6, a (one) global 
 > dæmon with a global address family setting cannot possibly work in a 
 > generic setting such as a Debian network configuration integration. 
  
 This paragraph is a bit too jumbled for my language parser not sure I get 
 what you mean but let me try anyway: 
  
 For all the sharp edges I found dhcpd does give us what I think you want 
 here. The only case where things get tricky is inet6 auto with dhcp=1 but I 
 don't think that's what you're thinking about? 
  
 FYI: Even the global daemon does have per-interface and per-af settings on 
 the cmdline and dhcpcd.conf. Its really quite flexible now that I've filed 
 down the edges a bit ;-). 
  
 --Daniel 
  
 -----BEGIN PGP SIGNATURE----- 
  
 iQIzBAABCAAdFiEEV6G/FbT2+ZuJ7bKf05SBrh55rPcFAmkKJfIACgkQ05SBrh55 
 rPcXPQ/9HVpCqSz1U3bW8uVXyYK9wLKsAHPUvE3+153nGCpaQv43RzaWowLM3dXZ 
 dHIY6Ylei327Xly1J6jNB0B6dq2vRsV8vKfWfS/AHqZG4cD1mRZDvyQlqUJhy8nK 
 0yeR266UU5HkBJfpGG0IAQ+OYxie8y+dDCNwUDGfsZHO08Qa2Xkg/ChvxrTij1Vr 
 s2jSL+pEXScseEpdsg+DhuQmQSJlnnVIpRBpPXaqcKf3or1VRDBnZmhHBpjHZui7 
 aqXqSFZu78k3IZ4mnwA6HB4/H6H2NWeAAz5Z36/ogSE5u3WNMJeGcRwNQoMOBTeH 
 QO3/6s6m86gHvwXcdkXqWtTsGUBX8jU7JxqbmSgXBGWxkW5ykpBW7tkt21fPNvgL 
 2mQDCzyUV+SWcq8LaV3AKYSHKU2RTi8WooR2dz4mCfMxZYHuvrwFX56RzcDY9gNu 
 zfc5P1wApm7Usp7XHQkxePo1sD0wn4zfNnxAbs4Ugmfq6L/MGIxLa+8YEWk9JJjL 
 wX5OFTpdXA/s/cX3AC5yJKY3MVOahiaD10Ei/99cFtW1s+sYKm9JLGs/mfMWeEC5 
 VKAq8QgOjQTQ0F9Ott6nQe5wshQxhoukR0MRNIatOsRJhvtMao7wQLxo1Q1FN7pr 
 PwFNDEXZxTat19oAusNS8toB/eaaa8t7d08BlYRD1Pwz2sGPODY= 
 =uxyF 
 -----END PGP SIGNATURE----- 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2)