IPv6 Privacy Extensions enabled on Ubuntu Server by default

Status changed to 'Confirmed' because the bug affects multiple users.

Although I sympathise with the sentiments in this bug, the real problem is that the application is not implementing the address selection process indicated in RFC 5014.

When an application opens a socket it can indicate that it requires the public address.

If you find an application that fails to take this into account, then best to report a bug on that application.

The problem is that by default pieces of software will use that address when communicating over IPv6. Such as wget downloading a file over IPv6 or connecting to a system using SSH.

This should absolutely not be the default for a server system.

-Tim

That's a bug in the software - not the server system. If the software
requires a global source address to work, then it should ask for one when
doing the bind or provide an option to do so.

If it doesn't do that then that is a buggy IPv6 implementation and should
be reported as such.

The problem here is developers using IPv6 with an IPv4 mentality.

On 13 March 2013 04:06, Tim Heckman <email address hidden> wrote:

> The problem is that by default pieces of software will use that address
> when communicating over IPv6. Such as wget downloading a file over IPv6
> or connecting to a system using SSH.
>
> This should absolutely not be the default for a server system.
>
> -Tim
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1068756
>
> Title:
> IPv6 Privacy Extensions enabled on Ubuntu Server by default
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1068756/+subscriptions
>

--
Neil Wilson

I don't think you are correct. Here's why: the comments in the file mentioned in my original bug report (of which I actually included the full contents of the file) state the following:

'2 - prefer privacy addresses and use them over the normal addresses.'

Heavy emphasis on the word prefer. These addresses will be preferred for *ALL* IPv6 traffic. This means that for all outbound IPv6 traffic, unless explicitly bound, it will use the privacy extension address. Which is correct, this is what software *should* do. In addition to that, addresses brought up with privacy extension enabled are global addresses. So even if said software were to bring use the 'global' address they would get the privacy extension address as it is preferred. The kernel is working right, the software is working right, the bug is that the server image has this enabled by default.

So in short, you're absolutely wrong. The server image should not have this enabled, and the software that is communicating over IPv6 is doing *exactly* what it should. It's using the preferred IPv6 address.

I'm okay with this being enabled for desktops, but it has *no* place in server environments.

-Tim

No the IPv6 system prefers privacy addresses over standard addresses if not
explicitly told otherwise.

Server *userspace software* should tell the system explicitly what it wants
to do so that clients can connect to it.

The problem is with the userspace software, not the IPv6 configuration. It
should be selecting addresses that it requires. Much outbound server
software can benefit from privacy addresses and your solution denies them
that option because of faulty binding in the userspace software.

So I disagree. The problem is userspace software not using the 'hint' IOCTL
in IPv6 address binding to tell the operating system what type of addresses
it requires.

In other words IPv4 thinking in an IPv6 world.

On 31 March 2013 23:26, Tim Heckman <email address hidden> wrote:

> I don't think you are correct. Here's why: the comments in the file
> mentioned in my original bug report (of which I actually included the
> full contents of the file) state the following:
>
> '2 - prefer privacy addresses and use them over the normal addresses.'
>
> Heavy emphasis on the word prefer. These addresses will be preferred for
> *ALL* IPv6 traffic. This means that for all outbound IPv6 traffic,
> unless explicitly bound, it will use the privacy extension address.
> Which is correct, this is what software *should* do. In addition to
> that, addresses brought up with privacy extension enabled are global
> addresses. So even if said software were to bring use the 'global'
> address they would get the privacy extension address as it is preferred.
> The kernel is working right, the software is working right, the bug is
> that the server image has this enabled by default.
>
> So in short, you're absolutely wrong. The server image should not have
> this enabled, and the software that is communicating over IPv6 is doing
> *exactly* what it should. It's using the preferred IPv6 address.
>
> I'm okay with this being enabled for desktops, but it has *no* place in
> server environments.
>
> -Tim
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1068756
>
> Title:
> IPv6 Privacy Extensions enabled on Ubuntu Server by default
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1068756/+subscriptions
>

--
Neil Wilson

Neil Wilson <email address hidden> writes:

> No the IPv6 system prefers privacy addresses over standard addresses if not
> explicitly told otherwise.
>
> Server *userspace software* should tell the system explicitly what it wants
> to do so that clients can connect to it.

