Comment 4 for bug 991360

Hi Stephane,

Sorry, I should have been clearer about that. I believe that I observed that the "<hostname>" magic only works with "option host-name" in the dhclient.conf file. 4.2 helps with this because it has the more generalized hostname() function which should be accepted in more places in the dhclient.conf file, such as after fqdn.fqdn. Sending a string hostname is nice, but that would require some way to populate fqdn.fqdn with the desired hostname - and that's something that even upstream (finally) agrees is something dhclient itself should know how to do.

The big question, I think, is whether there should be a separate dhclient6.conf file or not. I'm inclined to think there should be separate files; but that's just my opinion. I don't think it would be harmful to send fqdn.fqdn to a DHCPv4 server, but I don't know if people would expect that behavior from stock dhclient. Windows XP+ send both Option 12 (host-name) and Option 81 (fqdn.fqdn), and most of the DHCP servers I've run handle that just fine. But still, since options have different numbers and the wire protocol is so different, that means that DHCPv4 and DHCPv6 are effectively different services and should be orthogonal to each other.