Re: Problem with IPv6 privacy addresses in 7.0

[Stefano Brivio <sbrivio@redhat.com>]

On Fri, 29 May 2026 14:48:47 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:

> On Thu, May 28, 2026 at 05:17:11PM +0200, Stefano Brivio wrote:
> > On Thu, 28 May 2026 16:34:02 +0200
> > Andrew Lunn <andrew@lunn.ch> wrote:
> >   
> > > > 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.    
> > > 
> > > Can pasta also use this scheme to order the addresses? Is there a way
> > > pasta can be independent of the order?  
> > 
> > pasta itself doesn't even care, it just inserts (copies) addresses one
> > by one as returned. The kernel cares, because it preferentially picks
> > the first one, as stored, within a given scope.
> > 
> > The problem is that they are inserted in the opposite order than one
> > would expect (that is, opposite to what's used by the kernel to select
> > them, and opposite to what's done for IPv4).
> > 
> > This (with an older kernel version) is quite "funny" (pasta by default
> > copies everything it finds to the inner namespace):  
> 
> Fwiw, a hypothetical tool which copied network configuration from one
> namespace to an independent one - or which saved network configuration
> to restore it later - would likely hit the same issue.

It's not even hypothetical: iproute2 has that functionality (ip address
save / restore) and addresses are restored in the wrong order on kernel
versions without this change:

# ip a a ::2 dev x && ip a a ::3 dev x
# ip a s x
2: x: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether c2:72:d1:7b:ac:26 brd ff:ff:ff:ff:ff:ff
    inet6 ::3/128 scope global tentative 
       valid_lft forever preferred_lft forever
    inet6 ::2/128 scope global tentative 
       valid_lft forever preferred_lft forever

# ip -6 a save dev x > dump
# ip a f x

# ip a restore < dump
# ip a s x
2: x: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether c2:72:d1:7b:ac:26 brd ff:ff:ff:ff:ff:ff
    inet6 ::2/128 scope global tentative 
       valid_lft forever preferred_lft forever
    inet6 ::3/128 scope global tentative 
       valid_lft forever preferred_lft forever

So scripts using this are anyway broken (well, they would get the order
right on every other save/restore, which makes the breakage even more
subtle).

-- 
Stefano