On 19 June 2015 at 10:39, Mike Meredith <mike.meredith@port.ac.uk> wrote:
On Thu, 18 Jun 2015 15:51:31 -0400, "Joe Abley" <jabley@hopcount.ca> may have written:
Since DHCP uses broadcast and multicast addresses when a client is discovering a server, it's not obvious why you'd have to.
And broadcast/multicast when renewing a lease (DHCPREQUEST). You will of course see unicast addresses on the server side if the server is seeing requests forwarded by a udp helper.
RFC 2131 section 4.4.5: "At time T1 the client moves to RENEWING state and sends (*via unicast*) a DHCPREQUEST message to the server to extend its lease. The client sets the 'ciaddr' field in the DHCPREQUEST to its current network address. The client records the local time at which the DHCPREQUEST message is sent for computation of the lease expiration time. The client MUST NOT include a 'server identifier' in the DHCPREQUEST message." Also from section 4.3.2: "DHCPREQUEST generated during RENEWING state: 'server identifier' MUST NOT be filled in, 'requested IP address' option MUST NOT be filled in, 'ciaddr' MUST be filled in with client's IP address. In this situation, the client is completely configured, and is trying to extend its lease. This message will be *unicast*, so *no relay agents will be involved in its transmission*. Because 'giaddr' is therefore not filled in, the DHCP server will trust the value in 'ciaddr', and use it when replying to the client." If there is no reply to the unicast, the client should eventually do a fallback to broadcast, but a great number of DHCP clients fail to implement that. They will instead keep unicasting until the lease expire, then start over including deconfiguring the IP stack and then send DISCOVER. Regards, Baldur