Re: Problem with IPv6 privacy addresses in 7.0

On Thu, 28 May 2026 14:29:50 +0200
Thorsten Leemhuis <[email protected]> wrote:

> On 5/28/26 13:29, Fernando Fernandez Mancera wrote:
> > On 5/28/26 1:12 PM, Stefano Brivio wrote:  
> >> On Thu, 28 May 2026 12:46:05 +0200
> >> Fernando Fernandez Mancera <[email protected]> wrote:  
> >>> On 5/28/26 7:38 AM, Stefano Brivio wrote:  
> >  
> >> - regardless of this, would there be a way to make NetworkManager
> >>    robust to the order?
> >>
> >>    I'm asking this because yes, strictly speaking, you might say this
> >>    change breaks userspace (NetworkManager), but at the same time it
> >>    fixes another part of it (pasta), and changing it back would break
> >>    pasta again (in a way we can't really fix).  
> >
> > Ugh, that is a mess.  
> 
> Well, yes, but one that happens regularly. :-D
> 
> The problem here is that it was reported only some months after the
> culprit landed, as fixing the regression through a revert or so could
> now cause a bigger regression. Do we assume this to be the case here?

Not a bigger regression, but a regression definitely, even just for 'ip
address' or 'ip address showdump' which would now go back to display
/ save addresses in the reversed order for IPv6 (only).

> It
> sounds like pasta would "only" be broken about as much as it was before
> -- then a revert or something like that is the right solution to get
> back to the status quo. Or does pasta already depend on the new behavior
> somehow and would now break even more if we reverted the culprit?

It doesn't specifically depend on it. There might be users depending on
it because, if they choose to copy container addresses from the host,
they will be reversed, and also picked by the kernel in the reversed
order (if all other criteria based on scope and prefix length are the
same).

The likelihood of that breaking setups should be relatively small. It's
just not zero so if we had another sane option to keep this "fixed" I
would probably prefer that.

> Then it's really a mess. :-/

I guess not so much, it shouldn't be a drama for pasta and containers.

But then again if we revert this, how do we fix the issue later,
without resorting to any of the ugly things below?

> But there are ways to fix even this, it's just that most of them are
> ugly. Like adding some bit somewhere to /proc/ or so that a fixed
> NetworkManager (if it's the only affected app) could flip by default to
> change the things from the old behavior to the new one; and one pasta
> could check that bit and warn. Config options are also an option, but
> that's even uglier.

Actually, an eventually fixed version of NetworkManager doesn't need to
know the behaviour of the kernel: it can just order addresses by
timestamps instead, as Fernando mentioned.

And I'm not sure how relevant this is, but if we revert the fix,
current combinations of NetworkManager / kernel versions would be
anyway affected.

So at this point the only robust / complete fix would be changing
NetworkManager to sort addresses as needed. Are you suggesting that we
should anyway try to minimise the temporal impact of this with a revert?

> >>    Now, I suppose NetworkManager is much more universally used and it's
> >>    definitely a more mature project so it's a bigger userspace breakage,
> >>    but at the same time it's a ton of containers (Podman uses pasta by
> >>    default, Docker/moby optionally via rootlesskit) we might introduce a
> >>    regression for.  
> > 
> > I think the main argument here is: while we know it is affecting
> > NetworkManager, we cannot know if it is breaking something else. The
> > kernel rule is usually "do not break userspace" and this is likely
> > considered a regression from my understanding. Cc'ing Thorsten as he is
> > an expert on regressions.  
> 
> From the mail at the top of the thread it definitely sounds like one.

-- 
Stefano