The Dynamic Host Configuration Protocol (DHCP) is a network protocol which functions at the application layer of the Internet Protocol (IP) suite. A server which uses DHCP will be able to dynamically assign IP Addresses and other network configuration parameters to devices on the network; thus, allowing communication to a second network. The protocol can be implemented of networks of any sizes, ranging from small home area networks (HANs) to large campus area networks (CANs) and even the networks used by Internet Service Providers (ISPs).
DHCP runs in a client/server mode, where server sets up a pool of available IP addresses for a network. A DHCP server also provides network gateway, subnet masks, name servers and amount of time ("lease") that a given IP address will be valid. A DHCP client retrieves those parameters and uses them to join the existing network. In homes and small offices, a router also acts as a DHCP server. In a larger network, a dedicated server may act as a DHCP server along with performing other server activities.
The process of obtaining an IP address from the DHCP server is as follows.
A computer, tablet or smartphone that needs to join existing (home or office) network must be configured properly to communicate with other devices in the network. Manually configuring static IPv4 or IPv6 addresses along with network specific information results in human errors as there are significant number of digits to be entered. Also, manual configuration may end up assigning a same IP address to multiple devices causing an IP conflict. The DHCP automates that cumbersome manual process and assigns the IP address dynamically. You may also interest in reading static and dynamic IP addresses.
DHCP allows network administrators centrally manage and automate the assignment of the IP addresses without having to worry about assigning a duplicate IP address to multiple computers, and re-entering network gateway, subnet mask, and other network related information to each computer and hence making network administration a lot easier to manage.
If you want to know if you're using a dynamic or static IP address, you may use ipconfig command on Windows. On a MAC or Linux machines, you may use ifconfig command.
On Windows machine, the ipconfig command output will resemble like this.
C:\>ipconfig /all Windows IP Configuration Host Name . . . . . . . . . . . . : iplocation Primary Dns Suffix . . . . . . . : Node Type . . . . . . . . . . . . : Hybrid IP Routing Enabled. . . . . . . . : No WINS Proxy Enabled. . . . . . . . : No Ethernet adapter Wireless Network Connection: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Intel(R) PRO/Wireless LAN 2100 3B Mi ni PCI Adapter Physical Address. . . . . . . . . : 00-0C-F1-65-5B-70 Dhcp Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes IP Address. . . . . . . . . . . . : 192.168.1.100 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.1.1 DHCP Server . . . . . . . . . . . : 192.168.1.1 DNS Servers . . . . . . . . . . . : 192.168.1.1 Lease Obtained. . . . . . . . . . : Thursday, February 08, 2007 2:27:17 PM Lease Expires . . . . . . . . . . : Thursday, February 15, 2007 2:27:17 PM
On Mac and Linux machines, the ifconfig command output will look like this.
bash %>ifconfig eth0 Link encap:Ethernet HWaddr F2:3C:91:DB:8A:88 inet addr:192.168.1.96 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:27522604 errors:0 dropped:0 overruns:0 frame:0 TX packets:27666143 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2704290926 (2.5 GiB) TX bytes:52580665594 (48.9 GiB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:17632 errors:0 dropped:0 overruns:0 frame:0 TX packets:17632 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:2249069 (2.1 MiB) TX bytes:2249069 (2.1 MiB)
A DHCP server performs its functionality by enabling devices on its network to request IP Addresses and other network configurations from the ISP. This process allows the network to function without the need of a network administrator to manually assign IP Addresses to each device on the network. The protocol was designed with the client-server model in mind and thus, whenever a device connects to the network, the DHCP client software will broadcast a query to all devices on the network to request information. The query is recognized by any DHCP server on the network which will manage a pool IP Addresses and other important default configuration settings such as the default gateway, the domain name, time servers, and the name servers. The server which recognizes the request may respond with the relevant information for information for each client; information which would have been pre-configured by a network administrator. In the chance that this information has not been pre-configured by a network administrator, it will instead respond with a specific address and any other information which is suitable for the entire network and for the duration of the valid time period. These queries are usually sent immediately after a client boot and periodically then after before the information reaches expiration. It should also be noted that whenever the client is requesting new information for an assignment, it usually requests the same values but this can be changed by the network administrator depending on the assignment policies configured on the server.
The allocation of IP Addresses can be done in one of three ways depending on the DHCP server’s implementation. Dynamic allocation is accomplished by the network administrator denoting a range of IP Addresses to be used by the server to issue to clients for an allocated period of time. This request-and-grant process functions like a lease where the server can reclaim addresses which have not been renewed by the client for reallocation to other clients.
Automatic allocation is similar to dynamic allocation as the network administrator sets the range of IP Addresses for the server to use; however, these addresses are permanently tied to clients who connect on the server. This means that the server will also keep a record of which addresses are tied to which clients so that when a client reconnects to that server, they can receive the same IP Address as the last time when they were connected.
Finally, manual (or static) allocation is accomplished by the network administrator setting up a mapping schema for the server to use. Once configured, the server issues each client a private IP Address based on their Media Access Control (MAC) Address. In the event that a match for the client’s MAC Address cannot be mapped, the server may use one of the other allocation methods instead.
The protocol is used for both IPv4 and IPv6 and accomplish the same tasks on both versions but the details for each of them differ enough that they could be considered two separate protocols. Regardless of this, the protocol makes use of the User Datagram Protocol (UDP) to use a connectionless model. It uses two UDP port numbers for its operations port number 67 is used for a server while 68 is for the client. These operations can then be broken down into four phases: server discovery, IP lease offer, IP lease request, and IP lease acknowledgment. A common acronym used to describe these phases is DORA which stands for discovery, offer, request, and acknowledgment.
In the discovery phase, the client broadcasts a DHCPDISCOVER message to all devices on the network by using the address 255.255.255.255 or the specific subnet broadcast address. It should also be noted that a client could also request its last-known IP Address but the results can vary. If the client is on the same network as when it first connected, its request will be acknowledged without issue; however, if this is not the case it will depend on if the server is authoritative or not. An authoritative DHCP server will deny the request and force the client to ask for a new address while a non-authoritative DHCP server will ignore the request which may cause it to time-out for the client, depending on if it was implemented, and have them request a new IP Address.
During the offer phase, a DHCP server receives a DHCPDISCOVER message from a client on the network and responds by reserving an IP Address for the client and replies with a DHCPOFFER message to the client. This response-offer will contain the IP Address, subnet mask, the duration time of the lease, MAC Address of the client, and IP Address of the server.
In response to the offer made by a DHCP server, the client replies with a DHCPREQUEST message to enter the request phase. This message denotes the client accepting a server’s offer but it should be noted that while a client may receive numerous offers from numerous servers, it can only issue one request to accept one of the offers. Depending on the server identification option in the request and broadcast messaging, it is possible for all DHCP servers to be informed which offer a client has accepted. This allows the servers who may have pending offers to withdraw them and return the reserved IP Address back into their pool of available addresses.
Finally, once the server receives the DHCPREQUEST message as an acceptance of its offer from a client, the process enters the acknowledgment phase by having the server send a DHCPACK message back to the client. This message will include the lease duration and any other configuration parameters the client might have requested and brings the process to a close.
It should also be noted that it is possible to set up a DHCP Relay or DHCP Helper if the client and server are on different subnets within a network. In these scenarios, the DHCPDISCOVER message would be sent to the subnet which the server is on. This is accomplished by having two relay agents setup on both subnets so that they can relay the messages to the intended recipients.
DHCP typically do not have any systems in place for authorization and can fall victim to three types of attacks. Unauthorized servers can provide false information to clients as there is no way for a client to identify a valid DHCP server on the network. These rogue DHCP servers can take advantage of this and be used in a denial-of-service (DOS) attack to prevent proper functionality of the server or in a man-in-the-middle attack to gain information. Conversely, there can also be unauthorized clients gaining access to resources as there is no way for the server to authenticate a DHCP client either. This would allow clients to gain an IP Address from the server despite not being a valid client by masking itself as one. Enough unauthorized clients doing this could actually exhaust a server’s address pool and also affect the proper function of the network. The third classification of attack is repetitive and exhaustive attacks from malicious clients.
To combat these attacks, the Relay Agent Information Option Protocol (also called Option 82) was realized to allow networks to attach authorization tags to DHCP messages. This tag would then be used to control a client’s access to the server’s resources and because a client had no connection to the upstream network of the relay agent, the lack of validation would not prevent the server relying on the tag. Authentication for DHCP Messages was another innovation made in the way of validating messages although it was not widespread because of issues when managing keys for a large number clients.
Overall, these techniques are referred to as DHCP Snooping and considering the importance and use of the protocol is not going anywhere anytime soon, they are great skills for any network administrator to pick up.
© 2006 - 2018, Brand Media, Inc. All rights reserved.