Re: Problem with IPv6 privacy addresses in 7.0

On Thu, May 28, 2026 at 09:22:14PM +0200, Stefano Brivio wrote:

On Thu, 28 May 2026 20:50:48 +0200
Fernando Fernandez Mancera [off-list ref] wrote:

quoted

On 5/28/26 8:42 PM, Fernando Fernandez Mancera wrote:

quoted

On 5/28/26 7:21 PM, Stefano Brivio wrote:  

quoted

On Thu, 28 May 2026 18:01:27 +0200 Beniamino Galvani
[off-list ref] wrote:
 

quoted

On Thu, May 28, 2026 at 05:24:28PM +0200, Íñigo Huguet wrote:  

quoted

On Thu, May 28, 2026 at 4:53 PM Stefano Brivio
[off-list ref] wrote:  

quoted

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.  

Yes, that's also the case, but:
 

quoted

quoted

This is not NetworkManager specific. Or I am mistaken? I'm
speaking by memory  

...from what I understood of the issue at hand there's a part that's 
specific to NetworkManager here, because NetworkManager replaces / 
deletes the Privacy Extensions addresses, instead of different 
addresses, because it relies on that specific (reversed) order.

Anyway, yes, I see your point about UAPI now.
 

quoted

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.
 

quoted

quoted

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  

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.  

My remark here is about whether NetworkManager needs to detect this
at all. If it used timestamps to detect recent / older addresses, as 
Fernando mentioned, then you wouldn't need any detection at all,
right? Or is there something else we're missing?
 

Ohno. Now that Beniamino and Iñigo mentioned it, this will likely break
many other environments. In essence, many tools relies on the previous 
ordering to identify which address is the primary one.

E.g cloud tooling communicating with the metadata server via IMDS(v2) to 
configure IPv6 primary and secondary addresses. They are likely relying 
on the ordering for that.

I haven't seen any tool specifically relying on insertion order for
this so far and I'm having a hard time believing this kind of tooling
wouldn't rely explicitly on home / care-of addresses or different
labels -- see RFC 5014 and RFC 6724 Section 5. (or, perhaps clearer,
the examples in section 10.1, in particular rule 4. and rule 6.

But I'll look for more convincing examples in a bit (maybe you have some
at hand?)

This is all implemented by __ipv6_dev_get_saddr() and friends, by the way.

quoted

quoted

So maybe we could fix whatever is wrong with NetworkManager and 
temporary addresses order but I don't think this will scale for the 
cloud tooling with the primary/secondary issue.
  

quoted

By the way, if really needed, one could detect that with the
equivalent of:

ip a a ::2 dev lo && ip a a ::3 dev lo && [ $(ip -6 -j a | jq -rM '.
[] .addr_info[0].local') = ::3 ] && echo wrong || echo right

...depending on the application, that's not necessarily practical,
but so far we have no evidence of any application needing to do that
at all.

Plenty of tools (NetworkManager included) uses netlink so this isn't 
useful for them.

For now I am more in favor of the revert and to look for an alternative 
for pasta situation (like using a flag or something). But I am not a 
maintainer so it isn't my call :)

One question I started wondering about later is: should the flag affect
insertion or reporting, in case? I think we would need one for
insertion, otherwise it's not really generic / functional.

I'd certainly agree.  The bug? oddity? inconsistency? is on the
insertion side so the fix should be on that side (whether or not it's
conditional on a new flag).  If we "fixed" it on the reporting side
we'd instead be creating another bug that cancels its effect for some,
but not all, purposes.

The idea of NLM_INSERT_LAST seems marginally less ghastly to me than
NLM_F_DUMP_REVERSED, though I'm not sure I could articulate why.
Perhaps because we could also allow the former for IPv4 too (as a
no-op).

quoted

*facepalm* I just noticed the "with the equivalent of", disregard this 
last part tho.

Right, yeah, having a netlink implementation makes that a bit more
convenient. :)

-- 
Stefano

-- 
David Gibson (he or they)	| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you, not the other way
				| around.
http://www.ozlabs.org/~dgibson