idnits 2.17.1 draft-ietf-ftpext2-ftp64-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2577' is mentioned on line 222, but not defined == Unused Reference: 'I-D.draft-ietf-behave-ftp64-11' is defined on line 248, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-behave-ftp64-11 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 FTPEXT2 D. Liu 2 Internet-Draft China Mobile 3 Intended status: BCP Iljitsch van. Beijnum 4 Expires: July 11, 2012 IMDEA Networks 5 Z. Cao 6 China Mobile 7 January 11, 2012 9 FTP consideration for IPv4/IPv6 transition 10 draft-ietf-ftpext2-ftp64-02 12 Abstract 14 The File transfer protocol(FTP) has a long histroy,, but still being 15 widely used. The first concept of FTP was described RFC 114, and 16 then was specified in RFC 354. FTP can work in IPv4 environment and 17 then was extended to IPv6. RFC 2428 defines IPv6 extensions of FTP. 18 In the IPv6-IPv4 translation scenario, considerations should be 19 applied to FTP client, server and translation box to ensure FTP 20 protocol work properly. This document discusses the details for FTP 21 to work in IPv4-IPv6 transitiion scenario. This document gives 22 recommendation regarding how IPv6 FTP client should behave in 6to4 23 scenario. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 26, 2012. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Conventions used in this document . . . . . . . . . . . . . . . 4 61 3. Client considerations . . . . . . . . . . . . . . . . . . . . . 4 62 4. Server considerations . . . . . . . . . . . . . . . . . . . . . 5 63 5. FTP ALG considerations . . . . . . . . . . . . . . . . . . . . 5 64 5.1. FTP ALG limitations . . . . . . . . . . . . . . . . . . . . 5 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 67 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 70 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 73 1. Introduction 75 Figure 1 illustrated the IPv6-IPv4 translation FTP scenario. 77 +----------------------------------------------- -----+ 78 | | 79 | | 80 | +----------------+ +--------------+ | 81 | | IPv6 Network | | IPv4 Network | | 82 | | +-----------+ | +-----------+ | +----------+ | | 83 | | |IPv6 |--|--|Translation|--|-|IPv4 | | | 84 | | |FTP Client | | | Box | | |FTP Server| | | 85 | | +-----------+ | +-----------+ | +----------+ | | 86 | | | | | | 87 | +----------------+ +--------------+ | 88 | | 89 | | 90 +------------------------------------------------ ----+ 91 Figure 1 IPv6-IPv4 translation FTP scenario. 93 Figure 1 95 The IPv6 FTP client situated in an IPv6 network and tries to 96 communicate with an IPv4 server that situated in an IPv4 network 97 through a translation box in the middle. 99 It should be noted that in some scenario, the FTP client that running 100 on the IPv6 host maybe legacy IPv4 FTP client. Here "legacy IPv4 FTP 101 client" refers to the FTP client software that only support IPv4.In 102 this case, the communication will not succeed by only introducing 103 translation box in the network. That case is out the scope of this 104 document. 106 FTP has two operation modes: passive mode and active mode. In 107 passive mode, the server provides port used for the client to connect 108 to. In active mode, the server connects back to the client, using 109 the IP address and port number which provide by the client. 111 RFC 2428 specifies IPv6 extension of FTP. Two new commands, EPRT/ 112 EPSV are specified. The EPRT command is an extension of PORT, it 113 could provide IPv6 address and port number to the server. The EPSV 114 command is an extension of PASV, when client sends this command, the 115 server should responses its port number used for the client to 116 connect. 118 Many serves do not support EPSV command today, but most of them could 119 support PASV mode. This document provides guidelines and extensions 120 for implementing IPv6 FTP client to avoid the problems when an IPv6 121 FTP client communicating with an IPv4 server through a translation 122 box. 124 2. Conventions used in this document 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC 2119 [RFC2119]. 130 ALG: Application layer gateway 132 3. Client considerations 134 According to RFC 2428, the IPv6 client SHOULD support EPSV and EPRT 135 command. From the backward compatibility's perspective, this 136 document suggests that the IPv6 FTP client SHOULD support both EPSV 137 and PASV. The reason is that during the early stage of IPv6 138 transition, many FTP servers will be located in the IPv4 Internet 139 which may not support EPSV command. This requirement implies that 140 the IPv6 FTP client supports both IPv4 and IPv6 protocol version. 141 This requirement is reasonable since backward compatibility to IPv4 142 is one of the basic requirements for any IPv6 applications especially 143 in the early stage of IPv6 transition. 145 Most of today's dedicated IPv4 FTP client software uses passive mode 146 as the default mode. According to RFC 2428, for IPv6 FTP client, 147 EPSV command MUST be used when the control and data connection 148 established between the same two machines. The reasons that both 149 IPv4 and IPv6 FTP client prefer passive mode includes: 1. Active 150 mode of FTP may introduce security issues. For example, the attacker 151 may use PORT/EPRT command to specify a victim host's IP and port, 152 then the FTP serve will continually to send TCP SYN to the victim 153 host to try to establish data connection. This kind of attack is 154 recognized as FTP reflects attack. 2. Passive mode of FTP may 155 benefit when traverse firewalls or NAT. using passive mode also 156 eliminate FTP ALG in the middle box. 158 From the above analysis, it is suggested that FTP client SHOULD use 159 passive mode instead of active mode whenever it is possible. For 160 IPv6 FTP client, according to RFC 2428, it should use EPSV command. 162 In IPv4-IPv6 transition scenario, an IPv6 client may try to 163 communicate with an IPv4 server. In this case, the IPv4 server may 164 not support EPSV command and the EPSV command may fail. This 165 document suggests that the IPv6 FTP client SHOULD retry with PASV 166 command when EPSV command fails. The IPv4 FTP server will respond to 167 PASV command with a message that contains an IPv4 address and port 168 number of the FTP server that used for the client to connect to. The 169 client MUST ignores the IPv4 address provided in the response; it 170 should use the control connection's IP address to connect to the 171 server to establish the data connection. The approach that simply 172 ignoring PASV respond message's IP address and use control channel's 173 IP address could not only simply the FTP client software's 174 implementation but also can avoid the problems caused by using the 175 IPv4 address that included in the response message. For example, if 176 the FTP client has a private IPv4 connection and a public IPv6 177 connection, if it tries to use the IPv4 connection to establish data 178 connection with the server, it will never succeed. Another example 179 is: in an IPv4 world if for example a PASV reply contains network 180 address prefix, e.g. 192.168.0.0/16, which can happen if using 181 encrypted communications and going though NAT and the server hasn't 182 configured the "external" facing IP (And since the session is 183 encrypted, NAT can't see the address to change it). The client 184 should identify this (and similar) wrong IPs and reuse the control 185 connection's IP. 187 4. Server considerations 189 This document does not enforce any requirement for FTP server since 190 this document considers the IPv6 FTP client communicating with IPv4 191 FTP server scenario. The IPv4 FTP server maybe just an ordinary IPv4 192 FTP server. 194 5. FTP ALG considerations 196 This document argues that since FTP is a protocol that could avoid 197 ALG by slightly adjusting the operation of the IPv6 FTP client it is 198 not recommended the translation box to implement FTP ALG. 200 Adjusting the operation of IPv6 client is feasible because IPv6 is 201 not widely deployed and there are not much IPv6 FTP client deployed 202 right now. It is a good chance to give this guideline before the 203 widely deployment of IPv6 and IPv6 FTP client. 205 5.1. FTP ALG limitations 207 Implementing FTP ALG in the translation box may have some 208 limitations, such as: 210 1) FTP ALG may case to increase the complexity of translation box, 211 since FTP ALG needs to understand FTP protocol and translate the 212 application layer payload and update the header of FTP control 213 packets. ALG could also cause the decline of the translation box's 214 performance. 216 2) From the evolution perspective, if the network continues to 217 provide support of FTP ALG all the time, the ALG function of the 218 translation box will become more and more complex. 220 6. Security Considerations 222 FTP security is discussed in RFC 2577 [RFC 2577]. The recommendation 223 that is defined in this document will not impact FTP security. 225 7. IANA Considerations 227 None 229 8. Acknowledgments 231 The authors want to thanks the following people for their useful 232 suggestions: Robert Oslin,Anthony Bryan,John C Klensin,Mykyta 233 Yevstifeyev. 235 9. References 237 9.1. Normative References 239 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 240 Requirement Levels", BCP 14, RFC 2119, March 1997. 242 9.2. Informative References 244 [FTP Security Considerations] 245 M. Allman, "FTP Security Considerations", 1999, 246 . 248 [I-D.draft-ietf-behave-ftp64-11] 249 I. van Beijnum, "An FTP ALG for IPv6-to-IPv4 translation", 250 2011, 251 . 253 Authors' Addresses 255 Dapeng Liu 256 China Mobile 257 Unit2, 28 Xuanwumenxi Ave,Xuanwu District 258 Beijing 100053 259 China 261 Email: liudapeng@chinamobile.com 263 Iljitsch van Beijnum 264 IMDEA Networks 265 Avda. del Mar Mediterraneo, 22, Leganes 266 Madrid 28918 267 Spain 269 Email: iljitsch@muada.com 271 Zhen Cao 272 China Mobile 273 Unit2, 28 Xuanwumenxi Ave,Xuanwu District 274 Beijing 100053 275 China 277 Email: caozhen@chinamobile.com