Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 1785

TFTP Option Negotiation Analysis

Pages: 2
Informational
Updates:  1350

ToP   noToC   RFC1785 - Page 1
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
ToP   noToC   RFC1785 - Page 2
   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