DHCP reconfigure extension

The FORCERENEW approach was chosen because it does not require adding new states to the DHCP client implementation, minimizing code changes while still allowing server-driven lease renewal to optimize network usage or DHCP server load.

FORCERENEW usage for reconfiguring a client's address or local configuration parameters can interrupt active sessions; these procedures should therefore only be used in controlled circumstances.

When a client uses DHCP INFORM (address obtained via other means), FORCERENEW triggers a new INFORM request only; it must not override manually configured parameters, and its scope is limited to DHCP-eligible options.

FORCERENEW messages MUST be authenticated using the procedures described in RFC 3118 (DHCP-AUTH). FORCERENEW messages failing authentication should be silently discarded by the client.

security

If a client obtained its address via manual configuration and used DHCP INFORM for other parameters, it should respond to a unicast FORCERENEW message with a new DHCP INFORM request to obtain a potential new set of local configuration parameters.

If the FORCERENEW message is lost and the server does not receive a DHCP REQUEST, the server should retransmit the FORCERENEW message using an exponential backoff algorithm with a limited number of retransmissions.

Receipt of a multicast FORCERENEW message by the client should be silently discarded.

Upon receipt of a unicast FORCERENEW message, the client MUST change its state to the RENEW state and attempt to renew its lease according to normal DHCP procedures.

DHCPFORCERENEW is a new DHCP message type sent by the server to a client to trigger dynamic reconfiguration. It uses the standard DHCP message layout and is transmitted as a unicast message to the specific client.

IANA assigned the value 9 in the DHCP Message Type option (option 53) registry to represent DHCPFORCERENEW.

registry

In some network environments, FORCERENEW can be used to snoop and spoof traffic; therefore the message MUST be authenticated using RFC 3118 procedures, and unauthenticated messages must be silently discarded.

security

The mechanism is vulnerable to a denial-of-service attack through flooding a client with bogus FORCERENEW messages, as the cryptographic work to authenticate each bogus message may overwhelm the client device.

security

Upon receipt of DHCPFORCERENEW in the Bound state, the client transitions to the Renew state (labeled DHCPFORCE in the state diagram). If the server wishes to assign a new IP address, it replies to the subsequent DHCPREQUEST with DHCPNAK, driving the client back to Init, which then broadcasts DHCPDISCOVER.

DHCP option 53 (DHCP message type) is extended with the new value 9 to indicate a DHCPFORCERENEW message. No other changes to the DHCP message layout are required.