TFTP Protocol (revision 2)
RFC 783

Document Type RFC - Unknown (June 1981; Errata)
Obsoleted by RFC 1350
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 783 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                      K. R. Sollins
Request for Comments: 783                                            MIT
                                                              June, 1981
Updates: IEN 133

                     THE TFTP PROTOCOL (REVISION 2)


  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.



  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.


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.

   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
   This  replaces  the  "binary"  mode  of  previous  versions  of  this


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


formed  packet),  and  losing access to a necessary resource (e.g., disk

full or access denied during a transfer).
Show full document text