Movatterモバイル変換
[0]ホーム
[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Errata] [Info page]
Obsoleted by:1350 UNKNOWN
Errata ExistNetwork Working Group K. R. SollinsRequest for Comments: 783 MIT June, 1981Updates: IEN 133 THE TFTP PROTOCOL (REVISION 2) Summary TFTP is a very simple protocol used to transfer files. It is fromthis that its name comes, Trivial File Transfer Protocol or TFTP. Eachnonterminal packet is acknowledged separately. This document describesthe protocol and its types of packets. The document also explains thereasons behind some of the design decisions.
ACKNOWLEDGEMENTS The protocol was originally designed by Noel Chiappa, and wasredesigned by him, Bob Baldwin and Dave Clark, with comments from SteveSzymanski. The current revision of the document includes modificationsstemming from discussions with and suggestions from Larry Allen, NoelChiappa, Dave Clark, Geoff Cooper, Mike Greenwald, Liza Martin, DavidReed, Craig Milo Rogers (of UCS-ISI), Kathy Yellick, and the author.The acknowledgement and retransmission scheme was inspired by TCP, andthe error mechanism was suggested by PARC's EFTP abort message.This research was supported by the Advanced Research Projects Agency ofthe Department of Defense and was monitored by the Office of NavalResearch under contract number N00014-75-C-0661. 2
1. Purpose TFTP is a simple protocol to transfer files, and therefore was namedthe Trivial File Transfer Protocol or TFTP. It has been implemented ontop of the Internet User Datagram protocol (UDP or Datagram) [2] so itmay be used to move files between machines on different networksimplementing UDP. (This should not exlude the possibility ofimplementing TFTP on top of other datagram protocols.) It is designedto be small and easy to implement. Therefore, it lacks most of thefeatures of a regular FTP. The only thing it can do is read and writefiles (or mail) from/to a remote server. It cannot list directories,and currently has no provisions for user authentication. In common withother Internet protocols, it passes 8 bit bytes of data. 1 2 Three modes of transfer are currently supported: netascii ; octet ,raw 8 bit bytes; mail, netascii characters sent to a user rather than afile. Additional modes can be defined by pairs of cooperating hosts._______________ 1 This is ascii as defined in "USA Standard Code for InformationInterchange" [1] with the modifications specified in "Telnet ProtocolSpecification" [3]. Note that it is 8 bit ascii. The term "netascii"will be used throughout this document to mean this particular version ofascii. 2 This replaces the "binary" mode of previous versions of this 3
2. Overview of the Protocol Any transsfer begins with a request to read or write a file, which alsoserves to request a connection. If the server grants the request, theconnection is opened and the file is sent in fixed length blocks of 512bytes. Each data packet contains one block of data, and must beacknowledged by an acknowledgment packet before the next packet can besent. A data packet of less than 512 bytes signals termination of atransfer. If a packet gets lost in the network, the intended recipientwill timeout and may retransmit his last packet (which may be data or anacknowledgment), thus causing the sender of the lost packet toretransmit that lost packet. The sender has to keep just one packet onhand for retransmission, since the lock step acknowledgment guaranteesthat all older packets have been received. Notice that both machinesinvolved in a transfer are considered senders and receivers. One sendsdata and receives acknowledgments, the other sends acknowledgments andreceives data. Most errors cause termination of the connection. An error issignalled by sending an error packet. This packet is not acknowledged,and not retransmitted (i.e., a TFTP server or user may terminate aftersending an error message), so the other end of the connection may notget it. Therefore timeouts are used to detect such a termination whenthe error packet has been lost. Errors are caused by three types ofevents: not being able to satisfy the request (e.g., file not found,access violation, or no such user), receiving a packet which cannot beexplained by a delay or duplication in the network (e.g. an incorrectly 4
formed packet), and losing access to a necessary resource (e.g., diskfull or access denied during a transfer). TFTP recognizes only one error condition that does not causetermination, the source port of a received packet being incorrect. Inthis case, an error packet is sent to the originating host. This protocol is very restrictive, in order to simplifyimplementation. For example, the fixed length blocks make allocationstraight forward, and the lock step acknowledgement provides flowcontrol and eliminates the need to reorder incoming data packets.3. Relation to other Protocols As mentioned TFTP is designed to be implemented on top of the Datagramprotocol. Since Datagram is implemented on the Internet protocol,packets will have an Internet header, a Datagram header, and a TFTPheader. Additionally, the packets may have a header (LNI, ARPA header,etc.) to allow them through the local transport medium. As shown inFigure 3-1, the order of the contents of a packet will be: local mediumheader, if used, Internet header, Datagram header, TFTP header, followedby the remainder of the TFTP packet. (This may or may not be datadepending on the type of packet as specified in the TFTP header.) TFTPdoes not specify any of the values in the Internet header. On the otherhand, the source and destination port fields of the Datagram header (itsformat is given in the appendix) are used by TFTP and the length fieldreflects the size of the TFTP packet. The transfer identifiers (TID's) 5
used by TFTP are passed to the Datagram layer to be used as ports;therefore they must be between 0 and 65,535. The initialization ofTID's is discussed in the section on initial connection protocol. The TFTP header consists of a 2 byte opcode field which indicates thepacket's type (e.g., DATA, ERROR, etc.) These opcodes and the formatsof the various types of packets are discussed further in the section onTFTP packets. Figure 3-1: Order of Headers --------------------------------------------------- | Local Medium | Internet | Datagram | TFTP | ---------------------------------------------------4. Initial Connection Protocol A transfer is established by sending a request (WRQ to write onto aforeign file system, or RRQ to read from it), and receiving a positivereply, an acknowledgment packet for write, or the first data packet forread. In general an acknowledgment packet will contain the block numberof the data packet being acknowledged. Each data packet has associatedwith it a block number; block numbers are consecutive and begin withone. Since the positive response to a write request is anacknowledgment packet, in this special case the block number will bezero. (Normally, since an acknowledgment packet is acknowledging a datapacket, the acknowledgment packet will contain the block number of thedata packet being acknowledged.) If the reply is an error packet, then 6
the request has been denied. In order to create a connection, each end of the connection chooses aTID for itself, to be used for the duration of that connection. TheTID's chosen for a connection should be randomly chosen, so that theprobability that the same number is chosen twice in immediate successionis very low. Every packet has associated with it the two TID's of theends of the connection, the source TID and the destination TID. TheseTID's are handed to the supporting UDP (or other datagram protocol) asthe source and destination ports. A requesting host chooses its sourceTID as described above, and sends its initial request to the known TID69 decimal(105 octal) on the serving host. The response to therequest, under normal operation, uses a TID chosen by the server as itssource TID and the TID chosen for the previous message by the requestoras its destination TID. The two chosen TID's are then used for theremainder of the transfer. As an example, the following shows the steps used to establish aconnection to write a file. Note that WRQ, ACK, and DATA are the namesof the write request, acknowledgment, and data types of packetsrespectively. The appendix contains a similar example for reading afile. 1. Host A sends a "WRQ" to host B with source= A's TID, destination= 69. 2. Host B sends a "ACK" (with block number= 0) to host A with source= B's TID, destination= A's TID. 7
At this point the connection has been established and the first datapacket can be sent by Host A with a sequence number of 1. In the nextstep, and in all succeeding steps, the hosts should make sure that thesource TID matches the value that was agreed on in steps 1 and 2. If asource TID does not match, the packet should be discarded as erroneouslysent from somewhere else. An error packet should be sent to the sourceof the incorrect packet, while not disturbing the transfer.This can be done only if the TFTP in fact receives a packet with anincorrect TID. If the supporting protocols do not allow it, thisparticular error condition will not arise. The following example demonstrates a correct operation of the protocolin which the above situation can occur. Host A sends a request to hostB. Somewhere in the network, the request packet is duplicated, and as aresult two acknowledgments are returned to host A, with different TID'schosen on host B in response to the two requests. When the firstresponse arrives, host A continues the connection. When the secondresponse to the request arrives, it should be rejected, but there is noreason to terminate the first connection. Therefore, if different TID'sare chosen for the two connections on host B and host A checks thesource TID's of the messages it receives, the first connection can bemaintained while the second is rejected by returning an error packet. 8
5. TFTP Packets TFTP supports five types of packets, all of which have been mentionedabove: opcode operation 1 Read request (RRQ) 2 Write request (WRQ) 3 Data (DATA) 4 Acknowledgment (ACK) 5 Error (ERROR)The TFTP header of a packet contains the opcode associated with thatpacket. Figure 5-1: RRQ/WRQ packet 2 bytes string 1 byte string 1 byte ------------------------------------------------ | Opcode | Filename | 0 | Mode | 0 | ------------------------------------------------ RRQ and WRQ packets (opcodes 1 and 2 respectively) have the formatshown in Figure 5-1. The file name is a sequence of bytes in netasciiterminated by a zero byte. The mode field contains the string"netascii", "octet", or "mail" (or any comibnation of upper and lowercase, such as "NETASCII", NetAscii", etc.) in netascii indicating thethree modes defined in the protocol. A host which receives netasciimode data must translate the data to its own format. Octet mode is usedto transfer a file that is in the 8-bit format of the machine from whichthe file is being transferred. It is assumed that each type of machinehas a single 8-bit format that is more common, and that that format is 9
chosen. For example, on a DEC-20, a 36 bit machine, this is four 8-bitbytes to a word with four bits of breakage. If a host receives a octetfile and then returns it, the returned file must be identical to theoriginal. Mail mode uses the name of a mail recipient in place of afile and must begin with a WRQ. Otherwise it is identical to netasciimode. The mail recipient string should be of the form "username" or"username@hostname". If the second form is used, it allows the optionof mail forwarding by a relay computer. The discussion above assumes that both the sender and recipient areoperating in the same mode, but there is no reason that this has to bethe case. For example, one might build a storage server. There is noreason that such a machine needs to translate netascii into its own formof text. Rather, the sender might send files in netascii, but thestorage server might simply store them without translation in 8-bitformat. Another such situation is a problem that currently exists onDEC-20 systems. Neither netascii nor octet accesses all the bits in aword. One might create a special mode for such a machine which read allthe bits in a word, but in which the receiver stored the information in8-bit format. When such a file is retrieved from the storage site, itmust be restored to its original form to be useful, so the reverse modemust also be implemented. The user site will have to remember someinformation to achieve this. In both of these examples, the requestpackets would specify octet mode to the foreign host, but the local hostwould be in some other mode. No such machine or application specificmodes have been specified in TFTP, but one would be compatible with this 10
specification. It is also possible to define other modes for cooperating pairs ofhosts, although this must be done with care. There is no requirementthat any other hosts implement these. There is no central authoritythat will define these modes or assign them names. Figure 5-2: DATA packet 2 bytes 2 bytes n bytes ---------------------------------- | Opcode | Block # | Data | ---------------------------------- Data is actually transferred in DATA packets depicted in Figure 5-2.DATA packets (opcode = 3) have a block number and data field. The blocknumbers on data packets begin with one and increase by one for each newblock of data. This restriction allows the program to use a singlenumber to discriminate between new packets and duplicates. The datafield is from zero to 512 bytes long. If it is 512 bytes long, theblock is not the last block of data; if it is from zero to 511 byteslong, it signals the end of the transfer. (See the section on NormalTermination for details.) All packets other than those used for termination are acknowledgedindividually unless a timeout occurs. Sending a DATA packet is anacknowledgment for the ACK packet of the previous DATA packet. The WRQand DATA packets are acknowledged by ACK or ERROR packets, while RRQ and 11
Figure 5-3: ACK packet 2 bytes 2 bytes --------------------- | Opcode | Block # | ---------------------ACK packets are acknowledged by DATA or ERROR packets. Figure 5-3depicts an ACK packet; the opcode is 4. The block number in an ACKechoes the block number of the DATA packet being acknowledged. A WRQ isacknowledged with an ACK packet having a block number of zero. Figure 5-4: ERROR packet 2 bytes 2 bytes string 1 byte ----------------------------------------- | Opcode | ErrorCode | ErrMsg | 0 | ----------------------------------------- An ERROR packet (opcode 5) takes the form depicted in Figure 5-4. AnERROR packet can be the acknowledgment of any other type of packet. Theerror code is an integer indicating the nature of the error. A table ofvalues and meanings is given in the appendix. (Note that several errorcodes have been added to this version of this document.) The errormessage is intended for human consumption, and should be in netascii.Like all other strings, it is terminated with a zero byte. 12
6. Normal Termination The end of a transfer is marked by a DATA packet that contains between0 and511 bytes of data (i.e. Datagram length < 516). This packet isacknowledged by an ACK packet like all other DATA packets. The hostacknowledging the final DATA packet may terminate its side of theconnection on sending the final ACK. On the other hand, dallying isencouraged. This means that the host sending the final ACK will waitfor a while before terminating in order to retransmit the final ACK ifit has been lost. The acknowledger will know that the ACK has been lostif it receives the final DATA packet again. The host sending the lastDATA must retransmit it until the packet is acknowledged or the sendinghost times out. If the response is an ACK, the transmission wascompleted successfully. If the sender of the data times out and is notprepared to retransmit any more, the transfer may still have beencompleted successfully, after which the acknowledger or network may haveexperienced a problem. It is also possible in this case that thetransfer was unsuccessful. In any case, the connection has been closed.7. Premature Termination If a request can not be granted, or some error occurs during thetransfer, then an ERROR packet (opcode 5) is sent. This is only acourtesy since it will not be retransmitted or acknowledged, so it maynever be received. Timeouts must also be used to detect errors. 13
I. AppendixOrder of Headers 2 bytes ----------------------------------------------------------| Local Medium | Internet | Datagram | TFTP Opcode | ----------------------------------------------------------TFTP FormatsType Op # Format without header 2 bytes string 1 byte string 1 byte -----------------------------------------------RRQ/ | 01/02 | Filename | 0 | Mode | 0 |WRQ ----------------------------------------------- 2 bytes 2 bytes n bytes ---------------------------------DATA | 03 | Block # | Data | --------------------------------- 2 bytes 2 bytes -------------------ACK | 04 | Block # | -------------------- 2 bytes 2 bytes string 1 byte ----------------------------------------ERROR | 05 | ErrorCode | ErrMsg | 0 | ---------------------------------------- 14
Initial Connection Protocol for reading a file 1. Host A sends a "RRQ" to host B with source= A's TID, destination= 69. 2. Host B sends a "DATA" (with block number= 1) to host A with source= B's TID, destination= A's TID. 15
Error CodesValue Meaning0 Not defined, see error message (if any).1 File not found.2 Access violation.3 Disk full or allocation exceeded.4 Illegal TFTP operation.5 Unknown transfer ID.6 File already exists.7 No such user. 16
3Internet User Datagram Header [2] Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Source Port | Destination Port |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Length | Checksum |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Values of FieldsSource Port Picked by originator of packet.Dest. Port Picked by destination machine (69 for RRQ or WRQ).Length Number of bytes in packet after Datagram header. 4Checksum Reference 2 describes rules for computing checksum. Field contains zero if unused.Note: TFTP passes transfer identifiers (TID's) to the Internet UserDatagram protocol to be used as the source and destination ports._______________ 3 This has been included only for convenience. TFTP need not beimplemented on top of the Internet User Datagram Protocol. 4 The implementor of this should be sure that the correct algorithm isused here. 17
References [1] USA Standard Code for Information Interchange, USASI X3.4- 1968. [2] Postel, Jon., "User Datagram Protocol,"RFC768, August 28, 1980. [3] "Telnet Protocol Specification,"RFC764, June, 1980. 18
[8]ページ先頭