From: David Gibson <david@gibson.dropbear.id.au>
To: Stefano Brivio <sbrivio@redhat.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
Thorsten Leemhuis <regressions@leemhuis.info>,
Fernando Fernandez Mancera <fmancera@suse.de>,
Jakub Kicinski <kuba@kernel.org>,
netdev@vger.kernel.org, Yumei Huang <yuhuang@redhat.com>,
Ido Schimmel <idosch@idosch.org>,
Justin Iurman <justin.iurman@gmail.com>,
David Ahern <dsahern@kernel.org>,
ihuguet@redhat.com,
Linux kernel regressions list <regressions@lists.linux.dev>
Subject: Re: Problem with IPv6 privacy addresses in 7.0
Date: Fri, 29 May 2026 14:48:47 +1000 [thread overview]
Message-ID: <ahkar8tE5M6u0_zZ@zatzit> (raw)
In-Reply-To: <20260528171710.1a5f6b6b@elisabeth>
[-- Attachment #1: Type: text/plain, Size: 3414 bytes --]
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.
> ---
> $ 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
>
--
David Gibson (he or they) | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you, not the other way
| around.
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2026-05-29 4:48 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-21 13:53 Problem with IPv6 privacy addresses in 7.0 Chris Adams
2026-05-27 0:57 ` Jakub Kicinski
2026-05-27 1:06 ` Chris Adams
2026-05-27 1:31 ` Jakub Kicinski
2026-05-27 21:13 ` Chris Adams
2026-05-27 21:16 ` Fernando Fernandez Mancera
2026-05-27 21:51 ` Jakub Kicinski
2026-05-27 21:51 ` Chris Adams
2026-05-27 21:59 ` Fernando Fernandez Mancera
2026-05-27 23:07 ` Jakub Kicinski
2026-05-28 5:38 ` Stefano Brivio
2026-05-28 10:46 ` Fernando Fernandez Mancera
2026-05-28 11:12 ` Stefano Brivio
2026-05-28 11:29 ` Fernando Fernandez Mancera
2026-05-28 12:29 ` Thorsten Leemhuis
2026-05-28 13:32 ` Stefano Brivio
2026-05-28 14:02 ` Thorsten Leemhuis
2026-05-28 14:15 ` Íñigo Huguet
2026-05-28 14:53 ` Stefano Brivio
2026-05-28 15:24 ` Íñigo Huguet
2026-05-28 16:01 ` Beniamino Galvani
2026-05-28 17:21 ` Stefano Brivio
2026-05-28 18:42 ` Fernando Fernandez Mancera
2026-05-28 18:50 ` Fernando Fernandez Mancera
2026-05-28 19:22 ` Stefano Brivio
2026-05-29 4:47 ` David Gibson
2026-05-29 8:40 ` Beniamino Galvani
2026-05-29 17:40 ` Stefano Brivio
2026-05-28 14:34 ` Andrew Lunn
2026-05-28 15:17 ` Stefano Brivio
2026-05-29 4:48 ` David Gibson [this message]
2026-05-29 9:42 ` Stefano Brivio
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ahkar8tE5M6u0_zZ@zatzit \
--to=david@gibson.dropbear.id.au \
--cc=andrew@lunn.ch \
--cc=dsahern@kernel.org \
--cc=fmancera@suse.de \
--cc=idosch@idosch.org \
--cc=ihuguet@redhat.com \
--cc=justin.iurman@gmail.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=regressions@leemhuis.info \
--cc=regressions@lists.linux.dev \
--cc=sbrivio@redhat.com \
--cc=yuhuang@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox