Red Hat Bugzilla – Bug 851233
Regression: NM uses Privacy addresses by default
Last modified: 2013-08-01 14:41:27 EDT
IPV6 so-called "privacy addressing" is a stupid idea, which benefits nobody but the tinfoil-hat brigade.
It breaks reverse DNS and any logging or network diagnosis, because a client has a different address every few minutes. So it's impossible to analyse logs after the fact, and hard to do simple things like packet capture for traffic from a given host.
It also breaks *existing* connections, in the relatively common case that we call off the wireless network briefly and then rejoin. Often, the IP address that was IN USE for existing TCP connections is no longer available.
Privacy addresses are painful for all the same reasons that dynamic IP addresses are painful and people want a *static* address, even if it's a static RFC1918 address on their own internal network.
In Fedora 17, something is setting 'IPV6_PRIVACY=rfc3041' on all new (wireless?) connections. Please, make this insanity stop!
The paranoid and the mentally ill can enable it if they want to. That's bug #828931 (for the UI; it's already possible by editing config files).
> It breaks reverse DNS and any logging or network diagnosis, because a client
> has a different address every few minutes. So it's impossible to analyse
> logs after the fact, and hard to do simple things like packet capture for
> traffic from a given host.
Yep. It's behavior is similar to Windows, then :).
> It also breaks *existing* connections, in the relatively common case that we
> call off the wireless network briefly and then rejoin. Often, the IP address
> that was IN USE for existing TCP connections is no longer available.
This is a bug. Old addresses should always be kept. Care to try with 0.9.6?
> Privacy addresses are painful for all the same reasons that dynamic IP
> addresses are painful and people want a *static* address, even if it's a
> static RFC1918 address on their own internal network.
And other people keep barking about privacy concerns. Hard to get a consensus.
> In Fedora 17, something is setting 'IPV6_PRIVACY=rfc3041' on all new
> (wireless?) connections. Please, make this insanity stop!
It's NetworkManager's default configuration.
> The paranoid and the mentally ill can enable it if they want to. That's bug
> #828931 (for the UI; it's already possible by editing config files).
Configure IPv6 Privacy Extensions for SLAAC, described in RFC4941. If enabled, it makes the kernel generate a temporary IPv6 address in addition to the public one generated from MAC address via modified EUI-64. This enhances privacy, but could cause problems in some applications, on the other hand. The permitted values are: 0: disabled, 1: enabled (prefer public address), 2: enabled (prefer temporary addresses).
How is it possible that it's documented to default to -1 while it's not one of the valid values? Is -1 'the value when networkmanager has started'?
Then the ip6-privacy=2 is probably set by the UI tool.
(In reply to comment #1)
> Yep. It's behavior is similar to Windows, then :).
Not really an endorsement ☺
> This is a bug. Old addresses should always be kept. Care to try with 0.9.6?
Not right now. This happens especially in cases where the device goes away (rmmod b43; modprobe b43 due to hardware/driver issues) or suspend/resume. Is it really expected to resume previous addresses in that case, even when it thinks it's a completely new connection?
> And other people keep barking about privacy concerns. Hard to get a
Not really. Ignore the tinfoil-hat brigade and just go with the kernel's default setting. Which the paranoid can *already* change in /etc/sysctl.conf if they want to. There's no need for NetworkManager to override that setting and enable the stupid paranoid mode for itself.
> > In Fedora 17, something is setting 'IPV6_PRIVACY=rfc3041' on all new
> > (wireless?) connections. Please, make this insanity stop!
> It's NetworkManager's default configuration.
Where? How do I fix this bug at least on my own system?
As I understand it, NetworkManager's default is -1, or UNKNOWN. It doesn't modify the setting, and you inherit the kernel's default — which is sane, with privacy nonsense disabled unless a tinfoil-hat-wearer has edited /etc/sysctl.conf to change that.
There is something else going on, which is setting IPV6_PRIVACY=rfc3041 for all new wireless connections that I make through the gnome-shell UI.
This apparently doesn't happen on Ubuntu, but it does on Fedora 17.
They may have patched something or use an older version, e.g. the UI?
No, I don't think so. Perhps it's just a bug in the RH-specific code for writing out the /etc/sysconfig/network-scripts/ifcfg-* files, which erroneously sets IPV6_PRIVACY=rfc3041 when it shouldn't?
I can't see anything which would *deliberately* turn this stupid option on for specific connections.
If people want it enabled by default, that's what /etc/sysctl.conf is for. Having *every* individual connection override the default isn't something that anyone would do on purpose, surely?
Argh. I explicitly turned this silliness *off* in /etc/sysconfig/network-scripts/ifcfg-Auto_Baythorne_Wavelan, but now I see NM has decided to ignore that, and has created an ifcfg-Auto_Baythorne_Wavelan-1 (and it appears twice in the applet). With privacy breakage *enabled*...
The IPv6 privacy stuff has been disabled for automatic connections:
Oh, now I see that the latest NM in F17 is NetworkManager-0.9.4.0-9.git20120521.fc17 that doesn't include the commit. I guess we should update F17 NM to 0.9.6.4 that has been released lately.
As for creating ifcfg-Auto_Baythorne_Wavelan-1 when ifcfg-Auto_Baythorne_Wavelan already exists, it appears to be an issue in gnome-shell network indicator: /usr/share/gnome-shell/js/ui/status/network.js
It should detect that there's a connection for an SSID and connect the existing connection instead of instructing NM to create new one.
NM 0.9.6.4 update added to bodhi:
Please test, and add karma :)
I'm actually on F18 now, and I can at least confirm that removing the network config and letting it be recreated *does* work here. Can't easily test F17 any more though; sorry. This needs wireless, right?
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. 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 WONTFIX if it remains open with a Fedora
'version' of '17'.
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 prior to Fedora 17's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 17 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 to Fedora 17's end of life.
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.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.