idnits 2.17.1 draft-ietf-ftpext-ftp-over-ipv6-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 24 instances of lines with control characters in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 1, 1998) is 9491 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'Pos81b' is defined on line 285, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-ietf-ftpext-sec-consider-01 ** Downref: Normative reference to an Informational draft: draft-ietf-ftpext-sec-consider (ref. 'AO98') ** Downref: Normative reference to an Informational RFC: RFC 1579 (ref. 'Bel94') ** Obsolete normative reference: RFC 1883 (ref. 'DH96') (Obsoleted by RFC 2460) ** Obsolete normative reference: RFC 1884 (ref. 'HD96') (Obsoleted by RFC 2373) ** Downref: Normative reference to an Experimental RFC: RFC 1639 (ref. 'Pis94') ** Obsolete normative reference: RFC 793 (ref. 'Pos81b') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1700 (ref. 'RP94') (Obsoleted by RFC 3232) Summary: 17 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 FTPEXT Working Group Mark Allman 2 Internet Draft NASA Lewis/Sterling Software 3 Expires: November 1, 1998 Shawn Ostermann 4 Ohio University 5 Craig Metz 6 The Inner Net 7 May 1, 1998 9 FTP Extensions for IPv6 10 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as ``work in 23 progress.'' 25 To view the entire list of current Internet-Drafts, please check the 26 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 28 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 29 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 31 Distribution of this document is unlimited. Please send comments 32 to the FTP Extension working group (FTPEXT-WG) of the Internet 33 Engineering Task Force (IETF) at . 34 Subscription address is . 35 Discussions of the group are archived at 36 . 38 Abstract 40 The specification for the File Transfer Protocol assumes that the 41 underlying network protocol uses a 32-bit network address 42 (specifically IP version 4). With the deployment of version 6 of 43 the Internet Protocol, network addresses will no longer be 32-bits. 44 This paper specifies extensions to FTP that will allow the protocol 45 to work over IPv4 and IPv6. In addition, the framework defined can 46 support additional network protocols in the future. 48 1. Introduction 50 The keywords, such as MUST and SHOULD, found in this document are 51 used as defined in RFC 2119 [Bra97]. 53 The File Transfer Protocol [PR85] only provides the ability to 54 communicate information about IPv4 data connections. FTP assumes 55 network addresses will be 32 bits in length. However, with the 56 deployment of version 6 of the Internet Protocol [DH96] addresses 57 will no longer be 32 bits long. RFC 1639 [Pis94] specifies 58 extensions to FTP to enable its use over various network protocols. 59 Unfortunately, the mechanism can fail in a multi-protocol 60 environment. During the transition between IPv4 and IPv6, FTP needs 61 the ability to negotiate the network protocol that will be used for 62 data transfer. 64 This document provides a specification for a way that FTP can 65 communicate data connection endpoint information for network 66 protocols other than IPv4. In this specification, the FTP commands 67 PORT and PASV are replaced with EPRT and EPSV, respectively. This 68 document is organized as follows. Section 2 outlines the EPRT 69 command and Section 3 outlines the EPSV command. Section 4 defines 70 the utilization of these two new FTP commands. Section 5 briefly 71 presents security considerations. Finally, Section 6 provides 72 conclusions. 74 2. The EPRT Command 76 The EPRT command allows for the specification of an extended address 77 for the data connection. The extended address MUST consist of the 78 network protocol as well as the network and transport addresses. 79 The format of EPRT is: 81 EPRT 83 The EPRT command keyword MUST be followed by a single space (ASCII 84 32). Following the space, a delimiter character () MUST be 85 specified. The delimiter character MUST be one of the ASCII 86 characters in range 33-126 inclusive. The character "|" (ASCII 124) 87 is recommended unless it coincides with a character needed to encode 88 the network address. 90 The argument MUST be an address family number defined by 91 IANA in the latest Assigned Numbers RFC (RFC 1700 [RP94] as of the 92 writing of this document). This number indicates the protocol to be 93 used (and, implicitly, the address length). This document will use 94 two of address family numbers from [RP94] as examples, according to 95 the following table: 97 AF Number Protocol 98 --------- -------- 99 1 Internet Protocol, Version 4 [Pos81a] 100 2 Internet Protocol, Version 6 [DH96] 102 The is a protocol specific string representation of the 103 network address. For the two address families specified above (AF 104 Number 1 and 2), addresses MUST be in the following format: 106 AF Number Address Format Example 107 --------- -------------- ------- 108 1 dotted decimal 132.235.1.2 109 2 IPv6 string 1080::8:800:200C:417A 110 representations 111 defined in [HD96] 113 The argument must be the string representation of the 114 number of the TCP port on which the host is listening for the data 115 connection. 117 The following are sample EPRT commands: 119 EPRT |1|132.235.1.2|6275| 121 EPRT |2|1080::8:800:200C:417A|5282| 123 The first command specifies that the server should use IPv4 to open 124 a data connection to the host "132.235.1.2" on TCP port 6275. The 125 second command specifies that the server should use the IPv6 network 126 protocol and the network address "1080::8:800:200C:417A" to open a 127 TCP data connection on port 5282. 129 Upon receipt of a valid EPRT command, the server MUST return a code 130 of 200 (Command OK). The standard negative error code 500 and 501 131 [PR85] are sufficient to handle most errors (e.g., syntax errors) 132 involving the EPRT command. However, an additional error code is 133 needed. The response code 522 indicates that the server does not 134 support the requested network protocol. The interpretation of this 135 new error code is: 137 5yz Negative Completion 138 x2z Connections 139 xy2 Extended Port Failure - unknown network protocol 141 The text portion of the response MUST indicate which network 142 protocols the server does support. If the network protocol is 143 unsupported, the format of the response string MUST be: 145 \ 146 (prot1,prot2,...,protn) 148 In this document, any text enclosed within "<>" is informational 149 text that can be written in any language but MUST NOT include 150 parentheses. In the above case, the text SHOULD indicate that the 151 network protocol in the EPRT command is not supported by the server. 152 The list of protocols inside the parenthesis MUST be a comma 153 separated list of address family numbers. Two example response 154 strings follow: 156 Network protocol not supported, use (1) 158 Network protocol not supported, use (1,2) 159 3. The EPSV Command 161 The EPSV command requests that a server listen on a data port and 162 wait for a connection. The EPSV command takes an optional argument. 163 The response to this command includes only the TCP port number of 164 the listening connection. The format of the response, however, is 165 similar to the argument of the EPRT command. This allows the same 166 parsing routines to be used for both commands. In addition, the 167 format leaves a place holder for the network protocol and/or network 168 address, which may be needed in the EPSV response in the future. 169 The response code for entering passive mode using an extended 170 address MUST be 229. The interpretation of this code, according to 171 [PR85] is: 173 2yz Positive Completion 174 x2z Connections 175 xy9 Extended Passive Mode Entered 177 The text returned in response to the EPSV command MUST be: 179 \ 180 () 182 The portion of the string enclosed in parentheses MUST be the exact 183 string needed by the EPRT command to open the data connection, as 184 specified above. 186 The first two fields contained in the parenthesis MUST be blank. 187 The third field MUST be the string representation of the TCP port 188 number on which the server is listening for a data connection. The 189 network protocol used by the data connection will be the same 190 network protocol used by the control connection. In addition, the 191 network address used to establish the data connection will be the 192 same network address used for the control connection. An example 193 response string follows: 195 Entering Extended Passive Mode (|||6446|) 197 The standard negative error codes 500 and 501 are sufficient to 198 handle all errors involving the EPSV command (e.g., syntax errors). 200 When the EPSV command is issued with no argument, the server will 201 choose the network protocol for the data connection based on the 202 protocol used for the control connection. However, in the case of 203 proxy FTP, this protocol might not be appropriate for communication 204 between the two servers. Therefore, the client needs to be able to 205 request a specific protocol. If the server returns a protocol that 206 is not supported by the host that will be connecting to the port, 207 the client MUST issue an ABOR (abort) command to allow the server to 208 close down the listening connection. The client can then send an 209 EPSV command requesting the use of a specific network protocol, as 210 follows: 212 EPSV 213 If the requested protocol is supported by the server, it SHOULD use 214 the protocol. If not, the server MUST return the 522 error messages 215 as outlined in section 2. 217 Finally, the EPSV command can be used with the argument ``ALL'' to 218 inform Network Address Translators that the EPRT command (as well as 219 other data commands) will no longer be used. An example of this 220 command follows: 222 EPSVALL 224 Upon receipt of an EPSV ALL command, the server MUST reject all data 225 connection setup commands other than EPSV (i.e., EPRT, PORT, PASV, 226 et al.). This use of the EPSV command is further explained in 227 section 4. 229 4. Command Usage 231 For all FTP transfers where the control and data connection(s) are 232 being established between the same two machines, the EPSV command 233 MUST be used. Using the EPSV command benefits performance of 234 transfers that traverse firewalls or Network Address Translators 235 (NATs). RFC 1579 [Bel94] recommends using the passive command when 236 behind firewalls since firewalls do not generally allow incoming 237 connections (which are required when using the PORT (EPRT) command). 238 In addition, using EPSV as defined in this document does not require 239 NATs to change the network address in the traffic as it is 240 forwarded. The NAT would have to change the address if the EPRT 241 command was used. Finally, if the client issues an ``EPSV ALL'' 242 command, NATs may be able to put the connection on a ``fast path'' 243 through the translator, as the EPRT command will never be used and 244 therefore, translation of the data portion of the segments will 245 never be needed. When a client only expects to do two-way FTP 246 transfers, it SHOULD issue this command as soon as possible. If a 247 client later finds that it must do a three-way FTP transfer after 248 issuing an EPSV ALL command, a new FTP session MUST be started. 250 5. Security Issues 252 The authors do not believe that these changes to FTP introduce new 253 security problems. A companion Internet Draft [AO98] is a more 254 general discussion of FTP security issues and techniques to reduce 255 these security problems. 257 6. Conclusions 259 The extensions specified in this paper will enable FTP to operate 260 over a variety of network protocols. 262 References 264 [AO98] Mark Allman and Shawn Ostermann. FTP Security 265 Considerations, March 1998. I-D 266 draft-ietf-ftpext-sec-consider-01.txt (work in progress). 268 [Bel94] S. Bellovin. Firewall-Friendly FTP, February 1994. RFC 269 1579. 271 [Bra97] Scott Bradner. Key words for use in RFCs to Indicate 272 Requirement Levels, March 1997. RFC 2119. 274 [DH96] S. Deering and R. Hinden. Internet Protocol, Version 6 275 (IPv6) Specification, January 1996. RFC 1883. 277 [HD96] R. Hinden and S. Deering. IP Version 6 Addressing 278 Architecture, January 1996. RFC 1884. 280 [Pis94] D. Piscitello. FTP Operation Over Big Address Records 281 (FOOBAR), June 1994. RFC 1639. 283 [Pos81a] J. Postel. Internet Protocol, September 1981. RFC 791. 285 [Pos81b] J. Postel. Transmission Control Protocol, September 1981. 286 RFC 793. 288 [PR85] J. Postel and J. Reynolds. File Transfer Protocol (FTP), 289 October 1985. RFC 959. 291 [RP94] J. Reynolds and J. Postel. Assigned Numbers, October 1994. 292 RFC 1700. 294 Author's Addresses: 296 Mark Allman 297 NASA Lewis Research Center/Sterling Software 298 21000 Brookpark Rd. MS 54-2 299 Cleveland, OH 44135 300 Phone: (216) 433-6586 301 mallman@lerc.nasa.gov 302 http://gigahertz.lerc.nasa.gov/~mallman/ 304 Shawn Ostermann 305 School of Electrical Engineering and Computer Science 306 Ohio University 307 416 Morton Hall 308 Athens, OH 45701 309 Phone: (740) 593-1234 310 ostermann@cs.ohiou.edu 312 Craig Metz 313 The Inner Net 314 Box 10314-1954 315 Blacksburg, VA 24062-0314 316 Phone: (DSN) 754-8590 317 cmetz@inner.net