From Support ticket #15515

Reported on 1.5.0 but applies to all current versions of Kea DHCP

Some very fussy clients are ignoring ACKs to DHCPINFORMs sent by Kea DHCP. The only significant difference we can see between 'acceptable' and 'unacceptable' is whether or not CIADDR is returned to the client in the ACK. Kea DHCP is setting ciaddr to zero, even if the client supplied it in the DHCPINFORM, and despite using it to unicast the response to the client.

RFC2131 is a little ambiguous on the matter and says in section 4.3.1 "'ciaddr' from DHCPREQUEST or 0".

Kea DHCP has clearly taken this to mean 'the server can choose whether to send ciaddr or "0"', whereas I personally would have read this to mean 'if the client sent ciaddr, then echo it back to them, otherwise send "0"'.

There was a clarification document submitted, but it has expired and did not become an RFC: https://tools.ietf.org/html/draft-ietf-dhc-dhcpinform-clarify-06

In there, the author writes:

In the DHCPACK reply:

o The 'htype', 'hlen', 'chaddr', 'ciaddr', 'xid', 'flags' (with the exception noted below), and 'giaddr' fields MUST be copied from the client's DHCPINFORM

I'm with the clarification document on this - I think we should be sending ciaddr back to the client if it sent ciaddr to us in the DHCPINFORM.

(I suspect, looking at the author of it, that ISC DHCP does what the clarification document suggests, so this could become a migration issue too?)