Re: Problem with IPv6 privacy addresses in 7.0

On Thu, May 28, 2026 at 4:53 PM Stefano Brivio [off-list ref] 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.

quoted

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