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

A shared means of communication is absolutely necessary when exchanging data between two computer systems in a network. One of the simplest protocols developed specifically 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 specification 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 simplified transport protocol UDP (User Datagram Protocol) which enables data to be sent between communication partners without sharing a fixed connection. 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 counterpart FTP (File Transfer Protocol), TFTP cannot list directories or permissions via chmod. TFTP uses port 69 for requests. Subsequently, communication is established via individually assigned port numbers (between 1024 and 65535), which the TFTP server sends to the requesting 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 connection request, which is automatically granted if the server grants access. The client or server then sends the corresponding 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 individually.

The transfer is made block by block. Each block must be acknowledged via an acknowledgment 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 duplication in the network (e.g. an incorrectly 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 corresponding value:

However, the opcode is not the only way in which the structures 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 identified 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 consisting of zeros.

There is an additional variable length character string, which contains information about the data transfer mode. There are three modes of transfer: netascii, octet (for transferring 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 consisting of zeros.

DATA packets also begin with the opcode field. In this case, they were assigned the value “3”. The following 16-bit sequence identifies the number of the data block where the value "1" serves as the starting number. This value automatically increases by one for each additional 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 respective maximum size is reached, this means that the DATA packet does not contain the last block of the file. The last block indicating the end of the data transfer is always at least one byte smaller. If the remainder of the file to be transferred 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 communication via the Trivial File Transfer Protocol is successful (unless a timeout occurs).

ACK messages for TFTP communication 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 responding 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 corresponding 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 understand 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 consisting of zeros.

The TFTP stands out primarily because of its simplicity. The protocol is designed to enable reading and writing files and fulfills this role without having to establish a connection 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. Individual Transfer Identifiers (TIDs) and unique data block numbers ensure that the recipient receives the file in its entirety.

However, the lack of encryption or an authentication/access control mechanism makes sending sensitive files via the TFTP very risky, so safer alternatives such as a more complex FTP should be used. Furthermore, deleting and renaming files is not allowed on many TFTP servers.

The TFTP protocol is closely related to network booting (also known as bootstrapping). This method, which became popular in the 1980s, involves a network computer loading and starting the operating system from a central server. Therefore, the development and implementation of TFTP was crucial, especially for terminals and diskless workstations, 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 automatically obtain the IP address of the TFTP server.

Nowadays, the Trivial File Transfer Protocol is used much less frequently. In networks where the users these days are equipped with their own operating systems by default, the network boot method can only be found occasionally and in a modified form. As a result, the administrative workload can be reduced through, for example, system installations, maintenance, firmware updates and virus scans via ancillary operating systems. It is not unusual for the TFTP to be implemented in nonvolatile read-only memories (ROM) as it requires little effort thanks to the protocol's connectionless nature. In addition, TFTP servers are used to secure configurations and system images of Cisco routers and switches as well as to store charging data records for Siemens telephone systems.