Description of problem: after upgrading from F19 to F20 NetworkManager seems to ignore the IPv6 privacy extensions in /etc/sysconfig/network-scripts/ifcfg-* (https://fedoraproject.org/wiki/Tools/NetworkManager/IPv6). I use the router advertisement daemon (radvd) in my router to announce the prefix and F19 used to generate two IPv6 addresses, one FF:FE (EUI-64) address and one dynamically generated address which is set as preferred. Version-Release number of selected component (if applicable): NetworkManager-0.9.9.0-22.git20131003.fc20.x86_64 How reproducible: configure an interface that is controlled by NM with the privacy extension (IPV6_PRIVACY=rfc3041) Steps to Reproduce: 1. enable privacy extensions through sysctl: # echo "net.ipv6.conf.all.use_tempaddr = 2" > /etc/sysctl.d/ipv6_privacy.conf 2. enable privacy extensions for the interface: # echo "IPV6_PRIVACY=\"rfc3041\"" >> /etc/sysconfig/network-scripts/ifcfg-<someinterface> 3. reboot system or manually enable the sysctl setting, reconnect the interface and maybe wait for it to obtain a router announcement. Then check the interface's addresses with `ip address`. Actual results: only one IPv6 address which is deduced from the MAC (EUI-64) Expected results: two IPv6 addresses should be shown whereof one is randomly generated and set preferred. Additional information: besides configuring an rfc3041 address, IPv6 connectivity works. After some further investigation rfc3041 seems to be deprecated by rfc4941, but when I configure the newer rfc4941 (IPV6_PRIVACY="rfc4941" (or IPV6_PRIVACY="2")) NetworkManager will only display the IPv6 address in the gui instead of the full network details including the IPv4 settings. Other than that not much changes about the situation.
I can confirm this bug. Enabling privacy extensions does not work even without using NetworkManager: # uname -a Linux fedora 3.12.6-300.fc20.x86_64 #1 SMP Mon Dec 23 16:44:31 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux # cat /etc/os-release NAME=Fedora VERSION="20 (Heisenbug)" ID=fedora VERSION_ID=20 PRETTY_NAME="Fedora 20 (Heisenbug)" ANSI_COLOR="0;34" CPE_NAME="cpe:/o:fedoraproject:fedora:20" HOME_URL="https://fedoraproject.org/" BUG_REPORT_URL="https://bugzilla.redhat.com/" REDHAT_BUGZILLA_PRODUCT="Fedora" REDHAT_BUGZILLA_PRODUCT_VERSION=20 REDHAT_SUPPORT_PRODUCT="Fedora" REDHAT_SUPPORT_PRODUCT_VERSION=20 # cat /proc/sys/net/ipv6/conf/all/use_tempaddr 2 # ip -6 addr show | grep temp | wc -l 0 # ip -6 a s dev p22p1 2: p22p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000 inet6 2003:2e:ff0f:dc00:4a5b:abff:fecd:c3cf/128 scope global valid_lft forever preferred_lft forever inet6 fe80::4a5b:abff:fecd:c3cf/64 scope link valid_lft forever preferred_lft forever
Hi, I have problems with this, too. Today I found out something strange: In /etc/sysctl.conf I use the following entries to enable IPv6 privacy extensions (worked in F19 without further configuration): net.ipv6.conf.default.use_tempaddr = 2 net.ipv6.conf.all.use_tempaddr = 2 Now, if I use NetworkManager with IPv6 enabled (default settings), I do only get a global IPv6 address with my MAC in the suffix. BUT, if I disable IPv6 in the NetworkManager UI I still get IPv6 addresses!!! I get the global one with my MAC in the suffix and I get a private one!! The private one is the default then and is used to connect to the internet. I have this behaviour on all of my machines. I upgraded them from F19 to 20 with fedup. NetworkManager version is NetworkManager-0.9.9.0-24.git20131003.fc20.x86_64 every machine.
(In reply to Daniel L. from comment #2) > Hi, > > I have problems with this, too. Today I found out something strange: > > In /etc/sysctl.conf I use the following entries to enable IPv6 privacy > extensions (worked in F19 without further configuration): > net.ipv6.conf.default.use_tempaddr = 2 > net.ipv6.conf.all.use_tempaddr = 2 > > Now, if I use NetworkManager with IPv6 enabled (default settings), I do only > get a global IPv6 address with my MAC in the suffix. > > BUT, if I disable IPv6 in the NetworkManager UI I still get IPv6 > addresses!!! I get the global one with my MAC in the suffix and I get a > private one!! The private one is the default then and is used to connect to > the internet. > > I have this behaviour on all of my machines. I upgraded them from F19 to 20 > with fedup. NetworkManager version is > NetworkManager-0.9.9.0-24.git20131003.fc20.x86_64 every machine. If I disable IPv6 in NM then I only get a link-local address, which obviously isn't used to connect globally.
(In reply to Christian Klomp from comment #3) > If I disable IPv6 in NM then I only get a link-local address, which > obviously isn't used to connect globally. Do you use the net.ipv6.conf.default.use_tempaddr = 2 net.ipv6.conf.all.use_tempaddr = 2 options, too?
(In reply to Daniel L. from comment #4) > (In reply to Christian Klomp from comment #3) > > If I disable IPv6 in NM then I only get a link-local address, which > > obviously isn't used to connect globally. > > Do you use the > > net.ipv6.conf.default.use_tempaddr = 2 > net.ipv6.conf.all.use_tempaddr = 2 > > options, too? No I only use the second one (net.ipv6.conf.all.use_tempaddr = 2) but that shouldn't matter. I just investigated this some more and it does work (the privacy extensions) when the interface is taken off NM and controlled through network (or the network init scripts or whatever it is called that makes the magic happen). Steps to take (after my initial steps): 1. copy the ifcfg configuration file somewhere safe. 2. make NM forget the network in the gui: Reset --> Forget. 3. copy back the ifcfg configuration file to it's initial location and to be sure add the no NM rule (NM_CONTROLLED=no). 4. enable the interface: sudo ifup p7p1 (second interface from the vm). 5. ip a: p7p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 08:00:27:62:81:6d brd ff:ff:ff:ff:ff:ff inet 192.168.11.21/24 brd 192.168.11.255 scope global p7p1 valid_lft forever preferred_lft forever inet6 2a02:****:****:****:4daa:76c4:3176:ece5/64 scope global temporary dynamic valid_lft 86398sec preferred_lft 85798sec inet6 2a02:****:****:****:a00:27ff:fe62:816d/64 scope global dynamic valid_lft 86398sec preferred_lft 86398sec inet6 fe80::a00:27ff:fe62:816d/64 scope link valid_lft forever preferred_lft forever If you then take it down, change NM_CONTROLLED=no to yes and restart NetworkManager.service it will show only one global and FF:FE-ized address: p7p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 08:00:27:62:81:6d brd ff:ff:ff:ff:ff:ff inet 192.168.11.21/24 brd 192.168.11.255 scope global dynamic p7p1 valid_lft 172703sec preferred_lft 172703sec inet6 2a02:****:****:****:a00:27ff:fe62:816d/128 scope global dynamic valid_lft 86394sec preferred_lft 86394sec inet6 fe80::a00:27ff:fe62:816d/64 scope link valid_lft forever preferred_lft forever This was tested on the recently updated NM: NetworkManager-0.9.9.0-24.git20131003.fc20.x86_64 Also, I still see this every x seconds: https://bugzilla.redhat.com/show_bug.cgi?id=1045860
Had some time to try this out in F21 and it looks like NM behaves the same (NetworkManager-0.9.9.0-25.git20140117.fc21.i686). I also dove a bit into nmcli and it looks to me it is configured properly (when IPV6_PRIVACY=rfc3041 is removed from the cfg-<interface> ipv6.ip6-privacy shows -1 so it definitely picks up the setting). [user@localhost ~]$ nmcli conn show configured p7p1 | grep ipv6 ipv6.method: auto ipv6.dns: ipv6.dns-search: ipv6.addresses: ipv6.routes: 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-hostname: --
Privacy is currently known to be broken but is actively being fixed. It requires some kernel improvements which have already been accepted for the 3.13 (or 3.14?) kernel. See the th/ipv6-privacy branch in upstream NM git. It will hit Fedora 20 at some point here.
Merged branch upstream: http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=3bb54e20849469eccca565b3e69a544541adcbaf
Just updated to NetworkManager-0.9.9.0-28.git20131003.fc20.x86_64 and the kernel 3.12.9-301.fc20.x86_64 that has the back-ported patch and I can confirm it works like expected again (with help of libnl-1.1.4-3.fc20.x86_64). I also tested rawhide and the results are the same.
(In reply to Christian Klomp from comment #9) > Just updated to NetworkManager-0.9.9.0-28.git20131003.fc20.x86_64 and the > kernel 3.12.9-301.fc20.x86_64 that has the back-ported patch and I can > confirm it works like expected again (with help of > libnl-1.1.4-3.fc20.x86_64). > I also tested rawhide and the results are the same. Unfortunately, I do not see any changes here (F20): $ uname -a Linux fedora 3.12.9-301.fc20.x86_64 #1 SMP Wed Jan 29 15:56:22 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux $ rpm -qa | grep NetworkManager NetworkManager-0.9.9.0-28.git20131003.fc20.x86_64 I still have only one global address and this is not a temporary one: 2: p22p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 48:5b:39:b3:c3:c0 brd ff:ff:ff:ff:ff:ff inet 192.168.178.38/24 brd 192.168.178.255 scope global dynamic p22p1 valid_lft 863127sec preferred_lft 863127sec inet6 2003:5a:6f12:fd00:4a5b:abff:fecd:c3cf/128 scope global valid_lft forever preferred_lft forever inet6 fe80::4a5b:39ff:feb3:c3c0/64 scope link valid_lft forever preferred_lft forever Did I miss something?
Whoops, it seems I've been a bit too enthusiastic because the solution only seems to work now and then; after a boot most of time a temporary dynamic address is generated, but when manually disabling and re-enabling the interface it most of the time won't. It also doesn't seem to work at all with both my wireless nics (behaviour is just as before). Rawhide looks to work a bit better (so far it has generated the privacy address every time) so it might be something with the back port (though I couldn't really test this thoroughly because after a minute or two the CPU/kernel locks up and the VM hangs).
NetworkManager-0.9.9.0-29.git20140131.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/NetworkManager-0.9.9.0-29.git20140131.fc20
(In reply to Christian Klomp from comment #11) Yes, this was a misunderstanding. I just now made the update for F20 to testing. So, for this feature, the following versions are needed: NetworkManager-0.9.9.0-29.git20140131.fc20 libnl3-3.2.24-1.fc20 kernel-3.12.9-301.fc20 The version 0.9.9.0-27.git20140131.fc21 on Fedora 21 (rawhide) contains this feature too.
Package NetworkManager-0.9.9.0-29.git20140131.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing NetworkManager-0.9.9.0-29.git20140131.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-2092/NetworkManager-0.9.9.0-29.git20140131.fc20 then log in and leave karma (feedback).
Tried it out on my desktop and the wireless nic of my notebook and both are now working like expected again (the additional temporary dynamic address is consistently being generated and used by default). In my opinion this bug can be marked as fixed, but I'm not sure about the current status and whether I should change it to resolved.
(In reply to Christian Klomp from comment #15) > Tried it out on my desktop and the wireless nic of my notebook and both are > now working like expected again (the additional temporary dynamic address > is consistently being generated and used by default). > In my opinion this bug can be marked as fixed, but I'm not sure about the > current status and whether I should change it to resolved. AFAIK, it will automatically be set to CLOSED, once the new package hits the users. Since NetworkManager-0.9.9.0-29.git20140131.fc20 is a new snapshot from master (which brings more changes then just specific bug fixes), we are a big conservative and wait a bit more to see if testing users hit any other issues. Testing is appreciated!! Thanks
Works fine on three machines here! Thanks!
And again, no changes here. $ uname -a Linux hyperion 3.12.9-301.fc20.x86_64 #1 SMP Wed Jan 29 15:56:22 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux $ rpm -qa | grep NetworkManager NetworkManager-0.9.9.0-29.git20140131.fc20.x86_64 $ rpm -qa | grep libnl3 libnl3-3.2.24-1.fc20.x86_64
Did you enable privacy extensions in /etc/sysctl.conf? I activated them via net.ipv6.conf.default.use_tempaddr = 2 net.ipv6.conf.all.use_tempaddr = 2 "sysctl -p" and restarting the network devices made it then. There was no need to make any further changes.
Yes I do. Enabled for all interfaces. I even rebooted the machine twice. No changes. Are you sure you did not do any special changes that could affect your system?
In NetworkManager I changed IPv6 method from ignore to automatic. Apart from that I'm pretty sure that I didn't change anything else. kernel, NetworkManager, and libnl3 are in the same version as yours. Do you use a wired or a wireless network card? I use a wireless one.
(In reply to schmidtm from comment #20) > Yes I do. Enabled for all interfaces. I even rebooted the machine twice. No > changes. > > Are you sure you did not do any special changes that could affect your > system? It ~should~ work. Just to make sure... did you set the ipv6 method of the connection to auto? Do you get any global ipv6 addresses via SLAAC? Do you actually receive any router advertisements for any autoconf addresses? What does 'ip addr' say?
Works like a charm for me now.
(In reply to Thomas Haller from comment #22) > It ~should~ work. Just to make sure... > > did you set the ipv6 method of the connection to auto? Do you get any global > ipv6 addresses via SLAAC? Do you actually receive any router advertisements > for any autoconf addresses? What does 'ip addr' say? Interessting enough, it works now. I didn't chance anything at my F20-Laptop but I rebooted my local DSL router. And whoops ... the interface got a /64 temporary address. Sorry for the noise, but that was strange enough... @Thomas: Kudos for taking care of the update!
NetworkManager-0.9.9.0-30.git20131003.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/NetworkManager-0.9.9.0-30.git20131003.fc20
NetworkManager-0.9.9.0-30.git20131003.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
I still see this issue on Fedora 20. yum info NetworkMAnager gives me: Version : 0.9.9.0 Release : 46.git20131003.fc20 When I go to http://ipv6-test.com/ I see that my MAC is exposed in my public IP address. My system is up to date according to yum update (and using the updates-testing repo doesn't include an updated version of NetworkManager anyway). This seems to be a security hole. Can anyone confirm that they also see this problem on a fresh install of Fedora20? Update: after adding the following lines to /etc/sysctl, the privacy extensions appear to be fixed: net.ipv6.conf.default.use_tempaddr = 2 net.ipv6.conf.all.use_tempaddr = 2 This is good, but it is problematic that the default setting is not secure, surely?
(In reply to Robert Muil from comment #27) > I still see this issue on Fedora 20. > Update: after adding the following lines to /etc/sysctl, the privacy > extensions appear to be fixed: > net.ipv6.conf.default.use_tempaddr = 2 > net.ipv6.conf.all.use_tempaddr = 2 as you saw, you can either configure it systemwide (/etc/sysctl) or per connection, so it works as intended. > This is good, but it is problematic that the default setting is not secure, > surely? Note that this default is according to RFC. The default value could be modified, but it should be done for upstream NetworkManager first. Fedora 20 would most likely never change this behavior. For example, for RHEL7 there is open bug 1187525 requesting to change the default.