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 Detailed Operation
(Page 1 of 2)
Now that we have seen how
BOOTP messaging works in general terms,
let's take a closer look at the detailed operation of the protocol.
This will let us more clearly see how clients and servers create and
process messages, and also help make sense of some of the important
fields in the BOOTP message field format. Understanding the basic operation
of BOOTP will also be of use when we examine BOOTP
relay agents, and even when we discuss
BOOTP Bootstrapping Steps
The following are the basic steps
performed by the client and server in a regular BOOTP bootstrapping
procedure (see Figure 255).
Figure 255: Boot Protocol Operation
The Boot Protocol uses a simple two-step message exchange consisting of a broadcast request and broadcast reply. After the client receives configuration information from the BOOTP server, it completes the bootstrapping process using a protocol such as TFTP.
1. Client Creates Request
The client machine begins the procedure
by creating a BOOTP request message. In creating this message, it fills
in the following information:
2. Client Sends Request
- It sets the message type (Op) to the value
1, for a BOOTREQUEST message.
- If it knows its own IP address that it plans
to keep using, it specifies it in the CIAddr field. Otherwise,
it fills this field with zeroes. (See below for more on this.)
- It puts its own layer-two hardware address in
the CHAddr field. This is used by the server to determine the
right address and other parameters for the client.
- It generates a random transaction identifier,
and puts this in the XID field.
- The client may specify a particular server that
it wants to send it a reply and put that into the SName field.
It may also specify the name of a particular type of boot file that
it wants the server to provide in the File field.
- The client may specific vendor-specific information,
if programmed to do so.
The client broadcasts the BOOTREQUEST
message by transmitting it to address 255.255.255.255. Alternately,
if it already knows the address of a BOOTP server, it may send the request
3. Server Receives Request and Processes It
A BOOTP server, listening on UDP
port 67, receives the broadcasted request and processes it. If a name
of a particular server was specified and this name is different than
the name of this server, the server may discard the request. This is
especially true if the server knows that the server the client asked
for is also on the local network. If no particular server is specified,
or this particular server was the one the client wanted, the server
4. Server Creates Reply
The server creates a reply message
by copying the request message and changing several fields:
5. Server Sends Reply
- It changes the message type (Op) to the
value 2, for a BOOTREPLY message.
- It takes the client's specified hardware address
from the CHAddr field, and uses it in a table lookup to find
the matching IP address for this host. It then places this value into
the YIAddr (your IP address) of the reply.
- It processes the File field and provides
the filename type the client requested, or if the field was blank, the
- It puts its own IP address and name in the SIAddr
and SName fields.
- It sets any vendor-specific values in the Vend
The server sends the reply, the method
depending on the contents of the request:
6. Client Processes Reply
- If the B (Broadcast) flag is set,
this indicates that the client can't have the reply sent unicast, so
the server will broadcast it.
- If the CIAddr field is non-zero, the server
will send the reply unicast back to that CIAddr.
- If the B flag is zero and the CIAddr
field is also zero, the server may either use an ARP entry or broadcast,
as described in the
The client receives the server's
reply and processes it, storing the information and parameters provided.
(See below for one important issue related to this processing.)
7. Client Completes Boot Process
Once configured, the client proceeds
to phase two of the bootstrapping process, by using a protocol
such as TFTP to download its boot file containing operating system software,
using the filename the server provided.
|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!|
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.