idnits 2.17.1 draft-tsou-behave-ftp46-01.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 date (September 16, 2013) is 3874 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Tsou, Ed. 3 Internet-Draft Huawei Technologies (USA) 4 Intended status: Informational S. Perreault 5 Expires: March 20, 2014 Viagenie 6 J. Huang 7 Huawei Technologies 8 September 16, 2013 10 An FTP Application Layer Gateway (ALG) for IPv4-to-IPv6 Translation 11 draft-tsou-behave-ftp46-01 13 Abstract 15 An FTP ALG for NAT64 was defined in RFC 6384. Its scope was limited 16 to an IPv6 client connecting to an IPv4 server. This memo supports 17 the case of an IPv4 client connecting to an IPv6 server. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 20, 2014. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. PASV to EPSV . . . . . . . . . . . . . . . . . . . . . . . . 3 58 5. EPSV (IPv4) to EPSV (IPv6) . . . . . . . . . . . . . . . . . 4 59 6. Command to disable FTP ALG . . . . . . . . . . . . . . . . . 5 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 62 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 63 10. Normative References . . . . . . . . . . . . . . . . . . . . 6 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Overview 68 During the transition from IPv4 to IPv6, some operators need to 69 deploy NAT in their network. Some subscribers have the need to run 70 IPv4 based FTP servers at home, and some of the FTP [RFC0959] control 71 messages carry IP address and port number in the payload, which will 72 cause a NAT traversal problem. 74 [RFC6384] defines FTP ALG for NAT64, but only for the case where the 75 FTP client is on the inside of the NAT64. The case where an FTP 76 server is on the inside of the NAT64 is not covered. 78 When the FTP server is behind NAT, it can publish its service address 79 via a HTTP redirect server and a DDNS system which needs to support 80 both IP address and port rather than IP address only, or other 81 possible methods. The FTP server can listen on any possible ports, 82 not just port 21; FTP server can get it external IP address and port 83 via some technology like UPnP, and then publish the acquired IP 84 address and port as its URI, ftp://203.0.113.1:1200, port 1200 is 85 allocated by NAT. 87 1.1. Requirements Language 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 [RFC2119]. 92 2. Terminology 94 3. Scenarios 96 There can be several scenarios if NAT is involved in the network. 98 a) In this scenario, the FTP client is behind NAT, FTP ALG needs to 99 handle the EPRT / PORT command in FTP active mode, translating the IP 100 address and port. This scenario has been covered by [RFC6384], but 101 only for NAT64. This scenario for other kinds of NAT has not been 102 covered. 104 +--------+ +---------+ +-------+ +---------+ +--------+ 105 | FTP | | | | | | | | FTP | 106 | Client +----+ IPv6 +----+ NAT64 +----+ IPv4 +----+ Server + 107 | | | Network | | | | Network | | | 108 | IPv6 | | | | | | | | IPv4 | 109 +--------+ +---------+ +-------+ +---------+ +--------+ 111 FTP Client Behind NAT 113 b) If the FTP server is behind a NAT, FTP passive mode will be the 114 only working mode, the EPSV / PASV command and the response will be 115 processed by FTP ALG. This memo covers this scenario. 117 +--------+ +---------+ +-------+ +---------+ +--------+ 118 | FTP | | | | | | | | FTP | 119 | Server +----+ IPv6 +----+ NAT64 +----+ IPv4 +----+ Client + 120 | | | Network | | | | Network | | | 121 | IPv6 | | | | | | | | IPv4 | 122 +--------+ +---------+ +-------+ +---------+ +--------+ 124 FTP Server Behind NAT 126 4. PASV to EPSV 127 If FTP client issues PASV command to FTP server, FTP ALG translates 128 PASV command into EPSV command [RFC2428], setting the "net-prt" field 129 to 2 (IPv6). The response of EPSV command is translated into PASV 130 response. FTP ALG allocates an IPv4 address and port for the EPSV 131 response message, and builds a NAT mapping entry if the NAT is 132 stateful. The source address of the EPSV response message and the 133 "tcp-port" in the payload are used for the NAT mapping. The 134 allocated IPv4 address and port are put into the PASV response 135 message. 137 For instance, in the IPv4 side of NAT64, FTP server's address is 138 203.0.113.1. FTP client issues a PASV command to FTP server, and it 139 is translated into EPSV command by FTP AGL, as shown below: 141 PASV command: 143 PASV 145 EPSV command: 147 EPSV 2 149 When FTP server returns a success response of EPSV containing tcp- 150 port 3000, FTP AGL allocates an IPv4 address 203.0.113.1 and tcp-port 151 2000 corresponding to the tcp-port 3000 in the EPSV response message, 152 and puts the allocated IP address and port into PASV response 153 message, as shown below: 155 EPSV success response: 157 229 Entering Passive Mode (|||3000|) 159 PASV success response: 161 227 Entering Passive Mode (203,0,113,1,7,208) 163 5. EPSV (IPv4) to EPSV (IPv6) 165 If FTP client issues EPSV command to FTP server, FTP ALG modifies the 166 "net-prt", change the value from 1 (IPv4) to 2 (IPv6). The response 167 of IPv6 EPSV command is also translated. FTP ALG allocates an IPv4 168 address and port for the EPSV response message. 170 [RFC2428] requires that "the network address used to establish the 171 data connection will be the same network address used for the control 172 connection", so NAT MUST to make sure that IPv4 address for control 173 connection and IPv4 address for data connection for a FTP server must 174 be the same, which means all the mappings for an IPv6 address MUST 175 have the same external IPv4 address. 177 For instance, in the IPv4 side of NAT64, FTP server's address is 178 203.0.113.1. The FTP client issues an IPv4 EPSV command to FTP 179 server, and it is translated into IPv6 EPSV command by FTP AGL, as 180 shown below: 182 EPSV (IPv4) command: 184 EPSV 1 186 EPSV (IPv6) command: 188 EPSV 2 190 When FTP server returns a success response of EPSV containing port 191 3000, FTP AGL will allocate an IPv4 address 203.0.113.1 and port 2000 192 corresponding to the port 3000 in the EPSV response message, and put 193 the allocated port into PASV response message, as shown below: 195 EPSV (IPv6) success response: 197 229 Entering Passive Mode (|||3000|) 199 EPSV (IPv4) success response: 201 229 Entering Passive Mode (|||2000|) 203 6. Command to disable FTP ALG 205 Command ALGS defined in [RFC6384] is extended, three more possible 206 arguments are added: 208 ALGS STATUS46 to return the EPSV and EPRT translation status. 210 ALGS ENABLE46 to enable translation. 212 ALGS DISABLE46 to disable translation. 214 7. IANA Considerations 216 This memo includes no request to IANA. 218 8. Security Considerations 220 RFC6384's security considerations applies to this document. 222 9. Acknowledgements 224 10. Normative References 226 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 227 9, RFC 959, October 1985. 229 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 230 Requirement Levels", BCP 14, RFC 2119, March 1997. 232 [RFC2428] Allman, M., Ostermann, S., and C. Metz, "FTP Extensions 233 for IPv6 and NATs", RFC 2428, September 1998. 235 [RFC6384] van Beijnum, I., "An FTP Application Layer Gateway (ALG) 236 for IPv6-to-IPv4 Translation", RFC 6384, October 2011. 238 Authors' Addresses 240 Tina Tsou (editor) 241 Huawei Technologies (USA) 242 2330 Central Expressway 243 Santa Clara CA 95050 244 USA 246 Phone: +1 408 330 4424 247 Email: tina.tsou.zouting@huawei.com 249 Simon Perreault 250 Viagenie 251 246 Aberdeen 252 Quebec, QC G1R 2E1 253 Canada 255 Phone: +1 418 656 9254 256 Email: simon.perreault@viagenie.ca 257 URI: http://viagenie.ca 258 Jing Huang 259 Huawei Technologies 260 Huawei Area F, Bantian, Longgang District 261 Shenzhen 518129 262 China 264 Email: James.huang@huawei.com