|
DHCP Lease Reallocation Process
(Page 2 of 2)
Lease Reallocation Process Steps
The reallocation process is essentially
an abbreviated version of the allocation process described in the previous
topic. There is no need for the client to go through the whole yoohoo,
any servers out there want to give me a lease routine. Instead,
the client attempts to find the server that gave it the lease in the
first place, seeking a confirmation that the lease is still valid and
that it may resume using its previously-allocated IP address. It also
receives confirmation of the parameters it should use.
Figure 264: DHCP Lease Reallocation Process The lease reallocation process consists of seven steps that correspond approximately to steps 8 through 14 of the full lease allocation process shown in Figure 263. In this example, the server that originally granted the lease to the client is Server #2, so it is normally the only one that responds.
|
The following steps summarize
the reallocation process, which is also shown in Figure 264.
(Note that the same notes about addressing fields, relay agents and
such that I mentioned in the
discussion of lease allocation apply here
as well):
1. Client Creates DHCPREQUEST Message
The client begins in the INIT-REBOOT
state instead of the INIT state. It creates a DHCPREQUEST
message to attempt to find a server with information about its current
lease. Note that this may or may not be the server that originally granted
the lease; the server responsible for a lease could, theoretically,
have changed in the time since the client obtained the lease. Thus,
unlike the DHCPREQUEST message in step #8 in the allocation process,
the client does not include a DHCP Server Identifier
option. It does includes the following information:
- Its own hardware address in the CHAddr
field of the message, to identify itself.
- The IP address of its existing lease, in the
Requested IP Address DHCP option. Note that this address is not
put into the CIAddr field.
- A random transaction identifier, put into the
XID field. This is used to identify later messages as being part
of the same transaction.
- Any additional configuration parameters it wants,
in a Parameter Request List option in the message.
2. Client Sends DHCPREQUEST Message
The client broadcasts the DHCPREQUEST
message. It then transitions to the REBOOTING state, where it
waits for a reply from a server.
3. Servers Receive and Process DHCPREQUEST Message and Generate Replies
Each server on the network receives
and processes the client's request. The server looks up the client in
its database, attempting to find information about the lease. Each server
then decides how to reply to the client:
- Server Has Valid Client Lease Information:
The server has information about the client's lease. It sends a DHCPACK
message to confirm the lease. It will also reiterate any parameters
the client should be using.
- Server Determines Client Lease Is Invalid:
The server determines that the client's lease is no longer valid. Common
reasons for this happening are the client trying to confirm a lease
after it has moved to a different network, or after the least has in
fact already expired. In such a case the server sends a DHCPNAK
message to negate the lease request.
- Server Has No Definitive Information About
Client Lease: A server that has no information about the lease does
not respond. A server is also required not to respond unless its information
is guaranteed to be accurate. So, for example, if a server has knowledge
of an old expired lease, it cannot assume that the lease is no longer
valid and send a DHCPNAK, unless it also has certain knowledge
that no other server has a newer, valid lease for that client.
4. Servers Send Replies
Servers that are going to respond
to the clients DHCPREQUEST send their DHCPACK or
DHCPNAK messages.
5. Client Receives and Processes DHCPACK or DHCPNAK Message
The client waits for a period of
time to get a reply to its request. Again, there are three possibilities
that match the three in the previous step:
- Positive Acknowledgment: The client receives
a DHCPACK message; this confirms the validity of the lease. The
client will prepare to begin using the lease again, and continue with
the next step below.
- Negative Acknowledgment: The message is
a DHCPNAK, which tells the client that its lease is no longer
valid. The client transitions back to the INIT state to get a
new leasestep #1 in the allocation process.
- No Reply: If the client receives no reply
at all, it may retransmit the DHCPREQUEST message. If no reply
is received after a period of time, it will conclude that no server
has information about its lease and will return to the INIT state
to try to get a new lease.
6. Client Checks That Address Is Not In Use
Before resuming use of its lease,
the client device should perform a final check to ensure that the new
address isn't already in use. Even though this should not be the case
when a lease already exists, it's done anyway, as a safety measure
of sorts. The check is the same as described in step #13 of the allocation
process: an ARP request is issued on the local network, to see if any
other device thinks it already has the IP address this client was just
leased. If another device responds, the client sends a DHCPDECLINE
message back to the server, which tells it that the lease is no good
because some other device is using the address. The client then goes
back to the INIT state to get a new lease.
7. Client Finalizes Lease Allocation
Assuming that the address is not
already in use, the client finalizes the lease and transitions to the
BOUND state. It is now ready for normal operation.
Key Concept: If a client starts up and already has a lease, it need not go through the full lease allocation process; instead, it can use the shorter reallocation process. The client broadcasts a request to find the server that has the current information on its lease; that server responds back to confirm that the clients lease is still valid. |
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.
|