Trivial File Transfer Protocol

From Computing and Software Wiki

Current revision as of 15:55, 12 April 2009

The Trivial File Transfer Protocol (TFTP) was developed in 1980 by Noel Chiappa as a simple protocol to transfer files between computers.^[1] It is implemented using UDP (Port 69), and is designed to be lightweight (specifically on memory usage) and easy to implement. As such, it is very limited in features compared to other alternatives (FTP, SFTP) as well as security. Due to its lack of security features, it is not safe to use over the open internet, but is still used in private networks as a quick way to transfer files. It is also used to transfer small amounts of data in IP phone firmware as well as in network installations of many current operating systems to load the basic kernel. Windows, Linux and Mac OS all ship with the TFTP server included and disabled by default. The early versions of TFTP were flawed with what was called the Sorcerer's Apprentice Syndrome - causing ever growing packet replication during the transfer.^[1]

TFTP has only two features, reading and writing files. It offers no method of listing directory contents, displaying or changing file permissions or even user authentication.^[1]

Transfer Modes

TFTP features 3 different transfer modes: netascii, for the transfer of ascii files using 8-bit ascii characters, octet, which transfers binary files byte by byte between computers and mail, which was much like netascii but sent the file to a user rather than to the filesystem.^[1] For many years, the protocol allowed transfer of up to 32MB files. This limited transfer size was suitable for its time, however, as most files were small. It wasn't until 1998 in RFC 2348 when option extensions allowed for files up to 4GB which made the protocol more suitable for modern use.^[2]

Each transfer through TFTP occurs with a single packet being moved across the network at a time. These packets can either be a block of data or an acknowledgment. As TFTP is implemented using UDP, it utilizes its own methods for transport and session acknowledgement to create a more reliable connection.

Errors

Errors are signalled by sending a specific error packet and normally causes termination of the connection. Error packets are not acknowledged or retransmitted and as such, may not be received by the server or host. There are three different sources of error, namely: inability to satisfy the request (file not found, no permission, etc.), incorrectly formed packets and losing access to a critical resource (out of disk space, etc.). All of these errors will cause the connection to drop. If the source port is incorrect, an error packet will be sent to the originating host and the connection will not be dropped.

Operation

This section will outline the steps that occur during the normal operation of the TFTP server.

Write

An example occurrence of events during a write operation.

1. To initialize a write operation, a write request (WRQ) is sent from the local host to the remote server on UDP Port 69.
2. If the server is listening and accepting TFTP requests, it sends back an acknowledgment (ACK) to the local host on a randomly assigned ephemeral port. This is the port where the transfer of the actual data will occur.
3. Once received by the local host, the first of the data is sent in a 512 byte block to the remote server on the port which the acknolwedgement was received.
4. Each data block received by the server is acknolwedged with an ACK message back to the host before the next byte is transmitted. If no ACK is received within the retransmit timer, the unacknowledged block is resent.
5. The process continues until a partial data block or an empty data block (when the data fits into a distinct number of blocks) is received, indicating the end of the transfer.

Read

An example occurrence of events during a read operation.

1. To initialize a read operation, a read request (RRQ) is sent from the local host to the remote server on UDP Port 69.
2. If the server is listening and accepting TFTP requests, it sends back the first block of data to the local host on a randomly assigned ephemeral port.
3. Once received by the local host, the host sends back an acknowledgment (ACK) to the remote server on the port which the data was received.
4. Each data block received by the host is acknolwedged with an ACK message back to the server before the next byte is transmitted. If no ACK is received within the retransmit timer, the unacknowledged block is resent.
5. The process continues until a partial data block or an empty data block (when the data fits into a distinct number of blocks) is received, indicating the end of the transfer.

See Also

• Secure File Transfer Protocols

References

1. The TFTP Protocol, January 29, 1980 by Karen R. Sollins. Available at http://www.isi.edu/in-notes/ien/ien133.txt
2. TFTP Blocksize Option,May 1998. Available at http://www.ietf.org/rfc/rfc2348.txt

--Russeld 11:55, 12 April 2009 (EDT)