Comment 2 for bug 1977619

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 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.

The correct order for IPv6 addresses should be:

1. Static addresses (if present)
2. DHCPv6 addresses (shown as 'dynamic' with ip -6 a)
3. Temporary SLAAC addresses (in case IPv6 Privacy Extensions are enabled, otherwise not present)
4. Global SLAAC addresses (the long ones with :0: after the network part ending with /64)

With NetworkManager 1.36.6 the order is now 3 > 4 > 1 > 2.

I guess these commits are relevant:

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/c631aa48f034ade2b5cb97ccc4462d56d80174e7

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/257221d1986b56cbb2e329fcc74a2daca145b7aa

Bottom line: addresses are now being added in the wrong order, which is known and fixed upstream for 1.38.x, but never fixed for 1.36.x.