In computer networking, the Bootstrap Protocol, or BOOTP, is a network protocol used

by a network client to obtain an IP address from a configuration server. The BOOTP

protocol was originally defined in RFC 951.

BOOTP is usually used during the bootstrap process when a computer is starting up. A
BOOTP configuration server assigns an IP address to each client from a pool of
addresses. BOOTP uses the User Datagram Protocol (UDP) as a transport on IPv4
networks only.

Historically, BOOTP has also been used for Unix-like diskless workstations to obtain the
network location of their boot image in addition to an IP address, and also by enterprises
to roll out a pre-configured client (e.g., Windows) installation to newly installed PCs.

Originally requiring the use of a boot floppy disk to establish the initial network
connection, manufacturers of network cards later embedded the protocol in the BIOS of
the interface cards as well as system boards with on-board network adapters, thus
allowing direct network booting.

Recently, users with an interest in diskless stand-alone media center PCs have shown new
interest in this method of booting a Windows operating system.[1]

The Dynamic Host Configuration Protocol (DHCP) is a more advanced protocol for the
same purpose and has superseded the use of BOOTP. Most DHCP servers also function
as BOOTP servers.

The BOOTP protocol was first defined in RFC 951 as a replacement for the Reverse
Address Resolution Protocol RARP, published in RFC 903 in June 1984. The primary
motivation for replacing RARP with BOOTP is that RARP was a data link layer protocol.
This made implementation difficult on many server platforms, and required that a server
be present on each individual IP subnet. BOOTP introduced the innovation of a relay
agent, which allowed BOOTP packets to be forwarded from the local network using
standard IP routing, so that one central BOOTP server could serve hosts on many
subnets.
Description:

Protocol suite: TCP/IP.

Protocol type: Application layer configuration protocol.
Related protocols: DHCP.
Ports: 67 (UDP) server.
68 (UDP) host.
SNMP MIBs:
Working groups: DHCP, Dynamic Host Configuration Protocol.
Links: IANA: BOOTP/DHCP options.

The Bootstrap Protocol allows a host to configure itself dynamically at boot time. This
protocol provides 3 services:

• IP address assignment.
• Detection of the IP address for a serving machine.
• The name of a file to be loaded and executed by the client machine.

The BOOTP packet is assumed to never fragment.

MAC header IP header UDP header BOOTP message

BOOTP message:

00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Hardware address
Opcode Hardware type Hop count
length
Transaction ID
Number of seconds Flags
Client IP address
Your IP address
Server IP address
Gateway IP address
Client hardware address :::
Server host name :::
Boot filename :::
Vendor specific info :::

Opcode. 8 bits.
Value Description
1 BOOTREQUEST, Boot request.
2 BOOTREPLY, Boot reply.

Hardware type. 8 bits.

Value Description
1 Ethernet.
2 Experimental Ethernet.
3 Amateur Radio AX.25.
4 Proteon ProNET Token Ring.
5 Chaos.
6 IEEE 802.
7 ARCNET.
8 Hyperchannel.
9 Lanstar.
10 Autonet Short Address.
11 LocalTalk.
12 LocalNet (IBM PCNet or SYTEK LocalNET).
13 Ultra link.
14 SMDS.
15 Frame Relay.
16 ATM, Asynchronous Transmission Mode.
17 HDLC.
18 Fibre Channel.
19 ATM, Asynchronous Transmission Mode.
20 Serial Line.
21 ATM, Asynchronous Transmission Mode.
22 MIL-STD-188-220.
23 Metricom.
24 IEEE 1394.1995.
25 MAPOS.
26 Twinaxial.
27 EUI-64.
28 HIPARP.

Hardware address length. 8 bits.

Hop count. 8 bits.

Transaction ID. 32 bits.

Number of seconds. 16 bits.

The elapsed time, in seconds since the client sent its first BOOTREQUEST message.

Flags. 16 bits.
Defined in RFC 1542.

00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15
B 0

B, Broadcast. 1 bit.

Client IP address. 32 bits.

Your IP address. 32 bits.

Server IP address. 32 bits.

Gateway IP address. 32 bits.

Client hardware address. 16 bytes.

Server host name. 64 bytes.

Boot filename. 128 bytes.

Vendor specific info. 64 bytes.

 BOOTP
BOOTP (Boot Protocol) may be used to boot remote computers over a network. BOOTP
messages are encapsulated inside UDP messages and therefore its requests and replies
are forwarded by routers. BOOTP is defined by RFCs 951 and 1542. The drawing below
illustrates the data encapsulation:

The diskless system reads its unique hardware address from its network interface card
then sends a BOOTP request. The table below shows the BOOTP package format from
most significant bit to least significant bit.

Bit # of
Name Description
range Bits
Tells if the message is a BOOTP request or reply.
0-7 8 Op code
Request=1, reply=2
Indicates the type of hardware (link level). A value of
8-15 8 Hardware type
6 indicates ethernet
Hardware Tells the length in bytes of the hardware address
16-23 8
address length number. Ethernet addresses are 6 bytes long.
Initially set to 0. Incremented each time it is
23-31 8 Hop count
forwarded.
A random number set by the client and returned by
32-63 32 Transaction ID
the server. Used to match replies with requests
The time since the client started trying to bootstrap.
Number of
64-79 16 Used to tell if a backup BOOTP server should
seconds
respond.
80-95 16 unused not used
Clients IP The clients IP address. If a request, it is normally
96-127 32
address 0.0.0.0
 IP address for
