Netdev List
 help / color / mirror / Atom feed
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 --]

  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