Networking exercise

Before a device on a TCP/IP network can effectively communicate, it needs to know its IP address. While a conventional network host can read this information from its internal disk, some devices have no storage, and so do not have this luxury. They need help from another device on the network to provide them with an IP address and other information and/or software they need to become active IP hosts. This problem of getting a new machine up and running is commonly called bootstrapping, and to provide this capability to IP hosts, the TCP/IP Bootstrap Protocol (BOOTP) was created.

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”.

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.

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:

BOOTP Deals With the First Phase of Bootstrapping

It should be noted that even though the name of BOOTP implies that it defines everything needed for a storageless device to “boot”, this isn't really the case. As the BOOTP standard itself describes, “bootstrapping” generally requires two phases. In the first, the client is provided with an address and other parameters. In the second, the client downloads software, such as an operating system and drivers, that let it function on the network and perform whatever tasks it is charged with. BOOTP really only deals with the first of these phases: address assignment and configuration. The second is assumed to take place using a simple file transfer protocol like the Trivial File Transfer Protocol (TFTP).

Changes to BOOTP and the Development of DHCP

BOOTP was the TCP/IP host configuration of choice from the mid-1980s through the end of the 1990s. The vendor extensions introduced in RFC 1048 were popular, and over the years, additional vendor extensions were defined; RFC 1048 was replaced by RFCs 1084, 1395 and 1497 in succession. Some confusion also resulted over the years in how some sections of RFC 951 should be interpreted, and how certain features of BOOTP work.

RFC 1542, Clarifications and Extensions for the Bootstrap Protocol, was published in October 1993 to address this, and also made some slight changes to the protocol's operation. (RFC 1542 is actually a correction of the nearly-identical RFC 1532 that had some small errors in it.)

While BOOTP was obviously quite successful, it also had certain weaknesses of its own. One of the most important of these is lack of support for dynamic address assignment. The need for dynamic assignment became much more pronounced when the Internet really started to take off in the late 90s. This led directly to the development of the Dynamic Host Configuration Protocol (DHCP).

While DHCP replaced BOOTP as the TCP/IP host configuration protocol of choice, it would be inaccurate to say that BOOTP is “gone”. It is still used to this day in various networks. Furthermore, DHCP was based directly on BOOTP, and they share many attributes, including a common message format. BOOTP vendor extensions were used as the basis for DHCP options, which work in the same way but include extra capabilities. In fact, the successor to RFC 1497 is RFC 1533, which officially merges BOOTP vendor extensions and BOOTP options into the same standard.