What Is BOOTP?

BOOTP stands for the Bootstrap or BOOT Protocol. The standard method for booting a computer is to locate a boot block on a local drive and then go from there, so why are we discussing booting in a book that is supposed to be about networks? During the 1980s, BOOTP was developed to allow diskless workstations to boot by downloading the operating system from another network node. Many operating systems at that time used this protocol because it allowed the use of cheaper desktop workstations on the networklong before PCs became a standard desktop item. At the time, the X-Windows workstation was popular in Unix and OpenVMS networks. BOOTP was an economical way to provide an X-Windows desktop with an operating system without the need to equip the machine with disk drives and other devices not necessary for a simple client. Other types of network clients adopted the BOOTP protocol, allowing network devices to also be suitably configured by use of the protocol.

Note

The BOOTP protocol was originally defined in RFC 951, "Bootstrap Protocol," in 1985, and further details were provided by RFC 1542, "Clarifications and Extensions for the Bootstrap Protocol," in 1993. That RFC was made obsolete by several other RFCs, of which the most current is the proposed standard of the same name (RFC 2132). Another important proposed standard is RFC 1534, "Interoperation Between DHCP and BOOTP."

Downloading an operating system is only one of the functions performed by BOOTP. In addition, the diskless workstation (or other client) can also obtain network addressing information. This is because the lowest-level BOOTP client is presumed to be "diskless." It has no method to store configurable IP addressing information between power cycles.

The BOOTP protocol is not complex. Indeed, it is a simple protocol that is small and easy to implement in programmable read-only memory (PROM) chips. The following are some important features of BOOTP:

• A simple request/reply mechanism is used. The same packet format is used for both requests and replies.

• The UDP protocol is used to carry messages (ports 67 and 68, the same as are used by DHCP).

• Using relay agents, BOOTP exchanges can occur across routers.

• BOOTP can supply the client with an IP address, a subnet mask, and a default gateway. A BOOTP server can also give the client name of a trivial FTP server (TFTP) and a filename that can be used to download an operating system. This TFTP server is especially important for diskless workstations, as well as network devices that need to download an operating system. The trivial FTP server, which is a stripped-down simple version of FTP, is covered in Chapter 25, "Basic TCP/IP Services and Applications."

Another protocol, the Reverse Address Resolution Protocol (RARP), operates at the second layer of the OSI network model and is also capable of providing an IP address to another node that is booting on the network. However, RARP is very limited. For more information about RARP, see Chapter 24, "Overview of the TCP/IP Protocol Suite."

Format of the BOOTP Packet

The client and server share a common packet format. This packet is passed to UDP (the User Datagram Protocol) and encapsulated inside a UDP packet. The UDP and IP headers are added, and the information is finally passed to the Data Link and Physical layers for transmission on the network medium.

The IP and UDP protocols are also discussed in greater detail in Chapter 24.

The fields of the BOOTP packet are used for the following purposes:

• Opcode This 1-byte field has a value of either zero or one. If set to a value of one, the packet is a request from a client to a BOOTP server (or a DHCP server, as explained later). If the value is zero, the packet is a reply from a server to the client.

• Hardware Type Values in this 1-byte field are used to designate different kinds of hardware, different computer types, or network device types, for example. A value of one in this field indicates that the underlying hardware type of the network is 10Mb Ethernet, whereas the value of 32 is used for the emerging technology known as InfiniBand. You can find the full list of values at www.iana.org/assignments/arp-parameters.

• Hardware Address Length This 1-byte field indicates the number of bytes that the client hardware address field contains. For Ethernet, this value is six because it takes 6 bytes to represent the 48-bit Media Access Control (MAC) address used by Ethernet network cards.

• Hop Count This 1-byte field is always set to zero by the client, though the BOOTP server uses this field when relaying BOOTP requests across routers.

• Transaction ID This is a 4-byte field that is a unique 32-bit integer the client sets so that it can match up replies from the server to the requests the client has sent.

• Seconds This 2-byte field is expressed in seconds and is filled in by the client with a value indicating the time that has elapsed since the client started the boot process. This value can be used by secondary servers to recognize that the client's primary server is not responding. In that case, a secondary BOOTP server can make an attempt to satisfy the request.

