Mercurial > gftp.yaz
comparison docs/rfcs/rfc2428.txt @ 497:e60a6ec4aa85
2004-7-12 Brian Masney <masneyb@gftp.org>
* docs/rfcs/* - added RFCs that are used by this program
author | masneyb |
---|---|
date | Tue, 13 Jul 2004 01:35:15 +0000 |
parents | |
children |
comparison
equal
deleted
inserted
replaced
496:937f2b75bbee | 497:e60a6ec4aa85 |
---|---|
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 |