** Description changed: - My network has both DHCPv6 and SLAAC for IPv6. From both a privacy - perspective and readability reasons, 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. + Situation: + + My network has both DHCPv6 and SLAAC 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. Setting net.ipv6.conf.all.use_tempaddr=0 and net.ipv6.conf.<interface>.use_tempaddr=0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's - altogether is the only way to stop NetworkManager from preferring SLAAC - over DHCPv6 now. + on the router is the only way to stop NetworkManager from preferring + SLAAC over DHCPv6 now. None of the local options in NetworkManager + 1.36.6 are able to restore the previous, desired and correct way of + working. - Looking at the changelog of NetworkManager 1.36.6, things regarding IP - address order and temporary addresses have been changed in that release: + Looking at the changelog of NetworkManager 1.36.6, multiple things + regarding IP address order and temporary addresses have been changed in + that release: * 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 - When running `ip -6 a`, the list now sorts SLAAC addresses above DHCPv6 - addresses. With NetworkManager 1.36.4 this was not the case. (The Linux - kernel uses the address highest in the list as preferred.) + + 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 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), 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. + 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. + + + 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. + 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 + + So it looks like Ubuntu just introduced that bug by upgrading to 1.36.6. + 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 - nmcli -v: + apt info network-manager: - nmcli tool, version 1.36.6 + Package: network-manager + Version: 1.36.6-0ubuntu1 - 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 - - So it looks like Ubuntu just introduced that bug by upgrading to 1.36.6. - Please either backport the fix from 1.38.0 or revert to 1.36.4, which - was working fine. - - More background here: https://bugs.launchpad.net/ubuntu/+source/network- - manager/+bug/1974428/comments/11 + More background here: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1974428/comments/11
-- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1977619 Title: NetworkManager 1.36.6 orders IPv6 addresses incorrectly Status in network-manager package in Ubuntu: Confirmed Bug description: Situation: My network has both DHCPv6 and SLAAC 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. Setting net.ipv6.conf.all.use_tempaddr=0 and net.ipv6.conf.<interface>.use_tempaddr=0 with sysctl also no longer has any effect. Removing the SLAAC addresses with `ip addr del` or disabling SLAAC RA's on the router is the only way to stop NetworkManager from preferring SLAAC over DHCPv6 now. None of the local options in NetworkManager 1.36.6 are able to restore the previous, desired and correct way of working. Looking at the changelog of NetworkManager 1.36.6, multiple things regarding IP address order and temporary addresses have been changed in that release: * 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 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. 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 So it looks like Ubuntu just introduced that bug by upgrading to 1.36.6. 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 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1977619/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
