|
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 FSMs 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 clients 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.
If you find The TCP/IP Guide useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider purchasing a download license of The TCP/IP Guide. Thanks for your support! |
|
|
Home -
Table Of Contents - Contact Us
The TCP/IP Guide (http://www.TCPIPGuide.com)
Version 3.0 - Version Date: September 20, 2005
© Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.
|