Eric A. Hall

NOTE: This article is an archived copy for portfolio purposes only, and may refer to obsolete products or technologies. Old articles are not maintained for continued relevance and accuracy.

May 15, 1996

A Comparison of DHCP Clients

There's no doubt about it: The biggest problem with TCP/IP is the administrative burden of having to manage every node's unique IP address. But if you don't track the IP addresses in use on your LAN, you're in for even more trouble.

Trying to locate workstations with conflicting IP addresses can be incredibly difficult, and an equally incredible waste of time. In the end, tracking the addresses in use becomes less costly than not tracking them, so you end up having to manage them proactively anyway.

Having recognized these shortcomings, the Internet Engineering Task Force (IETF) has put forth a set of draft recommendations for a dynamic IP address assignment protocol called Dynamic Host Configuration Protocol (DHCP) that deals with the management issues explicitly.

The specification endorses the use of "pooled" addresses that are assigned to systems on an as-needed basis and includes recommendations for guaranteeing unique IP ad- dresses among the nodes themselves. These two components make DHCP a highly viable mechanism for managing IP addresses and go a long way toward making IP an easy-to-implement protocol for LANs and WANs of all sizes.

That's the theory, anyway. As we discovered in our testing, the various implementations are all somewhat off the mark, and there is still plenty of room for improvement. However, most of the implementations do interoperate successfully, so you should at least consider deploying the technology if not the specific products.

We brought together six TCP/IP stacks and pitted them against each other in our San Mateo, Calif., lab. Our testing consisted of five possible scenarios, each representing a likely event that could occur while using dynamically assigned IP addresses. We tested with a short-term 10 minute lease, a permanent lease that never expired and machine-specific leases that were tied to the client's Ethernet MAC address. We also tested the clients' recovery capabilities when placed in a situation where no server was available. Finally, we tested the clients' ability to let go of the lease when it was not in use.

Other client functionality beyond what shows up in these tests is also significant. For example, not all of the clients use the host name provided by the DHCP server, and not all of them supported the DHCP options we would have expected. Whether or not these are important to you will depend on your environment.

Microsoft Windows95

Microsoft's implementation of DHCP is either one of the best on the market or just mediocre, depending entirely upon your needs. If you want a client that is primarily focused on providing NetBIOS-over-TCP/IP services, then the DHCP client in Windows95 is arguably the best of the lot. But if you're looking for a "pure" TCP/IP client that happens to run on Windows95, then you're probably better off waiting for other vendors to port their products to that environment.

Figure 1

For example, rather than allow the DHCP server to assign the host name value, Windows95 insists on using the locally-defined NetBIOS node name. This is so that the client will always have the same name, allowing users on other Windows95 systems to use its resources consistently. This makes sense if that's how you work, but it's not exactly the purest way to handle IP host names. By definition, the host name is linked to the IP address in use on that host, which Windows95 will not take.

Regardless of these architectural issues, Windows95's DHCP client support is fairly robust. It worked well with all of the servers we examined. The bundled WINIPCFG.EXE utility is unique in that it not only gave us the ability to examine the current settings, but also allowed us to release and renew DHCP leases manually, which instantly set it apart from all of the other clients.

We were also surprised to find that the Windows95 DHCP client was the only one that would continue using a valid lease if there were no DHCP servers available. However, we were shocked to find that the Windows95 client did not automatically give up the lease when the system was shut down, even though the option was there to do it manually.

Once we killed the lease and restarted the system, Windows95 marked the interface down and removed the entry from its internal routing table. This caused all applications to fail immediately, reporting that there was no route to the specified host. While this guarantees that failures are quick, we would like it even better if the stack would inform us that no DHCP servers were available. As it stands, users will be left scratching their heads wondering why their apps aren't working anymore.

WRQ Reflection Services/TCP Connection 5.2

While Windows95 offered the most interactive capabilities once the stack was configured, WRQ's TCP Connection offered the broadest range of configuration options. TCP Connection Services provides an extremely granular level of control, allowing you to choose which DHCP options you want to override the locally defined settings on an item-by-item basis.

Figure 2

One of TCP Connection's outstanding features is its ability to request and kill a lease on an as-needed basis. The stack will request a lease whenever WINSOCK.DLL is loaded, and give it up whenever it's unloaded. If your users only need IP connectivity for a few minutes a day and you only have a few addresses to spare, then this is a godsend. TCP Connection also handled errors well, informing the user in no-nonsense language that the stack had failed to load, further offering to display the log file. Anytime that WINSOCK.DLL was loaded after that, the same sequence of events would repeat.

We'd like to see some functions added. Specifically, the product doesn't have any mechanisms for displaying the status of the current lease. Nor does the product support the reuse of valid leases when a server is unavailable, instead choosing to fail out of the lease negotiation process altogether. But, as it stands, TCP Connection Services is probably the best DHCP client for the Windows 3.x market.

