pfSense

Jim Pingle wrote in #note-1:

This is likely due to some client behavior, not the server, but this isn't the place to discuss and diagnose the issue. Start a forum thread to gather more information and this can be reopened with more accurate details if anything actionable is discovered.

Come on, DHCP server issued dynamic IP address for MAC address that is clearly configured to static mapping.
How on earth is this possibly not a bug???

Switching to ISC DHCP server makes the problem instantly go away, it only happens with Kea DHCP server.

Captured pcap file and provided description is sufficient for you to easily reproduce it on your own. There is no more information needed here to act upon it.
So please don't reject legitimate and obvious bugs as vague "some client behavior".

ISC DHCP failed to follow the DHCP spec in several ways, so it exposes some more undesirable client problems and configuration quirks that never should have worked, but happened to work by luck.

The packet capture shows the client rejecting the first address it was assigned and requesting a new address, which the server denied, and then it sent a request with much different client identifiers than the initial request. This is likely causing it to fail to match something in your configuration you expect, which needs to be diagnosed on the forum.

If it's a bug, it's almost certainly upstream in Kea, not in the configuration, but again, that's something that needs to be hashed out on the forum, not here.

I'd like to revisit the "Not a Bug" classification with specific citations from RFC 2131.

The address selection algorithm requires honoring the binding first

Section 4.3.1 defines the address selection order for DHCPDISCOVER as:

"The client's current address as recorded in the client's current binding, ELSE [...] A new address allocated from the server's pool"

A static reservation is the binding. Per the spec, it is the first priority - it must be honored before falling through to the dynamic pool.
The conflict resolution logic that bypasses this binding in favor of a pool address inverts that priority.

The client is violating the spec, which actually strengthens the case against honoring the new client-id

Section 4.2 states:

"If the client supplies a 'client identifier', the client MUST use the same 'client identifier' in all subsequent messages, and the server MUST use that identifier to identify the client."

My nasty Govee device is changing its client-id between requests, which is an explicit RFC 2131 violation.
A client that breaks this rule has forfeited the right to be identified by client-id.
The server is not obligated to accommodate this violation - and should not do so by allowing the client to bypass a static reservation.

The default binding key is hardware address, not client-id

Section 2.1 states:

"The protocol defines that the key will be (IP-subnet-number, hardware-address) unless the client explicitly supplies an identifier using the 'client identifier' option."

Client-id overrides chaddr only when consistently supplied.
When a client rotates its client-id across requests, it has not consistently supplied one, and the server should fall back to chaddr - which matches the reservation.

The specific failure

Kea's conflict check fires when the reserved address has an existing lease with a different client-id.
But it does not check whether the hw-address on that conflicting lease is the same as the hw-address on the reservation.
In this case it is: same physical device, same chaddr, same reservation key - only the client-id token changed between requests in violation of section 4.2. There is no real conflict.
The ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT path in Kea was designed for the case where the reserved address is genuinely held by a different device.

So if the hw-address on the existing lease matches the hw-address on the reservation, do not treat it as a conflict.
The spec provides clear grounds for this: the binding key defaults to hw-address, and a client that rotates its client-id has violated the consistency requirement that would entitle it to be tracked by client-id instead.

Whether this needs to be fixed in Kea upstream or downstream in pfSense configuration I do not know, but `match-client-id: false` (current default in pfSense is `true`) discussed in https://forum.netgate.com/topic/184569/kea-dhcp-server-behavior-ip-address-reassignment-issue-with-duplicate-mac-addresses seems to help in similar situations.

A misbehaving client is not a bug, there is nothing to revisit here.

There is a checkbox on the DHCP server options for each interface to toggle the match-client-id option, "Ignore Client Identifiers". If you have a misbehaving client violating the spec, check the box.

I'm disappointed that it is the only conclusion from my comment.
DHCP client is also misbehaving here, yet you seem to ignore it.

If DHCP server option exists that makes it follow the spec more closely, then maybe the default should change.
And those who want to ignore the spec and treat "two clients" with the same MAC address as distinct should flip the option to the opposite value.

Nazar Mokrynskyi wrote in #note-6:

I'm disappointed that it is the only conclusion from my comment.
DHCP client is also misbehaving here, yet you seem to ignore it.

The client is misbehaving, the server is behaving exactly as expected.

If DHCP server option exists that makes it follow the spec more closely, then maybe the default should change.
And those who want to ignore the spec and treat "two clients" with the same MAC address as distinct should flip the option to the opposite value.

You have it backward. The default behavior is following the spec more closely. Ignoring the client ID breaks the spec, hence it is not the default behavior.

Kea discusses this directly in their documentation:

https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#using-client-identifier-and-hardware-address

See also: #16512

If you feel that behavior is improper, then discuss it with Kea as we have no way to change how Kea behaves in this case other than by using the configuration, and we already supply the means to change the configuration. Hence, not a bug.