Computer systems require an IP address to be able to com­mu­ni­cate with one another in networks such as the Internet. In principle, this can be assigned manually, but most devices pick up their address au­to­mat­i­cal­ly nowadays. The basis for this is the com­mu­ni­ca­tion protocol DHCP, which helps systems seeking a con­nec­tion to get the in­for­ma­tion they need. In the early days of computers, networks etc. the bootstrap protocol, which is also known as BOOTP, still assumed the function of address manager.

What is BOOTP (the bootstrap protocol)?

In September 1985, the Stanford Uni­ver­si­ty Network GroupRFC 951 BOOTP in RFC 951 – Bootstrap Protocol. This com­mu­ni­ca­tions protocol, which was developed in co­op­er­a­tion with a team from Sun Mi­crosys­tems, made it possible to obtain in­for­ma­tion such as the gateway, boot server addresses, the directory of boot files (required for loading the operating system), as well as the IP address from the terminals and work­sta­tions without a hard drive for the first time. It replaced the reverse address res­o­lu­tion protocol (RRP) used up to then, which ex­clu­sive­ly supplies network addresses and could only be used in sub-nets.

The bootstrap protocol is part of the Internet protocol family and works – as do many other protocols of the stack – according to the client-server model, which means the exchange of messages to transmit the network in­for­ma­tion takes place between a BOOTP client and the BOOTP server. The minimal, con­nec­tion­less User Datagram Protocol (UDP) (port 67 and 68) is provided as the protocol for the transport of the relevant data packages. Compared to TCP, not only is this less complex, but in contrast to the standard protocol for data transport, it also supports broad­cast­ing. As the client does not know its own address nor that of the BOOTP server when making the con­nec­tion, this messaging method in which all network par­tic­i­pants are contacted is the only solution for au­to­mat­i­cal­ly obtaining the address.

The exchange of network in­for­ma­tion therefore works via BOOTP.

The address al­lo­ca­tion via BOOTP is based on a simple two-step message exchange between client and server, in which the client component is the initiator. As the client does not know its own IP address nor that of the BOOTP server at the start, it sends a general request (“BOOTRE­QUEST”) to the broadcast group address 255.255.255.255. The server, listening on UDP port 67, receives and processes this request by al­lo­cat­ing a suitable IP address to the MAC address of the client system. Then the response (“BOOTREPLY”) including further network in­for­ma­tion is sent back to the client via broadcast, which can receive the operating system via the network as a result.

Note

If the client already knows the address of the BOOTP server, it can also send this request directly via unicast con­nec­tion.

This is how the design of the messages looks, which the client and server send out when com­mu­ni­cat­ing via bootstrap protocol:

Image: Design of BOOTP messages
BOOTP protocol messages contain a range of in­for­ma­tion fields, some of which are optional, however.

Each BOOTP message begins with the 8-bit-long op field, which defines the type of operation or the message. For requests through the client, the value 1 is set at this point (for BOOTRE­QUEST), while the responses from the server display the value 2 (for BOOTREPLY). 8 bits follow, which mark the type (“htype”) as well as the length of the hardware address (“hlen”). The “hops” field, which is also 8 bits long, gives the number of interim stations which the package passes through on the way to the recipient. For client requests, the value is always 0.

