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.
ACKNOWLEDGEMENTS
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 UCS-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.
-
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.
2
-
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] so it
-
may be used to move files between machines on different networks
implementing UDP. (This should not exlude 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.
1 2
Three modes of transfer are currently supported: netascii ; octet ,
-
raw 8 bit bytes; mail, netascii characters sent to a user rather than a
-
file. Additional modes can be defined by pairs of cooperating hosts.
- _______________
1
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.
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 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 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
4
-
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. 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)
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 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.
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 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
6
-
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.
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 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.
8
-
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.
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 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 comibnation 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
9
-
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
10
-
specification.
- It is also possible to define other modes for cooperating pairs of
-
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.
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 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 those used for termination are acknowledged
-
individually unless a timeout occurs. Sending a DATA packet is an
-
acknowledgment for the ACK packet of the previous DATA packet. The WRQ
-
and 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-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.
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. 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.
12
-
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.
13
-
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 |
-----------------------------------------
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 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.
16
3
Internet 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 Fields
Source 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.
4
Checksum Reference 2 describes rules for computing checksum.
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.
_______________
3
This has been included only for convenience. TFTP need not be
implemented on top of the Internet User Datagram Protocol.
4
The implementor of this should be sure that the correct algorithm is
used 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
