[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 01 02 RFC 1782

draft-ietf-tftpexts-option-ext-02.txt         G. Malkin / Xylogics, Inc.
TFTP Option Extension                    A. Harkin / Hewlett-Packard Co.
Updates: RFC 1350 (STD 33)                                 December 1994


                         TFTP Option Extension


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.


Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim).


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].



Malkin & Harkin             Expires: 8Jun95                     [Page 1]


Internet Draft           TFTP Option Extension             December 1994


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.

   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 |
       >-------+---+---~~---+---+

      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 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             Expires: 8Jun95                     [Page 2]


Internet Draft           TFTP Option Extension             December 1994


   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 should 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



Malkin & Harkin             Expires: 8Jun95                     [Page 3]


Internet Draft           TFTP Option Extension             December 1994


   not acknowledged by the server.

   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             Expires: 8Jun95                     [Page 4]


Internet Draft           TFTP Option Extension             December 1994


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)", Request for
        Comments 1350 (STD 33), October 1992.

   [2]  Malkin, G., Harkin, A., "TFTP Blocksize Option", Internet Draft,
        draft-ietf-tftpexts-blksize-opt-01.txt, September 1994.

   [3]  Malkin, G., Harkin, A., "TFTP Timeout Interval and Transfer Size
        Options", Internet Draft, draft-ietf-tftpexts-options-00.txt,
        December 1994.





Malkin & Harkin             Expires: 8Jun95                     [Page 5]


Internet Draft           TFTP Option Extension             December 1994


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
































Malkin & Harkin             Expires: 8Jun95                     [Page 6]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/