Upstream provided me a patch to try which I uploaded to a ppa now,
https://launchpad.net/~ubuntu-desktop/+archive/ubuntu/ppa/+build/23833629
Could you install it and see if that fixes the issue?
** Changed in: network-manager (Ubuntu)
Status: Triaged => In Progress
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1977619
Title:
NetworkManager 1.36.6 no longer prefers DHCPv6 addresses over SLAAC
Status in NetworkManager:
New
Status in network-manager package in Ubuntu:
In Progress
Bug description:
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
To manage notifications about this bug go to:
https://bugs.launchpad.net/network-manager/+bug/1977619/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
