idnits 2.17.1 draft-ietf-ftpext-ftp-over-ipv6-01.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-26) 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines 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 26 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 (March 13, 1998) is 9541 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 283, 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) Summary: 16 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 FTPEXT Working Group Mark Allman 3 Internet Draft NASA Lewis/Sterling Software 4 Expires: August 14, 1998 Shawn Ostermann 5 Ohio University 6 Craig Metz 7 The Inner Net 8 March 13, 1998 9 Expires: September 13, 1998 11 FTP Extensions for IPv6 12 14 Status of this Memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as ``work in 25 progress.'' 27 To learn the current status of any Internet-Draft, please check the 28 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 29 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 30 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 31 ftp.isi.edu (US West Coast). 33 Distribution of this document is unlimited. Please send comments 34 to the FTP Extension working group (FTPEXT-WG) of the Internet 35 Engineering Task Force (IETF) at . 36 Subscription address is . 37 Discussions of the group are archived at 38 . 40 Abstract 42 The specification for the File Transfer Protocol assumes that the 43 underlying network protocol uses a 32-bit network address 44 (specifically IP version 4). With the deployment of version 6 of 45 the Internet Protocol, network addresses will no longer be 32-bits. 46 This paper specifies extensions to FTP that will allow the protocol 47 to work over IPv4 and IPv6. In addition, the framework defined can 48 support additional network protocols in the future. 50 1. Introduction 52 The keywords, such as MUST and SHOULD, found in this document are 53 used as defined in RFC 2119 [Bra97]. 55 The File Transfer Protocol [PR85] only provides the ability to open 56 data connections on networks using the IPv4 protocol [Pos81a]. FTP 57 assumes network addresses will be 32 bits in length. However, with 58 the deployment of version 6 of the Internet Protocol [DH96] 59 addresses will no longer be 32 bits long. RFC 1639 [Pis94] 60 specifies extensions to FTP to enable its use over various network 61 protocols. However, the mechanism can fail in a multiple protocol 62 environment. During the transition between IPv4 and IPv6, FTP needs 63 the ability to negotiate the network protocol that will be used for 64 data transfer. 66 This document provides a specification that makes no assumptions 67 regarding the underlying network protocol. In this specification, 68 the FTP commands PORT and PASV are replaced with EPRT and EPSV, 69 respectively. This document is organized as follows. Section 2 70 outlines the EPRT command and Section 3 outlines the EPSV command. 71 Section 4 defines the utilization of these two new FTP commands. 72 Section 5 briefly presents security considerations. Finally, 73 Section 6 provides conclusions. 75 2. The EPRT Command 77 The EPRT command allows for the specification of an extended address 78 for the data connection. The extended address MUST consist of the 79 network protocol as well as the network and transport addresses. 80 The format of EPRT is: 82 EPRT 84 The EPRT command keyword must be followed by a single space (ASCII 85 32). Following the space, a delimiter character () must be 86 specified. The delimiter character MUST be one of the ASCII 87 characters in range 33-126 inclusive. The character "|" (ASCII 124) 88 is recommended unless it coincides with a character needed to encode 89 the network address. 91 The argument MUST be an upper-case string indicating the 92 protocol to be used (and, implicitly, the address length). This 93 document defines keywords for the following network protocols: 95 Keyword Protocol 96 ------- -------- 97 IP4 Internet Protocol, Version 4 [Pos81a] 98 IP6 Internet Protocol, Version 6 [DH96] 100 It is expected that keywords for additional network protocols will 101 be specified as needed in later documents. 103 The is a protocol specific string representation of the 104 network address. For each of the following keywords, addresses MUST 105 be in the following format: 107 Keyword Address Format Example 108 ------- -------------- ------- 109 IP4 dotted decimal 132.235.1.2 110 IP6 IPv6 string 1080::8:800:200C:417A 111 representations 112 defined in [HD96] 114 The argument must be the string representation of the 115 number of the TCP port on which the host is listening for the data 116 connection. 118 The following are sample EPRT commands: 120 EPRT |IP4|132.235.1.2|6275| 122 EPRT |IP6|1080::8:800:200C:417A|5282| 124 The first command specifies that the server should use IPv4 to open 125 a data connection to the host "132.235.1.2" on TCP port 6275. The 126 second command specifies that the server should use the IPv6 network 127 protocol and the network address "1080::8:800:200C:417A" to open a 128 TCP data connection on port 5282. 130 Upon receipt of a valid EPRT command, the server MUST return a code 131 of 200 (Command OK). The standard negative error code 500 and 501 132 [PR85] are sufficient to handle most errors (e.g., syntax errors) 133 involving the EPRT command. However, an additional error code is 134 needed. The response code 522 indicates that the server does not 135 support the requested network protocol. The interpretation of this 136 new error code is: 138 5yz Negative Completion 139 x2z Connections 140 xy2 Extended Port Failure - unknown network protocol 142 The text portion of the response MUST indicate which network 143 protocols the server does support. If the network protocol is 144 unsupported, the format of the response string MUST be: 146 \ 147 (prot1,prot2,...,protn) 149 In this document, any text enclosed within "<>" is informational 150 text that can be written in any language. In the above case, the 151 text SHOULD indicate that the network protocol in the EPRT command 152 is not supported by the server. Two example response strings 153 follow: 155 Network protocol not supported, use (IP6) 157 Network protocol not supported, use (IP4,IP6) 158 3. The EPSV Command 160 The EPSV command requests that a server listen on a data port and 161 wait for a connection. The EPSV command takes an optional argument. 162 The response to this command includes only the TCP port number of 163 the listening connection. The format of the response, however, is 164 similar to the argument of the EPRT command. This allows the same 165 parsing routines to be used for both commands. In addition, the 166 format leaves a place holder for the network protocol and/or network 167 address, which may be needed in the EPSV response in the future. 168 The response code for entering passive mode using an extended 169 address MUST be 229. The interpretation of this code, according to 170 [PR85] is: 172 2yz Positive Completion 173 x2z Connections 174 xy9 Extended Passive Mode Entered 176 The text returned in response to the EPSV command MUST be: 178 \ 179 () 181 The portion of the string enclosed in parentheses MUST be the exact 182 string needed by the EPRT command to open the data connection, as 183 specified above. 185 The first two fields contained in the parenthesis MUST be blank. 186 The third field MUST be the string representation of the TCP port 187 number on which the server is listening for a data connection. The 188 network protocol used by the data connection will be the same 189 network protocol used by the control connection. In addition, the 190 network address used to establish the data connection will be the 191 same network address used for the control connection. An example 192 response string follows: 194 Entering Extended Passive Mode (|||6446|) 196 The standard negative error codes 500 and 501 are sufficient to 197 handle all errors involving the EPSV command (e.g., syntax errors). 199 When the EPSV command is issued with no argument, the server will 200 choose the network protocol for the data connection based on the 201 protocol used for the control connection. However, in the case of 202 proxy FTP, this protocol might not be appropriate for communication 203 between the two servers. Therefore, the client needs to be able to 204 request a specific protocol. If the server returns a protocol that 205 is not supported by the host that will be connecting to the port, 206 the client MUST issue an ABOR (abort) command to allow the server to 207 close down the listening connection. The client can then send an 208 EPSV command requesting the use of a specific network protocol, as 209 follows: 211 EPSV 212 If the requested protocol is supported by the server, it SHOULD use 213 the protocol. If not, the server MUST return the 522 error messages 214 as outlined in section 2. 216 Finally, the EPSV command can be used with the argument ``ALL'' to 217 inform Network Address Translators that the EPRT command will never 218 be used. An example of this command follows: 220 EPSVALL 222 Upon receipt of an EPSV ALL command, the server MUST reject all data 223 connection setup commands other than EPSV (i.e., EPRT, PORT, PASV, 224 et al.). This use of the EPSV command is further explained in 225 section 4. 227 4. Command Usage 229 For all FTP transfers where the control and data connection(s) are 230 being established between the same two machines, the EPSV command 231 MUST be used. Using the EPSV command benefits performance of 232 transfers that traverse firewalls or Network Address Translators 233 (NATs). RFC 1579 [Bel94] recommends using the passive command when 234 behind firewalls since firewalls do not generally allow incoming 235 connections (which are required when using the PORT (EPRT) command). 236 In addition, using EPSV as defined in this document does not require 237 NATs to change the network address in the traffic as it is 238 forwarded. The NAT would have to change the address if the EPRT 239 command was used. Finally, if the client issues an ``EPSV ALL'' 240 command, NATs may be able to put the connection on a ``fast path'' 241 through the translator, as the EPRT command will never be used and 242 therefore, translation of the data portion of the segments will 243 never be needed. When a client only expects to do two-way FTP 244 transfers, it SHOULD issue this command as soon as possible. If a 245 client later finds that it must do a three-way FTP transfer after 246 issuing an EPSV ALL command, a new FTP session MUST be started. 248 5. Security Issues 250 The authors do not believe that these changes to FTP introduce new 251 security problems. A companion Internet Draft [AO98] is a more 252 general discussion of FTP security issues and techniques to reduce 253 these security problems. 255 6. Conclusions 257 The extensions specified in this paper will enable FTP to operate 258 over a variety of network protocols. 260 References 262 [AO98] Mark Allman and Shawn Ostermann. FTP Security 263 Considerations, March 1998. I-D 264 draft-ietf-ftpext-sec-consider-01.txt (work in progress). 266 [Bel94] S. Bellovin. Firewall-Friendly FTP, February 1994. RFC 267 1579. 269 [Bra97] Scott Bradner. Key words for use in RFCs to Indicate 270 Requirement Levels, March 1997. RFC 2119. 272 [DH96] S. Deering and R. Hinden. Internet Protocol, Version 6 273 (IPv6) Specification, January 1996. RFC 1883. 275 [HD96] R. Hinden and S. Deering. IP Version 6 Addressing 276 Architecture, January 1996. RFC 1884. 278 [Pis94] D. Piscitello. FTP Operation Over Big Address Records 279 (FOOBAR), June 1994. RFC 1639. 281 [Pos81a] J. Postel. Internet Protocol, September 1981. RFC 791. 283 [Pos81b] J. Postel. Transmission Control Protocol, September 1981. 284 RFC 793. 286 [PR85] J. Postel and J. Reynolds. File Transfer Protocol (FTP), 287 October 1985. RFC 959. 289 Author's Addresses: 291 Mark Allman 292 NASA Lewis Research Center/Sterling Software 293 21000 Brookpark Rd. MS 54-2 294 Cleveland, OH 44135 295 Phone: (216) 433-6586 296 mallman@lerc.nasa.gov 297 http://gigahertz.lerc.nasa.gov/~mallman/ 299 Shawn Ostermann 300 School of Electrical Engineering and Computer Science 301 Ohio University 302 416 Morton Hall 303 Athens, OH 45701 304 Phone: (740) 593-1234 305 ostermann@cs.ohiou.edu 307 Craig Metz 308 The Inner Net 309 Box 10314-1954 310 Blacksburg, VA 24062-0314 311 Phone: (DSN) 754-8590 312 cmetz@inner.net