From Wikipedia, the free encyclopedia - View original article
Trivial File Transfer Protocol (TFTP) is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. One of its primary uses is in the early stages of nodes booting from a Local Area Network. TFTP has been used for this application because it is very simple to implement.
Due to its simple design, TFTP can be easily implemented by small footprint code. It is therefore the protocol of choice for the initial stages of any network booting strategy like BOOTP, PXE, BSDP, etc, when targeting from highly resourced computers to very low resourced Single-board computers (SBC) and System on a Chip (SoC). It is also used to transfer firmware images and configuration files to network appliances like routers, firewalls, IP phones, etc. Today TFTP is virtually unused for Internet transfers.
TFTP's design was influenced from the earlier protocol EFTP, which was part of the PUP protocol suite. TFTP was first defined in 1980 by IEN 133. In June 1981 The TFTP Protocol (Revision 2) was published as RFC 783 and later updated in July 1992 by RFC 1350 which fixed among other things the Sorcerer's Apprentice Syndrome. In March 1995 the TFTP Option Extension RFC 1782 updated later in May 1998 by RFC 2347, defined the option negotiation mechanism which establishes the framework for file transfer options to be negotiated prior to the transfer using a mechanism which is consistent with TFTP's original specification.
TFTP is a simple protocol for transferring files, implemented on top of the UDP/IP protocols using IANA registered port number 69. TFTP was designed to be small and easy to implement, and therefore it lacks most of the advanced features offered by more robust file transfer protocols. TFTP only reads and writes files from or to a remote server. It cannot list, delete, or rename files or directories and it has no provisions for user authentication. Today TFTP is generally only used on local area networks (LAN).
In TFTP, a transfer is initiated by the client issuing a request to read or write a particular file on the server. The request can optionally include a set of negotiated transfer parameters proposed by the client under the terms specified by RFC 2347. If the server grants the request, the file is sent in fixed length blocks of 512 bytes by default or the number specified in the blocksize negotiated option defined by RFC 2348. Each block of transferred data which is usually carried within a single IP packet in order to avoid IP fragmentation, must be acknowledged by an acknowledgment packet before the next block can be sent. A data packet of less than 512 bytes or the agreed blocksize option signals termination of a transfer. If a packet gets lost in the network, the intended recipient will timeout and may retransmit their 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 correctly received. Notice that both devices involved in a transfer are considered senders and receivers. One sends data and receives acknowledgments, the other sends acknowledgments and receives data.
TFTP defines three modes of transfer: netascii, octet, and mail.
TFTP uses UDP as its transport protocol. A transfer request is always initiated targeting port 69, but the data transfer ports are chosen independently by the sender and receiver during the transfer initialization. The ports are chosen at random according to the parameters of the networking stack, typically from the range of ephemeral ports.
TFTP includes no login or access control mechanisms. Care must be taken in the rights granted to a TFTP server process so as not to violate the security of the server's file system. TFTP is often installed with controls such that only files that have public read access are available via TFTP. Also, listing, deleting, renaming, and writing files via TFTP are typically disallowed. The use of TFTP is appropriate on networks where the inherent protocol limitations are not a liability.
TFTP has always been associated to network booting. One of the first attempts in this regard was the Bootstrap Loading using TFTP standard RFC 906, published in 1984, which established the 1981 published Trivial File Transfer Protocol standard RFC 783 to be used as the standard file transfer protocol for bootstrap loading. It was followed shortly after by the Bootstrap Protocol standard RFC 951 (BOOTP), published in 1985, which allowed a disk-less client machine to discover its own IP address, the address of a TFTP server, and the name of a Network Bootstrap Program (NBP) to be TFTP transferred, loaded into memory, and executed. Dynamic Host Configuration Protocol standard RFC 2131 (DHCP) published in 1997 improved BOOTP capabilities. Finally, the Preboot Execution Environment (PXE) version 2.0 was released in December 1998, and the update 2.1 was made public in September 1999 counting on TFTP as its file transfer protocol. Intel has recently decided to widely support PXE within the new UEFI specification extending the TFTP support to all EFI/UEFI environments.
The original protocol has a transfer file size limit of 512 bytes/block x 65535 blocks = 32 MB. In 1998 this limit was extended to 1468 bytes/block x 65535 blocks = 93 MB by TFTP Blocksize Option RFC 2348. If IP fragmentation is not an option the maximum block size is the size of an Ethernet MTU (1500) minus the headers of TFTP (4 bytes), UDP (8 bytes) and IP (20 bytes) = 1468 bytes/block. Today most servers and clients support block number roll-over (block counter going back to 0 after 65535) then the transfer 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') alternatively in flight on the network at any time. Due to this single data block strategy instead of sending a fluid amount of data blocks before to pause the transfer waiting for an acknowledge (windowing), TFTP provides low throughput specially over high latency links. Note that Windows 2008 introduced windowed TFTP as part of Windows Deployment Services (WDS) and uses an 8 block, window by default. This substantially improves performance for things like PXE booting.
|RFC Number||Title||Published||Author||Obsolete and Update Information|
|RFC 783||The TFTP Protocol (Revision 2)||June 1981||K.Sollins||Obsoleted by - RFC 1350|
|RFC 906||Bootstrap Loading using TFTP||June 1984||Ross Finlayson||-|
|RFC 951||Bootstrap Protocol||Sep.1985||Bill Croft||Updated by RFC 1395, RFC 1497, RFC 1532, RFC 1542, RFC 5494|
|RFC 1350||The TFTP Protocol (Revision 2)||July 1992||K.Sollins||Updated by RFC 1782, RFC 1783, RFC 1784, RFC 1785, RFC 2347, RFC 2348, RFC 2349|
|RFC 1782||TFTP Option Extension||March 1995||G. Malkin||Obsoleted by - RFC2347|
|RFC 2131||Dynamic Host Configuration Protocol||March 1997||R. Droms||Updated by RFC 3396, RFC 4361, RFC 5494, RFC 6842|
|RFC 2347||TFTP Option Extension||May 1998||G.Malkin||-|
|RFC 2348||TFTP Blocksize Option||May 1998||G.Malkin||-|
|RFC 2349||TFTP Timeout Interval and Transfer Size Options||May 1998||G.Malkin||-|