network-manager fails to deprecate addresses

[Eric C. Landgraf]

network manager does not properly deprecate autoconfigured temporary IP addresses when ValidLifetime for a prefix is 0 in router advertisements. This behaviour is non-compliant with RFC 4861 § 6.3.4, which reads:
        If the prefix is already present in the host's Prefix List as
        the result of a previously received advertisement, reset its
        invalidation timer to the Valid Lifetime value in the Prefix
        Information option. If the new Lifetime value is zero, time-out
        the prefix immediately.

The hosts instead continued to use temporary addresses configured until they reached their timeout, rather than immediately dropping the addresses. It further appears that it is generating new temporary addresses when the previous ones expire, but I have not been monitoring hosts closely enough to tell for sure---I will update on this when I have further information.

This problem was discovered on Ubuntu Studio 16.04.2; it is not present on Ubuntu Server (which uses Debian networking scripts).

Additional Info:

$ lsb_release -rd
Description: Ubuntu 16.04.2 LTS
Release: 16.04
$ apt-cache policy network-manager
network-manager:
  Installed: 1.2.6-0ubuntu0.16.04.1
  Candidate: 1.2.6-0ubuntu0.16.04.1
  Version table:
 *** 1.2.6-0ubuntu0.16.04.1 500
        500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     1.2.2-0ubuntu0.16.04.4 500
        500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages
     1.1.93-0ubuntu4 500
        500 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 Packages

[Julian Andres Klode (juliank)]

I can reproduce this on kinetic. I get sent a 2a02:908:2812:7d20::/64 prefix via RA with "valid lifetime" and ""preferred lifetime" set to 0, every 3s. Instead of the prefix being deleted from the interface, it's lifetime is set to 1s and then expires every second, causing regular "connection changed" type of errors in Chrome, it looks like this:

    inet6 2a02:908:2812:7d20::e9eb/128 scope global dynamic noprefixroute
       valid_lft 42961sec preferred_lft 42961sec
    inet6 2a02:908:2812:7d20:55e8:17dd:e766:a872/64 scope global deprecated dynamic noprefixroute
       valid_lft 6603sec preferred_lft 0sec

Reconnecting the WiFi gets rid of the /64 prefix.

I think my router is broken though, as it does not advertise any valid prefix, so you end up with *only* the /64 prefix until the router receives a new prefix from the ISP or reconfirms it or whatever, but still this is broken regardless.

[Julian Andres Klode (juliank)]

With systemd-networkd on the 20.04 server, the /64 prefix does not bounce between 0s and 1s, but stays at 0s, but is not removed (nor is the /128).

[Nick Rosbrook (enr0n)]

For the systemd-networkd case, can you set `SYSTEMD_LOG_LEVEL=debug` on systemd-networkd.service to see if it yields useful information?

[Julian Andres Klode (juliank)]

We believe the kernel handles RAs itself, adding a task for it.

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1699942

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Sebastien Bacher (seb128)]

The bug is from 2017 without activity until now, from a desktop perspective it isn't a rls issue, tagging a notfixing

[Nick Rosbrook (enr0n)]

This bug is stale, and it remains unclear if there is a systemd bug, so marking invalid.