The Dynamic Host Configuration Protocol

Introduction

The increasing popularity of the Internet has resulted in more and more computers needing to run TCP/IP. This has caused problems for network administrators because every computer that runs TCP/IP needs to be configured individually.

The very least that a TCP/IP station needs (in the way of configuration information) is its own IP address, a subnet mask, and the address of a default router. As well as this, however, it probably needs a host name, a domain name, the address of at least one DNS server, the address of an alternative router, some static routes, and finally lists of timer, news, and print servers. This is not to mention any configuration that the network administrator needs to perform on the proprietary TCP/IP stack he or she is using.

One option for the network administrator is to use a standard configuration to base new installations on. However, he or she still has to configure a separate IP address for each new TCP/IP station, and the problem of keeping track of IP addresses remains. Indeed, this problem gets worse every time a new user is assigned an IP address; as does the possible problem of there being too few IP addresses to go round. And even worse is the amount of reconfiguration required when groups of stations need to be moved from one subnet to another or, for example, when stations using unregistered IP addresses need to be assigned registered addresses.

RARP and BOOTP

Attempts have been made to simplify the network administrator's task by automating the configuration of TCP/IP stations. One such attempt was the RARP protocol (RARP stands for Reverse Address Resolution Protocol). This protocol enables each station on a subnet to receive its IP address from a central RARP server. However, the network administrator still has to configure individual records (including MAC-to-IP address mappings) on the RARP server for each TCP/IP station on the subnet. Moreover, the RARP server can only configure stations on a single subnet, therefore, the network administrator will probably need to set up RARP servers on several different subnets.

A more powerful protocol for configuring TCP/IP stations centrally is BOOTP. This protocol enables stations to receive IP addresses, domain names, and the addresses of DNS servers, from a central BOOTP server. It can also configure TCP/IP stations on other subnets. However, like a RARP server, a BOOTP server normally has to be configured manually.

Both these protocols simplify the network administrator's task, and the main problem with them is not so much that they perform only a limited role; it is that they cannot perform this limited role dynamically. What they cannot do, and what network administrators increasingly need them to do, is manage scarce IP addresses by assigning one IP address that a user has finished with to another user who needs it.

Dynamic Host Configuration Protocol (DHCP)

DHCP is a much more powerful protocol than BOOTP and RARP. It not only enables TCP/IP stations to receive automatically most if not all of the configuration information they need, it also assigns IP addresses dynamically. It works by leasing addresses to clients for a fixed time. A client can request the DHCP server to renew its lease, but once its lease is up, the client loses its IP address. Assuming that users only need to run TCP/IP part of the time, this concept of leasing enables the DHCP server to manage IP addresses so that all users can access the Internet even though there are more users than IP addresses.

DHCP servers can also be set up to configure groups of computers collectively. For example, a group of servers could be configured with a longer lease time than a group of workstations, because workstations - which get powered on and off more frequently than servers - will need their IP addresses for less time.

DHCP frames

If your network analyzer software does enable you to see DHCP frames, you will see the following frames:

DHCPDISCOVER When a client needs to find a DHCP server, it broadcasts a DHCPDISCOVER frame.
DHCPOFFER DHCP servers each respond to a DHCPDISCOVER broadcast by sending a DHCPOFFER frame back to the client. A DHCPOFFER frame contains an offer of an IP address and IP configuration information.
DHCPREQUEST The client chooses from the DCHPOFFER frames it receives. It then broadcasts a DHCPREQUEST frame which contains the identifier of the server whose offer it accepts. That server interprets this as an acceptance of its offer and all other servers interpret it as a rejection of theirs.
DHCPACK If the DHCP server still has available the IP address that it offered to the client, it acknowledges the client's DHCPREQUEST by sending it a DHCPACK frame.
DHCPDECLINE If the information in the DHCPACK frame is not acceptable to the client, it sends a DHCPDECLINE frame. It then starts the process of requesting an IP address again, by sending a DHCPDISCOVER frame.
DHCPNAK If the DHCP server no longer has available the IP address that it offered to the client, it responds to the client's DHCPREQUEST by sending it a DHCPNAK frame.
DHCPRELEASE When the client has finished with its IP address, it sends the server a DHCPRELEASE frame to indicate that it no longer needs the address.

The Madge DHCP client interface

Windows 95 and Windows NT both incorporate DHCP and the protocol is increasing in popularity. Madge supply a DHCP client as part of the Smart LAN Support Software. The DHCP module from Madge is called DHCP.SMT.