Very tangential, but I want to put what I learned down somewhere: There is a subset of the DHCP Protocol which is the DHCPINFORM packet. This is where the clie

Very tangential, but I want to put what I learned down somewhere: There is a subset of the DHCP Protocol which is the DHCPINFORM packet. This is where the client informs the server of the IP it already has, and gets network information (router, DNS...) back from the DHCP server. Search for "DHCPINFORM" in RFC2131 [1]. This protocol is used on Macs when you configure their interface with "Using DHCP with Manual Address". Now the fun thing is when you have a misconfigured firewall that's also serving as a DHCP relay, which is how I fell down this rabbit hole. The standard DHCP request package (DHCPREQUEST) by nature will be sent as a broadcast packet, as will the DHCPACK response because of course the client does not have an IP address yet. But a DHCPACK in response to a DHCPINFORM will be a unicast packet, because in this case the client does have an IP address. So if your firewall acts as a DHCP relay but otherwise blocks ports 67 & 68, then the usual DHCP stuff will work (broaecast, handled by the relay), but the "DHCP with Manual Address" (DHCPINFORM) will fail, because the unicast DHCPACK will get blocked. Anyways, I brought this up in relation to your comment because, for DHCPINFORM, the RFC says this: > The server SHOULD check the network address in a DHCPINFORM message for consistency, but MUST NOT check for an existing lease. [1] https://datatracker.ietf.org/doc/html/rfc2131 https://datatracker.ietf.org/doc/html/rfc2131