TFTP (Trivial File Transfer Protocol) – File Transfer Protocol made simple

A shared means of com­mu­ni­ca­tion is ab­solute­ly necessary when ex­chang­ing data between two computer systems in a network. One of the simplest protocols developed specif­i­cal­ly for this purpose is the Trivial File Transfer Protocol (TFTP), which played an important role at the dawn of the internet.

The Trivial File Transfer Protocol, TFTP for short, is a very simple client-server protocol, which manages file transfers in computer networks. The TFTP’s original spec­i­fi­ca­tion was published in June 1981 in RFC 783. The current standard was published in RFC 1350 in 1992. By default, the TFTP protocol is based on the similarly sim­pli­fied transport protocol UDP (User Datagram Protocol) which enables data to be sent between com­mu­ni­ca­tion partners without sharing a fixed con­nec­tion. It is also possible to implement the TFTP based on other protocols.

The packet-oriented File Transfer Protocol, which is part of the TCP/IP protocol family, was specially designed to be as small and easy to implement as possible. As a result, it only covers methods for reading/writing files or mail to or from a server. Unlike its better-known coun­ter­part FTP (File Transfer Protocol), TFTP cannot list di­rec­to­ries or per­mis­sions via chmod. TFTP uses port 69 for requests. Sub­se­quent­ly, com­mu­ni­ca­tion is es­tab­lished via in­di­vid­u­al­ly assigned port numbers (between 1024 and 65535), which the TFTP server sends to the re­quest­ing client in the form of TIDs (Transfer Identifiers).

TFTP file transfer is always based on a client request in which read or write access is requested. This request also serves as a con­nec­tion request, which is au­to­mat­i­cal­ly granted if the server grants access. The client or server then sends the cor­re­spond­ing file in blocks of a fixed size. In the original versions of the protocol, the fixed size was still 512 bytes. Since the release of RFC 2348, both the server and client have been able to define the block size in­di­vid­u­al­ly.

The transfer is made block by block. Each block must be ac­knowl­edged via an ac­knowl­edg­ment packet before the next block can be sent. A data packet smaller than the fixed size signals the end of a file transfer. If a packet is lost during the transfer, a timeout will occur on the receiver’s end prompting them to resend the last sent packet. This informs the sender of the lost packet which must be sent again. If an error occurs during the TFTP file transfer, this will result in an error packet being sent which will terminate the transfer in most cases. There are three possible sources of error:

• The request could not be satisfied for some reason (e.g. the file was not found, the user does not exist or there was an access violation, such as for a protected file).
• The client or server received a packet, which cannot be explained by a delay or du­pli­ca­tion in the network (e.g. an in­cor­rect­ly formed packet).
• The access to a necessary resource has been lost (e.g. the disc is full).

TFTP protocol supports five types of packets, each of which has its own 16-bit long opcode field (operation code) with the cor­re­spond­ing value:

However, the opcode is not the only way in which the struc­tures of these packet types differ.

Both RRQ and WRQ messages start with the 16-bit long opcode field used for protocols. As the first table shows, RRQ packets use the value “1” here, while WRQ packets are iden­ti­fied by the value “2”. This is followed by a bit sequence in netascii format with different sizes. It contains the name of the file that is to be read or sent. The end is marked by an 8-bit field con­sist­ing of zeros.

There is an ad­di­tion­al variable length character string, which contains in­for­ma­tion about the data transfer mode. There are three modes of transfer: netascii, octet (for trans­fer­ring files in an 8-bit format) and mail (for sending files to an email address). The end of this is also marked by an 8-bit field con­sist­ing of zeros.

DATA packets also begin with the opcode field. In this case, they were assigned the value “3”. The following 16-bit sequence iden­ti­fies the number of the data block where the value "1" serves as the starting number. This value au­to­mat­i­cal­ly increases by one for each ad­di­tion­al data block in the file. The blocks are contained in the data field, which is from 0 to 512 bytes long (4,096 bits), provided that the TFTP server and client have not set a different maximum size for the blocks. If the re­spec­tive maximum size is reached, this means that the DATA packet does not contain the last block of the file. The last block in­di­cat­ing the end of the data transfer is always at least one byte smaller. If the remainder of the file to be trans­ferred just happens to be exactly the same size as the block, the sender will have to transfer another packet with an empty data block.

All WRQ and data packets that do not mark the end of the file transfer are confirmed by ACK messages when com­mu­ni­ca­tion via the Trivial File Transfer Protocol is suc­cess­ful (unless a timeout occurs).

ACK messages for TFTP com­mu­ni­ca­tion consist of the 16-bit long opcode, which has been assigned a value of “4”, and the 16-bit long data block number which is confirmed by the ACK message. If it is re­spond­ing to a WRQ request, the ACK packet has the data block number “0”.

After the opcode, which also precedes ERROR messages (value "5"), there is a 16-bit long field that contains the error code. For example, the value "1" indicates that the cor­re­spond­ing file could not be found, while the value "6" indicates to the receiver that the file already exists. The resulting error message helps the user to un­der­stand the problem. This is another reason why this variable-length string is usually in the netascii format. The end is marked by an 8-bit field con­sist­ing of zeros.

The TFTP stands out primarily because of its sim­plic­i­ty. The protocol is designed to enable reading and writing files and fulfills this role without having to establish a con­nec­tion between the client and the server. As a result, the TFTP protocol is not only easy to implement but also paves the way for fast file transfers. In­di­vid­ual Transfer Iden­ti­fiers (TIDs) and unique data block numbers ensure that the recipient receives the file in its entirety.

However, the lack of en­cryp­tion or an au­then­ti­ca­tion/access control mechanism makes sending sensitive files via the TFTP very risky, so safer al­ter­na­tives such as a more complex FTP should be used. Fur­ther­more, deleting and renaming files is not allowed on many TFTP servers.

The TFTP protocol is closely related to network booting (also known as boot­strap­ping). This method, which became popular in the 1980s, involves a network computer loading and starting the operating system from a central server. Therefore, the de­vel­op­ment and im­ple­men­ta­tion of TFTP was crucial, es­pe­cial­ly for terminals and diskless work­sta­tions, which could not install their own operating system. The File Transfer Protocol was enhanced by BOOTP which was released in 1985. It enabled network clients to au­to­mat­i­cal­ly obtain the IP address of the TFTP server.

Nowadays, the Trivial File Transfer Protocol is used much less fre­quent­ly. In networks where the users these days are equipped with their own operating systems by default, the network boot method can only be found oc­ca­sion­al­ly and in a modified form. As a result, the ad­min­is­tra­tive workload can be reduced through, for example, system in­stal­la­tions, main­te­nance, firmware updates and virus scans via ancillary operating systems. It is not unusual for the TFTP to be im­ple­ment­ed in non­volatile read-only memories (ROM) as it requires little effort thanks to the pro­to­col's con­nec­tion­less nature. In addition, TFTP servers are used to secure con­fig­u­ra­tions and system images of Cisco routers and switches as well as to store charging data records for Siemens telephone systems.