Skip to content

ip6: revert to using sysctl ipv6.conf.default for ip6-privacy

Íñigo Huguet requested to merge ih/ip6_privacy_defaults into main

Summary

Revert the IPv6 privacy properties to use the values from /proc/sys/net/ipv6/conf/default as last resort default. Using the value from the interface specific sysctl setting is problematic.

Purpose

Commit 797f3caf ('device: fall back to saved use_tempaddr value instead of rereading /proc') changed the behaviour of how to get the last resort default value for ip6-privacy property.

Previously we read it from /proc/sys/net/ipv6/conf/default, buf after this commit we started to read /proc/sys/net/ipv6/conf/ instead, because the user might have set a different value specific for that device. As NetworkManager changes that value on connection activation, we used the value read at the time that NetworkManager was started.

Commit 6cb14ae6 ('device: introduce ipv6.temp-valid-lifetime and ipv6.temp-preferred-lifetime properties') introduced 2 new IPv6 privacy related properties relying on the same mechanism.

However, this new behaviour is problematic because it's not predictable nor reliable:

  • NetworkManager is normally started at boot time. That means that, if a user wants to set a new value to /proc/sys/net/ipv6/conf/, NetworkManager is likely alread running, so the change won't take effect.
  • If NetworkManager is restarted it will read the value again, but this value can be the one set by NetworkManager itself in the last activation. This means that different values can be used as default in the same system boot depending on the restarts of NetworkManager.

Moreover, this weird situation might happen:

  • Connection A with ip6-privacy=2 is activated
  • NetworkManager is stopped. The value in /proc/sys/net/ipv6/conf//use_tempaddr remains as 2.
  • NetworkManager starts. It reads from /proc/sys/... and saves the value '2' as the default.
  • Connection B with no ip6-privacy setting is activated. The '2' saved as default value is used. The connection didn't specify any value for it, and the value '2' was set by another connection for that specific connection only, not manually by a user that wanted '2' to be the default.

A user shouldn't have to think on when NetworkManager starts or restarts to known in an easy and predictable way what the default value for certain property is. It's totally counterintuitive.

Revert back to the old behaviour of reading from /proc/sys/net/ipv6/conf/default. Although this value is used by the kernel only for newly created interfaces, and not for already existing ones, it is reasonable to think on these settings as "systemwide defaults" that the user has chosen.

Note that setting a different default in NetworkManager.conf still takes precedence.

Resolves: https://issues.redhat.com/browse/RHEL-31182
NetworkManager-ci!1681 (merged)

Checklist

Please read https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/main/CONTRIBUTING.md before opening the merge request. In particular, check that:

  • the subject for all commits is concise and explicative
  • the message for all commits explains the reason for the change
  • the source is properly formatted
  • any relevant documentation is up to date
  • you have added unit tests if applicable
  • the NEWS file is updated when the change deserves to be mentioned, for example for new features, behavior changes, API deprecations, etc.

Merge request reports