396 lines
13 KiB
Plaintext
396 lines
13 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
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]
|
||
|