# Communication Networks/DHCP Protocol
## Dynamic Host Configuration Protocol

Dynamic Host Configuration Protocol (DHCP) allows for manual and automatic assignment of IP addresses (see IETF rfc 2131 & 2132). DHCP is enacted when a new machine joins a network or an existing machine attempts to renew its IP address. DHCP is an extension of an older protocol known as the "bootstrap protocol" (BOOTP) and is backwards compatible with BOOTP. There are three methods of IP address allocation:
By far the most common (and most detailed) method is the dynamic method, which we'll focus our attention on. A typical sequence for a new client requesting an IP address is shown in the diagrams.below. Please note that this depiction shows the DHCP server located on a different network segment than the new client. But it's not required to be that way.

#### Example

Figure 1
In figure 1, a new client that just joined the network, needs an IP address. Since it does not know the DHCP server's location, the client broadcasts (step 1) a DHCPDISCOVER message on the local network. The message packet contains a hardware identifier (usually the MAC address), the source port (68), the destination IP (255.255.255.255), destination port (67), and a randomly generated transaction id. Optionally the client can specify the IP address it wants and the lease duration in the message. Once the DHCP relay receives the broadcasted message, it fills in the "giaddr" field of the packet with the gateway IP address of 10.1.2.9 . This piece of information is critical because the DHCP Server needs it to determine which subnet the client is on and thus which IP address to allocate to the client. Afterwards the DHCPDISCOVER message is relayed to the DHCP Server via unicast (step 2). A unicast, instead of a broadcast, is sufficient because the DHCP relay knows the exact location of the DHCP server. For this same reason, the DHCP relay does not allow the other network segment, 10.1.1.X, to receive the message.
Once the DHCP server receives the DHCPDISCOVER request, it allocates an IP address, marks it as taken, and then broadcasts a DHCPOFFER message back to the requesting client. This message packet contains the DHCP server's IP address, the client's hardware identifier, the same transaction id, and the IP address allocated for the client. Optionally, the message may also contain the lease time, subnet mask, default TTL, default router(s), and numerous other parameters.
Figure 2
In figure 2, the DHCP server allocates new IP address 10.1.2.3 for the client and broadcasts a DHCPOFFER message to its network (step 3). When the DHCP relay sees the DHCPOFFER broadcast, it relays the broadcast to the 10.1.2.X network and only that network (step 4). Once the new client sees the DHCPOFFER message, it accepts the IP address (step 5) and prepares a confirmation message to the DHCP server with a DHCPREQUEST packet. Please note that the client does not have to accept this IP address, in which case it will not send a DHCPREQUEST message. If multiple DHCP servers sends out a DHCPOFFER, the client can choose which one to accept. If for some reason, the DHCPOFFER message fails to ever arrive, the client will rebroadcast the DHCPDISCOVER message.
Figure 3
If the client included optional information in the initial DHCPDISCOVER message, it must include that same information in the subsequent DHCPREQUEST message. In step 6 of figure 3, the new client confirms it wants the IP address 10.1.2.3 by broadcasting a DHCPREQUEST to the DHCP server. Once the DHCP Server receives this message (with help again from the DHCP Relay), it first ensures that it is the intended target - because the client could be responding to another DHCP Server. If this DHCP server is not the intended target, then it knows some other DHCP server is handling this client. So this DHCP server can discard any previously allocated IP address for that client. If this DHCP Server is the intended recipient, then it has to verify the optional parameters that it specified in the previous DHCPOFFER message to this client, are still valid. Assuming everything is fine up to this point, the DHCP Server sends a DHCPACK broadcast (step 8) to tell the client that its new IP address can now officially be used. However, if something is wrong, then a DHCPNACK is broadcasted instead. Either way, a DHCPACK or DHCPNACK will be the final message sent by the DHCP server in the dynamic IP address allocation sequence..
Assuming it receives the DHCPACK relayed by the router (step 9), the client is encouraged to verify no other hosts has the same IP address. This is usually accomplished through a simple ARP probe. Any response to the probe means that another client is already using the IP address. In such a situation, the client must send a DHCPDECLINE message to the DHCP server. Afterwards the client will then need to restart this whole process beginning with DHCPDISCOVER phase. In most cases, there's no response to the client's ARP probe. This means the client can go ahead and use the allocated IP address along with any other optional information stored in the message packet.
If the client got a DHCPNAK instead of DHCPACK, then it has no choice but to restart everything from the very beginning i.e. the DHCPDISCOVER stage. Finally, if the client doesn't receive any DHCPACK or DHCPNAK message after a certain period of time, then it rebroadcasts the DHCPREQUEST message.

#### Security Concerns

DHCP is inherently insecure because there's no authentication mechanism built in. Here are a few examples of security weaknesses.

## Summary

Dynamic Host Configuration Protocol (DHCP) is a convenient, though insecure, technique to assign an IP address to a host newly added to a network. It can also be used to extend the lease period of an existing IP address, drop the IP address of a host, or provide initial configuration parameters to a requesting host.

## Exercises

Question:
* Using the example illustrated in the DHCP section, explain how the interaction between the new client and the DHCP Server would change if the DHCP Server is located on the same network segment as the new client.
* (T/F) Once a new client receives the IP address after the DHCPOFFER, the client should verify no other hosts are using that IP address.
Answer:
* The only difference would be the DHCP Relay not getting involved. Thus the DHCP Server receives broadcasts instead of unicasts, and the "igaddr" field of the message packet wil be empty.
* False - the client must wait until DHCPACK (not DHCPOFFER) because the IP address is not officially assigned to the new client until DHCPACK is received.

## References

http://tools.ietf.org/html/rfc2131
http://www.windowsecurity.com/articles/DHCP-Security-Part1.html
http://www.eventhelix.com/RealtimeMantra/Networking/DHCP.pdf