Re: Problem with IPv6 privacy addresses in 7.0

On Thu, May 28, 2026 at 4:53 PM Stefano Brivio <[email protected]> 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

> Pushing this to the extreme, one could argue for example that if we
> accidentally byteswapped the last 16 bits of some IPv6 addresses, and
> NetworkManager started to work around that, that would start being
> considered established UAPI...

Fair enough. To some extent, it could be considered a long-standing
bug. You can fix bugs even if userspace programs started to workaround
them.

But, on the other side, it can be easier considered just a bad design
that, after a long time, should not be changed anymore because it's a
established UAPI.

> > 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

> Wait... that's how confusing it is. That's also what I thought at the
> beginning of https://bugs.passt.top/show_bug.cgi?id=175, but it turned
> out that insertion is actually reversed for IPv6. Dump isn't.

Uh, OK. That's even worse because even scripts using `ip addr add ...`
may think the first inserted address is the primary.

As I said, I leave for Beniamino the considerations from the
NetworkManager side.

-- 
Íñigo Huguet