Associated MAC randomization is enabled by default in Android. It uses a persistent per-network random MAC address. When MAC randomization is enabled, they use a link-local IP address based on the MAC address. They only use the stable privacy address feature when MAC rand is off.
Conversation
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.
2
1
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
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.
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.
1
Show replies