IPv6 address insertion order (was Re: [PATCH net v2] Revert "ipv6: preserve insertion order for same-scope addresses")

David Gibson <[email protected]> Tue, 2 Jun 2026 16:44:19 +1000

Newsgroups	dev.linux.lists.regressions,org.kernel.vger.netdev
Message-ID	<ah57wxGjL7JBORR1@zatzit>

I get the impression there's a rough consensus that the best we can do
now is revert this change (already done), and make a new patch which
changes the insertion order to the "correct" one conditional on a new
flag.

Stefano has enough other fires to fight, so I'm taking a look at
implementing that.  Some initial thoughts, that I'm soliciting
feedback on:

1) I'm assuming the idea here is to add the new flag to nlmsg_flags in
   nlmsghdr

ifa_flags in ifaddrmsg would be the other candidate, but it looks like
it's encoding properties of the address itself, not about the action
of inserting it.  Plus all its bits are allocated, anyway.

2) Could we re-use NLM_F_APPEND?

The short description of this existing flag in linux/uapi/netlink.h is
"Add to end of list" which sounds like the right thing.  Looking
closer, however, it seems like what is' used for so far is things
where the entity added with the NEW<whatever> operation is itself a
list, and NLM_F_APPEND causes it to be added to rather than replaced.
It's not used for addresses at present, AFAICT the list of addresses
is a semantic level above the address entity itself.

So maybe re-using it for the thing I tentatively called
NLM_F_INSERT_LAST would be confusing?

On the other hand, it's not used for addresses at the moment, so
AFAICT there's nothing actually preventing us reusing it for this
purpose. That would save a bit - we only have 2 general and 4 NEW
specific bits left, by the looks of it.

3) What other things might need changing to take advantage of the
   kernel change

My innitial testing suggests that unknown nlmsg_flags bits are
currently ignored by the kernel.  That means that tools for which the
new behviour is desirable, but not essential may be able to avoid
probing - they can set the bit and hope.  I think that includes
passt/pasta and also iproute's save/restore functionality.

That said, things which might want updating:
 - iproute2 to use this for save/restore
 - netlink(7) man page to detail the new flag / new flag semantics
 - passt/pasta
 - network-manager, here we require the exact behaviour be maintained,
   so it would have to attempt the new flag, then apply the existing
   workaround (reversing the order itself) if that fails.  Maybe more
   trouble that it's worth?

Any others people can think of?

-- 
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

signature.asc (application/pgp-signature, 833 B)