When using DHCPv6 with ifupdown it requires a link-local address.  After the interface
is brought up, the wait-for-ll6.sh script is supposed to be used to wait for the address
to be non-tentative (duplicate address detection has finished) before moving on to the
next phase.  This file lives in /usr/lib/ifupdown by default.

The problem is that the 'inet6' provider (defined in the source in inet6.defn and compiled
into the binary) uses the execable() function to decide whether to run it or not:

    wait-for-ll6.sh if (var_true("dhcp", ifd) && execable("wait-for-ll6.sh"))

execable() only looks through the PATH if 'program' does not start with a leading /.
Because /usr/lib/ifupdown is not in the default PATH, the script is never run.

You can see this in action by running 'ifup -v xxxx' with an appropriate interface configured.
It will show that 'ip link set dev XXXX up' was run, and then immediately runs the dhcp
client (in my case isc-dhcp-client) and fail because there is no link-local address.

If you then bring down the interface and make sure to flush the v6 addresses
(ip -6 addr flush XXXX) and run 'PATH=/usr/lib/ifupdown:$PATH ifup -v xxxx' it will
show that 'ip link set dev XXXX up' is run, then wait-for-ll6.sh, and then the dhcp
client, and it succeeds.

If debian is going to put these scripts into /usr/lib/ifupdown, then execable()
should look there first, and THEN check the PATH.

This seems like a direct result of this change:

commit 1eee7a3040eb7ba295c44beddbfb44abf342ca2c
Author: Guillem Jover <guillem@hadrons.org>
Date:   Sun Dec 3 02:51:43 2023 +0100

    Use relative names when executing programs

    This switches program invocations to use relative names, so that we
are
    then not concerned about the filesystem layout of the system we are
    installing into.

    While for programs we ship and install we will know the end
destination
    and could simply replace that at build or install time, that seemed
more
    effort than simply making all usage relative.