Re: Problem with IPv6 privacy addresses in 7.0

On Thu, 28 May 2026 16:34:02 +0200
Andrew Lunn <[email protected]> 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):

---
$ pasta -6 -Ix --no-ra
# ip a a fd00::1 dev x
# ip a a fd43::1 dev x
# ip a a 2620::1 dev x
# ip link set dev x up
# ip a s x
2: x: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 86:de:6b:53:5c:05 brd ff:ff:ff:ff:ff:ff
    inet6 2620::1/128 scope global tentative 
       valid_lft forever preferred_lft forever
    inet6 fd43::1/128 scope global tentative 
       valid_lft forever preferred_lft forever
    inet6 fd00::1/128 scope global tentative 
       valid_lft forever preferred_lft forever
# pasta -6 --config-net --no-ra
# ip a s x scope global
2: x: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65520 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether 32:d4:5b:f0:fd:50 brd ff:ff:ff:ff:ff:ff
    inet6 fd00::1/128 scope global nodad 
       valid_lft forever preferred_lft forever
    inet6 fd43::1/128 scope global nodad 
       valid_lft forever preferred_lft forever
    inet6 2620::1/128 scope global nodad 
       valid_lft forever preferred_lft forever
# pasta -6 --config-net --no-ra
# ip a s x scope global
2: x: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65520 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether 1a:ed:4a:27:f6:9f brd ff:ff:ff:ff:ff:ff
    inet6 2620::1/128 scope global nodad 
       valid_lft forever preferred_lft forever
    inet6 fd43::1/128 scope global nodad 
       valid_lft forever preferred_lft forever
    inet6 fd00::1/128 scope global nodad 
       valid_lft forever preferred_lft forever
---

...at every level of namespacing, the order is swapped. Note that
iproute2 also reports them in the order they're sent over netlink.

> Maybe we should just make the order random, so equally breaking
> everybody, and pushing user space to not assume any order :-)

The thing is... the kernel assumes the order. :) But it also has to.

-- 
Stefano