128-159 32 The server sets this in the reply message.
client
160-191 32 Server IP address Filled in by the server.
Gateway IP
192-223 32 Returned by the server.
address
Clients hardware
224-351 128 Provided by the client.
address
352- A null terminated string optionally filled in by the
1024 Server hostname
1375 server.
A fully qualified boot file name with path
1376-
2048 Boot filename information, terminated with a null. Supplied by the
3423
server.
3424- Vendor Used for various options to BOOTP including the
1024
4447 information subnet mask to the client.

The BOOTP server uses port 67 and the BOOTP client uses port 68. The following is a
brief explanation of what happens when a remote client boots:

1. BOOTP request. The client sends a BOOTP request from 0.0.0.0.68 to

255.255.255.255.67 with its ethernet address and number of second's fields filled
in.
2. BOOTP reply. The server responds with the client's IP address, the server's IP
address (it's own), and the IP address of a default gateway.
3. ARP request. The client issues an ARP to tell if the IP address it just received is
being used. It uses 0.0.0.0 as it's own address
4. ARP request. The client waits 0.5 seconds and repeats the same ARP request.
5. ARP request. The client waits another 0.5 seconds and repeats the ARP request
with it's own address as the senders address.
6. BOOTP request. The client waits 0.5 seconds and sends another BOOTP request
with its own IP address in the IP header
7. BOOTP reply. The server sends the same BOOTP reply it sent the last time.
8. ARP request. The client outputs an ARP request for the server hardware address
9. ARP reply. The server replies with its own ethernet address.
10. TFTP read request. The client sends a TFTP read request asking for its specified
boot file.
BOOTP is the Bootstrap Protocol.

The BOOTP protocol is utilized by diskless workstations to gather configuration

information from a network server.

The information provided by the BOOTP protocol is:

• The IP address which should be utilized by the diskless workstation

• The IP address of a server which will provide an Operating System image for the
diskless workstation
• The filename of an Operating System image which the diskless workstation
should boot

BOOTP workstations are identified by their MAC addresses.

The BOOTP protocol utilizes UDP ports 67 and 68.

Address Allocation Option 2: BOOTP
Updated: November 10, 2008

A BOOTP server automatically assigns the IP address from a pool of available addresses. By default, the
address is leased for 30 days. In its usual mode of operation, a BOOTP server always assigns the same
address to a client based on the client’s MAC address.

BOOTP operation has two phases:

• Address determination and bootfile selection.

• File transfer (the operating system download). The transfer typically occurs using Trivial File

Transfer Protocol (TFTP). The BOOTP server does not need to be the same server as the TFTP
image server.

In the BOOTP request, the client can include its MAC address (typically held in non-volatile memory on the
network card) and any previously bound IP address, if such information has been stored. The BOOTP
server can then respond with a particular IP address for the client, based on either the MAC address
mapping or the IP address that had been previously assigned.

BOOTP requests are network broadcasts; if routers support BOOTP replay, these broadcasts can be passed
through routers to other subnets so that a BOOTP server on every subnet is not required. The BOOTP
protocol supports a limited number of client configuration parameters called vendor extensions that can be
used to provide the client with information, such as default gateway and host name.

Advantages
The advantages of BOOTP include:

• Centralized service: BOOTP provides for centralized IP address allocation and management. A

network administrator can configure the BOOTP server, and then any device using BOOTP can
connect to this server to get an IP address (and, optionally, an operating system).

• Platform support: BOOTP is an established and widely supported protocol. BOOTP client support

is available for most, if not all, operating systems and BOOTP servers are available for Windows,
UNIX, mainframe, and other server platforms.

Disadvantages
The disadvantages of BOOTP include:

• Renewal on restart only: BOOTP clients rebind or renew their configuration with the BOOTP

server only when the system restarts. This can be a major disadvantage given that BOOTP has a
default 30-day expiration on IP address leases. An IP address allocation cannot be changed
before the 30-day lease has expired unless the client system is rebooted.

• No automatic address reuse: BOOTP does not provide automatic reclamation of unused IP

addresses, so it requires a manual method for reclaiming addresses that are no longer in service.

• Limited support for dynamic addressing: Addresses are usually fixed, so there is limited

opportunity for address reuse. It is difficult to support a greater number of hosts than there are
addresses in the pool because there is typically a one-to-one mapping between host MAC
 addresses and static IP addresses. This means an IP address is effectively in use all the time,
even if the host is not permanently online.

• Limited extensions: BOOTP provides for vendor extensions that allow extra information, such

as the address of a DNS server, to be sent to a client from the BOOTP server. However, these
extensions are limited to one 64-byte field. RFC 1084 originally standardized these extensions;
however, this approach does not allow much customization.