Vagueness of the DHCP RFCs and vendor implementations.

["Michael J. Lewis" <[e-mail]>]

Howdy, folks.

A couple of weeks ago you may recall my posting a couple of questions
regarding infinite leases and T1/T2 times.  The reason for the question 
was that I had one vendor (Novell) that uses infinite leases with finite 
T1/T2 times for manual addressed clients and another vendor (Microsoft) 
whose client ignored the T1/T2 times on infinite leases.  Consequently, 
although the Microsoft client could successfully receive a lease from 
the Novell server, it would not go through the renew cycle automatically 
and consequently would require intervention to pick up any updated 
configuration information.  (Microsoft allows automated update of 
router, subnet mask, DNS domain name, DNS server, WINS server, and 
NetBios type although obviously some of these one might not want to do 
automatically.)

This is but one example of a situation where both vendors consider 
themselves compliant with the DHCP RFCs but their different 
interpretations create situations where things do not mesh correctly.
Many of these incompatibilities occur because the RFCs (and subsequent 
drafts) are vague in describing how to implement certain facets of the 
protocol.  Vendors, then, interpret the RFCs differently and create 
"standard" RFC compliant products that either cannot interoperate or do 
not interoperate completely.  The infinite lease problem described above 
(for which I received two conflicting responses to my questions posed in 
this working group) is but one example.  (We have also encountered a 
client that does process an option overload specification from a server 
and hence does not pick up option information and a client that does not 
work with virtually any DHCP server.  We have also had to struggle with 
different interpretations for the setting of manual addresses.)

Obviously, one solution is to stick with one vendor's client and server 
implementations.  This is virtually impossible at a corporation like 
Chevron where we have a generally decentralized IT structure and utilize 
a plethora of different operating systems.  Whereas we generally are 
implementing DHCP to support Microsoft Desktops (Windows 95 
specifically), we may be doing so in sites that do not have Microsoft 
servers.  Therefore, we in our central IT are recommending servers for 
our most common OS platforms.  But since each vendor can interpret the 
RFC a little differently, having a vendor announce RFC compliance is 
insufficient for us; we therefore have had to develop our own testing 
procedures to validate DHCP implementations both against the RFCs (and 
drafts) and against our other recommended products.    

Tighter specifications, particularly in the area of manual addressing 
and infinite addressing, would make it easier for us to implement DHCP 
clients and servers from different vendors as there would be less 
deviation within the products.  I realize that some leeway within the 
specifications is helps developers as one can add additional value added 
functions that may sway us to purchase one product over another 
vendor's.  I also realize that as items such as dynamic DNS and a server 
to server protocol appear, we will be able to use the well defined 
dynamic addressing rather than manual addressing for servers and other 
items that require a constant address.  In the meantime, though it is 
very difficult and time consuming to implement multiple vendor DHCP 
solutions within a single environment.

Thanks.