All of lore.kernel.org
 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: 36+ 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
  -- strict thread matches above, loose matches on Subject: below --
2026-05-29 18:28 Tj
2026-05-29 20:04 ` Stefano Brivio
2026-05-29 20:18   ` Tj
2026-06-01  8:08     ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.