As per Relevance of the word hardware, we have this rfc below:
Network Working Group Bill Croft (Stanford University
Request for Comments: 951 John Gilmore (Sun Microsystems
September 1985
BOOTSTRAP PROTOCOL (BOOTP
1. Status of this
This RFC suggests a proposed protocol for the ARPA-
community, and requests discussion and suggestions for improvements
Distribution of this memo is unlimited
2.
This RFC describes an IP/UDP bootstrap protocol (BOOTP) which
a diskless client machine to discover its own IP address, the
of a server host, and the name of a file to be loaded into memory
executed. The bootstrap operation can be thought of as consisting
TWO PHASES. This RFC describes the first phase, which could
labeled 'address determination and bootfile selection'. After
address and filename information is obtained, control passes to
second phase of the bootstrap where a file transfer occurs. The
transfer will typically use the TFTP protocol [9], since it
intended that both phases reside in PROM on the client.
BOOTP could also work with other protocols such as SFTP [3]
FTP [6].
We suggest that the client's PROM software provide a way to do
complete bootstrap without 'user' interaction. This is the type
boot that would occur during an unattended power-up. A
should be provided for the user to manually supply the
address and filename information to bypass the BOOTP protocol
enter the file transfer phase directly. If non-volatile storage
available, we suggest keeping default settings there and
the BOOTP protocol unless these settings cause the file
phase to fail. If the cached information fails, the bootstrap
fall back to phase 1 and use BOOTP
Here is a brief outline of the protocol
1. A single packet exchange is performed. Timeouts are used
retransmit until a reply is received. The same packet
layout is used in both directions. Fixed length fields of
reasonable length are used to simplify structure definition
parsing
2. An 'opcode' field exists with two values. The
broadcasts a 'bootrequest' packet. The server then answers with
'bootreply' packet. The bootrequest contains the client'
hardware address and its IP address, if known
Croft & Gilmore [Page 1]
RFC 951 September 1985
Bootstrap
3. The request can optionally contain the name of the server
client wishes to respond. This is so the client can force
boot to occur from a specific host (e.g. if multiple versions
the same bootfile exist or if the server is in a far
net/domain). The client does not have to deal with name /
services; instead this function is pushed off to the BOOTP server
4. The request can optionally contain the 'generic' filename to
booted. For example 'unix' or 'ethertip'. When the server
the bootreply, it replaces this field with the fully
path name of the appropriate boot file. In determining this name
the server may consult his own database correlating the client'
address and filename request, with a particular boot
customized for that client. If the bootrequest filename is a
string, then the server returns a filename field indicating
'default' file to be loaded for that client
5. In the case of clients who do not know their IP addresses,
server must also have a database relating hardware address to
address. This client IP address is then placed into a field
the bootreply
6. Certain network topologies (such as Stanford's) may be
that a given physical cable does not have a TFTP server
attached to it (e.g. all the gateways and hosts on a certain
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
Gateways' below. This part of the protocol requires no
action on the part of the client. Implementation is optional
requires a small amount of additional code in gateways
servers
3. Packet
All numbers shown are decimal, unless indicated otherwise. The
packet is enclosed in a standard IP [8] UDP [7] datagram.
simplicity it is assumed that the BOOTP packet is never fragmented
Any numeric fields shown are packed in 'standard network byte order',
i.e. high order bits are sent first
In the IP header of a bootrequest, the client fills in its own
source address if known, otherwise zero. When the server address
unknown, the IP destination address will be the 'broadcast address
255.255.255.255. This address means 'broadcast on the local cable
(I don't know my net number)' [4].
Croft & Gilmore [Page 2]
RFC 951 September 1985
Bootstrap
The UDP header contains source and destination port numbers.
BOOTP protocol uses two reserved port numbers, 'BOOTP client' (68)
and 'BOOTP server' (67). The client sends requests using '
server' as the destination port; this is usually a broadcast.
server sends replies using 'BOOTP client' as the destination port
depending on the kernel or driver facilities in the server, this
or may not be a broadcast (this is explained further in the
titled 'Chicken/Egg issues' below). The reason TWO reserved
are used, is to avoid 'waking up' and scheduling the BOOTP
daemons, when a bootreply must be broadcast to a client. Since
server and other hosts won't be listening on the 'BOOTP client' port
any such incoming broadcasts will be filtered out at the
level. We could not simply allow the client to pick a 'random'
number for the UDP source port field; since the server reply may
broadcast, a randomly chosen port number could confuse other
that happened to be listening on that port
The UDP length field is set to the length of the UDP plus
portions of the packet. The UDP checksum field can be set to zero
the client (or server) if desired, to avoid this extra overhead in
PROM implementation. In the 'Packet Processing' section below
phrase '[UDP checksum.]' is used whenever the checksum might
verified/computed
FIELD BYTES
----- ----- -----------
op 1 packet op code / message type
1 = BOOTREQUEST, 2 =
htype 1 hardware address type
see ARP section in "Assigned Numbers" RFC
'1' = 10mb
hlen 1 hardware address
(eg '6' for 10mb ethernet).
hops 1 client sets to zero
optionally used by
in cross-gateway booting
xid 4 transaction ID, a random number
used to match this boot request with
responses it generates
secs 2 filled in by client, seconds elapsed
client started trying to boot
Croft & Gilmore [Page 3]
RFC 951 September 1985
Bootstrap
-- 2
ciaddr 4 client IP address
filled in by client in bootrequest if known
yiaddr 4 'your' (client) IP address
filled by server if client doesn'
know its own address (ciaddr was 0).
siaddr 4 server IP address
returned in bootreply by server
giaddr 4 gateway IP address
used in optional cross-gateway booting
chaddr 16 client hardware address
filled in by client
sname 64 optional server host name
null terminated string
file 128 boot file name, null terminated string
'generic' name or null in bootrequest
fully qualified directory-
name in bootreply
vend 64 optional vendor-specific area
e.g. could be hardware type/serial on request
or 'capability' / remote file system
on reply. This info may be set aside for
by a third phase bootstrap or kernel
4. Chicken / Egg
How can the server send an IP datagram to the client, if the
doesnt know its own IP address (yet)? Whenever a bootreply is
sent, the transmitting machine performs the following operations
1. If the client knows its own IP address ('ciaddr' field
nonzero), then the IP can be sent 'as normal', since the
will respond to ARPs [5].
2. If the client does not yet know its IP address (ciaddr zero),
then the client cannot respond to ARPs sent by the transmitter
the bootreply. There are two options
a. If the transmitter has the necessary kernel or driver
Croft & Gilmore [Page 4]
RFC 951 September 1985
Bootstrap
to 'manually' construct an ARP address cache entry, then it
fill in an entry using the 'chaddr' and 'yiaddr' fields.
course, this entry should have a timeout on it, just like
other entry made by the normal ARP code itself.
transmitter of the bootreply can then simply send the
to the client's IP address. UNIX (4.2 BSD) has
capability
b. If the transmitter lacks these kernel hooks, it can
send the bootreply to the IP broadcast address on
appropriate interface. This is only one additional
over the previous case
5. Client Use of
The client PROM must contain a simple implementation of ARP, e.g.
address cache could be just one entry in size. This will allow
second-phase-only boot (TFTP) to be performed when the client
the IP addresses and bootfile name
Any time the client is expecting to receive a TFTP or BOOTP reply,
should be prepared to answer an ARP request for its own IP
hardware address mapping (if known).
Since the bootreply will contain (in the hardware encapsulation)
hardware source address of the server/gateway, the client MAY be
to avoid sending an ARP request for the server/gateway IP address
be used in the following TFTP phase. However this should be
only as a special case, since it is desirable to still allow
second-phase-only boot as described above
6. Comparison to
An earlier protocol, Reverse Address Resolution Protocol (RARP) [1]
was proposed to allow a client to determine its IP address,
that it knew its hardware address. However RARP had the
that it was a hardware link level protocol (not IP/UDP based).
means that RARP could only be implemented on hosts containing
kernel or driver modifications to access these 'raw' packets.
there are many network kernels existent now, with each
maintained by different organizations, a boot protocol that does
require kernel modifications is a decided advantage
BOOTP provides this hardware to IP address lookup function,
addition to the other useful features described in the
above
Croft & Gilmore [Page 5]
RFC 951 September 1985
Bootstrap
7. Packet
7.1. Client
Before setting up the packet for the first time, it is a good
to clear the entire packet buffer to all zeros; this will
all fields in their default state. The client then creates
packet with the following fields
The IP destination address is set to 255.255.255.255. (
broadcast address) or to the server's IP address (if known).
IP source address and 'ciaddr' are set to the client's IP
if known, else 0. The UDP header is set with the proper length
source port = 'BOOTP client' port destination port = '
server' port
'op' is set to '1', BOOTREQUEST. 'htype' is set to the
address type as assigned in the ARP section of the "
Numbers" RFC. 'hlen' is set to the length of the hardware address
e.g. '6' for 10mb ethernet
'xid' is set to a 'random' transaction id. 'secs' is set to
number of seconds that have elapsed since the client has
booting. This will let the servers know how long a client
been trying. As the number gets larger, certain servers may
more 'sympathetic' towards a client they don't normally service
If a client lacks a suitable clock, it could construct a
estimate using a loop timer. Or it could choose to simply
this field as always a fixed value, say 100 seconds
If the client knows its IP address, 'ciaddr' (and the IP
address) are set to this value. 'chaddr' is filled in with
client's hardware address
If the client wishes to restrict booting to a particular
name, it may place a null-terminated string in 'sname'. The
used should be any of the allowable names or nicknames of
desired host
The client has several options for filling the 'file' name field
If left null, the meaning is 'I want to boot the default file
my machine'. A null file name can also mean 'I am only
in finding out client/server/gateway IP addresses, I dont
about file names'.
The field can also be a 'generic' name such as 'unix'
Croft & Gilmore [Page 6]
RFC 951 September 1985
Bootstrap
'gateway'; this means 'boot the named program configured for
machine'. Finally the field can be a fully directory
path name
The 'vend' field can be filled in by the client
vendor-specific strings or structures. For example the
hardware type or serial number may be placed here. However
operation of the BOOTP server should not DEPEND on
information existing
If the 'vend' field is used, it is recommended that a 4
'magic number' be the first item within 'vend'. This lets
server determine what kind of information it is seeing in
field. Numbers can be assigned by the usual 'magic number
process --you pick one and it's magic. A different magic
could be used for bootreply's than bootrequest's to allow
client to take special action with the reply information
[UDP checksum.]
7.2. Client Retransmission
If no reply is received for a certain length of time, the
should retransmit the request. The time interval must be
carefully so as not to flood the network. Consider the case of
cable containing 100 machines that are just coming up after
power failure. Simply retransmitting the request every
seconds will inundate the net
As a possible strategy, you might consider backing
exponentially, similar to the way ethernet backs off on
collision. So for example if the first packet is at time 0:00,
the second would be at :04, then :08, then :16, then :32,
:64. You should also randomize each time; this would be
similar to the ethernet specification by starting with a mask
'and'ing that with with a random number to get the first backoff
On each succeeding backoff, the mask is increased in length by
bit. This doubles the average delay on each backoff
After the 'average' backoff reaches about 60 seconds, it should
increased no further, but still randomized
Before each retransmission, the client should update the 'secs
field. [UDP checksum.]
Croft & Gilmore [Page 7]
RFC 951 September 1985
Bootstrap
7.3. Server Receives
[UDP checksum.] If the UDP destination port does not match
'BOOTP server' port, discard the packet
If the server name field (sname) is null (no particular
specified), or sname is specified and matches our name
nickname, then continue with packet processing
If the sname field is specified, but does not match 'us',
there are several options
1. You may choose to simply discard this packet
2. If a name lookup on sname shows it to be on this same cable
discard the packet
3. If sname is on a different net, you may choose to
the packet to that address. If so, check the 'giaddr' (
address) field. If 'giaddr' is zero, fill it in with
address or the address of a gateway that can be used to get
that net. Then forward the packet
If the client IP address (ciaddr) is zero, then the client
not know its own IP address. Attempt to lookup the
hardware address (chaddr, hlen, htype) in our database. If
match is found, discard the packet. Otherwise we now have an
address for this client; fill it into the 'yiaddr' (your
address) field
We now check the boot file name field (file). The field will
null if the client is not interested in filenames, or wants
default bootfile. If the field is non-null, it is used as
lookup key in a database, along with the client's IP address.
there is a default file or generic file (possibly indexed by
client address) or a fully-specified path name that matches,
replace the 'file' field with the fully-specified path name of
selected boot file. If the field is non-null and no match
found, then the client is asking for a file we dont have;
the packet, perhaps some other BOOTP server will have it
The 'vend' vendor-specific data field should now be checked and
a recognized type of data is provided, client-specific
should be taken, and a response placed in the 'vend' data field
the reply packet. For example, a workstation client could
Croft & Gilmore [Page 8]
RFC 951 September 1985
Bootstrap
an authentication key and receive from the server a capability
remote file access, or a set of configuration options, which
be passed to the operating system that will shortly be booted in
Place my (server) IP address in the 'siaddr' field. Set the 'op
field to BOOTREPLY. The UDP destination port is set to '
client'. If the client address 'ciaddr' is nonzero, send
packet there; else if the gateway address 'giaddr' is nonzero,
the UDP destination port to 'BOOTP server' and send the packet
'giaddr'; else the client is on one of our cables but it
know its own IP address yet --use a method described in the 'Egg
section above to send it to the client. If 'Egg' is used and
have multiple interfaces on this host, use the 'yiaddr' (your
address) field to figure out which net (cable/interface) to
the packet to. [UDP checksum.]
7.4. Server/Gateway Receives
[UDP checksum.] If 'yiaddr' (your [the client's] IP address
refers to one of our cables, use one of the 'Egg' methods above
forward it to the client. Be sure to send it to the '
client' UDP destination port
7.5. Client
Don't forget to process ARP requests for my own IP address (if
know it). [UDP checksum.] The client should discard
packets that: are not IP/UDPs addressed to the boot port; are
BOOTREPLYs; do not match my IP address (if I know it) or
hardware address; do not match my transaction id. Otherwise
have received a successful reply. 'yiaddr' will contain my
address, if I didnt know it before. 'file' is the name of
file name to TFTP 'read request'. The server address is
'siaddr'. If 'giaddr' (gateway address) is nonzero, then
packets should be forwarded there first, in order to get to
server
8. Booting Through
This part of the protocol is optional and requires some
code in cooperating gateways and servers, but it allows cross-
booting. This is mainly useful when gateways are diskless machines
Gateways containing disks (e.g. a UNIX machine acting as a gateway),
might as well run their own BOOTP/TFTP servers
Gateways listening to broadcast BOOTREQUESTs may decide to forward
rebroadcast these requests 'when appropriate'. For example,
Croft & Gilmore [Page 9]
RFC 951 September 1985
Bootstrap
gateway could have, as part of his configuration tables, a list
other networks or hosts to receive a copy of any
BOOTREQUESTs. Even though a 'hops' field exists, it is a poor
to simply globally rebroadcast the requests, since broadcast
will almost certainly occur
The forwarding could begin immediately, or wait until the 'secs
(seconds client has been trying) field passes a certain threshold
If a gateway does decide to forward the request, it should look
the 'giaddr' (gateway IP address) field. If zero, it should plug
own IP address (on the receiving cable) into this field. It may
use the 'hops' field to optionally control how far the packet
reforwarded. Hops should be incremented on each forwarding.
example, if hops passes '3', the packet should probably be discarded
[UDP checksum.]
Here we have recommended placing this special forwarding function
the gateways. But that does not have to be the case. As long
some 'BOOTP forwarding agent' exists on the net with the
client, the agent can do the forwarding when appropriate. Thus
service may or may not be co-located with the gateway
In the case of a forwarding agent not located in the gateway,
agent could save himself some work by plugging the broadcast
of the interface receiving the bootrequest into the 'giaddr' field
Thus the reply would get forwarded using normal gateways,
involving the forwarding agent. Of course the disadvantage here
that you lose the ability to use the 'Egg' non-broadcast method
sending the reply, causing extra overhead for every host on
client cable
9. Sample BOOTP Server
As a suggestion, we show a sample text file database that the
server program might use. The database has two sections,
by a line containing an percent in column 1. The first
contains a 'default directory' and mappings from generic names
directory/pathnames. The first generic name in this section is
'default file' you get when the bootrequest contains a null 'file
string
The second section maps hardware addresstype/address into
ipaddress. Optionally you can also overide the default generic
by supplying a ipaddress specific genericname. A 'suffix' item
also an option; if supplied, any generic names specified by
client will be accessed by first appending 'suffix' to the 'pathname
Croft & Gilmore [Page 10]
RFC 951 September 1985
Bootstrap
appropriate to that generic name. If that file is not found,
the plain 'pathname' will be tried. This 'suffix' option allows
whole set of custom generics to be setup without a lot of effort
Below is shown the general format; fields are delimited by one
more spaces or tabs; trailing empty fields may be omitted;
lines and lines beginning with '#' are ignored
# comment
genericname1 pathname
genericname2 pathname
...
% end of generic names, start of address
hostname1 hardwaretype hardwareaddr1 ipaddr1 genericname
hostname2 hardwaretype hardwareaddr2 ipaddr2 genericname
...
Here is a specific example. Note the 'hardwaretype' number is
same as that shown in the ARP section of the 'Assigned Numbers' RFC
The 'hardwaretype' and 'ipaddr' numbers are in decimal
'hardwareaddr' is in hex
# last updated by
/usr/
vmunix
tip
watch /usr/diag/
gate gate
% end of generic names, start of address
hamilton 1 02.60.8c.06.34.98 36.19.0.5
burr 1 02.60.8c.34.11.78 36.44.0.12
101-gateway 1 02.60.8c.23.ab.35 36.44.0.32 gate 101
mjh-gateway 1 02.60.8c.12.32.bc 36.42.0.64 gate
welch-tipa 1 02.60.8c.22.65.32 36.47.0.14
welch-tipb 1 02.60.8c.12.15.c8 36.46.0.12
In the example above, if 'mjh-gateway' does a default boot, it
get the file '/usr/boot/gate.mjh'.
Croft & Gilmore [Page 11]
RFC 951 September 1985
Bootstrap
10.
Ross Finlayson (et. al.) produced two earlier RFC's discussing
bootstraping [2] using RARP [1].
We would also like to acknowledge the previous work and comments
Noel Chiappa, Bob Lyon, Jeff Mogul, Mark Lewis, and David Plummer
1. Ross Finlayson, Timothy Mann, Jeffrey Mogul, Marvin Theimer.
Reverse Address Resolution Protocol. RFC 903, NIC, June, 1984.
2. Ross Finlayson. Bootstrap Loading using TFTP. RFC 906, NIC
June, 1984.
3. Mark Lottor. Simple File Transfer Protocol. RFC 913, NIC
September, 1984.
4. Jeffrey Mogul. Broadcasting Internet Packets. RFC 919, NIC
October, 1984.
5. David Plummer. An Ethernet Address Resolution Protocol.
826, NIC, September, 1982.
6. Jon Postel. File Transfer Protocol. RFC 765, NIC, June, 1980.
7. Jon Postel. User Datagram Protocol. RFC 768, NIC, August, 1980.
8. Jon Postel. Internet Protocol. RFC 791, NIC, September, 1981.
9. K. R. Sollins, Noel Chiappa. The TFTP Protocol. RFC 783, NIC
June, 1981.
Croft & Gilmore [Page 12]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
