BOOTP allows a diskless client machine to discover its own IP address,the address of a server host, and the name of a file to be loaded into memory and executed. The bootstrap operation can be thought of as consisting oftwo phases -first address determination and bootfile selection and second file transfer.
The client broadcasts a 'bootrequest' packet. The server then
answers with a 'bootreply' packet. The bootrequest contains the client's
hardware address and its IP address, if known. The request can optionally
contain either the name of the server the client wishes to respond or the
'generic' filename to be booted. When the server sends the bootreply, it
replaces filename with the fully qualified path name of the appropriate
boot file. In the case of clients who do not know their IP addresses, the
server must also have a database relating hardware address to IP address.
The BOOTP process involves the following steps:
1.The client determines its own hardware address; this is normally
in a ROM on the hardware.
2.A BOOTP client sends its hardware address in a UDP datagram
to the server. If the client knows its IP address and/or the address
of the server, it should use them, but in general
BOOTP clients have no IP configuration data at all. If the client does
not know its
own IP address, it uses 0.0.0.0. If the client does
not know the server's IP address, it uses the limited broadcast address
(255.255.255.255). The UDP port number is 67.
3.The server receives the datagram and looks up the hardware
address of the client in its configuration file, which contains the
client's IP address. The server fills in the remaining
fields in the UDP datagram and returns it to the client using UDP port
68.
One of three methods may be used to do this:
If the client knew its own
IP address (it was included in the BOOTP request), then the server returns
the datagram directly to this address.
It is likely that the ARP cache in the server's protocol stack will not
know the hardware address matching the IP address.
ARP will be used to determine it as normal.
If the client did not know
its own IP address (it 0.0.0.0 in the BOOTP request), then the server must
concern itself with its own ARP cache. ARP on
the server cannot be used to find the hardware address of the client because
the client does not know its IP address
and so cannot reply to an ARP request. This is called the ``chicken and
egg'' problem. There are
two possible solutions:
1) If the server has a mechanism for directly updating its own ARP cache without using ARP itself, it does so and then sends the datagram directly.
2) If the server cannot update its own ARP cache, it must send a broadcast reply.
4.When it receives the reply, the BOOTP client will record its
own IP address (allowing it to respond to ARP requests) and
begin the bootstrap process.
Earlier RARP was proposed to allow a client to determine its IP address, given that it knew its hardware address. However RARP had the disadvantage that it was a hardware link level protocol (not IP/UDP based). This means that RARP could only be implemented on hosts containing special kernel or driver modifications to access these 'raw' packets. Since there are many network kernels existent now, with each source maintained by different organizations, a boot protocol that does not require kernel modifications is a decided advantage.
for more detaile refer RFC
951