|
RFC Home |
Full RFC Index |
Recent RFCs |
RFC Standards |
Best Current Practice |
RFC Errata |
1 April RFC |
|
||||||
|
IETF RFC 1785
TFTP Option Negotiation Analysis Last modified on Monday, March 20th, 1995 Permanent link to RFC 1785 Search GitHub Wiki for RFC 1785 Show other RFCs mentioning RFC 1785 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 Malkin & Harkin PAGE 1 |