Posted by arlene

Although based on the simple BOOTP protocol, the DHCP protocol client/server exchange is a little more complicated. Both sides communicate using a set of messages, as listed here:

• DHCPDISCOVER—The client broadcasts this message to locate DHCP servers.
• DHCPOFFER—The server uses this message type to offer a set of configuration parameters to the client.
• DHCPREQUEST—A client can use this message type to explicitly accept an offer from one server while implicitly implying that it is not going to use the offers made by other servers. This message type can also be used to confirm the configuration data when the client reboots or when it is attempting to extend a lease.
• DHCPACK—The client sends this acknowledgment to the server, including the configuration parameters that were accepted.
• DHCPNAK—The server sends this negative acknowledgment to the client to inform the client that the address it has requested is not correct. For example, when a client is moved to a new subnet and attempts to renew an old IP address, the server can use this message to inform it that it needs a different one.
• DHCPDECLINE—The client can send this message to a server to indicate that a particular IP address is already in use.
• DHCPRELEASE—The client can give up an IP address and use this message to tell the server that the address can be recycled.
• DHCPINFORM—The client can use this message to request local configuration information from the server when the client has already been configured with an IP address by some other means.

Requesting Configuration Information from the DHCP Server

The communication process between the DHCP client and server is simple. The client initially broadcasts a DHCPDISCOVER message on the local subnet to which it is attached. If known, the client can insert configuration options in this discover packet, such as the IP address and a requested lease time.

All DHCP servers that receive the DHCPDISCOVER request can respond with a DHCPOFFER message, including a suggested IP address and any other options it can offer. Because more than one server can respond to a DHCP request (remember that DHCP packets can be relayed across routers using BOOTP relay agents), it then must decide which offer to accept.

The DHCPOFFER packet is sent as a unicast packet instead of a broadcast packet. The DHCP server can unicast or broadcast messages, which is determined in this way:

• If the Gateway IP Address (giaddr) field in the client’s packet is a nonzero value, the server assumes that this is the address of an intermediary router and unicasts the packet to this address, using the DHCP server port (67).
• If the Gateway IP Address field is zero but the Client’s IP Address (ciaddr) field is not, the server unicasts the packet to this address that the client has filled in.
• If both of these fields are zero and the broadcast flag bit is set in the client’s packet, the server broadcasts the packet to the client.
• If both of these fields are zero and the broadcast flag bit is not set, the server unicasts the packet to the client’s hardware address and the Client’s IP Address (yiaddr) field.

When a selection has been made, the client broadcasts another packet that contains a DHCPREQUEST message. This packet must include the server identification option, indicating from which server the client has chosen to accept the offer.

When the servers see this broadcast packet, those not chosen by the client use it as a flag that their offer was not accepted, and no further communications need to take place between the client and these servers. The chosen server binds the client to the addressing configuration information, and then sends the client a DHCPACK acknowledgment message. This packet also contains the set of agreed-upon options and parameters. If the server cannot grant the request—the IP address requested by the client is already in use, for example—the server responds with a DHCPNAK negative acknowledgment message.

After the client receives an acknowledgment packet indicating that it can use the configuration information, it must still perform some checks to be sure that the information is correct and will allow the client to function on the network. A few simple checks are performed. For example, the client can use ARP to check that the IP address it is about to use is not already in use on the network. This can happen when a DHCP server has been configured incorrectly. If there are no challenges, the client has the information it needs and the configuration of its protocol stack is performed. The client now can participate in the network.

If this last-minute test informs the client that the address is already in use, the client sends the DHCP server a DHCPDECLINE message. In this case, or if the client has received a DHCPNAK message from the server, the process backs off for a few seconds and begins again.

If the client does not receive either the DHCPACK or the DHCPNAK message within a set amount of time, it also restarts the configuration process.

Possibly related posts: (automatically generated)
The DHCP Client/Server Exchange

• Taking BOOTP One Step Further: DHCP
• Dedicated Server with Canadian Web Hosting
• Providing Support for BOOTP Clients
• Reservations and Exclusions
• How DHCP Interacts with Microsoft's Dynamic Domain Name Service (DNS)
• What Is a DHCP Cluster?
• The Dynamic Host Configuration Protocol and BOOTP
• Configuring a Router or WAP to Provide DHCP
• What Is APIPA?
• Symmetric and Asymmetric Encryption