Re: Problem with IPv6 privacy addresses in 7.0

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 6222 bytes --]

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 <fmancera@suse.de> wrote:
> 
> > On 5/28/26 8:42 PM, Fernando Fernandez Mancera wrote:
> > > On 5/28/26 7:21 PM, Stefano Brivio wrote:  
> > >> On Thu, 28 May 2026 18:01:27 +0200 Beniamino Galvani
> > >> <bgalvani@redhat.com> wrote:
> > >>  
> > >>> On Thu, May 28, 2026 at 05:24:28PM +0200, Íñigo Huguet wrote:  
> > >>>> On Thu, May 28, 2026 at 4:53 PM Stefano Brivio
> > >>>> <sbrivio@redhat.com> 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.  
> > >>
> > >> Yes, that's also the case, but:
> > >>  
> > >>>> 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.
> > >>  
> > >>> 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.
> > >>>  
> > >>>>>> 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.
> 
> > > 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.
> > >   
> > >> 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).

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]