Browse Prior Art Database

TFTP Option Negotiation Analysis (RFC1785)

IP.com Disclosure Number: IPCOM000004038D
Original Publication Date: 1995-Mar-01
Included in the Prior Art Database: 2019-Feb-12
Document File: 2 page(s) / 3K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

G. Malkin: AUTHOR [+1]

Related Documents

10.17487/RFC1785: DOI

Abstract

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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 66% of the total text.

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]

RFC 1785 TFTP Option Negotiation Analysis March 1995

negotiation mechanis...

Processing...
Loading...