You keep asserting this but don't back it up in any meaningful way.
It's turning this bug into a rather useless episode of "did", "didn't",
"did", "didn't".

> The problem is with the userspace software, not the IPv6
> configuration. It should be selecting addresses that it requires. Much
> outbound server software can benefit from privacy addresses and your
> solution denies them that option because of faulty binding in the
> userspace software.

I'm sorry but I don't believe the vast majority of server owners care
about the privacy of the MAC address of their servers. Clients
(generally speaking) map directly to an individual (i.e. human being),
servers (generally speaking) don't.

> So I disagree. The problem is userspace software not using the 'hint'
> IOCTL in IPv6 address binding to tell the operating system what type
> of addresses it requires.
>
> In other words IPv4 thinking in an IPv6 world.

No, sorry, it's called being realistic and pragmatic. If the vast
majority of software is "doing it wrong"¹, then privacy extensions
should be turned off on the server until a reasonable subset of software
is "fixed".

--
James

¹ And I don't think that's actually a given but let's run with it for
  the sake of argument.

I can confirm all of the security addresses by default are marked Global. There is no application level workaround for this.

$ ifconfig eth0 | awk '/inet6/ {print $1,$2,"ipv6addr",$4}'
inet6 addr: ipv6addr Scope:Global
inet6 addr: ipv6addr Scope:Global
inet6 addr: ipv6addr Scope:Global
inet6 addr: ipv6addr Scope:Link
inet6 addr: ipv6addr Scope:Global
inet6 addr: ipv6addr Scope:Global
inet6 addr: ipv6addr Scope:Global
inet6 addr: ipv6addr Scope:Global
inet6 addr: ipv6addr Scope:Global

From 'include/linux/in6.h'

/* RFC5014: Source address selection */
#define IPV6_ADDR_PREFERENCES 72

#define IPV6_PREFER_SRC_TMP 0x0001
#define IPV6_PREFER_SRC_PUBLIC 0x0002
#define IPV6_PREFER_SRC_PUBTMP_DEFAULT 0x0100
#define IPV6_PREFER_SRC_COA 0x0004
#define IPV6_PREFER_SRC_HOME 0x0400
#define IPV6_PREFER_SRC_CGA 0x0008
#define IPV6_PREFER_SRC_NONCGA 0x0800

so you need to call
setsockopt(socket, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES, &value, sizeof(value)).

Where value=IPV6_PREFER_SRC_PUBLIC

On 16 May 2013 23:24, Jason Eggleston <email address hidden> wrote:
>
> I can confirm all of the security addresses by default are marked
> Global. There is no application level workaround for this.
>
> $ ifconfig eth0 | awk '/inet6/ {print $1,$2,"ipv6addr",$4}'
> inet6 addr: ipv6addr Scope:Global
> inet6 addr: ipv6addr Scope:Global
> inet6 addr: ipv6addr Scope:Global
> inet6 addr: ipv6addr Scope:Link
> inet6 addr: ipv6addr Scope:Global
> inet6 addr: ipv6addr Scope:Global
> inet6 addr: ipv6addr Scope:Global
> inet6 addr: ipv6addr Scope:Global
> inet6 addr: ipv6addr Scope:Global
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1068756
>
> Title:
> IPv6 Privacy Extensions enabled on Ubuntu Server by default
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1068756/+subscriptions

--
Neil Wilson

RFC 4941:

   The use of temporary addresses may cause unexpected difficulties with
   some applications.
    ...
   Consequently, the use of temporary addresses SHOULD be disabled by
   default in order to minimize potential disruptions.

In my view this is NOT a software bug, its an OS bug.

Here's a completely different why this causes problems.

We use Ubuntu UEC images. There are no meaningful privacy considerations here because we generate both the MAC address and the IP address of the servers concerned. IE, if the machine is mobile and changes IP address, it changes MAC address too.

We build firewall rules automatically for the machine. These are applied outside of the machine (on the router). In order to write the rules correctly, we need to know the IPv6 address the machine will have, and use EUI-64 addressing to do this.

