Managing TCP/IP addresses on your network with DHCP

TCP/IP has quickly become one of the most widely used network protocols. If you aren't currently running TCP/IP on your network, you soon will be. And you'll quickly discover that TCP/IP can be very difficult to properly track and administer.

Every workstation on your network requires its own unique TCP/IP address. As your network grows, managing these addresses can become a time-consuming task. Fortunately, you can use DHCP (Dynamic Host Configuration Protocol) to manage TCP/IP addresses on your network and minimize the amount of time you spend keeping track of the details. In this article, we'll explain how DHCP works and how to install DHCP support on your server.

What is DHCP?

DHCP is a common protocol that allows you to establish a centrally located and managed range of TCP/IP addresses for your client workstations. After you've established a range, a DHCP server dynamically assigns addresses to workstations as needed.

DHCP evolved from the old BOOTP protocol, which lets you boot and configure diskless workstations from a central server. DHCP builds upon BOOTP's design to provide a central administration location from which TCP/IP configuration information can travel across the network.

As you'd expect, DHCP and BOOTP protocol messages include much of the same information. Although DHCP uses some fields differently than BOOTP and adds a few new ones, the packets are basically identical. Routers designed to handle BOOTP packets can also handle DHCP packets, enabling DHCP servers to span subnets.

Why do I need it?

The need for DHCP comes from some basic limitations in TCP/IP's design. Although these constraints don't affect TCP/IP's usefulness, they do make it more difficult to manage than other protocols such as IPX or NetBEUI.

For example, TCP/IP requires each workstation on your network to have a unique address. In a small network environment, this presents little problem. But as your network grows, managing IP addresses can be very time consuming. You must keep track of assigned and free addresses, workstations that no longer have addresses, and workstations that move from one subnet to another and require new addressws. The need for this kind of detailed record keeping is obvious: If you duplicate addresses on your workstations, clients may not be able to communicate on the network.

Managing TCP/IP addresses involves more than just tracking numbers assigned to workstations. To assign TCP/IP addresses statically, you must personally visit each workstation at least once. And along with the address, you also have to configure information such as gateways, subnet masks, and DNS servers. If you make an error in any of these entries, your workstation may not be able to communicate on the network.

DHCP solves TCP/IP configuration and administration problems for you. It eliminates manual configuration at each workstation and allocates and reclaims TCP/IP addresses as needed, giving you an efficient way to prevent IP address conflicts.

How does DHCP work?

For DHCP to work properly, you must have at least one DHCP server and one DHCP client on your network. You'll also need a range of TCP/IP addresses to assign, as well as the gateway addresses and your subnet mask.

Fortunately, Windows NT comes with DHCP support as one of its available services. Most of the workstations on your system probably already support DHCP. Support for the protocol also comes as part of Windows 95 and 98, OS/2 Warp 4, MacOS 7.x and 8.x, and Linux. You can even employ DHCP support on Windows 3.11 for Workgroups workstations.

During startup, a DHCP client workstation gets its TCP/IP addressing information from the server. Keep in mind that this address isn't permanent—the DHCP server simply "leases" the client an address that will expire and must be renewed on a regular basis.

Your workstation obtains and maintains its address leases through several handshaking phases known as states. The workstation DHCP states include:

During initialization, the client boots normally until it needs a TCP/IP address. The client then loads an empty TCP/IP address and broadcasts a DHCPDISCOVER packet across the network. The DHCPDISCOVER packet contains the workstation's name and Media Access Control (MAC) address and can also contain the last TCP/IP address the client obtained from the server. With this information, the server may be able to give the client the same address it received on its last request.

When an active DHCP server hears the DHCPDISCOVER packet, the selection state begins. The server reserves an address from its list and

broadcasts a response to the workstation. The response, called a DHCPOFFER packet, contains a proposed TCP/IP address for the workstation along with the workstation's MAC address, subnet mask information, length of lease, and the TCP/IP address of the DHCP server making the offer.

If the client doesn't receive a DHCPOFFER packet at startup, it tries to initiate selection up to four more times over a five-minute period. The four retries occur randomly but are based on a loose pattern. The client retries each of the four attempts at 2-, 4-, 8-, and 16-second intervals with a random time between 0 and 1,000 milliseconds tacked onto each try. If the workstation never receives a response, it waits five minutes and the process begins again.

If you have more than one DHCP server on your network, your client may receive more than one DHCPOFFER packet. If this happens, the client will choose one of the offers and discard the rest. (The client typically selects the first offer received, but this is not always the case.)

