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
  specified; however, an option may only be specified once.  The order
  of the options is not significant.

  If the server supports option negotiation, and it recognizes one or
  more of the options specified in the request packet, the server may
  respond with an Options Acknowledgment (OACK).  Each option the
  server recognizes, and accepts the value for, is included in the
  OACK.  Some options may allow alternate values to be proposed, but
  this is an option specific feature.  The server must not include in
  the OACK any option which had not been specifically requested by the
  client; that is, only the client may initiate option negotiation.
  Options which the server does not support should be omitted from the
  OACK; they must not cause an ERROR packet to be generated.  If the
  value of a supported option is invalid, the specification for that
  option will indicate whether the server should simply omit the option
  from the OACK, respond with an alternate value, or send an ERROR
  packet, with error code 8, to terminate the transfer.

  An option not acknowledged by the server must be ignored by the
  client and server as if it were never requested.  If multiple options
  were requested, the client must use those options which were
  acknowledged by the server and must not use those options which were
  not acknowledged by the server.



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


  When the client appends options to the end of a Read Request packet,
  three possible responses may be returned by the server:

     OACK  - acknowledge of Read Request and the options;

     DATA  - acknowledge of Read Request, but not the options;

     ERROR - the request has been denied.

  When the client appends options to the end of a Write Request packet,
  three possible responses may be returned by the server:

     OACK  - acknowledge of Write Request and the options;

     ACK   - acknowledge of Write Request, but not the options;

     ERROR - the request has been denied.

  If a server implementation does not support option negotiation, it
  will likely ignore any options appended to the client's request.  In
  this case, the server will return a DATA packet for a Read Request
  and an ACK packet for a Write Request establishing normal TFTP data
  transfer.  In the event that a server returns an error for a request
  which carries an option, the client may attempt to repeat the request
  without appending any options.  This implementation option would
  handle servers which consider extraneous data in the request packet
  to be erroneous.

  Depending on the original transfer request there are two ways for a
  client to confirm acceptance of a server's OACK.  If the transfer was
  initiated with a Read Request, then an ACK (with the data block
  number set to 0) is sent by the client to confirm the values in the
  server's OACK packet.  If the transfer was initiated with a Write
  Request, then the client begins the transfer with the first DATA
  packet, using the negotiated values.  If the client rejects the OACK,
  then it sends an ERROR packet, with error code 8, to the server and
  the transfer is terminated.

  Once a client acknowledges an OACK, with an appropriate non-error
  response, that client has agreed to use only the options and values
  returned by the server.  Remember that the server cannot request an
  option; it can only respond to them.  If the client receives an OACK
  containing an unrequested option, it should respond with an ERROR
  packet, with error code 8, and terminate the transfer.







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


Examples

  Read Request

     client                                           server
     -------------------------------------------------------
     |1|foofile|0|octet|0|blksize|0|1432|0|  -->               RRQ
                                   <--  |6|blksize|0|1432|0|   OACK
     |4|0|  -->                                                ACK
                            <--  |3|1| 1432 octets of data |   DATA
     |4|1|  -->                                                ACK
                            <--  |3|2| 1432 octets of data |   DATA
     |4|2|  -->                                                ACK
                            <--  |3|3|<1432 octets of data |   DATA
     |4|3|  -->                                                ACK

  Write Request

     client                                           server
     -------------------------------------------------------
     |2|barfile|0|octet|0|blksize|0|2048|0|  -->               RRQ
                                   <--  |6|blksize|0|2048|0|   OACK
     |3|1| 2048 octets of data |  -->                          DATA
                                                  <--  |4|1|   ACK
     |3|2| 2048 octets of data |  -->                          DATA
                                                  <--  |4|2|   ACK
     |3|3|<2048 octets of data |  -->                          DATA
                                                  <--  |4|3|   ACK

Security Considerations

  Security issues are not discussed in this memo.

References

  [1] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350,
      MIT, July 1992.

  [2] Malkin, G., and A. Harkin, "TFTP Blocksize Option", RFC 1783,
      Xylogics, Inc., Hewlett Packard Co., March 1995.

  [3] Malkin, G., and A. Harkin, A., "TFTP Timeout Interval and
      Transfer Size Options", RFC 1784, Xylogics, Inc., Hewlett Packard
      Co., March 1995.







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


Authors' Addresses

      Gary Scott Malkin
      Xylogics, Inc.
      53 Third Avenue
      Burlington, MA  01803

      Phone:  (617) 272-8140
      EMail:  [email protected]


      Art Harkin
      Internet Services Project
      Information Networks Division
      19420 Homestead Road MS 43LN
      Cupertino, CA  95014

      Phone: (408) 447-3755
      EMail: [email protected]
































Malkin & Harkin                                                 [Page 6]


You are viewing proxied material from gopher.fnord.one. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.