TFTP Options Analysis: TFTP Option Negotiation Analysis
Testing backward compatibility of TFTP option negotiation with old servers.
Malkin, G. and A. Harkin, "TFTP Option Negotiation Analysis", RFC 1785, DOI 10.17487/RFC1785, March 1995, <https://www.rfc-editor.org/info/rfc1785>.
@misc{rfc1785,
series = {Request for Comments},
number = 1785,
howpublished = {RFC 1785},
publisher = {RFC Editor},
doi = {10.17487/RFC1785},
url = {https://www.rfc-editor.org/info/rfc1785},
author = {G. Malkin and A. Harkin},
title = {{TFTP Option Negotiation Analysis}},
pagetotal = 2,
year = 1995,
month = mar,
} RFC text
Contents
Network Working Group G. Malkin
Request for Comments: 1785 Xylogics, Inc.
Updates: 1350 A. Harkin
Category: Informational Hewlett Packard Co.
March 1995
TFTP Option Negotiation Analysis
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
The TFTP option negotiation mechanism, proposed in [1], is a
backward-compatible extension to the TFTP protocol, defined in [2].
It allows file transfer options to be negotiated prior to the
transfer using a mechanism which is consistent with TFTP's Request
Packet format. The mechanism is kept simple by enforcing a request-
respond-acknowledge sequence, similar to the lock-step approach taken
by TFTP itself.
This document was written to allay concerns that the presence of
options in a TFTP Request packet might cause pathological behavior on
servers which do not support TFTP option negotiation.
Test Results
A TFTP client, modified to send TFTP options, was tested against five
unmodified servers:
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 each case, the servers ignored the option information in the
Request packet and the transfer proceeded as though no option
negotiation had been attempted. In addition, the standard BSD4.3
source for TFTPD, the starting point for many implementations, was
examined. The code clearly ignores any extraneous information in
Request packets.
From these results and examinations, it is clear that the TFTP option
negotiation mechanism is fully backward-compatible with unmodified
TFTP servers.
Security Considerations
Security issues are not discussed in this memo.
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
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
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
AI ELI5
On this page
§1TFTP Option Negotiation
TFTP (Trivial File Transfer Protocol) is a simple file transfer protocol defined in RFC 1350. A new extension, proposed in RFC 1782, adds option negotiation: a way to negotiate parameters like blocksize before the transfer begins.
The option mechanism is backward compatible by design. However, implementers worried that sending options to an old server—one that predates the option extension—might cause unexpected behavior. This memo documents tests to verify the concern was unfounded.
TFTP is a simple way to copy files. Engineers wanted to add a way to ask for special features, but worried old photocopiers might break if you asked for something they did not understand.
§2Testing Old Servers
A TFTP client was modified to send option negotiation in its request packets and tested against five unmodified TFTP server implementations on different systems: DEC Alpha running OSF1, SGI MIPS running IRIX, Sun SPARC running SunOS 5.1, IBM RS/6000 running AIX, and another Sun running SunOS 4.1.3.
In every case, the servers ignored the option information and processed the transfer as though no option negotiation had been attempted. The transfer succeeded.
In addition, the authors examined the BSD 4.3 TFTP source code, the foundation for many implementations. The code clearly ignores any extraneous data in request packets, confirming that the protocol design was sound.
They sent a new kind of request to five different old photocopiers. All five just ignored the new stuff and copied normally. They also looked at the original code: yep, it is set to ignore anything it does not recognize.
§3Backward Compatibility Confirmed
The test results demonstrate that the TFTP option negotiation mechanism is fully backward compatible with unmodified TFTP servers. Servers that do not understand option negotiation simply ignore the extra data and proceed with the standard transfer protocol.
This means implementers can safely deploy option negotiation extensions without breaking compatibility with existing deployed TFTP servers. The results give confidence that the design of the negotiation mechanism—to include options in the request packet without changing the basic structure—achieves its goal of graceful degradation.
It is safe to roll out the new feature. Old photocopiers will just say "I do not get it" silently and copy anyway.