TFTP: Trivial File Transfer Protocol

What is TFTP?

TFTP (Trivial File Transfer Protocol) is a deliberately simple file transfer protocol designed to do one thing well: move files between two machines with the absolute minimum amount of protocol overhead. Unlike FTP, TFTP has no authentication, no directory listing, no encryption, and no file management commands. It supports exactly two operations: reading a file and writing a file.

TFTP was first defined in 1981 under RFC 783 and later revised in 1992 as RFC 1350, which remains the current standard. The protocol runs over UDP on port 69, keeping both the implementation and the network footprint minimal. A complete TFTP client can be implemented in just a few hundred lines of code, which is why it has been the go-to protocol for environments with severe resource constraints.

TFTP was designed for situations where simplicity matters more than features. Its primary use cases include network booting (PXE), firmware updates for routers and switches, configuration file distribution for IP phones, and embedded systems with limited memory that cannot accommodate a full TCP/IP stack with FTP support. The protocol sacrifices speed, security, and functionality in exchange for a tiny implementation footprint and straightforward operation.

How TFTP Works: Stop-and-Wait

TFTP uses one of the simplest possible data transfer mechanisms: a lock-step, stop-and-wait protocol. Every data block must be acknowledged before the next block is sent. This eliminates the need for windowing, flow control, or complex buffering, but it also means that throughput is limited by the round-trip time between client and server.

A TFTP session begins when the client sends a Read Request (RRQ) or Write Request (WRQ) to the server on UDP port 69. The server receives this request and responds from a new, randomly-chosen high-numbered port. All subsequent communication for that session uses this new port, which frees port 69 to accept new requests from other clients.

For a read (download), the server sends the first data block (block 1, up to 512 bytes) and waits. The client receives the block, sends an ACK for block 1, and waits. Only after the server receives this ACK does it send block 2. This continues until the server sends a block that is smaller than 512 bytes. A short block (0 to 511 bytes) signals the end of the file transfer. If the file size is an exact multiple of 512 bytes, the server sends a final zero-length data block to indicate completion.

For a write (upload), the process reverses. The server acknowledges the WRQ with an ACK for block 0, then the client sends block 1 and waits for the ACK. The same stop-and-wait pattern applies: one block at a time, each acknowledged before the next is sent.

TFTP Opcodes

The entire TFTP protocol consists of just five message types, identified by a 2-byte opcode at the beginning of each packet. This is one of the simplest protocol specifications in networking.

That is the entire protocol. Five message types, no session negotiation, no keepalives, no compression, and no extensions in the base specification. The RRQ and WRQ packets contain the filename and transfer mode as null-terminated strings. DATA packets carry a 2-byte block number followed by up to 512 bytes of file data. ACK packets contain only the 2-byte block number being acknowledged. ERROR packets include a 2-byte error code and a human-readable error message.

TFTP Error Codes

When something goes wrong during a TFTP transfer, either side can send an ERROR packet (opcode 5) containing one of the following error codes. An ERROR packet immediately terminates the transfer.

Error code 0 is a catch-all for situations not covered by the other codes. The accompanying error message string provides more specific information. Error code 5 (Unknown transfer ID) occurs when a packet arrives from an unexpected source port, which can happen if packets are misdirected or if a session has timed out and been restarted.

TFTP Transfer Modes

TFTP defines three transfer modes, specified in the RRQ or WRQ packet. The mode determines how the file data is interpreted during transfer.

• netascii: transfers text files with CR/LF line ending conversion. The sender converts local line endings to the standard CR/LF pair, and the receiver converts them back to the local format. This ensures text files are readable across different operating systems.
• octet: transfers raw binary data with no modification. Every byte is sent exactly as it exists in the source file. This is the most commonly used mode and the correct choice for firmware images, configuration files, boot images, and any non-text content.
• mail:an obsolete mode that was intended to deliver files to a user's mailbox. This mode was never widely implemented and is not supported by modern TFTP servers.

In practice, always use octet mode for firmware, boot images, binary files, and any situation where you need byte-for-byte accuracy. Use netascii only when transferring plain text files between systems with different line ending conventions.

TFTP vs FTP vs SFTP

TFTP, FTP, and SFTP all transfer files, but they occupy very different positions in terms of complexity, security, and capability. Understanding when to use each protocol depends on your requirements for authentication, encryption, and operational features.

TFTP is not a replacement for FTP or SFTP. It fills a specific niche where the client device may not have the resources to run a TCP stack or where the simplicity of the protocol is the primary requirement. For general-purpose file transfers, SFTP is the recommended choice. For legacy compatibility, FTP or FTPS may be necessary. TFTP should only be used in controlled network environments where its lack of security is acceptable.

TFTP Block Size Extension

The original TFTP specification limits data blocks to 512 bytes, which results in poor throughput on modern networks. Every 512-byte block requires a full round trip for the ACK before the next block can be sent. On a network with 10ms latency, this caps throughput at roughly 50 KB/s regardless of available bandwidth.

RFC 2348 addresses this by introducing the blksize option. The client includes a desired block size in the RRQ or WRQ packet, and the server responds with an Option Acknowledgment (OACK) confirming the negotiated size. Block sizes can range from 8 bytes up to 65535 bytes. Larger blocks dramatically improve throughput by reducing the number of round trips needed to transfer a file. For example, using 1468-byte blocks (fitting within a standard Ethernet MTU) nearly triples throughput compared to the default 512-byte blocks.

