Re: Problem with IPv6 privacy addresses in 7.0

CCing Beniamino, NetworkManager maintainer.

On Thu, May 28, 2026 at 3:32 PM Stefano Brivio <[email protected]> wrote:
> Not a bigger regression, but a regression definitely, even just for 'ip
> address' or 'ip address showdump' which would now go back to display
> / save addresses in the reversed order for IPv6 (only).

One could argue that the bug had to be fixed in iproute2 and not in
the kernel, to avoid breaking UAPI.

> Actually, an eventually fixed version of NetworkManager doesn't need to
> know the behaviour of the kernel: it can just order addresses by
> timestamps instead, as Fernando mentioned.

If the fix must be in NetworkManager, we only need to parse them in
non-reverse order like IPv4, I guess.

> And I'm not sure how relevant this is, but if we revert the fix,
> current combinations of NetworkManager / kernel versions would be
> anyway affected.

Probably many, for who knows how much time, unless all distros
backport the NetworkManager patch. Many don't backport much except a
small bunch of security fixes.

> So at this point the only robust / complete fix would be changing
> NetworkManager to sort addresses as needed. Are you suggesting that we
> should anyway try to minimise the temporal impact of this with a revert?

I don't think it's the "only" robust fix. Normally one would think
first about not breaking UAPI. Kernel's UAPI is not great or intuitive
in many places, but normally it's never improved to avoid breaking
backward compatibility. Adding a GIVE_ME_THE_RIGHT_ORDER flag could
help too, but I agree that it sounds a bit silly to have an opt-in
option to force the right behaviour.

Then, the only robust fix would be to fix pasta and iproute2.

Here we know of 2 affected userspace programs, but we don't know if
more could be discovered in the future.

That said, it is true that this case is very unintuitive. Insertion is
direct-order for both IPv4 and 6. Dump is reversed, but only for IPv6.
Userspace programs won't expect this at all. Programs that do it right
it's probably because they encountered a bug because they were
initially reading in direct-order, and changed to reverse-order. I
haven't dug into NetworkManager's history but I bet this was the case.

In this case I would be in favor of not reverting the kernel change,
and fix NetworkManager, but I'd like to hear Beniamino's opinion, as
I'm not being much involved in NetworkManager any more.

-- 
Íñigo Huguet