RFC 1785

TFTP Option Negotiation Analysis 🎀

Okay bestie, let's get into this one 💖 First the title block: this is RFC 1785, and it's an Informational doc 🌸 Which means it's sharing info with the Internet community, not setting any official standard. It's dated March 1995 and was written by Gary Scott Malkin (Xylogics, Inc.) and Art Harkin (Hewlett Packard Co.). It updates RFC 1350, the TFTP Protocol (Revision 2) 💅

Status of this Memo ✨

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited 🫶

Abstract 🦋

Okay so the TFTP option negotiation mechanism, which was proposed in [1], is a backward-compatible extension to the TFTP protocol defined in [2] 🧚 It lets file transfer options get negotiated before the transfer starts, and it does this in a way that matches TFTP's Request Packet format, so it's giving consistency ✨ To keep it simple, it enforces a request-respond-acknowledge sequence, which is lowkey similar to the lock-step approach TFTP already takes itself 🔥

This document was written to ease worries that having options in a TFTP Request packet might cause pathological behavior on servers that don't support TFTP option negotiation 🙈 Like, that's the big fear, and the rest of this doc is the receipts 💜

Test Results 🧪

A TFTP client, modified to send TFTP options, was tested against five unmodified servers 😭 Here they are:

      DEC   DEC 3000/400 alpha   OSF1 V3.0
      SGI   IP17 mips            IRIX 5.2
      SUN   sun4c sparc          SunOS 5.1
      IBM   RS/6000 Model 320    AIX 3.4
      SUN   sun4m                SunOS 4.1.3

In every single case, the servers ignored the option info in the Request packet, and the transfer went ahead like no option negotiation had even been attempted 💀 Iconic behavior honestly 👑

The standard BSD4.3 source for TFTPD was also looked at. That's the starting point for a lot of implementations, so it matters 🍓 The code clearly ignores any extra info in Request packets. No drama, no cap 🌈

From these results and this code review, it's clear that the TFTP option negotiation mechanism is fully backward-compatible with unmodified TFTP servers ✨🎉 The servers just vibe past the extra stuff and keep going 🦋

Security Considerations 🔒

Security issues are not discussed in this memo. 💀 Honestly that's a whole plot twist, so keep it in mind when you're reading the rest 🙈

References 📚

[1] Malkin, G., and A. Harkin, "TFTP Option Extension", RFC 1782,
    Xylogics, Inc., Hewlett Packard Co., March 1995.

[2] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350,
    MIT, July 1992.

Related Documents 🧚‍♀️

These two are the sister docs, so you'll want them too 💖

Malkin, G., and A. Harkin, "TFTP Blocksize Option", RFC 1783,
    Xylogics, Inc., Hewlett Packard Co., March 1995.

Malkin, G., and A. Harkin, "TFTP Timeout Interval and Transfer Size
    Options", RFC 1784, Xylogics, Inc., Hewlett Packard Co., March
    1995.

Authors' Addresses 🫶

Here's how to reach the authors, iykyk 🎀

   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