The next block includes a random 32-bit long trans­ac­tion ID, which is generated by the client and is later also used in the response from the server so that the client can allocate this uniquely. The client also fills out the “secs” (16 bits), which gives the seconds that have passed since the boot attempt by the client. The com­ple­tion of the in­tro­duc­to­ry in­for­ma­tion forms another 16-bit field, which remains entirely empty. The further entries of the BOOTP package comprise the actual network in­for­ma­tion, which is explained in more detail in the following listing:

  • IP address of the client (ciaddr): The label “ciaddr” (client ip address) dis­tin­guish­es the 32-bit field in which the client enters its own IP address, provided this is already known. If this is not the case, the field contains the value 0.
  • IP address of the client (yiaddr): The field “yiaddr”, (your ip address) is reserved for the IP address of the client. However, in contrast to the pre­vi­ous­ly mentioned section of the package, this 32-bit field is filled out by the server, in case the client didn't know its IP address at the time of creating the network request.
  • IP address of the server (siaddr): In the 32-bit sequence “siaddr”, (server ip address), the BOOTP server gives the client its own IP address.
  • IP address of the gateway (giaddr): If a gateway (e.g. a router) is in­cor­po­rat­ed in the com­mu­ni­ca­tion process, this address is entered in the “giaddr” field (gateway ip address).
  • Hardware address of the client (chaddr): The hardware address (128-bit) is part of the mandatory in­for­ma­tion of the client when ex­chang­ing bootstrap protocol messages. Without this ID, also known as the device or MAC address, the server cannot allocate either the correct address or the right network pa­ra­me­ters to the client.
  • Host name of the server (sname): Op­tion­al­ly, the server can also be given its host names in the BOOTP response. A 512-bit field is available for this, in which it can add a cor­re­spond­ing zero-ter­mi­nat­ed character string (a zero character marks the end of the string).
  • Name of the boot file: Another option is to designate a specific boot file, which the client requires to start the operating system on the terminal or work­sta­tion in question. This field also provides a null-ter­mi­nat­ed string, which rep­re­sents the complete directory path of the file in this case. The sequence of char­ac­ters can be up to 1024 bits long. The client's request contains either the value 0 or a generic name.
  • Man­u­fac­tur­er-specific in­for­ma­tion (vend): The potential com­ple­tion of the BOOTP protocol message forms man­u­fac­tur­er-specific in­for­ma­tion, which is not covered by the protocol. This may be the des­ig­na­tion of special hardware types and serial numbers, for example. Fur­ther­more, this 512-bit-long in­for­ma­tion field can be reserved for a third bootstrap or kernel process.

Overall, the BOOTP messages may also be up to 2,400 bits long (300 bytes). The complete UDP/IP datagram, including in­te­grat­ed bootstrap protocol request or response is designed as follows:

Image: UDP/IP datagram with encapsulated BOOTP message
The Internet protocol (ad­dress­ing) and the UDP protocol (transport) form the basis for the BOOTP message exchange.

BOOTP vs. DHCP: why the bootstrap protocol is no longer used today

For terminal clients and diskless work­sta­tions, BOOTP was the perfect solution to obtain a personal IP address in the network required, and to reference the operating system in this way. The fact that the address reference could be carried out by the com­mu­ni­ca­tion protocol at the same time as the boot process was practical as well as straight­for­ward for sta­tion­ary computers, which were used in networks of a man­age­able size . For example, it was rarely a problem that the ad­min­is­tra­tor had to manually configure the network in­for­ma­tion tables of the BOOTP server.

However, as networks became ever larger and computers in­creas­ing­ly in­de­pen­dent, and – due to the de­vel­op­ment of portable devices – more mobile too, it was evident that the lack of op­por­tu­ni­ty for au­toma­tion of the con­fig­u­ra­tion process was negative. There was a re­quire­ment for a new protocol. With the dynamic host con­fig­u­ra­tion protocol (DHCP) this came about in 1993 (final spec­i­fi­ca­tion in RFC 2131). DHCP is in fact largely based on the structure of the bootstrap protocol, but it com­ple­ments this due to various ad­di­tion­al con­fig­u­ra­tion options, and offers the op­por­tu­ni­ty to assign reusable network addresses to clients seeking con­nec­tion. The al­lo­ca­tion of addressed in­for­ma­tion with DHCP also works during current system operation – it is not necessary to restart, as was the case with BOOTP.

“BOOTP vs. DHCP” – the most important dif­fer­ences are given below:

  BOOTP DHCP
Auto-con­fig­u­ra­tion Al­lo­ca­tion of IP addresses requires manual con­fig­u­ra­tion Supports automatic al­lo­ca­tion and ac­qui­si­tion of IP addresses (as well as manual con­fig­u­ra­tion)
Temporary IP addresses Not possible Possible for a limited period
Supports mobile devices IP con­fig­u­ra­tion and access to network in­for­ma­tion are not possible Supports the mobility of network clients
Error oc­cur­rence Very prone to errors due to manual con­fig­u­ra­tion Prac­ti­cal­ly immune to errors thanks to automated con­fig­u­ra­tion of the network com­po­nents
System re­quire­ments None Requires a disk to store and pass on in­for­ma­tion

Thanks to the various op­ti­miza­tions, DHCP has quickly become the standard protocol for IP man­age­ment in networks, while the BOOTP protocol is now of only his­tor­i­cal value. As DHCP supports the bootstrap protocol, in principle, DHCP servers can also respond to any requests made by a BOOTP client.

Go to Main Menu