• Flags In the original specifications for BOOTP, this 2-byte field was not used. However, in RFC 1542 this field was set aside to store flag bits. Only one has been defined so far. The most significant bit in this field is used as a Broadcast flag. The remaining bits are not yet defined and should be set to zeros.

• Client IP Address (ciaddr) If the client already knows its own address (which is explained shortly), it will fill in that address in this 4-byte field. In most cases the client does not know its own IP address (because that's one of the main things BOOTP is used to supply to the client), and in cases like these the value for this field should be zero.

• Your IP Address (yiaddr) This field is used by the BOOTP server to supply an IP address to a client requesting one. It also is a 4-byte field, the number of bytes needed to store an IP address. Although the client can fill in the ciaddr field with a requested address, this field contains the address the DHCP server returns to the client to use.

• Server IP Address (siaddr) The BOOTP server fills in this field, usually placing its own address here.

• Gateway IP Address (giaddr) If a BOOTP proxy server is being used, the address in this 4-byte field is the address of the router or other device performing the proxy function. Proxy BOOTP services are discussed later in this chapter. Note that this is not the address the client should use as a default gateway for TCP/IP configuration (though it could be the same). This field is used only to relay BOOTP requests across routers to and from the actual BOOTP server. The default gateway information is supplied in BOOTP options, described later in this chapter (see the section "Enabling the DHCP Relay Agent").

• Client's Hardware Address (chaddr) If the client already knows its own IP address, it will place the IP address into this 4-byte field. The client must fill in this required field because the typical BOOTP server uses it in an index of values it keeps track of for its clients.

• Server Hostname (sname) This field can be up to 64 bytes in length and contains a null-terminated ASCII string of characters that represent the server's hostname on the network. This hostname can be a simple hostname or a fully qualified domain name (FQDN). This is an optional field.

• Boot Filename (file) This field can be up to 128 characters in length and is used to supply the client with the filename it can download and use to boot. The value here is also a null-terminated string and includes the full path the client needs in order to locate the file.

• Vendor-Specific Area These 64 bytes are set aside to store vendor-specific optional information. The items are listed in Table 29.1 in the section "BOOTP Vendor-Specific Information Options." The first four octets in this field will be a "magic cookie." The last octet is the "End" tag, the value 255.

The client's hardware address (technically called the Media Access Control address, or MAC address) that is placed in the BOOTP packet is the same hardware address that will be found in the Ethernet frame that delivers the packet. However, after the Ethernet frame is received, the lower-level header information (such as the client's hardware address) is stripped off before the remaining packet is passed up through the IP and UDP layers. At the point where the BOOTP protocol begins to examine the packet, the Ethernet frame header information is not available in most TCP/IP stacks. For this reason, the hardware address is duplicated inside the BOOTP packet. Remember that the RARP protocol is a link-layer protocol, so it can retrieve the client's hardware address from the Ethernet frame, something most implementations of BOOTP cannot do.

Note

For those who are interested in the nitty-gritty details, the packets discussed here are transmitted on the wire in the order shown in the figures in this chapter. Additionally, the individual bytes are sent with the leftmost bit being the most significant. For multi-octet values, the most significant octet is transmitted first. This information might help you when diagnosing problems on the network using a LAN analyzer or other methods to intercept and interpret network packets.

The BOOTP Request/Reply Mechanism

Because it is usually implemented in a read-only memory (ROM) chip, the BOOTP protocol client is a simple, concise bit of code. The exchange of UDP messages between the client and the BOOTP server consists of a series of requests and replies. The same packet format is used for both types of messages with an Opcode field used to indicate whether the message is a request from the client or a reply from the server.

The following basic steps are involved in obtaining information from a BOOTP server:

