| blob | 86cd69e63c5421798e577c1afa16dee1897c38d5 |
3 Network Working Group Bill Croft (Stanford University)
4 Request for Comments: 951 John Gilmore (Sun Microsystems)
5 September 1985
7 BOOTSTRAP PROTOCOL (BOOTP)
10 1. Status of this Memo
12 This RFC suggests a proposed protocol for the ARPA-Internet
13 community, and requests discussion and suggestions for improvements.
14 Distribution of this memo is unlimited.
16 2. Overview
18 This RFC describes an IP/UDP bootstrap protocol (BOOTP) which allows
19 a diskless client machine to discover its own IP address, the address
20 of a server host, and the name of a file to be loaded into memory and
21 executed. The bootstrap operation can be thought of as consisting of
22 TWO PHASES. This RFC describes the first phase, which could be
23 labeled 'address determination and bootfile selection'. After this
24 address and filename information is obtained, control passes to the
25 second phase of the bootstrap where a file transfer occurs. The file
26 transfer will typically use the TFTP protocol [9], since it is
27 intended that both phases reside in PROM on the client. However
28 BOOTP could also work with other protocols such as SFTP [3] or
29 FTP [6].
31 We suggest that the client's PROM software provide a way to do a
32 complete bootstrap without 'user' interaction. This is the type of
33 boot that would occur during an unattended power-up. A mechanism
34 should be provided for the user to manually supply the necessary
35 address and filename information to bypass the BOOTP protocol and
36 enter the file transfer phase directly. If non-volatile storage is
37 available, we suggest keeping default settings there and bypassing
38 the BOOTP protocol unless these settings cause the file transfer
39 phase to fail. If the cached information fails, the bootstrap should
40 fall back to phase 1 and use BOOTP.
42 Here is a brief outline of the protocol:
44 1. A single packet exchange is performed. Timeouts are used to
45 retransmit until a reply is received. The same packet field
46 layout is used in both directions. Fixed length fields of maximum
47 reasonable length are used to simplify structure definition and
48 parsing.
50 2. An 'opcode' field exists with two values. The client
51 broadcasts a 'bootrequest' packet. The server then answers with a
52 'bootreply' packet. The bootrequest contains the client's
53 hardware address and its IP address, if known.
56 Croft & Gilmore [Page 1]
57 \f
60 RFC 951 September 1985
61 Bootstrap Protocol
64 3. The request can optionally contain the name of the server the
65 client wishes to respond. This is so the client can force the
66 boot to occur from a specific host (e.g. if multiple versions of
67 the same bootfile exist or if the server is in a far distant
68 net/domain). The client does not have to deal with name / domain
69 services; instead this function is pushed off to the BOOTP server.
71 4. The request can optionally contain the 'generic' filename to be
72 booted. For example 'unix' or 'ethertip'. When the server sends
73 the bootreply, it replaces this field with the fully qualified
74 path name of the appropriate boot file. In determining this name,
75 the server may consult his own database correlating the client's
76 address and filename request, with a particular boot file
77 customized for that client. If the bootrequest filename is a null
78 string, then the server returns a filename field indicating the
79 'default' file to be loaded for that client.
81 5. In the case of clients who do not know their IP addresses, the
82 server must also have a database relating hardware address to IP
83 address. This client IP address is then placed into a field in
84 the bootreply.
86 6. Certain network topologies (such as Stanford's) may be such
87 that a given physical cable does not have a TFTP server directly
88 attached to it (e.g. all the gateways and hosts on a certain cable
89 may be diskless). With the cooperation of neighboring gateways,
90 BOOTP can allow clients to boot off of servers several hops away,
91 through these gateways. See the section 'Booting Through
92 Gateways' below. This part of the protocol requires no special
93 action on the part of the client. Implementation is optional and
94 requires a small amount of additional code in gateways and
95 servers.
97 3. Packet Format
99 All numbers shown are decimal, unless indicated otherwise. The BOOTP
100 packet is enclosed in a standard IP [8] UDP [7] datagram. For
101 simplicity it is assumed that the BOOTP packet is never fragmented.
102 Any numeric fields shown are packed in 'standard network byte order',
103 i.e. high order bits are sent first.
105 In the IP header of a bootrequest, the client fills in its own IP
106 source address if known, otherwise zero. When the server address is
107 unknown, the IP destination address will be the 'broadcast address'
108 255.255.255.255. This address means 'broadcast on the local cable,
109 (I don't know my net number)' [4].
113 Croft & Gilmore [Page 2]
114 \f
117 RFC 951 September 1985
118 Bootstrap Protocol
121 The UDP header contains source and destination port numbers. The
122 BOOTP protocol uses two reserved port numbers, 'BOOTP client' (68)
123 and 'BOOTP server' (67). The client sends requests using 'BOOTP
124 server' as the destination port; this is usually a broadcast. The
125 server sends replies using 'BOOTP client' as the destination port;
126 depending on the kernel or driver facilities in the server, this may
127 or may not be a broadcast (this is explained further in the section
128 titled 'Chicken/Egg issues' below). The reason TWO reserved ports
129 are used, is to avoid 'waking up' and scheduling the BOOTP server
130 daemons, when a bootreply must be broadcast to a client. Since the
131 server and other hosts won't be listening on the 'BOOTP client' port,
132 any such incoming broadcasts will be filtered out at the kernel
133 level. We could not simply allow the client to pick a 'random' port
134 number for the UDP source port field; since the server reply may be
135 broadcast, a randomly chosen port number could confuse other hosts
136 that happened to be listening on that port.
138 The UDP length field is set to the length of the UDP plus BOOTP
139 portions of the packet. The UDP checksum field can be set to zero by
140 the client (or server) if desired, to avoid this extra overhead in a
141 PROM implementation. In the 'Packet Processing' section below the
142 phrase '[UDP checksum.]' is used whenever the checksum might be
143 verified/computed.
145 FIELD BYTES DESCRIPTION
146 ----- ----- -----------
148 op 1 packet op code / message type.
149 1 = BOOTREQUEST, 2 = BOOTREPLY
151 htype 1 hardware address type,
152 see ARP section in "Assigned Numbers" RFC.
153 '1' = 10mb ethernet
155 hlen 1 hardware address length
156 (eg '6' for 10mb ethernet).
158 hops 1 client sets to zero,
159 optionally used by gateways
160 in cross-gateway booting.
162 xid 4 transaction ID, a random number,
163 used to match this boot request with the
164 responses it generates.
166 secs 2 filled in by client, seconds elapsed since
167 client started trying to boot.
170 Croft & Gilmore [Page 3]
171 \f
174 RFC 951 September 1985
175 Bootstrap Protocol
178 -- 2 unused
180 ciaddr 4 client IP address;
181 filled in by client in bootrequest if known.
183 yiaddr 4 'your' (client) IP address;
184 filled by server if client doesn't
185 know its own address (ciaddr was 0).
187 siaddr 4 server IP address;
188 returned in bootreply by server.
190 giaddr 4 gateway IP address,
191 used in optional cross-gateway booting.
193 chaddr 16 client hardware address,
194 filled in by client.
196 sname 64 optional server host name,
197 null terminated string.
199 file 128 boot file name, null terminated string;
200 'generic' name or null in bootrequest,
201 fully qualified directory-path
202 name in bootreply.
204 vend 64 optional vendor-specific area,
205 e.g. could be hardware type/serial on request,
206 or 'capability' / remote file system handle
207 on reply. This info may be set aside for use
208 by a third phase bootstrap or kernel.
210 4. Chicken / Egg Issues
212 How can the server send an IP datagram to the client, if the client
213 doesnt know its own IP address (yet)? Whenever a bootreply is being
214 sent, the transmitting machine performs the following operations:
216 1. If the client knows its own IP address ('ciaddr' field is
217 nonzero), then the IP can be sent 'as normal', since the client
218 will respond to ARPs [5].
220 2. If the client does not yet know its IP address (ciaddr zero),
221 then the client cannot respond to ARPs sent by the transmitter of
222 the bootreply. There are two options:
224 a. If the transmitter has the necessary kernel or driver hooks
227 Croft & Gilmore [Page 4]
228 \f
231 RFC 951 September 1985
232 Bootstrap Protocol
235 to 'manually' construct an ARP address cache entry, then it can
236 fill in an entry using the 'chaddr' and 'yiaddr' fields. Of
237 course, this entry should have a timeout on it, just like any
238 other entry made by the normal ARP code itself. The
239 transmitter of the bootreply can then simply send the bootreply
240 to the client's IP address. UNIX (4.2 BSD) has this
241 capability.
243 b. If the transmitter lacks these kernel hooks, it can simply
244 send the bootreply to the IP broadcast address on the
245 appropriate interface. This is only one additional broadcast
246 over the previous case.
248 5. Client Use of ARP
250 The client PROM must contain a simple implementation of ARP, e.g. the
251 address cache could be just one entry in size. This will allow a
252 second-phase-only boot (TFTP) to be performed when the client knows
253 the IP addresses and bootfile name.
255 Any time the client is expecting to receive a TFTP or BOOTP reply, it
256 should be prepared to answer an ARP request for its own IP to
257 hardware address mapping (if known).
259 Since the bootreply will contain (in the hardware encapsulation) the
260 hardware source address of the server/gateway, the client MAY be able
261 to avoid sending an ARP request for the server/gateway IP address to
262 be used in the following TFTP phase. However this should be treated
263 only as a special case, since it is desirable to still allow a
264 second-phase-only boot as described above.
266 6. Comparison to RARP
268 An earlier protocol, Reverse Address Resolution Protocol (RARP) [1]
269 was proposed to allow a client to determine its IP address, given
270 that it knew its hardware address. However RARP had the disadvantage
271 that it was a hardware link level protocol (not IP/UDP based). This
272 means that RARP could only be implemented on hosts containing special
273 kernel or driver modifications to access these 'raw' packets. Since
274 there are many network kernels existent now, with each source
275 maintained by different organizations, a boot protocol that does not
276 require kernel modifications is a decided advantage.
278 BOOTP provides this hardware to IP address lookup function, in
279 addition to the other useful features described in the sections
280 above.
284 Croft & Gilmore [Page 5]
285 \f
288 RFC 951 September 1985
289 Bootstrap Protocol
292 7. Packet Processing
294 7.1. Client Transmission
296 Before setting up the packet for the first time, it is a good idea
297 to clear the entire packet buffer to all zeros; this will place
298 all fields in their default state. The client then creates a
299 packet with the following fields.
301 The IP destination address is set to 255.255.255.255. (the
302 broadcast address) or to the server's IP address (if known). The
303 IP source address and 'ciaddr' are set to the client's IP address
304 if known, else 0. The UDP header is set with the proper length;
305 source port = 'BOOTP client' port destination port = 'BOOTP
306 server' port.
308 'op' is set to '1', BOOTREQUEST. 'htype' is set to the hardware
309 address type as assigned in the ARP section of the "Assigned
310 Numbers" RFC. 'hlen' is set to the length of the hardware address,
311 e.g. '6' for 10mb ethernet.
313 'xid' is set to a 'random' transaction id. 'secs' is set to the
314 number of seconds that have elapsed since the client has started
315 booting. This will let the servers know how long a client has
316 been trying. As the number gets larger, certain servers may feel
317 more 'sympathetic' towards a client they don't normally service.
318 If a client lacks a suitable clock, it could construct a rough
319 estimate using a loop timer. Or it could choose to simply send
320 this field as always a fixed value, say 100 seconds.
322 If the client knows its IP address, 'ciaddr' (and the IP source
323 address) are set to this value. 'chaddr' is filled in with the
324 client's hardware address.
326 If the client wishes to restrict booting to a particular server
327 name, it may place a null-terminated string in 'sname'. The name
328 used should be any of the allowable names or nicknames of the
329 desired host.
331 The client has several options for filling the 'file' name field.
332 If left null, the meaning is 'I want to boot the default file for
333 my machine'. A null file name can also mean 'I am only interested
334 in finding out client/server/gateway IP addresses, I dont care
335 about file names'.
337 The field can also be a 'generic' name such as 'unix' or
341 Croft & Gilmore [Page 6]
342 \f
345 RFC 951 September 1985
346 Bootstrap Protocol
349 'gateway'; this means 'boot the named program configured for my
350 machine'. Finally the field can be a fully directory qualified
351 path name.
353 The 'vend' field can be filled in by the client with
354 vendor-specific strings or structures. For example the machine
355 hardware type or serial number may be placed here. However the
356 operation of the BOOTP server should not DEPEND on this
357 information existing.
359 If the 'vend' field is used, it is recommended that a 4 byte
360 'magic number' be the first item within 'vend'. This lets a
361 server determine what kind of information it is seeing in this
362 field. Numbers can be assigned by the usual 'magic number'
363 process --you pick one and it's magic. A different magic number
364 could be used for bootreply's than bootrequest's to allow the
365 client to take special action with the reply information.
367 [UDP checksum.]
369 7.2. Client Retransmission Strategy
371 If no reply is received for a certain length of time, the client
372 should retransmit the request. The time interval must be chosen
373 carefully so as not to flood the network. Consider the case of a
374 cable containing 100 machines that are just coming up after a
375 power failure. Simply retransmitting the request every four
376 seconds will inundate the net.
378 As a possible strategy, you might consider backing off
379 exponentially, similar to the way ethernet backs off on a
380 collision. So for example if the first packet is at time 0:00,
381 the second would be at :04, then :08, then :16, then :32, then
382 :64. You should also randomize each time; this would be done
383 similar to the ethernet specification by starting with a mask and
384 'and'ing that with with a random number to get the first backoff.
385 On each succeeding backoff, the mask is increased in length by one
386 bit. This doubles the average delay on each backoff.
388 After the 'average' backoff reaches about 60 seconds, it should be
389 increased no further, but still randomized.
391 Before each retransmission, the client should update the 'secs'
392 field. [UDP checksum.]
398 Croft & Gilmore [Page 7]
399 \f
402 RFC 951 September 1985
403 Bootstrap Protocol
406 7.3. Server Receives BOOTREQUEST
408 [UDP checksum.] If the UDP destination port does not match the
409 'BOOTP server' port, discard the packet.
411 If the server name field (sname) is null (no particular server
412 specified), or sname is specified and matches our name or
413 nickname, then continue with packet processing.
415 If the sname field is specified, but does not match 'us', then
416 there are several options:
418 1. You may choose to simply discard this packet.
420 2. If a name lookup on sname shows it to be on this same cable,
421 discard the packet.
423 3. If sname is on a different net, you may choose to forward
424 the packet to that address. If so, check the 'giaddr' (gateway
425 address) field. If 'giaddr' is zero, fill it in with my
426 address or the address of a gateway that can be used to get to
427 that net. Then forward the packet.
429 If the client IP address (ciaddr) is zero, then the client does
430 not know its own IP address. Attempt to lookup the client
431 hardware address (chaddr, hlen, htype) in our database. If no
432 match is found, discard the packet. Otherwise we now have an IP
433 address for this client; fill it into the 'yiaddr' (your IP
434 address) field.
436 We now check the boot file name field (file). The field will be
437 null if the client is not interested in filenames, or wants the
438 default bootfile. If the field is non-null, it is used as a
439 lookup key in a database, along with the client's IP address. If
440 there is a default file or generic file (possibly indexed by the
441 client address) or a fully-specified path name that matches, then
442 replace the 'file' field with the fully-specified path name of the
443 selected boot file. If the field is non-null and no match was
444 found, then the client is asking for a file we dont have; discard
445 the packet, perhaps some other BOOTP server will have it.
447 The 'vend' vendor-specific data field should now be checked and if
448 a recognized type of data is provided, client-specific actions
449 should be taken, and a response placed in the 'vend' data field of
450 the reply packet. For example, a workstation client could provide
455 Croft & Gilmore [Page 8]
456 \f
459 RFC 951 September 1985
460 Bootstrap Protocol
463 an authentication key and receive from the server a capability for
464 remote file access, or a set of configuration options, which can
465 be passed to the operating system that will shortly be booted in.
467 Place my (server) IP address in the 'siaddr' field. Set the 'op'
468 field to BOOTREPLY. The UDP destination port is set to 'BOOTP
469 client'. If the client address 'ciaddr' is nonzero, send the
470 packet there; else if the gateway address 'giaddr' is nonzero, set
471 the UDP destination port to 'BOOTP server' and send the packet to
472 'giaddr'; else the client is on one of our cables but it doesnt
473 know its own IP address yet --use a method described in the 'Egg'
474 section above to send it to the client. If 'Egg' is used and we
475 have multiple interfaces on this host, use the 'yiaddr' (your IP
476 address) field to figure out which net (cable/interface) to send
477 the packet to. [UDP checksum.]
479 7.4. Server/Gateway Receives BOOTREPLY
481 [UDP checksum.] If 'yiaddr' (your [the client's] IP address)
482 refers to one of our cables, use one of the 'Egg' methods above to
483 forward it to the client. Be sure to send it to the 'BOOTP
484 client' UDP destination port.
486 7.5. Client Reception
488 Don't forget to process ARP requests for my own IP address (if I
489 know it). [UDP checksum.] The client should discard incoming
490 packets that: are not IP/UDPs addressed to the boot port; are not
491 BOOTREPLYs; do not match my IP address (if I know it) or my
492 hardware address; do not match my transaction id. Otherwise we
493 have received a successful reply. 'yiaddr' will contain my IP
494 address, if I didnt know it before. 'file' is the name of the
495 file name to TFTP 'read request'. The server address is in
496 'siaddr'. If 'giaddr' (gateway address) is nonzero, then the
497 packets should be forwarded there first, in order to get to the
498 server.
500 8. Booting Through Gateways
502 This part of the protocol is optional and requires some additional
503 code in cooperating gateways and servers, but it allows cross-gateway
504 booting. This is mainly useful when gateways are diskless machines.
505 Gateways containing disks (e.g. a UNIX machine acting as a gateway),
506 might as well run their own BOOTP/TFTP servers.
508 Gateways listening to broadcast BOOTREQUESTs may decide to forward or
509 rebroadcast these requests 'when appropriate'. For example, the
512 Croft & Gilmore [Page 9]
513 \f
516 RFC 951 September 1985
517 Bootstrap Protocol
520 gateway could have, as part of his configuration tables, a list of
521 other networks or hosts to receive a copy of any broadcast
522 BOOTREQUESTs. Even though a 'hops' field exists, it is a poor idea
523 to simply globally rebroadcast the requests, since broadcast loops
524 will almost certainly occur.
526 The forwarding could begin immediately, or wait until the 'secs'
527 (seconds client has been trying) field passes a certain threshold.
529 If a gateway does decide to forward the request, it should look at
530 the 'giaddr' (gateway IP address) field. If zero, it should plug its
531 own IP address (on the receiving cable) into this field. It may also
532 use the 'hops' field to optionally control how far the packet is
533 reforwarded. Hops should be incremented on each forwarding. For
534 example, if hops passes '3', the packet should probably be discarded.
535 [UDP checksum.]
537 Here we have recommended placing this special forwarding function in
538 the gateways. But that does not have to be the case. As long as
539 some 'BOOTP forwarding agent' exists on the net with the booting
540 client, the agent can do the forwarding when appropriate. Thus this
541 service may or may not be co-located with the gateway.
543 In the case of a forwarding agent not located in the gateway, the
544 agent could save himself some work by plugging the broadcast address
545 of the interface receiving the bootrequest into the 'giaddr' field.
546 Thus the reply would get forwarded using normal gateways, not
547 involving the forwarding agent. Of course the disadvantage here is
548 that you lose the ability to use the 'Egg' non-broadcast method of
549 sending the reply, causing extra overhead for every host on the
550 client cable.
552 9. Sample BOOTP Server Database
554 As a suggestion, we show a sample text file database that the BOOTP
555 server program might use. The database has two sections, delimited
556 by a line containing an percent in column 1. The first section
557 contains a 'default directory' and mappings from generic names to
558 directory/pathnames. The first generic name in this section is the
559 'default file' you get when the bootrequest contains a null 'file'
560 string.
562 The second section maps hardware addresstype/address into an
563 ipaddress. Optionally you can also overide the default generic name
564 by supplying a ipaddress specific genericname. A 'suffix' item is
565 also an option; if supplied, any generic names specified by the
566 client will be accessed by first appending 'suffix' to the 'pathname'
569 Croft & Gilmore [Page 10]
570 \f
573 RFC 951 September 1985
574 Bootstrap Protocol
577 appropriate to that generic name. If that file is not found, then
578 the plain 'pathname' will be tried. This 'suffix' option allows a
579 whole set of custom generics to be setup without a lot of effort.
580 Below is shown the general format; fields are delimited by one or
581 more spaces or tabs; trailing empty fields may be omitted; blank
582 lines and lines beginning with '#' are ignored.
584 # comment line
586 homedirectory
587 genericname1 pathname1
588 genericname2 pathname2
589 ...
591 % end of generic names, start of address mappings
593 hostname1 hardwaretype hardwareaddr1 ipaddr1 genericname suffix
594 hostname2 hardwaretype hardwareaddr2 ipaddr2 genericname suffix
595 ...
597 Here is a specific example. Note the 'hardwaretype' number is the
598 same as that shown in the ARP section of the 'Assigned Numbers' RFC.
599 The 'hardwaretype' and 'ipaddr' numbers are in decimal;
600 'hardwareaddr' is in hex.
602 # last updated by smith
604 /usr/boot
605 vmunix vmunix
606 tip ethertip
607 watch /usr/diag/etherwatch
608 gate gate.
610 % end of generic names, start of address mappings
612 hamilton 1 02.60.8c.06.34.98 36.19.0.5
613 burr 1 02.60.8c.34.11.78 36.44.0.12
614 101-gateway 1 02.60.8c.23.ab.35 36.44.0.32 gate 101
615 mjh-gateway 1 02.60.8c.12.32.bc 36.42.0.64 gate mjh
616 welch-tipa 1 02.60.8c.22.65.32 36.47.0.14 tip
617 welch-tipb 1 02.60.8c.12.15.c8 36.46.0.12 tip
619 In the example above, if 'mjh-gateway' does a default boot, it will
620 get the file '/usr/boot/gate.mjh'.
626 Croft & Gilmore [Page 11]
627 \f
630 RFC 951 September 1985
631 Bootstrap Protocol
634 10. Acknowledgements
636 Ross Finlayson (et. al.) produced two earlier RFC's discussing TFTP
637 bootstraping [2] using RARP [1].
639 We would also like to acknowledge the previous work and comments of
640 Noel Chiappa, Bob Lyon, Jeff Mogul, Mark Lewis, and David Plummer.
642 REFERENCES
644 1. Ross Finlayson, Timothy Mann, Jeffrey Mogul, Marvin Theimer. A
645 Reverse Address Resolution Protocol. RFC 903, NIC, June, 1984.
647 2. Ross Finlayson. Bootstrap Loading using TFTP. RFC 906, NIC,
648 June, 1984.
650 3. Mark Lottor. Simple File Transfer Protocol. RFC 913, NIC,
651 September, 1984.
653 4. Jeffrey Mogul. Broadcasting Internet Packets. RFC 919, NIC,
654 October, 1984.
656 5. David Plummer. An Ethernet Address Resolution Protocol. RFC
657 826, NIC, September, 1982.
659 6. Jon Postel. File Transfer Protocol. RFC 765, NIC, June, 1980.
661 7. Jon Postel. User Datagram Protocol. RFC 768, NIC, August, 1980.
663 8. Jon Postel. Internet Protocol. RFC 791, NIC, September, 1981.
665 9. K. R. Sollins, Noel Chiappa. The TFTP Protocol. RFC 783, NIC,
666 June, 1981.
683 Croft & Gilmore [Page 12]
684 \f