diff options
Diffstat (limited to 'doc/rfc951.txt')
| -rw-r--r-- | doc/rfc951.txt | 684 |
1 files changed, 0 insertions, 684 deletions
diff --git a/doc/rfc951.txt b/doc/rfc951.txt deleted file mode 100644 index 86cd69e6..00000000 --- a/doc/rfc951.txt +++ /dev/null @@ -1,684 +0,0 @@ - - -Network Working Group Bill Croft (Stanford University) -Request for Comments: 951 John Gilmore (Sun Microsystems) - September 1985 - - BOOTSTRAP PROTOCOL (BOOTP) - - -1. Status of this Memo - - This RFC suggests a proposed protocol for the ARPA-Internet - community, and requests discussion and suggestions for improvements. - Distribution of this memo is unlimited. - -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: - - 1. 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. - - 2. 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. - - -Croft & Gilmore [Page 1] - - - -RFC 951 September 1985 -Bootstrap Protocol - - - 3. 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. - - 4. 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. - - 5. 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. - - 6. 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. - -3. Packet Format - - All numbers shown are decimal, unless indicated otherwise. The BOOTP - packet is enclosed in a standard IP [8] UDP [7] datagram. For - 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 IP - source address if known, otherwise zero. When the server address is - 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 Protocol - - - The UDP header contains source and destination port numbers. The - BOOTP protocol uses two reserved port numbers, 'BOOTP client' (68) - and 'BOOTP server' (67). The client sends requests using 'BOOTP - server' as the destination port; this is usually a broadcast. The - server sends replies using 'BOOTP client' as the destination port; - depending on the kernel or driver facilities in the server, this may - or may not be a broadcast (this is explained further in the section - titled 'Chicken/Egg issues' below). The reason TWO reserved ports - are used, is to avoid 'waking up' and scheduling the BOOTP server - daemons, when a bootreply must be broadcast to a client. Since the - server and other hosts won't be listening on the 'BOOTP client' port, - any such incoming broadcasts will be filtered out at the kernel - level. We could not simply allow the client to pick a 'random' port - number for the UDP source port field; since the server reply may be - broadcast, a randomly chosen port number could confuse other hosts - that happened to be listening on that port. - - The UDP length field is set to the length of the UDP plus BOOTP - portions of the packet. The UDP checksum field can be set to zero by - the client (or server) if desired, to avoid this extra overhead in a - PROM implementation. In the 'Packet Processing' section below the - phrase '[UDP checksum.]' is used whenever the checksum might be - verified/computed. - - FIELD BYTES DESCRIPTION - ----- ----- ----------- - - op 1 packet op code / message type. - 1 = BOOTREQUEST, 2 = BOOTREPLY - - htype 1 hardware address type, - see ARP section in "Assigned Numbers" RFC. - '1' = 10mb ethernet - - hlen 1 hardware address length - (eg '6' for 10mb ethernet). - - hops 1 client sets to zero, - optionally used by gateways - in cross-gateway booting. - - xid 4 transaction ID, a random number, - used to match this boot request with the - responses it generates. - - secs 2 filled in by client, seconds elapsed since - client started trying to boot. - - -Croft & Gilmore [Page 3] - - - -RFC 951 September 1985 -Bootstrap Protocol - - - -- 2 unused - - 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't - 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-path - name in bootreply. - - vend 64 optional vendor-specific area, - e.g. could be hardware type/serial on request, - or 'capability' / remote file system handle - on reply. This info may be set aside for use - by a third phase bootstrap or kernel. - -4. Chicken / Egg Issues - - How can the server send an IP datagram to the client, if the client - doesnt know its own IP address (yet)? Whenever a bootreply is being - sent, the transmitting machine performs the following operations: - - 1. If the client knows its own IP address ('ciaddr' field is - nonzero), then the IP can be sent 'as normal', since the client - 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 of - the bootreply. There are two options: - - a. If the transmitter has the necessary kernel or driver hooks - - -Croft & Gilmore [Page 4] - - - -RFC 951 September 1985 -Bootstrap Protocol - - - to 'manually' construct an ARP address cache entry, then it can - fill in an entry using the 'chaddr' and 'yiaddr' fields. Of - course, this entry should have a timeout on it, just like any - other entry made by the normal ARP code itself. The - transmitter of the bootreply can then simply send the bootreply - to the client's IP address. UNIX (4.2 BSD) has this - capability. - - b. If the transmitter lacks these kernel hooks, it can simply - send the bootreply to the IP broadcast address on the - appropriate interface. This is only one additional broadcast - over the previous case. - -5. Client Use of ARP - - The client PROM must contain a simple implementation of ARP, e.g. the - address cache could be just one entry in size. This will allow a - second-phase-only boot (TFTP) to be performed when the client knows - the IP addresses and bootfile name. - - Any time the client is expecting to receive a TFTP or BOOTP reply, it - should be prepared to answer an ARP request for its own IP to - hardware address mapping (if known). - - Since the bootreply will contain (in the hardware encapsulation) the - hardware source address of the server/gateway, the client MAY be able - to avoid sending an ARP request for the server/gateway IP address to - be used in the following TFTP phase. However this should be treated - only as a special case, since it is desirable to still allow a - second-phase-only boot as described above. - -6. Comparison to RARP - - An earlier protocol, Reverse Address Resolution Protocol (RARP) [1] - 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. - - BOOTP provides this hardware to IP address lookup function, in - addition to the other useful features described in the sections - above. - - - -Croft & Gilmore [Page 5] - - - -RFC 951 September 1985 -Bootstrap Protocol - - -7. Packet Processing - - 7.1. Client Transmission - - Before setting up the packet for the first time, it is a good idea - to clear the entire packet buffer to all zeros; this will place - all fields in their default state. The client then creates a - packet with the following fields. - - The IP destination address is set to 255.255.255.255. (the - broadcast address) or to the server's IP address (if known). The - IP source address and 'ciaddr' are set to the client's IP address - if known, else 0. The UDP header is set with the proper length; - source port = 'BOOTP client' port destination port = 'BOOTP - server' port. - - 'op' is set to '1', BOOTREQUEST. 'htype' is set to the hardware - address type as assigned in the ARP section of the "Assigned - 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 the - number of seconds that have elapsed since the client has started - booting. This will let the servers know how long a client has - been trying. As the number gets larger, certain servers may feel - more 'sympathetic' towards a client they don't normally service. - If a client lacks a suitable clock, it could construct a rough - estimate using a loop timer. Or it could choose to simply send - this field as always a fixed value, say 100 seconds. - - If the client knows its IP address, 'ciaddr' (and the IP source - address) are set to this value. 'chaddr' is filled in with the - client's hardware address. - - If the client wishes to restrict booting to a particular server - name, it may place a null-terminated string in 'sname'. The name - used should be any of the allowable names or nicknames of the - 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 for - my machine'. A null file name can also mean 'I am only interested - in finding out client/server/gateway IP addresses, I dont care - about file names'. - - The field can also be a 'generic' name such as 'unix' or - - - -Croft & Gilmore [Page 6] - - - -RFC 951 September 1985 -Bootstrap Protocol - - - 'gateway'; this means 'boot the named program configured for my - machine'. Finally the field can be a fully directory qualified - path name. - - The 'vend' field can be filled in by the client with - vendor-specific strings or structures. For example the machine - hardware type or serial number may be placed here. However the - operation of the BOOTP server should not DEPEND on this - information existing. - - If the 'vend' field is used, it is recommended that a 4 byte - 'magic number' be the first item within 'vend'. This lets a - server determine what kind of information it is seeing in this - field. Numbers can be assigned by the usual 'magic number' - process --you pick one and it's magic. A different magic number - could be used for bootreply's than bootrequest's to allow the - client to take special action with the reply information. - - [UDP checksum.] - - 7.2. Client Retransmission Strategy - - If no reply is received for a certain length of time, the client - should retransmit the request. The time interval must be chosen - carefully so as not to flood the network. Consider the case of a - cable containing 100 machines that are just coming up after a - power failure. Simply retransmitting the request every four - seconds will inundate the net. - - As a possible strategy, you might consider backing off - exponentially, similar to the way ethernet backs off on a - 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, then - :64. You should also randomize each time; this would be done - similar to the ethernet specification by starting with a mask and - 'and'ing that with with a random number to get the first backoff. - On each succeeding backoff, the mask is increased in length by one - bit. This doubles the average delay on each backoff. - - After the 'average' backoff reaches about 60 seconds, it should be - 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 Protocol - - - 7.3. Server Receives BOOTREQUEST - - [UDP checksum.] If the UDP destination port does not match the - 'BOOTP server' port, discard the packet. - - If the server name field (sname) is null (no particular server - specified), or sname is specified and matches our name or - nickname, then continue with packet processing. - - If the sname field is specified, but does not match 'us', then - 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 forward - the packet to that address. If so, check the 'giaddr' (gateway - address) field. If 'giaddr' is zero, fill it in with my - address or the address of a gateway that can be used to get to - that net. Then forward the packet. - - If the client IP address (ciaddr) is zero, then the client does - not know its own IP address. Attempt to lookup the client - hardware address (chaddr, hlen, htype) in our database. If no - match is found, discard the packet. Otherwise we now have an IP - address for this client; fill it into the 'yiaddr' (your IP - address) field. - - We now check the boot file name field (file). The field will be - null if the client is not interested in filenames, or wants the - default bootfile. If the field is non-null, it is used as a - lookup key in a database, along with the client's IP address. If - there is a default file or generic file (possibly indexed by the - client address) or a fully-specified path name that matches, then - replace the 'file' field with the fully-specified path name of the - selected boot file. If the field is non-null and no match was - found, then the client is asking for a file we dont have; discard - the packet, perhaps some other BOOTP server will have it. - - The 'vend' vendor-specific data field should now be checked and if - a recognized type of data is provided, client-specific actions - should be taken, and a response placed in the 'vend' data field of - the reply packet. For example, a workstation client could provide - - - - -Croft & Gilmore [Page 8] - - - -RFC 951 September 1985 -Bootstrap Protocol - - - an authentication key and receive from the server a capability for - remote file access, or a set of configuration options, which can - 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 'BOOTP - client'. If the client address 'ciaddr' is nonzero, send the - packet there; else if the gateway address 'giaddr' is nonzero, set - the UDP destination port to 'BOOTP server' and send the packet to - 'giaddr'; else the client is on one of our cables but it doesnt - 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 we - have multiple interfaces on this host, use the 'yiaddr' (your IP - address) field to figure out which net (cable/interface) to send - the packet to. [UDP checksum.] - - 7.4. Server/Gateway Receives BOOTREPLY - - [UDP checksum.] If 'yiaddr' (your [the client's] IP address) - refers to one of our cables, use one of the 'Egg' methods above to - forward it to the client. Be sure to send it to the 'BOOTP - client' UDP destination port. - - 7.5. Client Reception - - Don't forget to process ARP requests for my own IP address (if I - know it). [UDP checksum.] The client should discard incoming - packets that: are not IP/UDPs addressed to the boot port; are not - BOOTREPLYs; do not match my IP address (if I know it) or my - hardware address; do not match my transaction id. Otherwise we - have received a successful reply. 'yiaddr' will contain my IP - address, if I didnt know it before. 'file' is the name of the - file name to TFTP 'read request'. The server address is in - 'siaddr'. If 'giaddr' (gateway address) is nonzero, then the - packets should be forwarded there first, in order to get to the - server. - -8. Booting Through Gateways - - This part of the protocol is optional and requires some additional - code in cooperating gateways and servers, but it allows cross-gateway - 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 or - rebroadcast these requests 'when appropriate'. For example, the - - -Croft & Gilmore [Page 9] - - - -RFC 951 September 1985 -Bootstrap Protocol - - - gateway could have, as part of his configuration tables, a list of - other networks or hosts to receive a copy of any broadcast - BOOTREQUESTs. Even though a 'hops' field exists, it is a poor idea - to simply globally rebroadcast the requests, since broadcast loops - 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 at - the 'giaddr' (gateway IP address) field. If zero, it should plug its - own IP address (on the receiving cable) into this field. It may also - use the 'hops' field to optionally control how far the packet is - reforwarded. Hops should be incremented on each forwarding. For - example, if hops passes '3', the packet should probably be discarded. - [UDP checksum.] - - Here we have recommended placing this special forwarding function in - the gateways. But that does not have to be the case. As long as - some 'BOOTP forwarding agent' exists on the net with the booting - client, the agent can do the forwarding when appropriate. Thus this - service may or may not be co-located with the gateway. - - In the case of a forwarding agent not located in the gateway, the - agent could save himself some work by plugging the broadcast address - of the interface receiving the bootrequest into the 'giaddr' field. - Thus the reply would get forwarded using normal gateways, not - involving the forwarding agent. Of course the disadvantage here is - that you lose the ability to use the 'Egg' non-broadcast method of - sending the reply, causing extra overhead for every host on the - client cable. - -9. Sample BOOTP Server Database - - As a suggestion, we show a sample text file database that the BOOTP - server program might use. The database has two sections, delimited - by a line containing an percent in column 1. The first section - contains a 'default directory' and mappings from generic names to - directory/pathnames. The first generic name in this section is the - 'default file' you get when the bootrequest contains a null 'file' - string. - - The second section maps hardware addresstype/address into an - ipaddress. Optionally you can also overide the default generic name - by supplying a ipaddress specific genericname. A 'suffix' item is - also an option; if supplied, any generic names specified by the - client will be accessed by first appending 'suffix' to the 'pathname' - - -Croft & Gilmore [Page 10] - - - -RFC 951 September 1985 -Bootstrap Protocol - - - appropriate to that generic name. If that file is not found, then - the plain 'pathname' will be tried. This 'suffix' option allows a - whole set of custom generics to be setup without a lot of effort. - Below is shown the general format; fields are delimited by one or - more spaces or tabs; trailing empty fields may be omitted; blank - lines and lines beginning with '#' are ignored. - - # comment line - - homedirectory - genericname1 pathname1 - genericname2 pathname2 - ... - - % end of generic names, start of address mappings - - hostname1 hardwaretype hardwareaddr1 ipaddr1 genericname suffix - hostname2 hardwaretype hardwareaddr2 ipaddr2 genericname suffix - ... - - Here is a specific example. Note the 'hardwaretype' number is the - 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 smith - - /usr/boot - vmunix vmunix - tip ethertip - watch /usr/diag/etherwatch - gate gate. - - % end of generic names, start of address mappings - - 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 mjh - welch-tipa 1 02.60.8c.22.65.32 36.47.0.14 tip - welch-tipb 1 02.60.8c.12.15.c8 36.46.0.12 tip - - In the example above, if 'mjh-gateway' does a default boot, it will - get the file '/usr/boot/gate.mjh'. - - - - - -Croft & Gilmore [Page 11] - - - -RFC 951 September 1985 -Bootstrap Protocol - - -10. Acknowledgements - - Ross Finlayson (et. al.) produced two earlier RFC's discussing TFTP - bootstraping [2] using RARP [1]. - - We would also like to acknowledge the previous work and comments of - Noel Chiappa, Bob Lyon, Jeff Mogul, Mark Lewis, and David Plummer. - -REFERENCES - - 1. Ross Finlayson, Timothy Mann, Jeffrey Mogul, Marvin Theimer. A - 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. RFC - 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] - |