# 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.

## What is the TFTP (Trivial File Transfer Protocol)?

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](https://tools.ietf.org/html/rfc783 "RFC 783 – TFTP Protocol"). The current standard was published in [RFC 1350](https://tools.ietf.org/html/rfc1350 "RFC 1350 – The TFTP Protocol (Revision 2)") 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](https://www.ionos.com/digitalguide/server/know-how/allocating-directory-rights-with-chmod/ "Allocating directory rights with 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** (**T**ransfer **Id**entifiers).

Note Many operating systems have already **implemented their own TFTP clients and servers,** which can be used to transfer files via the protocol. For example, many Linux and Windows versions (specifically the server versions) provide the standard command line utilities tftpd (server) and tftp (client). Additionally, there are several third-party solutions such as the open-source software [Tftpd32](https://tftpd32.jounin.net/ "TFTP Client and Server for Windows: Tftpd32") which includes both a server and a client.

## How TFTP works

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](https://tools.ietf.org/html/rfc2348 "RFC 2348 – TFTP Blocksize Option"), both the server and client have been able to define the block size individually.

Note Initially, the size of files sent via TFTP was limited to 32 MB. Since the release of [RFC 2347](https://tools.ietf.org/html/rfc2347 "RFC 2347 – TFTP Option Extension") in 1998, the limit has been increased to **4 GB**.

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).

## How are TFTP packets structured?

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

<table>
  <tbody>
    <tr>
      <td><strong>Opcode</strong></td>
      <td><strong>Packet Type</strong></td>
      <td><strong>Description</strong></td>
    </tr>
    <tr>
      <td>1</td>
      <td>RRQ (<strong>R</strong>ead <strong>req</strong>uest)</td>
      <td>Read access request</td>
    </tr>
    <tr>
      <td>2</td>
      <td>WRQ (<strong>W</strong>rite <strong>req</strong>uest)</td>
      <td>Write access request</td>
    </tr>
    <tr>
      <td>3</td>
      <td>DATA (Data)</td>
      <td>Data packet</td>
    </tr>
    <tr>
      <td>4</td>
      <td>ACK (<strong>Ack</strong>nowledgment)</td>
      <td>Acknowledgment message</td>
    </tr>
    <tr>
      <td>5</td>
      <td>ERROR (Error)</td>
      <td>Error message</td>
    </tr>
  </tbody>
</table>

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

### Structure of TFTP read (RRQ) and write access packets (WRQ)

The only difference between the requests that a **TFTP client** sends to a TFTP server for read (RRQ packet) or write access (WRQ packet) is their operation code. Otherwise, both packet types have the same format:

[![Image: Structure of TFTP “RRQ” and “WRQ” packets](https://www.ionos.com/digitalguide/fileadmin/_processed_/6/d/csm_FR-TFTP-1_61e303c40c.webp "Structure of TFTP “RRQ” and “WRQ” packets")](https://www.ionos.com/digitalguide/fileadmin/DigitalGuide/Screenshots_2019/FR-TFTP-1.png) Structure of TFTP “RRQ” and “WRQ” packets 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.

Note Netascii is a modified form of ASCII. It is an 8-bit extension of the ASCII format, which leaves the rarely used control characters undefined. It contains the complete set of 95 characters ranging from x20 to x7E (32–126) as well as special characters (e.g. NUL, CR, LF).

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.

### Structure of TFTP data packets (DATA)

DATA packets contain files that are to be transferred between the client and the server. Since this data is transferred in blocks, a **TFTP DATA message** will always only contain part of the file, with the exception of files whose total size is smaller than the standard **512 bytes or the individually defined block size**. The format for the data packets is as follows:

[![Image: TFTP: Structure of DATA packets](https://www.ionos.com/digitalguide/fileadmin/_processed_/8/9/csm_FR-TFTP-2_6262d1d6bd.webp "TFTP: Structure of DATA packets")](https://www.ionos.com/digitalguide/fileadmin/DigitalGuide/Screenshots_2019/FR-TFTP-2.png) TFTP: Structure of DATA packets 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.

### Structure of TFTP ACK packets

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).

Note Requests for read access to a file (RRQ packets) are confirmed via DATA packets instead of ACK packets.

The **structure of these simplistic acknowledgment messages** is as follows:

[![Image: ACK packet: Structure of TFTP acknowledgment messages](https://www.ionos.com/digitalguide/fileadmin/_processed_/0/4/csm_FR-TFTP-3_2f82ce066a.webp "ACK packet: Structure of TFTP acknowledgment messages")](https://www.ionos.com/digitalguide/fileadmin/DigitalGuide/Screenshots_2019/FR-TFTP-3.png) ACK packet: Structure of TFTP acknowledgment messages 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”.

### Structure of TFTP error messages (ERROR)

ERROR messages are sent by the client or server as soon as an **error** occurs **in TFTP communication**. As a result, these message packets can be a response to all packet types already listed. Error packets are structured as follows:

[![Image: TFTP error messages: structure](https://www.ionos.com/digitalguide/fileadmin/_processed_/c/b/csm_FR-TFTP-4_05548e4bc2.webp "TFTP error messages: structure")](https://www.ionos.com/digitalguide/fileadmin/DigitalGuide/Screenshots_2019/FR-TFTP-4.png) TFTP error messages: structure 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.

## Advantages and disadvantages of the TFTP

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.

## What is the Trivial File Transfer Protocol used for?

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](https://www.ionos.com/digitalguide/server/know-how/bootp-protocol/ "Bootp protocol") which was released in 1985. It enabled network clients to automatically obtain the IP address of the TFTP server.

[YouTube video](https://www.youtube.com/watch?v=QHwfVjHL63I)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.


This is a markdown version of: [https://www.ionos.com/digitalguide/server/know-how/trivial-file-transfer-protocol/](https://www.ionos.com/digitalguide/server/know-how/trivial-file-transfer-protocol/) for AI/LLM consumption.