home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 3 / rfc1782.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  11.2 KB  |  340 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          G. Malkin
  8. Request for Comments: 1782                                Xylogics, Inc.
  9. Updates: 1350                                                  A. Harkin
  10. Category: Standards Track                            Hewlett Packard Co.
  11.                                                               March 1995
  12.  
  13.  
  14.                          TFTP Option Extension
  15.  
  16. Status of this Memo
  17.  
  18.    This document specifies an Internet standards track protocol for the
  19.    Internet community, and requests discussion and suggestions for
  20.    improvements.  Please refer to the current edition of the "Internet
  21.    Official Protocol Standards" (STD 1) for the standardization state
  22.    and status of this protocol.  Distribution of this memo is unlimited.
  23.  
  24. Abstract
  25.  
  26.    The Trivial File Transfer Protocol [1] is a simple, lock-step, file
  27.    transfer protocol which allows a client to get or put a file onto a
  28.    remote host.  This document describes a simple extension to TFTP to
  29.    allow option negotiation prior to the file transfer.
  30.  
  31. Introduction
  32.  
  33.    The option negotiation mechanism proposed in this document is a
  34.    backward-compatible extension to the TFTP protocol.  It allows file
  35.    transfer options to be negotiated prior to the transfer using a
  36.    mechanism which is consistent with TFTPs Request Packet format.  The
  37.    mechanism is kept simple by enforcing a request-respond-acknowledge
  38.    sequence, similar to the lock-step approach taken by TFTP itself.
  39.  
  40.    While the option negotiation mechanism is general purpose, in that
  41.    many types of options may be negotiated, it was created to support
  42.    the Blocksize option defined in [2].  Additional options are defined
  43.    in [3].
  44.  
  45.    This document assumes reader familiarity with the TFTP specification
  46.    [1] and its terminology.
  47.  
  48. Packet Formats
  49.  
  50.    TFTP options are appended to the Read Request and Write Request
  51.    packets.  A new type of TFTP packet, the Option Acknowledgment
  52.    (OACK), is used to acknowledge a client's option negotiation request.
  53.    A new error code, 8, is hereby defined to indicate that a transfer
  54.    should be terminated due to option negotiation.
  55.  
  56.  
  57.  
  58. Malkin & Harkin                                                 [Page 1]
  59.  
  60. RFC 1782                 TFTP Option Extension                March 1995
  61.  
  62.  
  63.    Options are appended to a TFTP Read Request or Write Request packet
  64.    as follows:
  65.  
  66.       +-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+-->
  67.       |  opc  |filename| 0 |  mode  | 0 |  opt1  | 0 | value1 | 0 | <
  68.       +-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+-->
  69.  
  70.        >-------+---+---~~---+---+
  71.       <  optN  | 0 | valueN | 0 |
  72.        >-------+---+---~~---+---+
  73.  
  74.       The "0"s shown in these illustrations and the ones below are all
  75.       all zero octets, i.e., NULL terminators for the preceeding
  76.       fields.
  77.  
  78.       opc
  79.          The opcode field contains either a 1, for Read Requests, or 2,
  80.          for Write Requests, as defined in [1].
  81.  
  82.       filename
  83.          The name of the file to be read or written, as defined in [1].
  84.          This is a NULL-terminated field.
  85.  
  86.       mode
  87.          The mode of the file transfer: "netascii", "octet", or "mail",
  88.          as defined in [1].  This is a NULL-terminated field.
  89.  
  90.       opt1
  91.          The first option, in case-insensitive ASCII (e.g., "blksize").
  92.          This is a NULL-terminated ASCII field.
  93.  
  94.       value1
  95.          The value associated with the first option, in case-insensitive
  96.          ASCII.  This is a NULL-terminated field.
  97.  
  98.       optN, valueN
  99.          The final option/value pair.  Each NULL-terminated field is
  100.          specified in case-insensitive ASCII.
  101.  
  102.    The options and values are all NULL-terminated, in keeping with the
  103.    original request format.  If multiple options are to be negotiated,
  104.    they are appended to each other.  The order in which options are
  105.    specified is not significant.  The maximum size of a request packet
  106.    is 512 octets.
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Malkin & Harkin                                                 [Page 2]
  115.  
  116. RFC 1782                 TFTP Option Extension                March 1995
  117.  
  118.  
  119.    The OACK packet has the following format:
  120.  
  121.       +-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
  122.       |  opc  |  opt1  | 0 | value1 | 0 |  optN  | 0 | valueN | 0 |
  123.       +-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
  124.  
  125.       opc
  126.          The opcode field contains a 6, for Option Acknowledgment.
  127.  
  128.       opt1
  129.          The first option acknowledgment, copied from the original
  130.          request.
  131.  
  132.       value1
  133.          The acknowledged value associated with the first option.  If
  134.          and how this value may differ from the original request is
  135.          detailed in the specification for the option.
  136.  
  137.       optN, valueN
  138.          The final option/value acknowledgment pair.
  139.  
  140. Negotiation Protocol
  141.  
  142.    The client appends options at the end of the Read Request or Write
  143.    request packet, as shown above.  Any number of options may be
  144.    specified; however, an option may only be specified once.  The order
  145.    of the options is not significant.
  146.  
  147.    If the server supports option negotiation, and it recognizes one or
  148.    more of the options specified in the request packet, the server may
  149.    respond with an Options Acknowledgment (OACK).  Each option the
  150.    server recognizes, and accepts the value for, is included in the
  151.    OACK.  Some options may allow alternate values to be proposed, but
  152.    this is an option specific feature.  The server must not include in
  153.    the OACK any option which had not been specifically requested by the
  154.    client; that is, only the client may initiate option negotiation.
  155.    Options which the server does not support should be omitted from the
  156.    OACK; they must not cause an ERROR packet to be generated.  If the
  157.    value of a supported option is invalid, the specification for that
  158.    option will indicate whether the server should simply omit the option
  159.    from the OACK, respond with an alternate value, or send an ERROR
  160.    packet, with error code 8, to terminate the transfer.
  161.  
  162.    An option not acknowledged by the server must be ignored by the
  163.    client and server as if it were never requested.  If multiple options
  164.    were requested, the client must use those options which were
  165.    acknowledged by the server and must not use those options which were
  166.    not acknowledged by the server.
  167.  
  168.  
  169.  
  170. Malkin & Harkin                                                 [Page 3]
  171.  
  172. RFC 1782                 TFTP Option Extension                March 1995
  173.  
  174.  
  175.    When the client appends options to the end of a Read Request packet,
  176.    three possible responses may be returned by the server:
  177.  
  178.       OACK  - acknowledge of Read Request and the options;
  179.  
  180.       DATA  - acknowledge of Read Request, but not the options;
  181.  
  182.       ERROR - the request has been denied.
  183.  
  184.    When the client appends options to the end of a Write Request packet,
  185.    three possible responses may be returned by the server:
  186.  
  187.       OACK  - acknowledge of Write Request and the options;
  188.  
  189.       ACK   - acknowledge of Write Request, but not the options;
  190.  
  191.       ERROR - the request has been denied.
  192.  
  193.    If a server implementation does not support option negotiation, it
  194.    will likely ignore any options appended to the client's request.  In
  195.    this case, the server will return a DATA packet for a Read Request
  196.    and an ACK packet for a Write Request establishing normal TFTP data
  197.    transfer.  In the event that a server returns an error for a request
  198.    which carries an option, the client may attempt to repeat the request
  199.    without appending any options.  This implementation option would
  200.    handle servers which consider extraneous data in the request packet
  201.    to be erroneous.
  202.  
  203.    Depending on the original transfer request there are two ways for a
  204.    client to confirm acceptance of a server's OACK.  If the transfer was
  205.    initiated with a Read Request, then an ACK (with the data block
  206.    number set to 0) is sent by the client to confirm the values in the
  207.    server's OACK packet.  If the transfer was initiated with a Write
  208.    Request, then the client begins the transfer with the first DATA
  209.    packet, using the negotiated values.  If the client rejects the OACK,
  210.    then it sends an ERROR packet, with error code 8, to the server and
  211.    the transfer is terminated.
  212.  
  213.    Once a client acknowledges an OACK, with an appropriate non-error
  214.    response, that client has agreed to use only the options and values
  215.    returned by the server.  Remember that the server cannot request an
  216.    option; it can only respond to them.  If the client receives an OACK
  217.    containing an unrequested option, it should respond with an ERROR
  218.    packet, with error code 8, and terminate the transfer.
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Malkin & Harkin                                                 [Page 4]
  227.  
  228. RFC 1782                 TFTP Option Extension                March 1995
  229.  
  230.  
  231. Examples
  232.  
  233.    Read Request
  234.  
  235.       client                                           server
  236.       -------------------------------------------------------
  237.       |1|foofile|0|octet|0|blksize|0|1432|0|  -->               RRQ
  238.                                     <--  |6|blksize|0|1432|0|   OACK
  239.       |4|0|  -->                                                ACK
  240.                              <--  |3|1| 1432 octets of data |   DATA
  241.       |4|1|  -->                                                ACK
  242.                              <--  |3|2| 1432 octets of data |   DATA
  243.       |4|2|  -->                                                ACK
  244.                              <--  |3|3|<1432 octets of data |   DATA
  245.       |4|3|  -->                                                ACK
  246.  
  247.    Write Request
  248.  
  249.       client                                           server
  250.       -------------------------------------------------------
  251.       |2|barfile|0|octet|0|blksize|0|2048|0|  -->               RRQ
  252.                                     <--  |6|blksize|0|2048|0|   OACK
  253.       |3|1| 2048 octets of data |  -->                          DATA
  254.                                                    <--  |4|1|   ACK
  255.       |3|2| 2048 octets of data |  -->                          DATA
  256.                                                    <--  |4|2|   ACK
  257.       |3|3|<2048 octets of data |  -->                          DATA
  258.                                                    <--  |4|3|   ACK
  259.  
  260. Security Considerations
  261.  
  262.    Security issues are not discussed in this memo.
  263.  
  264. References
  265.  
  266.    [1] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350,
  267.        MIT, July 1992.
  268.  
  269.    [2] Malkin, G., and A. Harkin, "TFTP Blocksize Option", RFC 1783,
  270.        Xylogics, Inc., Hewlett Packard Co., March 1995.
  271.  
  272.    [3] Malkin, G., and A. Harkin, A., "TFTP Timeout Interval and
  273.        Transfer Size Options", RFC 1784, Xylogics, Inc., Hewlett Packard
  274.        Co., March 1995.
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Malkin & Harkin                                                 [Page 5]
  283.  
  284. RFC 1782                 TFTP Option Extension                March 1995
  285.  
  286.  
  287. Authors' Addresses
  288.  
  289.        Gary Scott Malkin
  290.        Xylogics, Inc.
  291.        53 Third Avenue
  292.        Burlington, MA  01803
  293.  
  294.        Phone:  (617) 272-8140
  295.        EMail:  gmalkin@xylogics.com
  296.  
  297.  
  298.        Art Harkin
  299.        Internet Services Project
  300.        Information Networks Division
  301.        19420 Homestead Road MS 43LN
  302.        Cupertino, CA  95014
  303.  
  304.        Phone: (408) 447-3755
  305.        EMail: ash@cup.hp.com
  306.  
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Malkin & Harkin                                                 [Page 6]
  339.  
  340.