One actual problem not mentioned in the article is that, by default, SLAAC embeds the MAC address of the interface when generating the autoconfigured IPv6 addre

One actual problem not mentioned in the article is that, by default, SLAAC embeds the MAC address of the interface when generating the autoconfigured IPv6 address. As an example, if an interface’s MAC address was `01:23:45:67:89:ab`, the lower 64 bits of the SLAAC assignment (the “host” part) results in an IPv6 address of `:123:45ff:fe67:89ab` (the extra `ff:fe` bytes are constant, making it more obvious the surrounding bytes are likely a MAC address). This has huge implications to privacy, since even as you roam and change networks (and thus the upper part of the address changes), the lower 64-bits stay exactly the same, making it easy to “follow” a device from session to session and site to site. This was addressed by an update to SLAAC: “Privacy Extensions for Stateless Address Autoconfiguration in IPv6” in RFC 4941[0]... but it has to be explicitly enabled on a per-interface basis. A great thing about this feature is that these random, private addresses timeout and become “deprecated” (and a new random address gets assigned to the interface and used for new connections), making it harder for third-parties to track connections over the long-term. Unfortunately, address privacy is a SLAAC thing, so if you want the benefit of registering a device on your network (via DHCPv6, so you can actually correlate IPv6 traffic on your network to a device), you don’t get the benefits of SLAAC’s privacy extensions. [0] https://tools.ietf.org/html/rfc4941 https://tools.ietf.org/html/rfc4941