idnits 2.17.1 draft-ietf-behave-ftp64-12.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 (July 8, 2011) is 4675 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 6145 (Obsoleted by RFC 7915) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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 Institute IMDEA Networks 4 Internet-Draft July 8, 2011 5 Intended status: Standards Track 6 Expires: January 9, 2012 8 An FTP ALG for IPv6-to-IPv4 translation 9 draft-ietf-behave-ftp64-12 11 Abstract 13 The File Transfer Protocol (FTP) has a very long history, and despite 14 the fact that today other options exist to perform file transfers, 15 FTP is still in common use. As such, it is important that in the 16 situation where some client computers only have IPv6 connectivity 17 while many servers are still IPv4-only and IPv6-to-IPv4 translators 18 are used to bridge that gap, FTP is made to work through these 19 translators to the best possible extent. 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 specifies a middlebox that may solve this mismatch. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 9, 2012. 45 Copyright Notice 47 Copyright (c) 2011 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 4 64 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. ALG overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 5. Control channel translation . . . . . . . . . . . . . . . . . 6 67 5.1. Language negotiation . . . . . . . . . . . . . . . . . . . 7 68 6. EPSV to PASV translation . . . . . . . . . . . . . . . . . . . 8 69 7. EPRT to PORT translation . . . . . . . . . . . . . . . . . . . 10 70 7.1. Stateless EPRT translation . . . . . . . . . . . . . . . . 10 71 7.2. Stateful EPRT translation . . . . . . . . . . . . . . . . 10 72 8. Default port 20 translation . . . . . . . . . . . . . . . . . 11 73 9. Both PORT and PASV . . . . . . . . . . . . . . . . . . . . . . 11 74 10. Default behavior . . . . . . . . . . . . . . . . . . . . . . . 12 75 11. The ALGS command . . . . . . . . . . . . . . . . . . . . . . . 12 76 12. Timeouts and translating to NOOP . . . . . . . . . . . . . . . 14 77 13. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14 78 14. Security considerations . . . . . . . . . . . . . . . . . . . 15 79 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 81 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 17.1. Normative References . . . . . . . . . . . . . . . . . . . 16 83 17.2. Informative References . . . . . . . . . . . . . . . . . . 16 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 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 measures, active mode with a client-supplied port does not 92 work through NATs or firewalls. With active mode, the PORT command 93 has an IPv4 address as its argument, and in passive mode, the server 94 responds to the PASV command with an IPv4 address. This makes both 95 the passive and active modes as originally specified in [RFC0959] 96 incompatible with IPv6. These issues were solved in [RFC2428], which 97 introduces the EPSV (extended passive) command, where the server only 98 responds with a port number, and the EPRT (extended port) command, 99 which allows the client to supply either an IPv4 or an IPv6 address 100 (and a port) to the server. 102 A survey done in April of 2009 of 25 randomly picked and/or well- 103 known FTP sites reachable over IPv4 showed that only 12 of them 104 supported EPSV over IPv4. Additionally, only 2 of those 12 indicated 105 that they supported EPSV in response to the FEAT command introduced 106 in [RFC2389] that asks the server to list its supported features. 107 One supported EPSV but not FEAT. In 5 cases, issuing the EPSV 108 command to the server led to a significant delay, in 3 cases followed 109 by a control channel reset. Due to lack of additional information, 110 it is impossible to determine conclusively why certain FTP servers 111 reset the control channel connection some time after issueing an EPSV 112 command. However, a reasonable explanation would be that these FTP 113 servers are located behind application-aware firewalls which monitor 114 the control channel session and only allow the creation of data 115 channel sessions to the ports listed in the responses to PASV (and 116 Maybe PORT) commands. As the response to an EPSV command is 117 different (a 229 code rather than a 227 code), a firewall that is 118 unaware of the EPSV command would block the subsequent data channel 119 setup attempt. When after some time no data channel connection has 120 been established, the FTP server may decide to terminate the control 121 channel session in an attempt to leave this ambiguous state. 123 All 25 tested servers were able to successfully complete a transfer 124 in traditional PASV passive mode as required by [RFC1123]. More 125 testing showed that the use of an address family argument with the 126 EPSV command is widely mis- or unimplemented in servers. The 127 additional tests with more servers showed that approximately 65% of 128 FTP servers support EPSV successfully and around 96% support PASV 129 successfully. Clients were not extensively tested, but previous 130 experience from the author suggests that most clients support PASV, 131 with the notable exception of the command line client included with 132 Windows, which only supports active mode. This FTP client uses the 133 original PORT command when running over IPv4 and EPRT when running 134 over IPv6. 136 Although these issues can and should be addressed by modifying 137 clients and servers to support EPSV successfully, such modifications 138 may not appear widely in a timely fashion. Also, network operators 139 who may want to deploy IPv6-to-IPv4 translation generally don't have 140 control over client or server implementations. As such, this 141 document standardizes an FTP Application Layer Gateway (ALG) that 142 will allow unmodified IPv6 FTP clients to interact with unmodified 143 IPv4 FTP servers successfully when using FTP for simple file 144 transfers between a single client and a single server. 146 Clients that want to engage in more complex behavior, such as server- 147 to-server transfers, may make an FTP application layer gateway (ALG) 148 go into transparent mode by issuing the ALGS command as explained in 149 Section 5. 151 The recommendations and specifications in this document apply to all 152 forms of IPv6-to-IPv4 translation, including stateless translation 153 such as [RFC6145] as well as stateful translation such as [RFC6146]. 155 This documentation does not deal with the LPRT and LPSV commands 156 specified in [RFC1639] as these commands do not appear to be in 157 significant use. 159 2. Notational Conventions 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in [RFC2119]. 165 3. Terminology 167 Within the context of this document, the words "client" and "server" 168 refer to FTP client and server implementations, respectively. An FTP 169 server is understood to be an implementation of the FTP protocol 170 running on a server system with a stable address, waiting for clients 171 to connect and issue commands that eventually start data transfers. 172 Clients interact with servers using the FTP protocol, and store 173 (upload) files to, and retrieve (download) files from one or more 174 servers. This either happens interactively under control of a user, 175 or is done as an unattended background process. Most operating 176 systems provide a web browser that implements a basic FTP client, as 177 well as a command line client. Third-party FTP clients are also 178 widely available. 180 Other terminology is derived from the documents listed in the 181 references 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 overview 187 The most robust way to solve an IP version mismatch between FTP 188 clients and FTP servers would be by changing clients and servers 189 rather than using an IPv6-to-IPv4 translator for the data channel and 190 using an application layer gateway on the control channel. As such, 191 it is recommended to update FTP clients and servers as required for 192 IPv6-to-IPv4 translation support where possible, to allow proper 193 operation of the FTP protocol without the need for ALGs. 195 On the other hand, network operators or even network administrators 196 within an organization often have little influence over the FTP 197 client and server implementations used over the network. For those 198 operators and administrators, deploying an ALG may be the only way to 199 provide a satisfactory customer experience. So, even though not the 200 preferred solution, this document standardizes the functionality of 201 such an ALG in order to promote consistent behavior between ALGs in 202 an effort to minimize their harmful effects. 204 Operators and administrators are encouraged to only deploy an FTP ALG 205 for IPv6-to-IPv4 translation when the FTP ALG is clearly needed. In 206 the presence of the ALG, EPSV commands that could be handled directly 207 by conforming servers are translated into PASV commands, introducing 208 additional complexity and reducing robustness. As such a "set and 209 forget" policy on ALGs is not recommended. 211 Note that the translation of EPSV through all translators and EPRT 212 through a stateless translator is relatively simple but supporting 213 translation of EPRT through a stateful translator is relatively 214 difficult, because in the latter case a translation mapping must be 215 set up for each data transfer using parameters that must be learned 216 from the client/server interaction over the control channel. This 217 needs to happen before the EPRT command can be translated into a PORT 218 command and passed on to the server. As such, an ALG used with a 219 stateful translator MUST support EPSV translation and MAY support 220 EPRT translation. However, an ALG used with a stateless translator 221 MUST support EPSV translation and SHOULD also support EPRT 222 translation. 224 The ALG functionality is described as a function separate from the 225 IPv6-to-IPv4 translation function. However, in the case of EPRT 226 translation, the ALG and translator functions need to be tightly 227 coupled, so if EPRT translation is supported, it is assumed that the 228 ALG and IPv6-to-IPv4 translation functions are integrated within a 229 single device. 231 5. Control channel translation 233 The IPv6-to-IPv4 FTP ALG intercepts all TCP sessions towards port 21 234 for IPv6 destination addresses that map to IPv4 destinations 235 reachable through an IPv6-to-IPv4 translator. The FTP ALG implements 236 the Telnet protocol ([RFC0854]) used for control channel interactions 237 to the degree necessary to interpret commands and responses and re- 238 issue those commands and responses, modifying them as outlined below. 239 Telnet option negotiation attempts by either the client or the 240 server, except for those allowed by [RFC1123], MUST be refused by the 241 FTP ALG without relaying those attempts. For the purpose of Telnet 242 option negotiation, an FTP ALG MUST follow the behavior of an FTP 243 server as specified in [RFC1123] section 4.1.2.12. This avoids the 244 situation where the client and the server negotiate Telnet options 245 that are unimplemented by the FTP ALG. 247 There are two ways to implement the control channel ALG: 249 1. The ALG terminates the IPv6 TCP session, sets up a new IPv4 TCP 250 session towards the IPv4 FTP server, and relays commands and 251 responses back and forth between the two sessions. 253 2. Packets that are part of the control channel are translated 254 individually. 256 As they ultimately provide the same result, either implementation 257 strategy, or any other that is functionally equivalent, can be used. 259 In the second case, an implementation MUST have the ability to track 260 and update TCP sequence numbers when translating packets as well as 261 the ability to break up packets into smaller packets after 262 translation, as the control channel translation could modify the 263 length of the payload portion of the packets in question. Also, FTP 264 commands/responses or Telnet negotiations could straddle packet 265 boundaries, so in order to be able to perform the ALG function, it 266 can prove necessary to reconstitute Telnet negotiations and FTP 267 commands and responses from multiple packets. 269 Some FTP clients use the TCP urgent data feature when interrupting 270 transfers. An ALG MUST either maintain the semantics of the urgent 271 pointer when translating control channel interactions, even when 272 crossing packet boundaries, or clear the URG bit in the TCP header. 274 If the client issues the AUTH command, then the client is attempting 275 to negotiate [RFC2228] security mechanisms which are likely to be 276 incompatible with the FTP ALG function. For instance, if the client 277 attempts to negotiate TLS protection of the control channel 278 ([RFC4217], an ALG can do one of three things: 280 1. Transparently copy data transmitted over the control channel back 281 and forth, so the TLS session works as expected but the client 282 commands and server responses are now hidden from the ALG. 284 2. Block the negotiation of additional security, which will likely 285 make the client and/or the server break off the session, or if 286 not, perform actions in the clear that were supposed to be 287 encrypted. 289 3. Negotiate with both the client and the server so two separate 290 protected sessions are set up and the ALG is still able to modify 291 client commands and server responses. Again, clients and servers 292 are likely to reject the session because this will be percieved 293 as a man-in-the-middle attack. 295 An ALG MUST adopt the first option, and allow a client and a server 296 to negotiate security mechanisms. To ensure consistent behavior, as 297 soon as the initial AUTH command is issued by the client, an ALG MUST 298 stop translating commands and responses, and start transparently 299 copying back and forth TCP data sent by the client and the server. 300 The ALG SHOULD ignore the AUTH command and not go into transparent 301 mode if the server response is in the 4xx or 5xx ranges. 303 It is possible that commands or responses that were sent through the 304 ALG before the AUTH command was issued were changed in length so TCP 305 sequence numbers in packets entering the ALG and packets exiting the 306 ALG no longer match. In transparent mode, the ALG MUST continue to 307 adjust sequence numbers if it was doing so before entering 308 transparent mode as the result of the AUTH command. The ALGS command 309 (Section 11) can also be used to disable the ALG functionality, but 310 the control channel MUST then still be monitored for subsequent ALGS 311 commands that re-enable the ALG functionality. 313 5.1. Language negotiation 315 [RFC2640] specifies the ability for clients and servers to negotiate 316 the language used between the two of them in the descriptive text 317 that accompanies server response codes. Ideally, IPv6-to-IPv4 FTP 318 ALGs would support this feature, so that if a non-default language is 319 negotiated by a client and a server, the ALG also transmits its text 320 messages for translated responses in the negotiated language. 321 However, even if the ALG supports negotiation of the feature, there 322 is no way to make sure that the ALG has text strings for all possible 323 languages. So the situation where the client and server try to 324 negotiate a language that the ALG doesn't support can't be avoided. 325 The proper behavior for an FTP ALG in this situation may be addressed 326 in a future specification, as the same issue is present in IPv4-to- 327 IPv4 FTP ALGs. For the time being, ALG implementations MAY employ 328 one of the following strategies regarding LANG negotiation: 330 1. Monitor LANG negotiation, and send text in the negotiated 331 language if text in that language is available. If not, text is 332 sent in the default language. 334 2. Not monitor LANG negotiation. Text is sent in the default 335 language. 337 3. Block LANG negotiation by translating the LANG command to a NOOP 338 command, and translating the resulting 200 response into a 502 339 response, which is appropriate for unsupported commands. Text is 340 sent in the default language. 342 In the first two cases, if a language is negotiated, text transmitted 343 by the client or the server MUST be assumed to be encoded in UTF-8 344 rather than be limited to 7-bit ASCII. An ALG that implements the 345 first or second option MUST translate and/or forward commands and 346 responses containing UTF-8 encoded text when those occur. The ALG 347 itself MUST NOT generate characters outside the 7-bit ASCII range 348 unless it implements the first option and a language was negotiated. 350 Note that section 3.1 of [RFC2640] specifies new handling for spaces 351 and the CR character in path names. ALGs that don't block LANG 352 negotiation SHOULD comply with the specified rules for path handling. 353 Implementers should especially note that the NUL (%x00) character is 354 used as an escape whenever a CR character occurs in a pathname. 356 In the sections that follow, a number of well-known response numbers 357 are shown, along with the descriptive text that is associated with 358 that response number. However, this text is not part of the 359 specification of the response. As such, implementations MAY use the 360 response text shown or they MAY show a different response text for a 361 given response number. Requirements language only applies to the 362 response number. 364 6. EPSV to PASV translation 366 Although many IPv4 FTP servers support the EPSV command, some servers 367 react adversely to this command (see Section 1 for examples), and 368 there is no reliable way to detect in advance that this will happen. 370 As such, an FTP ALG SHOULD translate all occurrences of the EPSV 371 command issued by the client to the PASV command, and reformat a 227 372 response as a corresponding 229 response. However, an ALG MAY forego 373 EPSV to PASV translation if it has positive knowledge, either through 374 administrative configuration or learned dynamically, that EPSV will 375 be successful without translation to PASV. 377 For instance, if the client issues EPSV (or EPSV 2 to indicate IPv6 378 as the network protocol), this is translated to the PASV command. If 379 the server with address 192.0.2.31 then responds with: 381 227 Entering Passive Mode (192,0,2,31,237,19) 383 The FTP ALG reformats this as: 385 229 Entering Extended Passive Mode (|||60691|) 387 The ALG SHOULD ignore the IPv4 address in the server's 227 response. 388 This is the behavior that is exhibited by most clients and is needed 389 to work with servers that include [RFC1918] addresses in their 227 390 responses. However, if the 227 response contains an IPv4 address 391 that does not match the destination of the control channel, the FTP 392 ALG MAY send a 425 response to the client instead of the 229 393 response, e.g.: 395 425 Can't open data connection 397 It is important that the response is in the 4xx range to indicate a 398 temporary condition. 400 If the client issues an EPSV command with a numeric argument other 401 than 2, the ALG MUST NOT pass the command on to the server, but 402 rather respond with a 522 error, e.g.: 404 522 Network protocol not supported 406 If the client issues EPSV ALL, the FTP ALG MUST NOT pass this command 407 to the server, but respond with a 504 error, e.g.: 409 504 Command not implemented for that parameter 411 This avoids the situation where an FTP server reacts adversely to 412 receiving a PASV command after the client used the EPSV ALL command 413 to indicate that it will only use EPSV during this session. 415 7. EPRT to PORT translation 417 Should the IPv6 client issue an EPRT command, the FTP ALG MAY 418 translate this EPRT command to a PORT command. The translation is 419 different depending on whether the translator is a stateless one-to- 420 one translator or a stateful one-to-many translator. 422 7.1. Stateless EPRT translation 424 If the address specified in the EPRT command is the IPv6 address used 425 by the client for the control channel session, then the FTP ALG 426 reformats the EPRT command into a PORT command with the IPv4 address 427 that maps to the client's IPv6 address. The port number MUST be 428 preserved for compatibility with stateless translators. For 429 instance, if the client with IPv6 address 2001:db8:2::31 issues the 430 following EPRT command: 432 EPRT |2|2001:db8:2::31|5282| 434 Assuming the IPv4 address that goes with 2001:db8:2::31 is 435 192.0.2.31, the FTP ALG reformats this as: 437 PORT 192,0,2,31,20,162 439 If the address specified in the EPRT command is an IPv4 address or an 440 IPv6 address that is not the IPv6 address used by the client for the 441 control session, the ALG SHOULD NOT attempt any translation, but pass 442 along the command unchanged. 444 7.2. Stateful EPRT translation 446 If the address in the EPRT command is the IPv6 address used by the 447 client for the control channel, the stateful translator selects an 448 unused port number in combination with the IPv4 address used for the 449 control channel towards the FTP server, and sets up a mapping from 450 that transport address to the one specified by the client in the EPRT 451 command. The PORT command with the IPv4 address and port used on the 452 IPv4 side of the mapping is only issued towards the server once the 453 mapping is created. Initially, the mapping is such that either any 454 transport address or the FTP server's IPv4 address with any port 455 number is accepted as a source, but once the three-way handshake is 456 complete, the mapping SHOULD be narrowed to only match the negotiated 457 TCP session. 459 If the address specified in the EPRT command is an IPv4 address or an 460 IPv6 address that is not the IPv6 address used by the client for the 461 control session, the ALG SHOULD NOT attempt any translation, but pass 462 along the command unchanged. 464 If the client with IPv6 address 2001:db8:2::31 issues the EPRT 465 command: 467 EPRT |2|2001:db8:2::31|5282| 469 And the stateful translator uses the address 192.0.2.31 on its IPv4 470 interface, a mapping with destination address 192.0.2.31 and 471 destination port 60192 towards 2001:db8:2::31 port 5282 may be 472 created, after which the FTP ALG reformats the EPRT command as: 474 PORT 192,0,2,31,235,32 476 8. Default port 20 translation 478 If the client does not issue an EPSV/PASV or EPRT/PORT command prior 479 to initiating a file transfer, it is invoking the default active FTP 480 behavior where the server sets up a TCP session towards the client. 481 In this situation, the source port number is the default FTP data 482 port (port 20) and the destination port is the port the client uses 483 as the source port for the control channel session. 485 In the case of a stateless translator, this does not pose any 486 problems. In the case of a stateful translator, the translator MAY 487 accept incoming connection requests from the server on the IPv4 side 488 if the transport addresses match that of an existing FTP control 489 channel session, with the exception that the control channel session 490 uses port 21 and the new session port 20. In this case, a mapping is 491 set up towards the same transport address on the IPv6 side that is 492 used for the matching FTP control channel session. 494 An ALG/translator MAY monitor the progress of FTP control channels 495 and only attempt to perform a mapping when an FTP client has started 496 a file transfer without issuing the EPSV, PASV, EPRT or PORT 497 commands. 499 9. Both PORT and PASV 501 [RFC0959] allows a client to issue both PORT and PASV to use non- 502 default ports on both sides of the connection. However, this is 503 incompatible with the notion that with PASV, the data connection is 504 made from the client to the server, while PORT reaffirms the default 505 behavior where the server connects to the client. As such, the 506 behavior of an ALG is undefined when a client issues both PASV and 507 PORT. Implementations SHOULD NOT try to detect the situation where 508 both PASV and PORT commands are issued prior to a command that 509 initiates a transfer, but rather, translate commands as they occur. 511 So if a client issues PASV, PASV is then translated to EPSV. If 512 after that, before any transfers have occurred, the client issues 513 PORT and the ALG supports PORT translation for this session, the ALG 514 translates PORT to EPRT. 516 10. Default behavior 518 Whenever the client issues a command which the ALG is not set up to 519 translate, either because the command is not specified in this 520 document, the command is not part of any FTP specification, the ALG 521 functionality is disabled administratively for the command in 522 question, or translation does not apply for any other reason, the 523 command MUST be passed on to the server without modification, and the 524 server response MUST be passed on to the client without modification. 525 For example, if the client issues the PASV command, this command is 526 passed on to the server transparently, and the server's response to 527 the client. 529 11. The ALGS command 531 ALGs MUST support the new ALGS (ALG status) command that allows 532 clients to query and set the ALG's status. FTP servers (as opposed 533 to ALGs) MUST NOT perform any actions upon receiving the ALGS 534 command. FTP servers MUST still send a response, however. If FTP 535 servers recognize the ALGS command, the best course of action would 536 be to return a 202 response: 538 202 Command not implemented, superfluous at this site 540 However, there is no reason for FTP servers to specifically recognize 541 this command; returning any 50x response that is normally returned 542 when commands are not recognized is appropriate. 544 A client can use the ALGS command to request the ALG's status and to 545 enable and disable EPSV to PASV translation and, if implemented, EPRT 546 to PORT translation. There are three possible arguments to the ALGS 547 command: 549 ALGS STATUS64 550 The ALG is requested to return the EPSV and EPRT 551 translation status. 553 ALGS ENABLE64 554 The ALG is requested to enable translation. 556 ALGS DISABLE64 557 The ALG is requested to disable translation. 559 The ALG MUST enable or disable EPSV to PASV translation as requested. 560 If EPRT to PORT translation is supported, ALGS ENABLE64 SHOULD enable 561 it and ALGS DISABLE64 MUST disable it along with enabling or 562 disabling EPSV to PASV translation, respectively. If EPRT to PORT 563 translation is not supported, ALGS ENABLE64 only enables EPSV to PASV 564 translation. After an ALGS command with any of the three supported 565 arguments, the ALG MUST return a 216 response indicating the type of 566 translation that will be performed. 568 216 NONE 569 Neither EPSV nor EPRT translation is performed. 571 216 EPSV 572 EPSV is translated to PASV, no EPRT translation is 573 performed. 575 216 EPRT 576 EPRT is translated to PORT, no EPSV translation is 577 performed. 579 216 EPSVEPRT 580 EPSV is translated to PASV, EPRT is translated to 581 PORT. 583 The translation type MAY be followed by a space and additional 584 descriptive text until end-of-line. If the ALG is unable to set the 585 requested translation mode, for instance, because of lack of certain 586 resources, this is not considered an error condition. In those 587 cases, the ALG responds with a 216 response followed by the keyword 588 that indicates the current translation status of the ALG. 590 If there is no argument to the ALGS command, or the argument is not 591 one of STATUS64, ENABLE64 or DISABLE64 (or an argument specified by a 592 supported newer document), a 504 or 502 error SHOULD be returned. 594 The Augmented Backus-Naur Form (ABNF) notation (see [RFC5234]) of the 595 ALGS command and its response are as follows: 597 algs-command = "ALGS" SP algs-token CRLF 598 algs-token = "STATUS64" / "ENABLE64" / "DISABLE64" 600 algs-response = (ok-response / error-response) CRLF 601 ok-response = "216" SP response-token [ freetext ] 602 response-token = "NONE" / "EPSV" / "EPRT" / "EPSVEPRT" 603 error-response = not-implemented / invalid-parameter 604 not-implemented = "502" [ freetext ] 605 invalid-parameter = "504" [ freetext ] 606 freetext = (SP *VCHAR) 608 12. Timeouts and translating to NOOP 610 Wherever possible, control channels SHOULD NOT time out while there 611 is an active data channel. A timeout of at least 30 seconds is 612 RECOMMENDED for data channel mappings created by the FTP ALG that are 613 waiting for initial packets. 615 Whenever a command from the client is not propagated to the server, 616 the FTP ALG instead issues a NOOP command in order to keep the 617 keepalive state between the client and the server synchronized. The 618 response to the NOOP command MUST NOT be relayed back to the client. 619 An implementation MAY wait for the server to return the 200 response 620 to the NOOP command and translate that 200 response into the response 621 the ALG is required to return to the client. This way, the ALG never 622 has to create new packets to send to the client, but it can limit 623 itself to modifying packets transmitted by the server. If the server 624 responds with something other than 200 to the NOOP command, the ALG 625 SHOULD tear down the control channel session and log an error. 627 13. IANA considerations 629 IANA is requested to add to the FTP Commands and Extensions registry 630 the following entry: 632 Command Name 633 ALGS 635 FEAT Code 636 -N/A- 638 Description 639 FTP64 ALG status 641 Command Type 642 -N/A- 644 Conformance Requirements 645 o 647 Reference 648 RFC TBD Section 11 650 [TO BE REMOVED: This registration should take place at the following 651 location: http://www.iana.org/assignments/ftp-commands-extensions/ 652 ftp-commands-extensions.xhtml] 654 14. Security considerations 656 In the majority of cases, FTP is used without further security 657 mechanisms. This allows an attacker with passive interception 658 capabilities to obtain the login credentials, and an attacker that 659 can modify packets to change the data transferred. However, FTP can 660 be used with TLS in order to solve these issues. IPv6-to-IPv4 661 translation and the FTP ALG do not impact the security issues in the 662 former case nor the use of TLS in the latter case. However, if FTP 663 is used with TLS as per [RFC4217], or another authentication 664 mechanism that the ALG is aware of, the ALG function is not performed 665 so only passive transfers from a server that implements EPSV or a 666 client that supports PASV will succeed. 668 For general FTP security considerations, see [RFC2577]. 670 15. Contributors 672 Dan Wing, Kentaro Ebisawa, Remi Denis-Courmont, Mayuresh Bakshi, 673 Sarat Kamisetty, Reinaldo Penno, Alun Jones, Dave Thaler, Mohammed 674 Boucadair, Mikael Abrahamsson, Dapeng Liu, Michael Liu, Andrew 675 Sullivan, Anthony Bryan, Ed Jankiewicz Pekka Savola, Fernando Gont, 676 Rockson Li and Donald Eastlake contributed ideas and comments. Dan 677 Wing ran experiments with a large number of FTP servers that were 678 very illuminating; many of the choices underlying this document are 679 based on his results. 681 16. Acknowledgements 683 Iljitsch van Beijnum is partly funded by Trilogy, a research project 684 supported by the European Commission under its Seventh Framework 685 Program. 687 17. References 689 17.1. Normative References 691 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 692 Specification", STD 8, RFC 854, May 1983. 694 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 695 STD 9, RFC 959, October 1985. 697 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 698 and Support", STD 3, RFC 1123, October 1989. 700 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 701 Requirement Levels", BCP 14, RFC 2119, March 1997. 703 [RFC2228] Horowitz, M., "FTP Security Extensions", RFC 2228, 704 October 1997. 706 [RFC2428] Allman, M., Ostermann, S., and C. Metz, "FTP Extensions 707 for IPv6 and NATs", RFC 2428, September 1998. 709 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 710 Specifications: ABNF", STD 68, RFC 5234, January 2008. 712 17.2. Informative References 714 [RFC1639] Piscitello, D., "FTP Operation Over Big Address Records 715 (FOOBAR)", RFC 1639, June 1994. 717 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 718 E. Lear, "Address Allocation for Private Internets", 719 BCP 5, RFC 1918, February 1996. 721 [RFC2389] Hethmon, P. and R. Elz, "Feature negotiation mechanism for 722 the File Transfer Protocol", RFC 2389, August 1998. 724 [RFC2577] Allman, M. and S. Ostermann, "FTP Security 725 Considerations", RFC 2577, May 1999. 727 [RFC2640] Curtin, B., "Internationalization of the File Transfer 728 Protocol", RFC 2640, July 1999. 730 [RFC4217] Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217, 731 October 2005. 733 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 734 Algorithm", RFC 6145, April 2011. 736 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 737 NAT64: Network Address and Protocol Translation from IPv6 738 Clients to IPv4 Servers", RFC 6146, April 2011. 740 Author's Address 742 Iljitsch van Beijnum 743 Institute IMDEA Networks 744 Avda. del Mar Mediterraneo, 22 745 Leganes, Madrid 28918 746 Spain 748 Email: iljitsch@muada.com