idnits 2.17.1 draft-ietf-ftpext-ftp-over-ipv6-00.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-03-29) 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 29 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 (January 14, 1998) is 9571 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) == Missing Reference: 'AO96' is mentioned on line 222, but not defined == Unused Reference: 'AO97' is defined on line 233, but no explicit reference was found in the text == Unused Reference: 'Pos81b' is defined on line 251, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-ietf-ftpext-sec-consider-00 ** Downref: Normative reference to an Informational draft: draft-ietf-ftpext-sec-consider (ref. 'AO97') ** 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: 15 errors (**), 0 flaws (~~), 7 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: July 14, 1998 Shawn Ostermann 4 Ohio University 5 January 14, 1998 7 FTP Extensions for IPv6 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time. It is inappropriate to use Internet-Drafts as 20 reference material or to cite them other than as ``work in 21 progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 25 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Distribution of this document is unlimited. Please send comments 30 to the FTP Extension working group (FTPEXT-WG) of the Internet 31 Engineering Task Force (IETF) at . 32 Subscription address is . 33 Discussions of the group are archived at 34 . 36 Abstract 38 The specification for the File Transfer Protocol assumes that the 39 underlying network protocol uses a 32-bit network address 40 (specifically IP version 4). With the deployment of version 6 of 41 the Internet Protocol, network addresses will no longer be 32-bits. 42 This paper specifies extensions to FTP that will allow the protocol 43 to work over IPv4 and IPv6. In addition, the framework defined can 44 support additional network protocols in the future. 46 1. Introduction 48 The keywords, such as MUST and SHOULD, found in this document are 49 used as defined in RFC 2119 [Bra97]. 51 The File Transfer Protocol [PR85] only provides the ability to open 52 data connections on networks using the IPv4 protocol [Pos81a]. FTP 53 assumes network addresses will be 32 bits in length. However, with 54 the deployment of version 6 of the Internet Protocol [DH96] this 55 will no longer be the case. RFC 1639 [Pis94] specifies extensions 56 to FTP to enable its use over various network protocols. However, 57 the mechanism can fail in a multiple protocol environment. During 58 the transition between IPv4 and IPv6, FTP needs the ability to 59 negotiate the network protocol that will be used for data transfer. 61 This document provides a specification which makes no assumptions 62 regarding the underlying network protocol. In this specification, 63 the FTP commands PORT and PASV are replaced with EPRT and EPSV, 64 respectively. 66 2. The EPRT Command 68 The EPRT command allows for the specification of an extended address 69 for the data connection. The extended address consists of the 70 network protocol as well as the network and transport addresses. 71 The format of EPRT is: 73 EPRT 75 The EPRT command keyword must be followed by a single space. 76 Following the space, a delimiter character () must be specified. 77 The delimiter character MUST be one of the ASCII characters in range 78 33-126 inclusive. The character "|" (ASCII 124) is recommended 79 unless it coincides with a character needed to encode the network 80 address. 82 The argument MUST be an upper-case string indicating the 83 protocol to be used (and, implicitly, the address length). This 84 specification defines keywords for the following network protocols: 86 Keyword Protocol 87 ------- -------- 88 IP4 Internet Protocol, Version 4 [Pos81a] 89 IP6 Internet Protocol, Version 6 [DH96] 91 It is expected that keywords for additional network protocols will 92 be specified as needed in later documents. 94 The is a protocol specific string representation of the 95 network address. For each of the following keywords, addresses MUST 96 be in the following format: 98 Keyword Address Format Example 99 ------- -------------- ------- 100 IP4 dotted decimal 132.235.1.2 101 IP6 IPv6 string 1080::8:800:200C:417A 102 representations 103 defined in [HD96] 105 The argument must be the string representation of the 106 number of the TCP port on which the host is listening for the data 107 connection. 109 The and fields are optional. If left blank, 110 their default values are as follows: 112 Field Default Value If Omitted 113 ----- ------------------------ 114 Network protocol of the control connection 115 Network address of the control connection 117 The following are sample EPRT commands: 119 EPRT |IP4|132.235.1.2|6275| 121 EPRT |||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 network 126 protocol and network address used by the control connection to open 127 a 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 codes 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. In the above case, the 150 text SHOULD indicate that the network protocol in the EPRT command 151 is not supported by the server. Two example response strings 152 follow: 154 Supported network protocols (IP6) 156 Supported network protocols (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 162 argument. The response to this command includes all 163 information needed to setup a connection using the EPRT command. 164 The response code for entering passive mode using an extended 165 address MUST be 229. The interpretation of this code, according to 166 [PR85] is: 168 2yz Positive Completion 169 x2z Connections 170 xy9 Extended Passive Mode Entered 172 The text returned in response to the EPSV command MUST be: 174 \ 175 () 177 The portion of the string enclosed in parentheses MUST be the exact 178 string needed by the EPRT command to open the data connection, as 179 specified above. As with the EPRT command, the first two fields in 180 the EPSV response are optional. Similar to the EPRT commands, when 181 left blank these fields default to the values used for the control 182 connection. An example response string follows: 184 Entering Extended Passive Mode (|IP4|132.235.1.2|6446|) 186 The standard negative error codes 500 and 501 are sufficient to 187 handle all errors involving the EPSV command (e.g., syntax errors). 189 When the EPSV command is issued with no argument, the server will 190 choose the network protocol for the data connection. However, since 191 it is possible for the server to return an unsupported protocol in 192 the EPSV response, the client needs to be able to request a specific 193 protocol. If the server returns a protocol that the client does not 194 support, the client will not be able to open a data connection to 195 the server. In this situation, the client MUST issue an ABOR 196 (abort) command to allow the server to close down the listening 197 connection. The client can then send an EPSV command requesting the 198 use of a specific network protocol, as follows: 200 EPSV 202 If the requested protocol is supported by the server, it SHOULD use 203 the protocol. If not, the server MUST return the 522 error messages 204 as outlined in section 2. 206 The client may issue either form of the EPSV command at any time. 207 In other words, the version without arguments need not be issued 208 before the version with arguments. 210 4. IPv6 Transition Issues 212 To aid in transition from IPv4 to IPv6 it is RECOMMENDED that the 213 network address be omitted from the EPRT command and the EPSV 214 response whenever possible. This will allow the end hosts to 215 utilize standard IPv6 mechanisms to communicate (such as network 216 address translators), rather than forcing FTP to negotiate the 217 network protocol. 219 5. Security Issues 221 The above changes to FTP do not introduce new FTP security problems. 222 A companion Internet Draft [AO96] is a more general discussion of 223 FTP security issues and techniques to reduce these security 224 problems. 226 6. Conclusions 228 The extensions specified in this paper will enable FTP to operate 229 over a variety of network protocols. 231 References 233 [AO97] Mark Allman and Shawn Ostermann. FTP Security 234 Considerations, January 1998. I-D 235 draft-ietf-ftpext-sec-consider-00.txt (work in progress). 237 [Bra97] Scott Bradner. Key words for use in RFCs to Indicate 238 Requirement Levels, March 1997. RFC 2119. 240 [DH96] S. Deering and R. Hinden. Internet Protocol, Version 6 241 (IPv6) Specification, January 1996. RFC 1883. 243 [HD96] R. Hinden and S. Deering. IP Version 6 Addressing 244 Architecture, January 1996. RFC 1884. 246 [Pis94] D. Piscitello. FTP Operation Over Big Address Records 247 (FOOBAR), June 1994. RFC 1639. 249 [Pos81a] J. Postel. Internet Protocol, September 1981. RFC 791. 251 [Pos81b] J. Postel. Transmission Control Protocol, September 1981. 252 RFC 793. 254 [PR85] J. Postel and J. Reynolds. File Transfer Protocol (FTP), 255 October 1985. RFC 959. 257 Author's Addresses: 259 Mark Allman 260 NASA Lewis Research Center/Sterling Software 261 21000 Brookpark Rd. MS 54-2 262 Cleveland, OH 44135 263 mallman@lerc.nasa.gov 264 http://gigahertz.lerc.nasa.gov/~mallman/ 266 Shawn Ostermann 267 School of Electrical Engineering and Computer Science 268 Ohio University 269 416 Morton Hall 270 Athens, OH 45701 271 ostermann@cs.ohiou.edu