7 Network Working Group M. Allman
8 Request for Comments: 2428 NASA Lewis/Sterling Software
9 Category: Standards Track S. Ostermann
16 FTP Extensions for IPv6 and NATs
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.
28 Copyright (C) The Internet Society (1998). All Rights Reserved.
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.
42 The keywords, such as MUST and SHOULD, found in this document are
43 used as defined in RFC 2119 [Bra97].
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
58 Allman, et. al. Standards Track [Page 1]
60 RFC 2428 FTP Extensions for IPv6 and NATs September 1998
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
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
80 EPRT<space><d><net-prt><d><net-addr><d><tcp-port><d>
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
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
98 1 Internet Protocol, Version 4 [Pos81a]
99 2 Internet Protocol, Version 6 [DH96]
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:
105 AF Number Address Format Example
106 --------- -------------- -------
107 1 dotted decimal 132.235.1.2
108 2 IPv6 string 1080::8:800:200C:417A
114 Allman, et. al. Standards Track [Page 2]
116 RFC 2428 FTP Extensions for IPv6 and NATs September 1998
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
123 The following are sample EPRT commands:
125 EPRT |1|132.235.1.2|6275|
127 EPRT |2|1080::8:800:200C:417A|5282|
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.
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
143 5yz Negative Completion
145 xy2 Extended Port Failure - unknown network protocol
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:
151 <text stating that the network protocol is unsupported> \
152 (prot1,prot2,...,protn)
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:
164 Network protocol not supported, use (1)
166 Network protocol not supported, use (1,2)
170 Allman, et. al. Standards Track [Page 3]
172 RFC 2428 FTP Extensions for IPv6 and NATs September 1998
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]
189 2yz Positive Completion
191 xy9 Extended Passive Mode Entered
193 The text returned in response to the EPSV command MUST be:
195 <text indicating server is entering extended passive mode> \
196 (<d><d><d><tcp-port><d>)
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
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
211 Entering Extended Passive Mode (|||6446|)
213 The standard negative error codes 500 and 501 are sufficient to
214 handle all errors involving the EPSV command (e.g., syntax errors).
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
226 Allman, et. al. Standards Track [Page 4]
228 RFC 2428 FTP Extensions for IPv6 and NATs September 1998
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
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.
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
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
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.
282 Allman, et. al. Standards Track [Page 5]
284 RFC 2428 FTP Extensions for IPv6 and NATs September 1998
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.
296 The extensions specified in this paper will enable FTP to operate
297 over a variety of network protocols.
301 [AO98] Allman, M., and S. Ostermann, "FTP Security
302 Considerations", Work in Progress.
304 [Bel94] Bellovin, S., "Firewall-Friendly FTP", RFC 1579, February
307 [Bra97] Bradner, S., "Key words for use in RFCs to Indicate
308 Requirement Levels", BCP 14, RFC 2119, March 1997.
310 [DH96] Deering, S., and R. Hinden, "Internet Protocol, Version 6
311 (IPv6) Specification", RFC 1883, December 1995.
313 [HD96] Hinden, R., and S. Deering, "IP Version 6 Addressing
314 Architecture", RFC 2373, July 1998.
316 [Pis94] Piscitello, D., "FTP Operation Over Big Address Records
317 (FOOBAR)", RFC 1639, June 1994.
319 [Pos81a] Postel, J., "Internet Protocol", STD 5, RFC 791, September
322 [Pos81b] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
325 [PR85] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)",
326 STD 9, RFC 959, October 1985.
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
338 Allman, et. al. Standards Track [Page 6]
340 RFC 2428 FTP Extensions for IPv6 and NATs September 1998
346 NASA Lewis Research Center/Sterling Software
347 21000 Brookpark Rd. MS 54-2
350 Phone: (216) 433-6586
351 EMail: mallman@lerc.nasa.gov
352 http://gigahertz.lerc.nasa.gov/~mallman/
356 School of Electrical Engineering and Computer Science
361 Phone: (740) 593-1234
362 EMail: ostermann@cs.ohiou.edu
368 Blacksburg, VA 24062-0314
370 Phone: (DSN) 754-8590
371 EMail: cmetz@inner.net
394 Allman, et. al. Standards Track [Page 7]
396 RFC 2428 FTP Extensions for IPv6 and NATs September 1998
399 Full Copyright Statement
401 Copyright (C) The Internet Society (1998). All Rights Reserved.
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
417 The limited permissions granted above are perpetual and will not be
418 revoked by the Internet Society or its successors or assigns.
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.
450 Allman, et. al. Standards Track [Page 8]