summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1350.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1350.txt')
-rw-r--r--doc/rfc/rfc1350.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc1350.txt b/doc/rfc/rfc1350.txt
new file mode 100644
index 0000000..e00113b
--- /dev/null
+++ b/doc/rfc/rfc1350.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group K. Sollins
+Request For Comments: 1350 MIT
+STD: 33 July 1992
+Obsoletes: RFC 783
+
+
+ THE TFTP PROTOCOL (REVISION 2)
+
+Status of this Memo
+
+ This RFC specifies an IAB standards track protocol for the Internet
+ community, and requests discussion and suggestions for improvements.
+ Please refer to the current edition of the "IAB Official Protocol
+ Standards" for the standardization state and status of this protocol.
+ Distribution of this memo is unlimited.
+
+Summary
+
+ TFTP is a very simple protocol used to transfer files. It is from
+ this that its name comes, Trivial File Transfer Protocol or TFTP.
+ Each nonterminal packet is acknowledged separately. This document
+ describes the protocol and its types of packets. The document also
+ explains the reasons behind some of the design decisions.
+
+Acknowlegements
+
+ The protocol was originally designed by Noel Chiappa, and was
+ redesigned by him, Bob Baldwin and Dave Clark, with comments from
+ Steve Szymanski. The current revision of the document includes
+ modifications stemming from discussions with and suggestions from
+ Larry Allen, Noel Chiappa, Dave Clark, Geoff Cooper, Mike Greenwald,
+ Liza Martin, David Reed, Craig Milo Rogers (of USC-ISI), Kathy
+ Yellick, and the author. The acknowledgement and retransmission
+ scheme was inspired by TCP, and the error mechanism was suggested by
+ PARC's EFTP abort message.
+
+ The May, 1992 revision to fix the "Sorcerer's Apprentice" protocol
+ bug [4] and other minor document problems was done by Noel Chiappa.
+
+ This research was supported by the Advanced Research Projects Agency
+ of the Department of Defense and was monitored by the Office of Naval
+ Research under contract number N00014-75-C-0661.
+
+1. Purpose
+
+ TFTP is a simple protocol to transfer files, and therefore was named
+ the Trivial File Transfer Protocol or TFTP. It has been implemented
+ on top of the Internet User Datagram protocol (UDP or Datagram) [2]
+
+
+
+Sollins [Page 1]
+
+RFC 1350 TFTP Revision 2 July 1992
+
+
+ so it may be used to move files between machines on different
+ networks implementing UDP. (This should not exclude the possibility
+ of implementing TFTP on top of other datagram protocols.) It is
+ designed to be small and easy to implement. Therefore, it lacks most
+ of the features of a regular FTP. The only thing it can do is read
+ and write files (or mail) from/to a remote server. It cannot list
+ directories, and currently has no provisions for user authentication.
+ In common with other Internet protocols, it passes 8 bit bytes of
+ data.
+
+ Three modes of transfer are currently supported: netascii (This is
+ ascii as defined in "USA Standard Code for Information Interchange"
+ [1] with the modifications specified in "Telnet Protocol
+ Specification" [3].) Note that it is 8 bit ascii. The term
+ "netascii" will be used throughout this document to mean this
+ particular version of ascii.); octet (This replaces the "binary" mode
+ of previous versions of this document.) raw 8 bit bytes; mail,
+ netascii characters sent to a user rather than a file. (The mail
+ mode is obsolete and should not be implemented or used.) Additional
+ modes can be defined by pairs of cooperating hosts.
+
+ Reference [4] (section 4.2) should be consulted for further valuable
+ directives and suggestions on TFTP.
+
+2. Overview of the Protocol
+
+ Any transfer begins with a request to read or write a file, which
+ also serves to request a connection. If the server grants the
+ request, the connection is opened and the file is sent in fixed
+ length blocks of 512 bytes. Each data packet contains one block of
+ data, and must be acknowledged by an acknowledgment packet before the
+ next packet can be sent. A data packet of less than 512 bytes
+ signals termination of a transfer. If a packet gets lost in the
+ network, the intended recipient will timeout and may retransmit his
+ last packet (which may be data or an acknowledgment), thus causing
+ the sender of the lost packet to retransmit that lost packet. The
+ sender has to keep just one packet on hand for retransmission, since
+ the lock step acknowledgment guarantees that all older packets have
+ been received. Notice that both machines involved in a transfer are
+ considered senders and receivers. One sends data and receives
+ acknowledgments, the other sends acknowledgments and receives data.
+
+ Most errors cause termination of the connection. An error is
+ signalled by sending an error packet. This packet is not
+ acknowledged, and not retransmitted (i.e., a TFTP server or user may
+ terminate after sending an error message), so the other end of the
+ connection may not get it. Therefore timeouts are used to detect
+ such a termination when the error packet has been lost. Errors are
+
+
+
+Sollins [Page 2]
+
+RFC 1350 TFTP Revision 2 July 1992
+
+
+ caused by three types of events: not being able to satisfy the
+ request (e.g., file not found, access violation, or no such user),
+ receiving a packet which cannot be explained by a delay or
+ duplication in the network (e.g., an incorrectly formed packet), and
+ losing access to a necessary resource (e.g., disk full or access
+ denied during a transfer).
+
+ TFTP recognizes only one error condition that does not cause
+ termination, the source port of a received packet being incorrect.
+ In this case, an error packet is sent to the originating host.
+
+ This protocol is very restrictive, in order to simplify
+ implementation. For example, the fixed length blocks make allocation
+ straight forward, and the lock step acknowledgement provides flow
+ control 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
+ Datagram protocol (UDP). Since Datagram is implemented on the
+ Internet protocol, packets will have an Internet header, a Datagram
+ header, and a TFTP header. Additionally, the packets may have a
+ header (LNI, ARPA header, etc.) to allow them through the local
+ transport medium. As shown in Figure 3-1, the order of the contents
+ of a packet will be: local medium header, if used, Internet header,
+ Datagram header, TFTP header, followed by the remainder of the TFTP
+ packet. (This may or may not be data depending on the type of packet
+ as specified in the TFTP header.) TFTP does not specify any of the
+ values in the Internet header. On the other hand, the source and
+ destination port fields of the Datagram header (its format is given
+ in the appendix) are used by TFTP and the length field reflects the
+ size of the TFTP packet. The transfer identifiers (TID's) 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 of TID's is
+ discussed in the section on initial connection protocol.
+
+ The TFTP header consists of a 2 byte opcode field which indicates
+ the packet's type (e.g., DATA, ERROR, etc.) These opcodes and the
+ formats of the various types of packets are discussed further in the
+ section on TFTP packets.
+
+
+
+
+
+
+
+
+
+
+
+Sollins [Page 3]
+
+RFC 1350 TFTP Revision 2 July 1992
+
+
+ ---------------------------------------------------
+ | Local Medium | Internet | Datagram | TFTP |
+ ---------------------------------------------------
+
+ Figure 3-1: Order of Headers
+
+
+4. Initial Connection Protocol
+
+ A transfer is established by sending a request (WRQ to write onto a
+ foreign file system, or RRQ to read from it), and receiving a
+ positive reply, an acknowledgment packet for write, or the first data
+ packet for read. In general an acknowledgment packet will contain
+ the block number of the data packet being acknowledged. Each data
+ packet has associated with it a block number; block numbers are
+ consecutive and begin with one. Since the positive response to a
+ write request is an acknowledgment packet, in this special case the
+ block number will be zero. (Normally, since an acknowledgment packet
+ is acknowledging a data packet, the acknowledgment packet will
+ contain the block number of the data packet being acknowledged.) If
+ the reply is an error packet, then the request has been denied.
+
+ In order to create a connection, each end of the connection chooses a
+ TID for itself, to be used for the duration of that connection. The
+ TID's chosen for a connection should be randomly chosen, so that the
+ probability that the same number is chosen twice in immediate
+ succession is very low. Every packet has associated with it the two
+ TID's of the ends of the connection, the source TID and the
+ destination TID. These TID's are handed to the supporting UDP (or
+ other datagram protocol) as the source and destination ports. A
+ requesting host chooses its source TID as described above, and sends
+ its initial request to the known TID 69 decimal (105 octal) on the
+ serving host. The response to the request, under normal operation,
+ uses a TID chosen by the server as its source TID and the TID chosen
+ for the previous message by the requestor as its destination TID.
+ The two chosen TID's are then used for the remainder of the transfer.
+
+ As an example, the following shows the steps used to establish a
+ connection to write a file. Note that WRQ, ACK, and DATA are the
+ names of the write request, acknowledgment, and data types of packets
+ respectively. The appendix contains a similar example for reading a
+ file.
+
+
+
+
+
+
+
+
+
+Sollins [Page 4]
+
+RFC 1350 TFTP Revision 2 July 1992
+
+
+ 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.
+
+ At this point the connection has been established and the first data
+ packet can be sent by Host A with a sequence number of 1. In the
+ next step, and in all succeeding steps, the hosts should make sure
+ that the source TID matches the value that was agreed on in steps 1
+ and 2. If a source TID does not match, the packet should be
+ discarded as erroneously sent from somewhere else. An error packet
+ should be sent to the source of the incorrect packet, while not
+ disturbing the transfer. This can be done only if the TFTP in fact
+ receives a packet with an incorrect TID. If the supporting protocols
+ do not allow it, this particular error condition will not arise.
+
+ The following example demonstrates a correct operation of the
+ protocol in which the above situation can occur. Host A sends a
+ request to host B. Somewhere in the network, the request packet is
+ duplicated, and as a result two acknowledgments are returned to host
+ A, with different TID's chosen on host B in response to the two
+ requests. When the first response arrives, host A continues the
+ connection. When the second response to the request arrives, it
+ should be rejected, but there is no reason to terminate the first
+ connection. Therefore, if different TID's are chosen for the two
+ connections on host B and host A checks the source TID's of the
+ messages it receives, the first connection can be maintained while
+ the second is rejected by returning an error packet.
+
+5. TFTP Packets
+
+ TFTP supports five types of packets, all of which have been mentioned
+ above:
+
+ 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
+ that packet.
+
+
+
+
+
+
+
+Sollins [Page 5]
+
+RFC 1350 TFTP Revision 2 July 1992
+
+
+ 2 bytes string 1 byte string 1 byte
+ ------------------------------------------------
+ | Opcode | Filename | 0 | Mode | 0 |
+ ------------------------------------------------
+
+ Figure 5-1: RRQ/WRQ packet
+
+
+ RRQ and WRQ packets (opcodes 1 and 2 respectively) have the format
+ shown in Figure 5-1. The file name is a sequence of bytes in
+ netascii terminated by a zero byte. The mode field contains the
+ string "netascii", "octet", or "mail" (or any combination of upper
+ and lower case, such as "NETASCII", NetAscii", etc.) in netascii
+ indicating the three modes defined in the protocol. A host which
+ receives netascii mode data must translate the data to its own
+ format. Octet mode is used to transfer a file that is in the 8-bit
+ format of the machine from which the file is being transferred. It
+ is assumed that each type of machine has a single 8-bit format that
+ is more common, and that that format is chosen. For example, on a
+ DEC-20, a 36 bit machine, this is four 8-bit bytes to a word with
+ four bits of breakage. If a host receives a octet file and then
+ returns it, the returned file must be identical to the original.
+ Mail mode uses the name of a mail recipient in place of a file and
+ must begin with a WRQ. Otherwise it is identical to netascii mode.
+ The mail recipient string should be of the form "username" or
+ "username@hostname". If the second form is used, it allows the
+ option of mail forwarding by a relay computer.
+
+ The discussion above assumes that both the sender and recipient are
+ operating in the same mode, but there is no reason that this has to
+ be the case. For example, one might build a storage server. There
+ is no reason that such a machine needs to translate netascii into its
+ own form of text. Rather, the sender might send files in netascii,
+ but the storage server might simply store them without translation in
+ 8-bit format. Another such situation is a problem that currently
+ exists on DEC-20 systems. Neither netascii nor octet accesses all
+ the bits in a word. One might create a special mode for such a
+ machine which read all the bits in a word, but in which the receiver
+ stored the information in 8-bit format. When such a file is
+ retrieved from the storage site, it must be restored to its original
+ form to be useful, so the reverse mode must also be implemented. The
+ user site will have to remember some information to achieve this. In
+ both of these examples, the request packets would specify octet mode
+ to the foreign host, but the local host would be in some other mode.
+ No such machine or application specific modes have been specified in
+ TFTP, but one would be compatible with this specification.
+
+ It is also possible to define other modes for cooperating pairs of
+
+
+
+Sollins [Page 6]
+
+RFC 1350 TFTP Revision 2 July 1992
+
+
+ hosts, although this must be done with care. There is no requirement
+ that any other hosts implement these. There is no central authority
+ that will define these modes or assign them names.
+
+
+ 2 bytes 2 bytes n bytes
+ ----------------------------------
+ | Opcode | Block # | Data |
+ ----------------------------------
+
+ Figure 5-2: DATA packet
+
+
+ Data is actually transferred in DATA packets depicted in Figure 5-2.
+ DATA packets (opcode = 3) have a block number and data field. The
+ block numbers on data packets begin with one and increase by one for
+ each new block of data. This restriction allows the program to use a
+ single number to discriminate between new packets and duplicates.
+ The data field is from zero to 512 bytes long. If it is 512 bytes
+ long, the block is not the last block of data; if it is from zero to
+ 511 bytes long, it signals the end of the transfer. (See the section
+ on Normal Termination for details.)
+
+ All packets other than duplicate ACK's and those used for
+ termination are acknowledged unless a timeout occurs [4]. Sending a
+ DATA packet is an acknowledgment for the first ACK packet of the
+ previous DATA packet. The WRQ and DATA packets are acknowledged by
+ ACK or ERROR packets, while RRQ
+
+
+ 2 bytes 2 bytes
+ ---------------------
+ | Opcode | Block # |
+ ---------------------
+
+ Figure 5-3: ACK packet
+
+
+ and ACK packets are acknowledged by DATA or ERROR packets. Figure
+ 5-3 depicts an ACK packet; the opcode is 4. The block number in
+ an ACK echoes the block number of the DATA packet being
+ acknowledged. A WRQ is acknowledged with an ACK packet having a
+ block number of zero.
+
+
+
+
+
+
+
+
+Sollins [Page 7]
+
+RFC 1350 TFTP Revision 2 July 1992
+
+
+ 2 bytes 2 bytes string 1 byte
+ -----------------------------------------
+ | Opcode | ErrorCode | ErrMsg | 0 |
+ -----------------------------------------
+
+ Figure 5-4: ERROR packet
+
+
+ An ERROR packet (opcode 5) takes the form depicted in Figure 5-4. An
+ ERROR packet can be the acknowledgment of any other type of packet.
+ The error code is an integer indicating the nature of the error. A
+ table of values and meanings is given in the appendix. (Note that
+ several error codes have been added to this version of this
+ document.) The error message is intended for human consumption, and
+ should be in netascii. Like all other strings, it is terminated with
+ a zero byte.
+
+6. Normal Termination
+
+ The end of a transfer is marked by a DATA packet that contains
+ between 0 and 511 bytes of data (i.e., Datagram length < 516). This
+ packet is acknowledged by an ACK packet like all other DATA packets.
+ The host acknowledging the final DATA packet may terminate its side
+ of the connection on sending the final ACK. On the other hand,
+ dallying is encouraged. This means that the host sending the final
+ ACK will wait for a while before terminating in order to retransmit
+ the final ACK if it has been lost. The acknowledger will know that
+ the ACK has been lost if it receives the final DATA packet again.
+ The host sending the last DATA must retransmit it until the packet is
+ acknowledged or the sending host times out. If the response is an
+ ACK, the transmission was completed successfully. If the sender of
+ the data times out and is not prepared to retransmit any more, the
+ transfer may still have been completed successfully, after which the
+ acknowledger or network may have experienced a problem. It is also
+ possible in this case that the transfer 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 the
+ transfer, then an ERROR packet (opcode 5) is sent. This is only a
+ courtesy since it will not be retransmitted or acknowledged, so it
+ may never be received. Timeouts must also be used to detect errors.
+
+
+
+
+
+
+
+
+Sollins [Page 8]
+
+RFC 1350 TFTP Revision 2 July 1992
+
+
+I. Appendix
+
+Order of Headers
+
+ 2 bytes
+ ----------------------------------------------------------
+ | Local Medium | Internet | Datagram | TFTP Opcode |
+ ----------------------------------------------------------
+
+TFTP Formats
+
+ Type 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 |
+ ----------------------------------------
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sollins [Page 9]
+
+RFC 1350 TFTP Revision 2 July 1992
+
+
+Error Codes
+
+ Value Meaning
+
+ 0 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.
+
+Internet User Datagram Header [2]
+
+ (This has been included only for convenience. TFTP need not be
+ implemented on top of the Internet User Datagram Protocol.)
+
+ 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 Fields
+
+
+ Source Port Picked by originator of packet.
+
+ Dest. Port Picked by destination machine (69 for RRQ or WRQ).
+
+ Length Number of bytes in UDP packet, including UDP header.
+
+ Checksum Reference 2 describes rules for computing checksum.
+ (The implementor of this should be sure that the
+ correct algorithm is used here.)
+ Field contains zero if unused.
+
+ Note: TFTP passes transfer identifiers (TID's) to the Internet User
+ Datagram protocol to be used as the source and destination ports.
+
+
+
+
+
+
+Sollins [Page 10]
+
+RFC 1350 TFTP Revision 2 July 1992
+
+
+References
+
+ [1] USA Standard Code for Information Interchange, USASI X3.4-1968.
+
+ [2] Postel, J., "User Datagram Protocol," RFC 768, USC/Information
+ Sciences Institute, 28 August 1980.
+
+ [3] Postel, J., "Telnet Protocol Specification," RFC 764,
+ USC/Information Sciences Institute, June, 1980.
+
+ [4] Braden, R., Editor, "Requirements for Internet Hosts --
+ Application and Support", RFC 1123, USC/Information Sciences
+ Institute, October 1989.
+
+Security Considerations
+
+ Since TFTP includes no login or access control mechanisms, care must
+ be taken in the rights granted to a TFTP server process so as not to
+ violate the security of the server hosts file system. TFTP is often
+ installed with controls such that only files that have public read
+ access are available via TFTP and writing files via TFTP is
+ disallowed.
+
+Author's Address
+
+ Karen R. Sollins
+ Massachusetts Institute of Technology
+ Laboratory for Computer Science
+ 545 Technology Square
+ Cambridge, MA 02139-1986
+
+ Phone: (617) 253-6006
+
+ EMail: SOLLINS@LCS.MIT.EDU
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sollins [Page 11]
+ \ No newline at end of file