Re: Problem with IPv6 privacy addresses in 7.0

Stefano Brivio <[email protected]>
Newsgroups dev.linux.lists.regressions,org.kernel.vger.netdev
Organization Red Hat
Message-ID <20260601100826.4222a657@elisabeth>
On Fri, 29 May 2026 20:18:55 +0000
Tj <[email protected]> wrote:

> On 29/05/2026 20:04, Stefano Brivio wrote:
> > On Fri, 29 May 2026 18:28:58 +0000
> > Tj <[email protected]> wrote:
> >  
> >> I believe I hit this on a router using Debian 13 with v7.0.* kernel this week that
> >> uses systemd-networkd to configure IPV6 RA and prefix delegation after
> >> moving from v6.19.*.
> >>
> >> Symptom was the router could no longer reach public IPv6 addresses
> >> itself but forwarding was unaffected.
> >>
> >> The ISP (Starlink) provides a /64 prefix via RA and a /56 via DHCPv6. networkd
> >> allocates a static suffix address from both to the WAN-side interface.
> >>
> >> I discovered after much experimentation that instead of the usual /56
> >> address being the source it was choosing the /64 and failing.  
> > Do you really mean an address configured as /56, or a /64 address that
> > systemd-networkd derives from a /56 delegated prefix?
>
> Apologies - I should have been clearer. I meant addresses generated 
> *from the* respective prefixes - the addresses themselves are /64, yes!

Thanks for clarifying. Meanwhile, Jakub applied Fernando's revert patch
(I'm actually relieved, thanks Jakub ;)) but I had a look anyway into
how systemd-networkd handles these two cases.

They both seem to be hitting in the same way configure_address()
(src/network/networkd-address.c) with no attempt to define a given
order. After all, the only way to force a specific order would be to
remove and add addresses back, which systemd-networkd doesn't do.

So, whether the setup worked before the patch (and after the revert)
depends on the order of events / configurations, which in some sense
makes it even more important that we keep a stable order by default.

Contrary to NetworkManager, here, there's nothing we could really "fix".

-- 
Stefano
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.