RFC7844 DHCPv4 restricted version summary, questions and dhcpcanon specification¶

SHOULD randomize the ordering of options

MUST contain the Message Type option,

MUST contain the Message Type option,

If in response to a DHCPOFFER,
MUST contain the corresponding Server Identifier option
MUST contain the Requested IP address option.

If the message is not in response to a DHCPOFFER (BOUND, RENEW),:

MUST contain the Message Type option,
MUST contain the Server Identifier option,
MUST contain the Requested IP address option;

MUST contain the Message Type option,

MUST NOT include in the message a Client IP address that has been obtained
with a different link-layer address.

MUST use the option when mandated (DHCPREQUEST)

If in INIT-REBOOT:

If the hardware address is reset to a new randomized value,

DHCP
clients MUST use client identifiers based solely on the link-layer
address that will be used in the underlying connection.

Nodes visiting untrusted networks MUST NOT send or use the PXE options.

Vendor-Specific Information option (code 43), the Vendor Class
Identifier option (code 60), the V-I Vendor Class option (code 124),
or the V-I Vendor-Specific Information option (code 125),

the allocating
server SHOULD probe the reused address before allocating the address,
e.g., with an ICMP echo request, and the client SHOULD probe the
newly received address, e.g., with ARP.

 The client SHOULD perform a
check on the suggested address to ensure that the address is not
already in use.  For example, if the client is on a network that
supports ARP, the client may issue an ARP request for the suggested
request.  When broadcasting an ARP request for the suggested address,
the client must fill in its own hardware address as the sender's
hardware address, and 0 as the sender's IP address, to avoid
confusing ARP caches in other hosts on the same subnet.>>

The client SHOULD broadcast an ARP
reply to announce the client's new IP address and clear any outdated
ARP cache entries in hosts on the client's subnet.

The client SHOULD wait a random time between one and ten seconds to
   desynchronize the use of DHCP at startup.

a client retransmitting as described in section 4.1 might retransmit the
DHCPREQUEST message four times, for a total delay of 60 seconds

In both RENEWING and REBINDING states,
if the client receives no response to its DHCPREQUEST
message, the client SHOULD wait one-half of the remaining
time until T2 (in RENEWING state) and one-half of the
remaining lease time (in REBINDING state), down to a
minimum of 60 seconds, before retransmitting the
DHCPREQUEST message.

For example, in a 10Mb/sec Ethernet
internetwork, the delay before the first retransmission SHOULD be 4
seconds randomized by the value of a uniform random number chosen
from the range -1 to +1

Clients with clocks that provide resolution
granularity of less than one second may choose a non-integer
randomization value.

The delay before the next retransmission SHOULD
be 8 seconds randomized by the value of a uniform number chosen from
the range -1 to +1.

The retransmission delay SHOULD be doubled with
subsequent retransmissions up to a maximum of 64 seconds.

DHCP clients are free to use any strategy in selecting a DHCP server
among those from which the client receives a DHCPOFFER message.

client may choose to collect several DHCPOFFER
messages and select the "best" offer.

If the client receives no acceptable offers, the client
may choose to try another DHCPDISCOVER message.

The client collects DHCPOFFER messages over a period of time, selects
one DHCPOFFER message from the (possibly many) incoming DHCPOFFER
messages

The time
over which the client collects messages and the mechanism used to
select one DHCPOFFER are implementation dependent.

Times T1 and T2 are configurable by the server through options.  T1
defaults to (0.5 * duration_of_lease).  T2 defaults to (0.875 *
duration_of_lease).  Times T1 and T2 SHOULD be chosen with some
random "fuzz" around a fixed value, to avoid synchronization of
client reacquisition.

renewing_time = lease_time * 0.5 - time_elapsed_after_request
range_fuzz = lease_time * 0.875 - renewing_time
renewing_time += random.uniform(-(range_fuzz), +(range_fuzz))

rebinding_time = lease_time * 0.875 - time_elapsed_after_request
range_fuzz = lease_time - rebinding_time
rebinding_time += random.uniform(-(range_fuzz), +(range_fuzz))

There are scenarios in which a client connecting to a network
remembers a previously allocated address, i.e., when it is in the
INIT-REBOOT state.  In that state, any client that is concerned with
privacy SHOULD perform a complete four-way handshake, starting with a
DHCPDISCOVER, to obtain a new address lease.  If the client can
ascertain that this is exactly the same network to which it was
previously connected, and if the link-layer address did not change,
the client MAY issue a DHCPREQUEST to try to reclaim the current
address.