Equally, for the server to get metadata on a boot, both the IP address needs to be correct (and no, that's not the only thing that is checked). On UEC randomisation of addresses thus prevents getting metadata over IPv6. This is only 'not a killer problem' as most people have IPv4 too.

In a server environment (particularly on cloud images) there is no need whatsoever to have RFC4941 turned on by default.

As Brian Candler wrote, the RFC says this should be disabled by default. It also says:

   Devices implementing this specification MUST provide a way for the
   end user to explicitly enable or disable the use of temporary
   addresses. In addition, a site might wish to disable the use of
   temporary addresses in order to simplify network debugging and
   operations. Consequently, implementations SHOULD provide a way for
   trusted system administrators to enable or disable the use of
   temporary addresses.

On a cloud image, the user can't even administer his own machine until it has booted, which in a full IPv6 environment requires it to get metadata. For the reasons above, this prevents that from working. Therefore at least on UEC images, RFC4941 should be turned off by default and EUI-64 addresses only should be used.

The metadata request on IPv6 should ask to use the global address on
outgoing connection. If it did, then the firewall rule would work, the
metadata obtained and that can turn off the temporary address
mechanism if that is what you want.

Badly coded applications should be fixed to work properly with IPv6
*as IPv6 is designed*, and then temporary addresses would work quite
happily.

The problem here is primarily coding applications to use IPv6 as
though it is IPv4.

There is no need to cripple the UEC images. There is a need to fix the
software so it works with IPv6 properly.

On 4 June 2014 11:13, Alex Bligh <email address hidden> wrote:
> In my view this is NOT a software bug, its an OS bug.
>
> Here's a completely different why this causes problems.
>
> We use Ubuntu UEC images. There are no meaningful privacy considerations
> here because we generate both the MAC address and the IP address of the
> servers concerned. IE, if the machine is mobile and changes IP address,
> it changes MAC address too.
>
> We build firewall rules automatically for the machine. These are applied
> outside of the machine (on the router). In order to write the rules
> correctly, we need to know the IPv6 address the machine will have, and
> use EUI-64 addressing to do this.
>
> Equally, for the server to get metadata on a boot, both the IP address
> needs to be correct (and no, that's not the only thing that is checked).
> On UEC randomisation of addresses thus prevents getting metadata over
> IPv6. This is only 'not a killer problem' as most people have IPv4 too.
>
> In a server environment (particularly on cloud images) there is no need
> whatsoever to have RFC4941 turned on by default.
>
> As Brian Candler wrote, the RFC says this should be disabled by default.
> It also says:
>
> Devices implementing this specification MUST provide a way for the
> end user to explicitly enable or disable the use of temporary
> addresses. In addition, a site might wish to disable the use of
> temporary addresses in order to simplify network debugging and
> operations. Consequently, implementations SHOULD provide a way for
> trusted system administrators to enable or disable the use of
> temporary addresses.
>
> On a cloud image, the user can't even administer his own machine until
> it has booted, which in a full IPv6 environment requires it to get
> metadata. For the reasons above, this prevents that from working.
> Therefore at least on UEC images, RFC4941 should be turned off by
> default and EUI-64 addresses only should be used.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1068756
>
> Title:
> IPv6 Privacy Extensions enabled on Ubuntu Server by default
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1068756/+subscriptions

--
Neil Wilson

Neil: the metadata is just one example (though that's not happening).

The firewall rule thing applies irrespective of the metadata. The cloud environment created requires only /128 addresses it knows about to be accessible, and firewalls everything else out. Reasons for this include prevention of spoofing of IP addresses on outbound traffic. We want each UEC image to come up with the IPv6 address(es) we have assigned, and not a random one in the same /64. This is not an unreasonable requirement. We would use DHCPv6 for this if it weren't for the fact that DHCPv6 is broken in different ways and has little support.

IPv6 *as designed* says RFC4941 SHOULD (RFC capitalisation) be turned off by default. So the argument that applications should be using it 'as designed' is bogus, as if it was deployed *as designed* (i.e. per the RFC) it would work. There would be no problem with (e.g.) Network Manager turning this on in a desktop environment.

There's no problem with using it in an IPv6 environment if you use
IPv6 prefix mechanisms as designed

If you've tied down your cloud environment too tight (and technically
contra the spec - IPv6 is prefix based, not address based) then you
have to expect to make alterations to the standard equipment.

I have no problem with the temporary addresses as I scope my machines
on /64 boundaries - which is what everything pretty much expects and
RFC 5375 recommends. "Note that RFC 3177 strongly prescribes 64-bit
subnets for general usage, and that stateless autoconfiguration on
most link layers (including Ethernet) is only defined for 64-bit
subnets."

On 4 June 2014 11:57, Alex Bligh <email address hidden> wrote:
> Neil: the metadata is just one example (though that's not happening).
>
> The firewall rule thing applies irrespective of the metadata. The cloud
> environment created requires only /128 addresses it knows about to be
> accessible, and firewalls everything else out. Reasons for this include
> prevention of spoofing of IP addresses on outbound traffic. We want each
> UEC image to come up with the IPv6 address(es) we have assigned, and not
> a random one in the same /64. This is not an unreasonable requirement.
> We would use DHCPv6 for this if it weren't for the fact that DHCPv6 is
> broken in different ways and has little support.
>
> IPv6 *as designed* says RFC4941 SHOULD (RFC capitalisation) be turned
> off by default. So the argument that applications should be using it 'as
> designed' is bogus, as if it was deployed *as designed* (i.e. per the
> RFC) it would work. There would be no problem with (e.g.) Network
> Manager turning this on in a desktop environment.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1068756
>
> Title:
> IPv6 Privacy Extensions enabled on Ubuntu Server by default
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1068756/+subscriptions

--
Neil Wilson

That doesn't work if (for instance) you have 2 machines on the same SDN virtual LAN, which is a /64, and you want to prevent source spoofing between them. For avoidance of doubt, we do use /64s.

This affects 14.04 too

I would suggest that is a design flaw in your network - which is
working in an IPv4 manner, not an IPv6 one. You should have used a
prefix smaller than /64

The problem here is with the network design, not the image.

On 4 June 2014 14:40, Alex Bligh <email address hidden> wrote:
> That doesn't work if (for instance) you have 2 machines on the same SDN
> virtual LAN, which is a /64, and you want to prevent source spoofing
> between them. For avoidance of doubt, we do use /64s.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1068756
>
> Title:
> IPv6 Privacy Extensions enabled on Ubuntu Server by default
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1068756/+subscriptions

--
Neil Wilson

given "RFC4941 SHOULD (RFC capitalisation) be turned off by default" above, and the general lack of value of privacy extensions being enabled on a server or cloud geust, i really think we should:
 a.) turn off privacy extensions on cloud-images for 14.10+
 b.) look for a way to disable them by default for 'sever' for 14.10+
      note, this has been difficult in the past to set "server specific config". as determining what is a server and what is not is not as straight forward as it may appear.
 c.) document how the user can use user-data to customize the file on any ubuntu guest
 d.) document how cloud provider can use vendor-data to customize this change this defualt on any ubuntu guest.
 e.) change cloud-init metadata requests to IPV6_PREFER_SRC_PUBLIC
 f.) consider this change in 14.04 for cloud-images.

