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. On Sun, 05 Apr 2020 13:20:14 +0200 Adrian Zaugg <a...@ente.limmat.ch> wrote: > I would expect dhclient to set the prefix lenght, if the dhcp6 server sends > one. 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. […] > 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. 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
