Comparing the output of `ip -6 a`, you can see that the dynamic
addresses are no longer at the top of the list, where they should be.
Before (network-manager 1.36.4):
2: eno0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2a10:3781:xxxx::bd0/128 scope global dynamic noprefixroute
valid_lft 43193sec preferred_lft 43194sec
inet6 fd10:3781:xxxx::bd0/128 scope global dynamic noprefixroute
valid_lft 43193sec preferred_lft 43194sec
inet6 fd10:3781:xxxx:0:9875:4dec:b9f9:e768/64 scope global noprefixroute
valid_lft forever preferred_lft forever
inet6 2a10:3781:xxxx:0:f802:2428:9af1:dcb3/64 scope global noprefixroute
valid_lft forever preferred_lft forever
inet6 fe80::36e2:ec4c:fddb:3c89/64 scope link noprefixroute
valid_lft forever preferred_lft forever
After (network-manager 1.36.6):
2: eno0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 fd10:3781:xxxx:0:9875:4dec:b9f9:e768/64 scope global noprefixroute
valid_lft forever preferred_lft forever
inet6 2a10:3781:xxxx:0:f802:2428:9af1:dcb3/64 scope global noprefixroute
valid_lft forever preferred_lft forever
inet6 2a10:3781:xxxx::bd0/128 scope global dynamic noprefixroute
valid_lft 43194sec preferred_lft 43194sec
inet6 fd10:3781:xxxx::bd0/128 scope global dynamic noprefixroute
valid_lft 43194sec preferred_lft 43194sec
inet6 fe80::36e2:ec4c:fddb:3c89/64 scope link noprefixroute
valid_lft forever preferred_lft forever
On another machine with Debian sid and network-manager 1.38.0, it looks
like the way it should be again (dynamic addresses at the top of the
list, preferred to autoconfigured / temporary addresses):
2: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 fd10:3781:xxxx::5bf/128 scope global dynamic noprefixroute
valid_lft 43193sec preferred_lft 43193sec
inet6 2a10:3781:xxxx::5bf/128 scope global dynamic noprefixroute
valid_lft 43193sec preferred_lft 43193sec
inet6 2a10:3781:xxxx:0:42cd:4f1b:89b8:77fd/64 scope global noprefixroute
valid_lft forever preferred_lft forever
inet6 fd10:3781:xxxx:0:8a59:df52:9ea1:e7c8/64 scope global noprefixroute
valid_lft forever preferred_lft forever
inet6 fe80::a738:71dc:f10e:924e/64 scope link noprefixroute
valid_lft forever preferred_lft forever
So this bug was not present in NetworkManager 1.36.4, introduced in
1.36.6, and then fixed in 1.38.0.
--
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:
DHCPv6 addresses are no longer preferred over SLAAC addresses
Status in network-manager package in Ubuntu:
New
Bug description:
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.
NetworkManager has always been able to adhere to that by simply
setting ip6.privacy=0 for the connection.
So if you would - for instance - run `curl ifconfig.co`, the DHCPv6
address would be used to connect to the outside world.
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 RA's
altogether is the only way to stop NetworkManager from preferring
SLAAC over DHCPv6 now.
Looking at the changelog of NetworkManager 1.36.6, things regarding IP
address order and temporary addresses have been changed in that
release:
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.
Unfortunately, this introduced this bug, which is really breaking a
lot of my use cases.
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.
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 : [email protected]
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
