My take is that if you randomize the MAC addresses (*not* on a per-network basis), you probably have no reason for configuring a stable address. -- so you should doing RFC8981-only.
Conversation
Stable privacy addresses are only used by Android when MAC randomization is disabled. The stable privacy address feature otherwise isn't used. The issue with public IPv6 addresses isn't an intentional design choice by Android but rather a Linux kernel design issue.
2
1
So, if you stay on the same net, for a long period of time, no addresses remain stable? -- my recolection is that Android did RFC4941+RFC7217 of sorts... (i.e., *not* temp-only..)
1
By default, Android uses a persistent random MAC address for each network, a link-local IPv6 address based on the MAC address and an ephemeral public IPv6 address rotating daily for new connections and valid for up to a week per Linux kernel defaults for privacy address rotation.
2
1
If you disable MAC randomization, it uses the hardware MAC and a stable privacy address for the link-local IP address. Public addresses always work the same way: ephemeral rotating privacy addresses.
GrapheneOS adds ephemeral MAC rand and uses that as the default mode instead.
1
1
We still have both of their standard modes (per-network randomization, device MAC) but we add a 3rd mode.
The problem we need to fix is that when you move across networks, the Linux kernel doesn't start over with fresh public privacy addresses. Keeps counting down same timers.
2
1
Yes, that's (flawed) RFC4941 behaviour. However, of the top of my head, the patch I did for the Linux kernel should have taken care of that: patchwork.ozlabs.org/project/netdev
1
2
This probably does fix most of this issue but they don't backport these kinds of changes to kernel.org LTS releases. Android kernel LTS branches include all of the kernel.org LTS patches and a substantial amount of additional changes, but not this one.
2
1
Current mobile SoC generation uses the Linux 5.4.x LTS branch. 5.10.x is what will be used for hardware that's in development right now for next year. Pixels launch late in the yearly SoC generation cycle. If Pixel 6 has a Snapdragon SoC, it will be using Linux 5.4.x.
1
1
If they have their own SoC, then it's possible it will be using 5.10.x. Maybe they'll actually move to newer LTS branches within the lifetime of the device with their own SoC but it's incredibly uncommon. Linux kernel has a ton of regressions, particularly hardware-specific ones.
1
Pixel 5 is on 4.19.x, Pixel 4 is on 4.14.x and Pixel 3 is on 4.9.x. Qualcomm has moved to offering around 4 years of support for their new SoC hardware which means in the final year they'll be supporting a 5-6 year old kernel.
That's why the kernel.org LTS moved to 6 years of support: simply to provide 4 years of support for phones, and maybe 5 years if they start adopting the newer LTS branches faster. Maybe Google will do it differently for their SoC, but it's not what anyone else does.
1
IoT / embedded doesn't generally updates in the first place or at least not long enough / seriously enough for kernel LTS support to matter. Regardless, almost every production Linux device (i.e. not a hobbyist thing) never moves to a new LTS branch. That includes servers too.