1.	The client sends a broadcast message at the link-layer level because the client at this point is unaware of its own IP address or that of any BOOTP server that might be on the network. In the IP header information for the request, the client usually sets the source IP Address field to 0.0.0.0 and the destination address to 255.255.255.255. Because this is a UDP packet being sent through IP, the client sets the destination UDP port number to 68 (the BOOTP server port) so that a listening server will know to intercept the packet. The Transaction ID field that the client places in the BOOTP request packet is used by clients to sort out which replies are meant for them. The first 4 bytes of the vendor-specific information area should be set to a magic cookie. Note A magic cookie is a method used by BOOTP to tell the server what kind of format to use when creating a reply for a client's request. The magic cookie usually is the value 99.130.83.99 but can be a vendor-supplied value. The magic cookie is usually used to indicate that the vendor-specific area contains information for the server to examine. The remaining information in the 64-byte vendor-specific information is defined as a series of tags followed by a length field and then, in most cases, a variable-length field of information.
2.	If the broadcast flag is set, the server next broadcasts a reply that contains the client's IP address, the server's own IP address, and other requested information.
3.	If the broadcast flag is not set, the server can send a unicast address using the client's IP address to the address supplied by the client. The server should always check the Client IP Address (from Client) field set by the client to be sure it is not the default value of 0.0.0.0. If it is not, then, depending on the implementation, the server will set the Client IP Address (from Server) field to the same value and send a directed (unicast) packet back to the client. However, note that this can vary from one implementation to the next, and the server might decide to override the client's requested IP address and substitute another.
4.	Another possibility that occurs when using a router or other host to act as a proxy relay agent is that the Default-Gateway server field will be filled in. In this case, the server knows to use this field to send a directed (unicast) packet to the router or other device that is relaying the message instead of trying to broadcast or send the packet directly to the client using the client's address.

In step 2, even though the client might be capable of determining what it thinks its own IP address should beby saving it to a disk file in the case of a workstation that does have that capability, for examplethe server can choose to return a different IP address to the client. In that case, the client should stop using its previous IP address and accept the new one from the server. There is some disagreement in the literature about this situation, and you might find that it varies from one implementation to another. For example, some vendors allow the client to specify the address it wants to use, ignoring the one supplied by the server. In this type of situation, the client is usually using the BOOTP server to obtain other configuration information, such as a boot filename or vendor-specific items, when it already knows what its own IP address should be.

BOOTP Vendor-Specific Information Options

In addition to supplying a network node with an IP address and a boot filename (and the server from which the file can be retrieved), 64 bytes are reserved in the BOOTP Reply/Request packet that can be used to supply additional configuration information to the client. The client can also use the options fields to request certain information from the server.

The options used by BOOTP are a subset of those now incorporated into DHCP. Those listed in this section apply, therefore, to both BOOTP and DHCP. These options are defined (and discussed in greater detail) in RFC 2132, "DHCP Options and BOOTP Vendor Extensions."

The format for data in the options field is standard:

• Option Code This 1-byte field contains a code that identifies the particular option. The value of 0 is used for padding and the value of 255 is used as an end marker. Note that Option Code values from 128 to 254 are reserved for site-specific options.

• Length Octet This 1-byte value specifies the length of the option data to follow. This length does not include the Option Code or the Length Octets.

• Variable-length optional configuration data This data depends on what kind of information the option supplies.

As noted earlier, the value of 255 marks the end of an options list in the packet.

RFC 2132 defines a large number of options that can be used. Table 28.1 lists those that apply to both BOOTP and DHCP.

Table 28.1. Definition of BOOTP Vendor Extension Opcodes