After the client receives a DHCPOFFER packet and accepts a TCP/IP address, the requesting phase begins. The client generates a DHCPREQUEST packet, which includes the TCP/IP address of the server that provided the client address. If the client needs any additional configuration information, such as a default gateway, WINS, or DNS address, it includes the request in the packet.

To wrap up the requesting state, the client broadcasts its DHCPREQUEST packet to all the DHCP servers on the network. After receiving the packet, each server compares its own address to the server address included in the packet. If the server's address doesn't match the one in the packet, then the server releases the address it had reserved for the client in its own specific DHCPOFFER packet.

If a server finds its own TCP/IP address in the DHCPREQUEST packet, it responds to the client with a DHCPACK packet. This packet contains the lease for the client as well as additional information the client requested.

When the client receives the DHCPACK packet, it begins the binding phase by binding the assigned address to the TCP/IP protocol running on its network card. Then, the client system finishes booting. At this point, the client can communicate on the network using TCP/IP. The workstation keeps the assigned TCP/IP address for the length of its lease (which you can adjust) or until you manually shut off the client. If you keep the client running continuously, it will eventually reach the end of its lease period.

When the client reaches 50 percent of its assigned lease time, it will enter the renewal phase. The client sends a DHCPREQUEST packet directly to the server that gave it its TCP/IP address. The DHCP server renews the lease and sends back a DHCPACK packet, which contains the new lease and any configuration information that may have changed since the initial lease.

If the client can't communicate with the server that granted its lease, it will display an error message but continue to operate normally. When 87.5 percent of the client's lease time elapses, the client begins to panic and enters the rebinding phase.

During the rebinding phase, the client begins broadcasting DHCPREQUEST packets across the network to any DHCP server that will respond to it. The current DHCP server may respond with a DHCPACK packet that allows the client to continue using the address it was assigned initially. Or it may send a DHCPNAK packet, which forces the client to reinitialize TCP/IP and obtain a new TCP/IP address and lease. If it accepts the DHCPNAK packet, the client begins the whole process again at the initialization phase.

If the client can't reach a DHCP server by the time its lease expires, it must stop using its assigned TCP/IP address. At this point, it can no longer use TCP/IP to communicate with other workstations on the network. However, it can enter the initialization phase again and start broadcasting DHCPREQUEST packets in an attempt to get a new lease.

Preparing your network to use DHCP

Before you deploy DHCP on your network, you should sit down and do some planning. You'll need to know the configuration of your network, the capacity of your server, the TCP/IP address ranges that you want to assign, and the locations of the workstations that need the addresses. Here are a few other issues you should consider as you develop your implementation plan:

Microsoft recommends that you have at least two DHCP servers on your network to provide redundancy in case one server should fail. Remember, DHCP leases are temporary. When your client's lease expires, it can no longer use TCP/IP to communicate on the network. If you have only one DHCP server on the network and it crashes for an extended period of time, your clients will begin to lose their leases. With multiple servers, clients will have the option during the rebinding state to get new TCP/IP addresses.

If you're going to connect your network directly to the Internet, you may want to obtain a range of TCP/IP addresses for your organization from InterNIC, which you can contact at www.internic.net. Alternatively, if you want to connect to the Internet from behind a firewall, you can assign any range of addresses as long as the addresses fall within the private range of numbers defined in Table A.

Table A TCP/IP address ranges available for private use.

If you're using multiple DHCP servers, you need to divide your network's address ranges among the servers. Address numbers in separate ranges can't overlap. DHCP servers don't communicate with each other, so there's no way for one server to know what addresses the other server has available or has already assigned. If address ranges overlap, both servers could lease the same address to different workstations.

You'll find that you can use the same server for DHCP and file and print services. You shouldn't need to increase the hardware level of your server unless you're already pushing NT's minimum requirements.

Conclusion

Even though TCP/IP is a popular protocol, it can be difficult to manage in a large network environment. If you want to deploy TCP/IP on your network, you'll need a way to easily manage individual addresses for all your workstations. Fortunately, you can assign and manage TCP/IP addresses using DHCP. Doing so will make your job a lot easier.

Note:

Using DHCP is very simple. All you have to do is set up DHCP on your server and configure client support on your workstations. From that point, everything happens automatically.

Just as a workstation does with the DHCPDISCOVER packet, a DHCP server must broadcast over the network to reach the requesting client. Both systems must start with mass broadcasts because TCP/IP isn't configured yet on the client to allow point-to-point communication.