On Wed, 16 Apr 2025 14:20:03 +0200 Daniel =?utf-8?Q?Gr=C3=B6ber?= <d...@darkboxed.org> wrote: > On Wed, Mar 26, 2025 at 04:23:34PM +0200, Martin-Éric Racine wrote: > > 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. > > 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. > > However, I'm not entirely convinced that we can presume IPv6LL to be > > available at all times. I welcome opinions on this specific point. > > The way I see it IPv4LL was never widely adopted (by applications) in the > first place due to only showing up when there's network problems > already. OTOH IPv6 LLs are always there where applications can use them > unless users intervene with ill-advised disablement of IPv6. Agreed. Unless someone purposely disables IPv6 support or connects via an old router that doesn't support IPv6, IPv6LL should always work. > > 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. > > We'd have to remove that Provides yeah. That's already gone. My point mostly was that if we add 'noipv4ll' to the config Debian ships, we technically no longer support the feature by default (although it can obviously be re-enabled by commenting it out). Martin-Éric
