Figure 1. A screen capture of an exchange between a desktop computer and a DHCP server. Click here to see an enlarged diagram.
Frequently, all that is required to establish a connection to the Internet is to plug a cable into an available Ethernet jack and turn it on. After a few minutes, the computer is fully configured and ready to go. As with many things, however, there is a lot going on behind the scenes.
For the purpose of this discussion, let's assume you are plugging the computer into a corporate LAN connected to the Internet. Let's further assume that the corporate LAN uses private IP addressing as described in the Internet Engineering Task Force (IETF) Request for Comment (RFC) 1918 (available at www.rfcs.org). Given this information, you know that the network is likely to be in the range of 10.xxx.xxx.xxx, 172.16.xxx.xxx, or 192.168.xxx.xxx. You could just try some addresses and see if you can establish a connection. There are several problems with this method. First, you might never find the right network address range. Second, if you pick an IP address out of thin air, you could pick an address that has already been allocated to someone else. When this happens, both computers stop talking, with potentially catastrophic results.
What is needed is a system that coordinates the assignment of IP addresses on the network. Ideally, it would allow computers to obtain IP addresses automatically. The system should allow for both fixed IP addresses and dynamically assigned IP addresses. This is exactly what Dynamic Host Configuration Protocol (DHCP) does. (DHCP is more fully described in RFC 2131.)
If you have your network configuration set to obtain an IP address automatically, when your computer is connected to a network it begins a series of exchanges with a DHCP server. The server's task is to assign IP addresses according to a predetermined plan established by the administrator of the network.
I used a packet-sniffing tool (Ethereal) to capture an Ethernet conversation between a computer on the network and a DHCP server. (See Figure 1.) The conversation between the DHCP client (the computer requesting an IP address) and the DHCP server (the computer responsible for assigning IP addresses) follows a specific pattern. First, the client sends out a broadcast message asking DHCP servers to reply with an offer of an IP address. This is a DHCP Discover message. The DHCP standard allows multiple servers to reply with an offer. The Discover message can contain suggestions to the servers for an IP address and other IP parameters. Note that this is only a suggestion.
The second step in the process is for DHCP servers to respond to the Discover message with an Offer message. The Offer message contains, among other things, the IP address and the domain name server address the DHCP server is offering. It also contains a lease period. The lease period is an important part of the assignment process.
Imagine that you are a user with a laptop coming to a facility for a meeting. You plug in your computer and obtain an IP address for the local network via DHCP. When the meeting is over, you leave the facility and never return. It would be a big problem if the DHCP server reserved that IP address forever. The solution to the problem is simple — the DHCP server “leases” you an IP address for a specific period of time. Once the lease expires, the IP address becomes available for others to use. If you are a permanent network user, your computer periodically renews its lease.
During the third step in the DHCP negotiation process, the client sends a DHCP Request message back to the DHCP server requesting a specific IP address. The request also includes something called the server identifier (usually the IP address of the DHCP server) as a check to confirm that the request is being made of the correct DHCP server. (More than one DHCP server can offer an address to the client.)
Figure 2. The DHCP negotiation process involves four steps — Discover, Offer, Request and Acknowledge. Release is a command issued later to release the IP address allocation.
In the fourth and final step, the DHCP server sends a DHCP ACK message, acknowledging the IP address assignment. Figure 2 illustrates the complete negotiation process.
The DHCP process uses a protocol called BOOTP. This protocol was based upon Reverse Address Resolution Protocol (RARP), which was one of the first attempts to allocate network addresses dynamically. BOOTP (DHCP) rides upon User Datagram Protocol (UDP). As a result, delivery of DHCP messages is not guaranteed.
In Figure 1, the source address of the client is 0.0.0.0. This is because the client does not have an IP address yet. However, it does have a Media Access Control (MAC) address that uniquely identifies the client computer. The source and destination MAC addresses are sent with every DHCP message. This allows computers on the network to determine who sent the message and where it is intended to go. Messages targeted at the DHCP server are sent as broadcast messages with the special address of 255.255.255.255. Any messages with this destination address are intended to be “read” by all network devices. More than one DHCP server could respond to a DHCP Discover message, so these messages should be sent to everyone. Once the DHCP ACK message has been sent, the client may begin using the assigned IP address.
There are two ways that a DHCP address can be put back into the pool. One way is for the lease to expire. The other way is for the client to send a Release message to the DHCP server. The last line of Figure 1 shows that the client is now using the address it was assigned (192.168.1.101). The client sends the Release message to 192.168.1.1, which is the address of the DHCP server. The client saved this address when it received the DHCP ACK message.
Once you have obtained an IP address on an internal network, you may still have problems accessing the Internet. Many corporations have firewall rules that limit the type of traffic permitted to be exchanged between the Internet and computers within their facilities.
There are many other things that can be done with DHCP servers. If you would like to learn more, I encourage you to read the DHCP RFC (RFC 2131). A search for “DHCP tutorial” on your favorite Web search engine will yield many resources as well.
Brad Gilmer is executive director of the AAF Association, executive director of the Video Services Forum, and president of Gilmer & Associates.
Send questions and comments to:brad_gilmer@primediabusiness.com