Disabled IPv6 privacy extensions for Ubuntu 14.10 via /etc/sysctl.d. I would be in favor of making this a default for 14.04 as well.

marked this 'triaged' in cloud-init while still not really relevant.
Ben Howard has disabled the privacy extensions in cloud images in 14.10, and the plan is to just do the same for 14.04.

Just to document additional support. I concur that on a Server install, PE should disabled by default. A server doesn't fall into the use case of needing to protect the privacy of the user. It is meant to be known, not obfuscated.

interestingly enough, modifying the privacy settings via sysctl has some negative affects if addresses are already up. see diagnosis in bug 1377005 .

ok. so some updates.
Ben fixed this in the cloud image build process via [1] (commit [2]), and limited the change to utopic+.
The fix was done by adding a file /etc/sysctl.d/99-cloudimg-ipv6.conf

The problem with this change is described in bug 1352255 and bug 994931. If ipv6 addresses are already configured, then setting the 'net.ipv6.conf.all.use_tempaddr' will remove the configured addresses.

So to actually fix this right, I suggest that the build proces:
 * dpkg-divert /etc/sysctl.d/10-ipv6-privacy.conf to /etc/sysctl.d/10-ipv6-privacy.conf.disabled
 * add a file /etc/sysctl.d/10-ipv6-privacy.conf.README that explains that and how the user could re-enable it (un-dpkg-divert it).

