Comment 7 for bug 1969901

>> The exact conditions for reproducing this bug on mixed IPv4/IPv6 networks are not known
>
>Looking at the upstream commit description, isn't it just that a DHCPv6 lease expires and the >server NAKs a request for the same IP again? Or is that not sufficient to trigger the problem.
>
Yes, when having a look at the previously collected logs, that seems to be the case (journalctl -u NetworkManager.service).

Some of our computers get this problem more often that other. Some persons claim that they have never seen the problem. That is the part that is unclear.

>In any case, I appreciate there might be difficulty in testing the fix, but what's the actual >criteria you propose to use to decide when the bug is to be marked verification-done-bionic?

In the best of worlds I would like to simulated environment where dhcp-packages could be controlled, but that is not feasible.

I have been running this patch on two computers since 2022-04-13 and haven't seen the problem since. One laptop (restarted every day) and one desktop that is always on.
The desktop has been running for 29 days continuously according to syslog, without me having to manually remove dhcp lease files and restart network manager.

Ideas for getting confidence of this change:
We could ask more users who have experienced this error to install this change and confirm if they experience lost ipv6 addresses after installing patched version.

Another idea is to shutdown computer in single user mode (without network), edit the dhcp6 lease file in a way so that dhcp-server will respond with NACK when booting up in multi-user mode.
What to change in the lease file I do not know.