The TFTP Protocol (Revision 2)
RFC 1350

Document Type RFC - Internet Standard (July 1992; Errata)
Obsoletes RFC 783
Also known as STD 33
Was draft-ietf-iesg-tftp (individual)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html
Stream Legacy state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 1350 (Internet Standard)
Telechat date
Responsible AD (None)
Send notices to (None)
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
Show full document text