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