RFC 1784

TFTP Timeout Interval and Transfer Size Options 🎀

okay bestie, this is RFC 1784, and it's giving Standards Track 👑 It's from March 1995, written by G. Malkin of Xylogics, Inc. and A. Harkin of Hewlett Packard Co. 💖 It updates RFC 1350 (that's the TFTP spec!) and doesn't obsolete anything. The whole point is adding two little options to TFTP using the option extension mechanism from RFC 1782 ✨

---

Status of This Memo 📜

this is an Internet standards track protocol for the Internet community, and the authors are literally asking for discussion and suggestions for improvements 🫶 If you want the current standardization state, check the "Internet Official Protocol Standards" (STD 1) doc. Distribution of this memo is unlimited, so share away 🦋

Abstract 🌸

TFTP [1] is a simple, lock-step file transfer protocol that lets a client get a file from a remote host or put one onto it. It's giving minimalist icon energy 💅

This document adds two options. The first lets the client and server negotiate the Timeout Interval ⏱️ The second lets the side receiving the file figure out the final size of the transfer before it even begins 🙈 The TFTP Option Extension mechanism is described in [2].

This doc assumes you already know the terminology and notation from both [1] and [2], so go read those first, babe 📚

Timeout Interval Option Specification 🕰️

The TFTP Read Request or Write Request packet gets a glow-up to include the timeout option, and it looks like this:

+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
|  opc  |filename| 0 |  mode  | 0 | timeout| 0 |  #secs | 0 |
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+

Here's what each field does:

• opc: the opcode, which is either 1 for Read Requests or 2 for Write Requests, as defined in [1].
• filename: the name of the file being read or written, as defined in [1]. It's NULL-terminated.
• mode: the transfer mode, which is "netascii", "octet", or "mail", as defined in [1]. It's also NULL-terminated.
• timeout: the Timeout Interval option, spelled "timeout" (case insensitive). NULL-terminated, obviously 💀
• #secs: the number of seconds to wait before retransmitting, written in ASCII. Valid values run from "1" to "255" octets, inclusive. NULL-terminated too.

Here's an example of how it looks in action ✨

+-------+--------+---+--------+---+--------+---+--------+---+
|   1   | foobar | 0 | binary | 0 | timeout| 0 |    1   | 0 |
+-------+--------+---+--------+---+--------+---+--------+---+

That's a Read Request for the file "foobar", in binary transfer mode, with a timeout interval of 1 second. Iconic 🎀

If the server is down to accept the timeout option, it sends an Option Acknowledgment (OACK) back to the client 🫶 The timeout value in that OACK must match the one the client asked for, no exceptions 🔥

Transfer Size Option Specification 📦

The Read Request or Write Request packet also gets a size upgrade with the tsize option:

+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
|  opc  |filename| 0 |  mode  | 0 | tsize  | 0 |  size  | 0 |
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+

• opc: the opcode, which is 1 for Read Requests or 2 for Write Requests, as defined in [1].
• filename: the name of the file being read or written, as defined in [1]. NULL-terminated.
• mode: the transfer mode, "netascii", "octet", or "mail", as defined in [1]. NULL-terminated.
• tsize: the Transfer Size option, spelled "tsize" (case insensitive). NULL-terminated.
• size: the size of the file being transferred, written as a NULL-terminated ASCII string.

Example time 💖

+-------+--------+---+--------+---+--------+---+--------+---+
|   2   | foobar | 0 | binary | 0 | tsize  | 0 | 673312 | 0 |
+-------+--------+---+--------+---+--------+---+--------+---+

That's a Write Request for the 673312-octet file named "foobar", in binary mode 🦋

Now the main event. In Read Requests, the client puts a size of "0" in the request, and the server sends back the real file size in octets in the OACK 🧚 If the client decides the file is too big to handle, it can abort the transfer with an Error packet (error code 3) 🙈

In Write Requests, it's the reverse. The size is given in the request and echoed back in the OACK. If the server thinks the file is too big to handle, it can abort the transfer with an Error packet (error code 3) 💀

Both sides can bail with error code 3 if the file is too large. Protocol drama, but make it safe 🫶

---

Security Considerations 🔐

Security issues are not discussed in this memo. Full stop, no cap. Just because this doc doesn't cover security doesn't mean you can ignore it, so keep that in your back pocket when you implement this 😭

References 📚

• [1] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, MIT, July 1992.
• [2] Malkin, G., and A. Harkin, "TFTP Option Extension", RFC 1782, Xylogics, Inc., Hewlett Packard Co., March 1995.

Authors' Addresses 💌

• Gary Scott Malkin Xylogics, Inc. 53 Third Avenue Burlington, MA 01803 Phone: (617) 272-8140 EMail: gmalkin@xylogics.com
• Art Harkin Internet Services Project Information Networks Division 19420 Homestead Road MS 43LN Cupertino, CA 95014 Phone: (408) 447-3755 EMail: ash@cup.hp.com

That's the whole RFC, bestie! 🌈💅🧚