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

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:

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

Thanks