dhclient in 'stateless' mode does not wait for ipv6 dad

[Dan Streetman]

[impact]

when configuring an interface in ifupdown to use 'inet6 auto' (SLAAC), the option 'dhcp 1' can also be used, which will use isc-dhcp-client to perform 'stateless' dhcpv6, which does not get a dhcpv6 address, only config info, like DNS domain and server, etc.

bug 1633479 fixed isc-dhcp-client to properly bring up and wait for the interface's ipv6 Duplicate Address Detection (DAD) to complete, which is required for isc-dhcp-client to be able to open a socket and begin broadcasting DHCPv6 requests. However, that fix is skipped when isc-dhcp-client is used in 'stateless' mode, so it fails in exactly the same way, for the same reason; isc-dhcp-client needs to be updated to perform the 'PREINIT6' call to the dhclient script, which properly sets up the interface for dhclient to use.

Without that setup, isc-dhcp-client in DHCPv6 'stateless' mode will always fail immediately when the interface it's using is down. If the interface is up, it will already have completed DAD and dhclient will work.

[test case]

configure ifupdown with:

auto eth0
iface eth0 inet6 auto
  dhcp 1

replacing eth0 with the interface to test. Make sure the interface is down, then ifup the interface. isc-dhcp-client will fail claiming that:

no link-local IPv6 address for eth0

Alternately, ifupdown can be bypassed; for an interface that is currently down, do:

$ sudo dhclient -6 -S eth0

which will fail immediately (the -S param uses 'stateless' mode).

[regression potential]

changing isc-dhcp-client to perform PREINIT6 adds a new point of failure for doing DHCPv6, so there is the potential to break existing DHCPv6 clients if the preinit fails. However, 'normal' DHCPv6 already does preinit6 - this only adds it to 'stateless' DHCPv6, so the failure potential should be limited to only users of 'stateless' DHCPv6, and those users are likely already seeing failures as described in this bug.

[other info]

This is related to bug 1633479

[Dan Streetman (ddstreet)]

this issue was raised before in bug 1633562, and closed as invalid because a side effect of isc-dhcp doing 'preinit6' is clearing any existing global ipv6 addresses from the interface, which definitely is not desirable when using RA to get the address.

[Dan Streetman (ddstreet)]

this is also related to bug 1447715 in which i added the DAD wait to ifupdown. however, since bug 1633479 fixed the issue in dhclient instead of ifupdown, at around the same time, i marked bug 1447715 as wontfix, since that ifupdown change was no longer required to get dhclient working.

But, now with this bug, the side-effect of changing dhclient to do its 'PREINIT6' (as mentioned in last comment) seems to be prohibitive and it probably is much easier to simply re-open bug 1447715 and push that ifupdown fix into xenial.

That approach does mean that manual running of dhclient -6 -S will always fail with an interface that's down (or was brought up immediately before running dhclient -S, which is what ifupdown does). However, while manually running dhclient -6 on a currently down interface in order to both bring it up and get a dhcpv6 address does make sense, running dhclient -6 -S on a down interface does not really make sense, since doing that will only get the 'other' network info like DNS server, and won't actually set up an address on the interface. So I think I have to agree with the conclusion in bug 1633562, to mark waiting for dad when manually running dhclient -6 -S as invalid.

So, I'll mark this bug as a dup of that original bug, and I'll re-open bug 1447715 to push that ifupdown fix into xenial.