Table of Contents DOS
TCP/IP Tutorial and Technical Overview
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
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:
- The client determines its own hardware address; this is normally in a ROM
on the hardware.
- 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 0.0.0.0. If the client does
not know the server's IP address, it uses the limited broadcast address
(255.255.255.255). The UDP port number is 67.
- 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:
- If the client knew its own IP address (it was included in the BOOTP
request), then the server returns the datagram directly to this address. It is
likely that the ARP cache in the server's protocol stack will not know the
hardware address matching the IP address. ARP will be used to determine it as
- If the client did not know its own IP address (it 0.0.0.0 in the BOOTP
request), then the server must concern itself with its own ARP cache. ARP on
the server cannot be used to find the hardware address of the client because
the client does not know its IP address and so cannot reply to an ARP request.
This is called the ``chicken and egg'' problem. There are two possible
- If the server has a mechanism for directly updating its own ARP cache
without using ARP itself, it does so and then sends the datagram directly.
- If the server cannot update its own ARP cache, it must send a broadcast
- 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:
Refer to STD 2 - Assigned Internet Numbers for a complete list.
- IEEE 802 Networks
- Hardware address length in bytes. Ethernet and token-ring both use 6, for
- 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.
- A random number used to match this boot request with the response it
- Set by the client. It is the elapsed time in seconds since the client
started its boot process.
- 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 0.0.0.0.
Your IP Address
- Set by the server if the Client IP address field was 0.0.0.0.
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'.
- 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 188.8.131.52 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.
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
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.
Both client and server functions are provided.
- Server function: The BOOTPD command starts the server. When the BOOTP
server receives the hardware address it looks for a match in the /ETC/BOOTPTAB
file. Upon finding a matching hardware address, the server sends back (in the
UDP packet) an internet address, a subnet mask, and other information to the
client. Please refer to IBM TCP/IP Version 2.0 for OS/2: User's Guide
for more details about the /ETC/BOOTTAB file. BOOTP broadcast packets are used
for transfer and reside only on the local network. They do not pass through a
router to another network.
- Client function: the BOOTP command starts the client. The client will
execute and print out the response from the server as soon as the connection is
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)