Please Whitelist This Site? I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :) If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads. If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK. Thanks for your understanding! Sincerely, Charles Kozierok Author and Publisher, The TCP/IP Guide

NOTE: Using software to mass-download the site degrades the server and is prohibited. If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.

The TCP/IP Guide  9  TCP/IP Application Layer Protocols, Services and Applications (OSI Layers 5, 6 and 7)       9  TCP/IP Network Configuration and Management Protocols (BOOTP, DHCP, SNMP and RMON)            9  Host Configuration and TCP/IP Host Configuration Protocols (BOOTP and DHCP)                 9  TCP/IP Bootstrap Protocol (BOOTP)

BOOTP Message Format 1 2 3 BOOTP Relay Agents (Forwarding Agents)

BOOTP Vendor Information Extensions

Including the Vend field in BOOTP gives the protocol extensibility for vendor-specific information. Unfortunately, the original field format didn't include any way of extending the information sent from a server to a client for generic, non-vendor-specific TCP/IP information.

This was a significant oversight in the creation of the protocol, because there are many types of information that a TCP/IP host needs when it starts up that really have nothing to do with its vendor. For example, when a host boots, we probably want it to be told the address of a default router; the subnet mask for its local subnet; the address of a local DNS server; the MTU of the local network; and much more. None of these things are vendor-specific, but there is no place to put them in the BOOTP reply message.

Since there was no “non-vendor-specific area” field in BOOTP, the decision was made to define a way of using the Vendor-Specific Area for communicating this additional generic information. This was first standardized in RFC 1048, and then refined in later RFCs as I explained in the BOOTP overview. This scheme basically represents one particular way of using the Vend field that most TCP/IP BOOTP implementations have chosen to adopt, regardless of their vendor. This enhancement is formally referred to as BOOTP vendor information extensions.

To clearly mark that this particular meaning of the Vend field is being used, a special, universal “magic cookie” value of “99.130.83.99” is inserted into the first four bytes of the field. Then, the remaining 60 bytes can contain a sequence of one or more vendor information fields. The overall structure of the Vendor-Specific Area when vendor information extensions are used is shown in Figure 257.

BOOTP Message Format 1 2 3 BOOTP Relay Agents (Forwarding Agents)