On Wed, 26 Mar 2025 16:23:34 +0200 =?UTF-8?Q?Martin=2D=C3=89ric_Racine?= <[email protected]> wrote: > On Mon, 3 Mar 2025 14:24:15 +0100 Daniel =?utf-8?Q?Gr=C3=B6ber?= > <[email protected]> wrote: > > 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. > > I don't oppose disabling this – quite the contrary: I'd rather avoid > dhcpcd falling back to IPv4LL if dhcpcd fails at getting a response > from DHCPv4; I'd rather have it background its IPv4 process and retry > DHCPv4 at regular intervals, just like dhclient does. > > However, I'm not entirely convinced that we can presume IPv6LL to be > available at all times. I welcome opinions on this specific point. I > also ponder whether we can claim to offer a suitable substitute for > avahi-autoipd anymore if we disable IPv4LL in dhcpcd's stock > configuration.
I still welcome informed opinions on this specific point. Martin-Éric
