Ubuntu should activate the IPv6 privacy extension by default (echo 2 >/proc/sys/net/ipv6/conf/all/use_tempaddr)

If that helps, windows uses those temporary addresses by default when using ipv6.

I too think this should be the default policy, there is no good reason to expose your MAC-address to the world.
But adding net.ipv6.conf.all.use_tempaddr=2 to /etc/sysctl.conf was not enough to get it working on my Ethernet interface from boot.
I also had to add net.ipv6.conf.default.use_tempaddr=2, and force ipv6 to load before before sysctrl using /etc/modules.
Perhaps the default should be changed in the kernel instead?

I agree that this should be turned on by default. For any entry in the net.ipv4.conf or net.ipv6.conf trees I believe both ".all" and ".default" should be set to achieve the desired effect. In this case the proper sysctl.conf settings are:

net.ipv6.conf.all.use_tempaddr=2
net.ipv6.conf.default.use_tempaddr=2

RFC 3041 is not without controversy. For example, see "RFC 3041 Considered Harmful" (an Internet-Draft and thus work in progress; I could only find an expired copy, but haven't found a reason why the underlying issues should have expired):

  http://www.6net.org/publications/standards/draft-dupont-ipv6-rfc3041harmful-02.txt

http://www.ietf.org/mail-archive/web/ietf/current/msg25047.html also notes that there may be per-application problems with deploying RFC 3041 addresses. See also section 7.8 of http://www.6net.org/publications/deliverables/D2.5.2.pdf.

At this point I'm very reluctant to make this change for 8.04; given the relative rarity of IPv6 usage among Ubuntu users I think it is unlikely that we would hear about regressions in time to correct them. I think the best course of action for the time being is to document this in the release notes, and I've added it to my personal stash of items which I'll be documenting there.

Anyway for this sysctl change to work, ipv6 has to be loaded (in /etc/modules) before the sysctl change and it is too late to change that for hardy.
(unless you know how to have some sysctl affect a not yet loaded module, for example with some udev magic ?)

Can the privacy extension be listed in /etc/sysctl.conf but commented out by default?

putting sysctl -w net.ipv6.conf.all.use_tempaddr=2 in /etc/rc.local seemed to get it working on 8.04.1 for me.

There is a possibility to use /etc/sysctl.d/10-network-security.conf
I'm not sure if it won't be too late here. But these rules should be processed after regular sysctl rules...

Am I right?

There is a possibility to use /etc/sysctl.d/10-network-security.conf (Ubuntu 8.10 Intrepid and up only)
I'm not sure if it won't be too late here. But these rules should be processed after regular sysctl rules...

Am I right?

I think we want it to be executed after ipv6 is loaded and before any interface is up.

And you're sure that this file is processed after interfaces are going up?
I was asking, because I've no clue..

I've tried that.

Error messages like: Error: "net.ipv6.conf.xxx.xxx" is an unknown key
have just moved to next line when booting..

Files /etc/sysctl.d/nn-*.conf are loaded immediately after /etc/sysctl.conf
Numbers (nn) are only for adjusting execution order.

note: This probably won't change anything, but: UFW (firewall) 's sysctl.conf (/etc/ufw/sysctl.conf) is loaded probably after, because I've successfully enabled IPv6 forwarding on that machine.

@MMlosh

To workaround this, I added ipv6 to /etc/modules

:(
Loading ipv6 module removes "failed" messages when booting
and sets properly net.ipv6.conf.xxx.xxx variables, but address is still from MAC...

Maybe it's just wrong radvd configuration... I've no clue.

The way I got it to right (didn't reboot since some time so I'm not sure it's still ok):

net.ipv6.conf.wlan0.use_tempaddr = 2
net.ipv6.conf.eth0.use_tempaddr = 2
net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2

in /etc/sysctl.conf

and ipv6

in /etc/modules

After that, I get two dynamic addresses in ip addr, the secondary is the random one.

I was missing that line with "eth0", thanks.... This behavior does not look like intended ("all" should IMHO set this variable for all interfaces and "default" should do that for new interfaces...)

On Tue, Nov 25, 2008 at 06:15:02PM -0000, MMlosh wrote:
> I was missing that line with "eth0", thanks.... This behavior does not
> look like intended ("all" should IMHO set this variable for all
> interfaces and "default" should do that for new interfaces...)

I agree, but it doesn't seem to work and I didn't have time to debug it.

--
:wq

Updated links:
  * RFC4941 (obsoletes RFC3041), written in September 2007:
    http://tools.ietf.org/html/rfc4941
  * "RFC 3041 Considered Harmful" Internet Draft, written in June 2004, expired December 2004:
    http://tools.ietf.org/html/draft-dupont-ipv6-rfc3041harmful-05

Because the "RFC 3041 Considered Harmful" ID hasn't been refreshed since 2004, I wonder if all of the issues it raises have been addressed in the new RFC4941. I also wonder if the Linux kernel has been updated to address any differences between RFC3041 and RFC4941. (I haven't read the RFCs yet, so I'm not sure how they differ.)

I *have* read both, and the arguments from "RFC 3041 Considered Harmful"-draft have been
dealt with in RFC4941, Section 7. So there does not seem to be a reason for disabling the privacy extension.

In fact, the arguments form the "Considered Harmful"-draft are, in some sense, not valid -- the current situation "Ipv4+NAT" is in no way better than "IPv6+Privacy-Extension". Given a DOS attack, in both cases you have to block a complete subnet (it's NAT gateway) if somebody within the subnet rapidly changes his IP addrss.

RFC 4941, Section 3.6, says that temporary addresses should be disabled by default.

Speaking from an enterprise network perspective, I very much do *not* want to see privacy addresses enabled by default, as they can make complying with our network security policies much more difficult.

On Fri, Apr 10, 2009 at 03:00:28PM -0000, Derek Morr wrote:
> RFC 4941, Section 3.6, says that temporary addresses should be disabled
> by default.

ACK, does Vista still does it by default ?
>
> Speaking from an enterprise network perspective, I very much do *not*
> want to see privacy addresses enabled by default, as they can make
> complying with our network security policies much more difficult.

If you manage an enterprise network, you can alway change the policies,
you shouldn't care about the default (and your users shouldn't be able to
override this).

/b

--
:wq

"Speaking from an enterprise network perspective, I very much do *not* want to see privacy addresses enabled by default, as they can make complying with our network security policies much more difficult."

In terms of demographics, Ubuntu doesn't have nearly the market share in the enterprise as it does in other sectors.

The hit on user privacy for systems not using privacy extensions is large - especially for new users.

So here's the dilemma:
Either we enable it by default (like Windows 7 does, btw!) and take a few risks (networks are harder to debug, difficulties with applications, etc.) or we disable it and lessen privacy for end-users.

I'd prefer the second option, but only if we had a way of disabling it *easily*, e.g. checkbox like
"[x] Enable Privacy Extension for Autoconf IPv6" somewhere in network-manager (RFC says there MUST be a switch for end users anyway in 3.6).

I am having trouble with ipv6 after upgrade to maverick... a ton of addresses is assigned instead of 2 (and it does not work)

    inet (addr) brd (addr) scope global eth0
    inet6 2002:(addr)/64 scope global temporary deprecated dynamic
    inet6 2002:(addr)/64 scope global deprecated dynamic
    inet6 2001:(addr)/64 scope global temporary dynamic
    inet6 2001:(addr)/64 scope global dynamic
    inet6 fec0::(addr)/64 scope site temporary deprecated dynamic
    inet6 fec0::(addr)/64 scope site deprecated dynamic
    inet6 fe80::(addr)/64 scope link

oh.. nevermind.. it is 6to4, I hope by admins, not by networkmanager on my ubuntu computer

OK, that mess is unrelated, IPv6 network here is under construction.. there are really so many radvds around

Could this get reevaluated for natty?

Recent kernels have IPv6 enabled by default and with IPv6 day coming up (http://www.ipv6day.org/) and major providers here in germany having announced to enable IPv6 in 2011 this is turning into a much more important issue than back in 2007!

I guess it would make more sense to add an option to NetworkManager where you can enable or disable this flag. NetworkManager could enable it per default then.

If this was implemented I'd even go one step further:
* Set /proc/sys/net/ipv6/conf/all/accept_ra to 0 per default (if I setup a server somewhere I generally don't want to have autoconfig enabled unless I choose so).
* Let NetworkManager set /proc/sys/net/ipv6/conf/$iface/accept_ra to 1 per default (can be changed with an option).
* Let NetworkManager set /proc/sys/net/ipv6/conf/$iface/use_tempaddr to some default value to be discussed (can be changed as well).

There's an article which describes a simple method to activate it: http://www.heise.de/netze/hotline/IPv6-anonym-1100727.html

Just add a line to your /etc/udev/rules.d/70-persistent-net.rules:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", RUN+="sysctl net.ipv6.conf.%k.use_tempaddr=2"

Whoopie, did you try that? Either I've done something wrong or that doesn't work. At least it didn't work on my machine running maverick.

I would prefer enabling Privacy Extensions by default. As Derek Morr said before, if you manage an enterprise network you have the knowledge and the ability to disable privacy extensions if needed or wanted. A normal User might not worry about IPv6 privacy by now, but as hopefully he will soon.

I like the Idea to enable privacy extension by default giving the posibility to disable it via gui.

The method described in Post #28 doesn't work for me, the method in Post #14 does. I'm using Ubuntu Maverick 10.10 x64.

Philipp,

That's not what I said (that's what tonfa said in reply to my note). At many higher education institutions, we have policies that we need to know who is using any given IP address at any point in time. Privacy addresses make this much, much harder. Yes, we can disable them on managed machines, but not all machines on our network are managed. For example, student laptops on wireless networks. So, the default setting matters. Microsoft enables privacy addresses by default on Vista and 7, and it is already creating problems for us. I've heard similar complaints from several colleagues at other universities. Frankly, privacy addresses do very little to enhance privacy and create significant headaches for network administrators. Please, leave them disabled by default.

>At many higher education institutions, we have policies that we need to know who is using any given IP address at any point in time.
If this was to control access, couldn't you just make a separate /64 for unmanaged computers and filter based on that? I can see how you might want to know who has what address to prevent abuse. However, even if this was off by default, couldn't someone just take note of what block you are using, and either add a static address (accidentally using the same address as someone else would be unlikely) in that block or turn on privacy addresses and get around that?

>Privacy addresses make this much, much harder. Yes, we can disable them on managed machines, but not all machines on our network are managed. For example, student laptops on wireless networks. So, the default setting matters. Microsoft enables privacy addresses by default on Vista and 7, and it is already creating problems for us.
So any slightly devious student could turn on privacy addresses on their machine and circumvent your policies?
>Frankly, privacy addresses do very little to enhance privacy and create significant headaches for network administrators.
Is letting the world know your MAC address not a big deal? I'm not fully aware of the dangers/non-dangers of letting whoever you connect to know your MAC address. I do know it can be used to track your computer as it goes between networks and that websites could use it for tracking between visits. Maybe you could explain why privacy addresses do very little to enhance privacy?
I just don't see how changing the default will do anything when the user could just change it back if they wanted to.

On Jan 18, 2011 9:46 PM, "Erik B. Andersen" <email address hidden>
wrote:
>
> >At many higher education institutions, we have policies that we need to
know who is using any given IP address at any point in time.

If you *need* to know, and computer are self-managed, then the fact that
privacy addresses are disabled by default doesn't really help. You need to
log data from the switches as well.

> >Privacy addresses make this much, much harder. Yes, we can disable them
on managed machines, but not all machines on our network are managed. For
example, student laptops on wireless networks. So, the default setting
matters. Microsoft enables privacy addresses by default on Vista and 7, and
it is already creating problems for us.

And windows isn't going away.

> >Frankly, privacy addresses do very little to enhance privacy and create
significant headaches for network administrators.
> I just don't see how changing the default will do anything when the user
could just change it back if they wanted to.

I am of the opinion that this should be turned on by default.

I would like to see the default be private. However, the best way to accomplish this is still not entirely clear. Probably the udev rule makes the most sense, but if ipv6 is up early enough, sysctl would be sufficient.

It does sound like network-manager would be required to have a toggle, though, based on the RFC. That may need to be implemented first.

I'm assigning the NM bug task to myself to work on allowing users to toggle this setting.

Note that privacy extensions only really affect autogenerated addresses (or at least, that's what I got out of my quick read of RFC 4941). It's a nice and useful feature for users in general when dealing with non-IPv6 and/or public networks. In enterprise environments it shouldn't be too much of a big deal, especially since IP addresses would be handed out by DHCP.

Erik, the issue isn't access control. It's logging and compliance. If someone uses our network to break the law, we need to be able to identify the responsible person. Privacy addresses are directly at odds with this requirement. Leaving them off by default isn't a 100% solution, but it helps a lot. Defaults matter.

Mathieu, why do you assume that enterprises will use DHCPv6? Some might for some of their networks, but it doesn't make sense for all use cases.

Please DO NOT enable privacy extensions by default. For enterprise networks, this causes serious headaches, and is a very bad idea. There are good reasons why the RFC says this should be disabled by default. It impacts address management, DNS updates, forensics in response to incidents, ability to correlate and analyze logs, to name a few of the issues.

The RFC does say that systems administrators should be able to enable or disable this feature. But no mechanism is offered to network administrators who may want to enable or disable this across the networks that they manage. And most network administrators of IPv6-enabled enterprise networks will tell you how much they hate this feature and it's being the default in Microsoft implementations.

We outlaw IPv6 privacy extensions in our enterprise network, and even had to write scanning tools to track down all the systems that have it enabled, and then have to instruct the admins on what registry settings they have to change to disable it. It kills the beauty of IPv6 auto-configuration (plug-n-play) for us, because now we are forced into human intervention for each new Windows system that plugs into our network. We hate it.

When pointing out to Microsoft how their current default is a very bad idea, they just tell you that you can disable it globally using Active Directory. But that does no good for networks that don't run AD, or where only a portion of their Microsoft systems are controlled by AD. The one saving grace has been that only Microsoft has made this mistake, and our Linux, Solaris, Mac OSX, and other operating systems are still doing the right thing.

Another solution sometimes offered is DHCPv6. That is not an complete solution today because a significant portion of the installed base does not include any DHCPv6 client support.

Don't make the mistake that Microsoft did by enabling this by default. Leave it disabled, but then allow systems administrators to enable it when desired and when local policy allows.

I do not think users will be very happy when they discover that they are globally trackable when IPv6 is enabled.

The RFC solves the problem of being trackable within a site, when the big problem is being trackable between sites.
Unfortunately it is the only mechanism available at the moment, and until something better comes along I think it should be enabled by default.

If you want to disable anything but EUI-64 addresses, could you not filter on the local bit? And redirect people to something explaining your rules.
Even if it is off by default on every operating system, some users are invariable going to enable it, and you need to deal with them anyway.

> Even if it is off by default on every operating system, some users are
> invariable going to enable it, and you need to deal with them anyway.

This is exactly the point!

Ron, Derek, I can understand your headache with the privacy extensions in your scenarios. But you problems are not solved by the answer of whether to set the default to on or off.

I simply cannot and do not want to understand why one would give out his / her MAC address on the largest public network - the internet. It tells everyone if you are browsing via WiFi or Ethernet, others can track you as a person, know when you changed your network interface and with some devices (where you can't change the network interface) know what device you are using. That's simply bad and so the privacy extensions should be enabled by default.

I frankly couldn't care less if someone knows my MAC address. The MAC address of the laptop I'm typing on right now is 00:1e:c2:c0:52:e3. What does that get you? Not much.

If you're concerned about being tracked across the Internet, your IP address is probably the least of your concerns. Have you read the articles about browser fingerprinting? Even if you disable cookies and don't install Flash, you can still be identified pretty well. I find that much more concerning that someone knowing if I'm on Wifi or wired Ethernet, and the manufacturer of my NIC. Privacy addresses provide no protection against tracking cookies or other spyware.

Privacy addresses don't deliver much security (or privacy, frankly), and they make life much harder for enterprise admins. There's a significant difference between chasing down a few power users who enable privacy addresses -vs- having to reconfigure every machine (often manually).

I don't buy the "enterprise" argument flowing through this discussion:

* What kind of enterprise network are you running where you don't control the clients and can't disable privacy extensions?

* If you want to make sure nobody uses privacy extensions on your net, just reject all outgoing connections which do not have the global bit set on your perimeter firewall. Then people will call tech support and you can explain to them that/how they have to disable this feature.

* It is true that enabled privacy extensions make logging harder. But if you're letting people into your network who have sufficient permissions to change their network config, they can just configure a static IP address so you've got to log based on MAC addresses (hoping nobody will change them) anyway. Rigging up a linux box which runs a daemon sniffing all traffic and logs the assignment of MAC addresses to IP addresses is not trivial, but easy. (See previous point if you don't want to build such a device or your network structure is too complex.)

OTOH does IPv6 allow tracking people much more and easier than fingerprinting allows. While it is true that you can fingerprint browsers, is the implementation of such a fingerprinting device a lot more complicated than a simple log file. Additionally does (rather exact) fingerprinting only allow browser identification; with the MAC address all other protocols (P2P, ...) are traceable, too.

There's actually currently some discussion about IPv6 and privacy in German media, see eg. <http://www.h-online.com/security/news/item/IPv6-Smartphones-compromise-users-privacy-1169708.html> (and the longer article <http://www.heise.de/ct/inhalt/2011/03/146/>) and <http://www.netzpolitik.org/2011/leseempfehlungen-datenschutz-im-zeitalter-von-ipv6/> (in the comments of the latter post Lutz Donnerhacke promises an article on why IPv6 is *not* an issue for privacy, let's hope he'll shed some light on the topic).

Anyway, my preference is *for* privacy extensions enabled per default since they do improve privacy for the home user who walks into an IPv6-enabled network (and uses Ubuntu and not Windows...) and enterprise networks should have the means to either disable them or log the MAC addresses.

My enterprise is a large research university in North America. We control University owned machines, but student-owned machines are a different matter.

I'm not certain that filtering privacy addresses at the border is sufficient. I'd need to check with our security office, but I suspect we'd also need to block them for internal connections, which means blocking them at the edge. I doubt that all of our network equipment can filter based on specific bits in an IPv6 address. Like many large organizations, we have a large installed base of equipment from multiple vendors on various lifecycles. Some of this equipment is managed centrally, but a significant portion is managed by other units (colleges, departments, etc). I couldn't even begin to guess what percentage of our routers, switches, and firewalls have this sort of filtering ability.

We have thousands of networks at the university. It's not practical to install NDPmon on each of them, as much as I might wish it were done.

I think if you were to poll the Internet2 IPv6 community, you'd find many similar environments.

Let me flip the question around -- how many respondents manage networks at large institutions ?

I currently only administer a bunch of small/medium networks (up to 50 machines) and frankly I currently reject/disable any IPv6 on those networks (makes my life easier since I don't have the time to check if all devices have proper IPv6 security). But from experiences at previous jobs I pretend to have at least some experience with large(r) networks :)

Anyway, as I see it you've got some classes of problems and at neither I see that disabled Privacy Extensions help much security/logging wise:

* First of all, you've probably got some Windows machines and for those you've got to find a way to ensure that PE are disabled anyway. Any device accessible by these machines has to be protected in a PE-sensitive way.

* Second, as it was pointed out in comment 40, you let students and colleagues with their own machines into your network. You can't enforce anything on those machines and have to shield them from the rest of the network with a (hopefully properly IPv6 capable) firewall anyway.

* The same is true for machines run by other departments. You can't really control what they are doing on their internal networks, if they use PE or not, use DHCP or even static addresses. Only their access to somewhere else and you should have some proper firewalls betweens these networks.

* You talk about oldish devices on your net. Many of these probably do not even support IPv6 properly (plus, *if* they do not require a user login *and* support the logging you require); even if they do and they are that sensitive, put a firewall in front of them (will probably cost less than 10% those machines are/were worth).

That said, if you let people with their own (malicious) machines into your network, relying on security/compliance by logging IP addresses (even MAC addresses FWIW) they can chose as they like, is a folly. Security based on IP addresses was a bad idea with IPv4 and still is with IPv6.

That's why I don't think this whole "enterprise" argument is valid, no matter how big your networks are (well, except for some funny enterprisey parts of ISO27001).

Anyway, I guess best idea would be if some (recognised) IPv6 expert spoke up on this topic.

"I guess best idea would be if some (recognised) IPv6 expert spoke up on this topic."

Well, Ron Broersma did chime in :)

I must admit that I hadn't heard Ron's name before but Google tells me that he definitely has some experiences with IPv6 on large scale enterprise networks :)

He's got more or less the same arguments you have and I'm still not entirely convinced ("the RFC says so" is also not a good reasoning) since I still think in enterprise networks you've got the advantage of some control over your clients and can disable PE globally (just create a file /etc/sysctl.d/99-no-pe.conf) or block PE enabled systems. OTOH does the average home user know nothing about PE and how to enable them. (Well, not that the average home users uses Ubuntu but thats a different problem.) So I still think the advantage of not being easily trackable on a global scale per default outweights enterprise needs to track people locally. But until somebody else with better arguments than me speaks up, I'll shut up :)

I guess what really would settle this issue once and for all would be another flag in the RA to disable PE (cf. RFC 5175).

please add it for ubuntu 11.04. I really want to enable ipv6 for the network, but there will always be machines where privacy-extensions are forgotten, so its a good default to set them to on by default.
the "2" option adds an unique address as well, so it should not be a problem, only the default ip is anonymous, the secondary is MAC-based.

I certainly won't have time to implement setting these settings in the UI for NM for natty, so I'm removing the bug assignment.

Hi, one thing:

"net.ipv6.conf.default.use_tempaddr = 2" breaks TCP sessions.

I've been using IPv6 for some time now with this turned on and nearly all worked BUT: ssh sessions hung after some time. I first expected some sort of ssh bug since everything else worked but I wiresharked it and the issue is that privacy extensions rob the active IPv6 and assign a new one which breaks the TCP connection, of course.

This can also be found here:

http://osdir.com/ml/linux.ipv6.usagi.users/2006-09/msg00042.html

The report is from kernel 2.6.17 and still valid as I'm currently running

2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

could'nt find a bug report regarding that but will search further or create one.

Regards,
Michael Heimann

you nee to use the permanent address as source-address for ssh

man ssh_config

       BindAddress
              Use the specified address on the local machine as the source address of the connection. Only useful on
              systems with more than one address. Note that this option does not work if UsePrivilegedPort is set to
              ``yes''.

@Allo: This whould be a workaround that disables privacy extensions for one software only instead of deactivating it completly. The bug is with the privacy extensions and not with ssh. Actually all other software clients would also suffer under the bug.

@all:
I really can't understand why this is so low priority. This is important, easily reproducable and needs to be fixed as it affects a lot of people. And by the way, windows does it right. Don't let them teach us how to do it right ;)

Regards,
Michael

There's a bug for NM not having an IPv6 privacy extension option, see https://bugzilla.gnome.org/show_bug.cgi?id=633233 (Not that it looks like much is happening.)

@Michael Heimann
if you're using a software which needs long tcp-sessions, you have to either ...
... use the non-PE address, as its stays valid forever (or as long as your prefix is valid)
... or increase the time the temp-addr is valid
... or deal with the connection-loss from time to time

Please, disable IPv6 by default and warn the user of the security issues, if he wants to enable IPv6. To have an open door by default is not the best idea IMHO.

Otherwise it has an advantage: We'll be able to easily count the amount of Linux users in the world in the future ;)

PS: Why is this bug only on the wishlist? It's a security bug.

We need to be encouraging the adoption of IPv6, not disabling it. And how would it make it possible to count the number of Linux users?

I think the Ubuntu installer should come with a checkbox option:
[ ] Leave me naked on the Internet and STAB ME IN THE BACK.

Regardless of whether it's checked or unchecked by default, I have a feeling most people aren't going to want that.

Right now, I'm typing on an operating system where Samba defaults to settings that basically amount to, "Don't let anything work unless the user manually edits a configuration file," which is presumably for the sake of security (unless it's for the sake of deliberately hassling users). If security is prioritized over functionality, the same should go for privacy...yet this same operating system freely gives my MAC address to anyone I bump into with IPv6, because it's more functional...and get this: It's not even more functional for ME, but for hypothetical system/network admins who aren't even using my computer. You have to be kidding me.

I cannot BELIEVE the attitude of system admins on this board. "Oh no, this will make forensics so much harder..." Yes, that is the point. (It's ironic that these comments are positioned so closely to comments saying that the privacy extensions don't effectively protect privacy. Obviously, they do so enough to make forensics a pain in the butt, so they're accomplishing something good at least.) "It'd be okay if just a few rogue users used privacy extensions, but when it's set to default and everybody does it..." Yes, that is once again the whole point. To the extent that it affects me as an end user, "forensics" = tracking, and it's not something I particularly appreciate.

This may come as a surprise, but end users are not in the business of serving system admins who want to track them and/or snitch on them when some copyright mafia comes knocking. An end user's operating system should exclusively serve the end user, not others who may have conflicting interests. Writing software that obeys and serves the user [as opposed to potentially adversarial third parties] is such a cornerstone of free and open source software that the correct course of action here should be a no-brainer. Anything else is a betrayal.

Did I mention copyright mafias? Let's take that up a notch and consider the ramifications of default "ass hanging in the wind" policies in totalitarian countries without free speech. A journalist/whistleblower/political dissident or such can use encryption, a VPN, etc. all she wants, but her IPv6 address may be the one weak link that ultimately ties all of her activity together and betrays her to the people who want nothing more than to identify, torture, and kill her. There is simply no excuse for leaving an obscure hole like this open by default, especially considering that most people are completely unaware of it.

Are there lots of other ways for people to track you? Sure. Browser fingerprints are a problem, and that problem should be dealt with...but there are in fact solutions that are being increasingly adopted, and this problem is restricted to web browsers anyway. The existence of such a problem does not justify saying, "Well, let's just give up on user privacy and broadcast our friggin' MAC addresses to everyone we bump into, so we can ...

So how we deal with this situation in the future? Do we respect privacy anymore or not? Microsoft seams to be more trustworthy than Linux nowadays ... What's the problem with this issue?

I believe it would be great to have this feature in the upcoming LTS release, as the problem affects more and more users in the future, especially with the 5 year support cycle. I think it's not a big deal for admins to disable it, while most plain users aren't aware of the problem nor have the knowledge to change the setting according to their needs, which is privacy and security. There should be at least a simple gui checkbox to let the user choose which state he wants.

I also consider this as a serious privacy issue : in my opinion, IPv6 privacy should be enabled by default, while letting the user/admin disable it if necessary.
In any case, I agree that the upcoming LTS version is the right moment to make a decision on that issue

@Michael Heimann
yeah, the idea IS to have a workaround for ssh, and only for it (or some other server-software).

with tempaddr = 2 you have a dynamic and a static ip, and softwares are using the dynamic by default, if not configured otherwise.

You can surf (more) anonymously, but your ssh-session uses the static ip, so the session does not die when the tempaddr is discarded. It should be a user decision to use the static ip, the default should be safe for the average user, which means that he's not exposed by a static ip.

Server software will bind to all intefaces by default, so a http or ssh server will be reachable on the dynamic address (mostly useless for you) and the static address (useful). Client software which needs long sessions often can be configured to use a specific from-ip, as i showed you the manual for the ssh-client.

This bug was fixed in the package procps - 1:3.2.8-11ubuntu5

---------------
procps (1:3.2.8-11ubuntu5) precise; urgency=low

  * debian/sysctl.d/10-ipv6-privacy.conf: add a file to sysctl.d to apply the
    defaults for IPv6 privacy extensions for interfaces. (LP: #176125, #841353)
 -- Mathieu Trudel-Lapierre <email address hidden> Mon, 05 Dec 2011 12:46:24 +0100

ew59, please don't assign yourself to bugs unless you plan on directly working on them ;)

The above upload of procps comes after rather complete and extensive discussion at UDS Precise (and from the output of the same discussion at the previous UDS); there's a clear and definite benefit in enabling privacy extensions, which is what this upload does.

The next step is to also provide the necessary magic in NetworkManager to allow turning it on or off on a per-interface basis; which is something that ought to be done for Precise (it goes with the procps upload, and is a workitem for precise); so I'm going to target it to precise alpha-2 in hope we can get it in ASAP.

This is already covered in NetworkManager, there's now a way to enable/disable privacy extensions locally; but there was an error in setting it up as enabled by default (I forgot to set it to TRUE when I included the upstream patch, which defaults it to FALSE).

FWIW; this was in patch debian/patches/manage-privacy-extensions.patch; but the default value for the enable-ip6-privacy property needs to be TRUE rather than FALSE.

This bug was fixed in the package network-manager - 0.9.2.0+git201202161854.8572ecf-0ubuntu4

---------------
network-manager (0.9.2.0+git201202161854.8572ecf-0ubuntu4) precise; urgency=low

  [ Gabor Kelemen ]
  * debian/network-manager.upstart: Make NM aware of the locale. (LP: #875017)

  [ Mathieu Trudel-Lapierre ]
  * debian/patches/lp936712_dnsmasq_ip6_ns_ordering.patch: order IPv6
    nameservers before IPv4 ones in dnsmasq config: dnsmasq is able to properly
    deal with broken IPv6 nameservers (or routers). (LP: #936712)
  * debian/control: add Conflicts: connman to network-manager. (LP: #659460)
  * debian/patches/manage-privacy-extensions.patch: set the default for using
    IPv6 Privacy extensions to TRUE; this is just correcting an oversight from
    adapting the upstream patch. (LP: #176125)
 -- Mathieu Trudel-Lapierre <email address hidden> Tue, 21 Feb 2012 19:40:35 -0500