Re: Problem with IPv6 privacy addresses in 7.0

[Stefano Brivio <sbrivio@redhat.com>]

Hi Fernando, Jakub,

On Wed, 27 May 2026 23:59:47 +0200
Fernando Fernandez Mancera <fmancera@suse.de> wrote:

> On 5/27/26 11:51 PM, Chris Adams wrote:
> > Once upon a time, Jakub Kicinski <kuba@kernel.org> said:  
> >> On Tue, 26 May 2026 20:06:41 -0500 Chris Adams wrote:  
> >>>> Hi! Adding more people to CC. Do you know if you upgraded from 6.18
> >>>> or 6.19?  
> >>>
> >>> It was 6.19 to 7.0.
> >>>  
> >>>> Would you be able to try testing with some commits reverted?
> >>>> On a quick look the candidates would be:
> >>>>
> >>>> cb3de96eea66 ("ipv6: preserve insertion order for same-scope addresses")  
> >>>
> >>> It's this one.  
> >>
> >> Phew, the second one was mine :)
> >>  
> >>> I figured out that it happens after stopping a VM (and I usually
> >>> start/stop a VM for a bit in the morning, which is why it happened more
> >>> than once).  So I set up a VM with a nested VM, running up-to-date
> >>> Fedora 44, and then was able to bisect pretty easily, and it landed on
> >>> this commit.
> >>>
> >>> Fedora is using NetworkManager, and IIRC NM does some part of privacy
> >>> address management (right?).  NM didn't change, so maybe this commit is
> >>> confusing something in NM?  
> >>
> >> Sounds plausible, pretty sure we knew this commit was risky to begin
> >> with, but we had no direct proof that it'd break real life users.
> >>
> >> Revert is the right course of action here. Would you be willing/able
> >> to send the revert with your problem description and a Fixes tag
> >> pointing to the reverted commit?  
> > 
> > I did want to add a little more test note:
> > 
> > It's definitely an interaction with NetworkManager.  If I stop NM and
> > run my VM start/stop test, nothing unexpected happens after.  If NM is
> > running and I do my VM test, when the next router advertisement is
> > received, NM replaces the privacy addresses.
> >   
> 
> As someone that is experienced in NetworkManager, I can confirm it is 
> related. NetworkManager is querying the IPv6 address and when the 
> connection is configured with ipv6.ip6-privacy=2 (prefer-temp-addr), 
> NetworkManager creates a route to make the system use the temporary 
> address for outgoing connections by default.
> 
> If the order is messed up, the address picked will likely be too. One 
> could argue that this is partially fault of NetworkManager and that it 
> should check the timestamps or preferred times rather than order.. but 
> well, the rule is "do not break userspace".
> 
> I hope this clarifies things.

Not entirely. I'm looking into this right now, but note that the purpose
of that commit is to *preserve* the order of addresses as they were
inserted, not to mess it up.

Before that, addresses were stored and returned via netlink *reversed*
compared to the insertion, which is rather surprising, also because
it's the opposite of what we do for IPv4 addresses, and caused issues
with pasta(1) as it copies addresses into containers in the same order
as reported via netlink.

Do you happen to know exactly in which way the order happens to be wrong
now?

Also note that userspace was broken and fixed a couple of times:

  https://bugs.passt.top/show_bug.cgi?id=175#c10

so I would look into fixing that properly if doable. If it takes too
long and this is causing issues for a lot of people meanwhile of course
it might make sense to revert, but I'd give it a quick try at least.

-- 
Stefano