TFTP Option Extension
RFC 1782

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 02

Network Working Group                                          G. Malkin
Request for Comments: 1782                                Xylogics, Inc.
Updates: 1350                                                  A. Harkin
Category: Standards Track                            Hewlett Packard Co.
                                                              March 1995

                         TFTP Option Extension

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   The Trivial File Transfer Protocol [1] is a simple, lock-step, file
   transfer protocol which allows a client to get or put a file onto a
   remote host.  This document describes a simple extension to TFTP to
   allow option negotiation prior to the file transfer.

Introduction

   The option negotiation mechanism proposed in this document is a
   backward-compatible extension to the TFTP protocol.  It allows file
   transfer options to be negotiated prior to the transfer using a
   mechanism which is consistent with TFTPs 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.

   While the option negotiation mechanism is general purpose, in that
   many types of options may be negotiated, it was created to support
   the Blocksize option defined in [2].  Additional options are defined
   in [3].

   This document assumes reader familiarity with the TFTP specification
   [1] and its terminology.

Packet Formats

   TFTP options are appended to the Read Request and Write Request
   packets.  A new type of TFTP packet, the Option Acknowledgment
   (OACK), is used to acknowledge a client's option negotiation request.
   A new error code, 8, is hereby defined to indicate that a transfer
   should be terminated due to option negotiation.

Malkin & Harkin                                                 [Page 1]
RFC 1782                 TFTP Option Extension                March 1995

   Options are appended to a TFTP Read Request or Write Request packet
   as follows:

      +-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+-->
      |  opc  |filename| 0 |  mode  | 0 |  opt1  | 0 | value1 | 0 | <
      +-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+-->

       >-------+---+---~~---+---+
      <  optN  | 0 | valueN | 0 |
       >-------+---+---~~---+---+

      The "0"s shown in these illustrations and the ones below are all
      all zero octets, i.e., NULL terminators for the preceeding
      fields.

      opc
         The opcode field contains either a 1, for Read Requests, or 2,
         for Write Requests, as defined in [1].

      filename
         The name of the file to be read or written, as defined in [1].
         This is a NULL-terminated field.

      mode
         The mode of the file transfer: "netascii", "octet", or "mail",
         as defined in [1].  This is a NULL-terminated field.

      opt1
         The first option, in case-insensitive ASCII (e.g., "blksize").
         This is a NULL-terminated ASCII field.

      value1
         The value associated with the first option, in case-insensitive
         ASCII.  This is a NULL-terminated field.

      optN, valueN
         The final option/value pair.  Each NULL-terminated field is
         specified in case-insensitive ASCII.

   The options and values are all NULL-terminated, in keeping with the
   original request format.  If multiple options are to be negotiated,
   they are appended to each other.  The order in which options are
   specified is not significant.  The maximum size of a request packet
   is 512 octets.

Malkin & Harkin                                                 [Page 2]
RFC 1782                 TFTP Option Extension                March 1995

   The OACK packet has the following format:

      +-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
      |  opc  |  opt1  | 0 | value1 | 0 |  optN  | 0 | valueN | 0 |
      +-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+

      opc
         The opcode field contains a 6, for Option Acknowledgment.

      opt1
         The first option acknowledgment, copied from the original
         request.

      value1
         The acknowledged value associated with the first option.  If
         and how this value may differ from the original request is
         detailed in the specification for the option.

      optN, valueN
         The final option/value acknowledgment pair.

Negotiation Protocol

   The client appends options at the end of the Read Request or Write
   request packet, as shown above.  Any number of options may be