Please Whitelist This Site?

I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :)

If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads.

If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK.

Thanks for your understanding!

Sincerely, Charles Kozierok
Author and Publisher, The TCP/IP Guide


NOTE: Using software to mass-download the site degrades the server and is prohibited.
If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.

The Book is Here... and Now On Sale!

Searchable, convenient, complete TCP/IP information.
The TCP/IP Guide

Custom Search







Table Of Contents  The TCP/IP Guide
 9  TCP/IP Application Layer Protocols, Services and Applications (OSI Layers 5, 6 and 7)
      9  TCP/IP Network Configuration and Management Protocols (BOOTP, DHCP, SNMP and RMON)
           9  Host Configuration and TCP/IP Host Configuration Protocols (BOOTP and DHCP)
                9  TCP/IP Bootstrap Protocol (BOOTP)

Previous Topic/Section
BOOTP Detailed Operation
Previous Page
Pages in Current Topic/Section
1
Next Page
BOOTP Vendor-Specific Area and Vendor Information Extensions
Next Topic/Section

BOOTP Message Format

The exchange of information in BOOTP takes the form of a request sent by a client, and a reply sent back by the server. BOOTP, like a number of other request/reply protocols, uses a common message format for requests and replies. The client starts by setting aside memory space for the message and clearing it to all zeroes. It then fills in the fields of the message and sends the request, as we saw in the previous topic. The server creates its reply not from scratch, but by copying the request and changing certain fields.

BOOTP messages contain a considerable number of fields, so the message format is rather large. It is described fully in Table 186 and illustrated in Figure 256.


Table 186: BOOTP Message Format

Field Name

Size (bytes)

Description

Op

1

Operation Code: Specifies the type of message. A value of 1 indicates a request (BOOTREQUEST message) while a value of 2 is a reply (BOOTREPLY message).

HType

1

 

HLen

1

Hardware Address Length: Specifies how long hardware addresses are in this message. For Ethernet or other networks using IEEE 802 MAC addresses, the value is 6. This too is the same as the field with a similar name (HLN) in the ARP field format.

Hops

1

Hops: Set to 0 by a client before transmitting a request and used by BOOTP relay agents to control the forwarding of BOOTP messages.

XID

4

Transaction Identifier: A 32-bit identification field generated by the client, to allow it to match up the request with replies received from BOOTP servers.

Secs

2

Seconds: According to RFC 951, the client enters into this field the number of seconds “elapsed since [the] client started trying to boot”. This is supposed to provide information to BOOTP servers to help them decide which requests to respond to first.

Unfortunately, this definition was somewhat vague; it wasn't clear if this meant the amount of time since the machine was powered on, or since the first BOOTREQUEST message was sent. In addition, some devices incorrectly implemented this field. As a result, it is not always used.

Flags

2

 

CIAddr

4

Client IP Address: If the client has a current IP address that it plans to keep using, it puts it in this field. By filling in this field, the client is committing to responding to unicast IP datagrams sent to this address. Otherwise, it sets this field to all zero to tell the server it wants an address assigned. See the end of the detailed operation topic for important information on this field.

YIAddr

4

“Your” IP Address: The IP address that the server is assigning to the client. This may be different than the IP address currently used by the client. See the topic describing BOOTP operation in detail for an explanation of what happens in that case.

SIAddr

4

Server IP Address: The IP address of the BOOTP server sending a BOOTREPLY message.

GIAddr

4

Gateway IP Address: This field is used to route BOOTP messages when BOOTP relay agents facilitate the communication of BOOTP requests and replies between a client and a server on different subnets or networks. To understand the name, remember that the old TCP/IP term for “router” is “gateway”; BOOTP relay agents are typically routers.

Note that this field is set to 0 by the client and should be ignored by the client when processing a BOOTREPLY. It specifically does not represent the server giving the client the address of a default router address to be used for general IP routing purposes.

CHAddr

16

Client Hardware Address: The hardware (layer two) address of the client sending a BOOTREPLY. It is used both to look up a device's assigned IP address and also possibly in delivery of a reply message.

SName

64

Server Name: The server sending a BOOTREPLY may optionally put its name in this field. This can be a simple text “nickname” or a fully-qualified DNS domain name (such as “myserver.organization.org”).

Note that a client may specify a name in this field when it creates its request. If it does so, it is saying that it wants to get a reply only from the BOOTP server with this name. This may be done to ensure that the client is able to access a particular boot file stored on only one server

File

128

Boot Filename: Contains the full directory path and file name of a boot file that can be downloaded by the client to complete its bootstrapping process. The client may request a particular type of file by entering a text description here, or may leave the field blank and the server will supply the filename of the default file.

Vend

64

Vendor-Specific Area: Originally created to allow vendors to customize BOOTP to the needs of different types of hardware, this field is now also used to hold additional vendor-independent configuration information. See the next topic, on BOOTP vendor information extensions. It may be used by the client and/or the server.



Figure 256: BOOTP Message Format

 


As I mentioned in the topic on BOOTP messaging, both requests and replies are encapsulated into UDP messages for transmission. The BOOTP standard specifies that the use of UDP checksums is optional. Using the checksum provides protection against data integrity errors and is thus recommended. This may cause unacceptable processing demands on the part of very simple clients, so the checksum can legally be skipped.

Similarly, for simplicity, BOOTP assumes that its messages will not be fragmented. This is to allow BOOTP clients to avoid the complexity of reassembling fragmented messages. Since BOOTP messages are only 300 bytes in length, under the minimum MTU required for all TCP/IP links, this is not normally an issue.


Previous Topic/Section
BOOTP Detailed Operation
Previous Page
Pages in Current Topic/Section
1
Next Page
BOOTP Vendor-Specific Area and Vendor Information Extensions
Next Topic/Section

If you find The TCP/IP Guide useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider purchasing a download license of The TCP/IP Guide. Thanks for your support!
Donate $2
Donate $5
Donate $10
Donate $20
Donate $30
Donate: $



Home - Table Of Contents - Contact Us

The TCP/IP Guide (http://www.TCPIPGuide.com)
Version 3.0 - Version Date: September 20, 2005

Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.