Comment 0 for bug 1812760

[Impact]

Users cannot create IPv6 routes that specify PreferredSource. This means that users cannot specify a number of valid IPv6 routes that are useful in some circumstances. These routes can be created with the 'ip' tool, just not with systemd.

This was reported upstream in systemd issue #5882 is fixed by pulling in the changes in systemd PR #11375 - https://github.com/systemd/systemd/pull/11375

[Test Case]

Start a Bionic or Cosmic VM.

Add the following netplan yaml (adjust for ethernet card and MAC):

network:
    version: 2
    ethernets:
        ens3:
            dhcp4: true
            match:
                macaddress: 52:54:00:e2:c2:d7
            set-name: ens3
            addresses: ["fd8f:1d7d:b141::2/64", "fd8f:1d7d:b141::200/64"]
            routes:
              - to: "a::/16"
                via: "fd8f:1d7d:b141::1"
                from: "fd8f:1d7d:b141::2"
              - to: "fd8f:1d7d:b141::/64"
                scope: link
                from: "fd8f:1d7d:b141::2"
                metric: 255

Run netplan apply or reboot. Wait ~10s.

Currently, ip -6 route will not include a route to "a::/16", and will not include the route to "fd8f:1d7d:b141::/64" that has "fd8f:1d7d:b141::2" as the source address - both those addresses will be missing.

Correct behaviour is for ip -6 route to report the following:

ubuntu@b-np:~$ ip -6 route
a::/16 via fd8f:1d7d:b141::1 dev ens3 proto static src fd8f:1d7d:b141::2 metric 1024 pref medium
fd8f:1d7d:b141::/64 dev ens3 proto static src fd8f:1d7d:b141::2 metric 255 pref medium
fd8f:1d7d:b141::/64 dev ens3 proto kernel metric 256 pref medium
fe80::/64 dev ens3 proto kernel metric 256 pref medium

[Regression Potential]

This changes the state machine in systemd which configures the links. It passes systemd's internal tests, and has been approved by systemd maintainers, but it remains possible that the changes will break the configuration of obscure network setups.

The backport requires pulling in two further commits that also change behaviour: currently systemd deletes all addresses and routes that were attached to an interface. With this change, it will only delete those that are not specified in the configuration files. I do not know how this could cause issues - it moves from a surprising behaviour to a less surprising behaviour, but it's worth pointing out.