Re: Problem with IPv6 privacy addresses in 7.0

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
>> <[email protected]> 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
>>>> <[email protected]> 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.
> 
> 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 :)

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