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

[Stefano Brivio <sbrivio@redhat.com>]

On Thu, 4 Jun 2026 21:39:09 +0300
Ido Schimmel <idosch@nvidia.com> wrote:

> On Thu, Jun 04, 2026 at 11:26:08AM +1000, David Gibson wrote:
> > So, I second Stefano's arguments for the most part, as well as
> > re-iterating that being broken by this change would require the
> > intersection of two unlikely conditions (misusing NLM_F_APPEND *and*
> > expecting the "wrong" order).
> > 
> > That said, Ido, if you're still not convinced I can do this as an
> > attribute.  It's more hassle, but I can make it work.  
> 
> I appreciate the survey that Stefano and you conducted, but there is
> still a non-zero chance of causing regressions by suddenly giving
> NLM_F_APPEND a meaning in RTM_NEWADDR. We already tried the
> "change-and-see-what-happens" methodology once with this feature and it
> backfired, so it's going to be quite painful if we miss again.
> 
> As I see it, we have three options:

Thanks for the helpful summary by the way.

> 1. Use NLM_F_APPEND. Relatively easy change in both the kernel and user
> space, but at the risk of reintroducing regressions.
> 
> 2. Add a new attribute (e.g., IFA_INSERT_MODE with DEFAULT/APPEND
> options). Less risky than #1, at the cost of a bit more code in both the
> kernel and user space.
> 
> 3. Do nothing. As I understand it, any production software (as opposed
> to a test script) that cares about the in-scope order will have to
> maintain a fallback anyway (e.g., iterating over IPv6 addresses in
> reverse).

It's not always enough, or needed, or practical, though:

a. 'ip address restore' could be "fixed" to load the addresses in a
   reversed order for IPv6, but what should 'ip address showdump' do at
   that point?

   Also reverse the order? Or not, because that's the order addresses
   were dumped in? I'm fairly sure 'ip address save' shouldn't reverse
   it. It would be more convenient for the other operations, but
   definitely wrong, because the kernel is picking addresses in the
   opposite order.

   All these are doable, some look questionable, but any of the possible
   workarounds looks hard to document, or even remember.

b. as to pasta(1) and passt(1): the regression introduced by the revert
   of the kernel change isn't a big one: after all, we had the right
   behaviour for just a few months.

   Similarly, if the kernel gives us a way to get it right, we would
   just stick to it for the future and be done with it. Adding a
   workaround for older kernels isn't a priority because there was no
   regression.

   Side note: the workaround would be rather impractical for us because
   we don't use dynamic memory allocation, but we certainly can't blame
   the kernel or anybody else for that.

c. regardless of how addresses are dumped to userspace, there would be
   no way to get the kernel to do what one reasonably expects it to do
   (also from established IPv4 practice): *use* addresses in order of
   insertion

By the way of c., you're explicitly excluding test scripts as they are
certainly less important, but does it really make sense to force people
to to maintain the kind of workaround Matthieu mentioned? Reporting it
here for convenience:

  https://github.com/multipath-tcp/packetdrill/commit/1b7cd4482ce8

> Therefore, the changes in #1 and #2 are not strictly
> necessary, yet they are uAPI that the kernel will have to maintain
> forever.
> 
> Given the above, my preference would be #3 -> #2 -> #1. The first two
> options expose the same capability to user space, so #1 doesn't buy us
> anything over #2, except a bit less code, but we risk introducing a
> regression.
> 
> Between #2 and #3, production software can't drop the fallback even if
> we implement #2, yet #2 requires us to maintain uAPI forever. I think we
> should accept that the divergence between IPv4 and IPv6 is not ideal,
> but at least it's predictable and dependable (Fernando is working on a
> ksft and documentation).
> 
> That being said, you can send an RFC for #1 and see what others think
> since at this point it's unclear who is still following the thread.

I think there's general consensus against #1 ("abusing" NLM_F_APPEND),
but still, I think #2 is very much needed and fundamentally harmless.

-- 
Stefano