The issue seems triggered when a connection with LL IPv6 address still tentative is shut down as a consequence of the underlying device set to not managed. When a connection will be later again attached to the underlying device (so bringing it back in managed state) it will end up not generating the LL IPv6 address.

To reproduce locally:
* default ethernet connection A already up on interface eth0
# nmcli con down A
# nmcli con up A; nmcli device set eth0 managed no
# nmcli con up A

There will not be IPv6 address on eth0.

Digged more, found two issues, the first one detailed above and another one that makes the test fail:
1) The first issue is due to a race when upping and setting the device to unmanaged immediately.
In particular, if connection is upped and immediately device is set unmanaged, NM-internal device IP config is cleared due to the device unmanaged, but the platform event of the new IP6 address caused from the connection up, is got AFTER that, causing NM to recreate the internal IP6 config for the device (which is unmanaged).
When then the connection is upped again, when starting IPv6ll, NetworkManager wrongly founds an already present IPv6ll address for the device, so will skip generation of a new one: so no IPv6 address will be added.

2) When a device is unmanaged and then NetworkManager is restarted, it will recall that the device was unmanaged: anyway, if an IP6ll address is already configured on the device, the device internal device IP config will be populated with and the IP config will not be cleaned when setting the device unmanaged.
So, the same issue as in 1) (no IPv6) will happen when a connection for that device is upped.
To reproduce issue 2):
# nmcli con up A
# nmcli device set eth0 managed no
# service NetworkManager restart
# nmcli con up A

Device ip configuration is tracked by NetworkManager also when the device is not managed: despite not interfering with it, NetworkManager will keep tracking events from platform to expose on DBUS the ip configuration of the unmanaged device.

Both the issues described in c3 are caused by a race that happens when the IPv6LL address is removed and the device is being configured in NetworkManager: when checking if an IPv6LL address is there, if the address removal event has not already been processed, NetworkManager will be fooled that an IPv6LL address is already there, skipping IPv6LL generation.

Before checking for IPv6 addresses, check if there is some IPv6 event from platform waiting for being processed: if so do it immediately in order to do the check with up-to-date information.

branch: fg/ipv6_add_sync-rh1452046

The problem with this issue is that IPv6LL address will eventually be cleared if performing a "full" connection activation, as the one triggered by a "nmcli connection A up". If the device was already managed, it will correctly undergo a ip clear process at the very beginning of the activation.
Otherwise, it will be moved to the internal "managed" state later on, so skipping clearing of the internal device state and with it the IPv6LL address generation when needed as the current IPv6LL address will be cleared later.

Proper fix should be to mark the device as managed earlier if an explicit connection activation is performed on a device which was unmanaged or assumed. This would allow to let the device undergo the full clear process and avoid skipping IPv6LL address generation.

Please ignore fg/ipv6_add_sync-rh1452046 and instead review new branch:

fg/ipv6_add_sync-rh1452046-II

fg/ipv6_add_sync-rh1452046-II lgtm

Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.

Merged upstream to master:
https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=d4a033c4ad4ef4119eedfecae8e41e5ab2da4437

Merged upstream on nm-1-8 stable branch:
https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=cf726a51b9c9d0be4366b7932502f29babf88ce8

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0778