It is mostly laid out in this [0] document. RID = F(Prefix | Client_DUID | IAID | Counter | secret_key) Where: + secret_key is at least 128 bits, be cryp

It is mostly laid out in this [0] document. RID = F(Prefix | Client_DUID | IAID | Counter | secret_key) Where: + secret_key is at least 128 bits, be cryptographically generated, and as difficult to access as the system allows. It cannot be re-used for any other purpose. + F is at least SHA-1, but should probably be SHA-256 or above. It can be any cryptographically secure hash function that returns 64 or more bits. (And MD5 is explicitly banned). + Client_DUID is the Client Identifier sent to the DHCP. + IAID is the 32bit integer from the IA_NA option sent to the DHCP. And then, once you have that randomised ID: if(IPV6_ADDR < IPV6_ADDR_LOW || IPV6_ADDR > IPV6_ADDR_HI){ IPV6_ADDR = IPV6_ADDR_LOW + IPV6_ADDR % \ (IPV6_ADDR_HI - IPV6_ADDR_LOW + 1); } Where: + IPV6_ADDR starts out as RID. + IPV6_ADDR_HI is the upper bound of leaseable addresses. + IPV6_ADDR_LOW is the lower bound of leaseable addresses. If this produces an address that is invalid or already leased, increment Counter and try again. The result is that addresses in the same prefix are completely dissimilar, and opaque. When the system rolls the address, there is no way to predict what the next address will be, or what the previous address was. Windows, Android, macOS, and Linux tend to roll to a new IPv6 address either on system restart, or on an hourly basis, depending on settings. Thus, on par with current IPv4 addresses for tracking. [0] https://datatracker.ietf.org/doc/html/draft-ietf-dhc-stable-privacy-addresses-02 https://datatracker.ietf.org/doc/html/draft-ietf-dhc-stable-...