Organization: China Interactive Publishing Network (http://www.china-pub.com/)
RFC Document Chinese Translation Program (http://www.china-pub.com/compters/emook/aboutemook.htm)
E-mail: Ouyang@china-pub.com
Translator: Jin Tao (PIEX Albertxu@bigfoot.com)
Translation time: 2001-07-05
Copyright: This Chinese translation copyright belongs to China Interactive Publishing Network. Can be used for non-commercial use free reprint, but must be retained
Document translation and copyright information.
Network Working Group Bill Croft (Stanford University)
Request for Comments: 951 John Gilmore (Sun Microsystems)
September 1985
Boot Protocol (bootp)
(RFC951-Bootstrap Protocol (bootp))
The state of this memo
This RFC document provides an proposed protocol to the ARPA-Internet community, which requires further discussion and recommendations.
To improve.
This document has no release limit.
table of Contents
1 Overview 2
2 pack format 3
3 chicken and egg problem 6
4 ARP uses 7 in the client
5 with RARP control 7
6 package processing 7
6.1 Client Transfer 7
6.2 Client Rebirth Strategy 9
6.3 Server Receive BootRequest (Boot Request) 9
6.4 Server / Gateway Receive BootReply (Boot Answer) 11
6.5 Client Receive 11
7 guided 11 through the gateway
8 sample BOOTP server database 12
9 Acknowledgments 14
10 Reference 14
1 Overview
This RFC describes an IP / UDP boot protocol (bootp) that allows a diskless client to find its IP address,
The address of the server host, and loads a file to memory and runs. The boot operation has two phases.
This RFC describes the first stage: 'Distribution Address and Select Boot File'.
After obtaining address and file name information, enter the second phase of the boot: file transfer.
File transfer generally uses TFTP protocols [9], because two phases reside in the client's PROM.
But BootP can also work with other protocols such as SFTP or FTP.
We recommend that the client's PROM software provides a complete boot mode without user interaction.
This is an unattended power-on starting method.
A mechanism must be provided to allow users to manually provide address and filename information bypass BootP protocol to enter file transfer
stage.
If you provide non-variable storage, we recommend saving settings to bypass BootP protocol until these settings lead to files.
The transfer phase failed.
If the cached information fails, the boot will be retracted to the first phase and use bootp.
The main points of the agreement:
1. Use a separate package exchange (information). Use the timeout mechanism until a response is received.
Use the same package field structure two-way. Simplify structural definitions using (maximum possible length) Fixed field
And analysis.
2. A 'OPCode' field contains two values. The client broadcasts a 'boot request (BootRequest)' package.
The server answers a 'booteply' package. 'BootRequest' contains the hardware address of the client, if you know,
It also contains its IP address.
3. The request can contain the name of the response server specified by the client.
This allows the client to force from a specified host. (If there is a variety of versions of the same boot file
Or servers in a remote network / domain. )
The client does not have to deal with the name / domain service, which is pushed to the BOOTP server.
4. Requests can contain 'universal' boot file names. For example, 'UNIX' or 'EtherTIP'. But server sends
When the response is acknowledged, it replaces this field using the exact path name of the corresponding boot file.
The server queries the client's address and requests the file name related database to use the specific boot of the client.
The file determines this file name.
If the boot request file name is an empty string, the server returns a file name with the default file loaded with the client.
Field.
5. The client does not know if their IP addresses are
The server must have a database corresponding to a hardware address and an IP address.
This client IP address is placed in the (corresponding) field of the boot response.
6. Some network tops (such as Stanford's network) may not have a TFTP that can be accessed directly on a physical website
server
For example, all gateways and hosts on some online may be free).
BootP allows the client to boot by using the adjacent gateways from several jumped servers. Please see below 'through the gateway
The chapter of boot '.
This part of the agreement does not require the client part to do specific actions.
Implementation is an optional, gateway and server require some extra code.
2 pack format
Unless otherwise indicated, all displayed numbers are decimal.
Simplification, assuming that the bootp package will not be shard.
All numbers field use the standard network byte order. That is, the high bit is first transmitted.
In the IP header of the guidance request, if you know your IP source address, you will fall. When the server address is not known
Time,
The IP destination address will be broadcast address 255.255.255.255. This address means' in the local online broadcast, I don't know me.
The network number '[4].
The UDP header contains the source and destination port number. Bootp protocol uses two reserved port numbers, 'bootp client' (68)
And 'BootP Server' (67).
The customer uses the 'BootP server' as the destination port to send a request; this is usually broadcast.
The server uses the 'bootp client' as the destination port to send a response; depending on the core or drive device of the server.
Can you or may not be broadcast?
(Explanation in the chapter of the 'chicken and eggs in the following.
The reason for using two reserved ports is that when the boot response must be broadcast to the client to avoid 'waken' and scheduling booTP service
Worker process.
Because the server and other hosts will not listen to the 'bootp client' port,
All entered broadcast messages will be filtered out at the core level.
We cannot simply allow the client to find a random port number as a UDP source port field; because the server answers may
Is broadcast,
A randomly selected port number may mess with the host happens to listen to the port.
The UDP length field is set to the UDP length plus the BOOTP section.
UDP checksum can be set to 0 by client (or server) to avoid additional costs in the PROM implementation.
The '[UDP checksum]' phrase 'phrase is used to represent the check and possible verification / calculation.
Field byte number description
---------------------
OP 1 Packet Op Code / Message Type. Package Operations / Message Types
1 = BootRequest (Boot Request), 2 = BootReply (Boot Answer)
HTYPE 1 Hardware Address Type, Hardware Address Type
See Arp Section in "Assigned Numbers" RFC. Please see the ARP chapter in "AssignedNumBers" RFC
'1' = 10MB Ethernet 10m Ethernet
HLEN 1 Hardware Address Length Hardware Address Length
(EG '6' for 10MB Ethernet. For example, '6' is 10M Ethernet
HOPS 1 Client sets to zero, the client is set to 0
Optionally Used by Gateways can choose to use when guided by the gateway
IN cross-gateway booting.
XID 4 Transaction ID, A Random Number,
Used to match this boot request with the
Responses it generates. Transaction ID, a random number, used to match the reference request
Respond
SECS 2 Filled in by Client, Seconds Elapsed Since
Client Started Trying to Boot. Filtrated by the client, after the client boots
In the past
- 2 unused unused
Ciaddr 4 Client IP Address; client IP address,
Filled in by Client in BootRequest if know. If the client knows is booting
Fill in the request
Yiaddr 4 'Your' (client) ip address; 'Your' (Client) IP address
Filled by Server if Client Doesn't
KNOW ITS OWN Address (Ciaddr Was 0). If the client doesn't know its address
(Ciaddr is 0), the server fills in
Siaddr 4 Server IP Address; server IP address
Returned in bootreply by Server. Returns by the server in the boot response
Giaddr 4 Gateway IP Address, Gateway IP Address
Used in Optional Cross-Gateway Booting. You can choose from across gateway boots
use
Chaddr 16 Client Hardware Address, client hardware address
Filled in by client.
Sname 64 Optional Server Host Name, optional server host name
Null Terminated String. String of the Empty End
File 128 Boot File Name, Null Terminated String; Boot File Name, String of Empty End
'Generic' Name or Null in BootRequest, use the 'universal' name in the boot request
Empty
Fully Qualified Directory-Path is the use of exact objects in boot response
Recording path name
Name in bootreply.
Vend 64 Optional Vendor-Specific Area, an optional seller designated area,
E.g. Could Be Hardware Type / Serial On Request, for example, can be a request hardware
Type / sequence,
OR 'Capability' / Remote File System Handle or Responding Performance / Remote File System Handle.
On Reply. This Info May Be set aside for USE This information is left to third parties
Analyze boot or core (program).
By a third phasebootstrap or kernel.
3 chicken and egg problems
If the client doesn't know your IP address, the server sends an IP packet to the client.
Whenever a boot response is sent, the sending device performs the following operations:
1. If the client knows your IP address (the 'ciadr' field is not zero),
Because the client can respond to ARPS [5], IP can be sent normally.
2. If the client still doesn't know your IP address (Ciaddr is zero),
The client cannot respond to the ARPS back to the boot response sender. There are two options at this time:
a. If the sender has the necessary core or drive hook programs to manually establish an ARP address buffer entry,
You can fill in an entry using the 'Chaddr' and 'Yiaddr' fields. Of course, this item is based on normal ARP.
There is a life time like other entries.
The transmit procedure of the boot response can simply send the boot response to the client's IP address. UNIX (4.2
BSD) has this function.
b. If the sender lacks these core hook programs, it can only simply send boot response to the broadcast of the corresponding interface.
address.
This is just an additional broadcast outside the previous situation.
4 ARP is used in the client
Client PROM must include an ARP simple implementation, for example, address buffer can accommodate an entry.
This will allow the client to perform the second phase boot (TFTP) after knowing the IP address and the boot file name.
At any time, the client should be prepared to respond to an ARP request (if you know) to receive your own IP to the hardware address.
TFTP or Bootp response.
Because the boot response will contain the hardware source address of the server / gateway (package in hardware), the client can
Avoid sending an ARP request to apply for a server / gateway IP address used in subsequent TFTP phases.
But this should be just a special case because only the second phase of boot described above is still allowed.
5 with RARP
Propose the client to use an earlier protocol, reverse address analysis protocol (RARP) [1] to determine from its hardware address
IP address.
However, Rarp's disadvantages are a protocol of a hardware link layer (not IP / UDP).
This means that RARP can only be implemented on the core and drive-driven hosts that include special packet modifications.
Because there are now many network cores that have different organizations maintained, a boot protocol that does not require the modification of the core is a certainment
The advantages.
In addition to the useful features described above, BOOTP provides a query function of hardware to IP addresses.
6 package processing
6.1 Client Transfer
Before the first establishment package, it is best to clear the buffer of the entire package;
This sets all the fields into default status. Any client established the following fields in the package.
The IP destination address is set to 255.255.255.255 (broadcast address) or the server's IP address (if you know).
The IP source address and 'CIADDR' are set to client IP addresses (if you know), or 0. UDP header uses the appropriate length
Set;
Source port = 'bootp client' port, target port = 'bootp server' port.
'OP' is set to '1', BootRequest (boot request). 'htype' is set to the hardware address type allocated in the "AssignedNumbers" RFC ARP chapter.
'hlen' is set to hardware address length, for example, 10M Ethernet is '6'.
'XID' is set to a 'random' transaction ID. 'secs' is set to the client boot the number of seconds after the start.
This allows the server to know how long the client has tried.
When the numbers become large, some servers may pay more attention to this client to provide different services.
If the client lacks an appropriate clock, it can create a rough estimate using a loop timer.
Or it can choose to simply send the use of a fixed value such as 100 seconds.
If the client knows the IP address, 'CIADDR' (and IP source addresses) is set to this value.
'CHADDR' is filled in using the client hardware address.
If the client wants to limit the boot from a specific server name, you can put an empty end in 'sname'.
string.
The name used should be the proper name or alias of the corresponding host.
The client has many options in filling the 'file' file name field.
If you set it an empty, it means 'I use the default file to guide my machine'. An empty document name also means
'I only interested in finding the IP address of the client / server / gateway, I don't care the file name'.
This field can also be a 'universal' name into 'UNIX' or 'Gateway'; this means
'Use a named program configuration to guide my machine'. Finally, this field can be the exact directory path name.
The 'Vend' field can be fill the string or structure of the seller by the client. For example, you can fill in the machine hardware type or sequence
number.
But the operation of the BootP server should not rely on information that exists with these.
If the 'vend' is used, it is recommended to be a 4-byte 'magic number' in 'vend'.
This allows the server to determine what type of information it sees in this field.
The value can be allocated by the usual 'magic word' process, you pick one, it becomes a magic word.
The boot response uses a magic word different from the guidance request to allow the client to make special movements according to the response information.
Work.
[UDP checksum]
6.2 Client retransmission strategy
There is no response in a long period of time, and the client should retransmit the request.
The time interval must be carefully selected not to cause the network storm.
It can be considered that a network that contains 100 machines occurs after the power failure.
Simple summary requests will be overwhelmed.
A possible strategy, you may consider the compensation of the exponential level, like Ethernet in the collision.
For example, the first package is at 0:00, the second at: 04, then: 08, then: 16,: 32,: 64.
You should randomize each time; this is like a mask 'with a random number as the first complement like an Ethernet specification.
Compend.
In each subsequent compensation, the mask increases a bit.
This differs in each compensation.
After the 'average' compensation arrives for 60 seconds, it will no longer grow, but still randomly.
The client should modify the 'secs' field before each retransmission. [UDP checksum]
6.3 Server Receive BootRequest (Boot Request)
[UDP checksum] If the UDP destination port does not match the 'Bootp Server' port, this package is discarded.
If the server name field (SNAME) is empty (no specific server), or SNAME is specified and matches our name or alias,
The process of continuing the package.
If the sname field is specified, do not match 'we', there are many options:
1. You can choose to simply discard this package.
2. If the name of the query SNAME is displayed in a network, discard this package.
3. If SNAME is in different networks, you can choose to forward this package to that address.
If so, check the 'gaddr' (gateway address) field. If 'gaddr' is 0, fill in my address or can be used
Arrive at the address of the gateway of that network.
Then forward this package.
If the client IP address (CIADDR) is 0, then the client doesn't know his IP address.
Try finding the client's hardware address (Chaddr, Hlen, HTYPE) in our database.
If there is no match, discard this package. Otherwise, we now have an IP address on this client; fill in 'yiaddr' (you
IP address) field.
We now check the boot file name field (file). If the client does not pay attention to the file name or want the default boot file,
This field is empty.
If this field is non-empty, you can make it and the client's IP address as the database of the query keyword.
If there is a default file or universal file (possibly by the client address as an index) or a matching specified path
name,
Then fill the specified path name of the selected boot file in the 'File' field.
If the field is non-empty and does not match, then the client wants a file we have, discarding this package, maybe
Other bootp servers have this file.
The data field specified by the seller 'Vend' should now be checked. If you provide an identifiable type of data,
The client should be performed, and the 'Vend' data field to be filled in the answer package should be recalled.
For example, a workstation client may provide a verification word and receive an access to the remote file from the server.
limit,
Or a set of configuration options is transmitted to the operating system to be guided immediately.
My (server) IP address fills in the 'siaddr' field. Set the 'op' field for bootreply.
The UDP destination port is set to 'bootp client'. If the client address 'Ciaddr' is not 0, send the package to there;
Otherwise, if the gateway address 'gaddr' is not 0, set the UDP destination port to the 'bootp server' and send the package to
'gaddr'.
Otherwise the client is in our network but it still doesn't know his IP address, and is described in the 'Egg' chapter above.
The method to transmit it to the client.
If you use 'egg' and we have a number of interfaces on the host, use the 'Yiaddr' (your IP address) field to point out the send package
Which network (network / interface) is to.
[UDP checksum]
6.4 Server / Gateway Receive BootReply (Boot Answer)
[UDP checksum] If 'yiaddr' (your [client's] IP address) points to our network, use the above 'egg'
The law forwarded it to the client.
Confirm to transfer it to the port of the 'BOOTP client' UDP destination.
6.5 Client Receive
Don't forget to process the ARP request for my own IP address (if I know). [UDP checksum]
The client should discard the following packets: IP / UDP positioned to the boot port; not bootreply
Guide answer);
Do not match my IP address (if I know) or my hardware address; don't match my transaction ID.
Otherwise, we receive a successful response. If I didn't know before, 'Yiaddr' contained my IP address.
'file' is the file name of the TFTP 'read request'. The server address is in 'siaddr'. If 'gaddr' (gateway address) is not 0,
Then the package should be forwarded there and then reach the server.
7 guided by gateway
This part of the protocol is optional and requires a number of additional code that cooperates with the server, but it allows you to boot across the gateway.
This is mainly useful when the gateway is a diskless machine.
With a disk gateway (for example, a Unix machine as a gateway) might run their own BootP / TFTP server.
The gateway listening to BootRequest broadcasts may determine that forwarding these requests will be broadcast rapidly.
For example, as part of the configuration table, the gateway can have a reception of any bootRequest (boot request)
A list of other networks or hosts broadcast.
Even if you consider there is a 'hops' field, the simple all of the broadcast request is still a poor method because the broadcast loop is almost will
Said.
Forward, you can start now, or wait for 'Secs' (second number of client attempts) fields more than a certain threshold.
If a gateway determines the forwarding request, it should look at the 'GiaDDR' (Gateway IP Address) field.
If it is 0, it adds its own IP address in this field (in the received network).
You can also use the 'hops' field to select the control package to forward how far. Each forwarding should increase the number of hops.
For example, if the number of hops exceeds '3', the package should be discarded.
[UDP checksum]
Here we recommend adding this special forwarding function in the gateway.
But not always like this.
There are some 'bootp forwarding proxy' boot the client on the Internet, which can forward appropriately.
Thus these services can be together with the gateway or not together.
When the forwarding agent is not with the gateway, the agent can add the port of the interface by adding the 'gaddr' field in the received boot request.
The play address saves some work.
This response can be used to forward without including the forwarding agent.
Of course, the disadvantage is that you have lost your ability to use 'egg' non-broadcast methods, resulting in each host on the client online.
Extra cost.
8 sample bootp server database
As a suggestion, we offer a sample text file database that can be used by a BOOTP server query.
There are two sections in the database, and the lines use a row using a percentage as a delimiter.
The first section contains a 'default directory', and mapping from the general name to the directory / path.
The first general name in this section is that when the reference request contains a space 'file' string is the 'default file' you use.
The second section maps the hardware address type / address to the IP address. Optional, you can use a universal name of a specific IP address
To ignore the default universal name.
A 'suffix' project is also optional; if provided, access to any client-specific general name corresponding to the 'path name
Symmers' plus' suffix '.
If the file is not found, try the simple 'path name'.
This 'suffix' option allows you to easily establish a complete user universal (configuration). The universal format is displayed; one or more spaces or tabs are bounded by the field; the late empty fields are omitted; empty lines and with '#'
Started trip.
# 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
...
This is a specific sample. Note the 'hardware type' value is the ARP section in 'Assigned NumBers' RFC.
'Hardware type' and 'IP address' value is a decimal; 'hardware address' is hexadecimal.
# 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 above case, if 'MJH-Gateway' is a default boot program, it will get file '/usr/boot/gate.mjh'.
9 thank you
Ross Finlayson, etc., first proposed two RFCs that use the TFTP boot boot that discuss RARP [1].
We thank NOEL Chiappa, Bob Lyon, Jeff Mogul, Mark Lewis, and the preliminary work of David Plummer and
annotation.
10 reference
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. RFC826, 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.
RFC951 - RFC951-Bootstrap Protocol (BootP) Boot Protocol (BootP)
1
RFC Document Chinese Translation Program