Opcode	Name	Description
0	Pad	Used to align following entries on a word boundary.
255	End	Marks end of options.
1	Subnet Mask	Subnet mask for client to use.
2	Time Offset	UTC time offset value.
3	Router	List of IP address of routers on the client's subnet.
4	Time Server	List of time servers.
5	Name Server	List of IEN 116 name servers.
6	Domain Name Server	List of DNS servers (RFC 1035).
7	Log Server	List of MIT-LCS UDP log servers.
8	Cookie Server	List of cookie servers (RFC 865).
9	LPR Server	List of LPR printers (RFC 1179).
10	Impress Server	List of Imagen Impress servers.
11	Resource Location Server	List of resource location servers (RFC 887).
12	Host Name	Client's hostname.
13	Boot File Size	Size in 512-byte blocks of the default boot image file for the client.
14	Merit Dump File	Path of file that client can use for a memory dump.
15	Domain Name	Name of DNS domain of client.
16	Swap Server	IP address of client's swap server.
17	Root Path	Pathname for client's root disk.
18	Extensions Path	Specifies a file that contains information similar to this vendor-specific information area.
19	IP Forwarding	0 = Disable IP forwarding, 1 = enable IP forwarding on client.
20	Non-Local Source Routing	0 = Disallow forwarding, 1 = allow forwarding of nonlocal source-routed datagrams.
21	Policy Filter	A list of IP addresses and subnet masks to use to filter incoming source routes.
22	Maximum Datagram	The maximum size datagram Reassembly Size that the client should be able to reassemble.
23	Default IP TTL	Default value client should set the TTL field for outgoing datagrams.
24	Path MTU Aging Timeout	Seconds to use when aging path MTU values (as discovered via RFC 1191).
25	Path MTU Plateau Table	Table of sizes to use for path MTU discovery (RFC 1191).
26	Interface MTU	MTU for this interface (per interface).
27	All Subnets	0 = Subnets can have smaller MTU, 1 = Subnets have same MTU.
28	Broadcast Address	Broadcast address for client to use.
29	Perform Mask Discovery	0 = Do not perform mask discovery, 1 = Perform mask discovery using ICMP.
30	Mask Supplier	0 = Client should not respond to subnet mask request using ICMP, 1 = Client should respond.
31	Perform Router Discovery	0 = Do not use router discovery, 1 = Use router discovery (RFC 1256).
32	Router Solicitation Address	Address for router solicitation requests.
33	Static Route	List of static routes (destination address + router address) to be inserted into client's routing cache.
34	Trailer Encapsulation	0 = Do not use trailers, 1 = Attempt to use trailers.
35	ARP Cache Timeout	Seconds for ARP cache timeout.
36	Ethernet Encapsulation	0 = Use Ethernet Version 2 (RFC 894), 1 = Use IEEE 802.3 (RFC 1042).
37	TCP Default TTL	Default TTL for client to use when sending out TCP segments.
38	TCP Keepalive Interval	Seconds to wait before sending TCP keepalive messages. Zero indicates no messages to be sent, unless requested by application.
39	TCP Keepalive Garbage	0 = Do not send octet of garbage for compatibility with older versions, 1 = Send garbage octet.
40	NIS Service Domain	Network Information System (NIS) domain of client.
41	NIS Servers	List of IP address of NIS servers.
42	NTP Servers	List of IP addresses of NTP time servers.
43	Vendor Specific Information	Vendor-specific information, as defined by vendor.
44	NetBIOS over TCP/IP	List of NBNS servers (RFC Name Server 1001/1002).
45	NetBIOS over TCP/IP Datagram Distribution Servers	List of NBDD Server (RFC 1001/1002).
46	NetBIOS over TCP/IP	NetBIOS node type (RFC 1001/Node Type 1002).
47	NetBIOS over TCP/IP Scope	NBT Scope parameter (RFC 1001/1002).
48	X Window System Font Server	List of X Window System Font servers.
49	X Window System Display Manager	List of IP addresses of systems running the X Window System Display Manager.
64	NIS+ Domain	Name of NIS+ domain.
65	NIS+ Server	List of IP addresses of NIS+ servers.
68	Mobile IP Home Agent	IP addresses of mobile IP home agents.
69	SMTP Server	List of Simple Mail Transport Protocol (SMTP) servers.
70	POP3 Server	List of POP3 servers.
71	NNTP Server	List of Network News Transfer Protocol (NNTP) servers.
72	Default WWW Server	List of WWW servers.
73	Default Finger Server	List of Finger servers.
74	Default IRC Server	List of default Internet Relay Chat (IRC) servers.
75	StreetTalk Server	List of StreetTalk servers.
76	StreetTalk Directory	List of STDA servers. Assistance

Downloading an Operating System

After a client has obtained the data needed to configure itself for network access, it can use the boot file information supplied by the BOOTP server to locate and download an operating system. The BOOTP protocol only gives the name and path that can be used to locate the file. BOOTP does not perform any other functions to assist the client in obtaining a copy of the file. Instead, the client uses the Trivial File Transfer Protocol (TFTP) to retrieve the file.

The Trivial File Transfer Protocol is discussed more fully in Chapter 25.

TFTP, like BOOTP, is a simple protocol to implement, making it easy to create client code that can be stored on a chip or embedded in a device's firmware. There is no exchange of authentication information, such as a username and password, between the client and the TFTP server. Instead, the client simply requests a copy of the file and it is sent to the client on a packet-by-packet basis with the client acknowledging each packet. This start-stop, single-packet exchange method is slower than that which could be accomplished using TCP, but it is not intended for everyday file transfers. TFTP is more than adequate for downloading operating-system code during the boot process.

After the file has been downloaded to the client, it is executed and the client boots to become a full-fledged member of the network.