If that’s what ISC DHCP is doing, I’m all for it. There’s no RFC, which makes it a little difficult to know what’s the “right” thing to do.
I've read "https://tools.ietf.org/html/draft-ietf-dhc-dhcpinform-clarify-06" carefully and found this:
Next, the DHCPv4 server MUST determine the "reply address and port" according to the first of the following conditions it finds a valid reply address for, in order:
1. If the 'ciaddr' field is non-zero, the server selects its contents as an IPv4 address and port 68 ('DHCP client').
2. If the 'giaddr' field is non-zero, the server selects its contents as an IPv4 address and port 67 ('DHCP server').
3. If the IPv4 source address field is non-zero, the server selects its contents as an IPv4 address and port 68 ('DHCP client')
4. The server selects the limited broadcast address (all-ones) and port 68 ('DHCP client').
At this point, the DHCPv4 server verifies that it holds configuration authority over the reply address (or link in case of limited broadcast address) it has selected to transmit the reply to. If the server has not been configured to hold authority over this address, it MUST NOT reply. It SHOULD increment a counter visible to the operator but SHOULD NOT log an error (unless a mechanism is used to suppress repeated log messages). See the Security section (Section 5) for the rationale behind this direction.
Note very carefully that a DHCPv4 server will send replies directly to a DHCPv4 client by way of 'ciaddr' even if the DHCPINFORM message was relayed. Note that this means DHCPINFORM processing is intentionally broken in deployments where the client's address space is unreachable by the DHCPv4 server. In such cases, the server should probably be configured not to reply to DHCPINFORMs.
So, I think I'm right. I don't have a working isc-dhcpd now, but in one or two days I'll find it and test this thing. My clients flooding FR with DHCP-Informs and I want to shut their win7's up.