Comment 24 for bug 1068756

The situation appears to have improved somewhat in Xenial. The net/ipv6/conf/all/disable_ipv6 sysctl appears to have become a no-op in recent kernels, so when 10-ipv6-privacy.conf gets applied during the bootup sequence (by systemd-sysctl.service) it does *not* change the effective per-device setting for already existing devices (which defaults to 0).

However, devices that show up later in the boot process, the 10-ipv6-privacy.conf-set value of net/ipv6/conf/default/disable_ipv6 is inherited, so privacy extensions remain enabled by default for userspace-created devices.

Finally, NetworkManager will by default bounce the disable_ipv6 sysctl on devices it's bringing up. That seems to cause the device's use_tempaddr sysctl to be re-inherited from net/ipv6/conf/default/disable_ipv6, ensuring the setting from 10-ipv6-privacy.conf is applied.

In summary, the following seems to be true in Xenial:

- Physical kernel-plumbed interfaces (e.g., "eth0") managed through interfaces(5): Privacy extensions disabled by default.
- Physical kernel-plumbed interfaces (e.g., "eth0") managed through NetworkManager(8): Privacy extensions enabled by default.
- User-space created interfaces (e.g., "bond0" or "vlan123"), regardless of management method: Privacy extensions enabled by default.

Another thing worth noting is that the version of NetworkManager shipped by Xenial uses RFC7217 Interface IDs by default. These are randomly generated and do not leak MAC addresses, yet they are stable on any given link/network. They will change when the link prefix changes, thus preventing tracking between networks. So where NetworkManager is used, there is IMHO very little rationale remaining for enabling RFC 4941 privacy extensions by default.

https://blogs.gnome.org/lkundrak/2015/12/03/networkmanager-and-privacy-in-the-ipv6-internet/