--
[1] http://bazaar.launchpad.net/~ubuntu-on-ec2/vmbuilder/automated-ec2-builds/view/head:/live-config/common/hooks/060-ipv6.chroot
[2] http://bazaar.launchpad.net/~ubuntu-on-ec2/vmbuilder/automated-ec2-builds/revision/646

The situation appears to have improved somewhat in Xenial. The net/ipv6/conf/all/disable_ipv6 sysctl appears to have become a no-op in recent kernels, so when 10-ipv6-privacy.conf gets applied during the bootup sequence (by systemd-sysctl.service) it does *not* change the effective per-device setting for already existing devices (which defaults to 0).

However, devices that show up later in the boot process, the 10-ipv6-privacy.conf-set value of net/ipv6/conf/default/disable_ipv6 is inherited, so privacy extensions remain enabled by default for userspace-created devices.

Finally, NetworkManager will by default bounce the disable_ipv6 sysctl on devices it's bringing up. That seems to cause the device's use_tempaddr sysctl to be re-inherited from net/ipv6/conf/default/disable_ipv6, ensuring the setting from 10-ipv6-privacy.conf is applied.

In summary, the following seems to be true in Xenial:

- Physical kernel-plumbed interfaces (e.g., "eth0") managed through interfaces(5): Privacy extensions disabled by default.
- Physical kernel-plumbed interfaces (e.g., "eth0") managed through NetworkManager(8): Privacy extensions enabled by default.
- User-space created interfaces (e.g., "bond0" or "vlan123"), regardless of management method: Privacy extensions enabled by default.

Another thing worth noting is that the version of NetworkManager shipped by Xenial uses RFC7217 Interface IDs by default. These are randomly generated and do not leak MAC addresses, yet they are stable on any given link/network. They will change when the link prefix changes, thus preventing tracking between networks. So where NetworkManager is used, there is IMHO very little rationale remaining for enabling RFC 4941 privacy extensions by default.

https://blogs.gnome.org/lkundrak/2015/12/03/networkmanager-and-privacy-in-the-ipv6-internet/

Correction to my previous comment: "disable_ipv6" should of course have read "use_tempaddr" throughout, except for the part about NM bouncing the disable_ipv6 sysctl.

In case anyone's interested in knowing why setting net/ipv6/conf/all/use_tempaddr=2 no longer changes the value of pre-existing interfaces (thus ensuring privacy extensions are disabled by default for physical interfaces configured through /etc/network/interfaces), it's because http://kernel.ubuntu.com/git/ubuntu/ubuntu-trusty.git/commit/?id=c999e7dff4570e4c28a0953e7189c0c31343ce62 was dropped from the Ubuntu kernel packages starting with Utopic.

Thanks Tore for checking so much Details and all the relations to NetworkManager it might have on a Desktop.
On a server (no NM) I'd think it is always enabled i'd think.

But if that is a bug or not is a"discussion".
Just as much as users want it off (here) others want it on - see bug 176125 and bug 841353.
I think it is about the best default and control.
Reading through these bugs IMHO I see stronger arguments to keep it enabled for now - and since /etc/sysctl.d/10-ipv6-privacy.conf is a conffile it can be adapted if needed.

I'd currently be more concerned if disabling in /etc/sysctl.d/10-ipv6-privacy.conf would not switch them off in all of them, but had no time to check.

I'll also subscribe cyphermox who worked on enabling that if this becomes more of a discussion.

Hi Christian. Some comments/corrections:

1) On servers privacy extensions are *not* always enabled. As I pointed out in comment #24, if NM is not in use, privacy extensions are only enabled for userspace-created interfaces such as "vlan123". It is *not* enabled by default for physical interfaces such as "eth0". This is inconistent, but at least it's a good default for most people (i.e., those that are using "eth0").

2) The old bugs #176125 and #841353 concern themselves with the potential leak of information of the user's MAC address. While this was a valid concern in the past, it no longer is. This is because (as I also pointed out in comment #24) NM will by default use RFC7217 interface identifiers. These do not contain the MAC address. Additionally, they will change when moving between networks, preventing tracking.

3) Finally, which has been pointed out by others earlier in the thread, even RFC4941 itself recommends that privacy extensions are disabled by default.

Tore

Is the current situation good enough? In the procps package, the default is still "2". Image deployments change that as Scott described in comment #23 (but that was 3y ago, might have changed). I don't know how server installs using the text mode installer behave, it's been a while since I last used it.