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