DHCP Options, Option Format and "Option Overloading"
(Page 1 of 4)
When BOOTP was first developed, its message format included a 64-byte Vend field, called the Vendor-Specific Area. The idea behind this field was to provide flexibility to the protocol. The BOOTP standard did not define any specific way of using this field. Instead, the field was left open for the creators of different types of hardware to use it to customize BOOTP to meet the needs of their clients and/or servers.
Including this sort of undefined field is always a good idea because it makes a protocol easily extensible. That is, allows the protocol to be easily enhanced in the future through the definition of new fields while not disturbing any existing fields. The problem with the BOOTP Vendor-Specific Area, however, is that the extensibility was in fact vendor-specific. It was useful only for special fields that were particular to a single vendor.
What was really needed was a way to define new fields for general purpose, vendor-independent parameter communication, but there was no field in the BOOTP message format that would let this happen. The solution came in the form of RFC 1048, which defined a technique called BOOTP vendor information extensions. This method redefines the vendor-specific area to allow it to carry general parameters between client and server. This idea was so successful that it largely replaced the older vendor-specific use of the Vend field.
Home - Table Of Contents - Contact Us
The TCP/IP Guide (http://www.TCPIPGuide.com)
Version 3.0 - Version Date: September 20, 2005
© Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.