idnits 2.17.1 draft-ietf-behave-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 : ---------------------------------------------------------------------------- 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 (May 14, 2010) is 5096 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 informational reference (is this intentional?): 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 Summary: 0 errors (**), 0 flaws (~~), 4 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 14, 2010 5 Intended status: Standards Track 6 Expires: November 15, 2010 8 IPv6-to-IPv4 translation FTP considerations 9 draft-ietf-behave-ftp64-02 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 do not support this mode, and some clients do not 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 15, 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. The ALGS command . . . . . . . . . . . . . . . . . . . . . 10 76 4.8. Timeouts and translating to NOOP . . . . . . . . . . . . . 12 77 5. Client recommendations . . . . . . . . . . . . . . . . . . . . 12 78 6. Server recommendations . . . . . . . . . . . . . . . . . . . . 13 79 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14 80 8. Security considerations . . . . . . . . . . . . . . . . . . . 14 81 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 85 11.2. Informative References . . . . . . . . . . . . . . . . . . 15 86 Appendix A. Document and discussion information . . . . . . . . . 16 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 89 1. Introduction 91 [RFC0959] specifies two modes of operation for FTP: active mode, in 92 which the server connects back to the client and passive mode, where 93 the server opens a port for the client to connect to. Without 94 additional action, active mode with a client-supplied port does not 95 work through NATs or firewalls. With active mode, the PORT command 96 has an IPv4 address as its argument, and in passive mode, the server 97 responds to the PASV command with an IPv4 address. This makes both 98 the passive and active modes as originally specified in [RFC0959] 99 incompatible with IPv6. These issues were solved in [RFC2428], which 100 introduces the EPSV (extended passive) command, where the server only 101 responds with a port number, and the EPRT (extended port) command, 102 which allows the client to supply either an IPv4 or an IPv6 address 103 (and a port) to the server. 105 A survey done in April of 2009 of 25 randomly picked and/or well- 106 known FTP sites reachable over IPv4 showed that only 12 of them 107 supported EPSV over IPv4. Additionally, only 2 of those 12 indicated 108 that they supported EPSV in response to the FEAT command introduced 109 in [RFC2389] that asks the server to list its supported features. 110 One supported EPSV but not FEAT. In 5 cases, issuing the EPSV 111 command to the server led to a significant delay, in 3 cases followed 112 by a control channel reset. All 25 servers were able to successfully 113 complete a transfer in traditional passive PASV mode as required by 114 [RFC1123]. More tests showed that the use of an address family 115 argument with the EPSV command is widely mis- or unimplemented in 116 servers. The additional tests with more servers showed that 117 approximately 65% of FTP servers support EPSV successfully and around 118 96% support PASV successfully. Clients were not extensively tested, 119 but previous experience from the author suggests that most clients 120 support PASV, with the notable exception of the command line client 121 included with Windows, which only supports active mode. This FTP 122 client uses the original PORT command when running over IPv4 and EPRT 123 when running over IPv6. 125 Considering the above, this document describes the following 126 recommendations: 128 Servers: 130 * Allow EPSV (even for IPv4-only servers) 132 * Use a predictable address in the response to the PASV command 134 Clients: 136 * Use EPSV over IPv6 rather than EPRT 138 * Fall back to PASV if EPSV fails (even over IPv6) 140 * Do not use certain modes and options that trigger server bugs 142 Additionally, the document standardizes behavior for application 143 layer gateway functionality to provide connectivity between unupdated 144 servers and/or clients. Clients that want to engage in more complex 145 behavior, such as server-to-server transfers, may make an FTP ALG go 146 into transparent mode by issuing an AUTH command as explained in 147 Section 4.1. 149 The recommendations and specifications in this document apply to all 150 forms of IPv6-to-IPv4 translation, including stateless translation 151 such as [RFC2765] or [I-D.ietf-behave-v6v4-xlate] as well as stateful 152 translation such as [I-D.ietf-behave-v6v4-xlate-stateful]. 154 The FTP protocol allows for complex interactions, such as the 155 situation where a client connects to two servers and directs the 156 servers to exchange data between them. No attempt is made to address 157 these other than through making ALGs transparent after an AUTH 158 command. 160 2. Notational Conventions 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in [RFC2119]. 166 3. Terminology 168 Within the context of this document, the words "client" and "server" 169 refer to FTP client and server implementations, respectively. An FTP 170 server is understood to be an implementation of the FTP protocol 171 running on a server system with a stable address, waiting for clients 172 to connect and issue commands and start data transfers. Clients 173 interact with servers using the FTP protocol, and store (upload 174 files) to or retrieve (download files) from one or more servers, 175 either interactively under control of a user, or as an unattended 176 background process. Most operating systems provide a web browser 177 that implements a basic FTP client, as well as a command line client. 178 Third-party FTP clients are also widely available. 180 Other terminology is derived from the documents listed in the 181 reference section. Note that this document cannot be fully 182 understood on its own; it depends on background and terminology 183 outlined in the references. 185 4. ALG functionality 187 Many within the IETF community argue that an IP version mismatch 188 between FTP clients and FTP servers is better solved by changing 189 clients and servers rather than using a translator. As such, it is 190 recommended to update FTP clients and servers as required for IPv6- 191 to-IPv4 translation support where possible, to allow proper operation 192 of the FTP protocol without the need for ALGs. 194 On the other hand, network operators often have little influence over 195 the FTP clients their customers run, let alone the FTP servers used 196 throughout the Internet. For those operators, deploying an ALG may 197 be the only way to provide a satisfactory customer experience. So, 198 even though not the preferred solution, this document standardizes 199 the functionality of such an ALG in order to promote consistent 200 behavior between ALGs in an effort to minimize their harmful effects. 202 Operators are encouraged to only deploy an FTP ALG for IPv6-to-IPv4 203 translation when the FTP ALG is clearly needed. In the presence of 204 the ALG, EPSV commands that could be handled directly by conforming 205 servers are translated into PASV commands, introducing unnecessary 206 complexity and reducing robustness. As such a "set and forget" 207 policy on ALGs is not recommended. 209 Note that the translation of EPSV through all translators and EPRT 210 through a stateless translator is relatively simple and translation 211 of EPRT through a stateful translator relatively difficult because a 212 translation mapping must be set up. This needs to happen before the 213 EPRT command can be translated into a PORT command and passed on to 214 the server. As such, an ALG used with a stateful translator MUST 215 support EPSV and MAY support EPRT. However, an ALG used with a 216 stateless translator SHOULD also support EPRT. 218 The ALG functionality is described as a function separate from the 219 IPv6-to-IPv4 translation function. However, in the case of EPRT 220 translation, the ALG and translator functions need to be tightly 221 coupled, so in EPRT translation is supported, it is assumed that the 222 ALG and IPv6-to-IPv4 translation functions are integrated within a 223 single device. 225 4.1. Control channel translation 227 The IPv6-to-IPv4 FTP ALG intercepts all TCP sessions towards IPv4 228 port 21 destinations. The FTP ALG implements the Telnet protocol 229 ([RFC0854]) used for control channel interactions to the degree 230 necessary to interpret commands and responses and re-issue those 231 commands and responses, modifying them as outlined below. Telnet 232 option negotiation attempts by either the client or the server, 233 except for those allowed by [RFC1123], MUST be rejected by the FTP 234 ALG without relaying those attempts. This avoids the situation where 235 the client and the server negotiate Telnet options unknown to the FTP 236 ALG. 238 There are two ways to implement the control channel ALG: 240 1. The ALG terminates the IPv6 TCP session, sets up a new IPv4 TCP 241 session towards the IPv4 FTP server, and relays commands and 242 responses back and forth between the two sessions. 244 2. Packets that are part of the control channel are translated 245 individually. 247 In the second case, an implementation MUST have the ability to track 248 and update TCP sequence numbers when translating packets and break up 249 packets into smaller packets after translation, as the control 250 channel translation could modify the length of the payload portion of 251 the packets in question. Also, FTP commands/responses or Telnet 252 negotiations could straddle packet boundaries, so in order to be able 253 to perform the ALG function, it can prove necessary to reconstitute 254 Telnet negotiations and FTP commands and responses from multiple 255 packets. 257 If the client issues the AUTH command the client is attempting to 258 negotiate [RFC2228] security mechanisms which are likely to be 259 incompatible with the FTP ALG function. In this situation, the FTP 260 ALG MUST switch to transparently forwarding all data on the control 261 channel in both directions until the end of the control channel 262 session. This requirement applies regardless of the response from 263 the server. In other words, it is the fact that the client attempts 264 the AUTH negotiation that requires the ALG to become transparent, 265 whether or not the attempt is successful. The transparency 266 requirement applies to the commands and responses flowing between the 267 client and the server. It is possible that commands or responses 268 that were sent through the ALG before the AUTH command was issued 269 were changed in length so TCP sequence numbers in packets entering 270 the ALG and packets exiting the ALG no longer match. In transparent 271 mode, the ALG MUST continue to adjust sequence numbers if it was 272 doing so before entering transparent mode as the result of the AUTH 273 command. The ALGS command (Section 4.7) MAY have a similar effect as 274 the AUTH command, depending on the argument used. 276 There have been FTP ALGs for the purpose of making active FTP work 277 through IPv4 NATs for a long time. Another type of ALG would be one 278 that imposes restrictions required by security policies. Multiple 279 ALGs can be implemented as a single entity. If such a multi-purpose 280 ALG forbids the use of the AUTH command for policy reasons, the side 281 effect of making the ALG stop performing the translations described 282 here, as well as other possible interventions related to IPv6-to-IPv4 283 translation, MUST be retained even if the ALG responds to the AUTH 284 command with an error and does not propagate the command to the 285 server. Implementers are further advised that unlike hosts behind an 286 IPv4 NAT, IPv6 hosts using an IPv6-to-IPv4 translator will normally 287 have the ability to execute FTP over IPv6 without interference from 288 the IPv6-to-IPv4 translator or the ALG, so an IPv6-to-IPv4 289 translation FTP ALG is not the best place to implement security 290 policies. 292 4.2. EPSV to PASV translation 294 Although many IPv4 FTP servers support the EPSV command, some servers 295 react adversely to this command, and there is no reliable way to 296 detect in advance that this will happen. As such, an FTP ALG MUST 297 translate all occurrences of the EPSV command issued by the client to 298 the PASV command, and reformat a 227 response as a corresponding 229 299 response. However, an ALG MAY forego EPSV to PASV translation if it 300 has positive knowledge, either trough administrative configuration or 301 learned dynamically, that EPSV will be successful without translation 302 to PASV. 304 For instance, if the client issues EPSV (or EPSV 2 to indicate IPv6 305 as the network protocol), this is translated to the PASV command. If 306 the server with address 192.0.2.31 then responds with: 308 227 Entering Passive Mode (192,0,2,31,237,19) 310 The FTP ALG reformats this as: 312 229 Entering Extended Passive Mode (|||60691|) 314 The ALG SHOULD ignore the IPv4 address in the server's 227 response. 315 This is the behavior that is exhibited by most clients and is needed 316 to work with servers that include [RFC1918] addresses in their 227 317 responses. However, if the 227 response contains an IPv4 address 318 that does not match the destination of the control channel, the FTP 319 ALG MAY send the following response to the client instead of the 229 320 response: 322 425 Can't open data connection. 324 It is important that the response is in the 4xx range to indicate a 325 temporary condition. 327 If the client issues an EPSV command with a numeric argument other 328 than 2, the ALG MUST NOT pass the command on to the server, but 329 rather respond with a 522 error. 331 If the client issues EPSV ALL, the FTP ALG MUST NOT pass this command 332 to the server, but respond with: 334 504 Command not implemented for that parameter. 336 This avoids the situation where an FTP server reacts adversely to 337 receiving a PASV command after the client indicated that it will only 338 use EPSV during this session. 340 4.3. EPRT to PORT translation 342 Should the IPv6 client issue an EPRT command, the FTP ALG MAY 343 translate this EPRT command to a PORT command. The translation is 344 different depending on whether the translator is a stateless one-to- 345 one translator or a stateful one-to-many translator. 347 4.3.1. Stateless EPRT translation 349 If the address specified in the EPRT command is the client's IPv6 350 address, then the FTP ALG reformats the EPRT command into a PORT 351 command with the IPv4 address that maps to the client's IPv6 address. 352 The port number must be preserved for compatibility with stateless 353 translators. For instance, if the client with IPv6 address 2001:db8: 354 2::31 issues EPRT the EPRT command: 356 EPRT |2|2001:db8:2::31|5282| 358 Assuming the IPv4 address that goes with 2001:db8:2::31 is 359 192.0.2.31, the FTP ALG reformats this as: 361 PORT 192,0,2,31,20,162 363 If the address specified in the EPRT command is an IPv4 address or an 364 IPv6 address that is not the client's IPv6 address, the ALG's 365 response is undefined. It may pass along the command unchanged, 366 respond with an error, or attempt to perform an appropriate 367 translation. 369 If the address specified in the EPRT command is an IPv4 address or an 370 IPv6 address that is the client's IPv6 address, but there is no IPv4 371 address that maps to the client's IPv6 address, the ALG responds as 372 follows: 374 425 Can't open data connection. 376 It is important that the response is in the 4xx range to indicate a 377 temporary condition. 379 4.3.2. Stateful EPRT translation 381 If the address in the EPRT command is the IPv6 address of the control 382 channel client's address, the stateful translator selects an unused 383 port number in combination with the IPv4 address used for the control 384 channel towards the FTP server, and sets up a mapping from that 385 transport address to the one specified by the client in the EPRT 386 command. The PORT command with the IPv4 address and port used on the 387 IPv4 side of the mapping is only issued towards the server once the 388 mapping is created. Initially, the mapping is such that either any 389 transport address or the FTP server's IPv4 address with any port 390 number is accepted as a source, but once the three-way handshake is 391 complete, the mapping SHOULD be narrowed to only match the negotiated 392 TCP session. 394 If the address in the EPRT command is not the client's IPv6 address, 395 the ALG's response is undefined. 397 If the client with IPv6 address 2001:db8:2::31 issues the EPRT 398 command: 400 EPRT |2|2001:db8:2::31|5282| 402 And the stateful translator uses the address 192.0.2.31 on its IPv4 403 interface, a mapping with destination address 192.0.2.31 and 404 destination port 60192 towards 2001:db8:2::31 port 5282 might be 405 created, after which the FTP ALG reformats the EPRT command as: 407 PORT 192,0,2,31,235,32 409 4.4. Default port 20 translation 411 If the client does not issue an EPSV/PASV or EPRT/PORT command prior 412 to initiating a file transfer, it is invoking the default active FTP 413 behavior where the server sets up a TCP session towards the client. 414 In this situation, the source port number is the default FTP data 415 port (port 20) and the destination port is the port the client uses 416 as the source port in the control channel session. 418 In the case of a stateless translator, this does not pose any 419 problems. In the case of a stateful translator, the translator 420 SHOULD accept incoming connection requests from the server on the 421 IPv4 side if the transport addresses match that of an existing FTP 422 control channel session, with the exception that the control channel 423 session uses port 21 and the new session port 20. In this case, a 424 mapping is set up towards the same transport address on the IPv6 side 425 that is used for the matching FTP control channel session. 427 Note that if multiple clients are using the IPv6-to-IPv4 to 428 communicate with the same FTP server, and for each client the IPv6- 429 to-IPv4 translator uses the same source address on its IPv4 side, 430 incoming FTP data channel sessions cannot be correlated to the 431 intended IPv6 host unambiguously. In such cases, the IPv6-to-IPv4 432 translator SHOULD refuse the connection establishment attempt by 433 returning a TCP reset packet. An ALG/translator MAY monitor the 434 progress of FTP control channels and only attempt to perform a 435 mapping when an FTP client has started a file transfer without 436 issuing the EPSV, PASV, EPRT or PORT commands. 438 4.5. Both PORT and PASV 440 [RFC0959] allows a client to issue both PORT and PASV to use non- 441 default ports on both sides of the connection. However, this is 442 incompatible with the notion that with PASV, the data connection is 443 made from the client to the server, while PORT reaffirms the default 444 behavior where the server connects to the client. As such, the 445 behavior of an ALG is undefined when a client issues both PASV and 446 PORT. 448 4.6. Default behavior 450 Whenever the client issues a command which the ALG is not set up to 451 translate, either because the command is not mentioned above, the 452 command is not part of any FTP specification, the ALG functionality 453 is disabled administratively or otherwise for the command in 454 question, or translation does not apply for any other reason, the 455 command MUST be passed on to the server without modification, and the 456 server response MUST be passed on to the client without any 457 modification. For example, if the client issues the PASV command, 458 this command is passed on to the server transparently. 460 4.7. The ALGS command 462 ALGs SHOULD support the new ALGS (ALG status) command that allows 463 clients to query and set ALG status. Note that this command MUST NOT 464 be implemented in FTP servers. If the ALGS command is invoked 465 without arguments, the ALG SHOULD answer with a status code that 466 indicates whether EPSV is translated to PASV and/or EPRT is 467 translated to PORT. There are four possible responses: 469 216 NONE 470 Neither EPSV nor EPRT translation is performed. 472 216 EPSV 473 EPSV is translated to PASV, no EPRT translation is 474 performed. 476 216 EPRT 477 EPRT is translated to PORT, no EPSV translation is 478 performed. 480 216 BOTH 481 EPSV is translated to PASV, EPRT is translated to PORT. 483 The four letter translation type MAY be followed by a space and 484 additional descriptive text until end-of-line. If the ALGS command 485 is not implemented, a 502 response SHOULD be returned. 487 A client can also use the ALGS command to request certain translation 488 behavior from the ALG. There are four possible arguments to the ALGS 489 command: 491 ALGS NONE 492 The ALG is requested to perform neither EPSV nor EPRT 493 translation. 495 ALGS EPSV 496 The ALG is requested to perform EPSV to PASV translation, 497 but not EPRT translation. 499 ALGS EPRT 500 The ALG is requested to perform EPRT to PORT translation, 501 but not EPSV translation. 503 ALGS BOTH 504 The ALG is requested to perform both EPSV to PASV and 505 EPRT to PORT translation. 507 The ALG SHOULD set the requested translation mode where possible. If 508 EPSV translation is supported and PORT translation is not, EPRT 509 becomes the equivalent of NONE and BOTH the equivalent of EPSV. 510 After changing the translation modes where possible, the ALG returns 511 a 216 response indicating the now current ALG status as described 512 above. This status can be different from the one requested by the 513 client. 515 4.8. Timeouts and translating to NOOP 517 Wherever possible, control channels should not time out while there 518 is an active data channel. A timeout of at least 30 seconds is 519 recommended for data channel mappings created by the FTP ALG that are 520 waiting for initial packets. 522 Whenever a command from the client is not propagated to the server, 523 the FTP ALG instead issues a NOOP command in order to keep the 524 keepalive state between the client and the server synchronized. The 525 response to the NOOP command MUST NOT be relayed back to the client. 526 An implementation MAY wait for the server to return the 200 response 527 to the NOOP and translate that 200 response into the response the ALG 528 is required to return to the client. This way, the ALG never has to 529 create new packets to send to the client, but it can limit itself to 530 modifying packets transmitted by the server. If the server responds 531 with something other than 200 to the NOOP command, the ALG MUST tear 532 down the control channel session and log an error. 534 5. Client recommendations 536 All FTP clients are encouraged to support EPSV when communicating 537 over IPv6 and always attempt to use EPSV mode unless explicitly 538 configured to use EPRT. 540 It is highly recommended that FTP clients react by retrying with PASV 541 when the EPSV command fails, either because of an error response by 542 the server (40x, 42x, 50x and 52x responses), because the data 543 connection could not be created or because the control channel 544 session was terminated. When after attempting to initiate EPSV 545 and/or EPRT modes unsuccessfully and a client retries with PASV, the 546 server will respond to the PASV command with an IPv4 address that the 547 client is supposed to use to connect to for the data connection. 548 Even if the client has IPv4 reachability, it is better to ignore the 549 server-supplied address and set up a data connection towards the IPv6 550 address of the server that is used for the control channel session. 551 However, in this case the port number used for the data connection is 552 taken from the 227 response to the PASV command as usual. 554 If a client falls back to PASV after attempting EPSV/EPRT 555 unsuccessfully, a client could cache the name or address of the FTP 556 server and issue PASV rather than EPSV in future sessions. In that 557 case, the cache entry might be cleared if sufficient time has passed 558 that the server may have been updated. The suggested time for 559 removal of a server from this case is 7 days, 1 day when the server 560 indicates EPSV support in its FEAT response where it previously did 561 not. 563 There is always a risk that an error was the result of a condition 564 unrelated to IPv6-to-IPv4 translation. However, retrying with a PASV 565 request has little potential for harm, so unless the error is clearly 566 unrelated, retrying with PASV is the appropriate reaction. 568 The main rationale for ignoring the IPv4 address in the 227 response, 569 even if the client has IPv4 connectivity, most servers will only 570 allow a data connection from the same client address as seen in the 571 control channel connection, see [Bernstein]. Using IPv6 for the 572 control channel and IPv4 for the data channel means that the source 573 address will almost certainly be different in both cases, making it 574 unlikely that the data connection can be established successfully. 575 Also, IPv4 reachability towards the server-supplied address may or 576 may not exist, while IPv6 reachability has been established by virtue 577 of the control channel connection. 579 Clients do best to refrain from using any arguments with the EPSV 580 command. "EPSV 2" to request IPv6 will fail across an IPv6-to-IPv4 581 translator. Also, this command is often not handled properly by IPv6 582 servers. "EPSV ALL" indicates that the client will use EPSV for all 583 transfers, but an ALG could translate EPSV commands to PASV commands, 584 conflicting with the earlier "EPSV ALL", so the control channel 585 session cannot be continued successfully. 587 6. Server recommendations 589 As EPSV works through IPv6-to-IPv4 translation transparently without 590 additional effort on the part of the client, the server or an 591 application layer gateway, it is highly recommended that all servers 592 implement EPSV. 594 [RFC2428] suggests that the EPSV mode is useful both for clients with 595 IPv6 connectivity and for clients operating behind a NAT device. 596 Hence, it is common for IPv6-capable clients to use EPSV even when 597 communicating over IPv4. If a server does not implement EPSV and 598 responds with a 501 or 502 error, the client simply retries with 599 PASV. This works well with both servers that have working EPSV and 600 servers that do not implement EPSV. However, there is a class of 601 servers that does implement EPSV, but is unable to use EPSV mode 602 because the data connection cannot be established successfully. This 603 is very likely the result of a middlebox monitoring the control 604 channel interactions, and creating firewall or translation state 605 according to the information 227 response after a PASV command. With 606 the EPSV command, there is a 229 response and no 227 response, so if 607 the server supports EPSV but the middlebox does not, the result is 608 that the data connection cannot be established and the data transfer 609 fails. 611 To avoid this, it is highly recommended that server implementers 612 include a configuration setting that makes it possible to disable 613 EPSV and EPRT support and respond with a 502 (command not 614 implemented) error instead. Server operators can thus disable EPSV 615 support in servers located behind PASV-only middleboxes so clients 616 that issue EPSV can fall back to PASV gracefully rather than time 617 out. 619 The test performed by Dan Wing showed that existing implementations 620 tend to present the address used for the server side of the control 621 channel connection in the 227 response to a PASV command. Clients 622 following the recommendations in this document depend on this 623 behavior and it allows ALGs to translate a 227 PASV response to a 229 624 EPSV response without loss of information; as such it is highly 625 recommended that servers continue to implement this limitation. 626 Later tests showed that some servers list [RFC1918] addresses in 627 their 227 responses. Many of these servers were known to reside 628 behind NAT devices. In these cases, ignoring the address in the 227 629 response is the desired behavior. 631 Many servers that support the FEAT command do not list EPSV and EPRT 632 as a supported feature in the response to the FEAT command. It is 633 recommended that EPSV and EPRT capability is included in the FEAT 634 response, unless EPSV and/or EPRT are administratively disabled as 635 outlined above. 637 7. IANA considerations 639 None. 641 8. Security considerations 643 In the majority of cases, FTP is used without further security 644 mechanisms. This allows an attacker with passive interception 645 capabilities to obtain the login credentials, and an attacker that 646 can modify packets to change the data transferred. However, FTP can 647 be used with TLS in order to solve these issues. IPv6-to-IPv4 648 translation and the FTP ALG do not impact the security issues in the 649 former case nor the use of TLS in the latter case. However, if FTP 650 is used with TLS or another authentication mechanism, the ALG 651 function is not performed so only passive transfers from a server 652 that implements EPSV or a client that supports PASV will succeed. 654 9. Contributors 656 Dan Wing, Kentaro Ebisawa, Remi Denis-Courmont, Mayuresh Bakshi, 657 Sarat Kamisetty, Reinaldo Penno, Alun Jones, Dave Thaler, Mohammed 658 Boucadair, Mikael Abrahamsson, Dapeng Liu and Michael Liu contributed 659 ideas and comments. Dan Wing ran experiments with a large number of 660 FTP servers that were very illuminating; many of the choices 661 underlying this document are based on his results. This document 662 adopts several design decisions from [I-D.liu-behave-ftp64]. 664 10. Acknowledgements 666 Iljitsch van Beijnum is partly funded by Trilogy, a research project 667 supported by the European Commission under its Seventh Framework 668 Program. 670 11. References 672 11.1. Normative References 674 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 675 Specification", STD 8, RFC 854, May 1983. 677 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 678 STD 9, RFC 959, October 1985. 680 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 681 and Support", STD 3, RFC 1123, October 1989. 683 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 684 Requirement Levels", BCP 14, RFC 2119, March 1997. 686 [RFC2389] Hethmon, P. and R. Elz, "Feature negotiation mechanism for 687 the File Transfer Protocol", RFC 2389, August 1998. 689 [RFC2228] Horowitz, M., "FTP Security Extensions", RFC 2228, 690 October 1997. 692 [RFC2428] Allman, M., Ostermann, S., and C. Metz, "FTP Extensions 693 for IPv6 and NATs", RFC 2428, September 1998. 695 11.2. Informative References 697 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 698 E. Lear, "Address Allocation for Private Internets", 699 BCP 5, RFC 1918, February 1996. 701 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 702 (SIIT)", RFC 2765, February 2000. 704 [I-D.ietf-behave-v6v4-xlate-stateful] 705 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 706 NAT64: Network Address and Protocol Translation from IPv6 707 Clients to IPv4 Servers", 708 draft-ietf-behave-v6v4-xlate-stateful-11 (work in 709 progress), March 2010. 711 [I-D.ietf-behave-v6v4-xlate] 712 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 713 Algorithm", draft-ietf-behave-v6v4-xlate-05 (work in 714 progress), December 2009. 716 [I-D.liu-behave-ftp64] 717 Liu, D. and Z. Cao, "IPv6 IPv4 translation FTP 718 considerations", draft-liu-behave-ftp64-03 (work in 719 progress), August 2009. 721 [Bernstein] 722 Bernstein, D., "PASV security and PORT security", 2000, 723 . 725 Appendix A. Document and discussion information 727 Please direct questions and comments to the BEHAVE mailinglist. The 728 latest version of this document will always be available at 729 http://www.muada.com/drafts/. 731 Author's Address 733 Iljitsch van Beijnum 734 IMDEA Networks 735 Avda. del Mar Mediterraneo, 22 736 Leganes, Madrid 28918 737 Spain 739 Email: iljitsch@muada.com