497
|
1
|
|
2
|
|
3
|
|
4
|
|
5
|
|
6
|
|
7 Network Working Group M. Allman
|
|
8 Request for Comments: 2428 NASA Lewis/Sterling Software
|
|
9 Category: Standards Track S. Ostermann
|
|
10 Ohio University
|
|
11 C. Metz
|
|
12 The Inner Net
|
|
13 September 1998
|
|
14
|
|
15
|
|
16 FTP Extensions for IPv6 and NATs
|
|
17
|
|
18 Status of this Memo
|
|
19
|
|
20 This document specifies an Internet standards track protocol for the
|
|
21 Internet community, and requests discussion and suggestions for
|
|
22 improvements. Please refer to the current edition of the "Internet
|
|
23 Official Protocol Standards" (STD 1) for the standardization state
|
|
24 and status of this protocol. Distribution of this memo is unlimited.
|
|
25
|
|
26 Copyright Notice
|
|
27
|
|
28 Copyright (C) The Internet Society (1998). All Rights Reserved.
|
|
29
|
|
30 Abstract
|
|
31
|
|
32 The specification for the File Transfer Protocol assumes that the
|
|
33 underlying network protocol uses a 32-bit network address
|
|
34 (specifically IP version 4). With the deployment of version 6 of the
|
|
35 Internet Protocol, network addresses will no longer be 32-bits. This
|
|
36 paper specifies extensions to FTP that will allow the protocol to
|
|
37 work over IPv4 and IPv6. In addition, the framework defined can
|
|
38 support additional network protocols in the future.
|
|
39
|
|
40 1. Introduction
|
|
41
|
|
42 The keywords, such as MUST and SHOULD, found in this document are
|
|
43 used as defined in RFC 2119 [Bra97].
|
|
44
|
|
45 The File Transfer Protocol [PR85] only provides the ability to
|
|
46 communicate information about IPv4 data connections. FTP assumes
|
|
47 network addresses will be 32 bits in length. However, with the
|
|
48 deployment of version 6 of the Internet Protocol [DH96] addresses
|
|
49 will no longer be 32 bits long. RFC 1639 [Pis94] specifies
|
|
50 extensions to FTP to enable its use over various network protocols.
|
|
51 Unfortunately, the mechanism can fail in a multi-protocol
|
|
52 environment. During the transition between IPv4 and IPv6, FTP needs
|
|
53 the ability to negotiate the network protocol that will be used for
|
|
54 data transfer.
|
|
55
|
|
56
|
|
57
|
|
58 Allman, et. al. Standards Track [Page 1]
|
|
59
|
|
60 RFC 2428 FTP Extensions for IPv6 and NATs September 1998
|
|
61
|
|
62
|
|
63 This document provides a specification for a way that FTP can
|
|
64 communicate data connection endpoint information for network
|
|
65 protocols other than IPv4. In this specification, the FTP commands
|
|
66 PORT and PASV are replaced with EPRT and EPSV, respectively. This
|
|
67 document is organized as follows. Section 2 outlines the EPRT
|
|
68 command and Section 3 outlines the EPSV command. Section 4 defines
|
|
69 the utilization of these two new FTP commands. Section 5 briefly
|
|
70 presents security considerations. Finally, Section 6 provides
|
|
71 conclusions.
|
|
72
|
|
73 2. The EPRT Command
|
|
74
|
|
75 The EPRT command allows for the specification of an extended address
|
|
76 for the data connection. The extended address MUST consist of the
|
|
77 network protocol as well as the network and transport addresses. The
|
|
78 format of EPRT is:
|
|
79
|
|
80 EPRT<space><d><net-prt><d><net-addr><d><tcp-port><d>
|
|
81
|
|
82 The EPRT command keyword MUST be followed by a single space (ASCII
|
|
83 32). Following the space, a delimiter character (<d>) MUST be
|
|
84 specified. The delimiter character MUST be one of the ASCII
|
|
85 characters in range 33-126 inclusive. The character "|" (ASCII 124)
|
|
86 is recommended unless it coincides with a character needed to encode
|
|
87 the network address.
|
|
88
|
|
89 The <net-prt> argument MUST be an address family number defined by
|
|
90 IANA in the latest Assigned Numbers RFC (RFC 1700 [RP94] as of the
|
|
91 writing of this document). This number indicates the protocol to be
|
|
92 used (and, implicitly, the address length). This document will use
|
|
93 two of address family numbers from [RP94] as examples, according to
|
|
94 the following table:
|
|
95
|
|
96 AF Number Protocol
|
|
97 --------- --------
|
|
98 1 Internet Protocol, Version 4 [Pos81a]
|
|
99 2 Internet Protocol, Version 6 [DH96]
|
|
100
|
|
101 The <net-addr> is a protocol specific string representation of the
|
|
102 network address. For the two address families specified above (AF
|
|
103 Number 1 and 2), addresses MUST be in the following format:
|
|
104
|
|
105 AF Number Address Format Example
|
|
106 --------- -------------- -------
|
|
107 1 dotted decimal 132.235.1.2
|
|
108 2 IPv6 string 1080::8:800:200C:417A
|
|
109 representations
|
|
110 defined in [HD96]
|
|
111
|
|
112
|
|
113
|
|
114 Allman, et. al. Standards Track [Page 2]
|
|
115
|
|
116 RFC 2428 FTP Extensions for IPv6 and NATs September 1998
|
|
117
|
|
118
|
|
119 The <tcp-port> argument must be the string representation of the
|
|
120 number of the TCP port on which the host is listening for the data
|
|
121 connection.
|
|
122
|
|
123 The following are sample EPRT commands:
|
|
124
|
|
125 EPRT |1|132.235.1.2|6275|
|
|
126
|
|
127 EPRT |2|1080::8:800:200C:417A|5282|
|
|
128
|
|
129 The first command specifies that the server should use IPv4 to open a
|
|
130 data connection to the host "132.235.1.2" on TCP port 6275. The
|
|
131 second command specifies that the server should use the IPv6 network
|
|
132 protocol and the network address "1080::8:800:200C:417A" to open a
|
|
133 TCP data connection on port 5282.
|
|
134
|
|
135 Upon receipt of a valid EPRT command, the server MUST return a code
|
|
136 of 200 (Command OK). The standard negative error code 500 and 501
|
|
137 [PR85] are sufficient to handle most errors (e.g., syntax errors)
|
|
138 involving the EPRT command. However, an additional error code is
|
|
139 needed. The response code 522 indicates that the server does not
|
|
140 support the requested network protocol. The interpretation of this
|
|
141 new error code is:
|
|
142
|
|
143 5yz Negative Completion
|
|
144 x2z Connections
|
|
145 xy2 Extended Port Failure - unknown network protocol
|
|
146
|
|
147 The text portion of the response MUST indicate which network
|
|
148 protocols the server does support. If the network protocol is
|
|
149 unsupported, the format of the response string MUST be:
|
|
150
|
|
151 <text stating that the network protocol is unsupported> \
|
|
152 (prot1,prot2,...,protn)
|
|
153
|
|
154 Both the numeric code specified above and the protocol information
|
|
155 between the characters '(' and ')' are intended for the software
|
|
156 automata receiving the response; the textual message between the
|
|
157 numeric code and the '(' is intended for the human user and can be
|
|
158 any arbitrary text, but MUST NOT include the characters '(' and ')'.
|
|
159 In the above case, the text SHOULD indicate that the network protocol
|
|
160 in the EPRT command is not supported by the server. The list of
|
|
161 protocols inside the parenthesis MUST be a comma separated list of
|
|
162 address family numbers. Two example response strings follow:
|
|
163
|
|
164 Network protocol not supported, use (1)
|
|
165
|
|
166 Network protocol not supported, use (1,2)
|
|
167
|
|
168
|
|
169
|
|
170 Allman, et. al. Standards Track [Page 3]
|
|
171
|
|
172 RFC 2428 FTP Extensions for IPv6 and NATs September 1998
|
|
173
|
|
174
|
|
175 3. The EPSV Command
|
|
176
|
|
177 The EPSV command requests that a server listen on a data port and
|
|
178 wait for a connection. The EPSV command takes an optional argument.
|
|
179 The response to this command includes only the TCP port number of the
|
|
180 listening connection. The format of the response, however, is
|
|
181 similar to the argument of the EPRT command. This allows the same
|
|
182 parsing routines to be used for both commands. In addition, the
|
|
183 format leaves a place holder for the network protocol and/or network
|
|
184 address, which may be needed in the EPSV response in the future. The
|
|
185 response code for entering passive mode using an extended address
|
|
186 MUST be 229. The interpretation of this code, according to [PR85]
|
|
187 is:
|
|
188
|
|
189 2yz Positive Completion
|
|
190 x2z Connections
|
|
191 xy9 Extended Passive Mode Entered
|
|
192
|
|
193 The text returned in response to the EPSV command MUST be:
|
|
194
|
|
195 <text indicating server is entering extended passive mode> \
|
|
196 (<d><d><d><tcp-port><d>)
|
|
197
|
|
198 The portion of the string enclosed in parentheses MUST be the exact
|
|
199 string needed by the EPRT command to open the data connection, as
|
|
200 specified above.
|
|
201
|
|
202 The first two fields contained in the parenthesis MUST be blank. The
|
|
203 third field MUST be the string representation of the TCP port number
|
|
204 on which the server is listening for a data connection. The network
|
|
205 protocol used by the data connection will be the same network
|
|
206 protocol used by the control connection. In addition, the network
|
|
207 address used to establish the data connection will be the same
|
|
208 network address used for the control connection. An example response
|
|
209 string follows:
|
|
210
|
|
211 Entering Extended Passive Mode (|||6446|)
|
|
212
|
|
213 The standard negative error codes 500 and 501 are sufficient to
|
|
214 handle all errors involving the EPSV command (e.g., syntax errors).
|
|
215
|
|
216 When the EPSV command is issued with no argument, the server will
|
|
217 choose the network protocol for the data connection based on the
|
|
218 protocol used for the control connection. However, in the case of
|
|
219 proxy FTP, this protocol might not be appropriate for communication
|
|
220 between the two servers. Therefore, the client needs to be able to
|
|
221 request a specific protocol. If the server returns a protocol that
|
|
222 is not supported by the host that will be connecting to the port, the
|
|
223
|
|
224
|
|
225
|
|
226 Allman, et. al. Standards Track [Page 4]
|
|
227
|
|
228 RFC 2428 FTP Extensions for IPv6 and NATs September 1998
|
|
229
|
|
230
|
|
231 client MUST issue an ABOR (abort) command to allow the server to
|
|
232 close down the listening connection. The client can then send an
|
|
233 EPSV command requesting the use of a specific network protocol, as
|
|
234 follows:
|
|
235
|
|
236 EPSV<space><net-prt>
|
|
237
|
|
238 If the requested protocol is supported by the server, it SHOULD use
|
|
239 the protocol. If not, the server MUST return the 522 error messages
|
|
240 as outlined in section 2.
|
|
241
|
|
242 Finally, the EPSV command can be used with the argument "ALL" to
|
|
243 inform Network Address Translators that the EPRT command (as well as
|
|
244 other data commands) will no longer be used. An example of this
|
|
245 command follows:
|
|
246
|
|
247 EPSV<space>ALL
|
|
248
|
|
249 Upon receipt of an EPSV ALL command, the server MUST reject all data
|
|
250 connection setup commands other than EPSV (i.e., EPRT, PORT, PASV, et
|
|
251 al.). This use of the EPSV command is further explained in section
|
|
252 4.
|
|
253
|
|
254 4. Command Usage
|
|
255
|
|
256 For all FTP transfers where the control and data connection(s) are
|
|
257 being established between the same two machines, the EPSV command
|
|
258 MUST be used. Using the EPSV command benefits performance of
|
|
259 transfers that traverse firewalls or Network Address Translators
|
|
260 (NATs). RFC 1579 [Bel94] recommends using the passive command when
|
|
261 behind firewalls since firewalls do not generally allow incoming
|
|
262 connections (which are required when using the PORT (EPRT) command).
|
|
263 In addition, using EPSV as defined in this document does not require
|
|
264 NATs to change the network address in the traffic as it is forwarded.
|
|
265 The NAT would have to change the address if the EPRT command was
|
|
266 used. Finally, if the client issues an "EPSV ALL" command, NATs may
|
|
267 be able to put the connection on a "fast path" through the
|
|
268 translator, as the EPRT command will never be used and therefore,
|
|
269 translation of the data portion of the segments will never be needed.
|
|
270 When a client only expects to do two-way FTP transfers, it SHOULD
|
|
271 issue this command as soon as possible. If a client later finds that
|
|
272 it must do a three-way FTP transfer after issuing an EPSV ALL
|
|
273 command, a new FTP session MUST be started.
|
|
274
|
|
275
|
|
276
|
|
277
|
|
278
|
|
279
|
|
280
|
|
281
|
|
282 Allman, et. al. Standards Track [Page 5]
|
|
283
|
|
284 RFC 2428 FTP Extensions for IPv6 and NATs September 1998
|
|
285
|
|
286
|
|
287 5. Security Issues
|
|
288
|
|
289 The authors do not believe that these changes to FTP introduce new
|
|
290 security problems. A companion Work in Progress [AO98] is a more
|
|
291 general discussion of FTP security issues and techniques to reduce
|
|
292 these security problems.
|
|
293
|
|
294 6. Conclusions
|
|
295
|
|
296 The extensions specified in this paper will enable FTP to operate
|
|
297 over a variety of network protocols.
|
|
298
|
|
299 References
|
|
300
|
|
301 [AO98] Allman, M., and S. Ostermann, "FTP Security
|
|
302 Considerations", Work in Progress.
|
|
303
|
|
304 [Bel94] Bellovin, S., "Firewall-Friendly FTP", RFC 1579, February
|
|
305 1994.
|
|
306
|
|
307 [Bra97] Bradner, S., "Key words for use in RFCs to Indicate
|
|
308 Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|
309
|
|
310 [DH96] Deering, S., and R. Hinden, "Internet Protocol, Version 6
|
|
311 (IPv6) Specification", RFC 1883, December 1995.
|
|
312
|
|
313 [HD96] Hinden, R., and S. Deering, "IP Version 6 Addressing
|
|
314 Architecture", RFC 2373, July 1998.
|
|
315
|
|
316 [Pis94] Piscitello, D., "FTP Operation Over Big Address Records
|
|
317 (FOOBAR)", RFC 1639, June 1994.
|
|
318
|
|
319 [Pos81a] Postel, J., "Internet Protocol", STD 5, RFC 791, September
|
|
320 1981.
|
|
321
|
|
322 [Pos81b] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
|
|
323 September 1981.
|
|
324
|
|
325 [PR85] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)",
|
|
326 STD 9, RFC 959, October 1985.
|
|
327
|
|
328 [RP94] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
|
|
329 1700, October 1994. See also:
|
|
330 http://www.iana.org/numbers.html
|
|
331
|
|
332
|
|
333
|
|
334
|
|
335
|
|
336
|
|
337
|
|
338 Allman, et. al. Standards Track [Page 6]
|
|
339
|
|
340 RFC 2428 FTP Extensions for IPv6 and NATs September 1998
|
|
341
|
|
342
|
|
343 Authors' Addresses
|
|
344
|
|
345 Mark Allman
|
|
346 NASA Lewis Research Center/Sterling Software
|
|
347 21000 Brookpark Rd. MS 54-2
|
|
348 Cleveland, OH 44135
|
|
349
|
|
350 Phone: (216) 433-6586
|
|
351 EMail: mallman@lerc.nasa.gov
|
|
352 http://gigahertz.lerc.nasa.gov/~mallman/
|
|
353
|
|
354
|
|
355 Shawn Ostermann
|
|
356 School of Electrical Engineering and Computer Science
|
|
357 Ohio University
|
|
358 416 Morton Hall
|
|
359 Athens, OH 45701
|
|
360
|
|
361 Phone: (740) 593-1234
|
|
362 EMail: ostermann@cs.ohiou.edu
|
|
363
|
|
364
|
|
365 Craig Metz
|
|
366 The Inner Net
|
|
367 Box 10314-1954
|
|
368 Blacksburg, VA 24062-0314
|
|
369
|
|
370 Phone: (DSN) 754-8590
|
|
371 EMail: cmetz@inner.net
|
|
372
|
|
373
|
|
374
|
|
375
|
|
376
|
|
377
|
|
378
|
|
379
|
|
380
|
|
381
|
|
382
|
|
383
|
|
384
|
|
385
|
|
386
|
|
387
|
|
388
|
|
389
|
|
390
|
|
391
|
|
392
|
|
393
|
|
394 Allman, et. al. Standards Track [Page 7]
|
|
395
|
|
396 RFC 2428 FTP Extensions for IPv6 and NATs September 1998
|
|
397
|
|
398
|
|
399 Full Copyright Statement
|
|
400
|
|
401 Copyright (C) The Internet Society (1998). All Rights Reserved.
|
|
402
|
|
403 This document and translations of it may be copied and furnished to
|
|
404 others, and derivative works that comment on or otherwise explain it
|
|
405 or assist in its implementation may be prepared, copied, published
|
|
406 and distributed, in whole or in part, without restriction of any
|
|
407 kind, provided that the above copyright notice and this paragraph are
|
|
408 included on all such copies and derivative works. However, this
|
|
409 document itself may not be modified in any way, such as by removing
|
|
410 the copyright notice or references to the Internet Society or other
|
|
411 Internet organizations, except as needed for the purpose of
|
|
412 developing Internet standards in which case the procedures for
|
|
413 copyrights defined in the Internet Standards process must be
|
|
414 followed, or as required to translate it into languages other than
|
|
415 English.
|
|
416
|
|
417 The limited permissions granted above are perpetual and will not be
|
|
418 revoked by the Internet Society or its successors or assigns.
|
|
419
|
|
420 This document and the information contained herein is provided on an
|
|
421 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
|
422 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
|
423 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
|
424 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
|
425 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|
426
|
|
427
|
|
428
|
|
429
|
|
430
|
|
431
|
|
432
|
|
433
|
|
434
|
|
435
|
|
436
|
|
437
|
|
438
|
|
439
|
|
440
|
|
441
|
|
442
|
|
443
|
|
444
|
|
445
|
|
446
|
|
447
|
|
448
|
|
449
|
|
450 Allman, et. al. Standards Track [Page 8]
|
|
451
|