RFC 2349 adds two more options: timeout (allowing the client and server to negotiate the retransmission timeout) and tsize (allowing the sender to communicate the total transfer size before the transfer begins). The transfer size option is particularly useful for PXE boot clients that need to allocate memory before downloading a boot image.

PXE Network Booting with TFTP

PXE (Preboot Execution Environment) is the primary use case for TFTP in modern networks. PXE allows a computer to boot from the network instead of a local disk, and TFTP serves as the file transfer mechanism for downloading the boot image. The process works as follows.

1. The device powers on and its network interface card (NIC) sends a DHCP discover message to obtain an IP address.
2. The DHCP server responds with an IP address and includes two additional options: option 66 (the IP address or hostname of the TFTP server) and option 67 (the filename of the boot image to download).
3. The device sends a TFTP RRQ to the specified server, requesting the boot image file.
4. The TFTP server transfers the boot image using the standard stop-and-wait protocol.
5. Once the download is complete, the device loads the boot image into memory and begins executing it.

PXE booting with TFTP is widely used for OS deployment across large fleets of machines, diskless workstations that run entirely from network-loaded images, thin client environments, and data center provisioning where hundreds of servers need to be imaged simultaneously. The simplicity of TFTP is a strength here: the PXE boot ROM in the NIC only needs a minimal TFTP client implementation, which can fit in a small amount of firmware memory.

Common Use Cases

Despite its age and limitations, TFTP remains actively used in several specific scenarios where its simplicity is an advantage rather than a drawback.

• PXE network booting: deploying operating systems across large numbers of machines, running diskless workstations, and provisioning data center servers over the network
• Router and switch firmware updates: Cisco IOS, Juniper Junos, and many other network operating systems use TFTP for loading firmware images and backing up configurations
• IP phone configuration: VoIP phones from Cisco, Polycom, and other vendors download their configuration files from a TFTP server when they boot up
• Embedded system firmware loading: devices with limited memory and processing power use TFTP to receive firmware updates because the protocol requires minimal resources to implement
• Network device backup and restore: administrators use TFTP to back up running configurations and restore them when needed, particularly on Cisco networking equipment

Frequently Asked Questions About TFTP

Why does TFTP use UDP instead of TCP?

TFTP uses UDP because it was designed to be implementable on devices with extremely limited resources. A full TCP stack requires connection management, windowing, flow control, and retransmission logic. TFTP handles reliability itself through its stop-and-wait mechanism: each block is acknowledged, and if an ACK is not received within the timeout period, the block is retransmitted. This approach is less efficient than TCP for large transfers, but it allows the entire protocol to be implemented with very little code and memory.

Is TFTP secure?

No. TFTP has no security features at all. There is no authentication, no encryption, and no access control built into the protocol. Anyone on the network can read or write files to a TFTP server. For this reason, TFTP servers should only be deployed on trusted, isolated network segments. TFTP should never be exposed to the public internet or used to transfer sensitive data. If you need secure file transfer, use SFTP instead.

Why is TFTP still used?

TFTP survives because of its extreme simplicity. PXE network booting requires a file transfer protocol that can be implemented in a tiny boot ROM on a network card. Network equipment vendors have built their firmware update and configuration workflows around TFTP for decades. Replacing TFTP in these use cases would require changes to hardware boot ROMs and vendor tooling, which is a slow process. In its niche, TFTP does exactly what is needed with minimal complexity.

What is the maximum file size TFTP can transfer?

With the standard 512-byte block size and a 16-bit block number, the theoretical maximum file size is 65535 blocks times 512 bytes, which equals approximately 32 MB. With the block size extension (RFC 2348) allowing blocks up to 65535 bytes, the theoretical maximum increases to roughly 4 GB. In practice, most TFTP implementations handle files well beyond the original 32 MB limit by using the block size extension or by wrapping the block counter.

What is PXE boot and how does it use TFTP?

PXE (Preboot Execution Environment) is a standard that allows computers to boot from the network. During PXE boot, the device obtains its IP address and the location of a boot image from a DHCP server. It then uses TFTP to download the boot image file from the specified TFTP server. Once the image is downloaded, the device executes it. TFTP is used for this purpose because the PXE boot ROM needs only a minimal protocol implementation.

Can TFTP upload files?

Yes. TFTP supports both reading (downloading) and writing (uploading) files. The client sends a WRQ (Write Request, opcode 2) to initiate an upload. The server acknowledges the request with an ACK for block 0, and the client then sends data blocks using the same stop-and-wait mechanism used for downloads. However, many TFTP server configurations disable write access for security reasons, since TFTP has no authentication to verify who is uploading files.

Related Protocols

• FTP: the full-featured file transfer protocol that TFTP was simplified from, supporting authentication, directory listing, and file management
• UDP: the transport protocol that TFTP runs on, providing lightweight, connectionless delivery
• DHCP: works alongside TFTP in PXE boot scenarios, providing IP configuration and TFTP server information to booting devices
• SSH: provides SFTP, the secure alternative to both FTP and TFTP for environments requiring encryption and authentication