Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#30278 - [procps-ng] /etc/sysctl.conf - add and enable IPv6 privacy extensions

Attached to Project: Arch Linux
Opened by Sir Pogsalot (Pogs) - Wednesday, 13 June 2012, 09:24 GMT
Last edited by Gaetan Bisson (vesath) - Monday, 17 September 2012, 08:13 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To Gaetan Bisson (vesath)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 4
Private No



It is my opinion that IPv6 and its "stateless address autoconfiguration" is a privacy concern to those few of us who are lucky enough to have a global IPv6 address. The problem is that IPv6 in that schenario will form your global address by using a portion of your network interface's MAC when auto-assigning what address the interface will take on. [1] This in turn will make it easier for certain companies interested in tracking your behavior on the web to collect information about you. While the prefix of the address from the ISP may change, the MAC address portion will make it much easier for sites like Facebook to collect behavioral analysis data (if they do already or choose to in the future). I don't want to get into a discussion about paranoia and anonymity, and I'm sorry I alluded to what (might) already be a practice among companies that do data mining, but I thought it would be important to at least explain why I want this.

TL;DR: I would like to suggest that the maintainer/owner of procps-ng please add the following options (enabled) to /etc/sysctl.conf:

# Enable IPv6 Privacy Extensions
net.ipv6.conf.default.use_tempaddr = 2
net.ipv6.conf.all.use_tempaddr = 2
#net.ipv6.conf.<nic0>.use_tempaddr = 2
#net.ipv6.conf.<nicN>.use_tempaddr = 2

As I understand it, this will make the global address it forms for the interface be generated randomly, for all interfaces (this was copied from Arch's Wiki). It is my opinion that the average user will not take time to look at or configure anything in /etc/sysctl.conf so it is important that we encourage use of the IPv6 privacy extensions by it being enabled from a stock Arch installation. With Wikipedia saying that Windows and Mac OS X both have IPv6 privacy extensions enabled by default, I was hoping it would be an easy "feature" to add with the consensus of those who will handle this report. In terms of what is gained and lost: Privacy is gained, nothing is lost, as autogenerated global IPv6 addresses are also handled for collisions (in the incredible chance that ever happens. This is about keeping LAN information on the LAN, and not advertising your MAC address to the rest of the internet. :>


Additional info:
* I am using procps-ng 3.3.3-1
* IPv6 privacy extensions are not enabled or mentioned in the stock /etc/sysctl.conf

I hope that I am correct in everything I have discussed/suggested here, I have witnessed this "breach of privacy" after having been moved to AT&T's Uverse fiber network earlier today. Please enable these privacy extensions so that others may not be caught unawares.
This task depends upon

Closed by  Gaetan Bisson (vesath)
Monday, 17 September 2012, 08:13 GMT
Reason for closing:  Won't implement
Additional comments about closing:  Enabling IPv6 privacy extensions by default goes against both the RFC and the default configuration of its Linux implementation.
Comment by Sir Pogsalot (Pogs) - Wednesday, 13 June 2012, 09:37 GMT
Er, when I said that it would make it easier for certain companies to collect information about you, I mean that it would be done without your consent, as they would be tracking you by your IPv6 address and not through cookies. It's impossible for others to tell if your IPv6 address has been generated from your MAC or at random, but the ones that are generated at random would show up in their webserver logs far less frequently -- so it would be somewhat easy to tell who is the same person with an address incorporating their MAC.

I am not _against_ companies collecting information on you, it does have its benefits -- from targetted advertising to how Facebook can magically connect you to people and organizations with similar interests. BUT: I do not believe this is a way to collect information they should have access to as it requires you to know about its existence to opt out of.

I'm someone in favor of giving people "implicit" privacy, and letting them relinquish it themselves.

I hope this helps balance out my argument.
Comment by Sir Pogsalot (Pogs) - Wednesday, 13 June 2012, 10:21 GMT
net.ipv6.conf.eth0.use_tempaddr = 2

^ This should actually be there on top of having net.ipv6.conf.all.use_tempaddr = 2

It turns out *.all.use_tempaddr affects only the addresses generated on interfaces brought up later, not those at boot. Since eth0 is referenced in the stock rc.conf (iirc) it seems okay that specifically defining IPv6 privacy extensions on eth0 (assuming it exists) is the "right thing". I wish *.all.use_tempaddr worked as I expected...

Corrected addition to /etc/sysctl.conf:

# Enable IPv6 Privacy Extensions
net.ipv6.conf.default.use_tempaddr = 2
net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.eth0.use_tempaddr = 2
#net.ipv6.conf.<nic0>.use_tempaddr = 2
#net.ipv6.conf.<nicN>.use_tempaddr = 2

Note: 1 is addresses that incorporate MAC addresses into the IPv6 address, 2 is privacy addresses that generate what would be the MAC portion at random
Comment by Phillip Smith (fukawi2) - Saturday, 01 September 2012, 15:33 GMT
  • Field changed: Percent Complete (100% → 0%)
I don't believe this is a sane default. It certainly broke some things in my environment when traffic from my machine was coming from "random" addresses (ACL's etc failed to match).

It also goes against what the upstream default seems to be:;a=blob;f=Documentation/networking/ip-sysctl.txt;hb=HEAD#l1232

Those who are concerned about this issue are likely to already know how to enable it, and/or seek out the information.
Comment by Phillip Smith (fukawi2) - Monday, 03 September 2012, 01:09 GMT
(Thank-you for reopening this task)

In addition to my comments above, this change also goes against the recommendation of the relevant RFC [1], which states:
"Consequently, the use of temporary addresses SHOULD be disabled by default in order to minimize potential disruptions."

I recognize that this is an easy to change alter for the user, however as a default configuration I propose this change be reverted for 3 main reasons:
1) It introduces unexpected and transient behaviour.
2) It goes against upstream code in the interest of patching for privacy, which is generally not what Arch aims to do.
3) It goes against the RFC recommendation.

Comment by Alexander F Rødseth (xyproto) (trontonic) - Monday, 10 September 2012, 09:30 GMT
This package is an orphan. Assigned to one of the last maintainer that made changes to this package in subversion. (Please move it to [community] if there is no interest for it). Thanks.
Comment by Greg (dolby) - Monday, 10 September 2012, 13:11 GMT
procps-ng is in the base group. it cant just "move to community" :)
Comment by Alexander F Rødseth (xyproto) (trontonic) - Monday, 10 September 2012, 16:05 GMT
Sure it can ;) Better maintained in community than orphan in core. However, it seems like some work is being done here by a secretive, but industrial, package maintainer which have not declared ownership of the package, so it's not as abandoned as it may seem at first glance.
Comment by Gaetan Bisson (vesath) - Monday, 17 September 2012, 06:22 GMT
Although I perfectly undestand the benefits of enabling this extension, I do not think we should go against the RFC recommendation *and* the default behavior of its implementation in Linux.

Therefore, I'll remove those two lines from sysctl.conf in SVN but, before pushing it in [testing], I'll see if we can move this file to the filesystem package - because I have no idea what sysctl.conf is doing in procps-ng... (Or am I missing something obvious?)
Comment by Phillip Smith (fukawi2) - Monday, 17 September 2012, 06:24 GMT
Well AFAIK, the sysctl binary is provided by procps-ng? So it would make sense for the config file to be in the same package...
Comment by Gaetan Bisson (vesath) - Monday, 17 September 2012, 06:53 GMT
Oh, right. I always thought sysctl was in util-linux. Well, I'll push my changes to [testing] then.