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