RFC 2347

TFTP Option Extension

πŸ“… published May 1998, from ietf

RFC 2347: TFTP Option Extension ✨

Okay bestie, so this is RFC 2347 πŸŽ€, the TFTP Option Extension, written by Gary Scott Malkin (Bay Networks) and Art Harkin (Hewlett Packard Co.). It's a Standards Track doc, dated May 1998. It updates RFC 1350 and obsoletes RFC 1782 πŸ’….


Status of This Memo πŸ“‹

Okay so this doc is an Internet standards track protocol for the whole Internet community 🌐, and it's literally begging for discussion and suggestions to make it better πŸ₯Ί. For the current standardization state and status of this protocol, check the "Internet Official Protocol Standards" (STD 1), iykyk. And distribution of this memo is unlimited, so share away πŸ’–.

Copyright (C) The Internet Society (1998). All Rights Reserved. The Internet Society holds it down πŸ”’.

Abstract πŸ¦‹

TFTP [1] is the Trivial File Transfer Protocol, and it's giving simple, lock-step energy. A client can get a file from a remote host or put one onto it πŸ“. This doc adds a simple extension to TFTP so the two sides can negotiate options before the file transfer even starts ✨.

Introduction 🌸

Okay so the option negotiation mechanism in this doc is a backward-compatible extension to TFTP, which is honestly iconic πŸ‘‘. It lets file transfer options get negotiated before the transfer, and it does this in a way that matches TFTP's Request Packet format, so it fits right in 🫢.

It's kept simple by enforcing a request-respond-acknowledge sequence, which is basically the same lock-step approach TFTP already uses itself 🧚.

Now, the mechanism is general purpose, so lots of different kinds of options can be negotiated 🌈. It was originally created to support the Blocksize option defined in [2]. Additional options are defined in [3] πŸ’œ.

Packet Formats πŸŽ€

Okay so TFTP options get tacked onto the end of the Read Request and Write Request packets πŸ“¦. There's also a brand new packet type, the Option Acknowledgment (OACK), which is used to acknowledge a client's option negotiation request πŸ’…. And a new error code, 8, is hereby defined to signal that a transfer should be terminated because of option negotiation πŸ’€.

Here's how options get appended to a TFTP Read Request or Write Request packet:

+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+-->
|  opc  |filename| 0 |  mode  | 0 |  opt1  | 0 | value1 | 0 | <
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+-->

 >-------+---+---~~---+---+
<  optN  | 0 | valueN | 0 |
 >-------+---+---~~---+---+

Let's break down each field, bestie 🧁:

  • opc is the opcode field. It contains either a 1, for Read Requests, or 2, for Write Requests, as defined in [1] πŸ”₯.
  • filename is the name of the file to be read or written, as defined in [1]. It's a NULL-terminated field πŸ“.
  • mode is the mode of the file transfer: "netascii", "octet", or "mail", as defined in [1]. It's also NULL-terminated πŸ“.
  • opt1 is the first option, in case-insensitive ASCII (e.g., blksize). It's NULL-terminated too 🧚.
  • value1 is the value associated with the first option, in case-insensitive ASCII. Yep, NULL-terminated πŸ’–.
  • optN, valueN is the final option/value pair. Each NULL-terminated field is specified in case-insensitive ASCII πŸ¦‹.

Okay so the options and values are all NULL-terminated, same as the original request format, which is so consistent of them πŸ₯Ή. If you're negotiating multiple options, they just get appended to each other 🫢. The order of the options doesn't matter at all, not significant, periodt πŸ’….

Heads up: the maximum size of a request packet is 512 octets. ⚠️

Now the OACK packet looks like this:

+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
|  opc  |  opt1  | 0 | value1 | 0 |  optN  | 0 | valueN | 0 |
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+

And the fields work like this ✨:

  • opc contains a 6, for Option Acknowledgment 🌟.
  • opt1 is the first option acknowledgment, copied from the original request πŸ“‹.
  • value1 is the acknowledged value associated with the first option. Whether and how this value can differ from the original request is spelled out in the specification for that option πŸ”.
  • optN, valueN is the final option/value acknowledgment pair πŸ’œ.

Okay bestie, the legal bit at the end! πŸ’… Copyright (C) The Internet Society (1998). All Rights Reserved. 🌸

So you can copy this document and hand it out to people, and you can make derivative works that comment on or explain it or help people implement it. You can publish and distribute those too, in whole or in part, with no restrictions of any kind, as long as the copyright notice and this paragraph are on every copy and derivative work. ✨

But the document itself can't be modified in any way. That means no removing the copyright notice or the references to the Internet Society or other Internet organizations. There are two exceptions: developing Internet standards, where the procedures for copyrights defined in the Internet Standards process must be followed, or translating it into languages other than English. 🌈

The permissions above are perpetual, so the Internet Society or its successors or assigns won't revoke them. πŸ¦‹

And the boring-but-important part 😭: this document and the info in it is provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. no cap, they're not promising it's perfect πŸ’€

πŸ“¦ where this page comes from