Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be unavailable on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1047139 - NetworkManager in F20 ignores privacy extensions (IPV6_PRIVACY=rfc3041)
Summary: NetworkManager in F20 ignores privacy extensions (IPV6_PRIVACY=rfc3041)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Thomas Haller
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1056711 1057061
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-29 11:44 UTC by Christian Klomp
Modified: 2015-02-05 21:04 UTC (History)
10 users (show)

Fixed In Version: NetworkManager-0.9.9.0-30.git20131003.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-02-22 00:59:04 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 705170 0 Normal RESOLVED [review] th/ipv6-privacy: implement temporary addresses (aka privacy extensions) 2020-08-07 07:29:22 UTC

Description Christian Klomp 2013-12-29 11:44:18 UTC
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.

Comment 1 schmidtm 2014-01-15 19:29:45 UTC
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

Comment 2 Daniel Laczi 2014-01-16 22:51:42 UTC
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.

Comment 3 Christian Klomp 2014-01-17 13:29:58 UTC
(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.

Comment 4 Daniel Laczi 2014-01-17 14:46:40 UTC
(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?

Comment 5 Christian Klomp 2014-01-17 18:30:16 UTC
(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

Comment 6 Christian Klomp 2014-01-26 20:39:37 UTC
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:                     --

Comment 7 Dan Williams 2014-01-27 21:31:35 UTC
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.

Comment 9 Christian Klomp 2014-02-03 11:56:56 UTC
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.

Comment 10 schmidtm 2014-02-03 18:49:21 UTC
(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?

Comment 11 Christian Klomp 2014-02-03 19:16:53 UTC
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).

Comment 12 Fedora Update System 2014-02-04 23:23:44 UTC
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

Comment 13 Thomas Haller 2014-02-04 23:32:50 UTC
(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.

Comment 14 Fedora Update System 2014-02-06 04:03:34 UTC
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).

Comment 15 Christian Klomp 2014-02-06 19:32:44 UTC
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.

Comment 16 Thomas Haller 2014-02-06 22:52:34 UTC
(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

Comment 17 Daniel Laczi 2014-02-07 18:20:26 UTC
Works fine on three machines here! Thanks!

Comment 18 schmidtm 2014-02-07 20:38:38 UTC
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

Comment 19 Daniel Laczi 2014-02-07 20:48:54 UTC
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.

Comment 20 schmidtm 2014-02-07 21:30:32 UTC
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?

Comment 21 Daniel Laczi 2014-02-07 21:43:19 UTC
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.

Comment 22 Thomas Haller 2014-02-07 23:25:39 UTC
(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?

Comment 23 kubrick@fgv6.net 2014-02-08 00:23:27 UTC
Works like a charm for me now.

Comment 24 schmidtm 2014-02-08 09:39:11 UTC
(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!

Comment 25 Fedora Update System 2014-02-16 15:19:40 UTC
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

Comment 26 Fedora Update System 2014-02-22 00:59:04 UTC
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.

Comment 27 Robert Muil 2015-02-05 13:07:22 UTC
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?

Comment 28 Thomas Haller 2015-02-05 21:04:27 UTC
(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.


Note You need to log in before you can comment on or make changes to this bug.