| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
BOOTP Vendor-Specific Area and Vendor Information Extensions (Page 3 of 3) BOOTP Vendor Information Fields Each vendor information field specifies a particular type of information to be communicated, and is encoded using a special subfield structure that specifies the field's type, length and value. This is a common method of specifying options, called TLV-encoding (for type, length, value of course). The same basic method is used for encoding IPv4 and IPv6 options. Table 187 shows the structure and the common names for the subfields of each vendor information field.
There are two special cases that violate the field format of Table 187. A Code value of 0 is used as a pad, when subfields need to be aligned on word boundaries; it contains no information. The value 255 is used to mark the end of the vendor information fields. Both of these codes contain no actual data, so to save space, when either is used just the single Code value is included; the Len and Data fields are omitted. A device seeing a Code value of 0 just skips it as filler; a device seeing a Code value of 255 knows it has reached the end of the vendor information fields in this Vend field. The vendor information extensions of BOOTP have become so popular that the use of this field for sending extra generic information is pretty much standard. In fact, I am not even sure if anyone today still uses the Vend field solely for vendor-specific information at all. When the vendor information extensions were introduced, one was created that points to a file where vendor-specific information can be found. This lets devices have the best of both worldsthey can use the standard vendor-independent fields and also incorporate vendor-specific fields (through the referenced file) where needed. Later, another field type was created that lets vendor-specific fields be mixed with vendor-independent ones right in a BOOTP message. When DCHP was created, the same vendor extension mechanism was maintained and enhanced further, but instead of the field being called vendor information extensions, it was renamed to Options. (A much better name!) The BOOTP vendor information fields were retained in DHCP and new DHCP-specific options were defined. To avoid duplication, I have listed all the BOOTP vendor information fields and DHCP options in a set of tables in the section on DHCP. This includes a discussion of how vendor-specific and vendor-independent information can be mixed as I mentioned in the previous paragraph.You may also want to read the topic describing DHCP options and discussing how they were created from BOOTP vendor information extensions.
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. |