Please Whitelist This Site? I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :) If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads. If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK. Thanks for your understanding! Sincerely, Charles Kozierok Author and Publisher, The TCP/IP Guide

NOTE: Using software to mass-download the site degrades the server and is prohibited. If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.

The TCP/IP Guide  9  TCP/IP Application Layer Protocols, Services and Applications (OSI Layers 5, 6 and 7)       9  TCP/IP Network Configuration and Management Protocols (BOOTP, DHCP, SNMP and RMON)            9  Host Configuration and TCP/IP Host Configuration Protocols (BOOTP and DHCP)                 9  TCP/IP Dynamic Host Configuration Protocol (DHCP)                      9  DHCP Configuration and Operation

DHCP General Operation and Client Finite State Machine 1 2 3 DHCP Lease Reallocation Process

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:

• Its own hardware address in the CHAddr field of the message, to identify itself.
  
  
• A random transaction identifier, put into the XID field. This is used to identify later messages as being part of the same transaction.
  
  
• Optionally, the client may request a particular IP address using a Requested IP Address DHCP option, a particular lease length using an IP Address Lease Time option, and/or specific configuration parameters by including a Parameter Request List option in the message.

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 IP address to be assigned to the client, in the YIAddr field. If the server previously had a lease for this client it will attempt to reuse the IP address it used last time. Failing that, it will try to use the client's requested address if present; otherwise, it will select any available address.
  
  
• The length of the lease being offered.
  
  
• Any client-specific configuration parameters either requested by the client or programmed into the server to be returned to the client.
  
  
• Any general configuration parameters to be returned to all clients or clients in this client's class.
  
  
• The server's identifier in the DHCP Server Identifier option.
  
  
• The same transaction ID (XID) used in the DHCPDISCOVER message.

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 terms—for 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 identifier of the “chosen” server in the DHCP Server Identifier option, so everyone knows “who won”.
  
  
• The IP address that the DHCP server assigned the client in the DHCPOFFER message, which the client puts in the Requested IP Address DHCP option as a confirmation.
  
  
• Any additional configuration parameters it wants in a Parameter Request List option in the message.

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.

DHCP General Operation and Client Finite State Machine 1 2 3 DHCP Lease Reallocation Process