Table of Contents DOS
TCP/IP Tutorial and Technical Overview

4.17 BOOTstrap Protocol - BOOTP

BOOTP is a draft standard protocol. Its status is recommended. The BOOTP specifications can be found in RFC 951 - Bootstrap Protocol and RFC 1497 - BOOTP Vendor Information Extensions.

There are also updates to BOOTP that allow it to interoperate with DHCP (see Dynamic Host Configuration Protocol (DHCP)). These are described in RFC 1542 - Clarifications and Extensions for the Bootstrap Protocol which updates RFC 951 and RFC 1533 - DHCP Options and BOOTP Vendor Extensions, which obsoletes RFC 1497. These updates to BOOTP are proposed standards with a status of elective.

LANs make it possible to use diskless hosts as workstations, routers, terminal concentrators and so on. Diskless hosts require a mechanism to boot remotely over a network. The BOOTP protocol is used for remote booting over IP networks. It allows a minimum IP protocol stack with no configuration information, typically stored in ROM, to obtain enough information to begin the process of downloading the necessary boot code. BOOTP does not define how the downloading is done, but this process typically uses TFTP (see also Trivial File Transfer Protocol (TFTP)) as described in RFC 906 - Bootstrap loading using TFTP.

The BOOTP process involves the following steps:

  1. The client determines its own hardware address; this is normally in a ROM on the hardware.
  2. A BOOTP client sends its hardware address in a UDP datagram to the server. The full contents of this datagram are shown in Figure - BOOTP Message Format. If the client knows its IP address and/or the address of the server, it should use them, but in general BOOTP clients have no IP configuration data at all. If the client does not know its own IP address, it uses If the client does not know the server's IP address, it uses the limited broadcast address ( The UDP port number is 67.
  3. The server receives the datagram and looks up the hardware address of the client in its configuration file, which contains the client's IP address. The server fills in the remaining fields in the UDP datagram and returns it to the client using UDP port 68. One of three methods may be used to do this:
  4. When it receives the reply, the BOOTP client will record its own IP address (allowing it to respond to ARP requests) and begin the bootstrap process.

Figure: BOOTP Message Format

Indicates a request or a reply
The type of hardware, for example:
IEEE 802 Networks
Refer to STD 2 - Assigned Internet Numbers for a complete list.
Hardware address length in bytes. Ethernet and token-ring both use 6, for example.
The client sets this to 0. It is incremented by a router which relays the request to another server and is used to identify loops. RFC 951 suggests that a value of 3 indicates a loop.
Transaction ID
A random number used to match this boot request with the response it generates.
Set by the client. It is the elapsed time in seconds since the client started its boot process.
Flags Field
The most significant bit of the flags field is used as broadcast flag. All other bits must be set to zero; they are reserved for future use. Normally, BOOTP servers attempt to deliver BOOTREPLY messages directly to a client using unicast delivery. The destination address in the IP header is set to the BOOTP your IP address and the MAC address is set to the BOOTP client hardware address. If a host is unable to receive a unicast IP datagram until it knows its IP address, then this broadcast bit must be set to indicate the server that the BOOTREPLY must be sent as an IP and MAC broadcast. Otherwise this bit must be set to zero.
Client IP address
Set by the client. Either its known IP address, or
Your IP Address
Set by the server if the Client IP address field was
Server IP address
Set by the server.
Router IP address
Set by the forwarding router if BOOTP forwarding is being used.
Client hardware address
Set by the client and used by the server to identify which registered client is booting.
Server host name
Optional server host name terminated by X'00'.
Boot file name
The client either leaves this null or specifies a generic name, such as ``router'' indicating the type of boot file to be used. The server returns the fully qualified filename of a boot file suitable for the client. The value is terminated by terminated by X'00'.
Vendor-specific area
Optional vendor-specific area. It is recommended that clients always fill the first four bytes with a ``magic cookie''. If a vendor-specific ``magic cookie'' is not used the client should use followed by an end tag (255) and set the remaining bytes to zero. Please see RFC 1533 for details.

One restriction with this scheme is the use of the limited broadcast address for BOOTP requests; it requires that the server is on the same subnet as the recipient. BOOTP forwarding is a mechanism for routers to forward BOOTP requests. It is a configuration option available on some routers, including the IBM 6611 and 2210 Network Processors. See RFC 951 for more information about BOOTP forwarding.

Once the BOOTP client has processed the reply, it may proceed with the transfer of the boot file and execute the full boot process. See RFC 906 for the specification of how this is done with TFTP. The full boot process will replace the minimum IP protocol stack used by BOOTP and TFTP by a normal IP protocol stack transferred as part of the boot file and containing the correct customization for the client.

4.17.1 Implementations AIX/6000

The BOOTP server function is implemented in the bootpd daemon. This daemon is a subserver controlled by the inetd superdaemon. Bootpd searches the /etc/bootptab file for hardware addresses. For details on the file format, please refer to the online InfoExplorer.

The BOOTP client function is used in conjunction with TFTP to load executable modules (X stations, diskless workstations) or configuration files (intelligent hubs, routers) automatically at system startup.

Note: BOOTP requests from a BOOTP client are not able to pass an IP router if not explicitly customized. OS/2

Both client and server functions are provided. DOS

TCP/IP for DOS provides the BOOTP client function. The BOOTP command initiates this client function which can be very useful in establishing SLIP connections (since BOOTP can be used to assign your IP address, you do not need to know the IP address before the connection is made).

Table of Contents Dynamic Host Configuration Protocol (DHCP)