dhclient does not wait for ipv6 dad (duplicate address detection)

Note, bug 1447715 fixes ifupdown for this, but it seems to me that the fix is better suited here.

So I'm not convinced that doing this in dhclient is necessarily right. Unlike IPv4 where DHCP operates over a raw socket, in IPv6 mode, dhclient is just a regular network client and as such requires a source address to be set so it can contact the network (the link-local address in this case).

As dhclient is supposed to only be triggered after a RA has been received and parsed, it should be the job of whatever handles the RA to wait until a viable link-local has been established before triggering dhclient.

That being said, since we don't seem to have anything that handles that first configuration step properly, this workaround certainly won't hurt and will fix the current race condition.

This bug was fixed in the package isc-dhcp - 4.3.3-5ubuntu16

---------------
isc-dhcp (4.3.3-5ubuntu16) zesty; urgency=medium

  * ipv6: wait for duplicate address detection to finish (LP: #1633479).

 -- Scott Moser <email address hidden> Thu, 20 Oct 2016 12:55:33 -0400

Hello Scott, or anyone else affected,

Accepted isc-dhcp into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/isc-dhcp/4.2.4-7ubuntu12.8 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Hello Scott, or anyone else affected,

Accepted isc-dhcp into precise-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/isc-dhcp/4.1.ESV-R4-0ubuntu5.12 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Hello Scott, or anyone else affected,

Accepted isc-dhcp into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/isc-dhcp/4.3.3-5ubuntu12.4 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Hello Scott, or anyone else affected,

Accepted isc-dhcp into yakkety-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/isc-dhcp/4.3.3-5ubuntu15.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

isc-dhcp-client 4.3.3-5ubuntu12.4 fixed the problem for me.

This bug was fixed in the package isc-dhcp - 4.3.3-5ubuntu12.4

---------------
isc-dhcp (4.3.3-5ubuntu12.4) xenial; urgency=medium

  * ipv6: wait for duplicate address detection to finish (LP: #1633479).

 -- Scott Moser <email address hidden> Mon, 31 Oct 2016 14:32:14 -0400

I've verified that this fixes issue on yakkety.

## Set up a network in lxc that listens to dhcp ipv4 and ipv6

$ netname="v4and6"
$ profname="$netname-profile"
$ cnamepre="v4v6-"
$ lxc network create $netname
Network v4and6 created

$ lxc network set $netname ipv6.dhcp.stateful true
$ lxc profile create $profname
$ lxc profile device add $profname eth0 nic nictype=bridged parent=$netnam
Device eth0 added to v4and6-profile

$ lxc network show $netname
name: v4and6
config:
  ipv4.address: 10.152.128.1/24
  ipv4.nat: "true"
  ipv6.address: fd42:198e:d2a5:1d10::1/64
  ipv6.dhcp.stateful: "true"
  ipv6.nat: "true"
managed: true
type: bridge
usedby: []

$ lxc profile show $profname
name: v4and6-profile
config: {}
description: ""
devices:
  eth0:
    nictype: bridged
    parent: v4and6
    type: nic
usedby: []

## Now launch a container to verify
$ rel=yakkety
$ cname=v5v6-$rel
$ lxc launch ubuntu-daily:$rel --profile=$profname $cname
$ sleep 20; # give it time to come up
% lxc exec $cname /bin/bash

## inside
$ dev=eth0;
$ ifdown $dev; ip link set down dev $dev; killall dhclient;
Killed old client process
$ dhclient -6 -1 -v $dev
...
Can't bind to dhcp address: Cannot assign requested address
Please make sure there is no other dhcp server
...
$ echo $?
1

## That verified busted. now fix.
$ ifup eth0 # brings up ipv4 dhcp properly
$ m=http://archive.ubuntu.com/ubuntu
$ echo "deb $m $(lsb_release -sc)-proposed main" | sudo tee /etc/apt/sources.list.d/proposed.list

$ sudo apt-get install isc-dhcp-client
$ dpkg-query --show isc-dhcp-client
isc-dhcp-client 4.3.3-5ubuntu15.1

$ ifdown $dev; ip link set down dev $dev; killall dhclient;
$ dhclient -6 -1 -v $dev
...
message status code Success: "success"
PRC: Bound to lease 00:01:00:01:1f:c5:e1:fb:b8:ae:ed:75:5f:9a.

$ echo $?
0

I can also confirm trusty and precise as shown above.
They behave differently, in that instead of exiting failure, dhclient actually tries again and ends up getting an address. So in precise you would see:

| # dhclient -6 -1 -v $dev
| Internet Systems Consortium DHCP Client 4.1-ESV-R4
| Copyright 2004-2011 Internet Systems Consortium.
| All rights reserved.
| For info, please visit https://www.isc.org/software/dhcp/
|
| Bound to *:546
| Listening on Socket/eth0
| Sending on Socket/eth0
| PRC: Confirming active lease (INIT-REBOOT).
|
| XMT: Forming Confirm, 0 ms elapsed.
| XMT: X-- IA_NA 3e:28:e6:37
| XMT: | X-- Confirm Address fd42:198e:d2a5:1d10:1e4c:ac80:7f2e:f59e
| XMT: V IA_NA appended.
| XMT: Confirm on eth0, interval 920ms.
| send_packet6: Cannot assign requested address
| dhc6: sendpacket6() sent -1 of 84 bytes
| [***** short pause here *****]
| XMT: Forming Confirm, 920 ms elapsed.
| XMT: X-- IA_NA 3e:28:e6:37
| XMT: | X-- Confirm Address fd42:198e:d2a5:1d10:1e4c:ac80:7f2e:f59e
| XMT: V IA_NA appended.
| XMT: Confirm on eth0, interval 1910ms.
| send_packet6: Cannot assign requested address
| dhc6: sendpacket6() sent -1 of 84 bytes
| [***** short pause here *****]
| XMT: Forming Confirm, 2830 ms elapsed.
| XMT: X-- IA_NA 3e:28:e6:37
| XMT: | X-- Confirm Address fd42:198e:d2a5:1d10:1e4c:ac80:7f2e:f59e
| XMT: V IA_NA appended.
| XMT: Confirm on eth0, interval 3710ms.
| RCV: Reply message on eth0 from fe80::3896:5cff:fe61:baf0.
| RCV: X-- Server ID: 00:01:00:01:1f:c5:e1:fb:b8:ae:ed:75:5f:9a
| message status code Success: "all addresses still on link"
| PRC: Bound to lease 00:01:00:01:1f:c5:e1:fb:b8:ae:ed:75:5f:9a.

After the fix you see:
| # dhclient -6 -1 -v $dev
| Internet Systems Consortium DHCP Client 4.1-ESV-R4
| Copyright 2004-2011 Internet Systems Consortium.
| All rights reserved.
| For info, please visit https://www.isc.org/software/dhcp/
|
| Bound to *:546
| Listening on Socket/eth0
| Sending on Socket/eth0
| PRC: Confirming active lease (INIT-REBOOT).
|
| XMT: Forming Confirm, 0 ms elapsed.
| XMT: X-- IA_NA 3e:28:e6:37
| XMT: | X-- Confirm Address fd42:198e:d2a5:1d10:1e4c:ac80:7f2e:f59e
| XMT: V IA_NA appended.
| XMT: Confirm on eth0, interval 920ms.
| send_packet6: Cannot assign requested address
| dhc6: sendpacket6() sent -1 of 84 bytes

So I'm marking this fixed on precise and trusty also as we fix the error messages like:
  send_packet6: Cannot assign requested address
  dhc6: sendpacket6() sent -1 of 84 bytes

Hello Scott, or anyone else affected,

Accepted isc-dhcp into yakkety-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/isc-dhcp/4.3.3-5ubuntu15.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

It looks like the updates to Trusty and Precise can now be released. Scott, there's .git noise in the Precise diff: http://launchpadlibrarian.net/291515979/isc-dhcp_4.1.ESV-R4-0ubuntu5.11_4.1.ESV-R4-0ubuntu5.12.diff.gz - do you want me to release anyway?

Yakkety has been superseded by bug 1621507 and is now blocked by the verification of that bug and the minimum aging period.

This bug was fixed in the package isc-dhcp - 4.2.4-7ubuntu12.8

---------------
isc-dhcp (4.2.4-7ubuntu12.8) trusty; urgency=medium

  * ipv6: wait for duplicate address detection to finish (LP: #1633479).

 -- Scott Moser <email address hidden> Mon, 31 Oct 2016 14:31:58 -0400

I've removed the verification-needed tag that seemed to have been blocking this into precise-updates.
My comment in 13 stands, as I verified on precise at that time, and added the verification-done-precise tag.

Robie,
wrt git noise on precise, I'm not fussed either way. I can re-upload if you'd like.

Scott, while this is a linux-specific change (and not applicable to upstream isc-dhcp itself), it doesn't look like this fix is upstream in debian; have you opened a bug there and/or are you planning to push it up?

The verification of the Stable Release Update for isc-dhcp has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

This bug was fixed in the package isc-dhcp - 4.1.ESV-R4-0ubuntu5.12

---------------
isc-dhcp (4.1.ESV-R4-0ubuntu5.12) precise; urgency=medium

  * ipv6: wait for duplicate address detection to finish (LP: #1633479).

 -- Scott Moser <email address hidden> Mon, 31 Oct 2016 14:30:03 -0400

This bug was fixed in the package isc-dhcp - 4.3.3-5ubuntu15.2

---------------
isc-dhcp (4.3.3-5ubuntu15.2) yakkety; urgency=medium

  * debian/initramfs/lib/etc/dhcp/dhclient-enter-hooks.d/config: fix script to
    not write to /run/net-$iface.conf when dealing with IPv6; which should only
    write to a /run/net6-$iface.conf file. (LP: #1621507)
  * debian/README.Debian: document what this config script is and why a hook is
    shipped for the initramfs.

isc-dhcp (4.3.3-5ubuntu15.1) yakkety; urgency=medium

  * ipv6: wait for duplicate address detection to finish (LP: #1633479).

 -- Mathieu Trudel-Lapierre <email address hidden> Fri, 21 Oct 2016 12:46:20 -0400

This does *not* appear to resolve a closely related problem where the link-local address has not yet been assigned. See LP: 1718568

In brief, the loop

        case " $out " in
            *\ dadfailed\ *)
                error "$dev: ipv6 dad failed."
                return 1;;
            *\ tentative\ *) :;;
            *) return 0;;
        esac

exits with 'return 0' with the lack of a link-local address as " " ($out empty) matches the default pattern as would a valid, link-local address.

One possible solution is to add "the missing case" that matches $out being empty that performs the "wait and try again" action.

Additional note for this bug: this has been "fixed" upstream by adding a --dad-wait-time parameter to dhclient. However, that param defaults to 0, and also requires an update to the dhclient-script.linux that isc-dhcp provides. Debian has its own modified dhclient-script.linux, slightly different than upstream, which is what we modified to fix this bug.

The upstream bug is:
https://bugs.isc.org/Public/Bug/Display.html?id=36169

I don't personally recommend using the upstream isc-dhcp "fix" for this; our change to the dhclient-script.linux maintained by debian/ubuntu is a better fix, at least for the SRU releases; and our change doesn't require tooling that uses dhclient to add a new --dad-wait-time parameter.