GrapheneOS adds an ephemeral MAC randomization option and that's the default for us. It can be changed to per-network MAC randomization or disabling MAC randomization, which are the 2 options in AOSP and the stock OS on Pixels without modifications to them.
Conversation
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.
1
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
Why not add it to GrapheneOS kernel in top of Google's code?
1
We don't want to deviate from appearing to be a regular Android device. I linked that commit in the issue I have open with them about the issue. If they apply it as the fix for the issue, then that's fine. It's not the only issue though. We ideally need to flush all the state.