Re: Problem with IPv6 privacy addresses in 7.0

On Fri, 29 May 2026 10:40:29 +0200
Beniamino Galvani [off-list ref] wrote:

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

quoted

quoted

quoted

quoted

quoted

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?  

The problem arises from how NetworkManager handles updates (e.g. after
receiving a Router Advertisement). At each update NM determines the
list of addresses to configure and checks if the addresses are already
in the right order in the kernel. If they aren't, NM removes and
re-adds them in reverse to achieve the desired order. Since kernel
7.0+, the order changed and the addresses always appear in the reverse
order.

Oh, I see now, thanks for explaining. That's a bit more than just
relying on a given order. On the other hand, it sounds like you have a
possible detection mechanism already implemented. :)

This creates 2 negative effects. First, it breaks source preference:
if users configured a profile with addr1=A, addr2=B because they
wanted A to be preferred, now B is preferred. This is not
NetworkManager-specific, it affects also simple scripts that add two
addresses (like the selftest that had to be changed in the commit).

At the same time, it fixes the kernel behaviour for anything that might
expect the same outcome as IPv4, or relying on iproute2's save /
restore functionality, as I'm showing here:

  https://lore.kernel.org/all/20260529114216.2e42c4dd@elisabeth/ (local)

...one might argue that it's more likely to break things than fixing
them at this point. I'm not sure.

But most importantly, at each commit NM detects that the order is
wrong and constantly removes and re-adds the addresses. This
continuous cycle is what causes the bug that Chris reported.

BTW, NM doesn't touch the temporary addresses directly; they are
automatically removed when the corresponding SLAAC address is
removed. Since the problem is not only about temporary addresses we
can't rely on timestamps.

So if the kernel change is not reverted you would need to have a
detection mechanism and change NetworkManager's behaviour according to
the detected kernel behaviour, correct? I guess it's nasty / ugly? But
doable?

quoted

quoted

quoted

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.  

I'm not familiar with home addresses, reading the RFC it seems that
setting the flag might have effect not only on source address
selection but also on other aspects?

In theory yes, that should affect the destination address as well in
the sense that getaddrinfo() should prefer the same type (home or
care-of) of address as the candidate source address, but I'm not aware
of any C library for Linux supporting ai_eflags / AI_EXTFLAGS that
would be needed for this (RFC 5014 section 11. discusses the
requirement).

As far as I know those flags are commonly used just to prefer a given
source address. I'm not sure if it's used by IMDSv2 tooling, I couldn't
find any evidence so far.

quoted

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

I remember we had users reporting issues about the ordering of IPv6
addresses, I'll try to find links to them.

I'm currently asking around about IMDSv2 cases. I think it would be
really interesting to see what users might have reported around
NetworkManager over the years, in one sense or another.

As to an hypothetical NLM_F_INSERT_LAST flag, I think that would be
fine for pasta(1) and containers, because the same "buggy" behaviour
that one might have on a host / parent namespace would be replicated to
other namespaces, and we're mostly interested in consistency.

The effect of keeping the "wrong" behaviour as default looks rather
problematic to me (see the iproute2 example) but we could also "fix"
iproute2 by setting the flag and maybe propose that as default after a
number of years.

-- 
Stefano