3 ms·

IPv6 has a few extensions, that have been implemented in just about every OS, to make things more private. [0][1][2] To put it simply, badly implemented IPv6 m

• gruez 5y ago
  >To put it simply, badly implemented IPv6 makes it easier, but all the ways to make it on-par with IPv4 have been widely deployed since 2016. Not really. According to the wikipedia article[1], you still have an unique address per device. It rotates daily, but you still can uniquely identify a device on a daily basis. This wouldn't be possible with ivp4 with NAT. [1] https://en.wikipedia.org/wiki/IPv6#Stateless_address_autoconfiguration_.28SLAAC.29 https://en.wikipedia.org/wiki/IPv6#Stateless_address_autocon...
  • shakna 5y ago
    If you read RFC7721 which I linked above, you'll find that "SLAAC temporary addresses" is the bare minimum (from 2012), but not the recommended process (over a decade later). And is therefore not what most platforms use today. > DHCPv6 temporary addresses have the same properties as SLAAC temporary addresses (see Section 4.6). On the other hand, the properties of DHCPv6 non-temporary addresses typically depend on the specific DHCPv6 server software being employed. Recent releases of most popular DHCPv6 server software typically lease random addresses with a similar lease time as that of IPv4. Thus, these addresses can be considered to be "stable, semantically opaque". [DHCPv6-IID] specifies an algorithm that can be employed by DHCPv6 servers to generate "stable, semantically opaque" addresses. [0] The very last line of that Wikipedia paragraph points you to RFC8064 [1], which is a standard, and completely obsoletes the early "SLAAC temporary addresses", and makes the rest of the paragraph nothing but historical information. (The mention of Windows XP should stand out as a red flag, there.) > By default, nodes SHOULD NOT employ IPv6 address generation schemes that embed a stable link-layer address in the IID. [0] https://datatracker.ietf.org/doc/html/rfc7721#section-4.7 https://datatracker.ietf.org/doc/html/rfc7721#section-4.7 [1] https://datatracker.ietf.org/doc/html/rfc8064 https://datatracker.ietf.org/doc/html/rfc8064
    • gruez 5y ago
      Is there a tl;dr description as to how the current address generation/randomization process works?
      • shakna 5y ago
        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-...