idnits 2.17.1 draft-ietf-behave-ftp64-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 17, 2009) is 5244 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2765 (Obsoleted by RFC 6145) == Outdated reference: A later version (-12) exists of draft-ietf-behave-v6v4-xlate-stateful-07 == 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: 3 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). 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 December 17, 2009 5 Intended status: Informational 6 Expires: June 20, 2010 8 IPv6-to-IPv4 translation FTP considerations 9 draft-ietf-behave-ftp64-00.txt 11 Abstract 13 The File Transfer Protocol has a very long history, and despite the 14 fact that today, other options exist to perform file transfers, FTP 15 is still in common use. As such, it is important that in the 16 situation where some client computers are IPv6-only while many 17 servers are still IPv4-only and IPv6-to-IPv4 translators are used to 18 bridge that gap, FTP is made to work through these translators as 19 best it can. 21 FTP has an active and a passive mode, both as original commands that 22 are IPv4-specific, and as extended, IP version agnostic commands. 23 The only FTP mode that works without changes through an IPv6-to-IPv4 24 translator is extended passive. However, many existing FTP servers 25 don't support this mode, and some clients don't ask for it. This 26 document describes server, client and middlebox (if any) behavior 27 that minimizes this problem. 29 Status of this Memo 31 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 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 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt. 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 This Internet-Draft will expire on June 20, 2010. 52 Copyright Notice 54 Copyright (c) 2009 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Client recommendations . . . . . . . . . . . . . . . . . . . . 4 72 4. ALG functionality . . . . . . . . . . . . . . . . . . . . . . 5 73 4.1. Control channel translation . . . . . . . . . . . . . . . 6 74 4.2. EPSV to PASV translation . . . . . . . . . . . . . . . . . 7 75 4.3. EPRT to PORT translation . . . . . . . . . . . . . . . . . 8 76 4.3.1. Stateless EPRT translation . . . . . . . . . . . . . . 8 77 4.3.2. Stateful EPRT translation . . . . . . . . . . . . . . 8 78 4.4. Default port 20 translation . . . . . . . . . . . . . . . 9 79 4.5. Both PORT and PASV . . . . . . . . . . . . . . . . . . . . 9 80 4.6. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 82 6. Security considerations . . . . . . . . . . . . . . . . . . . 10 83 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 Appendix A. Server implementation recommendations . . . . . . . . 11 85 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 12 86 Appendix C. Document and discussion information . . . . . . . . . 12 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 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 doesn't 95 work through NATs or firewalls. And in both cases, an IPv4 address 96 is specified, making both the original passive and active modes 97 incompatible with IPv6. These issues were solved in [RFC2428], which 98 introduces the EPSV (extended passive) mode, where the server only 99 responds with a port number, and the EPRT (extended port) command, 100 which allows the client to supply either an IPv4 or an IPv6 address 101 (and a port) to the server. 103 A survey done in April of 2009 of 25 randomly picked and/or well- 104 known FTP sites reachable over IPv4 showed that only 12 of them 105 supported EPSV over IPv4. Additionally, only 2 of those 12 indicated 106 that they supported EPSV in response to the FEAT command ([RFC2389]) 107 that asks the server to list its supported features. One supported 108 EPSV but not FEAT. In 5 cases, issuing the EPSV command to the 109 server led to a significant delay, in 3 cases followed by a control 110 channel reset. All 25 servers were able to successfully complete a 111 transfer in traditional passive PASV mode as required by [RFC1123]. 112 More tests showed that the use of an address family argument with the 113 EPSV command is widely mis- or unimplemented in servers. The 114 additional tests with more servers showed that approximately 65% of 115 FTP servers support EPSV successfully and around 96% support PASV 116 successfully. Clients weren't extensively tested, but previous 117 experience from the author suggests that most clients support PASV, 118 with the notable exception of the command line client included with 119 Windows, which only supports active mode. It uses the original PORT 120 command when running over IPv4 and EPRT when running over IPv6. 122 Considering the above, this document describes the following 123 recommendations: 125 Servers: 127 * Allow EPSV (even for IPv4-only servers) 129 * Use a predictable address in the response to the PASV command 131 Clients: 133 * Use EPSV over IPv6 rather than EPRT 135 * Fall back to PASV if EPSV fails (even over IPv6) 136 * Don't use certain modes and options that trigger server bugs 138 Additionally, there are guidelines for operators choosing to 139 implement application layer gateway functionality to provide 140 connectivity between unupdated servers and/or clients. Clients that 141 want to engage in more complex behavior, such as server-to-server 142 transfers, may make an FTP ALG go into transparent mode by issuing an 143 AUTH command. 145 The recommendations in this document apply to all forms of IPv6-to- 146 IPv4 translation, including stateless translation such as [RFC2765] 147 or [I-D.ietf-behave-v6v4-xlate] as well as stateful translation such 148 as [I-D.ietf-behave-v6v4-xlate-stateful]. 150 The FTP protocol allows for complex interactions, such as the 151 situation where a client connects to two servers and directs the 152 servers to exchange data between them. No attempt is made to address 153 these other than through making ALGs transparent after an AUTH 154 command. 156 2. Terminology 158 Within the context of this document, the words "client" and "server" 159 refer to FTP client and server implementations, respectively. An FTP 160 server is understood to be an implementation of the FTP protocol 161 running on a server system with a stable address, waiting for clients 162 to connect and issue commands and start data transfers. Clients 163 interact with servers using the FTP protocol, and store (upload) or 164 retrieve (download) files to/from one or more servers, either 165 interactively under control of a user, or as an unattended background 166 process. Most operating systems provide a web browser that 167 implements a basic FTP client, as well as a command line client. 168 Third-party FTP clients are also widely available. 170 Other terminology is derived from the documents listed in the 171 reference section. 173 3. Client recommendations 175 All FTP clients should support EPSV when communicating over IPv6 and 176 always attempt to use EPSV mode unless explicitly configured to use 177 EPRT. 179 It is highly recommended that FTP clients react by retrying with PASV 180 when the EPSV command fails, either because of an error response by 181 the server (40x, 42x, 50x and 52x responses), because the data 182 connection couldn't be created or because the control channel session 183 was terminated. In the latter two cases, a client may cache the name 184 or address of the FTP server and issue PASV rather than EPSV in 185 future sessions. In that case, the cache entry should be cleared if 186 older than 7 days and the server indicates EPSV support in its FEAT 187 response where it previously did not indicate EPSV support in its 188 FEAT response. There is always a risk that an error was the result 189 of a condition unrelated to IPv6-to-IPv4 translation. However, 190 retrying with a PASV request has little potential for harm, so unless 191 the error is clearly unrelated, retrying with PASV is the appropriate 192 reaction. 194 When after attempting to initiate EPSV and/or EPRT modes 195 unsuccessfully and a client retries with PASV, the server will 196 respond to the PASV command with an IPv4 address that the client must 197 use to connect to for the data connection. Even if the client has 198 IPv4 reachability, it should ignore the server-supplied address and 199 set up a data connection towards the IPv6 address of the server that 200 is used for the control channel session. However, the port number 201 used for the data connection is taken from the 227 response to the 202 PASV command. 204 The main rationale for ignoring the IPv4 address in the 227 response, 205 even if the client has IPv4 connectivity, is the fact that most 206 servers will only allow a data connection from the same client 207 address as seen in the control channel connection, see 208 . Using IPv6 for the control 209 channel and IPv4 for the data channel means that the source address 210 will almost certainly be different in both cases, making it unlikely 211 that the data connection can be established successfully. 213 Clients should refrain from using any arguments with the EPSV 214 command. "EPSV 2" to request IPv6 will fail across an IPv6-to-IPv4 215 translator. Also, this command is often not handled properly by IPv6 216 servers. "EPSV ALL" indicates that the client will use EPSV for all 217 transfers, but an ALG may translate EPSV commands to PASV commands, 218 conflicting with the earlier "EPSV ALL". 220 4. ALG functionality 222 The use of FTP application layer gateways for compatibility with 223 IPv6-to-IPv4 translators is rejected by many within the IETF 224 community. As such, it is recommended to update FTP clients and 225 servers as required for IPv6-to-IPv4 translation support where 226 possible, to allow proper operation of the FTP protocol without the 227 need for ALGs. 229 On the other hand, network operators often have little influence over 230 the FTP clients their customers run, let alone the FTP servers used 231 throughout the Internet. For those operators, deploying an ALG may 232 be the only way to provide a satisfactory customer experience. So, 233 even though not the preferred solution, this document describes the 234 functionality of such an ALG in order to promote consistent behavior 235 between ALGs in an effort to minimize their harmful effects. 236 However, the situation with regard to FTP servers and -clients, 237 especially in IPv6-heavy deployments, may change fast, so within 238 relatively little time it may become feasible to stop running an ALG. 239 Operators are encouraged to keep revisiting the issue. 241 Note that the translation of EPSV through all translators and EPRT 242 through a stateless translator is relatively simple and translation 243 of EPRT through a stateful translator relatively difficult. As such, 244 an ALG used with a stateful translator may choose to support only 245 EPSV. However, an ALG used with a stateless translator should also 246 support EPRT. 248 4.1. Control channel translation 250 The IPv6-to-IPv4 FTP ALG intercepts all TCP sessions towards IPv4 251 port 21 destinations. The FTP ALG implements the Telnet protocol 252 ([RFC0854]) used for control channel interactions to the degree 253 necessary to interpret commands and responses and re-issue those 254 commands and responses, modifying them as outlined below. Option 255 negotiation attempts by either the client or the server, except for 256 those allowed by [RFC1123], should be rejected by the FTP ALG without 257 relaying those attempts. This avoids the situation where the client 258 and the server negotiate options unknown to the FTP ALG. 260 There are two ways to implement the control channel ALG: 262 1. The ALG terminates the IPv6 TCP session, sets up a new IPv4 TCP 263 session towards the IPv4 FTP server, and relays commands and 264 responses back and forth between the two sessions. 266 2. Packets that are part of the control channel are translated 267 individually. 269 In the second case, an implementation must have the ability to track 270 and update TCP sequence numbers when translating packets and break up 271 packets into smaller packets after translation, as the control 272 channel translation may modify the length of the payload portion of 273 the packets in question. Also, FTP commands/responses or Telnet 274 negotiations may straddle packet boundaries, so in order to be able 275 to perform the ALG function, it may be necessary to reconstitute 276 Telnet negotiations and FTP commands and responses from multiple 277 packets. 279 If the client issues the AUTH command the client is attempting to 280 negotiate [RFC2228] security mechanisms which are likely to be 281 incompatible with the FTP ALG function. In this situation, the FTP 282 ALG must switch to transparently forwarding all data on the control 283 channel in both directions until the end of the control channel 284 session. This requirement applies regardless of the response from 285 the server. In other words, it is the fact that the client attempts 286 the AUTH negotiation that requires the ALG to become transparent, not 287 whether or not the attempt is successful. 289 There have been FTP ALGs for the purpose of making active FTP work 290 through IPv4 NATs for a long time. Another type of ALG would be one 291 that imposes restrictions required by security policies. Multiple 292 ALGs can be implemented as a single entity. Should such a multi- 293 purpose ALG forbid the use of the AUTH command for policy reasons, 294 the side effect of making the ALG stop performing the translations 295 described here, as well as other possible interventions related to 296 IPv6-to-IPv4 translation, must be retained even if the ALG responds 297 to the AUTH command with an error and doesn't propagate the command 298 to the server. (Implementers are further advised that unlike hosts 299 behind an IPv4 NAT, IPv6 hosts using an IPv6-to-IPv4 translator will 300 normally have the ability to execute FTP over IPv6 without 301 interference from the ALG.) 303 4.2. EPSV to PASV translation 305 Although many IPv4 FTP servers support the EPSV command, some servers 306 react adversely to this command, and there is no reliable way to 307 detect in advance that this will happen. As such, an FTP ALG may 308 translate all occurrences of the EPSV command issued by the client to 309 the PASV command, and reformat a 227 response as a corresponding 229 310 response. 312 For instance, if the client issues EPSV (or EPSV 2 to indicate IPv6 313 as the network protocol), this is translated to the PASV command. If 314 the server with address 192.0.2.31 then responds with: 316 227 Entering Passive Mode (192,0,2,31,237,19) 318 The FTP ALG reformats this as: 320 229 Entering Extended Passive Mode (|||60691|) 322 If the server's 227 response contains an IPv4 address that doesn't 323 match the destination of the control channel, the FTP ALG should send 324 the following response to the client: 326 425 Can't open data connection. 328 It is important that the response is in the 4xx range to indicate a 329 temporary condition. 331 If the client issues an EPSV command with a numeric argument other 332 than 2, the ALG must not pass the command on to the server, but 333 rather respond with a 522 error. 335 If the client issues EPSV ALL, the FTP ALG must not pass this command 336 to the server, but respond with: 338 202 Command not implemented. 340 This avoids the situation where an FTP server may react adversely to 341 receiving a PASV command after the client indicated that it will only 342 use EPSV during this session. 344 4.3. EPRT to PORT translation 346 Should the IPv6 client issue an EPRT command, the FTP ALG may 347 translate this EPRT command to a PORT command. The translation is 348 different depending on whether the translator is a stateless one-to- 349 one translator or a stateful one-to-many translator. 351 4.3.1. Stateless EPRT translation 353 If the address specified in the EPRT command is the client's IPv6 354 address, then the FTP ALG reformats the EPRT command into a PORT 355 command with the IPv4 address that maps to the client's IPv6 address. 356 The port number must be preserved for compatibility with stateless 357 translators. 359 If the address specified in the EPRT command is not the client's IPv4 360 address, the ALG's response is undefined. It may pass along the 361 command unchanged, respond with an error, or attempt to perform an 362 appropriate translation. 364 4.3.2. Stateful EPRT translation 366 If the address in the EPRT command is the IPv6 address of the control 367 channel client's address, the stateful translator selects an unused 368 port number in combination with the IPv4 address used for the control 369 channel towards the FTP server, and sets up a mapping from that 370 transport address to the one specified by the client in the EPRT 371 command. The PORT command with the IPv4 address and port used on the 372 IPv4 side of the mapping is only issued towards the server once the 373 mapping is created. Initially, the mapping is such that either any 374 transport address or the FTP server's IPv4 address with any port 375 number is accepted as a source, but once the three-way handshake is 376 complete, the mapping is narrowed to only match the negotiated TCP 377 session. 379 If the address in the EPRT command is not the client's IPv6 address, 380 the ALG's response is undefined. 382 4.4. Default port 20 translation 384 If the client doesn't issue an EPSV/PASV or EPRT/PORT command, it is 385 invoking the default active FTP behavior where the server sets up a 386 TCP session towards the client. In this situation, the source port 387 number is the default FTP data port (port 20) and the destination 388 port is the port the client uses as the source port in the control 389 channel session. 391 In the case of a stateless translator, this does not pose any 392 problems. In the case of a stateful translator, the translator 393 should accept incoming connection requests from the server on the 394 IPv4 side if the transport addresses match that of an existing FTP 395 control channel session, with the exception that the control channel 396 session uses port 21 and the new session port 20. In this case, a 397 mapping is set up towards the same transport address on the IPv6 side 398 that is used for the matching FTP control channel session. 400 So for instance, the client is 2001:db8:31::6 and the server is 401 192.0.2.4. The translator has prefix 2001:db8:ffff:fffff::/96 as its 402 translator prefix and 10.0.0.1 as its IPv4 address. On the IPv6 403 side, the transport addresses for an FTP control channel session 404 could then be 2001:db8:31::6,49152 to 2001:db8:ffff:ffff::c000:204,21 405 on the IPv6 side and 10.0.0.1,60000 to 192.0.2.4,21 on the IPv4 side. 406 If then the FTP server initiates a session from 192.0.2.4,20 to 407 10.0.0.1,60000, the translator sets up a mapping from those addresses 408 to source 2001:db8:ffff:ffff::c000:204,20 destination 2001:db8:31:: 409 6,49152. 411 If there is no (unambiguous) match for an existing data channel 412 session when an incoming session request on port 20 arrives, the 413 connection is refused with a TCP RST. 415 4.5. Both PORT and PASV 417 [RFC0959] allows a client to issue both PORT and PASV to use non- 418 default ports on both sides of the connection. However, this is 419 incompatible with the notion that with PASV the data connection is 420 made from the client to the server, while PORT reaffirms the default 421 behavior where the server connects to the client. As such, the 422 behavior of an ALG is undefined when a client issues both PASV and 423 PORT. 425 4.6. Timeouts 427 Wherever possible, control channels should not time out while there 428 is an active data channel. A timeout of at least 30 seconds is 429 recommended for mappings created by the FTP ALG that are waiting for 430 initial packets. 432 Whenever a command from the client isn't propagated to the server, 433 the FTP ALG instead issues a NOOP command in order to keep the 434 keepalive state between the client and the server synchronized. The 435 response to the NOOP command is not relayed back to the client. 437 5. IANA considerations 439 None. 441 6. Security considerations 443 In the majority of cases, FTP is used without further security 444 mechanisms. This allows an attacker with passive interception 445 capabilities to obtain the login credentials, and an attacker that 446 can modify packets to change the data transferred. However, FTP can 447 be used with TLS in order to solve these issues. IPv6-to-IPv4 448 translation and the FTP ALG don't impact the security issues in the 449 former case nor the use of TLS in the latter case. However, if FTP 450 is used with TLS or another authentication mechanism, the ALG 451 function is not performed so only passive transfers from a server 452 that implements EPSV or a client that supports PASV will succeed. 454 7. References 456 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 457 Specification", STD 8, RFC 854, May 1983. 459 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 460 STD 9, RFC 959, October 1985. 462 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 463 and Support", STD 3, RFC 1123, October 1989. 465 [RFC2389] Hethmon, P. and R. Elz, "Feature negotiation mechanism for 466 the File Transfer Protocol", RFC 2389, August 1998. 468 [RFC2228] Horowitz, M., "FTP Security Extensions", RFC 2228, 469 October 1997. 471 [RFC2428] Allman, M., Ostermann, S., and C. Metz, "FTP Extensions 472 for IPv6 and NATs", RFC 2428, September 1998. 474 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 475 (SIIT)", RFC 2765, February 2000. 477 [I-D.ietf-behave-v6v4-xlate-stateful] 478 Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network 479 Address and Protocol Translation from IPv6 Clients to IPv4 480 Servers", draft-ietf-behave-v6v4-xlate-stateful-07 (work 481 in progress), December 2009. 483 [I-D.ietf-behave-v6v4-xlate] 484 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 485 Algorithm", draft-ietf-behave-v6v4-xlate-05 (work in 486 progress), December 2009. 488 [I-D.liu-behave-ftp64] 489 Liu, D. and Z. Cao, "IPv6 IPv4 translation FTP 490 considerations", draft-liu-behave-ftp64-03 (work in 491 progress), August 2009. 493 Appendix A. Server implementation recommendations 495 As EPSV works through IPv6-to-IPv4 translation transparently without 496 additional effort on the part of the client, the server or an 497 application layer gateway, it is highly recommended that all servers 498 implement EPSV. 500 [RFC2428] suggests that the EPSV mode is useful both for clients with 501 IPv6 connectivity and for clients operating behind a NAT device. As 502 such, it is common for IPv6-capable clients to use EPSV even when 503 communicating over IPv4. If a server doesn't implement EPSV and 504 responds with a 501 or 502 error, the client simply retries with 505 PASV. This works well with both servers that have working EPSV and 506 servers that don't implement EPSV. However, there is a class of 507 servers that does implement EPSV, but is unable to use this mode 508 because the data connection can't be established successfully. This 509 is very likely the result of a middlebox monitoring the control 510 channel interactions, and creating firewall or translation state 511 according to the information 227 response after a PASV command. If 512 the server supports EPSV but the middlebox doesn't, the result is 513 that the data connection cannot be established and the data transfer 514 fails. 516 To avoid this, it is highly recommended that server implementers 517 include a configuration setting that makes it possible to disable 518 EPSV and EPRT support and respond with a 502 (command not 519 implemented) error instead. Server operators can thus disable EPSV 520 support in servers located behind PASV-only middleboxes so clients 521 that issue EPSV can fall back to PASV gracefully rather than a 522 timeout. 524 The test performed by Dan Wing showed that existing implementations 525 present the address used for the server side of the control channel 526 connection in the 227 response to a PASV command. Clients conforming 527 to this specification depend on this behavior and it allows ALGs to 528 translate a 227 PASV response to a 229 EPSV response without loss of 529 information; as such it is highly recommended that servers continue 530 to implement this limitation. 532 Many servers that support the FEAT command do not list EPSV and EPRT 533 as a supported feature in the response to the FEAT command. It is 534 recommended that EPSV and EPRT capability is included in the FEAT 535 response, unless EPSV and/or EPRT are administratively disabled as 536 outlined above. 538 Appendix B. Acknowledgements 540 Kentaro Ebisawa, Remi Denis-Courmont, Mayuresh Bakshi, Sarat 541 Kamisetty, Reinaldo Penno, Alun Jones, Dave Thaler, Mohammed 542 Boucadair, Mikael Abrahamsson and Dapeng Liu contributed ideas and 543 comments. Dan Wing ran experiments with a large number of FTP 544 servers that were very illuminating; many of the choices underlying 545 this document are based on his results. This document adopts several 546 important design decisions from [I-D.liu-behave-ftp64]. 548 Iljitsch van Beijnum is partly funded by Trilogy, a research project 549 supported by the European Commission under its Seventh Framework 550 Program. 552 Appendix C. Document and discussion information 554 Please direct questions and comments to the BEHAVE mailinglist. The 555 latest version of this document will always be available at 556 http://www.muada.com/drafts/. 558 Author's Address 560 Iljitsch van Beijnum 561 IMDEA Networks 562 Avda. del Mar Mediterraneo, 22 563 Leganes, Madrid 28918 564 Spain 566 Email: iljitsch@muada.com