1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
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
|
<pre>Network Working Group G. Malkin
Request for Comments: 1782 Xylogics, Inc.
Updates: <a href="./rfc1350">1350</a> A. Harkin
Category: Standards Track Hewlett Packard Co.
March 1995
<span class="h1">TFTP Option Extension</span>
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 [<a href="#ref-1" title=""The TFTP Protocol (Revision 2)"">1</a>] 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 [<a href="#ref-2" title=""TFTP Blocksize Option"">2</a>]. Additional options are defined
in [<a href="#ref-3" title=""TFTP Timeout Interval and Transfer Size Options"">3</a>].
This document assumes reader familiarity with the TFTP specification
[<a href="#ref-1" title=""The TFTP Protocol (Revision 2)"">1</a>] 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.
<span class="grey">Malkin & Harkin [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc1782">RFC 1782</a> TFTP Option Extension March 1995</span>
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 [<a href="#ref-1" title=""The TFTP Protocol (Revision 2)"">1</a>].
filename
The name of the file to be read or written, as defined in [<a href="#ref-1" title=""The TFTP Protocol (Revision 2)"">1</a>].
This is a NULL-terminated field.
mode
The mode of the file transfer: "netascii", "octet", or "mail",
as defined in [<a href="#ref-1" title=""The TFTP Protocol (Revision 2)"">1</a>]. 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.
<span class="grey">Malkin & Harkin [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc1782">RFC 1782</a> TFTP Option Extension March 1995</span>
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.
<span class="grey">Malkin & Harkin [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc1782">RFC 1782</a> TFTP Option Extension March 1995</span>
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.
<span class="grey">Malkin & Harkin [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc1782">RFC 1782</a> TFTP Option Extension March 1995</span>
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
[<a id="ref-1">1</a>] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, <a href="./rfc1350">RFC 1350</a>,
MIT, July 1992.
[<a id="ref-2">2</a>] Malkin, G., and A. Harkin, "TFTP Blocksize Option", <a href="./rfc1783">RFC 1783</a>,
Xylogics, Inc., Hewlett Packard Co., March 1995.
[<a id="ref-3">3</a>] Malkin, G., and A. Harkin, A., "TFTP Timeout Interval and
Transfer Size Options", <a href="./rfc1784">RFC 1784</a>, Xylogics, Inc., Hewlett Packard
Co., March 1995.
<span class="grey">Malkin & Harkin [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc1782">RFC 1782</a> TFTP Option Extension March 1995</span>
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 [Page 6]
</pre>
|
