The TFTP Protocol (Revision 2)
obsoletes
- rfc-783 — TFTP Protocol (revision 2)
updated by
- rfc-1782 — TFTP Option Extension
- rfc-1783 — TFTP Blocksize Option
- rfc-1784 — TFTP Timeout Interval and Transfer Size Options
- rfc-1785 — TFTP Option Negotiation Analysis
- rfc-2347 — TFTP Option Extension
- rfc-2348 — TFTP Blocksize Option
- rfc-2349 — TFTP Timeout Interval and Transfer Size Options
also
- std-33
Extracted elements (24)
Block numbers begin at 1 and increase by one, which allows a single number to discriminate between new packets and duplicates—a deliberate simplification that supports the single-packet retransmission model.
Each side of the connection maintains only one packet for retransmission because the lock-step acknowledgment guarantees all older packets have been received, keeping implementation memory requirements minimal.
Error packets are sent as a courtesy but are not retransmitted or acknowledged, so they may never be received. This was an intentional simplification; timeouts are the reliable termination-detection mechanism.
Fixed 512-byte data blocks were chosen to make buffer allocation straightforward. Lock-step acknowledgment provides flow control and eliminates the need to reorder incoming data packets, deliberately sacrificing throughput for implementation simplicity.
The May 1992 revision of RFC 1350 was made specifically to fix the 'Sorcerer's Apprentice' protocol bug described in RFC 1123 section 4.2, where duplicate requests could cause packet storms; implementations should consult RFC 1123 for further directives.
The mode field in RRQ/WRQ is case-insensitive; any combination of upper and lower case (e.g., 'NETASCII', 'NetAscii') is acceptable. Sender and recipient are not required to operate in the same mode.
A host that receives data in netascii mode must translate the data to its own local format. Octet mode transfers raw 8-bit bytes, and a file sent in octet mode and returned must be identical to the original.
An ERROR packet is not acknowledged and not retransmitted; therefore timeouts must be used to detect connection termination when an error packet is lost.
Each non-terminal DATA packet must be acknowledged by an ACK packet before the next packet can be sent (lock-step acknowledgment). A data packet of less than 512 bytes signals transfer termination.
If a packet is received with a source TID that does not match the agreed-upon TID, the packet should be discarded and an error packet (error code 5, Unknown transfer ID) should be sent to the source of the incorrect packet without disturbing the ongoing transfer.
Initial TFTP requests (RRQ or WRQ) MUST be sent to the well-known TID 69 decimal (105 octal) on the serving host. The server responds using a newly chosen source TID.
Mail mode is obsolete and should not be implemented or used. The two remaining valid transfer modes are 'netascii' and 'octet'.
The host acknowledging the final DATA packet should 'dally'—wait for a period before terminating—so it can retransmit the final ACK if the final DATA packet is received again, indicating the ACK was lost.
The host sending the last DATA packet must retransmit it until the packet is acknowledged or the host times out. If a timeout occurs without acknowledgment, the transfer outcome is indeterminate.
TIDs 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. TIDs must be between 0 and 65,535 to be valid as UDP port numbers.
TFTP defines five packet types: RRQ (1), WRQ (2), DATA (3), ACK (4), and ERROR (5), identified by a 2-byte opcode in the TFTP header.
TFTP error codes: 0=Not defined (see message), 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.
TFTP includes no login or access control mechanisms. Care must be taken in rights granted to a TFTP server process; common practice restricts TFTP to files with public read access and disallows write access to prevent unauthorized access to the server's file system.
Connection establishment: client sends RRQ or WRQ to port 69; server responds with DATA block 1 (for RRQ) or ACK block 0 (for WRQ), establishing the TID pair. Subsequent packets use only these two TIDs. An ERROR response denies the request.
Normal transfer termination: triggered when a DATA packet with 0–511 bytes is received, acknowledged with a final ACK. The sender retransmits the final DATA until ACKed or timed out; the acknowledger dallies to handle retransmission of the final ACK.
ACK packet format (opcode=4): 2-byte opcode followed by 2-byte block number echoing the DATA packet being acknowledged. A WRQ is acknowledged with block number zero.
DATA packet format (opcode=3): 2-byte opcode, 2-byte block number (starting at 1), followed by 0 to 512 bytes of data. A data field shorter than 512 bytes signals the last block.
ERROR packet format (opcode=5): 2-byte opcode, 2-byte error code, null-terminated netascii error message string. The error code is an integer from the defined error code table.
RRQ/WRQ packet format: 2-byte opcode (1=RRQ, 2=WRQ), followed by a null-terminated netascii filename string, followed by a null-terminated netascii mode string ('netascii', 'octet', or 'mail').