Forgot to add references:

[1] 9e792f7ef7298080c058fbc2d36a4e60e596dae9
[2] f9fc93690aef7a56f62a051de6231fe2af699728

ALso, I plan to merge each commit as a single cherry pick and push them in one go. Looks to me like the best way, if merging them in a single commit is preferred please let me know.

Given this is a new feature, I think it will be much more clean to merge all related commits into a single one when MFCing.

In D54382#1242898, @zlei wrote:

Also, I plan to merge each commit as a single cherry pick and push them in one go. Looks to me like the best way, if merging them in a single commit is preferred please let me know.

Given this is a new feature, I think it will be much more clean to merge all related commits into a single one when MFCing.

Thanks for the feedback. If this is the cnsensus I can go this way, using the commit message from 31ec8b6407fdd5a87d70265762457c67ce618283 but adding the required tags and "cherry picked" lines. And a comment about the other related commits.

From a testing perspective, I can confirm that the solution has been working well on stable/15 for quite some time on a laptop and several desktops. I recently cherry-picked it at work onto our build machine and started testing it on servers running stable/15 as well, although only a small subset of those systems use EUI-64–based IPv6 addressing.

I’m not convinced that squashing these commits would add much value. None of them introduces critical breakage - the system will never panic. The MFC workflow is well known and clear, and bisecting can always be properly done against not only the main branch.

In D54382#1242817, @madpilot wrote:

Forgot to add references:

[1] 9e792f7ef7298080c058fbc2d36a4e60e596dae9

This is a behaviour change, which is why I initially didn't mark it as an MFC candidate.
That said, it's very limited in scope, and only allows users to do new things, I don't expect this to break any existing setups, so there should be relatively little risk to including it.

[2] f9fc93690aef7a56f62a051de6231fe2af699728

This is a fix to the above, so either take both or neither.

I had some time to test the below{1} merge on stable/15 following the traditional, still recommended upgrade path with intermediate reboot (install kernel, reboot, install world, reboot).
I hereby report that the stable/15 system with IPv6 EUI-64–based primary address and IPv6 static address configured as alias0 encountered no problems after the first and second reboot. Moreover, with stableddress enabled in the loader.conf[2], the system did not encounter any issues either and after the first reboot system was already following RFC 7217 requirements. Thus, it was proven that even if stableaddr will become the default at some point, the ABI will not be broken, and old ifconfig(8) will be able to take care of interface addressing.

! In D54382#1242898, @zlei wrote:
Given this is a new feature, I think it will be much more clean to merge all related commits into a single one when MFCing.

When I was testing the initial implementation, I believed that ABI breakage must happen, but it was a wrong assumption. The above tests have proven that squashing commits

• sys/netinet6: Implement RFC 7217 (cherry picked from commit 31ec8b6407fdd5a87d70265762457c67ce618283) and
• sys/netinet6: Fix ABI breakage introduced with RFC 7217 support (cherry picked from commit 0ec13430c583830cc4d29640787e2d154b140e31)

could be valuable and appreciated.

[1]:

sys/netinet6: Fix SLAAC for interfaces with no /64 LL address (cherry picked from commit 9e792f7ef7298080c058fbc2d36a4e60e596dae9)
sys/netinet6: Implement RFC 7217 (cherry picked from commit 31ec8b6407fdd5a87d70265762457c67ce618283)
sys/netinet6: Fix ABI breakage introduced with RFC 7217 support (cherry picked from commit 0ec13430c583830cc4d29640787e2d154b140e31)
sys/netinet6: Use atomic(9) for dad_failures counter (cherry picked from commit 0c94dc9da7c238603e43c55ca6da64c417fc2204)
sys/netinet6: fix memory corruption in in6_ifadd (cherry picked from commit f9fc93690aef7a56f62a051de6231fe2af699728)

[2]:

net.inet6.ip6.use_stableaddr="1"
net.inet6.ip6.stableaddr_netifsource="2"