Posted by arlene

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.
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 be—by saving it to a disk file in the case of a workstation that does have that capability, for example—the 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—Thisdata depends on what kind of information the option supplies.

Possibly related posts: (automatically generated)
The BOOTP Request/Reply Mechanism

• The DHCP Packet Format and Additional Options
• BOOTP and Dynamic Host Configuration Protocol
• Server Replies to FTP Commands
• Taking BOOTP One Step Further: DHCP
• The Dynamic Host Configuration Protocol and BOOTP
• Providing Support for BOOTP Clients
• Reactive Routing Protocols
• Client/Server must Know
• Primary, Secondary, and Caching-Only Name Servers
• How SMTP works