Conserve IP addresses on your network

The Internet has grown exponentially throughout the 1990s, doubling in size nearly every 10 months. A result of this growth is that address registration authorities, such as InterNIC Registration Services (http://www.internic.net), have allocated IP address space at an astounding rate. Because IP addresses are 32 bits long, the potential exists for 4 billion unique addresses. Although the Internet hasn't reached that size, address depletion is occurring. A factor in address depletion is IP's use of hierarchical addressing, which means InterNIC allocates addresses per network rather than per host. Thus, InterNIC allocates one Class C address, which as many as 254 hosts can use, to networks that might contain only a few hosts.

One innovation to conserve IP addresses is DHCP (for more information about other IP address conservation methods, see the sidebar "Alternative Address Conservation Schemes," page 118). DHCP is a widely used protocol that systems administrators can use to temporarily assign IP addresses to hosts. This functionality lets systems administrators control address proliferation by allocating an address only to a host that is connected to the local network. Although DHCP offers other capabilities, the protocol is an important tool for conserving network addresses.

Do You Need DHCP?
Many sites avoid DHCP because their administrators see it as another service to run and manage. However, depending on a site's environment, the effort you spend managing DHCP might be much less than the alternative. For example, our company uses one Class C address split between two physical locations. All hosts have a static IP address, and the DNS server lists all the hosts. When our company first connected to the Internet in 1994, many anonymous FTP sites did a reverse lookup on the host IP address to ensure that the host IP address matched the user's email address domain. In time, our company had to allocate an IP address on both of its subnetworks for every portable host, because tracking who was using which address in which office was too much of a hassle. Also, users had to reconfigure their systems when they moved to a different subnetwork. As our company added dial-up and VPN capabilities, it found that the server might allocate three or four addresses to a user (one on each subnet, plus one or two for the VPN connection), even when the user was using only one or two. After determining that running the server was less costly than running out of IP addresses, our company decided to employ DHCP.

An important advantage of DHCP is that host renumbering becomes less of a headache—DHCP reduces the amount of hands-on configuration a systems administrator must perform on host systems; this headache is particularly a problem at small remote offices. In addition, most companies change their ISP every year or two, which requires a company to change its IP network address even if its domain name remains the same. In a DHCP environment, changing IP host addresses is as simple as changing the address parameters on the DHCP server (and changing the host addresses of any systems with static addresses).

So, do you need DHCP? Consider implementing DHCP if your environment includes many remote dial-up users who move from network to network, a large network in which address management at the desktop level is difficult or inconvenient, more potential users than you have addresses, or frequent network changes. However, DHCP isn't the best choice for routers, servers, printers, and other systems that need static addresses; sites that have plenty of available addresses; or sites in which addresses don't frequently change.

DHCP Defined
As defined in Request for Comments (RFC) 2131, DHCP is an Internet standards track protocol that lets a TCP/IP network server provide clients with configuration information such as the default gateway (i.e., router), cookie, time server, DNS server, and WINS addresses; domain name; and subnet mask. Although this article provides a Windows NT spin on this protocol, DHCP is hardware and software platform-independent. DHCP server software is available for most OSs, and most TCP/IP client software implementations support DHCP; furthermore, any DHCP client can communicate with any DHCP server.

Also, DHCP defines a mechanism for IP host address allocation. DHCP supports three allocation mechanisms, and any site will use one or more of these mechanisms depending on its local network administration policies:

  • Automatic allocation—The server assigns a permanent IP address to a client.
  • Dynamic allocation—The server assigns an IP address to a client for a limited time (i.e., the lease period) or until the client explicitly relinquishes the address.
  • Manual allocation—The server conveys to the client an address that the network administrator specifically assigned.

Dynamic allocation is the only mechanism that supports automatic reuse of addresses. This capability is the factor that makes DHCP a useful tool for temporarily assigning addresses to client systems that aren't always connected to a network. Because dynamic allocation is the most commonly employed mode of DHCP, it's the mode we'll discuss in detail.

Dynamic Allocation
By supporting reuse of IP addresses, DHCP helps control the address-exhaustion problem. For example, ISPs use DHCP to temporarily assign an address to hosts that use a dial-up connection so that a host has an IP address for only the duration of the connection. Suppose an ISP has 5000 customers and 250 dial-up ports. Each customer needs an IP address to access the Internet. If the ISP used static addressing, each customer would need an IP address whether the customer was connected or not. Using DHCP, the ISP can allocate an IP address to each dial-up port, thus assigning an IP address to a host only when the host connects. The ISP that uses static addressing needs 5000 IP addresses, whereas the dynamic addressing environment needs only 250 addresses because only 250 hosts can make simultaneous dial-up connections.

This simple example demonstrates how network administrators can use DHCP in any network environment that supports remote users. DHCP not only reduces the number of IP addresses a site needs but also simplifies mobility between networks, because users won't have to manually reconfigure their systems each time they switch networks. Also, DHCP prevents the server from allocating more than one address at a time to a host.

Operation
DHCP operation is straightforward: A host computer that supports DHCP acts as a DHCP client if you set its IP address to 0.0.0.0 or if you select a DHCP-related option in its network configuration, such as Obtain an IP address automatically. You select this option in the Network applet in Control Panel by selecting the TCP/IP dial-up component and clicking Properties (Screen 1 shows a Windows 95 TCP/IP client we configured to use DHCP). NT, Win9x, UNIX, and OS/2 systems support DHCP as a native client service in the TCP/IP kernel. (DHCP client software isn't available in all TCP/IP suites, in which case these DHCP-related options aren't available.)

DHCP operates in four basic phases, which Figure 1 shows. Like most TCP/IP applications, DHCP uses a client/server model and the client initiates activity. DHCP transports all messages in UDP datagrams: The client sends messages to UDP port 67 on the DHCP server, and the server sends messages to UDP port 68 on the DHCP client.

First, the Initialization phase occurs when a client requests an IP address. The client sends a DHCPDISCOVER message on the local IP subnet to find the DHCP server (or servers). The client doesn't know the address (or addresses) of the DHCP server (or servers), so it uses an IP broadcast address for the DHCPDISCOVER message. All available DHCP servers respond with a DHCPOFFER message. If more than one server is available, the client usually selects the first server to respond, but no rule specifies which server the client has to use. Regardless of how many servers respond, the client broadcasts a DHCPREQUEST message that identifies which server the client will use and implicitly informs all other servers that the client won't use them. The selected server responds to the client with a DHCPACK message that contains the assigned IP address, any other network parameter assignments, and the lease (i.e., the amount of time for which the DHCP server assigns the client the IP address).

The DHCP client maintains two timers: T1, the address renewal timer; and T2, the server rebinding timer. By default, the client sets T1 to 50 percent of the lease and T2 to 87.5 percent of the lease. This setting allows the client plenty of time to renew the lease. The client can set both timer values to another value at the time the DHCP server assigns the address; however, T1 must be less than T2.

When T1 expires, the client enters the Renewal phase and tries to renew its address lease. To renew its lease, the client sends a DHCPREQUEST message to the server that assigned the address. The server replies with a DHCPACK message and a new lease period. As long as the server renews the address lease within the T1 period, T2 will never expire. If T2 expires, the client enters the Rebind phase and tries to find any other server that will renew the address.

In the Rebind phase, the client broadcasts a DHCPREQUEST message to find any DHCP server that will renew the lease. Any server that can renew the lease for this address replies with a DHCPACK message and a new lease. At some point, the client will relinquish the address and disconnect from the network. If the client supports Graceful Shutdown, it will send a DHCPRELEASE message to the server, giving up its address.

This description explains the basic operation of the DHCP protocol; however, be aware of DHCP's security concerns. DHCP is an insecure protocol that is difficult to securely protect. Nefarious users can easily set up an unauthorized DHCP server that they can use to send clients disruptive information, such as incorrect or duplicate IP addresses and incorrect gateway or name server addresses. In addition, a malicious DHCP client can claim all available addresses, denying the addresses to other users. Therefore, implement DHCP across a firewall only in environments in which DHCP is absolutely necessary.

Installation and Administration
Installing the DHCP Server service on an NT server is simple. Anyone logged on as a member of the Administrators group can install the DHCP service by selecting Microsoft DHCP Server, Add on the Services tab of the Network applet in Control Panel.

In the server's Administrative Tools group, you use the DHCP Manager to administer the DHCP service (Screen 2, page 121, shows the DHCP Manager dialog box). You can use the DHCP Manager to manage only NT-based DHCP servers within an NT domain. Through the DHCP Manager Server menu, you can add or remove DHCP servers and display a server's properties.

After you install the DHCP Server service, the first order of business is to define one or more scopes. A scope is a range of IP addresses that the server can assign to client systems. You create, delete, configure, activate, and deactivate individual scopes via the DHCP Manager Scope menu. To create a scope, you use the Create Scope dialog box, which Screen 3, page 121, shows. The dialog box is straightforward, and you need to supply the following information:

  • Start Address and End Address—required fields that you use to specify the address pool's first and last IP addresses that the DHCP Server service can assign to clients.
  • Subnet Mask—a required field in which you define the subnet mask the DHCP Server service assigns to all clients in this DHCP scope.
  • Exclusion Range Start Address and End Address—optional fields that you use to specify a range of IP addresses that the DHCP Server service needs to remove from the address pool. This specification is important in environments in which you have assigned static addresses in the address pool range.
  • Lease Duration—a required field you use to define the duration for which address assignments are effective. If you select Unlimited, address assignments never expire; otherwise, use the Limited To option to specify the lease in days, hours, and minutes.
  • Name—a required field in which you determine the name of the scope (for administrative purposes).
  • Comment—an optional field in which you can provide additional comments that describe the scope.

After you define a scope, you must activate it before the DHCP service can use it. When you create the scope, DHCP asks whether you want to activate it immediately. You can activate a scope when you create it, or you can use the DHCP Manager to activate it later.

When you select the range of addresses in the assignment pool, don't include addresses for the router (i.e., gateway); DHCP, Web, FTP, email, DNS, Simple Network Management Protocol (SNMP), and other servers; or SNMP-managed devices, printers, and other devices to which you have assigned static IP addresses. Use the Exclusion Range fields to exclude these addresses from the DHCP address pool.

Determining the lease duration might be the hardest task for a DHCP administrator. Leases can vary from as short as a few hours or days (e.g., for a very dynamic network with frequent changes) to several months (e.g., for a stable network); thus, to choose the best lease, administrators need to understand their network environment and its usage patterns. To determine the optimal lease time, you have to consider several factors, such as the number of available IP addresses vs. the number of potential clients, the frequency of DHCP option and network changes, and the frequency of client additions and removals from the network. If you set leases too short, network traffic increases and the clients and servers spend additional time exchanging DHCP renewal messages. If you set leases too long and clients don't employ Graceful Shutdown, addresses might remain allocated even when the client is no longer connected to the network. Although determining the ideal lease is difficult, you don't need to assign an infinite-time lease. This option seems like a way to permanently assign an IP address; however, in time, an infinite lease can cause problems as the client and server power up and down. The Scope menu lets you examine the currently active leases within a scope and reserve a specific address for a specific host.

Client/Server Environments
Four basic network topologies exemplify DHCP network scenarios. The simplest and most common scheme is to employ one DHCP server to assign addresses and other parameters to clients on one network segment. In this scenario, the server receives and responds to all requests.

A potential problem with this single-server model is that clients can't access information if the server is down, and the network can grow unstable if the server's downtime is lengthy. A common workaround is to employ two DHCP servers on a network segment to provide redundancy. Although this setup prevents the problem of an unavailable DHCP server, it adds another potential problem—the two servers have to control two disjointed address scopes. The problem is that DHCP servers on the same network don't communicate with each other. Therefore, if scopes overlap, the servers can assign the same address to different clients. (Several vendors and the Internet Engineering Task Force—IETF—DHCP Working Group are developing a specification that creates a common directory to store configuration information that multiple DHCP servers can access. This specification would mean that multiple servers could provide true redundancy over one address pool.)

In networks with multiple LAN segments that connect via a router, you can set up the DHCP service in different ways (e.g., one server for all segments or a server on each segment). One common option is to use one DHCP server to support clients across multiple networks connected by a router. Figure 2 shows this scenario, in which two networks use Class C addresses 192.168.88.0 and 192.168.99.0. The DHCP server is part of the first network and has the address 192.168.88.5. The router that connects the networks uses IP addresses 192.168.88.1 and 192.168.99.1. In this example, you'll define two scopes: the local subnet at 192.168.88.16 through 192.168.88.100 and the remote subnet at 192.168.99.50 through 192.168.99.75. This scope definition means that the DHCP server can assign addresses in the range 192.168.88.16 through 192.168.88.100 to clients on the 192.168.88.0 segment and in the range 192.168.99.50 through 192.168.99.75 to clients on the 192.168.99.0 segment. You can understand how the DHCP server correctly assigns addresses to clients on the 192.168.88.0 segment, but how the DHCP server assigns address to clients on the 192.168.99.0 side of the router is less obvious.

When a client on the 192.168.99.0 network broadcasts a DHCP message, the router must pass it to the other subnet for the server to see it. Thus, you must implement proxy DHCP software at the router. If the router supports proxy DHCP, the router accepts DHCP messages and forwards them to the server. For example, in a Cisco Systems (http://www.cisco.com) environment, the network administrator can use the following commands to enable the DHCP proxy capability and identify a DHCP server:

ip dhcp server 192.168.88.5 (Cisco 2500 IOS V11.0)
set dhcp relay 192.168.88.5 (Cisco 2500 IOS after V11.0)

When a DHCP server that can assign addresses on multiple subnets receives a request, the server selects the appropriate address pool by determining which scope matches the requesting client. If a DHCP relay agent passed the request to the server, the request includes the relay agent's IP address. A router always has at least two addresses, so the relay agent must advertise the address of the subnet where the DHCP request originated. In the previous example, the router advertises its 192.168.99.1 address because that is the address of the local network where the request originated.

Given this information, the operation of the DHCP server is straightforward. If the incoming DHCP message doesn't contain a relay agent address, the server assumes that the requesting client is on the same subnet as the DHCP server (192.168.88.0 in Figure 2) and assigns the client an address from the local subnet scope. If the message contains a relay agent's address, the server assumes that the requesting client is on the same subnet as the agent (192.168.99.0 in Figure 2) and assigns the client an address from the remote subnet scope.

An alternative network topology is to use multiple servers across multiple segments. This scenario operates much like the previous scenarios; however, be careful that the address scopes of the multiple DHCP servers don't overlap. In addition, if you use DHCP relays (e.g., two servers in a three-segment network), ensure that your clients carefully select the most appropriate server via the router.

A Full-Featured Tool
Although using DHCP to assign addresses is the most common purpose, you can use DHCP to do much more. The NT version of the DHCP Server service offers almost 50 network settings, which you can assign and manage using the DHCP Manager Options menu. DHCP assigns global settings to all scopes that a DHCP server manages (DHCP uses the globe icon to denote global settings), or you can limit settings to one scope. The DHCP Manager Options menu provides a complete list of DHCP options that the NT DHCP Server service supports. You can find a complete list of DHCP options from IETF at http://www.isi.edu/in-notes/iana/assignments/bootp-dhcp-parameters.

DHCP is neither appropriate nor necessary for all environments. However, it's an important tool for the network administrator whose IP address space is at a premium.