|
An edited version of this paper appeared with the title "Windows NT & DHCP" in the May 1999 issue of Windows NT Magazine.
The Internet has experienced exponential growth throughout the 1990s, doubling in size nearly every 10 months. One result is that the Internet Protocol (IP) address space has been allocated at an astounding rate. IP addresses are 32 bits in length, meaning that there are four billion unique addresses and the Internet is not (yet!) anywhere near that size. Address depletion is occurring, however, because IP uses hierarchical addressing; that is, to simplify routing, addresses aren't allocated on a per-host basis but on a per-network basis. Thus, a single Class C address (which can be used to address up to 254 hosts) must be allocated even for a network of just a few hosts.
The Dynamic Host Configuration Protocol (DHCP) is a widely used protocol that can be used to assign IP addresses to hosts on a temporary basis. DHCP is being effectively used by many sites to control the proliferation of addresses by only allocating an address to a system that is actually connected to the local network. Although not created specifically with this purpose in mind, DHCP is an important tool for the network administrator looking to conserve network addresses.
DHCP DefinedDHCP, currently defined in Request for Comments (RFC) 2131, is an Internet standards track protocol that allows a server on a TCP/IP network to provide configuration information to clients, including default gateway (router), DNS, WINS, cookie, and/or time server addresses; domain name; and subnet mask. DHCP also defines a mechanism for the allocation of IP host addresses. Although this article will provide a Windows NT spin on this protocol, a further advantage of DHCP is that it is hardware and software platform-independent. DHCP server software is available for most operating systems and most TCP/IP client software implementations support DHCP; furthermore, any DHCP client can communicate with any DHCP server.
DHCP supports three different mechanisms for IP address allocation:
Based upon the local network administration policies, any given site will use one or more of these mechanisms for address allocation. Dynamic allocation, however, is the only one that supports automatic reuse of addresses that are no longer being used. It is this capability that makes DHCP a useful and simple tool for temporarily assigning addresses to client systems that are only temporarily connected to a network. DHCP, for example, is almost universally used by ISPs to temporarily assign an address to hosts with a dial-up connection, so that an IP address is assigned to the host only for the duration of the connection. As this is the most commonly employed mode of DHCP, it is the one that we will discuss here.
Supporting reuse of IP addresses is the way in which DHCP helps control the address exhaustion problem. Consider again the example of an ISP. Suppose an ISP has 5000 customers and 250 dial-up ports. Each customer needs an IP address to access the Internet. Using static addressing, each customer would need an assigned IP address whether the customer was connected or not. Using DHCP, on the other hand, an IP address could be allocated to each dial-up port and assigned to a host only when actually connected. While the ISP would have to "own" 5000 addresses in the static addressing case, only 250 addresses are needed in the dynamic addressing environment because only 250 simultaneous dial-up connections can be made (one per port). While the example is somewhat simplified, it demonstrates how DHCP could be used in any network environment with remote users. IP addresses are assigned only to hosts that are actually connected, saving the number of addresses that a site needs to have. It can also make mobility from one network to another easier for the user since they will not have to manually reconfigure their system; it also can prevent a host from being allocated more than one address at a time.
Many sites avoid DHCP because it is just another service to run and manage. In our environment, for example, we have a single Class C address split between two physical locations. All hosts have a static IP address (and hosts are listed in the DNS). When we were first connected to the Internet in 1994, many anonymous FTP sites did a reverse lookup on the host IP address to make sure that it matched the user's e-mail address domain. Over time, we found that we have had to allocate an IP address on both of our subnetworks for every portable host because it was too much of a hassle to track who was using what address in what office. This also required users to reconfigure their systems when they moved to a different subnetwork. Furthermore, as we added dial-up and virtual private network (VPN) capabilities, we found that a given user might have three or four addresses allocated for them even though they were using only one or two; one on each subnet plus one or two allocated for the VPN connection. We decided to employ DHCP once we determined that the overhead of running the server was lower than the problem of running out of addresses!
Another important advantage of DHCP is that host renumbering becomes a thing of the past and, indeed, this is the main motivation for most sites that employ DHCP -- it reduces the amount of hands-on configuration of host systems, which can be a particular problem at small remote offices. DHCP provides an even added advantage given the fact that many companies change their ISP every year or two, and when an organization changes ISP, the IP network address changes even if the 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 statically-addressed systems).
So, when might you use DHCP? Consider DHCP if you have:
DHCP is not the best choice for:
DHCP uses a relatively simple protocol and its operation is straight-forward. A host computer that supports DHCP will act as a DHCP client if the IP address is set to 0.0.0.0 or if an option such as Server assigned IP address is selected. DHCP client software may not be available is some particular TCP/IP suites, in which case these settings will not be available; Unix, OS/2, and Windows 95/98/NT systems, however, all support DHCP as a native client service in the TCP/IP kernel. Figure 1, for example, shows how a Windows 95 TCP/IP client would be configured to use DHCP by selecting the Obtain an IP address automatically option in the TCP/IP Properties window.
|
|
|
Figure 2 shows the messages exchanged during the four basic DHCP operational phases. Like most TCP/IP applications, DHCP uses a client-server model and the client initiates the activity. Although not shown here, all DHCP messages are transported in User Datagram Protocol (UDP) datagrams; client-to-server messages are sent to UDP port 67 (DHCP server) at the server and server-to-client messages are sent to UDP port 68 (DHCP client) at the client.
The Initialization phase occurs when a client first requests an IP address:
The DHCP client maintains two timers, called T1 (the address renewal timer) and T2 (the server rebinding timer). By default, T1 is set to 50% of the lease period and T2 is set to 87.5% of the lease period. Both timer values may be set to another value by the host when the address is assigned (although T1 must be less than T2).
When the T1 timer expires, the client enters the Renewal phase and tries to renew its address lease:
As long as the server renews the address lease within the T1 period, the T2 timer will never expire. If T2 does expire, the client enters the Rebind phase and tries to find any other server that will renew the address:
At some point, the client is ready to relinquish the address and disconnect from the network. If the client supports Graceful Shutdown, it will send a DHCPRELEASE to the server, giving up the claim on its address.
This description, while providing the basic operation of the DHCP protocol, is purposefully brief and leaves out many of the details. It should also be noted that DHCP is an insecure protocol since it is difficult to securely protect the systems that DHCP is intended to serve. Additionally, a nefarious user can easily setup an unauthorized DHCP server which can then send disruptive information to clients, such as incorrect or duplicate IP addresses, and incorrect gateway or name server addresses. For that matter, a malicious DHCP client could claim all of the available addresses for itself, denying those addresses for other users. For these and other reasons, DHCP use across a firewall should be implemented only where absolutely necessary.
Installing and Managing DHCP on a Windows NT ServerInstalling the DHCP Server service on a Windows NT Server is relatively simple. The DHCP service can be installed by anyone logged in as a member of the Administrators group by clicking on the Network icon in the Control Panel, choosing the Services tab, selecting Microsoft DHCP server, and then clicking Add.
|
The DHCP service is administered using the DHCP Manager (located in the Administrative Tools group on the server system). The DHCP Manager can be used only to manage Windows NT-based DHCP servers within a Windows NT domain (Figure 3). Selections under the Server pulldown menu allow the manager to add or remove DHCP servers to be managed, or to display the properties of a particular server.
|
The first order of business after installing the DHCP Server service is to define one or more scopes. A scope is a range of IP addresses that the server can assign to client systems. Creation, deletion, configuration, and activation/deactivation of individual scopes is accomplished via the Scope pulldown menu in the DHCP Manager. When a scope is created, a dialog box such as the one in Figure 4 will appear. The information to be supplied here is rather straight forward:
Once the scope has been defined, it must be activated before it can be used by the DHCP service. A scope can be activated when created or via the DHCP Manager.
When selecting the range of addresses in the assignment pool, do not include addresses for the router (gateway); DHCP, Web, FTP, e-mail, DNS, SNMP, and other servers; SNMP-managed devices; printers; and other devices where addresses are statically assigned and managed. Addresses for these devices should be excluded from the DHCP address pool.
Finally, determining the lease duration may be the hardest task for the DHCP administrator. A number of factors have to be considered in determining the best lease times, including the number of available IP addresses versus the number of potential clients, as well as the frequency of DHCP option and network changes, and the frequency of client additions and removals from the network. If leases are too short, traffic on the network increases and additional time is spent exchanging DHCP renewal messages; if leases are too long (and clients do not employ graceful shutdown), addresses may stay allocated even though the client is no longer on the system. It is a good idea, however, never to assign an infinite-time lease; although that might sound like a way to permanently assign an IP address, it can actually cause problems over time as the client and server go up and down. Administrators need to understand their network environment and the patterns of usage to best choose a lease duration, and lease durations 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 relatively stable network). The most efficient address assignments, of course, are when the clients relinquish addresses when they disconnect from the network. The Scope pulldown menu is also used by a network manager to examine the currently active leases within a scope and to reserve a specific address for a specific host.
As mentioned above, DHCP can be used to do much more than assign addresses, although that is the most common purpose and addresses are typically the scarcest resource associated with DHCP. The NT version of the DHCP server can, in fact, be used to assign nearly 50 different network settings, such as the ones shown in the figure:
| 002 | Time Offset | Time offset (in seconds) from Universal Time Coordinated (UTC), aka Greenwich Mean Time |
| 003 | Router | IP address of default gateway(s) |
| 006 | DNS Servers | IP address(es) of network DNS server(s) |
| 015 | Domain Name | Default host domain name |
The DHCP Options pulldown menu manages the assignment of DHCP optional network settings; global settings are assigned to all scopes managed by a particular server (denoted by the globe icon) and scope options are limited to a single scope. The complete list of DHCP options supported by the Windows NT DHCP Service will be found here, as well.
As an aside, the number preceding the setting name (such as the "003" before "Router") refers to the DHCP option identifier. A complete list of DHCP options per the Internet Engineering Task Force (IETF) can be found on the Internet at http://www.isi.edu/in-notes/iana/assignments/bootp-dhcp-parameters. (Table 1 below lists all of the DHCP options supported in the Windows NT DHCP Service).
There are four basic network topologies that exemplify DHCP network scenarios. The simplest, and most common, scheme is to employ a single DHCP server to assign addresses and other parameters to clients that are all on a single network segment. In this scenario, the server receives and responds to all requests.
One potential problem with this single-server model is that clients cannot access the information if the server is down, and the network can grow unstable if the server's downtime is lengthy. A common work-around, then, is to employ two DHCP servers on the network segment to provide redundancy. While this obviates the problem of an unavailable DHCP server, it potentially adds another problem; namely, the two servers will have to control two disjoint address scopes. The reason for this is that DHCP servers, even on the same network, do not communicate with each other. Therefore, if the scopes overlap, it is quite possible that the same address will be assigned to two different clients. (The IETF DHCP Working Group and a number of vendors, however, are currently working on a specification to store configuration information in a common directory that can be accessed by multiple DHCP servers. This would mean that multiple servers could provide true redundancy over a single address pool.)
|
In those networks with multiple LAN segments connected via a router, the DHCP service can be handled in a couple of ways; namely a single server for all segments or a server on each segment. Using a single DHCP server to support clients across multiple networks connected by a router is quite common and an example of this scenario is shown in Figure 5:
The DHCP server system (at 192.168.88.5) can be set up as described above. In this example, two different scopes will be defined:
This means that addresses in the range 192.168.88.16-192.168.88.100 may be assigned to a client on the 192.168.88.0 segment and clients on the 192.168.99.0 segment can be allocated addresses in the range 192.168.99.50-192.168.99.75. It is easy enough to see how the DHCP server assigns addresses correctly to clients on the 192.168.88.0 segment, but it is worth a more detailed look at how the server correctly assigns addresses to clients on the 192.168.99.0 side of the router.
When a client on the 192.168.99.0 network broadcasts a DHCP message, it must be passed to the other subnet to be seen by the server. This is accomplished by using proxy DHCP, software which must be implemented at the router. If the router supports proxy DHCP, the router will accept DHCP messages and forward them to the server. In the Cisco environment, for example, a DHCP proxy capability could be enabled and a DHCP server identified for this example using one of the following router commands:
When a request comes to the DHCP server that can assign addresses on multiple subnets, the server must determine which address pool to use. This is accomplished simply by determining which scope matches the requester. In particular, if the request was passed along by a DHCP relay agent, the request will include the relay agent's IP address. Since a router will always have at least two addresses, it is important that the relay agent advertise the address of the subnet where the DHCP request originated; in this example, the router will advertise its 192.168.99.1 address.
Given this information, the operation of the DHCP server is straight forward:
The final topology scenario -- using multiple servers across the multiple segments -- is just a more general case of the scenarios above. But be careful! The address scopes still should not overlap. In addition, if DHCP relays are employed (for example, if you use two servers in a three-segment network), be sure that your clients carefully select the most appropriate server (via the router, of course).
Conclusion
DHCP is not appropriate nor necessary for all user sites or for all situations. But it is an important tool for the network administrator, particularly if IP address space is at a premium, and the Windows NT implementation works well. Most good network management books discuss DHCP in more detail, including those on Windows NT Server. In addition, DHCP: A Guide to Dynamic TCP/IP Network Configuration by Berry Kercheval (Prentice Hall) is a good detailed reference on this subject.
There are actually a number of methods that have been introduced in the last few years to more cleverly use the available IP address space. Classless Interdomain Routing (CIDR), for example, was designed to aggregate IP addresses and decrease the size of routing tables, but also allows a network to be assigned a sub-Class C address, or just a portion of a Class C address space. This capability, employed by most Internet service providers (ISPs) and address registrars (at least in North America), means that several very small networks can share a single Class C address. Network Address Translation (NAT) and Port Address Translation (PAT) are two other schemes supported by some routers which will extend the life of the IP address space by hiding the addresses actually used on the internal addresses from those addresses advertised and accessible from the Internet.
CIDR, however, is much more applicable to large networks, ISPs, and the Internet backbone than to individual user nets. NAT and PAT, while supported on many routers, is not yet in widespread use. DHCP, on the other hand, is well-known, well-understood, easy to use, and widely available in most server operating systems.
IP version 6 (IPv6), of course, obviates the address exhaustion problem by employing 128-bit addresses -- a large enough space to address every molecule in the solar system! But schemes such as CIDR, NAT, PAT, and DHCP are actually extending the life of the current version of IP (IPv4) because of their address handling capabilities.
| TABLE 1. Standard DHCP Options. In addition to these,
site-specific options can also be defined. | ||||
| 002 | Time Offset | 028 | Broadcast Address | |
| 003 | Router | 029 | Perform Mask Discovery | |
| 004 | Time Servers | 030 | Mask Supplier Option | |
| 005 | Name Servers | 031 | Perform Router Discover | |
| 006 | DNS Servers | 032 | Router Solicitation Address | |
| 007 | Log Servers | 033 | Static Route Option | |
| 008 | Cookie Servers | 034 | Trailer Encapsulation | |
| 009 | LPR Servers | 035 | ARP Cache Timeout | |
| 010 | Impress Servers | 036 | Ethernet Encapsulation | |
| 011 | Resource Location Servers | 037 | Default TTL Option | |
| 012 | Host Name | 038 | Keepalive Interval | |
| 013 | Boot File Size | 040 | NIS Domain Name | |
| 014 | Merit Dump File | 041 | NIS Servers | |
| 015 | Domain Name | 042 | NTP Servers | |
| 016 | Swap Server | 043 | Vendor Specific Information | |
| 017 | Root Path | 044 | WINS/NBNS Servers | |
| 018 | Extensions Path | 045 | NetBIOS Server TCP/IP NDDD addresses | |
| 019 | IP Layer Forwarding | 047 | NetBIOS Scope ID | |
| 020 | Non-local Source Routing | 048 | X Window System Font | |
| 021 | Policy Filter Masks | 049 | X Window System Display | |
| 022 | Max DG Reassembly Size | 064 | NIS + Domain Name | |
| 023 | Default Time to Live | 065 | NIS + Servers | |
| 024 | Path MTU Aging TO | 066 | Boot Server Host Name | |
| 025 | Path MTU Plateau Table | 067 | Bootable Name | |
| 026 | MTU Option | 068 | Mobile IP Home Agents | |
| 027 | All subnets are local | |||
ABOUT THE AUTHORS: Gary C. Kessler was, at the time this article was written, the Director of Information Technology at Hill Associates, a telecommunications training and education firm with headquarters in Colchester, VT. Carol A. Monaghan is currently the Director of Information Technology at Hill Associates. Their e-mail addresses are kumquat@sover.net and c.monaghan@hill.com, respectively.