idnits 2.17.1 draft-liu-behave-ftp64-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 27, 2009) is 5355 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: 'I-D.draft-van-beijnum-behave-ftp64-05' is mentioned on line 225, but not defined == Unused Reference: 'RFC959' is defined on line 253, but no explicit reference was found in the text == Unused Reference: 'RFC2428' is defined on line 256, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 259, but no explicit reference was found in the text == Unused Reference: 'RFC1579' is defined on line 262, but no explicit reference was found in the text == Unused Reference: '1' is defined on line 266, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1579 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Behavior Engineering for Hindrance Dapeng Liu 2 Zhen Cao 3 Internet Draft China Mobile 4 Intended status: Standards Track August 27, 2009 5 Expires: February 2010 7 IPv6 IPv4 translation FTP considerations 8 draft-liu-behave-ftp64-03.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with 13 the provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on February, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your 42 rights and restrictions with respect to this document. 44 Abstract 46 The File transfer protocol, which is defined by the RFC 959, is 47 widely used. RFC 2428 define IPv6 extensions of FTP, introducing EPRT 48 and EPSV command. 50 In the IPv6-IPv4 translation scenario, considerations should be 51 applied to FTP client, server and translation box to ensure FTP 52 protocol work properly. There already have some work to address this 53 problem, such as "draft-van-beijnum-behave-ftp64-05" etc, but this 54 document provides a different approach. 56 Table of Contents 58 1. Introduction................................................3 59 2. Conventions used in this document............................4 60 3. Client considerations........................................4 61 4. Server considerations........................................4 62 5. ALG considerations..........................................4 63 6. Existing solutions and comparison............................5 64 7. Security Considerations......................................6 65 8. IANA Considerations.........................................6 66 9. Acknowledgments.............................................6 67 10. References.................................................6 68 10.1. Normative References...................................6 69 10.2. Informative References.................................7 70 Author's Addresses.............................................7 72 1. Introduction 74 Figure 1 illustrated the IPv6-IPv4 translation FTP scenario. 76 +----------------------------------------------- -----+ 77 | | 78 | | 79 | +----------------+ +--------------+ | 80 | | IPv6 Network | | IPv4 Network | | 81 | | +-----------+ | +-----------+ | +----------+ | | 82 | | |IPv6 |--|--|Translation|--|-|IPv4 | | | 83 | | |FTP Client | | | Box | | |FTP Server| | | 84 | | +-----------+ | +-----------+ | +----------+ | | 85 | | | | | | 86 | +----------------+ +--------------+ | 87 | | 88 | | 89 +------------------------------------------------ ----+ 91 Figure 1 IPv6-IPv4 translation FTP scenario. 93 The IPv6 FTP client situated in an IPv6 network and tries to 94 communicate with an IPv4 server that situated in an IPv4 network 95 using a translation box in the middle. 97 FTP has two operation modes: passive mode and active mode. In passive 98 mode, the server provides port used for the client to connect to. In 99 active mode, the server connect back to the client, using the IP 100 address and port number which provide by the client. 102 RFC 2428 specifies IPv6 extension of FTP. Two new commands, EPRT/EPSV 103 are specified. The EPRT command is an extension of PORT, it could 104 provide IPv6 address and port number to the server. The EPSV command 105 is an extension of PASV, when issue this command, the server should 106 responses its port number used for the client to connect. 108 Many serves do not support EPSV command, but most of them could 109 support PASV mode (draft-van-beijnum-behave-ftp64-05). This document 110 provides guidelines for client and server to avoid the problems that 111 IPv6 FTP client communication with an IPv4 server through a 112 translation box. 114 2. Conventions used in this document 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC-2119. 120 3. Client considerations 122 It is required that all IPv6 FTP clients MUST support both EPSV and 123 PASV command. 125 When the client tries to connect to a server using IPv6 connection, 126 it should use EPSV command first. If the server response that it does 127 not support this command or encounters an error, it MUST retry with 128 PASV command. The server will respond to PASV command with an message 129 that contains an IPv4 address and port number that used for the 130 client to connect to. The client MUST ignores the IPv4 address 131 provided in the response; it should use the control connection's IP 132 address to connect to the server to establish the data connection. 134 This approach could not only simply the FTP client software's 135 implementation but also can avoid the problems caused by using the 136 IPv4 address that included in the response message. For example, if 137 the FTP client has a private IPv4 connection and a public IPv6 138 connection, if it tries to use the IPv4 connection to establish data 139 connection with the server, it will never success. 141 4. Server considerations 143 All FTP servers MUST support EPSV and PASV command. All FTP severs 144 MUST could respond with error message to EPSV command if it does not 145 support it. The FTP sever MUST allow the client to retry with PASV 146 command when it fails with EPSV command. Also, the server must allow 147 the client to use the control connection's IP address to establish 148 data connection when it retries with PASV command. 150 5. FTP ALG considerations 152 5.1. FTP ALG limitations 154 Implementing FTP ALG in the translation box may have some limitations, 155 such as: 157 1) FTP ALG may case to increase the complexity of translation box, 158 since FTP ALG needs to understand FTP protocol and translate the 159 application layer payload and update the header of FTP control 160 packets. 162 2) For most of current Network Processor based translation box, ALG 163 processing may cause its performance decreased significantly. The 164 reason is that FTP ALG processing can not take the advantage of 165 Network Processor, which is designed and optimized for processing 166 regular packets (such as header translation). 168 3) From the evolution perspective, if the network continues to 169 provide support of FTP ALG all the time, the users will have no 170 motivation to upgrade their FTP client software. If things evolve 171 toward this direction, the ALG function of the translation box 172 will become more and more complex. In reality, upgrading FTP 173 client software is a more easy way to solve the ALG issue 174 compared with requiring that all the translation box to implement 175 FTP ALG. 177 5.2. Solution to avoid FTP ALG 179 This document suggests that the translation box which situated 180 between the IPv6 network and IPv4 network should not implement FTP 181 ALG. It is depend on the client and server that comply with this 182 specification to avoid the FTP ALG issue. 184 The reason that this document does not encourage translation box to 185 implement FTP ALG is that since the FTP ALG problem can be totally 186 avoid by defining the behavior of the client and server, it is not 187 necessary to implement it at all. This approach can reduce the 188 translation box's complexity. Also, the FTP client and server's 189 communication without ALG will significantly improve its performance. 191 For the legacy IPv6 FTP client, this document suggests that the 192 legacy client should behave like RFC1579 recommendation which is that 193 "vendors convert their FTP clients programs to use PASV instead of 194 PORT". For IPv6 FTP client, this recommendation should be "the users 195 or vendors should convert their FTP clients programs to use EPSV 196 instead of EPRT". This can be done by configuration and do not 197 require upgrading of the client software for most of current IPv6 FTP 198 client. This solution may require that the FTP server should support 199 EPSV command. 201 6. Existing solutions and comparison 203 [I-D.draft-van-beijnum-behave-ftp64-05] provides a solution that 204 addresses same problem as this document, the major differences 205 between the two approaches are: 207 1. ALG considerations of the translation box 209 [I-D.draft-van-beijnum-behave-ftp64-05] does not speak out in favor 210 or against the deployment of an FTP application layer gateway. 211 However, this document specifies that the translation box should not 212 implement FTP ALG. 214 The main concern of not recommending ALG is that FTP ALG could 215 dramatically decrease the performance of the translation box due to 216 the stateful application layer processing. ALG could be avoided by 217 the FTP client and server's implantation that complies with this 218 document. The argument here is that it is much easier for the 219 client/server software to upgrade than implementation of ALG in the 220 translation box. Eliminating the ALG function in the translation box 221 will simply the protocol operation and avoid unexpected errors. 223 2. Behavior of FTP client when retrying with PASV command 225 [I-D.draft-van-beijnum-behave-ftp64-05] recommends that the client 226 should use the IPv4 address in the PASV response message if it has 227 IPv4 connectivity and use the control connection's IP address if it 228 does not have IPv4 connectivity. However, this document specifies 229 that the client should use the control channel's IP address without 230 determination whether it has IPv4 connectivity or not. This will 231 simplify the client software, besides, if the client has IPv4 232 connectivity, the control channel will use its IPv4 address instead 233 of using its IPv6 address to connect to the IPv4 server. This 234 approach can avoid the problems that maybe caused by using the 235 client's IPv4 connection as described in section 3. 237 7. Security Considerations 239 TBD 241 8. IANA Considerations 243 None 245 9. Acknowledgments 247 TBD 249 10. References 251 10.1. Normative References 253 [RFC959] J. Postel,J.Reynolds, "File Transfer Protocol(FTP)",October 254 1985 256 [RFC2428] M.Allman,S.Ostermann,C.Metz, "FTP Extensions for IPv6 and 257 NATs", September 1998. 259 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 260 Requirement Levels", BCP 14, RFC 2119, March 1997. 262 [RFC1579] S.Bellovin, "Firewall-Friendly FTP", February 1994. 264 10.2. Informative References 266 [1] I.van Beijnum,"IPv6-to-IPv4 translation FTP considerations", 267 July 13, 2009. 269 Author's Addresses 271 Dapeng Liu 272 China Mobile research institute 273 Unit2, 28 Xuanwumenxi Ave,Xuanwu District, 274 Beijing 100053, China 276 Phone: (8610)13911788933 277 Email: liudapeng@chinamobile.com 279 Zhen Cao 280 China Mobile research institute 281 Unit2, 28 Xuanwumenxi Ave,Xuanwu District, 282 Beijing 100053, China 284 Phone: (8610)15120015799 285 Email: caozhen@chinamobile.com