idnits 2.17.1 draft-ietf-behave-ftp64-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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 3 instances 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 date (May 2, 2010) is 5070 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) ** Obsolete normative reference: RFC 2765 (Obsoleted by RFC 6145) == Outdated reference: A later version (-12) exists of draft-ietf-behave-v6v4-xlate-stateful-11 == Outdated reference: A later version (-23) exists of draft-ietf-behave-v6v4-xlate-05 == Outdated reference: A later version (-05) exists of draft-liu-behave-ftp64-03 ** Downref: Normative reference to an Informational draft: draft-liu-behave-ftp64 (ref. 'I-D.liu-behave-ftp64') -- Possible downref: Non-RFC (?) normative reference: ref. 'Bernstein' Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Behavior Engineering for Hindrance I. van Beijnum 3 Avoidance IMDEA Networks 4 Internet-Draft May 2, 2010 5 Intended status: Standards Track 6 Expires: November 3, 2010 8 IPv6-to-IPv4 translation FTP considerations 9 draft-ietf-behave-ftp64-01 11 Abstract 13 The File Transfer Protocol has a very long history, and despite the 14 fact that today, other options exist to perform file transfers, FTP 15 is still in common use. As such, it is important that in the 16 situation where some client computers are IPv6-only while many 17 servers are still IPv4-only and IPv6-to-IPv4 translators are used to 18 bridge that gap, FTP is made to work through these translators as 19 best it can. 21 FTP has an active and a passive mode, both as original commands that 22 are IPv4-specific, and as extended, IP version agnostic commands. 23 The only FTP mode that works without changes through an IPv6-to-IPv4 24 translator is extended passive. However, many existing FTP servers 25 don't support this mode, and some clients don't ask for it. This 26 document describes server, client and middlebox (if any) behavior 27 that minimizes this problem. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on November 3, 2010. 46 Copyright Notice 48 Copyright (c) 2010 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 4 65 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4. ALG functionality . . . . . . . . . . . . . . . . . . . . . . 5 67 4.1. Control channel translation . . . . . . . . . . . . . . . 5 68 4.2. EPSV to PASV translation . . . . . . . . . . . . . . . . . 7 69 4.3. EPRT to PORT translation . . . . . . . . . . . . . . . . . 8 70 4.3.1. Stateless EPRT translation . . . . . . . . . . . . . . 8 71 4.3.2. Stateful EPRT translation . . . . . . . . . . . . . . 9 72 4.4. Default port 20 translation . . . . . . . . . . . . . . . 9 73 4.5. Both PORT and PASV . . . . . . . . . . . . . . . . . . . . 10 74 4.6. Default behavior . . . . . . . . . . . . . . . . . . . . . 10 75 4.7. Timeouts and translating to NOOP . . . . . . . . . . . . . 10 76 5. Client recommendations . . . . . . . . . . . . . . . . . . . . 11 77 6. Server recommendations . . . . . . . . . . . . . . . . . . . . 12 78 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 79 8. Security considerations . . . . . . . . . . . . . . . . . . . 13 80 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 82 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 Appendix A. Document and discussion information . . . . . . . . . 15 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 1. Introduction 88 [RFC0959] specifies two modes of operation for FTP: active mode, in 89 which the server connects back to the client and passive mode, where 90 the server opens a port for the client to connect to. Without 91 additional action, active mode with a client-supplied port doesn't 92 work through NATs or firewalls. And in both cases, an IPv4 address 93 is specified, making both the original passive and active modes 94 incompatible with IPv6. These issues were solved in [RFC2428], which 95 introduces the EPSV (extended passive) mode, where the server only 96 responds with a port number, and the EPRT (extended port) command, 97 which allows the client to supply either an IPv4 or an IPv6 address 98 (and a port) to the server. 100 A survey done in April of 2009 of 25 randomly picked and/or well- 101 known FTP sites reachable over IPv4 showed that only 12 of them 102 supported EPSV over IPv4. Additionally, only 2 of those 12 indicated 103 that they supported EPSV in response to the FEAT command ([RFC2389]) 104 that asks the server to list its supported features. One supported 105 EPSV but not FEAT. In 5 cases, issuing the EPSV command to the 106 server led to a significant delay, in 3 cases followed by a control 107 channel reset. All 25 servers were able to successfully complete a 108 transfer in traditional passive PASV mode as required by [RFC1123]. 109 More tests showed that the use of an address family argument with the 110 EPSV command is widely mis- or unimplemented in servers. The 111 additional tests with more servers showed that approximately 65% of 112 FTP servers support EPSV successfully and around 96% support PASV 113 successfully. Clients weren't extensively tested, but previous 114 experience from the author suggests that most clients support PASV, 115 with the notable exception of the command line client included with 116 Windows, which only supports active mode. It uses the original PORT 117 command when running over IPv4 and EPRT when running over IPv6. 119 Considering the above, this document describes the following 120 recommendations: 122 Servers: 124 * Allow EPSV (even for IPv4-only servers) 126 * Use a predictable address in the response to the PASV command 128 Clients: 130 * Use EPSV over IPv6 rather than EPRT 132 * Fall back to PASV if EPSV fails (even over IPv6) 133 * Don't use certain modes and options that trigger server bugs 135 Additionally, the document standardizes behavior for application 136 layer gateway functionality to provide connectivity between unupdated 137 servers and/or clients. Clients that want to engage in more complex 138 behavior, such as server-to-server transfers, may make an FTP ALG go 139 into transparent mode by issuing an AUTH command as explained in 140 Section 4.1. 142 The recommendations and specifications in this document apply to all 143 forms of IPv6-to-IPv4 translation, including stateless translation 144 such as [RFC2765] or [I-D.ietf-behave-v6v4-xlate] as well as stateful 145 translation such as [I-D.ietf-behave-v6v4-xlate-stateful]. 147 The FTP protocol allows for complex interactions, such as the 148 situation where a client connects to two servers and directs the 149 servers to exchange data between them. No attempt is made to address 150 these other than through making ALGs transparent after an AUTH 151 command. 153 2. Notational Conventions 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in [RFC2119]. 159 3. Terminology 161 Within the context of this document, the words "client" and "server" 162 refer to FTP client and server implementations, respectively. An FTP 163 server is understood to be an implementation of the FTP protocol 164 running on a server system with a stable address, waiting for clients 165 to connect and issue commands and start data transfers. Clients 166 interact with servers using the FTP protocol, and store (upload files 167 to) or retrieve (download files from) one or more servers, either 168 interactively under control of a user, or as an unattended background 169 process. Most operating systems provide a web browser that 170 implements a basic FTP client, as well as a command line client. 171 Third-party FTP clients are also widely available. 173 Other terminology is derived from the documents listed in the 174 reference section. Note that this document can't be fully understood 175 on its own; it depends on background and terminology outlined in the 176 references. 178 4. ALG functionality 180 Many within the IETF community argue that the problem is better 181 solved by changing FTP clients and FTP servers rather than using a 182 translator. As such, it is recommended to update FTP clients and 183 servers as required for IPv6-to-IPv4 translation support where 184 possible, to allow proper operation of the FTP protocol without the 185 need for ALGs. 187 On the other hand, network operators often have little influence over 188 the FTP clients their customers run, let alone the FTP servers used 189 throughout the Internet. For those operators, deploying an ALG may 190 be the only way to provide a satisfactory customer experience. So, 191 even though not the preferred solution, this document standardizes 192 the functionality of such an ALG in order to promote consistent 193 behavior between ALGs in an effort to minimize their harmful effects. 194 However, the situation with regard to FTP servers and -clients, 195 especially in IPv6-heavy deployments, is subject to change, at which 196 time it may become feasible to stop running an ALG. Operators are 197 encouraged to keep revisiting the issue. 199 Operators are encouraged to only deploy an FTP ALG for IPv6-to-IPv4 200 translation when the FTP ALG is clearly needed. In the presence of 201 the ALG, EPSV commands that could be handled directly by conforming 202 servers are translated into PASV commands, introducing unnecessary 203 complexity and reducing robustness. As such a "set and forget" 204 policy on ALGs is not recommended. 206 Note that the translation of EPSV through all translators and EPRT 207 through a stateless translator is relatively simple and translation 208 of EPRT through a stateful translator relatively difficult because a 209 translation mapping must be set up. This needs to happen before the 210 EPRT command can be translated into a PORT command and passed on to 211 the server. As such, an ALG used with a stateful translator MUST 212 support EPSV and MAY support EPRT. However, an ALG used with a 213 stateless translator SHOULD also support EPRT. 215 The ALG functionality is described as a function separate from the 216 IPv6-to-IPv4 translation function. However, in the case of stateless 217 translation, the ALG and translator functions need to be tightly 218 coupled, so presumably, these functions are integrated within a 219 single device. 221 4.1. Control channel translation 223 The IPv6-to-IPv4 FTP ALG intercepts all TCP sessions towards IPv4 224 port 21 destinations. The FTP ALG implements the Telnet protocol 225 ([RFC0854]) used for control channel interactions to the degree 226 necessary to interpret commands and responses and re-issue those 227 commands and responses, modifying them as outlined below. Telnet 228 option negotiation attempts by either the client or the server, 229 except for those allowed by [RFC1123], MUST be rejected by the FTP 230 ALG without relaying those attempts. This avoids the situation where 231 the client and the server negotiate Telnet options unknown to the FTP 232 ALG. 234 There are two ways to implement the control channel ALG: 236 1. The ALG terminates the IPv6 TCP session, sets up a new IPv4 TCP 237 session towards the IPv4 FTP server, and relays commands and 238 responses back and forth between the two sessions. 240 2. Packets that are part of the control channel are translated 241 individually. 243 In the second case, an implementation MUST have the ability to track 244 and update TCP sequence numbers when translating packets and break up 245 packets into smaller packets after translation, as the control 246 channel translation could modify the length of the payload portion of 247 the packets in question. Also, FTP commands/responses or Telnet 248 negotiations could straddle packet boundaries, so in order to be able 249 to perform the ALG function, it can prove necessary to reconstitute 250 Telnet negotiations and FTP commands and responses from multiple 251 packets. 253 If the client issues the AUTH command the client is attempting to 254 negotiate [RFC2228] security mechanisms which are likely to be 255 incompatible with the FTP ALG function. In this situation, the FTP 256 ALG MUST switch to transparently forwarding all data on the control 257 channel in both directions until the end of the control channel 258 session. This requirement applies regardless of the response from 259 the server. In other words, it is the fact that the client attempts 260 the AUTH negotiation that requires the ALG to become transparent, 261 whether or not the attempt is successful. The transparency 262 requirement applies to the commands and responses flowing between the 263 client and the server. It is possible that commands or responses 264 that were sent through the ALG before the AUTH command was issued 265 were changed in length so TCP sequence numbers in packets entering 266 the ALG and packets exiting the ALG no longer match. In transparent 267 mode, the ALG MUST continue to adjust sequence numbers if it was 268 doing so before entering transparent mode as the result of the AUTH 269 command. 271 There have been FTP ALGs for the purpose of making active FTP work 272 through IPv4 NATs for a long time. Another type of ALG would be one 273 that imposes restrictions required by security policies. Multiple 274 ALGs can be implemented as a single entity. If such a multi-purpose 275 ALG forbids the use of the AUTH command for policy reasons, the side 276 effect of making the ALG stop performing the translations described 277 here, as well as other possible interventions related to IPv6-to-IPv4 278 translation, MUST be retained even if the ALG responds to the AUTH 279 command with an error and doesn't propagate the command to the 280 server. Implementers are further advised that unlike hosts behind an 281 IPv4 NAT, IPv6 hosts using an IPv6-to-IPv4 translator will normally 282 have the ability to execute FTP over IPv6 without interference from 283 the ALG, so an IPv6-to-IPv4 translation FTP ALG is not the best place 284 to implement security policies. 286 4.2. EPSV to PASV translation 288 Although many IPv4 FTP servers support the EPSV command, some servers 289 react adversely to this command, and there is no reliable way to 290 detect in advance that this will happen. As such, an FTP ALG MUST 291 translate all occurrences of the EPSV command issued by the client to 292 the PASV command, and reformat a 227 response as a corresponding 229 293 response. However, an ALG MAY forego EPSV to PASV translation if it 294 has positive knowlegde, either administratively configured or learned 295 dynamically, that EPSV will be successful without translation to 296 PASV. 298 For instance, if the client issues EPSV (or EPSV 2 to indicate IPv6 299 as the network protocol), this is translated to the PASV command. If 300 the server with address 192.0.2.31 then responds with: 302 227 Entering Passive Mode (192,0,2,31,237,19) 304 The FTP ALG reformats this as: 306 229 Entering Extended Passive Mode (|||60691|) 308 The ALG SHOULD ignore the IPv4 address in the server's 227 response, 309 this is the behavior that is exhibited by most clients and is needed 310 to work with servers that include [RFC1918] addresses in their 227 311 responses. However, if the 227 response contains an IPv4 address 312 that doesn't match the destination of the control channel, the FTP 313 ALG MAY send the following response to the client instead of the 229 314 response: 316 425 Can't open data connection. 318 It is important that the response is in the 4xx range to indicate a 319 temporary condition. 321 If the client issues an EPSV command with a numeric argument other 322 than 2, the ALG MUST NOT pass the command on to the server, but 323 rather respond with a 522 error. 325 If the client issues EPSV ALL, the FTP ALG MUST NOT pass this command 326 to the server, but respond with: 328 504 Command not implemented for that parameter. 330 This avoids the situation where an FTP server may react adversely to 331 receiving a PASV command after the client indicated that it will only 332 use EPSV during this session. 334 4.3. EPRT to PORT translation 336 Should the IPv6 client issue an EPRT command, the FTP ALG may 337 translate this EPRT command to a PORT command. The translation is 338 different depending on whether the translator is a stateless one-to- 339 one translator or a stateful one-to-many translator. 341 4.3.1. Stateless EPRT translation 343 If the address specified in the EPRT command is the client's IPv6 344 address, then the FTP ALG reformats the EPRT command into a PORT 345 command with the IPv4 address that maps to the client's IPv6 address. 346 The port number must be preserved for compatibility with stateless 347 translators. For instance, if the client with IPv6 address 2001:db8: 348 2::31 issues EPRT the EPRT command: 350 EPRT |2|2001:db8:2::31|5282| 352 Assuming the IPv4 address that goes with 2001:db8:2::31 is 353 192.0.2.31, the FTP ALG reformats this as: 355 PORT 192,0,2,31,20,162 357 If the address specified in the EPRT command is an IPv4 address or an 358 IPv6 address that is not the client's IPv6 address, the ALG's 359 response is undefined. It may pass along the command unchanged, 360 respond with an error, or attempt to perform an appropriate 361 translation. 363 If the address specified in the EPRT command is an IPv4 address or an 364 IPv6 address that is the client's IPv6 address, but there is no IPv4 365 address that maps to the client's IPv6 address, the ALG responds as 366 follows: 368 425 Can't open data connection. 370 It is important that the response is in the 4xx range to indicate a 371 temporary condition. 373 4.3.2. Stateful EPRT translation 375 If the address in the EPRT command is the IPv6 address of the control 376 channel client's address, the stateful translator selects an unused 377 port number in combination with the IPv4 address used for the control 378 channel towards the FTP server, and sets up a mapping from that 379 transport address to the one specified by the client in the EPRT 380 command. The PORT command with the IPv4 address and port used on the 381 IPv4 side of the mapping is only issued towards the server once the 382 mapping is created. Initially, the mapping is such that either any 383 transport address or the FTP server's IPv4 address with any port 384 number is accepted as a source, but once the three-way handshake is 385 complete, the mapping is narrowed to only match the negotiated TCP 386 session. 388 If the address in the EPRT command is not the client's IPv6 address, 389 the ALG's response is undefined. 391 If the client with IPv6 address 2001:db8:2::31 issues EPRT the EPRT 392 command: 394 EPRT |2|2001:db8:2::31|5282| 396 And the stateful translator uses the address 192.0.2.31 on its IPv4 397 interface, a mapping with destination address 192.0.2.31 and 398 destination port 60192 towards 2001:db8:2::31 port 5282 may be 399 created, after which the FTP ALG reformats the EPRT command as: 401 PORT 192,0,2,31,235,32 403 4.4. Default port 20 translation 405 If the client doesn't issue an EPSV/PASV or EPRT/PORT command, it is 406 invoking the default active FTP behavior where the server sets up a 407 TCP session towards the client. In this situation, the source port 408 number is the default FTP data port (port 20) and the destination 409 port is the port the client uses as the source port in the control 410 channel session. 412 In the case of a stateless translator, this does not pose any 413 problems. In the case of a stateful translator, the translator 414 should accept incoming connection requests from the server on the 415 IPv4 side if the transport addresses match that of an existing FTP 416 control channel session, with the exception that the control channel 417 session uses port 21 and the new session port 20. In this case, a 418 mapping is set up towards the same transport address on the IPv6 side 419 that is used for the matching FTP control channel session. 421 So for instance, the client is 2001:db8:31::6 and the server is 422 192.0.2.4. The translator has prefix 2001:db8:ffff:fffff::/96 as its 423 translator prefix and 10.0.0.1 as its IPv4 address. On the IPv6 424 side, the transport addresses for an FTP control channel session 425 could then be 2001:db8:31::6,49152 to 2001:db8:ffff:ffff::c000:204,21 426 on the IPv6 side and 10.0.0.1,60000 to 192.0.2.4,21 on the IPv4 side. 427 If then the FTP server initiates a session from 192.0.2.4,20 to 428 10.0.0.1,60000, the translator sets up a mapping from those addresses 429 to source 2001:db8:ffff:ffff::c000:204,20 destination 2001:db8:31:: 430 6,49152. 432 If there is no (unambiguous) match for an existing data channel 433 session when an incoming session request on port 20 arrives, the 434 connection is refused with a TCP RST. 436 4.5. Both PORT and PASV 438 [RFC0959] allows a client to issue both PORT and PASV to use non- 439 default ports on both sides of the connection. However, this is 440 incompatible with the notion that with PASV the data connection is 441 made from the client to the server, while PORT reaffirms the default 442 behavior where the server connects to the client. As such, the 443 behavior of an ALG is undefined when a client issues both PASV and 444 PORT. 446 4.6. Default behavior 448 Whenever the client issues a command which the ALG is not set up to 449 translate, either because the command is not mentioned above, the 450 command is not part of any FTP specification, the ALG functionality 451 is disabled administratively or otherwise for the command in 452 question, or translation does not apply for any other reason, the 453 command MUST be passed on to the server without modification, and the 454 server response MUST be passed on to the client without any 455 modification. For example, if the client issues the PASV command, 456 this command is passed on to the server transparently. 458 4.7. Timeouts and translating to NOOP 460 Wherever possible, control channels should not time out while there 461 is an active data channel. A timeout of at least 30 seconds is 462 recommended for mappings created by the FTP ALG that are waiting for 463 initial packets. 465 Whenever a command from the client is not propagated to the server, 466 the FTP ALG instead issues a NOOP command in order to keep the 467 keepalive state between the client and the server synchronized. The 468 response to the NOOP command MUST NOT be relayed back to the client. 469 An implementation MAY wait for the server to return the 200 response 470 to the NOOP and translate that 200 response into the response the ALG 471 is required to return to the client to maintain parity between 472 packets flowing in and out of the ALG. If the server responds with 473 something other than 200 to the NOOP command, the ALG MUST tear down 474 the control channel session and log an error. 476 5. Client recommendations 478 All FTP clients are encouraged to support EPSV when communicating 479 over IPv6 and always attempt to use EPSV mode unless explicitly 480 configured to use EPRT. 482 It is highly recommended that FTP clients react by retrying with PASV 483 when the EPSV command fails, either because of an error response by 484 the server (40x, 42x, 50x and 52x responses), because the data 485 connection couldn't be created or because the control channel session 486 was terminated. When after attempting to initiate EPSV and/or EPRT 487 modes unsuccessfully and a client retries with PASV, the server will 488 respond to the PASV command with an IPv4 address that the client is 489 supposed to use to connect to for the data connection. Even if the 490 client has IPv4 reachability, it is better to ignore the server- 491 supplied address and set up a data connection towards the IPv6 492 address of the server that is used for the control channel session. 493 However, in this case the port number used for the data connection is 494 taken from the 227 response to the PASV command. If a client falls 495 back to PASV after attempting EPSV/EPRT unsuccessfully, a client 496 could cache the name or address of the FTP server and issue PASV 497 rather than EPSV in future sessions. In that case, the cache entry 498 might be cleared if sufficient time has passed that the server may 499 have been updated. The suggested time for removal of a server from 500 this case is 7 days, 1 day when the server indicates EPSV support in 501 its FEAT response where it previously did not. 503 There is always a risk that an error was the result of a condition 504 unrelated to IPv6-to-IPv4 translation. However, retrying with a PASV 505 request has little potential for harm, so unless the error is clearly 506 unrelated, retrying with PASV is the appropriate reaction. 508 The main rationale for ignoring the IPv4 address in the 227 response, 509 even if the client has IPv4 connectivity, is the fact that most 510 servers will only allow a data connection from the same client 511 address as seen in the control channel connection, see [Bernstein]. 512 Using IPv6 for the control channel and IPv4 for the data channel 513 means that the source address will almost certainly be different in 514 both cases, making it unlikely that the data connection can be 515 established successfully. Also, IPv4 reachability towards the 516 server-supplied address may or may not exist, while IPv6 reachability 517 has been established by virtue of the control channel connection. 519 Clients do best to refrain from using any arguments with the EPSV 520 command. "EPSV 2" to request IPv6 will fail across an IPv6-to-IPv4 521 translator. Also, this command is often not handled properly by IPv6 522 servers. "EPSV ALL" indicates that the client will use EPSV for all 523 transfers, but an ALG could translate EPSV commands to PASV commands, 524 conflicting with the earlier "EPSV ALL", so the control channel 525 session can't be continued successfully. 527 6. Server recommendations 529 As EPSV works through IPv6-to-IPv4 translation transparently without 530 additional effort on the part of the client, the server or an 531 application layer gateway, it is highly recommended that all servers 532 implement EPSV. 534 [RFC2428] suggests that the EPSV mode is useful both for clients with 535 IPv6 connectivity and for clients operating behind a NAT device. As 536 such, it is common for IPv6-capable clients to use EPSV even when 537 communicating over IPv4. If a server doesn't implement EPSV and 538 responds with a 501 or 502 error, the client simply retries with 539 PASV. This works well with both servers that have working EPSV and 540 servers that don't implement EPSV. However, there is a class of 541 servers that does implement EPSV, but is unable to use EPSV mode 542 because the data connection can't be established successfully. This 543 is very likely the result of a middlebox monitoring the control 544 channel interactions, and creating firewall or translation state 545 according to the information 227 response after a PASV command. With 546 the EPSV command, there is no 229 response, so if the server supports 547 EPSV but the middlebox doesn't, the result is that the data 548 connection cannot be established and the data transfer fails. 550 To avoid this, it is highly recommended that server implementers 551 include a configuration setting that makes it possible to disable 552 EPSV and EPRT support and respond with a 502 (command not 553 implemented) error instead. Server operators can thus disable EPSV 554 support in servers located behind PASV-only middleboxes so clients 555 that issue EPSV can fall back to PASV gracefully rather than time 556 out. 558 The test performed by Dan Wing showed that existing implementations 559 tend to present the address used for the server side of the control 560 channel connection in the 227 response to a PASV command. Clients 561 following the recommendations in this document depend on this 562 behavior and it allows ALGs to translate a 227 PASV response to a 229 563 EPSV response without loss of information; as such it is highly 564 recommended that servers continue to implement this limitation. 565 Later tests showed that some servers list [RFC1918] addresses in 566 their 227 responses. Many of these servers were known to reside 567 behind NAT devices. In these cases, ignoring the address in the 227 568 response is the desired behavior. 570 Many servers that support the FEAT command do not list EPSV and EPRT 571 as a supported feature in the response to the FEAT command. It is 572 recommended that EPSV and EPRT capability is included in the FEAT 573 response, unless EPSV and/or EPRT are administratively disabled as 574 outlined above. 576 7. IANA considerations 578 None. 580 8. Security considerations 582 In the majority of cases, FTP is used without further security 583 mechanisms. This allows an attacker with passive interception 584 capabilities to obtain the login credentials, and an attacker that 585 can modify packets to change the data transferred. However, FTP can 586 be used with TLS in order to solve these issues. IPv6-to-IPv4 587 translation and the FTP ALG don't impact the security issues in the 588 former case nor the use of TLS in the latter case. However, if FTP 589 is used with TLS or another authentication mechanism, the ALG 590 function is not performed so only passive transfers from a server 591 that implements EPSV or a client that supports PASV will succeed. 593 9. Contributors 595 Kentaro Ebisawa, Remi Denis-Courmont, Mayuresh Bakshi, Sarat 596 Kamisetty, Reinaldo Penno, Alun Jones, Dave Thaler, Mohammed 597 Boucadair, Mikael Abrahamsson, Dapeng Liu and Michael Liu contributed 598 ideas and comments. Dan Wing ran experiments with a large number of 599 FTP servers that were very illuminating; many of the choices 600 underlying this document are based on his results. This document 601 adopts several design decisions from [I-D.liu-behave-ftp64]. 603 10. Acknowledgements 605 Iljitsch van Beijnum is partly funded by Trilogy, a research project 606 supported by the European Commission under its Seventh Framework 607 Program. 609 11. References 611 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 612 Specification", STD 8, RFC 854, May 1983. 614 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 615 STD 9, RFC 959, October 1985. 617 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 618 and Support", STD 3, RFC 1123, October 1989. 620 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 621 E. Lear, "Address Allocation for Private Internets", 622 BCP 5, RFC 1918, February 1996. 624 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 625 Requirement Levels", BCP 14, RFC 2119, March 1997. 627 [RFC2389] Hethmon, P. and R. Elz, "Feature negotiation mechanism for 628 the File Transfer Protocol", RFC 2389, August 1998. 630 [RFC2228] Horowitz, M., "FTP Security Extensions", RFC 2228, 631 October 1997. 633 [RFC2428] Allman, M., Ostermann, S., and C. Metz, "FTP Extensions 634 for IPv6 and NATs", RFC 2428, September 1998. 636 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 637 (SIIT)", RFC 2765, February 2000. 639 [I-D.ietf-behave-v6v4-xlate-stateful] 640 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 641 NAT64: Network Address and Protocol Translation from IPv6 642 Clients to IPv4 Servers", 643 draft-ietf-behave-v6v4-xlate-stateful-11 (work in 644 progress), March 2010. 646 [I-D.ietf-behave-v6v4-xlate] 647 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 648 Algorithm", draft-ietf-behave-v6v4-xlate-05 (work in 649 progress), December 2009. 651 [I-D.liu-behave-ftp64] 652 Liu, D. and Z. Cao, "IPv6 IPv4 translation FTP 653 considerations", draft-liu-behave-ftp64-03 (work in 654 progress), August 2009. 656 [Bernstein] 657 Bernstein, D., "PASV security and PORT security", 2000, 658 . 660 Appendix A. Document and discussion information 662 Please direct questions and comments to the BEHAVE mailinglist. The 663 latest version of this document will always be available at 664 http://www.muada.com/drafts/. 666 Author's Address 668 Iljitsch van Beijnum 669 IMDEA Networks 670 Avda. del Mar Mediterraneo, 22 671 Leganes, Madrid 28918 672 Spain 674 Email: iljitsch@muada.com