TFTP Options Analysis: TFTP Option Negotiation Analysis
A test of how unmodified TFTP servers handle option information.
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
ISO Plain Language
On this page
§1The Compatibility Concern
The TFTP option negotiation mechanism described in RFC 1782 is a backward-compatible extension that negotiates transfer options before file transfer. It uses a request, response, and acknowledgment sequence similar to TFTP's lock-step approach.
RFC 1785 addresses concerns that an option-bearing request might cause pathological behavior on servers that do not support option negotiation.
The option extension adds information to a TFTP request. The memo checks whether an older server can safely ignore that information.
§2Testing Unmodified Servers
A client modified to send TFTP options was tested against five unmodified servers. In each test, the server ignored the option information and the transfer proceeded as if no option negotiation had been attempted.
The authors also examined BSD 4.3 TFTPD source code, which clearly ignored extra information in request packets. Based on these tests and source examination, the memo concludes that the mechanism is backward-compatible with unmodified TFTP servers.
All five tested servers ignored the options and continued normally. The BSD server code also ignored extra request information.
§3Status of the Analysis
RFC 1785 is an Informational analysis of TFTP option negotiation. It does not specify an Internet standard.
This memo reports compatibility tests; it does not define a new TFTP standard.