Bug 851233 - Regression: NM uses Privacy addresses by default
Regression: NM uses Privacy addresses by default
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-23 10:36 EDT by David Woodhouse
Modified: 2013-08-01 14:41 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-01 14:41:23 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Woodhouse 2012-08-23 10:36:23 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).
Comment 1 Pavel Šimerda (pavlix) 2012-08-24 11:27:14 EDT
> 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).
Comment 2 Pavel Šimerda (pavlix) 2012-08-24 11:31:39 EDT
From http://projects.gnome.org/NetworkManager/developers/api/09/ref-settings.html

int32
-1
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.
Comment 3 David Woodhouse 2012-08-24 11:35:11 EDT
(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
> consensus.

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?
Comment 4 David Woodhouse 2012-08-24 11:40:11 EDT
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.
Comment 5 Pavel Šimerda (pavlix) 2012-08-24 12:13:09 EDT
They may have patched something or use an older version, e.g. the UI?
Comment 6 David Woodhouse 2012-08-26 18:43:31 EDT
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?
Comment 7 David Woodhouse 2012-10-29 06:37:33 EDT
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*...
Comment 8 Jirka Klimes 2012-10-30 08:11:49 EDT
The IPv6 privacy stuff has been disabled for automatic connections:
http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=systemd-sleep-compat&id=af0eb9e7adf0732921ebe927408a41a36f56f72e

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.
Comment 9 Jirka Klimes 2012-10-31 03:54:03 EDT
NM 0.9.6.4 update added to bodhi:
https://admin.fedoraproject.org/updates/NetworkManager-0.9.6.4-1.fc17?_csrf_token=79a051148feb24e3668baa66360fd86299c218e3

Please test, and add karma :)
Comment 10 David Woodhouse 2012-10-31 04:43:54 EDT
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?
Comment 11 Fedora End Of Life 2013-07-04 02:59:32 EDT
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.
Comment 12 Fedora End Of Life 2013-08-01 14:41:27 EDT
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.

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