isc-dhcp-client does not send hostnames in DHCPv6 by default

Bug #991360 reported by Martin Jackson
This bug affects 1 person
Affects Status Importance Assigned to Milestone
isc-dhcp (Ubuntu)
Fix Released
Stéphane Graber

Bug Description

DHCPv6 does not have a host-name option to send the client hostname to register with the DHCP server. There are several potential options here:

1) Use the same "magic" to insert the hostname via fqdn.fqdn (i.e. "send fqdn.fqdn "<hostname>";" This should work with DHCPv4 as well.
2) Backport the gethostname() functionality from DHCP 4.2.
3) Upgrade to isc-dhcp-client 4.2.

Perhaps some of these are more appropriate to consider for the Q cycle. Personally, I think option 1 (implementing "<hostname>" magic) for fqdn.fqdn would be the least intrusive.

As issues go, this is admittedly minor.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: isc-dhcp-client 4.1.ESV-R4-0ubuntu5
ProcVersionSignature: Ubuntu 3.2.0-24.37-generic 3.2.14
Uname: Linux 3.2.0-24-generic x86_64
ApportVersion: 2.0.1-0ubuntu7
Architecture: amd64
CheckboxSubmission: 014d169fc2d78562c156088c6ab6adc0
CheckboxSystem: c69722ecac764861be52925fa50b4dcc
Date: Sun Apr 29 13:19:49 2012

 PATH=(custom, user)
SourcePackage: isc-dhcp
UpgradeStatus: Upgraded to precise on 2012-04-15 (14 days ago)
mtime.conffile..etc.dhcp.dhclient.conf: 2011-09-26T21:03:34.986111

Related branches

CVE References

Revision history for this message
Martin Jackson (mhjacks) wrote :
summary: - isc-dhcp-client does not register IPv6 names by default
+ isc-dhcp-client does not send hostnames in DHCPv6 by default
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in isc-dhcp (Ubuntu):
status: New → Confirmed
Revision history for this message
Stéphane Graber (stgraber) wrote :

For 12.10 we're moving to 4.2. What makes you think 4.2 will magically fix that though?

As far as I can see the default dhclient.conf in 4.2 still doesn't set fqdn.fqdn.

Changed in isc-dhcp (Ubuntu):
status: Confirmed → In Progress
assignee: nobody → Stéphane Graber (stgraber)
importance: Undecided → Low
Revision history for this message
Martin Jackson (mhjacks) wrote :

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.

Revision history for this message
Stéphane Graber (stgraber) wrote :

As far as I can tell, fqdn.fqdn doesn't seem to be problematic to set as based on a quick read of the RFC, it's not actually required for it to be an actual fqdn (gethostname() will only return the hostname, not the fqdn).

So until such time that we get a getfqdn() (retuning hostname -f), I'm going to go with setting it for both ipv4 and ipv6 to the value of gethostname().

Changed in isc-dhcp (Ubuntu):
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (7.6 KiB)

This bug was fixed in the package isc-dhcp - 4.2.4-1ubuntu1

isc-dhcp (4.2.4-1ubuntu1) quantal; urgency=low

  * Merge from Debian. Remaining changes:
    (LP: #768171, LP: #841182, LP: #881558, LP: #872929, LP: #616809)
    - Use upstart jobs for isc-dhcp-server and isc-dhcp-relay.
    - Add IPv6 support to udeb dhclient-script (forwarded as Debian #635897).
    - Add an apport hook to isc-dhcp-client and isc-dhcp-server.
    - Add an apparmor profile to isc-dhcp-client and isc-dhcp-server.
    - Update default dhclient.conf to ask for IPv6 configuration.
    - Patches:
      + dhclient-fix-backoff
      + dhclient-more-debug
      + dhclient-onetry-call-clientscript
      + dhclient-safer-timeout
      + dhcpd.conf-subnet-examples
      + multi-ip-addr-per-if
      + onetry_retry_after_initial_success
      + revert-next-server
  * Set fqdn.fqdn to the result of gethostname(); (LP: #991360)
  * Replace old droppriv and deroot patches by use of --enable-paranoia
    and matching -user and -group parameters to dhcpd. (LP: #727837)
  * Allow read access to /etc/dhcp/ddns-keys/* for ddns. (LP: #341817)
    It's expected that people generate one key per zone and have it stored
    in both /etc/bind9 and /etc/dhcp/ddns-keys/ for security reason.
  * Fix apport hook to work with python3.

isc-dhcp (4.2.4-1) unstable; urgency=low

  * New upstream release
  * debian/control: reformatted Uploaders so that dch doesn't think I'm making
  * debian/rules: do a clean between the LDAP-enabled build and the
    non-LDAP-enabled one, so that no LDAP-related artefacts are accidently
    incorporated into the non-LDAP build
  * debian/dhclient-script.*: conditionalise the chown/chmod of the new
    resolv.conf on the existence of the old one (closes: #595400)
  * debian/dhclient-script.linux: comply with RFC 3442 and ignore
    the routers option if the rfc3442-classless-static-routes option is present
    (closes: #592735)
  * debian/dhclient-script.kfreebsd: fix subnet mask handling (closes: #677985)

isc-dhcp (4.2.2.dfsg.1-5) unstable; urgency=medium

  [ Andrew Pollock ]
  * debian/dhclient.conf: send the hostname (closes: #151820)

  [ Michael Gilbert ]
  * Fix cve-2011-4868: error in DDNS handling with IPv6 (closes: #655746)
  * Fix cve-2011-4539: error in regular expression handling
    (closes: #652259)
  * Make dependencies diff-able
  * Add myself to uploaders
  * Remove all automatically generated files in clean rule
  * Medium urgency for security updates

isc-dhcp (4.2.2.dfsg.1-4) unstable; urgency=low

  * The "Zoe woke up at 4am and I couldn't get back to sleep so I had some
    extra time to work on this" release
  * patch the Makefile for the embedded BIND libraries so that autoconf is run
    so that the modification to to fix the FTBFS on kFreeBSD
    actually does something useful (closes: #643569)

isc-dhcp (4.2.2.dfsg.1-3) unstable; urgency=low

  * debian/control: remove transitional packages
  * debian/rules: apply the intent of Pierre Chifflier's patch to enable
    hardening options (closes: #644413)
  * debian/control: also add inetutils-ping to the dependencies for
    isc-dhcp-client on hurd (...


Changed in isc-dhcp (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
Thomas Hood (jdthood) wrote :

In light of the following changelog entry, should this report (bug #991360) be reopened?

isc-dhcp (4.2.4-1ubuntu10.2) quantal-proposed; urgency=low
  * Don't set fqdn.fqdn in dhclient.conf as that seems to confuse some DHCP
    servers. An alternative would have been to only set fqdn.fqdn and not
    host-name, but that appears to confuse another set of servers.
    For now go with just host-name which is the most common and if becomes a
    big problem for IPv6 (where fqdn.fqdn is apparently required), then we'll
    need to have a separate dhclient6.conf file and change all the calls to
    dhclient -6 to use that file instead. (LP: #1088682)
 -- Stéphane Graber <email address hidden> Fri, 01 Mar 2013 16:07:49 -0500

Revision history for this message
Craig McQueen (cmcqueen1975) wrote :

The opening line is somewhat misleading, even if in some sense it may be technically correct.

> DHCPv6 does not have a host-name option to send the client hostname to register with the DHCP server.

See option 39 OPTION_CLIENT_FQDN, and RFC 4704 "The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option".

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers