summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2347.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2347.txt')
-rw-r--r--doc/rfc/rfc2347.txt395
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc2347.txt b/doc/rfc/rfc2347.txt
new file mode 100644
index 0000000..dbc0f8c
--- /dev/null
+++ b/doc/rfc/rfc2347.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group G. Malkin
+Request for Commments: 2347 Bay Networks
+Updates: 1350 A. Harkin
+Obsoletes: 1782 Hewlett Packard Co.
+Category: Standards Track May 1998
+
+
+ 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.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+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 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.
+
+ 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].
+
+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
+
+
+
+Malkin & Harkin Standards Track [Page 1]
+
+RFC 2347 TFTP Option Extension May 1998
+
+
+ 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.
+
+ The OACK packet has the following format:
+
+
+
+
+
+
+
+Malkin & Harkin Standards Track [Page 2]
+
+RFC 2347 TFTP Option Extension May 1998
+
+
+ +-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
+ | 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
+ not acknowledged by the server.
+
+
+
+
+
+Malkin & Harkin Standards Track [Page 3]
+
+RFC 2347 TFTP Option Extension May 1998
+
+
+ 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 Standards Track [Page 4]
+
+RFC 2347 TFTP Option Extension May 1998
+
+
+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
+
+ The basic TFTP protocol has no security mechanism. This is why it
+ has no rename, delete, or file overwrite capabilities. This document
+ does not add any security to TFTP; however, the specified extensions
+ do not add any additional security risks.
+
+References
+
+ [1] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350,
+ October 1992.
+
+ [2] Malkin, G., and A. Harkin, "TFTP Blocksize Option", RFC 2348,
+ May 1998.
+
+ [3] Malkin, G., and A. Harkin, "TFTP Timeout Interval and Transfer
+ Size Options", RFC 2349, May 1998.
+
+
+
+
+
+Malkin & Harkin Standards Track [Page 5]
+
+RFC 2347 TFTP Option Extension May 1998
+
+
+Authors' Addresses
+
+ Gary Scott Malkin
+ Bay Networks
+ 8 Federal Street
+ Billerica, MA 01821
+
+ Phone: (978) 916-4237
+ EMail: gmalkin@baynetworks.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 Standards Track [Page 6]
+
+RFC 2347 TFTP Option Extension May 1998
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Malkin & Harkin Standards Track [Page 7]
+