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 Book is Here... and Now On Sale!

Read offline with no ads or diagram watermarks!
The TCP/IP Guide

Custom Search







Table Of Contents  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)

Previous Topic/Section
TCP/IP Bootstrap Protocol (BOOTP)
Previous Page
Pages in Current Topic/Section
1
23
Next Page
BOOTP Client/Server Messaging and Addressing
Next Topic/Section

BOOTP Overview, History and Standards
(Page 1 of 3)

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.

BOOTP: Correcting the Weaknesses of RARP

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.

Previous Topic/Section
TCP/IP Bootstrap Protocol (BOOTP)
Previous Page
Pages in Current Topic/Section
1
23
Next Page
BOOTP Client/Server Messaging and Addressing
Next Topic/Section

If you find The TCP/IP Guide useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider purchasing a download license of The TCP/IP Guide. Thanks for your support!
Donate $2
Donate $5
Donate $10
Donate $20
Donate $30
Donate: $



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.