SunSoft PC-NFS Pro 2.0

Just as Windows95's native stack is the best DHCP client for Microsoft-centric networks, SunSoft's PC-NFS is the best DHCP client for Sun-centric networks. For example, PC-NFS Pro was the only client to support the configuration of NIS via DHCP, even though Chameleon and OnNet both support NIS directly. In terms of interoperability with NIS—and especially Solaris-based LANs—PC-NFS is your best bet.

Figure 3

In terms of general functionality, PC-NFS provides some of the most extensive options of any client that we tested. Not only does it support MAC-based fixed leases, but it also allows you to specify a Client ID and a Class ID for dedicated leases and pools. Although this was rare but not unique, PC-NFS' ability to enter and view these fields as ASCII strings or their numeric equivalents made it easy to take advantage of these features, which was unique among the systems we tested.

PC-NFS was the only Windows 3.1 stack we tested that allowed us to view and release a lease manually. However, we could not reclaim a lease once we had destroyed it but were forced to restart Windows instead. Also, during our failure tests we discovered that PC-NFS reported the lack of a server well enough, but it gave us no opportunity to try again, forcing us to restart Windows to get a lease at all.

TGV Software MultiNet for Windows 1.2

TGV Software's MultiNet for Windows 1.2 is a solid and reliable offering, although it lags behind the Windows95 and WRQ products in terms of functionality. What it does, it does very well. Unfortunately, it just doesn't do all that much.

Figure 4

For example, MultiNet lacks any DHCP management capabilities such as the lease monitoring and disposal that are in the Windows95, TCP Connection and PC-NFS stacks. Nor does the product allow users to configure MultiNet's native NetBIOS-over-TCP/IP or router discovery functions via DHCP.

MultiNet provided the best error reporting of the group during our failure tests. When no server could be located, the client prompted the user to abort the connection, and even told us (correctly) what might be the source of the problem.

If no configuration information was available, then the interface was marked as down at the kernel level. Subsequently, if an IP application was launched, the stack would try to obtain a lease again and failing that, it would return a "no route to host" error to the calling application.

MultiNet for Windows is extremely robust and offers strong reliability, but doesn't offer enough functionality to put it at the head of the class.

FTP Software OnNet for Windows 2.0

FTP Software is a well-known and well-respected vendor of TCP/IP stacks for DOS and Windows. However, the DHCP component of OnNet for Windows 2.0 is not one of its stronger areas. It came out only marginally ahead of Chameleon, although it did work with all of the servers we tested and offered some extended capabilities.

Figure 5

The most glaring problem we found was the fact that OnNet refused to conduct ARP broadcasts on the IP address that it received from the DHCP lease. Although this behavior is not mandated in the DHCP specifications, it's highly recommended and all of the other products we tested provide this functionality. With non-locally assigned addresses, sanity testing is a must-have.

OnNet also failed to pass our MAC-based machine-specific lease tests. OnNet insisted on devising and sending a Client ID whenever it issued a DHCPDISCOVER. This caused the servers to attempt to match the system based on the Client ID instead of the MAC address. Since there were no entries for the Client ID in the pool of reserved addresses, the servers did not recognize the system and assigned an address from the general pool.

During our failure tests, OnNet displayed a blank black screen during system startup, and no error messages or any other diagnostic aids were shown. The system appeared to be locked. Once we pressed a key, Windows continued to load, but no errors were ever reported. Additionally, attempts to load IP applications resulted in no indicative error messages. Instead, the applications simply timed out or reported DNS failures.

One of the positive aspects of OnNet is that it did give up the lease when Windows exited, allowing us to recycle addresses on a short-term basis. Also, OnNet was the only system other than TCP Connection that allowed us to configure the NetBIOS-over-TCP/IP capabilities in the stack. Since OnNet only supports broadcast NetBIOS, it does not use any data beyond the NetBIOS scope setting.

NetManage ChameleonNFS 4.6

NetManage's ChameleonNFS 4.6 was the worst DHCP client that we tested, failing to work with 50 percent of the servers we tested. No matter what other benefits it may offer, failing to interoperate automatically puts it at the bottom of the pile.

Figure 6

Chameleon does provide a modicum of error management. If a server cannot be found, an error window is displayed that says "Waiting for DHCP reply" over and over, until you either exit Windows or disable the logging. Unfortunately, the kernel is corrupted until the DHCP reply is received, preventing any other interfaces from being used in the meantime.

Users can configure the stack so that it will reuse previously obtained DHCP information, but this mechanism does not follow the specification. Rather than send out request packets, it initiates a new discovery, and if no servers respond, then it assigns the last known information, even if the lease has expired. This can cause duplicate addresses to be allocated to multiple systems, depending on the mix of nodes and the state of the server. Worse still, Chameleon does not conduct any ARP tests on the address that it assigns itself (a fundamental tenant of the DHCP specification), thereby failing to guarantee that it is unique on the network.