Hi Thorsten,
On Thu, Oct 23, 2025 at 08:48:34PM +0200, Thorsten Glaser wrote:
> >> I’ve never seen inet6 auto used anywhere, only inet6 static (and
> >> I’ve not personally encountered inet6 dhcp yet, and given rtadvd
> >> and rtsol work, I don’t quite see the use for most networks).
> >
> >Strange, given that this is what d-i will produce by default -- if the
> >installation network has IPv6 RAs at least.
>
> As of which release? ;-)
Quite a while ago: 2002 AFAICT from a quick look at d-i/netcfg git logs.
Happy to be proven wrong, but for now I'm going to continue assuming inet6
auto lines should be the norm in typical Debian installations.
> [...] I’ve since switched away from d-i to just debootstrap plus a small
> shell script that does what d-i does to the installed system (except it
> doesn’t copy the live CD’s network config), as has been a growing trend
> among (at least) Grml enthusiasts for years.
It falls on you to keep up with system changes then. Hope you're an avid
NEWS reader :-).
> >IMO if you need to make changes that deep it's alright to have to go to the
> >dhcp client config files to do it honestly, unless you disagree?
>
> I find “hands off my resolv.conf” (the standard config tends to not
> change the system hostname, domain and timezone, but since I saw this
> in the manpage I added it) is the one single change to DHCP client
> configuration I need in most places where I need any. This could also
> be handled by the hooks or something, but if there isn’t any mechanism
> for this at the moment, don’t lose any time for this, the other issues
> are more important.
>
> Just I don’t consider “hands off my hostname, domain and timezone”
> something I should even *have* to specify, and “hands off my resolv.conf”
> the one useful high-level toggle here (defaulting to write it is okay,
> but perhaps I run a recursive resolver myself and have that in the conf).
I think all of these we could pass overrides down to dhcpcd from ifupdown
if we needed to (--nohook/--nooption), but AFAIK the system defaults are
alright currently. Testing welcome.
> >> Note that it could also be started from /etc/init.d/dhcpcd, so
> >> ordering there also needs to be correct.
> >
> >Naturally, but I do think that should also be possible. I'm just not
> >familliar with sysvinit's ways.
>
> Yes, I was just pointing out that not everyone uses systemd.
> An X-Start-Before: in the LSB pseudoheader should suffice, but
> the debian-init-diversity mailing list is available to help,
> once you have a concrete setup.
Thanks for the hint on which pseudoheader to use! I'll see to it Martin
makes that change along with the systemd service fix if we end up going
that route.
> >> Likely not going to happen, as it has no security support.
> >
> >Well given that we've shipped isc-dhcp-client in Trixie already without
> >properly moving all users over that ship has kinda already sailed. Now we
> >have to support it. See #1106121.
>
> It’s not the first package we ship in a stable release for users’
> convenience that has no support. (And it allows people to decouple
> “upgrade to trixie” from “switch to kea”, as kea in bookworm was…
> not quite ready.)
Right. I do think switching to dhcpcd is the right long term solution
anyhow. My preferred solution is porting the fixes to Trixie too, I'm just
not sure whether the needed changes are "small" enough for a stable update
at this point :D.
> >If we remove the release-notes notice at least fewer users might try to
> >switch and consequently run into problems. Idk. if that'd really be a
> >good idea its just a thought.
>
> If the SRM agree and you manage to get this fixed in sid, I’d like
> for the fixes to end up in trixie, so less people run the unsupported
> software (and it’d look bad for Debian if we recommended people to
> stay on it for one more release, when the client is already… four?
> years dead upstream).
Its looking plenty bad already :-(.
> >Eeeeerm. Well. I've seen dhclient crash mysteriously after long runtime
> >leaving systems without IPs somehow. So that's not a sure bet
>
> How? If it crashes it won’t remove the currently working IPs.
You (and me) would think so! Somehow that's what the systems ended up
looking like. I didn't check logs at the time unfortunately and switched to
dhcpcd since, so I have no clue if it's still happening. I'm watching bugs
on isc-dhcp so we'll see if anything crops up.
My theory is the crash happened just after a lease expired which would take
the IPs/routes with it. Perhaps the ISP took a (long) while to do
maintainance on their DHCP server. If dhclient crashes as it's trying for a
new lease you'll be left with a system without IPs and no DHCP client
running and no mechanism that would restart it. Sad face.
> But at least IPv6 will still work in that case, as it’s kernel-
> managed ;) (see above…), so it’s recoverable.
IPv6 win, nice.
> >Thinking about this some more I may consider requiring `inet6 auto` in the
> >future for this configuration, but not without a proper transition and
> >ample notice.
>
> That directly contradicts what you wrote above. That would mean
> ifupdown would break kernel defaults without the user explicitly
> asking for it, by merely the user specifying IPv4 configuration.
>
> This will be a net loss because at the moment, IPv6 “just works”
> with no configuration for many people because of the kernel default,
> and this should not change to the worse.
Let me expand on this a bit then since it doesn't seem to be clear.
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_requests/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
Attachment:
signature.asc
Description: PGP signature