procps' 10-ipv6-privacy.conf stomps on the ifup/NetworkManager "privext"/"ipv6.ip6-privacy" settings

Bug #1497166 reported by Tore Anderson
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ifupdown (Ubuntu)
Invalid
Undecided
Unassigned
network-manager (Ubuntu)
Fix Released
Undecided
Unassigned
procps (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

I have configured the following in /etc/network/interfaces:

auto eth0
iface eth0 inet6 auto
  privext 0

According to interfaces(5), this should disable IPv6 Privacy Extensions. However, after booting the machine, /proc/sys/net/ipv6/conf/eth0/use_tempaddr contains the value "2" - which means that Privacy Extensions are enabled. However running "ifdown eth0; ifup eth0" does fix the problem, so it is clear that ifup(8) does correctly set the use_tempaddr sysctl when bringing up the interface.

What's going on is that sometime later in the bootup process, the procps package overrides the user-configured value and sets it unconditionally to "2" for every interface on the system. This happens because the file /etc/sysctl.d/10-ipv6-privacy.conf contains "net.ipv6.conf.all.use_tempaddr = 2". It should not, or this bug should be reassigned to the ifupdown package requesting for the removal of the defunct "privext" setting.

On a related node, enabling IPv6 Privacy Extensions by default is counter to RFC 4941's recommendations. Quoting from section 3.6 Deployment Considerations:

   The use of temporary addresses may cause unexpected difficulties with
   some applications. As described below, some servers refuse to accept
   communications from clients for which they cannot map the IP address
   into a DNS name. In addition, some applications may not behave
   robustly if temporary addresses are used and an address expires
   before the application has terminated, or if it opens multiple
   sessions, but expects them to all use the same addresses.
   Consequently, the use of temporary addresses SHOULD be disabled by
   default in order to minimize potential disruptions. Individual
   applications, which have specific knowledge about the normal duration
   of connections, MAY override this as appropriate.

As such, the most appropriate course of action is probably to stop shipping the 10-ipv6-privacy.conf file by default.

The described behaviour is observed on Trusty LTS.

Tore

Revision history for this message
Tore Anderson (toreanderson) wrote : Re: 10-ipv6-privacy.conf stomps on the ifup/NetworkManager "privext"/"ipv6.ip6-privacy" settings

I just realised that this bug also impacts NetworkManager, at least on Vivid: I set the property "ipv6.ip6-privacy" on the default wired Ethernet interface to 0 (in order to prevent a remote CIFS mount from freezing every few hours), however after a reboot, privacy extensions remained active. My assumption is that NetworkManager configured the interface correctly (without privacy extensions) early on during the boot process, only to have the procps' 10-ipv6-privacy.conf overwrite it moments later. Disabling 10-ipv6-privacy.conf solved this issue too.

summary: - 10-ipv6-privacy.conf stomps on user-configured "privext" option
+ 10-ipv6-privacy.conf stomps on the ifup/NetworkManager
+ "privext"/"ipv6.ip6-privacy" settings
summary: - 10-ipv6-privacy.conf stomps on the ifup/NetworkManager
+ procps' 10-ipv6-privacy.conf stomps on the ifup/NetworkManager
"privext"/"ipv6.ip6-privacy" settings
Revision history for this message
Tore Anderson (toreanderson) wrote :

This issue seems to have been resolved in Xenial as a side-effect of changing to systemd, as systemd-sysctl.service runs before NetworkManager.service and networking.service. When those services configure a device-specific use_tempaddr sysctl, it will be left alone.

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Ok, closing as Fix Released then if it's fixed.

Changed in procps (Ubuntu):
status: New → Invalid
Changed in network-manager (Ubuntu):
status: New → Fix Released
Changed in ifupdown (Ubuntu):
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.