Re: Problem with IPv6 privacy addresses in 7.0
flat view
From: Stefano Brivio <hidden>
Date: 2026-05-28 15:17:18
Also in:
regressions
On Thu, 28 May 2026 16:34:02 +0200 Andrew Lunn [off-list ref] wrote:
quoted
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