DHCP General Operation and Client Finite State Machine

DHCP General Operation and Client Finite State Machine

Dynamic address allocation is probably the most important new capability introduced by DHCP. In the last section I discussed in detail the significance of the change from IP address ownership to IP address leasing. I also provided a high-level look of the activities involved in leasing, by providing an overview of the DHCP lease “life cycle”.

An overview of this sort is useful to get a general handle on how leases work, but to really understand the mechanics of DHCP address assignment and client/server communication, we need more detail on how the devices behave and what messages they send. One tool often employed by networking engineers to describe a protocol is a theoretical model called a finite state machine (FSM). In this technique, the protocol's specific behavior is illustrated by showing the different states a device can be in, what possible transitions exist from one state to another, what events cause transitions to occur, and what actions are performed in response to an event. The TCP operational overview contains more general background information on finite state machines.

The DHCP standard uses an FSM to describe the lease life cycle from the perspective of a DHCP client. The client begins in an initial INIT state where it has no lease, and then transitions through various states as it acquires, renews, rebinds and/or releases its IP address. The FSM also indicates what message exchanges occurs between the server and client at various stages.

Some people think finite state machines are a little “dense” and hard to understand, and I can see why. You can skip this topic of course, but I think the FSM provides a useful way of illustrating in a comprehensive way most of the behavior of a DHCP client. Table 188 describes each of the DHCP client states, and summarizes the messages sent and received by the client in each, as well as showing the state transitions that occur in response. The FSM’s states, events and transitions are easier to envision in Figure 262, which also incorporates a color coding scheme so you can see which states are associated with each of the main DHCP processes.

Table 188: DHCP Client Finite State Machine

State	State Description	Event and Transition
INIT	This is the initialization state, where a client begins the process of acquiring a lease. It also returns here when a lease ends, or when a lease negotiation fails.	Client Sends DHCPDISCOVER: The client creates a DHCPDISCOVER message and broadcasts it to try to find a DHCP server. It transitions to the SELECTING state.
SELECTING	The client is waiting to receive DHCPOFFER messages from one or more DHCP servers, so it can choose one.	Client Receives Offers, Selects Preferred Offer, Sends DHCPREQUEST: The client chooses one of the offers it has been sent, and broadcasts a DHCPREQUEST message to tell DHCP servers what its choice was. It transitions to the REQUESTING state.
REQUESTING	The client is waiting to hear back from the server to which it sent its request.	Client Receives DHCPACK, Successfully Checks That IP Address Is Free: The client receives a DHCPACK message from its chosen server, confirming that it can have the lease that was offered. It checks to ensure that address is not already used, and assuming it is not, records the parameters the server sent it, sets the lease timers T1 and T2, and transitions to the BOUND state.
		Client Receives DHCPACK, But IP Address Is In Use: The client receives a DHCPACK message from its chosen server, confirming that it can have the lease that was offered. However, it checks and finds the address already in use. It sends a DHCPDECLINE message back to the server, and returns to the INIT state.
		Client Receives DHCPNAK: The client receives a DHCPNAK message from its chosen server, which means the server has withdrawn its offer. The client returns to the INIT state.
INIT-REBOOT	When a client that already has a valid lease starts up after a power-down or reboot, it starts here instead of the INIT state.	Client Sends DHCPREQUEST: The client sends a DHCPREQUEST message to attempt to verify its lease and re-obtain its configuration parameters. It then transitions to the REBOOTING state to wait for a response.
REBOOTING	A client that has rebooted with an assigned address is waiting for a confirming reply from a server.	Client Receives DHCPACK, Successfully Checks That IP Address Is Free: The client receives a DHCPACK message from the server that has its lease information, confirming that the lease is still valid. To be safe, the client checks anyway to ensure that the address is not already in use by some other device. Assuming it is not, the client records the parameters the server sent it and transitions to the BOUND state.
		Client Receives DHCPACK, But IP Address Is In Use: The client receives a DHCPACK message from the server that had its lease, confirming that the lease is still valid. However, the client checks and finds that while the client was offline, some other device has grabbed its leased IP address. The client sends a DHCPDECLINE message back to the server, and returns to the INIT state to obtain a new lease.
		Client Receives DHCPNAK: The client receives a DHCPNAK message from a server. This tells it that its current lease is no longer valid; for example, the client may have moved to a new network where it can no longer use the address in its present lease. The client returns to the INIT state.
BOUND	Client has a valid lease and is in its normal operating state.	Renewal Timer (T1) Expires: The client transitions to the RENEWING state.
		Client Terminates Lease, Sends DHCPRELEASE: The client decides to terminate the lease (due to user command, for example.) It sends a DHCPRELEASE message and returns to the INIT state.
RENEWING	Client is trying to renew its lease. It regularly sends DHCPREQUEST messages with the server that gave it its current lease specified, and waits for a reply.	Client Receives DHCPACK: The client receives a DHCPACK reply to its DHCPREQUEST. Its lease is renewed, it restarts the T1 and T2 timers, and returns to the BOUND state.
		Client Receives DHCPNAK: The server has refused to renew the client's lease. The client goes to the INIT state to get a new lease.
		Rebinding Timer (T2) Expires: While attempting to renew its lease, the T2 timer expires, indicating that the renewal period has ended. The client transitions to the REBINDING state.
REBINDING	The client has failed to renew its lease with the server that originally granted it, and now seeks a lease extension with any server that can hear it. It periodically sends DHCPREQUEST messages with no server specified until it gets a reply or the lease ends.	Client Receives DHCPACK: Some server on the network has renewed the client's lease. The client binds to the new server granting the lease, restarts the T1 and T2 timers, and returns to the BOUND state.
		Client Receives DHCPNAK: A server on the network is specifically telling the client it needs to restart the leasing process. This may be the case if a new server is willing to grant the client a lease, but only with terms different than the client’s current lease. The client goes to the INIT state.
		Lease Expires: The client receives no reply prior to the expiration of the lease. It goes back to the INIT state.

Figure 262: DHCP Client Finite State Machine

This diagram shows the finite state machine used by DHCP clients. The colored background areas show the transitions taken by a DHCP client as it moves through the four primary DHCP processes: allocation, reallocation, renewal and rebinding.

This is just a summary of the finite state machine, and does not show every possible event and transition, since it is complex enough already. For example, if a client that received two offers in the SELECTING state receives a DHCPNAK from its chosen server in the REQUESTING state, it may choose to send a new DHCPREQUEST to its “second choice” instead of starting over from scratch. Also, the client must have logic that lets it “time out” if it receives no reply to sent messages in various states, such as not receiving any offers in the SELECTING state. The next few topics discuss these matters in more detail.

Note also that the DHCP standard does not describe the DHCP server's behavior in the form of a finite state machine, only the client's. Here too, there is more information on what exactly DHCP servers do in the pages that follow.

I should also point out explicitly that this finite state machine applies to dynamically-allocated clients; that is, ones with conventional leases. A device configured using “automatic” allocation will go through the same basic allocation process, but does not need to renew its lease. The process for manual allocation is somewhat different.

Reference from http://www.tcpipguide.com/free/t_DHCPGeneralOperationandClientFiniteStateMachine.htm