OIT DHCP Service has been modified to perform an additional validation check on requests it receives from clients.
This change will resolve a DHCP problem for some clients.
As a side effect, a small number of DHCP clients that have been (mostly misconfigured or malfunctioning ones) receiving OIT DHCP service will stop receiving that service. (Most of these are DHCP clients which were misconfigured or malfunctioning; a handful are DHCP clients using a rarely-used way to identify themselves.) These DHCP clients will need to be reconfigured to resume functioning. Specifically, DHCP clients that send a DHCP Client Identifier that differs from the client's hardware type and hardware address will need to be reconfigured. Most common reasons (and solutions) for such a mismatch appear below.
Every request sent from a DHCP client to DHCP servers contains a hardware type and a client hardware address. For Ethernet and 802.11 wireless clients, the hardware type is always 01. The client hardware address is simply the hardware address of the client's network (Ethernet or Wireless) interface. (For example, 0:1:2:a0:bc:d3, also written as 00:01:02:a0:bc:d3, 000102a0bcd3, or 00 01 02 a0 bc d3.)
Every request sent from a DHCP client to DHCP servers may optionally also contain a DHCP Client Identifier option. This is an arbitrary value that may be used to identify a client instead of the hardware type and client hardware address. Traditionally, the DHCP Client Identifier (when present) has been set to a value equal to the hardware type followed by the client hardware address. (For example, 01 00 01 02 a0 bc d3.)
On the campus network, devices (more precisely, network interfaces) are uniquely identified by their (Ethernet or Wireless) hardware addresses. OIT DHCP Service (and OIT BootP Service) provides service to clients based on their hardware addresses.
A number of years ago, some operating systems were enhanced to allow customers to configure their DHCP client software to use arbitrary DHCP Client Identifier values. The software used to configure the device's network interface was changed to add a place for the customer to override the default DHCP Client Identifier. Leaving that field empty caused the DHCP client software to continue to operate as before; it either added no DHCP Client Identifier option in its requests to the DHCP server, or it sent a DHCP Client Identifier option that matched its hardware type and hardware address.
Not understanding the purpose of this field, some customers on campus mistakenly entered arbitrary values into this new field. This caused their DHCP client software to send a DHCP Client Identifier option to the DHCP server with an arbitrary value that no longer matched the client's hardware type and hardware address. Since OIT DHCP Service (and OIT BootP Service) identifies clients by hardware address, this caused those DHCP clients to stop receiving OIT DHCP Service.
To shield those customers from the misconfiguration on their DHCP client software, in 1998 OIT modified OIT DHCP Service to ignore the DHCP Client Identifier option. It instead relied solely on the hardware type and client hardware address fields. That allowed even clients configured to send bad DHCP Client Identifier values to continue to receive service.
Recently we have learned there are some devices trying to use varying DHCP Client Identifier values to simultaneously obtain more than one IP address for a single network interface. In particular, each device involved sends all its DHCP requests using the same hardware type and client hardware address, but differentiates among the requests by using different DHCP Client Identifiers. Since the 1998 modification caused the DHCP servers to ignore the DHCP Client Identifiers, the DHCP servers viewed all the device's DHCP requests as coming from a single client, yet the device viewed these as requests from multiple different DHCP clients. This difference caused the device to believe it had obtained leases on multiple IP addresses (one per DHCP Client Identifier) while in fact OIT DHCP Service had leased only a single IP address to the device (one per client hardware address).
To stop that from happening, we have removed the 1998 modification we had made to OIT DHCP Service. We have replaced it with a new modification to validate the DHCP Client Identifier value sent by the client. If a DHCP client sends no DHCP Client Identifier option, the service continues to operate as it has in the past. If a DHCP client sends a DHCP Client Identifier option, the DHCP server validates the value to ensure it matches the hardware type and client hardware address. If the values match, the DHCP server provides service to the client as it has in the past. If the values do not match, the DHCP server does not respond to the client's request.
The benefit of this change is that clients behaving as described earlier will no longer believe they have been leased multiple IP addresses. The DHCP requests they send with a DHCP Client Identifier that matches the hardware type and client hardware address will receive DHCP service. The other DHCP requests they send (with DHCP Client Identifiers that do not match the hardware type and client hardware address) will not receive DHCP service.
A drawback of this change is that the DHCP clients (mostly misconfigured or malfunctioning ones) that were helped by the 1998 modification will no longer receive OIT DHCP Service. To date, this has affected a small number (47) of clients. To regain OIT DHCP Service, those DHCP clients will need to be configured so they no longer send a mismatched DHCP Client Identifier. Common causes for that issue appear in a section below.
We believe this additional validation is a reasonable change to make to OIT DHCP Service, because the service has never been intended to lease more than one IP address at a time to a device's network interface.
BootP clients do not send a DHCP Client Identifier, so aren't affected.
The most common reasons that a DHCP client will send a DHCP Client Identifier that differs from its hardware type and client hardware address include:
Here's where that setting is located for some common platforms:
If the printer's DHCP client software can be reconfigured to stop sending any DHCP Client Identifier, you may choose to do that. Or reconfigure the printer so it doesn't rely on its DHCP client software; have it learn its IP information via BootP or manual configuration. Or get the vendor to fix the DHCP client firmware (through a firmware update).
Apparently, these are attempts by RAS to obtain additional IP addresses for potential dial-in clients. In nearly all cases, RAS was enabled by mistake; disabling it will resolve the issue.
The DHCP client software may use terminology such as "enabling DUID" to refer to this behavior. In that case, reconfiguring the DHCP client software to "disable DUID" may cause the DHCP client to instead send the kind of DHCP Client Identifier we expect: a hardware type followed by a hardware address.
Those versions of Fedora can be reconfigured to stop doing that by editing the file /etc/dhcp/dhclient.conf to specify:
send dhcp-client-identifier = hardware;
If the file does not yet exist, you may need to create it. See the dhclient.conf(5) man page which came with your software.
Reconfigure the ALOM card so it doesn't rely on DHCP to obtain its IP address. Or if you had attached the ALOM card's Ethernet interface to the campus network in error, simply disconnect the ALOM card's Ethernet interface from the campus network.