Re: Problem with IPv6 privacy addresses in 7.0

[Stefano Brivio <sbrivio@redhat.com>]

On Fri, 29 May 2026 20:18:55 +0000
Tj <tj.iam.tj@proton.me> wrote:

> On 29/05/2026 20:04, Stefano Brivio wrote:
> > On Fri, 29 May 2026 18:28:58 +0000
> > Tj <tj.iam.tj@proton.me> 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