idnits 2.17.1 draft-liu-ftpext2-ftp64-00.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 : ---------------------------------------------------------------------------- No issues found here. 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). -- The document date (July 15, 2013) is 3937 days in the past. Is this intentional? 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) -- Obsolete informational reference (is this intentional?): RFC 6145 (Obsoleted by RFC 7915) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 FTPEXT2 D. Liu 3 Internet-Draft China Mobile 4 Intended status: Best Current Practice Iljitsch. Beijnum 5 Expires: January 16, 2014 IMDEA Networks 6 Hui. Deng 7 Z. Cao 8 China Mobile 9 July 15, 2013 11 Recommendations for FTP Clients and Servers in the IPv6/IPv4 Transition 12 Scenario 13 draft-liu-ftpext2-ftp64-00 15 Abstract 17 The File transfer protocol, which was originally defined in RFC 114 18 and published in 1971, well before TCP and IP were created. However, 19 it is still in wide use. Many FTP servers implement RFC 959, which 20 requires IPv4. RFC 2428 defines extensions that allow FTP to work 21 over IPv6 by introducing the EPRT and EPSV commands. When IPv6 FTP 22 clients attempt to communicate with IPv4 FTP servers through an 23 IPv6-IPv4 translator, only certain combinations of FTP client and 24 server behavior lead to successful file transfers. This document 25 proposes the best current practice for IPv6 FTP client 26 implementations in the IPv6-IPv4 translation scenario, allowing file 27 transfers to succeed without the presence of an ALG (Application 28 Layer Gateway). 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 16, 2014. 47 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Conventions used in this document . . . . . . . . . . . . . . 3 65 3. IPv6 FTP Client Considerations . . . . . . . . . . . . . . . 3 66 4. FTP Server considerations . . . . . . . . . . . . . . . . . . 5 67 5. FTP ALG considerations . . . . . . . . . . . . . . . . . . . 5 68 5.1. FTP ALG limitations . . . . . . . . . . . . . . . . . . . 5 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 71 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 74 9.2. Informative References . . . . . . . . . . . . . . . . . 6 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 77 1. Introduction 79 Figure 1 illustrates FTP [RFC0959] in the IPv6-IPv4 translation 80 scenario. 82 +------------------------------------------------------+ 83 | | 84 | | 85 | +----------------+ +--------------+ | 86 | | IPv6 Network | | IPv4 Network | | 87 | | +-----------+ | +------------+ | +----------+ | | 88 | | |IPv6 |--|--| IPv6-IPv4 |--|-|IPv4 | | | 89 | | |FTP Client | | | Translator | | |FTP Server| | | 90 | | +-----------+ | +------------+ | +----------+ | | 91 | | | | | | 92 | +----------------+ +--------------+ | 93 | | 94 | | 95 +------------------------------------------------------+ 96 Figure 1. IPv6-IPv4 translation the FTP scenario. 98 Figure 1 100 The IPv6 FTP client is situated in an IPv6 network and communicates 101 with an IPv4 server that is situated in an IPv4 network through a 102 translation box in the middle. Here "IPv6 FTP client" means an FTP 103 client that supports IPv6, i.e., it implements [RFC2428]. "IPv4 104 server" means an FTP server with only IPv4 connectivity, which may or 105 may not support the RFC2428 extensions. 107 The situation where a legacy IPv4 FTP client that does not support 108 the RFC2428 extensions runs on the IPv6 host is out of scope. 110 FTP has two operation modes: passive mode and active mode. In 111 passive mode, the server listens on a TCP port, which the client 112 connects to. In active mode, the server connects back to the client, 113 using the IP address and port number provided by the client. 115 RFC2428 specifies extensions to the FTP protocol which let it work 116 over IPv6, and make it easier for FTP to work through firewalls and 117 NATs. Two new commands are specified: EPRT and EPSV. The EPRT 118 command is an extension of the existing PORT command. It provides 119 and IP address (IPv4 or IPv6) and a port number to the server to 120 connect to. The EPSV command is a simplified version of the PASV 121 command. Unlike with PASV, with EPSV the server does not respond 122 with an IP address for the client to connect to. Instead, the server 123 only specifies a port number. The IP address the client should 124 connect to is the same IP address that the client is already 125 connected to for the control channel TCP session. 127 Many servers do not support EPSV command today, or send a valid 128 response, but the subsequent data channel connection fails to 129 establish. However, most of these servers support PASV mode. This 130 document provides recommendations for IPv6 FTP clients that allow 131 them to successfully communicate with an IPv4 server through a 132 stateless [RFC6145] or stateful [RFC6146] IPv6-IPv4 translation box. 134 2. Conventions used in this document 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC2119]. 140 3. IPv6 FTP Client Considerations 142 According to [RFC2428], the IPv6 client SHOULD support EPSV and EPRT 143 commands. This document recommends that the IPv6 FTP client SHOULD 144 support both EPSV and PASV command. The reason is that during the 145 early stage of IPv6 transition, many FTP servers will be still 146 located in the IPv4 Internet and not support the EPSV command. This 147 requirement implies that the IPv6 FTP client SHOULD support both IPv4 148 and IPv6. This requirement is reasonable since backward 149 compatibility to IPv4 is one of the basic requirements for any IPv6 150 applications especially during the early stage of IPv6 transition. 152 Most of today's dedicated IPv4 FTP client software uses passive mode 153 as the default mode. According to RFC 2428, for IPv6 FTP client, 154 EPSV command MUST be used when the control and data connection is 155 established between the same two machines. The reasons that both 156 IPv4 and IPv6 FTP client prefer passive mode includes: 158 1. Active mode of FTP may introduce security issues. For example, 159 the attacker may use PORT/EPRT command to specify a victim host's 160 IP address and port, and then the FTP serve will send TCP SYN to 161 the victim host to attempt to establish data connection. This 162 kind of attack is recognized as FTP reflects attack. 163 2. Using passive mode of FTP can traverse firewalls and NATs more 164 easily because passive mode does not require the middle box to 165 implement an FTP ALG (Application Layer Gateway). 167 Considering the above, it is recommended that the IPv6 FTP client 168 SHOULD use passive mode instead of active mode whenever it is 169 possible. 171 In IPv6/IPv4 translation scenario, an IPv6 FTP client which is 172 located in the IPv6 network may need to communicate with an IPv4 173 server which is located in the IPv4 network. In this case, the IPv4 174 server may not support EPSV command and if the IPv6 FTP client uses 175 the EPSV command, the command may not be recognized so no file 176 transfer can be established. 178 This document recommends that the IPv6 FTP client SHOULD retry with 179 PASV command when EPSV command fails with a 50x response from the 180 server, the server sends a 229 response but the data connection 181 cannot be established, or the control channel TCP session is lost 182 between the 229 response and any other messages sent over the control 183 channel by the server. 185 After the client issues a PASV command, the IPv4 FTP server will 186 respond with a 227 message that contains an IPv4 address and port 187 number of the FTP server for the client to connect to. The IPv6 FTP 188 client MUST ignore the IPv4 address provided in the response; 189 instead, it MUST use the remote IP address used for the control 190 channel to establish the data connection. 192 Many IPv4 FTP clients already ignore the IP address in the 227 193 response because this way, the data connection will still be 194 established if the server includes its [RFC1918] address in the 227 195 response. Also, if a dual stack host connects over IPv6 for the 196 control channel and then over IPv4 for the data channel, the server 197 may reject the data channel connection because it comes from an 198 unexpected address. 200 Another important benefit of this approach is that the translation 201 box will not need to implement FTP ALG [RFC6384]. 203 4. FTP Server considerations 205 Clients conforming to the recommendations listed above will be able 206 to transfer files to/from all FTP servers. However, FTP servers are 207 encouraged to support the EPSV command if this can be done 208 successfully. If the server cannot successfully use the EPSV 209 command, for instance, because the server is located behind an 210 application aware firewall that only allows incoming data connections 211 after observing 227 responses in the FTP control channel, then 212 servers SHOULD return a 502 response when the client sends the EPSV 213 command. 215 Implementers of FTP server software SHOULD include a setting that 216 allows the EPSV command to return a 502 response. 218 5. FTP ALG considerations 220 This document recommends that the translation box does not need to 221 implement FTP ALG [RFC6384] in the IPv6/IPv4 translation scenario. 222 Instead, it is recommended that the IPv6 FTP client implementation 223 should comply with this document to avoid the necessity of 224 implementation FTP ALG in the IPv6/IPv4 translation box. 226 Adjusting the behaviour of IPv6 clients is feasible because IPv6 is 227 not widely deployed and there are not much IPv6 FTP client been 228 deployed currently. It is a good chance to publish this 229 recommendation before the widely deployment of IPv6 and IPv6 FTP 230 client. 232 5.1. FTP ALG limitations 234 Implementing FTP ALG in the translation box may have some 235 limitations, such as: 237 1) FTP ALG may case to increase the complexity of translation box, 238 since FTP ALG needs to understand FTP protocol and translate the 239 application layer payload and update the header of FTP control 240 packets. ALG could also cause impair the translation box's 241 performance. 243 2) From the evolution perspective, if the network continues to 244 provide support of FTP ALG indefinitely, the ALG function of the 245 translation box will become more and more complex. 247 6. Security Considerations 249 FTP security is discussed in [RFC2577]. The extension that is 250 defined in this document will not impact the FTP security. 252 7. IANA Considerations 254 No IANA action is required. 256 8. Acknowledgments 258 The authors want to thanks the following people for their useful 259 suggestions: Robert Oslin, Anthony Bryan. 261 9. References 263 9.1. Normative References 265 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 266 9, RFC 959, October 1985. 268 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 269 Requirement Levels", BCP 14, RFC 2119, March 1997. 271 [RFC2428] Allman, M., Ostermann, S., and C. Metz, "FTP Extensions 272 for IPv6 and NATs", RFC 2428, September 1998. 274 9.2. Informative References 276 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 277 E. Lear, "Address Allocation for Private Internets", BCP 278 5, RFC 1918, February 1996. 280 [RFC2577] Allman, M. and S. Ostermann, "FTP Security 281 Considerations", RFC 2577, May 1999. 283 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 284 Algorithm", RFC 6145, April 2011. 286 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 287 NAT64: Network Address and Protocol Translation from IPv6 288 Clients to IPv4 Servers", RFC 6146, April 2011. 290 [RFC6384] van Beijnum, I., "An FTP Application Layer Gateway (ALG) 291 for IPv6-to-IPv4 Translation", RFC 6384, October 2011. 293 Authors' Addresses 295 Dapeng Liu 296 China Mobile 297 Unit2, 28 Xuanwumenxi Ave,Xuanwu District 298 Beijing 100053 299 China 301 Email: liudapeng@chinamobile.com 303 Iljitsch van Beijnum 304 IMDEA Networks 305 Avda. del Mar Mediterraneo, 22, Leganes 306 Madrid 28918 307 Spain 309 Email: iljitsch@muada.com 311 Hui Deng 312 China Mobile 313 Unit2, 28 Xuanwumenxi Ave,Xuanwu District 314 Beijing 100053 315 China 317 Email: denghui@chinamobile.com 319 Zhen Cao 320 China Mobile 321 Unit2, 28 Xuanwumenxi Ave,Xuanwu District 322 Beijing 100053 323 China 325 Email: caozhen@chinamobile.com