RFC 1350
The TFTP Protocol (Revision 2)
RFC 1350: THE TFTP PROTOCOL (REVISION 2) 🎀
Okay bestie, the tea first ☕ This is RFC 1350, THE TFTP PROTOCOL (REVISION 2), from the Network Working Group 🌸 K. Sollins at MIT wrote it, it came out in July 1992, and it's an IAB standards track protocol with STD 33 💖 It obsoletes RFC 783, so that older one is officially retired 🙈 Keep that in your back pocket as we go 💅
Status of this Memo ✨
So this RFC is an IAB standards track protocol for the Internet community, and it's basically begging for discussion and suggestions for improvements 🫶 If you want the current standardization state and status of this protocol, go check the current edition of the "IAB Official Protocol Standards" 📜 Distribution of this memo is unlimited, so share away 🌈
Summary 💖
TFTP is a super simple protocol for transferring files 🦋 That's literally where the name comes from: Trivial File Transfer Protocol, or TFTP. Each nonterminal packet gets acknowledged separately ✨ This doc describes the protocol and its types of packets, and it also explains the reasons behind some of the design decisions 💜
Acknowlegements 🫶
The protocol was originally designed by Noel Chiappa, who then redesigned it with Bob Baldwin and Dave Clark, with comments from Steve Szymanski 👑 The current revision picked up changes from discussions with and suggestions from Larry Allen, Noel Chiappa, Dave Clark, Geoff Cooper, Mike Greenwald, Liza Martin, David Reed, Craig Milo Rogers (of USC-ISI), Kathy Yellick, and the author 🧚 The acknowledgement and retransmission scheme was inspired by TCP, and the error mechanism came from PARC's EFTP abort message. Iconic borrowing, honestly 🔥
The May, 1992 revision that fixed the "Sorcerer's Apprentice" protocol bug [4] and other minor document problems was done by Noel Chiappa 🛠️
This research was supported by the Advanced Research Projects Agency of the Department of Defense and was monitored by the Office of Naval Research under contract number N00014-75-C-0661 🌈
1. Purpose 🌸
TFTP is a simple protocol for transferring files, which is why it got the name Trivial File Transfer Protocol or TFTP 🎀 It's been implemented on top of the Internet User Datagram protocol (UDP or Datagram) [2], so it can move files between machines on different networks that implement UDP 🦋 (This should not exclude the possibility of implementing TFTP on top of other datagram protocols.) It's designed to be small and easy to implement, so it's missing most of the features of a regular FTP 💅 The only thing it can do is read and write files (or mail) from or to a remote server. It cannot list directories, and it currently has no provisions for user authentication 🙈 Like other Internet protocols, it passes 8 bit bytes of data.
Three modes of transfer are currently supported 🍓 First is netascii (this is ascii as defined in "USA Standard Code for Information Interchange" [1], with the modifications specified in "Telnet Protocol Specification" [3].) Note that it is 8 bit ascii. The term "netascii" is used throughout this document to mean this particular version of ascii. Second is octet, which replaces the "binary" mode of previous versions of this document, so it's raw 8 bit bytes ✨ Third is mail, which is netascii characters sent to a user rather than a file. (The mail mode is obsolete and should not be implemented or used.) Lowkey a plot twist, but that's the lore 💀 Additional modes can be defined by pairs of cooperating hosts 🌸
Reference [4] (section 4.2) should be consulted for further valuable directives and suggestions on TFTP 📜
2. Overview of the Protocol 💅
Any transfer begins with a request to read or write a file, and that request also serves to request a connection 🦋 If the server grants the request, the connection opens and the file gets sent in fixed length blocks of 512 bytes 🎀 Each data packet holds one block of data, and it 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 time out and may retransmit its last packet (which may be data or an acknowledgment), which causes the sender of the lost packet to retransmit that lost packet 🔁 The sender only has to keep one packet on hand for retransmission, since the lock step acknowledgment guarantees that all older packets have been received. Notice that both machines in a transfer count as senders and receivers 👑 One sends data and receives acknowledgments, and the other sends acknowledgments and receives data. It's a whole tag-team situation 🫶
Most errors cause termination of the connection 🙈 An error gets signalled by sending an error packet. That packet is not acknowledged and not retransmitted (i.e., a TFTP server or user may terminate after sending an error message), so the other end of the connection may not get it. That's why timeouts are used to detect such a termination when the error packet has been lost 💀 Errors come from three types of events. The first is not being able to satisfy the request (e.g., file not found, access violation, or no such user). The second is receiving a packet that can't be explained by a delay or duplication in the network (e.g., an incorrectly formed packet). The third is losing access to a necessary resource (e.g., disk full or access denied during a transfer) 😭
TFTP recognizes only one error condition that does not cause termination, which is the source port of a received packet being incorrect 🧚 In that case, an error packet is sent to the originating host.
This protocol is very restrictive, in order to simplify implementation 💖 For example, the fixed length blocks make allocation straight forward, and the lock step acknowledgement provides flow control and eliminates the need to reorder incoming data packets. Minimalism, but make it iconic ✨
3. Relation to other Protocols 🦋
As mentioned, TFTP is designed to be implemented on top of the Datagram protocol (UDP) 🌈 Since Datagram is implemented on the Internet protocol, packets will have an Internet header, a Datagram header, and a TFTP header. Packets may also have a header (LNI, ARPA header, etc.) to get them through the local transport medium 🛸 As shown in Figure 3-1, the order of the contents of a packet is: local medium header (if used), Internet header, Datagram header, TFTP header, and then the remainder of the TFTP packet. (That remainder may or may not be data, depending on the type of packet as specified in the TFTP header.) TFTP does not specify any of the values in the Internet header 🙈
The source and destination port fields of the Datagram header (its format is given in the appendix) are used by TFTP, and the length field reflects the size of the TFTP packet 🎀 The transfer identifiers (TID's) used by TFTP get passed to the Datagram layer to be used as ports, so they must be between 0 and 65,535. How TID's get initialized is discussed in the section on initial connection protocol 🧠
The TFTP header is a 2 byte opcode field that indicates the packet's type (e.g., DATA, ERROR, etc.) 🍓 These opcodes and the formats of the various types of packets are covered further in the section on TFTP packets ✨
---------------------------------------------------
| Local Medium | Internet | Datagram | TFTP |
---------------------------------------------------
Figure 3-1: Order of Headers4. Initial Connection Protocol 🧚
A transfer is established by sending a request, either a WRQ (to write onto a foreign file system) or an RRQ (to read from it), and then receiving a positive reply 💜 For a write, that positive reply is an acknowledgment packet. For a read, it's the first data packet. In general, an acknowledgment packet contains the block number of the data packet being acknowledged. Each data packet has a block number, and block numbers are consecutive and begin with one 🌸 Since the positive response to a write request is an acknowledgment packet, the block number in that special case is zero. (Normally, since an acknowledgment packet is acknowledging a data packet, it contains the block number of the data packet being acknowledged.) If the reply is an error packet, then the request has been denied 🙈
To create a connection, each end chooses a TID for itself, to be used for the duration of that connection ✨ The TID's chosen for a connection should be randomly chosen, so that the probability of the same number being chosen twice in immediate succession is very low 🎲 Every packet has the two TID's of the ends of the connection attached to it, the source TID and the destination TID. These TID's are handed to the supporting UDP (or other datagram protocol) as the source and destination ports 🦋 A requesting host picks its source TID as described above, and sends its initial request to the known TID 69 decimal (105 octal) on the serving host 📮 Under normal operation, the response to the request uses a TID chosen by the server as its source TID, and the TID the requestor chose for the previous message as its destination TID. The two chosen TID's are then used for the rest of the transfer 💖
Here's an example of the steps used to establish a connection to write a file 🎀 WRQ, ACK, and DATA are the names of the write request, acknowledgment, and data types of packets, respectively. The appendix has a similar example for reading a file 🌈
1. Host A sends a "WRQ" to host B with source= A's TID,
destination= 69.
2. Host B sends a "ACK" (with block number= 0) to host A with
source= B's TID, destination= A's TID.At this point the connection is established, and Host A can send the first data packet with a sequence number of 1 🔥 In this step and all the succeeding steps, the hosts should make sure that the source TID matches the value that was agreed on in steps 1 and 2 🫶 If a source TID doesn't match, the packet should be discarded as erroneously sent from somewhere else. An error packet should be sent to the source of the incorrect packet, without disturbing the transfer. This can only be done if TFTP actually receives a packet with an incorrect TID. If the supporting protocols don't allow it, this particular error condition won't come up 💀
The following example shows the protocol working correctly in a situation where the above can happen 👑 Host A sends a request to host B. Somewhere in the network, the request packet gets duplicated, so two acknowledgments come back to host A, with different TID's chosen on host B in response to the two requests. When the first response arrives, host A continues the connection. When the second response arrives, it should be rejected, but there's no reason to terminate the first connection 😤 So if host B chooses different TID's for the two connections, and host A checks the source TID's of the messages it receives, the first connection can be kept while the second gets rejected by returning an error packet 🧚
5. TFTP Packets ✨
okay bestie, TFTP only has five packet types 💅 and we've been name-dropping them since the start, so here's the full lineup:
opcode operation
1 Read request (RRQ)
2 Write request (WRQ)
3 Data (DATA)
4 Acknowledgment (ACK)
5 Error (ERROR)every packet's TFTP header carries the opcode that goes with it 🎀
2 bytes string 1 byte string 1 byte
------------------------------------------------
| Opcode | Filename | 0 | Mode | 0 |
------------------------------------------------Figure 5-1: RRQ/WRQ packet
RRQ and WRQ packets (opcodes 1 and 2 respectively) are shaped like Figure 5-1 🦋 The filename is a run of bytes in netascii that ends with a zero byte. The mode field holds a string in netascii that says netascii, octet, or mail, and it's totally fine to mix up the capitals (like NETASCII or NetAscii). Those are the three modes TFTP defines. A host that receives netascii mode data must translate it into its own format 🧚
Octet mode is for moving a file that's already in the 8-bit format of the machine it's coming from. The idea is that every type of machine has one 8-bit format that's the most common, and that's the one that gets used. For example, a DEC-20 is a 36-bit machine, so its word is four 8-bit bytes with four bits of breakage 🙈 If a host gets an octet file and then sends it back, the returned file must be identical to the original, no exceptions. Mail mode swaps the file name for the name of a mail recipient, and it must begin with a WRQ. Otherwise it works exactly like netascii mode. The recipient string should look like "username" or "username@hostname". If you use the second form, a relay computer can forward the mail for you 💌
Now, all of this assumes the sender and the recipient are in the same mode, but they don't have to be 🌈 Picture a storage server. It has no reason to translate netascii into its own kind of text. The sender could send netascii, and the storage server could just stash the bytes as they are in 8-bit format. There's also a real DEC-20 problem: neither netascii nor octet can get at every bit in a word. You could invent a special mode that reads all the bits, with the receiver storing the data in 8-bit format. When that kind of file comes back from the storage site, it has to be restored to its original form to be useful, so the reverse mode must be implemented too, and the user site will have to remember some info to pull that off. In both examples, the request packets say octet mode to the foreign host, but the local host runs in some other mode. TFTP hasn't specified any machine-specific or application-specific modes, but one could still be compatible with this spec ✨
You can also define other modes for pairs of hosts that agree to work together, but this has to be done with care 🔥 No other hosts are required to implement those modes. Nobody's in charge of defining these modes or handing out their names either.
Data gets moved around in DATA packets, shown in Figure 5-2 🌸
2 bytes 2 bytes n bytes
----------------------------------
| Opcode | Block # | Data |
----------------------------------Figure 5-2: DATA packet
DATA packets (opcode = 3) carry a block number and a data field 💖 Block numbers start at one and go up by one for each new block of data. That's the whole trick, because it lets the program use one number to tell new packets apart from duplicates. The data field can be anywhere from zero to 512 bytes long. If it's exactly 512 bytes, the block isn't the last one. If it's from zero to 511 bytes, that's the end of the transfer. (See the section on Normal Termination for details.)
Almost every packet gets an acknowledgment unless a timeout happens [4] 🫶 The only exceptions are duplicate ACKs and the packets used for termination. Sending a DATA packet counts as an acknowledgment for the first ACK packet of the previous DATA packet. WRQ and DATA packets get acknowledged by ACK or ERROR packets, while RRQ and ACK packets get acknowledged by DATA or ERROR packets. Figure 5-3 shows an ACK packet, and its opcode is 4 🎀 The block number in an ACK echoes the block number of the DATA packet it's acknowledging. A WRQ gets an ACK with a block number of zero.
2 bytes 2 bytes
---------------------
| Opcode | Block # |
---------------------Figure 5-3: ACK packet
2 bytes 2 bytes string 1 byte
-----------------------------------------
| Opcode | ErrorCode | ErrMsg | 0 |
-----------------------------------------Figure 5-4: ERROR packet
ERROR packets (opcode 5) look like Figure 5-4 😭 An ERROR packet can acknowledge any other type of packet. The error code is an integer that tells you what went wrong, and the appendix has a table of values and what they mean. (Note that several error codes were added to this version of the document.) The error message is for humans to read, so it should be in netascii. Like every other string in here, it ends with a zero byte.
6. Normal Termination 🏁
A transfer officially ends with a DATA packet that holds between 0 and 511 bytes of data (aka a datagram length under 516) 🎉 That final DATA packet gets an ACK like every other DATA packet. The host sending that final ACK can close its side of the connection right after it sends it. BUT dallying is encouraged, which means the host sending the final ACK waits around a little before closing, just in case the ACK got lost and has to be sent again. The acknowledger knows the ACK was lost if the final DATA packet shows up again 👀 The host that sent the last DATA has to keep resending it until it gets acknowledged or it times out. If the response is an ACK, the transfer finished successfully ✨ If the sender times out and isn't willing to resend anymore, the transfer may still have worked, and then the acknowledger or the network may have hit a problem afterward. It's also possible the transfer failed. Either way, the connection is closed by then 🔒
7. Premature Termination 🚨
If a request can't be granted, or some error shows up during the transfer, an ERROR packet (opcode 5) gets sent 💀 This is only a courtesy, though, because it won't be retransmitted or acknowledged, so it might never arrive. That's why timeouts must also be used to detect errors.
I. Appendix 🌸
Order of Headers
2 bytes
----------------------------------------------------------
| Local Medium | Internet | Datagram | TFTP Opcode |
----------------------------------------------------------TFTP Formats
Type Op # Format without header
2 bytes string 1 byte string 1 byte
-----------------------------------------------
RRQ/ | 01/02 | Filename | 0 | Mode | 0 |
WRQ -----------------------------------------------
2 bytes 2 bytes n bytes
---------------------------------
DATA | 03 | Block # | Data |
---------------------------------
2 bytes 2 bytes
-------------------
ACK | 04 | Block # |
--------------------
2 bytes 2 bytes string 1 byte
----------------------------------------
ERROR | 05 | ErrorCode | ErrMsg | 0 |
----------------------------------------Initial Connection Protocol for reading a file
- Host A sends a
"RRQ"to host B withsource= A's TIDanddestination= 69🚀 - Host B sends a
"DATA"(with block number= 1) to host A withsource= B's TIDanddestination= A's TID💖
Error Codes
Value Meaning
0 Not defined, see error message (if any).
1 File not found.
2 Access violation.
3 Disk full or allocation exceeded.
4 Illegal TFTP operation.
5 Unknown transfer ID.
6 File already exists.
7 No such user.Internet User Datagram Header [2]
(This is only here for convenience 🎀 TFTP doesn't have to sit on top of the Internet User Datagram Protocol.)
Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Values of Fields
Source Port Picked by originator of packet.
Dest. Port Picked by destination machine (69 for RRQ or WRQ).
Length Number of bytes in UDP packet, including UDP header.
Checksum Reference 2 describes rules for computing checksum.
(The implementor of this should be sure that the
correct algorithm is used here.)
Field contains zero if unused.Note: TFTP passes transfer identifiers (TID's) to the Internet User Datagram protocol to be used as the source and destination ports. 🧚
References 📚
- [1] USA Standard Code for Information Interchange, USASI X3.4-1968.
- [2] Postel, J., "User Datagram Protocol," RFC 768, USC/Information Sciences Institute, 28 August 1980.
- [3] Postel, J., "Telnet Protocol Specification," RFC 764, USC/Information Sciences Institute, June, 1980.
- [4] Braden, R., Editor, "Requirements for Internet Hosts -- Application and Support", RFC 1123, USC/Information Sciences Institute, October 1989.
Security Considerations 🔥
Since TFTP has no login or access control mechanisms, you have to be really careful about the rights you give a TFTP server process so it doesn't break the security of the server host's file system 😱 TFTP is often installed with controls so that only files with public read access can be reached through it, and writing files through TFTP is disallowed.
This is the big one, bestie. TFTP has no login or access control, so whatever rights the server process gets are the rights the whole file system is exposed to. Lock it down before you let anyone near it.
Author's Address 💌
Karen R. Sollins
Massachusetts Institute of Technology
Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139-1986
Phone: (617) 253-6006
EMail: SOLLINS@LCS.MIT.EDU📦 where this page comes from
- ietf: rfc1350 1992-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms