But despite a broad level of support for the protocol, surprisingly few DHCP installations go beyond its most basic features. Most DHCP products and their users treat it as if it were nothing more than an advanced address-assignment protocol, and few users truly leverage the host configuration aspects that define DHCP's true power.
Much of the blame for this can be laid at the feet of vendors, but users who are willing to invest some sweat equity in their installations can get high levels of reward for their efforts. What follows are some techniques to increase your network automation and reap those management rewards.
Read the Book!
Reading The DHCP Handbook: Understanding, Deploying, and Managing Automated Configuration Services (Ralph Droms and Ted Lemon, Macmillan Technical Publishing, 1999) is the greatest favor you can do for yourself if you're serious about exploiting DHCP fully. It takes only a few days to get through the material, and if you can practice on throwaway machines, you'll be a DHCP master in no time.
Although at 500 pages The DHCP Handbook is too large to be a handbook, it is an excellent reference for the mechanics of the DHCP protocol and has many solid working examples.
Use Those Options
Most organizations use DHCP only for minimal stack configuration, limiting the configuration information to an IP address, subnet mask, default router and possibly some DNS or NetBIOS settings. However, the true power of DHCP is found in its broad capabilities as a complete system-configuration protocol. When fully leveraged, DHCP lets you define a variety of system-specific aspects, including directory-services information for LDAP, NDS and NIS (Network Information Services) servers and context, the NTP (Network Time Protocol) servers the system should use, default Web and mail servers, and more.
Making full use of this extended configuration data can be difficult for two related reasons: First, the DHCP client has to be able to accept this data. Second, this data has to be stored somewhere that the supporting applications can access it. Because many DHCP clients are not easily extended to request or accept this data, users look to external configuration mechanisms for this service.
Unfortunately, there isn't much in the way of standardized configuration services either, so you end up using many services together (such as LDAP- or NDS-centric schema in conjunction with SLP multicasts and operating system-specific "user profiles"), or you end up using none of them.
Many of the corporate-focused operating systems actually are entirely capable of requesting and storing extended DHCP options and their data. For example, the DHCP clients that are bundled with Caldera Systems' OpenLinux, Digital Equipment Corp.'s Unix and Sun Microsystems' Solaris operating systems can completely configure a system--including its host name, available routes and application- and directory-specific settings--simply by providing the data via standardized DHCP options.
Microsoft's Windows NT and Windows 2000 are more difficult to coerce, but it's possible to use DHCP options to configure a system if you're willing to do some work. With those two operating systems, the built-in DHCP client uses registry entries from the HKLM\System\Current ControlSet\Services\DHCP\Parameters\Options branch to decide which options to request during the initialization procedure and tells the client where to store received option data.
Using an external registry-reading tool, you can parse and stuff this data back into systemwide configuration files via scripts, if needed. For example, this process could be used to tell Windows NT to request the default SMTP mail server (standard option 69) during the DHCP lease-negotiation process, and then have the system login scripts read the resulting data from the registry and put it into a mail client's configuration files. Although this can be difficult, it is definitely a step forward in overall systems management.
Alas, not all operating systems are even this friendly. Versions of Windows from the 9x family are not extensible at all and require either that application developers bind to the DHCP client's UDP (User Datagram Protocol) socket to intercept extended-option data or that the applications perform their own DHCP lease renewals to obtain extended-lease data. This is how Novell's NetWare client gets NDS data from DHCP, for example.
Another option is to consider using a special-purpose DHCP client, such as Network Telesystems' Shadow IPclient, which is specifically designed to provide extended-option management as part of an overall client-management service.