Requesting an address with dhclient over dhcp6 does not always set the ipv6 prefix length
right. The address received seems always to get a /128 prefix set, even if the dhcp6 server
sends another one.

I would expect dhclient to set the prefix lenght, if the dhcp6 server sends one.

The code in /sbin/dhclient-script under the relevant section "### DHCPv6 Handlers" is the
same in Devuan Jessie, where I used reportbug to write this bug, Debian Stretch (4.3.5-3+deb9u1)
and in Debian Sid (4.4.1-2.1+b2).

In the code that does set the ipv6 address using iproute2 there is no prefix mentioned at all.
See line 385 and the following:

    385     BOUND6|RENEW6|REBIND6)
    386         if [ "${new_ip6_address}" ]; then
    387             # set leased IP
    388             ip -6 addr add ${new_ip6_address} \
    389                 dev ${interface} scope global
    390         fi

It could be that /sbin/dhclient should set the prefix to the address, I don't know.

This part has two problems: It should also be called upon reason REBOOT6 (see man dhclient-script(8))
and it should set the prefix if one was given (and not already present with the address). Something
like the following would help:

    385     BOUND6|RENEW6|REBIND6|REBOOT6)
    386         if [ "${new_ip6_address}" ]; then
    387
    388             # check wether a prefix was passed and add it to the address
    389             if [ -n "$new_ip6_prefixlen" ]; then
    390                 new_ip6_address_and_prefix="${new_ip6_address}/${new_ip6_prefixlen}"
    391             else
    392                 new_ip6_address_and_prefix="${new_ip6_address}"
    393             fi
    394
    395             # set leased IP
    396             ip -6 addr add ${new_ip6_address_and_prefix} \
    397                 dev ${interface} scope global
    398             fi

What really confuses me, is that ISC did change the IPv6 handling in the dhclient-script, but it is not
brought to Debian. In the upstream version they call a function "add_ipv6_addr_with_DAD". So I guess, the
bug is not present there. If I watch at the source package of 4.4.1-2.1, I do see the upstream changes, but
they are not present in the script that the binary package of 4.4.1-2.1+b2 delivers. Sorry, I don't
understand what's going on here.

Thank you for your help.


Regards, Adrian.

Hello Adrian,

[CC'ing the maintainers for the suggestion at the end]

I hope you don't mind me commenting on this issue, that I stumbled upon
by chance; I do not use isc-dhcp with IPv6, but spotted a
misunderstanding.

The DHCPv6 protocol does not take care of prefix length. This is a
property of the routing infrastructure, not the addressing
infrastructure, and is thus not conveyed by the DHCPv6 server but by
the router(s) advertising the prefix through Neighbour Discovery's
Router Advertisements.

The “issue” you see —I imagine— is that matching what prefix
advertisement correspond to what address, in the traditional IPv4
sense, is hard when done this way. And indeed, there is no formal
relation possible in IPv6, and often you will see a node address prefix
(/128) alongside the network prefix (/64 or whatever), but this does
not affect the correct functionning of the routing or addressing in any
way. This is on purpose in the IPv6 design, and it is a common mistake
to translate some IPv4 knowledge to IPv6 and ask this kind of question.

If there really is an issue with your setup, I think you should try to
describe it more precisely, and state what you expect exactly.

[…]

I looked and your are actually right that the function was not updated
in Debian's script. But your guess is wrong, even if the prefix length
mention suprised me at first: the new add_ipv6_addr_with_DAD does a bit
more with DAD (Duplicate Address Detection) validation before
returning, but this issue (DAD conflict) almost never happen and its
absence will not usually hinder you.

The part about the prefix length surprised me, but by looking at
client/dhclient.c, we can see that this parameter is the one provided
*by the user* launching dhclient (--address-prefix-len parameter). So I
think this is kind of a “workaround” for administrator really wanting
to hardcode the prefix length somewhere, and avoiding the /128 I
mentionned above. But this does not come at all from the DHCPv6 server,
as this concept does not exist in the protocol.

In the end, I think that appart from the script update which could use
the DAD helper, this bug is indeed not a bug.

Hope this helps. Regards,
--
Benjamin

Dear submitter,

as the package isc-dhcp has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/1143544

The version of this package that was in Debian prior to this removal
can still be found using https://snapshot.debian.org/.

Please note that the changes have been done on the master archive and
will not propagate to any mirrors until the next dinstall run at the
earliest.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Thorsten Alteholz (the ftpmaster behind the curtain)