Re: Problem with IPv6 privacy addresses in 7.0

[Beniamino Galvani <bgalvani@redhat.com>]

On Thu, May 28, 2026 at 05:24:28PM +0200, Íñigo Huguet wrote:
> On Thu, May 28, 2026 at 4:53 PM Stefano Brivio <sbrivio@redhat.com> wrote:
> > I think what's considered UAPI in this case isn't so clear-cut. I guess
> > it would have been pretty hard for anybody not familiar with
> > NetworkManager's codebase to imagine that an application would rely on
> > IPv6 addresses (and only IPv6) to be returned in the reverse order.
> 
> IMHO it's not because an application would rely on the order. It's
> because the order matters, as the first one is considered the primary.
> This is not NetworkManager specific. Or I am mistaken? I'm speaking by
> memory

Yes, exactly. If you do:

 ip addr add dev X 3fff::1/64
 ip addr dev dev X 3fff::2/64

then the old kernel chooses the address that was added last as source
address for outgoing communications. With the new kernel it chooses
the address that was added first.

I think that any script or network management tool that cares about
the source address selection is impacted. Indeed, the commit had
effects on one of the selftests, which had to be modified to change
the order of iproute2 invocations.
 
> > > If the fix must be in NetworkManager, we only need to parse them in
> > > non-reverse order like IPv4, I guess.
> >
> > But that would then require some form of detection, and, at least
> > according to Fernando, isn't the most robust option anyway, as ideally
> > NetworkManager shouldn't rely on the order at all.
> 
> True

Correct, if the new behavior is considered better, there should be a
way to detect which order must be used. Otherwise userspace tools
won't be able to maintain the same behavior with different kernels.

Beniamino