Have you tried changing the IPv6 'Privacy' setting to "Enabled (prefer temporary addresses)"? At least, that's what it looks like in KDE's plasma-nm. I don't know about the Gnome/GTK interface.

The GNOME interface doesn't have such option. I don't know how it could have one, Fedora still has NetworkManager 1.0.6 and e603c86926ce48a7dd53b892fe85d506e6322378 is only available in the 1.1 dev branch.

Presumably either that KDE option does nothing at all or KDE has reimplemented a chunk of NetworkManager functionality for dubious reasons.

RFC4941 privacy extensions were supposedly enabled in NM 1.0.4. So it should be working out of the box in NM 1.0.6 on Fedora 23, but it's not. On the same hardware, ancient Windows and OS X (years older) do not do this. I thought this was working on Fedora 21 or 22, but can't immediately test it.

What's supposed to land in NM 1.2 for Fedora 24 is RFC7217 which is stable privacy addressing.

OK so the MAC address itself is leaked as the IID, even aside from the ipv6 privacy extensions issue:

Fedora 23 + Firefox 42
https://drive.google.com/open?id=0B_2Asp8DGjJ9aFl5SnZzRzEybkE

OS X 10.9 (2013) + Firefox 43
https://drive.google.com/open?id=0B_2Asp8DGjJ9ZkJONUNzS1pKZWs

I get essentially identical results on Android, as I do on OS X. I guess this is more of a privacy concern than a security concern, although the lack of temporary (rotating) globally available IPs via RFC4941 does slightly bother me.

Further I'm confused because this blog entry says privacy extensions enabled and turned on by default in NM 1.0.4, and yet evidence to the contrary unless I'm misunderstanding something significantly.
https://blogs.gnome.org/lkundrak/2015/12/03/networkmanager-and-privacy-in-the-ipv6-internet/

OK, the GNOME Settings Network interface may not have any privacy configuration options, but nm-connection-editor does, and setting that to "Enabled (prefer temporary address)" does use RFC4941 addresses.

'git log --grep=4941' shows that the way this is configured (and the default values) have changed several times, I wouldn't be surprised if things got lost in the shuffle.

I can confirm using nm-connection-editor > connection:edit > ipv6 settings > ipv6 privacy extensions "enabled (prefer temporary address)" and then 'sudo systemctl restart NetworkManager' fixes this without further action.

This adds:
IPV6_PRIVACY=rfc3041
to this file:
/etc/sysconfig/network-scripts/ifcfg-<linkname>

When I Google serach RFC3041(2001), it's been obsoleted by RFC4941 (2007), and at least one result comes up saying 3041 is harmful. So is it a 3041 implementation or is this just wrongly named in the configuration file?

That's just how the ifcfg-rh configuration backend serializes it, NetworkManager implements RFC4941.

Seems like setting ipv6.ip6-privacy 2 (enabled, prefer temporary IP) causes avahi-daemon to totally flip out and flood the journal upon preferred_lft being reached and the ipv6 address becoming deprecated. See upstream bug and also bug 1221676 for more info.

This is still a problem on Rawhide. nmcli reports value -1 for ipv6.ip6-privacy.

Hit by the same problem (reproduced on 2 fresh F23 installations) 

Looks like there is a problem with related sysctl toggles in case privacy option is enabled (and DCHPv6 is in use?)

accept_ra_pinfo=0 which means the interface will not generate IPv6 address from prefix

net.ipv6.conf.enp9s0.accept_ra = 1
net.ipv6.conf.enp9s0.accept_ra_defrtr = 0
net.ipv6.conf.enp9s0.accept_ra_from_local = 0
net.ipv6.conf.enp9s0.accept_ra_min_hop_limit = 1
net.ipv6.conf.enp9s0.accept_ra_mtu = 1
net.ipv6.conf.enp9s0.accept_ra_pinfo = 0            <----!!!!
net.ipv6.conf.enp9s0.accept_ra_rt_info_max_plen = 0
net.ipv6.conf.enp9s0.accept_ra_rtr_pref = 0
net.ipv6.conf.enp9s0.autoconf = 1
net.ipv6.conf.enp9s0.use_tempaddr = 2

Workaround: on a running interface execute

sysctl -w  net.ipv6.conf.enp9s0.accept_ra_pinfo=1

and wait for next Router Advertisement, then the tempaddr appears

