Trivial File Transfer Protocol

Trivial File Transfer Protocol (TFTP) is a file transfer protocol notable for its simplicity. It is generally used for automated transfer of configuration or boot files between machines in a local environment. Compared to FTP, TFTP is extremely limited, providing no authentication, and is rarely used interactively by a user.

Due to its simple design, TFTP could be implemented using a very small amount of memory. It is therefore useful for booting computers such as routers which may not have any data storage devices. It is an element of the Preboot Execution Environment (PXE) network boot protocol, where it is implemented in the firmware ROM / NVRAM of the host's network card.

It is also used to transfer small amounts of data between hosts on a network, such as IP phone firmware or operating system images when a remote X Window System terminal or any other thin client boots from a network host or server. The initial stages of some network based installation systems (such as Solaris Jumpstart, Red Hat Kickstart, Symantec Ghost and Windows NT's Remote Installation Services) use TFTP to load a basic kernel that performs the actual installation. It was used for saving router configurations on Cisco routers, but was later augmented by other protocols.^[1]

TFTP was first defined in 1980 by IEN 133.^[2] It is currently defined by RFC 1350. There have been some extensions to the TFTP protocol documented in later RFCs (see the section on Extensions, below). TFTP is based in part on the earlier protocol EFTP, which was part of the PUP protocol suite. TFTP support appeared first as part of 4.3 BSD.

Due to the lack of security, it is dangerous to use it over the Internet. Thus, TFTP is generally only used on private, local networks.

1 Overview
2 Protocol walkthrough
- 2.1 Additional details
- 2.2 Extensions
3 Known TFTP implementations
4 See also
5 References
6 Further reading

Overview

Trivial File Transfer Protocol (TFTP) is a simple protocol to transfer files. It has been implemented on top of the User Datagram Protocol (UDP) using port number 69. TFTP is designed to be small and easy to implement, and therefore it lacks most of the features of a regular FTP. TFTP only reads and writes files (or mail) from/to a remote server. It cannot list directories, and currently has no provisions for user authentication.

In TFTP, any transfer 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 transfer. If a packet gets lost in the network, the intended recipient will timeout and may retransmit his last packet (which may be data or an acknowledgment), thus causing the sender of the lost packet to retransmit that lost packet. The sender has to keep just one packet on hand for retransmission, since the lock step acknowledgment guarantees that all older packets have been received. Notice that both machines involved in a transfer are considered senders and receivers. One sends data and receives acknowledgments, the other sends acknowledgments and receives data.

TFTP typically uses UDP as its transport protocol, but it is not a requirement. Data transfer is initiated on port 69, but the data transfer ports are chosen independently by the sender and receiver during initialization of the connection. The ports are chosen at random according to the parameters of the networking stack, typically from the range of Ephemeral ports.^[3]

TFTP defines three modes of transfer: netascii, octet, and mail. Netascii is a modified form of ASCII, defined in RFC 764. It consists of an 8-bit extension of the 7-bit ASCII character space from 0x20 to 0x7F (the printable characters and the space) and eight of the control characters. The allowed control characters include the null (0x00), the line feed (LF, 0x0A), and the carriage return (CR, 0x0D). Netascii also requires that the end of line marker on a host be translated to the character pair CR LF for transmission, and that any CR must be followed by either a LF or the null.

Octet allows for the transfer of arbitrary 8-bit bytes, with the received file identical to the sent file. More correctly, if a host receives an octet file and then returns it, the returned file must be identical to the original.^[4] The Mail transfer mode uses Netascii transfer, but the file is sent to an email recipient by specifying that recipient's email address as the file name. RFC 1350 declared this mode of transfer obsolete.

No security or authentication is provided by the protocol specification. Unix implementations often restrict file transfers to a single configured directory, and only to read from files with world readability, and only write to already existing files that have world writeability.

Protocol walkthrough

(W1) Host A requests to write

(W2) Server S acknowledges request

(W3) Host A sends numbered data packets

(R1) Host A requests to read

(R2) Server S sends data packet 1

(R3) Host A acknowledges data packet 1

The initiating host A sends an RRQ (read request) or WRQ (write request) packet to host S at port number 69, containing the filename and transfer mode.
S replies with an ACK (acknowledgement) packet to WRQ and directly with a DATA packet to RRQ. Packet is sent from a freshly allocated ephemeral port, and all future packets to host S should be to this port.
The source host sends numbered DATA packets to the destination host, all but the last containing a full-sized block of data (512 bytes). The destination host replies with numbered ACK packets for all DATA packets.
The final DATA packet must contain less than a full-sized block of data to signal that it is the last. If the size of the transferred file is an exact multiple of the block-size, the source sends a final DATA packet containing 0 bytes of data.
Receiver responds to each DATA with associated numbered ACK. Sender responds to the first received ACK of a block with DATA of the next block.
If an ACK is not eventually received, a retransmit timer resends DATA packet.

Additional details

The original versions of TFTP, prior to RFC 1350, displayed a particularly bad protocol flaw which was named Sorcerer's Apprentice Syndrome (after "The Sorcerer's Apprentice" segment of Fantasia) when it was discovered.
In the early days of work on the TCP/IP protocol suite, TFTP was often the first protocol implemented on a new host type, because it was so simple.

Extensions

The original protocol has a file size limit of 32 MB. In 1998 this limit was extended to 4 GB by RFC 2347 which introduced option negotiation and RFC 2348 which introduced block-size negotiation. If the server and client support block number wraparound, file size is essentially unlimited.
Since TFTP utilizes UDP, it has to supply its own transport and session support. Each file transferred via TFTP constitutes an independent exchange. Classically, this transfer is performed in lock-step, with only one packet (either a block of data, or an 'acknowledgement') ever in flight on the network at any time. Due to this lack of windowing, TFTP provides low throughput over high latency links. Note that Windows 2008 introduced pipelined TFTP as part of Windows Deployment Services (WDS) and uses an 8 packet window by default. This substantially improves performance for things like PXE booting.

Known TFTP implementations

GNU inetutils: the GNU project network suite includes a TFTP client/server implementation
tftp-hpa: An opensource TFTP host published under BSD license.
atftp: a GPL client/server implementation of the TFTP protocol for Linux
tftp-server: a GPL, multi-threaded TFTP server for Linux
TFTP Server: a free mobile TFTP server for Apple iPhone and iPad
TFTP Server: TFTP server for OS X
Tftpd32: an opensource (EUPL) IPv6 ready TFTP and DHCP server/service for Windows
haneWIN DHCP: a shareware TFTP and DHCP server/service for Windows
Solarwinds TFTP Server: a freeware TFTP server
dnsmasq: a lightweight server designed to provide DNS, DHCP and TFTP
Serva: a freeware Automated PXE Server Solution Accelerator including TFTP Server (for Windows)

References

^ http://www.cisco.com/en/US/docs/ios/1 1_3/configfun/command/reference/frcfg fil.html#wp14279
^ Karen R. Sollins (1980-01-29). The TFTP Protocol. IETF. IEN 133. https://tools.ietf.org/rfcmarkup?url= ftp://ftp.rfc-editor.org/in-notes/ien /ien133.txt. Retrieved 2010-05-01.
^ Karen R. Sollins (July 1992). The TFTP Protocol (Revision 2). IETF. RFC 1350. https://tools.ietf.org/html/rfc1350. Retrieved 2010-05-01.
^ RFC 1350, page 5.

Contents