Connected: An Internet Encyclopedia
2. Overview
Up:
Connected: An Internet Encyclopedia
Up:
Requests For Comments
Up:
RFC 951
Prev: RFC 951
Next: 3. Packet Format
2. Overview
2. Overview
This RFC describes an IP/UDP bootstrap protocol (BOOTP) which 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 of
TWO PHASES. This RFC describes the first phase, which could be
labeled 'address determination and bootfile selection'. After this
address and filename information is obtained, control passes to the
second phase of the bootstrap where a file transfer occurs. The file
transfer will typically use the TFTP protocol [9], since it is
intended that both phases reside in PROM on the client. However
BOOTP could also work with other protocols such as SFTP [3] or
FTP [6].
We suggest that the client's PROM software provide a way to do a
complete bootstrap without 'user' interaction. This is the type of
boot that would occur during an unattended power-up. A mechanism
should be provided for the user to manually supply the necessary
address and filename information to bypass the BOOTP protocol and
enter the file transfer phase directly. If non-volatile storage is
available, we suggest keeping default settings there and bypassing
the BOOTP protocol unless these settings cause the file transfer
phase to fail. If the cached information fails, the bootstrap should
fall back to phase 1 and use BOOTP.
Here is a brief outline of the protocol:
- A single packet exchange is performed. Timeouts are used to
retransmit until a reply is received. The same packet field
layout is used in both directions. Fixed length fields of maximum
reasonable length are used to simplify structure definition and
parsing.
- An 'opcode' field exists with two values. 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 the name of the server the
client wishes to respond. This is so the client can force the
boot to occur from a specific host (e.g. if multiple versions of
the same bootfile exist or if the server is in a far distant
net/domain). The client does not have to deal with name / domain
services; instead this function is pushed off to the BOOTP server.
- The request can optionally contain the 'generic' filename to be
booted. For example 'unix' or 'ethertip'. When the server sends
the bootreply, it replaces this field with the fully qualified
path name of the appropriate boot file. In determining this name,
the server may consult his own database correlating the client's
address and filename request, with a particular boot file
customized for that client. If the bootrequest filename is a null
string, then the server returns a filename field indicating the
'default' file to be loaded for that client.
- 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. This client IP address is then placed into a field in
the bootreply.
- Certain network topologies (such as Stanford's) may be such
that a given physical cable does not have a TFTP server directly
attached to it (e.g. all the gateways and hosts on a certain cable
may be diskless). With the cooperation of neighboring gateways,
BOOTP can allow clients to boot off of servers several hops away,
through these gateways. See the section 'Booting Through
Gateways' below. This part of the protocol requires no special
action on the part of the client. Implementation is optional and
requires a small amount of additional code in gateways and
servers.
Next: 3. Packet Format
Connected: An Internet Encyclopedia
2. Overview