Dynamic Client/Server Interaction For Dhcpv4 - Juniper EX3400 Features Manual

DHCP and Other System Services Feature Guide for EX2300, EX3400, and EX4300 Switches

Dynamic Client/Server Interaction for DHCPv4

Dynamic Client/Server Interaction for DHCPv6
112
over the access network, resulting in an outage. The DHCP local server needs to wait
for the client to send a message to renew its lease or rebind to the server. In response,
the server sends a NAK message to the client to force it to begin the DHCP connection
process again. Alternatively, the provider can wait for customers to make a service call
about the network failures and then instruct them to power cycle their customer
premises equipment to reinitiate the connection. Neither of these actions is timely or
convenient for customers.
On switches—Suppose you restructure the addressing scheme or change the server
IP addresses that the DHCP server provides to clients. Without dynamic reconfiguration,
the network typically clears the DHCP server binding table, but cannot inform the DHCP
clients that their bindings have been cleared. Consequently, the DHCP client operates
as though its IP address is still valid, but it is now unable to communicate over the
access network, resulting in an outage. The DHCP local server needs to wait for the
client to send a message to renew its lease or rebind to the server. In response, the
server sends a NAK message to the client to force it to begin the DHCP connection
process again. Alternatively, you can wait for users to notify you of the network failures
and then instruct them to power cycle their equipment to reinitiate the connection.
Neither of these actions is timely or convenient for users.
Dynamic reconfiguration for DHCPv4 is available through a partial implementation of
RFC 3203, DHCP Reconfigure Extension for DHCPv4. It enables the DHCPv4 local server
to send a message to the client to force reconfiguration.
The server sends a forcerenew message to a DHCPv4 client, initiating a message
exchange. In response, DHCPv4 clients that support the forcerenew message then send
a lease renewal message to the server. The server rejects the lease renewal request and
sends a NAK to the client, causing the client to reinitiate the DHCP connection. A
successful reconnection results in the reconfiguration of the DHCP client. Only the
exchange of forcerenew, renew, and NAK messages is supported from RFC 3202. DHCP
relay and DHCP relay proxy do not participate in the client reconfiguration or react to
forcerenew messages other than to forward them to the client.
When the local server state machine starts the reconfiguration process on a bound client,
the client transitions to the reconfiguring state and the local server sends a forcerenew
message to the client. Because the client was in the bound state before entering the
reconfiguring state, all subscriber services or DHCP-managed services, such as forwarding
and statistics, continue to work. Client statistics are not maintained in the interval between
a successful reconfiguration and the subsequent client binding. When the server responds
to the client renewal request with a NAK, the client entry is removed from the binding
table and final statistics are reported. New statistics are collected when the client sends
a discover message to establish a new session.
Dynamic reconfiguration for DHCPv6 is available through a partial implementation of
RFC 3315, Dynamic Host Configuration Protocol for IPv6 (DHCPv6). It enables the DHCPv6
local server to send a message to the client to force reconfiguration.
Copyright © 2017, Juniper Networks, Inc.