Your message dated Thu, 8 May 2025 22:42:43 +0300
with message-id
<CAPZXPQfHvqj3eq3MiwS9hHiwcKoQ2Lyb4vm+FVNgeLL=5m8=t...@mail.gmail.com>
and subject line Re: dhcpcd: Please disable IPv4LL by default for trixie
has caused the Debian Bug report #1099425,
regarding dhcpcd: Please disable IPv4LL by default for trixie
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1099425: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1099425
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: dhcpcd
Version: 1:9.4.1-24~deb12u4
Severity: normal
X-Debbugs-Cc: [email protected]
Hi Martin,
I was just looking through my dhcpcd.conf again and was reminded that I've
had to set `noipv4ll` very early on when starting to use dhcpcd and I've
had it ever since. Now that I think about it I also remember complaints
from collegues about this feature breaking their systems at very
inopportune times.
I think we should disable IPv4LL for trixie.
IPv6 link-locals perform the same function but with less breakage since
arguably more software is used to them being enabled. Since RFC 6540 "IPv6
Support Required for All IP-Capable Nodes" is a thing I don't see any point
in having this legacy feature enabled by default.
Ofc. I don't remember exactly what the problems with it were right now, but
I'll probably remember later if I think about it a while. IIRC it was
something to do with software incorrectly thinking the machine is online
due to the IPv4LL address/route, but I'm not sure.
--Daniel
signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
On Mon, 28 Apr 2025 14:43:33 +0300
=?UTF-8?Q?Martin=2D=C3=89ric_Racine?= <[email protected]>
wrote:
> On Sun, 20 Apr 2025 18:51:10 +0200 Daniel =?utf-8?Q?Gr=C3=B6ber?=
> <[email protected]> wrote:
> > Hi Martin,
> >
> > On Sat, Apr 19, 2025 at 05:27:12PM +0300, Martin-Éric Racine wrote:
> > > > Uff. I hadn't even considered that aspect yet. Yeah this would get
> > > > people
> > > > fuming :D
> > >
> > > It happened recently with one of my hosts. Thank goodness it happens
> > > to sit in the next room, so I was able to just walk over and restart
> > > ifupdown. That's one aspect where I prefer dhclient's behavior of
> > > retrying at regular intervals, rather than giving up and reverting to
> > > IPv4LL.
> >
> > Now imagine having to do that with a fleet of thousands or more and
> > exponentially scale effort to account for the rage factor ;-)
>
> It just occured to me that merely disabling ipv4ll in the config that
> Debian ships won't be enough. Once that's done, instead of reverting
> to ipv4ll, dhcpcd will exit. Fixing this requires a kuldge in ifupdown
> at the stanza that calls dhcpcd: if dhcpcd exits, we need to sleep 1
> minute and call dhdpcd again. It's basically a poor man's
> implementation of dhclient's periodic attempt at reconnecting if no IP
> was obtained.
I consider this issue closed as of 1:10.1.0-11:
* [patches]
+ Upstream Git cherry-picks: prevent exit on timeout. We keep on trying to
acquire an IP no matter what, switching to IPv4LL and back as needed.
dhcpcd now works just like avahi-autoipd did with dhclient's exit
loop: it switches back and forth between DHCPv4 and IPv4LL as needed.
On IPv6-capable hosts, IPv6LL is always present. Other IPv6 addresses
are acquired and deleted dynamically using RA/DHCPv6.
Martin-Éric
--- End Message ---