This is non-persistent because NM overwrites accept_ra_pinfo=0 on next down/up cylce :-(


Suggestion: in case 
use_tempaddr>0 also set accept_ra_pinfo=1


In case dhclient is also in the game, here options and config

/sbin/dhclient -d -q -6 -N -sf /usr/libexec/nm-dhcp-helper -pf /var/run/dhclient6-enp9s0.pid -lf /var/lib/NetworkManager/dhclient6-***-enp9s0.lease -cf /var/lib/NetworkManager/dhclient6-enp9s0.conf enp9s0


/var/lib/NetworkManager/dhclient6-enp9s0.conf
send fqdn.fqdn "****"; # added by NetworkManager
send fqdn.encoded on;
send fqdn.server-update on;

also request dhcp6.name-servers;
also request dhcp6.domain-search;
also request dhcp6.client-id;


configuration retrieved with "nmcli c show <UUID>" and here the important/related entries shown below.


connection.id:                          enp9s0
connection.type:                        802-3-ethernet
connection.autoconnect:                 yes
connection.autoconnect-priority:        0
ipv4.method:                            manual
ipv4.dns:                               192.168.1.1
ipv4.dns-search:                        
ipv4.addresses:                         192.168.1.2/24
ipv4.gateway:                           192.168.1.1
ipv4.routes:                            
ipv4.route-metric:                      -1
ipv4.ignore-auto-routes:                no
ipv4.ignore-auto-dns:                   no
ipv4.dhcp-client-id:                    --
ipv4.dhcp-send-hostname:                yes
ipv4.dhcp-hostname:                     --
ipv4.never-default:                     no
ipv4.may-fail:                          no
ipv6.method:                            auto
ipv6.dns:                               
ipv6.dns-search:                        
ipv6.addresses:                         
ipv6.gateway:                           --
ipv6.routes:                            
ipv6.route-metric:                      -1
ipv6.ignore-auto-routes:                no
ipv6.ignore-auto-dns:                   no
ipv6.never-default:                     no
ipv6.may-fail:                          yes
ipv6.ip6-privacy:                       2 (enabled, prefer temporary IP) <-!!
ipv6.dhcp-send-hostname:                yes
ipv6.dhcp-hostname:                     --
GENERAL.NAME:                           enp9s0
GENERAL.UUID:                           ***
GENERAL.DEVICES:                        enp9s0
GENERAL.STATE:                          activated
GENERAL.DEFAULT:                        yes
GENERAL.DEFAULT6:                       yes
GENERAL.VPN:                            no
GENERAL.ZONE:                           --
GENERAL.DBUS-PATH:                      /org/freedesktop/NetworkManager/ActiveConnection/0
GENERAL.CON-PATH:                       /org/freedesktop/NetworkManager/Settings/0
GENERAL.SPEC-OBJECT:                    /
GENERAL.MASTER-PATH:                    --
IP4.ADDRESS[1]:                         192.168.1.2/24
IP4.GATEWAY:                            192.168.1.1
IP4.DNS[1]:                             192.168.1.1
IP6.ADDRESS[1]:                         2001:a61:**:**:2**:**ff:fe**:****/128
IP6.ADDRESS[2]:                         fe80::2**:**ff:fe**:****/64
IP6.GATEWAY:                            fe80::2665:11ff:fe8e:68a0

DHCP6.OPTION[1]:                        dhcp6_client_id = ***
DHCP6.OPTION[2]:                        dhcp6_name_servers = fd00::2665:11ff:fe8e:68a0
DHCP6.OPTION[3]:                        requested_dhcp6_name_servers = 1
DHCP6.OPTION[4]:                        rebind = 2880
DHCP6.OPTION[5]:                        max_life = 7200
DHCP6.OPTION[6]:                        preferred_life = 3600
DHCP6.OPTION[7]:                        requested_dhcp6_domain_search = 1
DHCP6.OPTION[8]:                        requested_dhcp6_client_id = 1
DHCP6.OPTION[9]:                        life_starts = 1455175073
DHCP6.OPTION[10]:                       ip6_address = 2001:***:***:***:2**:**ff:fe**:****
DHCP6.OPTION[11]:                       ip6_prefixlen = 128
DHCP6.OPTION[12]:                       renew = 1800
DHCP6.OPTION[13]:                       dhcp6_server_id = 0:3:0:1:24:65:11:8e:68:a0

I've played around with a scriptlet and it turned out, that something near/inbetween DHCPv6 will reset accept_ra_pinfo even if tempaddr is enabled:

Feb 11 09:53:42 *** root[565]: 01-PB.sh/up: set sysctl/ipv6/conf/accept_ra_pinfo=1 for enp9s0
Feb 11 09:53:42 *** nm-dispatcher[456]: net.ipv6.conf.enp9s0.accept_ra_pinfo = 1
Feb 11 09:53:42 *** systemd[1]: iscsi.service: Unit cannot be reloaded because it is inactive.
Feb 11 09:53:42 *** chronyd[854]: Source 192.168.1.1 online
Feb 11 09:53:42 *** root[584]: 99-PB.sh/up: already active sysctl/ipv6/conf/accept_ra_pinfo=1 for enp9s0
Feb 11 09:53:43 *** chronyd[854]: Selected source 192.168.1.1
Feb 11 09:53:44 *** avahi-daemon[844]: Joining mDNS multicast group on interface enp9s0.IPv6 with address fe80::*:*ff:fe*:*.
Feb 11 09:53:44 *** avahi-daemon[844]: New relevant interface enp9s0.IPv6 for mDNS.
Feb 11 09:53:44 *** avahi-daemon[844]: Registering new address record for fe80::*:*ff:fe*:* on enp9s0.*.
Feb 11 09:53:44 *** NetworkManager[30335]: <info>  Activation (enp9s0) Beginning DHCPv6 transaction (timeout in 45 seconds)
Feb 11 09:53:44 *** NetworkManager[30335]: <info>  dhclient started with pid 597
Feb 11 09:53:45 *** dhclient[597]: XMT: Confirm on enp9s0, interval 960ms.
Feb 11 09:53:45 *** dhclient[597]: RCV: Reply message on enp9s0 from fe80::*:*ff:fe*:*.
Feb 11 09:53:45 *** NetworkManager[30335]: <info>    valid_lft 7200
Feb 11 09:53:45 *** NetworkManager[30335]: <info>    preferred_lft 3600
Feb 11 09:53:45 *** NetworkManager[30335]: <info>    address 2001:*:*:*:*:*ff:fe*:*
Feb 11 09:53:45 *** NetworkManager[30335]: <info>    nameserver 'fd00::*:*ff:fe*:*'
Feb 11 09:53:45 *** NetworkManager[30335]: <info>  (enp9s0): DHCPv6 state changed unknown -> bound, event ID="70:b2:d2:d1|1455180473"
Feb 11 09:53:45 *** NetworkManager[30335]: <info>  Policy set 'enp9s0' (enp9s0) as default for IPv6 routing and DNS.
Feb 11 09:53:45 *** nm-dispatcher[456]: Dispatching action 'dhcp6-change' for enp9s0
Feb 11 09:53:45 *** root[616]: 01-PB.sh/dhcp6-change: set sysctl/ipv6/conf/accept_ra_pinfo=1 for enp9s0
Feb 11 09:53:45 *** nm-dispatcher[456]: net.ipv6.conf.enp9s0.accept_ra_pinfo = 1
Feb 11 09:53:45 *** root[629]: 99-PB.sh/dhcp6-change: already active sysctl/ipv6/conf/accept_ra_pinfo=1 for enp9s0

scriptlet stored in /etc/NetworkManager/dispatcher.d/ as 01-PB.sh and softlinked to 99-PB.sh

#!/bin/sh

export LC_ALL=C

IF="$1"
ACTION="$2"
prog=$(basename "$0")

if [ "$IF" != "enp9s0" ]; then
	exit 0
fi

if [ "$ACTION" = "up" -o "$ACTION" = "dhcp6-change" ]; then
	if [ "$(sysctl -n net.ipv6.conf.$IF.accept_ra_pinfo)" = "0" ]; then
		logger "$prog/$ACTION: set sysctl/ipv6/conf/accept_ra_pinfo=1 for $IF"
		sysctl -w net.ipv6.conf.$IF.accept_ra_pinfo=1
	else
		logger "$prog/$ACTION: already active sysctl/ipv6/conf/accept_ra_pinfo=1 for $IF"
	fi
fi

exit 0

This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

ipv6.ip6-privacy still doesn't default to 1 or 2. Please change version info to F25.

The correct solution would be setting ipv6.addr-gen-mode to stable-privacy by default. Also adding a way of configuring addr-gen-mode to the GUI tools.

as explained in `man NetworkManager.conf`, ipv6.ip6-privacy defaults to -1.
that default means to fallback to global configuration in NetworkManager.conf -- and if absence of such configuration, use /proc/sys/net/ipv6/conf/default/use_tempaddr.

NM doesn't have an ultimate default value for ipv6.ip6-privacy. If it is neither specified per-connection nor in NetworkManager.conf, it inherits the value from sysctl -- defined outside of NM.


(In reply to Nicholas Miell from comment #14)
> The correct solution would be setting ipv6.addr-gen-mode to stable-privacy
> by default. Also adding a way of configuring addr-gen-mode to the GUI tools.

Indeed, in the meantime, NM supports RFC7217 stable privacy addresses.
Note that these are enabled by default -- as you request. See `man nm-settings` how to configure it.

See also, connection.stable-id setting which affects the stable-privacy address. And have a look at https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/examples/nm-conf.d/30-anon.conf?id=a21b8882cc9defc43248afc94bf59ca0f84f0d27

Also, NM supports to randomize your MAC address -- which affects the EUI64 addr-gen-mode. See wifi.cloned-mac-address and ethernet.cloned-mac-address settings.