[Chapter 3] 3.6 Bootstrap Protocol

3.6 Bootstrap Protocol

Bootstrap Protocol (BOOTP) is defined in RFCs 951 and 1532. The RFCs describe BOOTP as an alternative to RARP, and when BOOTP is used RARP is not needed. BOOTP, however, is a more comprehensive configuration protocol than RARP. It provides much more configuration information and has the potential to offer still more. The original specification allowed vendor extensions as a vehicle for the protocol's evolution. RFC 1048 first formalized the definition of these extensions, which have been updated over time and are currently defined in RFC 2132. BOOTP and its extensions became the basis for the Dynamic Host Configuration Protocol (DHCP). (More on DHCP later.)

The BOOTP client broadcasts a single packet called a BOOTREQUEST packet that contains, at a minimum, the client's physical network address. The client sends the broadcast using the address 255.255.255.255, which is a special address called the limited broadcast address . [14] The client waits for a response from the server. If a response is not received within a specified time interval, the client retransmits the request. BOOTP uses UDP as a transport protocol and, unlike RARP, it does not require any special Network Access Layer protocols.

[14] This address is useful because, unlike the normal broadcast address, it doesn't require the system to know the address of the network it is on.

The server responds to the client's request with a BOOTREPLY packet. BOOTP uses two different well-known port numbers. UDP port number 67 is used for the server and UDP port number 68 is used for the client. This is very unusual. Most software uses a well-known port on the server side and a randomly generated port on the client side. [15] The random port number ensures that each pair of source/destination ports identifies a unique path for exchanging information. A BOOTP client, however, is still in the process of booting. It may not know its IP address. Even if the client generates a source port for the BOOTREQUEST packet, a server response that is addressed to that port and the client's IP address won't be read by a client that doesn't recognize the address. Therefore, BOOTP sends the response to a specific port on all hosts. A broadcast sent to UDP port 68 is read by all hosts, even by a system that doesn't know its specific address. The system then determines if it is the intended recipient by checking the physical network address embedded in the response.

[15] How and why random source port numbers are used is described in Chapter 1 .

The server fills in all of the fields in the packet for which it has data. BOOTP can provide every essential TCP/IP configuration value. Chapter 9 provides a tutorial on setting up a BOOTP server, as well as a complete list of all of the configuration parameters that BOOTP can provide. In the next section we look at DHCP, which is based on BOOTP.

3.6.1 Dynamic Host Configuration Protocol

Dynamic Host Configuration Protocol (DHCP) is defined in RFCs 2131 and 2132. It's designed to be compatible with BOOTP. RFC 1534 outlines interactions between BOOTP clients and DHCP servers, and between DHCP clients and BOOTP servers. But interoperability problems are possible; many network administrators limit DHCP servers to DHCP clients. That's not necessary. See Chapter 9 and Appendix D, A dhcpd Reference for information on supporting BOOTP clients with DHCP servers.

DHCP uses the same UDP ports, 67 and 68, as BOOTP and the same BOOTREQUEST and BOOTREPLY packet format. But DHCP is more then just an update of BOOTP. The new protocol expands the function of BOOTP in two areas:

The configuration parameters provided by a DHCP server include everything defined in the Requirements for Internet Hosts RFC. DHCP provides a client with a complete set of TCP/IP configuration values.
DHCP permits automated allocation of IP addresses.

DHCP uses the portion of the BOOTP packet originally set aside for vendor extensions to indicate the DHCP packet type and to carry a complete set of configuration information. DHCP calls the values in this part of the packet options instead of vendor extensions . This is a more accurate description because DHCP defines how the options are used and does not leave their definition up to the vendors. To handle the full set of configuration values from the Requirements for Internet Hosts RFC, the Options field is expanded to 312 bytes from the original 64 bytes of the BOOTP Vendor Extensions field.

You don't usually need to use this full set of configuration values. Don't get me wrong. The parameters are needed for a complete TCP/IP configuration. It's just that you don't need to define values for them. Default values are provided in most TCP/IP implementations, and the defaults only need to be changed in special circumstances. Frankly, you don't need most of the parameters defined by BOOTP, let alone any additional parameters. The expanded configuration parameters of DHCP make it a more complete protocol than BOOTP, but they are of only marginal value.

For most network administrators, automatic allocation of IP addresses is a more interesting feature. DHCP allows addresses to be assigned in three ways:

Manual allocation: The network administrator keeps complete control over addresses by specifically assigning them to clients. This is exactly the same way that addresses are handled under BOOTP.
Automatic allocation: The DHCP server permanently assigns an address from a pool of addresses. The administrator is not involved in the details of assigning a client an address.
Dynamic allocation: The server assigns an address to a DHCP client for a limited period of time. The limited life of the address is called a lease. The client can return the address to the server at any time, but must request an extension from the server to retain the address longer than the time permitted. The server automatically reclaims the address after the lease expires if the client has not requested an extension.

Dynamic allocation is useful in a large distributed network where many systems are being added and deleted. Unused addresses are returned to the pool of addresses without relying on users or system administrators to take action to return them. Addresses are only used when and where they're needed. Dynamic allocation allows a network to make the maximum use of a limited set of addresses. It is particularly well-suited to mobile systems that move from subnet to subnet and therefore must be constantly reassigned addresses appropriate for their current network location.

Dynamic address allocation does not work for every system. Name servers, email servers, login hosts and other shared systems are always online, and they are not mobile. These systems are accessed by name, so a shared system's domain name must resolve to the correct address. Shared systems are manually allocated permanent, fixed addresses.

Dynamic address assignment has major repercussions for DNS. DNS is required to map hostnames to IP addresses. It cannot perform this job if IP addresses are constantly changing and DNS is not informed of the changes. To make dynamic address assignment work for all types of systems, we need a new DNS that can be dynamically updated by the DHCP server. The IETF is currently working on a standard for Dynamic DNS . When fully operational, it will help make dynamic addresses available to systems that provide services and to those that use them.

Given the nature of dynamic addressing, most sites assign permanent fixed addresses to shared servers. This happens through traditional system administration and is not handled by DHCP. In effect, the administrator of the shared server is given an address and puts that address in the shared server's configuration. Using DHCP for some systems doesn't mean it must be used for all systems.

Many DHCP servers can support BOOTP clients. However, a DHCP client is needed to take full advantage of the services offered by DHCP. BOOTP clients do not understand dynamic address leases. They do not know that an address can time out and that it must be renewed. BOOTP clients must be manually or automatically assigned permanent address. True dynamic address assignment is limited to DHCP clients.

Therefore, most sites that use DHCP have a mixture of:

Permanent addresses assigned to systems that can't use DHCP or BOOTP
Manual addresses assigned by DHCP to BOOTP clients
Dynamic addresses assigned to all DHCP clients

We conclude this chapter with a discussion of file and print servers.