idnits 2.17.1 draft-ietf-behave-ftp64-07.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 (January 28, 2011) is 4836 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) == Unused Reference: 'Bernstein' is defined on line 714, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2765 (Obsoleted by RFC 6145) == Outdated reference: A later version (-23) exists of draft-ietf-behave-v6v4-xlate-05 Summary: 0 errors (**), 0 flaws (~~), 3 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 January 28, 2011 5 Intended status: Standards Track 6 Expires: August 1, 2011 8 An FTP ALG for IPv6-to-IPv4 translation 9 draft-ietf-behave-ftp64-07 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 as 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 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 August 1, 2011. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 5. Control channel translation . . . . . . . . . . . . . . . . . 5 67 5.1. Language negotiation . . . . . . . . . . . . . . . . . . . 7 68 6. EPSV to PASV translation . . . . . . . . . . . . . . . . . . . 8 69 7. EPRT to PORT translation . . . . . . . . . . . . . . . . . . . 9 70 7.1. Stateless EPRT translation . . . . . . . . . . . . . . . . 9 71 7.2. Stateful EPRT translation . . . . . . . . . . . . . . . . 10 72 8. Default port 20 translation . . . . . . . . . . . . . . . . . 10 73 9. Both PORT and PASV . . . . . . . . . . . . . . . . . . . . . . 11 74 10. Default behavior . . . . . . . . . . . . . . . . . . . . . . . 11 75 11. The ALGS command . . . . . . . . . . . . . . . . . . . . . . . 11 76 12. Timeouts and translating to NOOP . . . . . . . . . . . . . . . 13 77 13. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 78 14. Security considerations . . . . . . . . . . . . . . . . . . . 14 79 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 81 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 17.1. Normative References . . . . . . . . . . . . . . . . . . . 15 83 17.2. Informative References . . . . . . . . . . . . . . . . . . 15 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 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. All 25 servers were able to successfully 110 complete a transfer in traditional PASV passive mode as required by 111 [RFC1123]. More testing showed that the use of an address family 112 argument with the EPSV command is widely mis- or unimplemented in 113 servers. The additional tests with more servers showed that 114 approximately 65% of FTP servers support EPSV successfully and around 115 96% support PASV successfully. Clients were not extensively tested, 116 but previous experience from the author suggests that most clients 117 support PASV, with the notable exception of the command line client 118 included with Windows, which only supports active mode. This FTP 119 client uses the original PORT command when running over IPv4 and EPRT 120 when running over IPv6. 122 Although these issues can and should be addressed by modifying 123 clients and servers to support EPSV successfully (see 124 [I-D.liu-ftp64-extension]), such modifications may not appear widely 125 in a timely fashion. Also, network operators who may want to deploy 126 IPv6-to-IPv4 translation generally don't have control over client or 127 server implementations. As such, this document standardizes an FTP 128 Application Layer Gateway (ALG) that will allow unmodified IPv6 FTP 129 clients to interact with unmodified IPv4 FTP servers successfully 130 when using FTP for simple file transfers between a single client and 131 a single server. 133 Clients that want to engage in more complex behavior, such as server- 134 to-server transfers, may make an FTP application layer gateway (ALG) 135 go into transparent mode by issuing AUTH or ALGS commands as 136 explained in Section 5. 138 The recommendations and specifications in this document apply to all 139 forms of IPv6-to-IPv4 translation, including stateless translation 140 such as [RFC2765] or [I-D.ietf-behave-v6v4-xlate] as well as stateful 141 translation such as [I-D.ietf-behave-v6v4-xlate-stateful]. 143 2. Notational Conventions 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 3. Terminology 151 Within the context of this document, the words "client" and "server" 152 refer to FTP client and server implementations, respectively. An FTP 153 server is understood to be an implementation of the FTP protocol 154 running on a server system with a stable address, waiting for clients 155 to connect and issue commands that eventually start data transfers. 156 Clients interact with servers using the FTP protocol, and store 157 (upload) files to, and retrieve (download) files from one or more 158 servers. This either happens interactively under control of a user, 159 or is done as an unattended background process. Most operating 160 systems provide a web browser that implements a basic FTP client, as 161 well as a command line client. Third-party FTP clients are also 162 widely available. 164 Other terminology is derived from the documents listed in the 165 references section. Note that this document cannot be fully 166 understood on its own; it depends on background and terminology 167 outlined in the references. 169 4. ALG overview 171 The most robust way to solve an IP version mismatch between FTP 172 clients and FTP servers would be by changing clients and servers 173 rather than using an IPv6-to-IPv4 translator for the data channel and 174 using an application layer gateway on the control channel. As such, 175 it is recommended to update FTP clients and servers as required for 176 IPv6-to-IPv4 translation support where possible, to allow proper 177 operation of the FTP protocol without the need for ALGs. 179 On the other hand, network operators or even network administrators 180 within an organization often have little influence over the FTP 181 client and server implementations used over the network. For those 182 operators and administrators, deploying an ALG may be the only way to 183 provide a satisfactory customer experience. So, even though not the 184 preferred solution, this document standardizes the functionality of 185 such an ALG in order to promote consistent behavior between ALGs in 186 an effort to minimize their harmful effects. 188 Operators and administrators are encouraged to only deploy an FTP ALG 189 for IPv6-to-IPv4 translation when the FTP ALG is clearly needed. In 190 the presence of the ALG, EPSV commands that could be handled directly 191 by conforming servers are translated into PASV commands, introducing 192 additional complexity and reducing robustness. As such a "set and 193 forget" policy on ALGs is not recommended. 195 Note that the translation of EPSV through all translators and EPRT 196 through a stateless translator is relatively simple but supporting 197 translation of EPRT through a stateful translator is relatively 198 difficult, because in the latter case a translation mapping must be 199 set up for each data transfer using parameters that must be learned 200 from the client/server interaction over the control channel. This 201 needs to happen before the EPRT command can be translated into a PORT 202 command and passed on to the server. As such, an ALG used with a 203 stateful translator MUST support EPSV and MAY support EPRT. However, 204 an ALG used with a stateless translator SHOULD also support EPRT. 206 The ALG functionality is described as a function separate from the 207 IPv6-to-IPv4 translation function. However, in the case of EPRT 208 translation, the ALG and translator functions need to be tightly 209 coupled, so if EPRT translation is supported, it is assumed that the 210 ALG and IPv6-to-IPv4 translation functions are integrated within a 211 single device. 213 5. Control channel translation 215 The IPv6-to-IPv4 FTP ALG intercepts all TCP sessions towards port 21 216 for IPv6 destination addresses that map to IPv4 destinations 217 reachable through an IPv6-to-IPv4 translator. The FTP ALG implements 218 the Telnet protocol ([RFC0854]) used for control channel interactions 219 to the degree necessary to interpret commands and responses and re- 220 issue those commands and responses, modifying them as outlined below. 221 Telnet option negotiation attempts by either the client or the 222 server, except for those allowed by [RFC1123], MUST be rejected by 223 the FTP ALG without relaying those attempts. This avoids the 224 situation where the client and the server negotiate Telnet options 225 that are unimplemented by the FTP ALG. 227 There are two ways to implement the control channel ALG: 229 1. The ALG terminates the IPv6 TCP session, sets up a new IPv4 TCP 230 session towards the IPv4 FTP server, and relays commands and 231 responses back and forth between the two sessions. 233 2. Packets that are part of the control channel are translated 234 individually. 236 As they ultimately provide the same result, either implementation 237 strategy, or any other that is functionally equivalent, can be used. 239 In the second case, an implementation MUST have the ability to track 240 and update TCP sequence numbers when translating packets as well as 241 the ability to break up packets into smaller packets after 242 translation, as the control channel translation could modify the 243 length of the payload portion of the packets in question. Also, FTP 244 commands/responses or Telnet negotiations could straddle packet 245 boundaries, so in order to be able to perform the ALG function, it 246 can prove necessary to reconstitute Telnet negotiations and FTP 247 commands and responses from multiple packets. 249 If the client issues the AUTH command, then the client is attempting 250 to negotiate [RFC2228] security mechanisms which are likely to be 251 incompatible with the FTP ALG function. In this situation, the FTP 252 ALG MUST switch to transparently forwarding all data on the control 253 channel in both directions until the end of the control channel 254 session. This requirement applies regardless of the response from 255 the server. In other words, it is the fact that the client attempts 256 the AUTH negotiation that requires the ALG to become transparent, 257 whether or not the attempt is successful. The transparency 258 requirement applies to the commands and responses flowing between the 259 client and the server. It is possible that commands or responses 260 that were sent through the ALG before the AUTH command was issued 261 were changed in length so TCP sequence numbers in packets entering 262 the ALG and packets exiting the ALG no longer match. In transparent 263 mode, the ALG MUST continue to adjust sequence numbers if it was 264 doing so before entering transparent mode as the result of the AUTH 265 command. The ALGS command (Section 11) can also be used to disable 266 the ALG functionality, but the control channel MUST then still be 267 monitored for subsequent ALGS commands that re-enable the ALG 268 functionality. 270 There have been FTP ALGs for the purpose of making active FTP work 271 through IPv4 NATs for a long time. Another type of ALG would be one 272 that imposes restrictions required by security policies. Multiple 273 ALGs of different types can be implemented as a single entity. If 274 such a multi-purpose ALG forbids the use of the AUTH command for 275 policy reasons, the side effect of making the ALG stop performing the 276 translations described here, as well as other possible interventions 277 related to IPv6-to-IPv4 translation, MUST be retained even if the ALG 278 responds to the AUTH command with an error and does not propagate the 279 command to the server. This way, any time a client issues the AUTH 280 command, it knows that an ALG will be in transparent mode afterwards. 281 Implementers are further advised that unlike hosts behind an IPv4 282 NAT, IPv6 hosts using an IPv6-to-IPv4 translator will normally have 283 the ability to execute FTP over IPv6 without interference from the 284 IPv6-to-IPv4 translator or the ALG, so an IPv6-to-IPv4 translation 285 FTP ALG is not the best place to implement security policies. 287 5.1. Language negotiation 289 [RFC2640] specifies the ability for clients and servers to negotiate 290 the language used between the two of them in the descriptive text 291 that accompanies server response codes. Ideally, IPv6-to-IPv4 FTP 292 ALGs would support this feature, so that if a non-default language is 293 negotiated by a client and a server, the ALG also transmits its text 294 messages for translated responses in the negotiated language. 295 However, even if the ALG supports negotiation of the feature, there 296 is no way to make sure that the ALG has text strings for all possible 297 languages. So the situation where the client and server try to 298 negotiate a language that the ALG doesn't support can't be avoided. 299 The proper behavior for an FTP ALG in this situation may be addressed 300 in a future specification, as the same issue is present in IPv4-to- 301 IPv4 FTP ALGs. For the time being, ALG implementations may employ 302 one of the following strategies regarding LANG negotiation: 304 1. Monitor LANG negotiation, and send text in the negotiated 305 language if text in that language is available. If not, text is 306 sent in the default language. 308 2. Not monitor LANG negotiation. Text is sent in the default 309 language. 311 3. Block LANG negotiation by translating the LANG command to a NOOP 312 command, and translating the resulting 200 response into a 313 response appropriate for unsupported commands, such as 500. Text 314 is sent in the default language. 316 In the first two cases, if a language is negotiated, text transmitted 317 by the client or the server MUST be assumed to be encoded in UTF-8 318 rather than be limited to 7-bit ASCII. An ALG that implements the 319 first or second option MUST translate and/or forward commands and 320 responses containing UTF-8 encoded text when those occur. The ALG 321 itself MUST NOT generate characters outside the 7-bit ASCII range 322 unless it implements the first option and a language was negotiated. 324 Note that [RFC2640] section 3.1 specifies new handling for spaces and 325 the CR character in path names. ALGs that don't block LANG 326 negotiation SHOULD comply with the specified rules for path handling. 327 Implementers should especially note that the NUL (%x00) character is 328 used as an escape whenever a CR character occurs in a pathname. 330 In the sections that follow, a number of well-known response numbers 331 are shown, along with the descriptive text that is associated with 332 that response number. However, this text is not part of the 333 specification of the response. As such, implementations MAY use the 334 response text shown or they MAY show a different response text for a 335 given response number. Requirements language only applies to the 336 response number. 338 6. EPSV to PASV translation 340 Although many IPv4 FTP servers support the EPSV command, some servers 341 react adversely to this command, and there is no reliable way to 342 detect in advance that this will happen. As such, an FTP ALG SHOULD 343 translate all occurrences of the EPSV command issued by the client to 344 the PASV command, and reformat a 227 response as a corresponding 229 345 response. However, an ALG MAY forego EPSV to PASV translation if it 346 has positive knowledge, either through administrative configuration 347 or learned dynamically, that EPSV will be successful without 348 translation to PASV. 350 For instance, if the client issues EPSV (or EPSV 2 to indicate IPv6 351 as the network protocol), this is translated to the PASV command. If 352 the server with address 192.0.2.31 then responds with: 354 227 Entering Passive Mode (192,0,2,31,237,19) 356 The FTP ALG reformats this as: 358 229 Entering Extended Passive Mode (|||60691|) 360 The ALG SHOULD ignore the IPv4 address in the server's 227 response. 361 This is the behavior that is exhibited by most clients and is needed 362 to work with servers that include [RFC1918] addresses in their 227 363 responses. However, if the 227 response contains an IPv4 address 364 that does not match the destination of the control channel, the FTP 365 ALG MAY send a 425 response to the client instead of the 229 366 response, e.g.: 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 If the client issues an EPSV command with a numeric argument other 374 than 2, the ALG MUST NOT pass the command on to the server, but 375 rather respond with a 522 error, e.g.: 377 522 Network protocol not supported 379 If the client issues EPSV ALL, the FTP ALG MUST NOT pass this command 380 to the server, but respond with a 504 error, e.g.: 382 504 Command not implemented for that parameter 384 This avoids the situation where an FTP server reacts adversely to 385 receiving a PASV command after the client used the EPSV ALL command 386 to indicate that it will only use EPSV during this session. 388 7. EPRT to PORT translation 390 Should the IPv6 client issue an EPRT command, the FTP ALG MAY 391 translate this EPRT command to a PORT command. The translation is 392 different depending on whether the translator is a stateless one-to- 393 one translator or a stateful one-to-many translator. 395 7.1. Stateless EPRT translation 397 If the address specified in the EPRT command is the IPv6 address used 398 by the client for the control channel session, then the FTP ALG 399 reformats the EPRT command into a PORT command with the IPv4 address 400 that maps to the client's IPv6 address. The port number MUST be 401 preserved for compatibility with stateless translators. For 402 instance, if the client with IPv6 address 2001:db8:2::31 issues the 403 following EPRT command: 405 EPRT |2|2001:db8:2::31|5282| 407 Assuming the IPv4 address that goes with 2001:db8:2::31 is 408 192.0.2.31, the FTP ALG reformats this as: 410 PORT 192,0,2,31,20,162 412 If the address specified in the EPRT command is an IPv4 address or an 413 IPv6 address that is not the IPv6 address used by the client for the 414 control session, the ALG SHOULD NOT attempt any translation, but pass 415 along the command unchanged. 417 7.2. Stateful EPRT translation 419 If the address in the EPRT command is the IPv6 address used by the 420 client for the control channel, the stateful translator selects an 421 unused port number in combination with the IPv4 address used for the 422 control channel towards the FTP server, and sets up a mapping from 423 that transport address to the one specified by the client in the EPRT 424 command. The PORT command with the IPv4 address and port used on the 425 IPv4 side of the mapping is only issued towards the server once the 426 mapping is created. Initially, the mapping is such that either any 427 transport address or the FTP server's IPv4 address with any port 428 number is accepted as a source, but once the three-way handshake is 429 complete, the mapping SHOULD be narrowed to only match the negotiated 430 TCP session. 432 If the address specified in the EPRT command is an IPv4 address or an 433 IPv6 address that is not the IPv6 address used by the client for the 434 control session, the ALG SHOULD NOT attempt any translation, but pass 435 along the command unchanged. 437 If the client with IPv6 address 2001:db8:2::31 issues the EPRT 438 command: 440 EPRT |2|2001:db8:2::31|5282| 442 And the stateful translator uses the address 192.0.2.31 on its IPv4 443 interface, a mapping with destination address 192.0.2.31 and 444 destination port 60192 towards 2001:db8:2::31 port 5282 may be 445 created, after which the FTP ALG reformats the EPRT command as: 447 PORT 192,0,2,31,235,32 449 8. Default port 20 translation 451 If the client does not issue an EPSV/PASV or EPRT/PORT command prior 452 to initiating a file transfer, it is invoking the default active FTP 453 behavior where the server sets up a TCP session towards the client. 454 In this situation, the source port number is the default FTP data 455 port (port 20) and the destination port is the port the client uses 456 as the source port for the control channel session. 458 In the case of a stateless translator, this does not pose any 459 problems. In the case of a stateful translator, the translator MAY 460 accept incoming connection requests from the server on the IPv4 side 461 if the transport addresses match that of an existing FTP control 462 channel session, with the exception that the control channel session 463 uses port 21 and the new session port 20. In this case, a mapping is 464 set up towards the same transport address on the IPv6 side that is 465 used for the matching FTP control channel session. 467 An ALG/translator MAY monitor the progress of FTP control channels 468 and only attempt to perform a mapping when an FTP client has started 469 a file transfer without issuing the EPSV, PASV, EPRT or PORT 470 commands. 472 9. Both PORT and PASV 474 [RFC0959] allows a client to issue both PORT and PASV to use non- 475 default ports on both sides of the connection. However, this is 476 incompatible with the notion that with PASV, the data connection is 477 made from the client to the server, while PORT reaffirms the default 478 behavior where the server connects to the client. As such, the 479 behavior of an ALG is undefined when a client issues both PASV and 480 PORT. Implementations SHOULD NOT try to detect the situation where 481 both PASV and PORT commands are issued prior to a command that 482 initiates a transfer, but rather, apply the same translation they 483 would have if there had not been a PASV command prior to a PORT 484 command or a PORT command prior to a PASV command. 486 10. Default behavior 488 Whenever the client issues a command which the ALG is not set up to 489 translate, either because the command is not specified in this 490 document, the command is not part of any FTP specification, the ALG 491 functionality is disabled administratively for the command in 492 question, or translation does not apply for any other reason, the 493 command MUST be passed on to the server without modification, and the 494 server response MUST be passed on to the client without modification. 495 For example, if the client issues the PASV command, this command is 496 passed on to the server transparently, and the server's response to 497 the client. 499 11. The ALGS command 501 ALGs SHOULD support the new ALGS (ALG status) command that allows 502 clients to query and set the ALG's status. Note that this command 503 MUST NOT be implemented in FTP servers. If those recognize the 504 command, the best course of action would be to return a 202 response: 506 202 Command not implemented, superfluous at this site 508 However, as FTP servers don't implement the command, there is no 509 reason for them to specifically recognize this command, and returning 510 any 50x response that is normally returned when commands are not 511 recognized is appropriate. A client can use the ALGS command to 512 request the ALG's status and to enable and disable EPSV to PASV and, 513 if implemented, EPRT to PORT translation. There are three possible 514 arguments to the ALGS command: 516 ALGS STATUS64 517 The ALG is requested to return the EPSV and EPRT 518 translation status. 520 ALGS ENABLE64 521 The ALG is requested to enable translation. 523 ALGS DISABLE64 524 The ALG is requested to disable translation. 526 The ALG SHOULD enable or disable translation as requested. If EPRT 527 to PORT translation is supported, ALGS ENABLE64 enables it and ALGS 528 DISABLE64 disables it along with enabling or disabling EPSV to PASV 529 translation, respectively. If EPRT to PORT translation is not 530 supported, ALGS ENABLE64 only enables EPSV to PASV translation. 531 After an ALGS command with any of the three supported arguments, the 532 ALG returns a 216 response indicating the type of translation that 533 will be performed. There are four possible keywords that follow the 534 216 response code: 536 216 NONE 537 Neither EPSV nor EPRT translation is performed. 539 216 EPSV 540 EPSV is translated to PASV, no EPRT translation is 541 performed. 543 216 EPRT 544 EPRT is translated to PORT, no EPSV translation is 545 performed. 547 216 EPSVEPRT 548 EPSV is translated to PASV, EPRT is translated to 549 PORT. 551 The translation type MAY be followed by a space and additional 552 descriptive text until end-of-line. Failure to set the requested 553 translation mode is not an error condition, and is thus indicated by 554 the keyword that shows the translation status of the ALG following 555 the 216 response, and not with an error code response. 557 If the ALGS command is not implemented, the command SHOULD be passed 558 on to the server without modification. If there is no argument to 559 the ALGS command, or the argument is not one of STATUS64, ENABLE64 or 560 DISABLE64 (or an argument specified by a supported newer document), a 561 504 or 502 error SHOULD be returned. 563 The Augmented Backus-Naur Form (ABNF) notation (see [RFC5234]) of the 564 ALGS command and its response are as follows: 566 algs-command = "ALGS" SP algs-token CRLF 567 algs-token = "STATUS64" / "ENABLE64" / "DISABLE64" 569 algs-response = (ok-response / error-response) CRLF 570 ok-response = "216" SP response-token [ freetext ] 571 response-token = "NONE" / "EPSV" / "EPRT" / "EPSVEPRT" 572 error-response = not-implemented / invalid-parameter 573 not-implemented = "502" [ freetext ] 574 invalid-parameter = "504" [ freetext ] 575 freetext = (SP *VCHAR) 577 12. Timeouts and translating to NOOP 579 Wherever possible, control channels SHOULD NOT time out while there 580 is an active data channel. A timeout of at least 30 seconds is 581 RECOMMENDED for data channel mappings created by the FTP ALG that are 582 waiting for initial packets. 584 Whenever a command from the client is not propagated to the server, 585 the FTP ALG instead issues a NOOP command in order to keep the 586 keepalive state between the client and the server synchronized. The 587 response to the NOOP command MUST NOT be relayed back to the client. 588 An implementation MAY wait for the server to return the 200 response 589 to the NOOP command and translate that 200 response into the response 590 the ALG is required to return to the client. This way, the ALG never 591 has to create new packets to send to the client, but it can limit 592 itself to modifying packets transmitted by the server. If the server 593 responds with something other than 200 to the NOOP command, the ALG 594 SHOULD tear down the control channel session and log an error. 596 13. IANA considerations 598 IANA is requested to add to the FTP Commands and Extensions registry 599 the following entry: 601 Command Name 602 ALGS 604 FEAT Code 605 -N/A- 607 Description 608 FTP64 ALG status 610 Command Type 611 -N/A- 613 Conformance Requirements 614 o 616 Reference 617 RFC TBD Section 11 619 [TO BE REMOVED: This registration should take place at the following 620 location: http://www.iana.org/assignments/ftp-commands-extensions/ 621 ftp-commands-extensions.xhtml] 623 14. Security considerations 625 In the majority of cases, FTP is used without further security 626 mechanisms. This allows an attacker with passive interception 627 capabilities to obtain the login credentials, and an attacker that 628 can modify packets to change the data transferred. However, FTP can 629 be used with TLS in order to solve these issues. IPv6-to-IPv4 630 translation and the FTP ALG do not impact the security issues in the 631 former case nor the use of TLS in the latter case. However, if FTP 632 is used with TLS or another authentication mechanism, the ALG 633 function is not performed so only passive transfers from a server 634 that implements EPSV or a client that supports PASV will succeed. 636 For general FTP security considerations, see [RFC2577]. 638 15. Contributors 640 Dan Wing, Kentaro Ebisawa, Remi Denis-Courmont, Mayuresh Bakshi, 641 Sarat Kamisetty, Reinaldo Penno, Alun Jones, Dave Thaler, Mohammed 642 Boucadair, Mikael Abrahamsson, Dapeng Liu, Michael Liu, Andrew 643 Sullivan, Anthony Bryan and Ed Jankiewicz contributed ideas and 644 comments. Dan Wing ran experiments with a large number of FTP 645 servers that were very illuminating; many of the choices underlying 646 this document are based on his results. 648 16. Acknowledgements 650 Iljitsch van Beijnum is partly funded by Trilogy, a research project 651 supported by the European Commission under its Seventh Framework 652 Program. 654 17. References 656 17.1. Normative References 658 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 659 Specification", STD 8, RFC 854, May 1983. 661 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 662 STD 9, RFC 959, October 1985. 664 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 665 and Support", STD 3, RFC 1123, October 1989. 667 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 668 Requirement Levels", BCP 14, RFC 2119, March 1997. 670 [RFC2228] Horowitz, M., "FTP Security Extensions", RFC 2228, 671 October 1997. 673 [RFC2428] Allman, M., Ostermann, S., and C. Metz, "FTP Extensions 674 for IPv6 and NATs", RFC 2428, September 1998. 676 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 677 Specifications: ABNF", STD 68, RFC 5234, January 2008. 679 17.2. Informative References 681 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 682 E. Lear, "Address Allocation for Private Internets", 683 BCP 5, RFC 1918, February 1996. 685 [RFC2389] Hethmon, P. and R. Elz, "Feature negotiation mechanism for 686 the File Transfer Protocol", RFC 2389, August 1998. 688 [RFC2577] Allman, M. and S. Ostermann, "FTP Security 689 Considerations", RFC 2577, May 1999. 691 [RFC2640] Curtin, B., "Internationalization of the File Transfer 692 Protocol", RFC 2640, July 1999. 694 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 695 (SIIT)", RFC 2765, February 2000. 697 [I-D.ietf-behave-v6v4-xlate-stateful] 698 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 699 NAT64: Network Address and Protocol Translation from IPv6 700 Clients to IPv4 Servers", 701 draft-ietf-behave-v6v4-xlate-stateful-12 (work in 702 progress), July 2010. 704 [I-D.ietf-behave-v6v4-xlate] 705 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 706 Algorithm", draft-ietf-behave-v6v4-xlate-05 (work in 707 progress), December 2009. 709 [I-D.liu-ftp64-extension] 710 Liu, D., Beijnum, I., and Z. Cao, "FTP extension for IPv4/ 711 IPv6 transition", draft-liu-ftp64-extension-00 (work in 712 progress), October 2010. 714 [Bernstein] 715 Bernstein, D., "PASV security and PORT security", 2000, 716 . 718 Author's Address 720 Iljitsch van Beijnum 721 IMDEA Networks 722 Avda. del Mar Mediterraneo, 22 723 Leganes, Madrid 28918 724 Spain 726 Email: iljitsch@muada.com