Table of Contents DOS

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 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.
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:
   • 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 normal.
   • 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 solutions:
     • 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 reply.
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.

code

Indicates a request or a reply

1

Request

2

Reply

HWtype

The type of hardware, for example:

1

Ethernet

6

IEEE 802 Networks

Refer to STD 2 - Assigned Internet Numbers for a complete list.

length

Hardware address length in bytes. Ethernet and token-ring both use 6, for example.

hops

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.

Seconds

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

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 99.130.83.99 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

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

4.17.1.2 OS/2

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

4.17.1.3 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)