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)

TCP/IP Bootstrap Protocol (BOOTP) 1 2 3 BOOTP Client/Server Messaging and Addressing

The TCP/IP protocol suite has been with us for over two decades, and the problem of how to automate the configuration of parameters on IP hosts has been around almost as long. Back in the early 1980s, networks were small and relatively simple. Automated host configuration wasn't considered an important capability so much because of the difficulty of manual configuration. It was needed because there is no other way to configure devices like diskless workstations.

As I discussed in the overview topic on host configuration, without a form of internal storage, a device must rely on someone or something to tell it “who it is” (its address) and how to function each time it is powered up. When a device like this is turned on, it is in a difficult position: it needs to use IP to communicate with another device that will tell it how to communicate using IP! This process, called bootstrapping or booting, comes from an analogy to a person “pulling himself up using his own bootstraps”. You've likely encountered this term before, if at no other time then at least when some tech support person has told you to “reboot” your computer.

The Reverse Address Resolution Protocol (RARP) was the first attempt to resolve this “bootstrap problem”. Created in 1984, RARP is a direct adaptation of the low-level Address Resolution Protocol (ARP) that binds IP addresses to link-layer hardware addresses. RARP is capable of providing a diskless device with its IP address, using a simple client/server exchange of a request and reply between a host and an RARP server.

The difficulty with RARP is that it has so many limitations. It operates at a fairly low level using hardware broadcasts, so it requires adjustments for different hardware types. An RARP server is also required on every physical network to respond to layer-two broadcasts. Each RARP server must have address assignments manually provided by an administrator. And perhaps worst of all, RARP only provides an IP address to a host and none of the other information a host may need. (I describe these issues in detail in the topic on RARP.)

RARP clearly wasn't sufficient for the host configuration needs of TCP/IP. To support both the needs of diskless hosts and other situations where the benefits of autoconfiguration were required, the Bootstrap Protocol (BOOTP) was created. BOOTP was standardized in RFC 951, published September 1985. This relatively straight-forward protocol was designed specifically to address the shortcomings of RARP:

• It is still based on a client/server exchange, but is implemented as a higher-layer software protocol, using UDP for message transport. It is not dependent on the particular hardware of the network like RARP.
  
  
• It supports sending additional configuration information to a client beyond just an IP address. This extra information can usually all be sent in one message for efficiency.
  
  
• It can handle having the client and server on different networks of an internetwork. This allows the administration of the server providing IP addresses to be more centralized, saving money as well as administrative time and hassle.

TCP/IP Bootstrap Protocol (BOOTP) 1 2 3 BOOTP Client/Server Messaging and Addressing