Browse Prior Art Database

TFTP Protocol (revision 2) (RFC0783) Disclosure Number: IPCOM000003832D
Original Publication Date: 1981-Jun-01
Included in the Prior Art Database: 2019-Feb-14
Document File: 19 page(s) / 18K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

K.R. Sollins: AUTHOR

Related Documents

10.17487/RFC0783: DOI

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 16% of the total text.

Network Working Group K. R. Sollins Request for Comments: 783 MIT June, 1981 Updates: IEN 133



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.

_______________ 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


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