1

I'm using isc-dhcp-server version 4.3 (isc-dhcpd-4.3.5) as a DHCP server for my local IPv4 LAN and I'm trying to configure it to use the option dhcp-client-identifier (DHCP option 61) in a host declaration in order to identify a DHCP client:

host client_host {
  option dhcp-client-identifier xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx;
  fixed-address 192.168.0.20;
}

Unfortunately, the DHCP server seems to be ignoring this option (it doesn't complain about this option when starting – so the option is recognized and the syntax is correct). The address assignment works perfectly fine when I use hardware ethernet with the client's MAC, so I'm sure that otherwise both the DHCP server and the DHCP client are configured properly.

In the official ISC DHCP specification for the dhcpd.conf file (this is for version 4.1, and same thing is also in the documentation for version 4.4, so I'm assuming that this is also true for version 4.3.5, which I'm using) I've found the following:

Host declarations are matched to actual DHCP or BOOTP clients by matching the dhcp-client-identifier option specified in the host declaration to the one supplied by the client, or, if the host declaration or the client does not provide a dhcp-client-identifier option, by matching the hardware parameter in the host declaration to the network hardware address supplied by the client. BOOTP clients do not normally provide a dhcp-client-identifier, so the hardware address must be used for all clients that may boot using the BOOTP protocol.

I'm also sure that the DHCP client does send the dhcp-client-identifier in the DHCPv4 request – I've looked inside the packet using wireshark, and verified it conforms to RFC-4361. Also, according to the same RFC, a conformant DHCP Server cannot ignore this option:

DHCPv4 servers that conform to this specification MUST use the 'client identifier' option to identify the client if the client sends it.

At this point I'm assuming that the isc-dhcp-server does support the dhcp-client-identifier option (this assumption is based on the ISC DHCP specification). The refered ISC DHCP specification also describes a behaviour that is also conformant to the RFC (as quoted above).

So my question is – what am I missing here? Is there some additional ISC DHCP server configuration needed?

Or maybe isc-dhcpd does not support the dhcp-client-identifier option for IPv4 (and at the same time their official specification is incorrect)?

EDIT Perhaps I should mention that I have also a DHCPv6 server running in parallel to the DHCPv4 one. The DHCPv6 server is configured to use the same DUID and it works perfectly fine there:

host client_host {
  host-identifier option
      dhcp6.client-id xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx;

  fixed-address fdxx:xxxx:xxxx:xxxx::1;
}

The reason why I want to use the DUID also in the DHCPv4 configuration is that I want the DHCP servers to dynamically update my local DNS for both IPv4 and IPv6 networks. And the DNS server cannot identify a specific client using both the MAC address (received from the DHCPv4 server) and the DUID (from the DHCPv6 server) – it will only accept one form of identification and ignore the other one.

Tomek
  • 111
  • 1
  • 3

3 Answers3

2

I had a similar issue with ISC DHCP 4.4.1, which I got working by prepending the id with a 0xff, i.e.:

host TestHost {
        option dhcp-client-identifier ff:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx;
        fixed-address 192.168.1.1;
}

The clue was in the tcpdump output of the request where it indicated the client id was hardware-type 255.

Tim
  • 21
  • 1
  • The dhcp-client-identifier I'm using in my configuration already contains the hardware-type (it's value is 1 in my case). Moreover, it also contains the DUID Type, and the whole identifier consists of the following parts: <2 bytes duid-type><2 bytes hardware-type><4 bytes time><6 bytes link-layer-address> – Tomek Jun 18 '20 at 19:46
  • Also, I'm using identical id in the DHCPv6 server configuration and it works just fine there. I have tried removing the DUID Type part and reducing the Hardware Type part to just one byte, but this doesn't help. And since I'm planning on setting-up DNS for my local network, I need the exact same identifier to be set in both DHCPv4 and DHCPv6 configuration. – Tomek Jun 18 '20 at 19:56
  • This works with ISC DHCP v4.1-ESV-R16. Note: RFC-2132 says: "A hardware type of 0 (zero) should be used when the value field contains an identifier other than a hardware address". If a client follows that, then use "00:" instead of "ff:". – SKi Feb 02 '21 at 15:33
1

I've been facing this as well, and from what I've gathered the option is not officially supported in ISC DHCP 4.1 through 4.4. I've been playing with this as well as I have a trunk from my switch to my workstation such that I can monitor, and administer on any of my VLANs. Good news is that ISC is porting to a new DHCP software package called Kea, which is intended to have many more options available to you in both IPv4 and IPv6. Among these are DUID support, DDNS updates made on behalf of clients for both IP versions. No support is anticipated for Windows. Everything you've been asking about is in Kea, and as always; is available as a free download from ISC.

Guy
  • 11
  • 1
0

I too had this problem and overcame by using the identifier as: host TestHost { option dhcp-client-identifier 00:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx; fixed-address 192.168.1.1; } if the received client id is ascii based. for eth: put 01:xx:xx all in hexa

kalyan
  • 1