| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
DHCP Lease Allocation Process (Page 2 of 3) Lease Allocation Process Steps Below I have described the steps that are followed by a DHCP client and server in the initial allocation of an IP address lease. This is a basic description, and I have not included all the details of what the client and server do, as that would make this description incredibly long. Instead, I have focused on the most important tasks each device performs, and also specified the message types exchanged and critical pieces of data included in each message, as well as client states and transitions. The process is also illustrated in Figure 263.
The client begins in the INIT (initialization) state. It has no IP address and doesn't even know whether or where a DHCP server may be on the network. To find one, it creates a DHCPDISCOVER message, including the following information:
The client broadcasts the DHCPDISCOVER message on the local network. The client transitions to the SELECTING state, where it waits for replies to its message. Each DHCP server on the local network receives the client's DHCPDISCOVER message and examines it. The server looks up the client's hardware address in its database and determines if it is able to offer the client a lease, and what the terms of the lease will be. If the client has made requests for a particular IP address, lease length, or other parameters, the server will attempt to satisfy these requests, but is not required to do so. A server may decide not to offer a lease to a particular client if it has not been programmed to provide service for it, it has no remaining IP addresses or for other reasons. Each server that chooses to respond to the client creates a DHCPOFFER message including the following information:
The DHCP standard specifies that before sending a DHCPOFFER to a client, the server SHOULD check to see that the IP address isn't already in use by sending an ICMP Echo message to that address. If the probe is made and the address is in use, the server will of course not offer it to the client. This may be disabled by an administrator. It is considered a key part of the DHCP server conflict detection feature. Whether or not it probes the address offered, the server may also reserve the address so that if the client decides to use it, it will be available. This isn't mandatory, because as we'll see below, the protocol handles the case where an offered lease is retracted. It is more efficient if servers do reserve addresses, but if IP addresses are in very short supply, such reservation may not be practical. Each server sends its DHCPOFFER message. They of course may not all be sent at exactly the same time. The messages are sent either unicast or broadcast, as mentioned earlier. The client waits for DHCPOFFER messages to arrive in response to its DHCPDISCOVER. The exact behavior of the client here is implementation-dependent. The client may decide to simply take the first offer it receives, for expediency. Alternately, it may choose to shop around by waiting for a period of time. It can then process each offer and take the one with the most favorable termsfor example, the one with the longest lease. If no DHCPOFFER messages are received, the client will enter a retransmission mode and try sending the DHCPDISCOVER again for a period of time. The client creates a DHCPREQUEST message for the server offer it has selected. This message serves two purposes: it tells the server whose offer the client has accepted yes, I accept your offer, assuming it is still available and also tells the other servers sorry, your offer was rejected. (Well, except for the sorry part; servers are pretty thick-skinned about rejection. J) In this message, the client includes the following information:
The client sends the DHCPREQUEST message. Since it is intended for not just the selected DHCP server but all servers, it is broadcast. After doing this, the client transitions to the REQUESTING state, where it waits for a reply from the chosen server. Each of the servers receives and processes the client's request message. The servers not chosen will take the message as a rejection. However, note that a client may select one offer, attempt to request the lease and have the transaction not complete successfully. The client may then come back and try its second choice offer by sending a DHCPREQUEST containing a different Server Identifier. This means that if Server A receives a single DHCPREQUEST with a Server Identifier of Server B, that doesn't necessarily mean that Server A is done with the transaction. For this reason, rejected servers will wait for a while before offering a previously-offered lease to another client. The chosen server will see that its lease has been selected. If it did not previously reserve the IP address that was offered to the client, it must check to make sure it is still available. If it is not, the server sends back a DHCPNAK (negative acknowledgment) message, which essentially means never mind, that lease is no longer available. Usually, however, the server will still have that lease. It will create a binding for that client, and send back a DHCPACK (acknowledgment) message that confirms the lease and contains all the pertinent configuration parameters for the client. The client receives either a positive or negative acknowledgment for its request. If the message is a DHCPNAK, the client transitions back to the INIT state and starts over: back to square one (step #1). If it is a DHCPACK, the client reads the IP address from the YIAddr field, and records the lease length and other parameters from the various message fields and DHCP options. If the client receives neither message, it may retransmit the DHCPREQUEST message one or more times. If it continues to hear nothing then it must conclude that the server flaked out and go back to step #1. The client device should perform a final check to ensure that the new address isn't already in use before it concludes the leasing process. This is typically done by generating an Address Resolution Protocol (ARP) request 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 basically means hey server, you screwed up, someone's already using that address. The client then, you guessed it, goes back to step #1 and starts over. Assuming that the address is not already in use, the client finalizes the lease and transitions to the BOUND state. It also sets its two lease timers, T1 and T2. It is now ready for normal operation.
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. |