[Bug 1977619] Re: NetworkManager 1.36.6 no longer prefers DHCPv6 addresses over SLAAC

Thu Jun 9 11:41:30 UTC 2022

Thanks for the testing and for following up on the issue. I've uploaded
that patch to the SRU queue now

** Description changed:

+ * Impact
+ The recent SRU created a regression in IPv6 routing order
+ 
+ * Test Case
+ 
+ 1. Connect to a network where the router sends "A" and "M" bits in the
+ RA's and has a DHCPv6 server running (e.g. any OpenWrt router).
+ 
+ 2. When running `ip -6 a`, the list now sorts SLAAC addresses above
+ DHCPv6 addresses. With NetworkManager 1.36.4 and earlier, this was not
+ the case. (The Linux kernel uses the address highest in the list as
+ preferred.)
+ 
+ 3. When running something like `curl ifconfig.co`, the SLAAC address is
+ being returned, which makes sense as that is now preferred by the
+ kernel. (But it shouldn't be.)
+ 
+ Desired behaviour:
+ 
+ NetworkManager should always sort DHCPv6 addresses above SLAAC
+ addresses, as is the case for all versions prior to 1.36.6 and also
+ corrected again in 1.38.0. In case static addresses are manually set,
+ those should take first priority, with DHCPv6 second and SLAAC/autoconf
+ last.
+ 
+ * Regression potential
+ 
+ The patch change the IPv6 addresses order to match the behaviour from
+ the previous version. If that was buggy the routing order would still be
+ wrong, so we should check that IPv6 setups behave as expected.
+ 
+ ---------------------------------------
+ 
  Situation:

  My network has both DHCPv6 and SLAAC (autoconf) for IPv6. From a privacy
  perspective, for readability reasons and for network management
  policies, DHCPv6 should *always* be preferred over SLAAC addresses when
  available. And according to RFC 6724, the smaller /128 scope of the
  DHCPv6 address should be chosen over the larger /64 scope of the SLAAC
  address.

  NetworkManager has always been able to adhere to that by simply setting
  ip6.privacy=0 for the connection (in nm-connection-editor *not*
  selecting "Prefer temporary address" for IPv6 privacy extensions). Then
  it would use the DHCPv6 address as the source for all outgoing traffic.

  So if you would - for instance - run `curl ifconfig.co`, the DHCPv6
  address would be used to connect to the outside world and be echoed
  back.

  Regression:

  Since the update to 1.36.6, this is no longer the case. NetworkManager
  now routes outgoing traffic through the SLAAC address, even if
  ip6.privacy=0 is set for the connection.

  Constantly removing the SLAAC addresses with `ip addr del` or disabling
  SLAAC RA's on the router are now the only ways to stop NetworkManager
  from preferring SLAAC over DHCPv6. None of the local options in
  NetworkManager 1.36.6 are able to restore the previous, desired and
  correct way of working: the SLAAC address should never be used as the
  preferred address if a DHCPv6 lease is given.

  Looking at the changelog of NetworkManager 1.36.6, multiple things
  regarding IP address order and temporary addresses have been changed in
  that release, any of them (or a combination) introducing this bug:

  * Fix a bug in synchronization of IP addresses with kernel that could lead to a wrong address order.
  * Ignore addresses from DHCPv6 when the Otherconf router advertisement flag is set.
  * Ensure temporary IPv6 addresses are removed on disconnect and reapply.

  https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-36/NEWS

  Steps to reproduce:

  1. Connect to a network where the router sends "A" and "M" bits in the
  RA's and has a DHCPv6 server running (e.g. any OpenWrt router).

  2. When running `ip -6 a`, the list now sorts SLAAC addresses above
  DHCPv6 addresses. With NetworkManager 1.36.4 and earlier, this was not
  the case. (The Linux kernel uses the address highest in the list as
  preferred.)

  3. When running something like `curl ifconfig.co`, the SLAAC address is
  being returned, which makes sense as that is now preferred by the
  kernel. (But it shouldn't be.)

  Desired behaviour:

  NetworkManager should always sort DHCPv6 addresses above SLAAC
  addresses, as is the case for all versions prior to 1.36.6 and also
  corrected again in 1.38.0. In case static addresses are manually set,
  those should take first priority, with DHCPv6 second and SLAAC/autoconf
  last.

  Implications:

  This can break many real-life use cases. For instance, my router gives
  out static leases to my machines. Those addresses are whitelisted in all
  kinds of firewalls to allow me to access servers for my work. Now that
  the "wrong" address is being preferred for outgoing traffic (a SLAAC
  address that I have no influence on and cannot centrally configure), I
  am being locked out of the servers in question unless I forcefully
  remove the addresses or disable SLAAC on my router, so my outgoing
  traffic is being routed through the DHCPv6 address again.

  Note that "just disabling SLAAC RA's on the router" is not something
  everybody can do, as it requires root access to the device. Moreover, it
  would break IPv6 connectivity entirely for devices that don't support
  DHCPv6 (read: Android).

  Conclusion:

  So this update introduces a very breaking change in IPv6 source address
  selection to an LTS release, while LTS releases should be stable.

  I should note that the bug is not present in NetworkManager 1.38.0 on
  Debian sid. That just prefers DHCPv6 addresses when available, like it
  should. As that version is also used in Ubuntu kinetic, most likely this
  bug is not present there.

  Looking at the changelog of 1.38.0:

  * Fix bug setting priority for IP addresses.
  * Static IPv6 addresses from "ipv6.addresses" are now preferred over addresses from DHCPv6, which are preferred over addresses from autoconf. This affects IPv6 source address selection, if the rules from RFC 6724, section 5 don't give a exhaustive match.

  https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/nm-1-38/NEWS

  It looks like Ubuntu just introduced that bug by upgrading to 1.36.6,
  while a proper fix has only landed in 1.38.0, leaving the 1.36.x series
  now broken. Please either backport the fix from 1.38.0 or revert to
  1.36.4, which was working fine.

  System information:

  /etc/os-release:

  PRETTY_NAME="Ubuntu 22.04 LTS"
  NAME="Ubuntu"
  VERSION_ID="22.04"
  VERSION="22.04 LTS (Jammy Jellyfish)"
  VERSION_CODENAME=jammy
  ID=ubuntu
  ID_LIKE=debian
  HOME_URL="https://www.ubuntu.com/"
  SUPPORT_URL="https://help.ubuntu.com/"
  BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
  PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
  UBUNTU_CODENAME=jammy

  apt info network-manager:

  Package: network-manager
  Version: 1.36.6-0ubuntu1

  More background here: https://bugs.launchpad.net/ubuntu/+source/network-
  manager/+bug/1974428/comments/11

** Changed in: network-manager (Ubuntu)
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Network-
manager, which is subscribed to NetworkManager.
https://bugs.launchpad.net/bugs/1977619

Title:
  NetworkManager 1.36.6 no longer prefers DHCPv6 addresses over SLAAC

To manage notifications about this bug go to:
https://bugs.launchpad.net/network-manager/+bug/1977619/+subscriptions