RFC 6384
An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation
An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation ✨
Okay, title block first 🎀 This is RFC 6384, written by I. van Beijnum from the Institute IMDEA Networks. It's dated October 2011, it's a Standards Track document, and its ISSN is 2070-1721. The title block doesn't list any RFC that it obsoletes or updates, so nothing is being replaced or patched here 🦋
Abstract 💜
The File Transfer Protocol (FTP) has a very long history, and even though other options exist for file transfers now, FTP is still in common use 🌸 So say some client computers only have IPv6 connectivity, while lots of servers are still IPv4-only, and IPv6-to-IPv4 translators are bridging that gap. In that situation it's important that FTP works through these translators as well as it possibly can 🫶
FTP has an active mode and a passive mode. Each has original commands that are IPv4-specific, and extended commands that don't care which IP version you're using. ngl, the only FTP mode that works through an IPv6-to-IPv4 translator with no changes is extended passive. The problem is that many existing FTP servers don't support it, and some clients never ask for it 😭 This document specifies a middlebox that may solve this mismatch ✨
Status of This Memo 📜
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6384.
Copyright Notice ©️
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. ALG Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Control Channel Translation . . . . . . . . . . . . . . . . . 5
5.1. Language Negotiation . . . . . . . . . . . . . . . . . . . 7
6. EPSV to PASV Translation . . . . . . . . . . . . . . . . . . . 8
7. EPRT to PORT Translation . . . . . . . . . . . . . . . . . . . 9
7.1. Stateless EPRT Translation . . . . . . . . . . . . . . . . 9
7.2. Stateful EPRT Translation . . . . . . . . . . . . . . . . 10
8. Default Port 20 Translation . . . . . . . . . . . . . . . . . 10
9. Both PORT and PASV . . . . . . . . . . . . . . . . . . . . . . 11
10. Default Behavior . . . . . . . . . . . . . . . . . . . . . . . 11
11. The ALGS Command . . . . . . . . . . . . . . . . . . . . . . . 12
12. Timeouts and Translating to NOOP . . . . . . . . . . . . . . . 13
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
14. Security Considerations . . . . . . . . . . . . . . . . . . . 14
15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
17.1. Normative References . . . . . . . . . . . . . . . . . . . 15
17.2. Informative References . . . . . . . . . . . . . . . . . . 151. Introduction 🦋
[RFC0959] describes two FTP modes 💅 In active mode, the server connects back to the client. In passive mode, the server opens a port and the client connects to it. Without extra help, active mode with a client-supplied port doesn't work through NATs or firewalls, which is giving chaos 🙈 In active mode the PORT command takes an IPv4 address as its argument, and in passive mode the server answers the PASV command with an IPv4 address. So both the passive and active modes, as originally specified in [RFC0959], are incompatible with IPv6. Iconic problem, honestly. [RFC2428] fixed this with two new commands: EPSV (extended passive), where the server only responds with a port number, and EPRT (extended port), which lets the client give the server either an IPv4 or an IPv6 address (plus a port) 🌈
A survey from April 2009 looked at 25 randomly picked and/or well-known FTP sites that were reachable over IPv4. Only 12 of them supported EPSV over IPv4 😬 Only 2 of those 12 said they supported EPSV when asked through the FEAT command, which was introduced in [RFC2389] so the server can list its supported features. One supported EPSV but not FEAT. In 5 cases, sending EPSV led to a big delay, and in 3 of those cases the control channel got reset after the delay 💀 We can't say for sure why some FTP servers reset the control channel some time after an EPSV command, because there isn't enough information. But a reasonable guess is that these servers sit behind application-aware firewalls. Those firewalls watch the control channel and only let data channel sessions open to ports listed in the responses to PASV (and maybe PORT) commands. An EPSV response is different (a 229 code instead of a 227 code), so a firewall that doesn't know about EPSV would block the next data channel setup attempt. If no data channel connection gets established after some time, the FTP server may decide to end the control channel session to get out of this ambiguous state 🫠
All 25 tested servers managed to complete a transfer in traditional PASV passive mode, which [RFC1123] requires ✨ More testing showed that using an address family argument with the EPSV command is widely misimplemented or not implemented at all in servers. More tests with more servers found that about 65% of FTP servers support EPSV successfully, and around 96% support PASV successfully. Clients weren't tested extensively, but the author's previous experience suggests that most clients support PASV. The big exception is the command line client that comes with Windows, which only supports active mode. That FTP client uses the original PORT command over IPv4 and EPRT over IPv6 🎀
Yes, these issues can and should be fixed by updating clients and servers to support EPSV properly. But those updates may not show up widely anytime soon. Also, network operators who want to deploy IPv6-to-IPv4 translation usually don't control client or server implementations. So this document standardizes an FTP Application Layer Gateway (ALG) that lets unmodified IPv6 FTP clients successfully talk to unmodified IPv4 FTP servers, as long as they're doing simple file transfers between a single client and a single server 💖
Clients that want more complex behavior, like server-to-server transfers, may make an FTP Application Layer Gateway (ALG) go into transparent mode by issuing the ALGS command, as explained in Section 5 🧚
The recommendations and specifications in this document apply to all forms of IPv6-to-IPv4 translation. That includes stateless translation like [RFC6145] and stateful translation like [RFC6146] 🌸
This document doesn't deal with the LPRT and LPSV commands from [RFC1639], because those commands don't appear to see much real use 🙅♀️
2. Notational Conventions 📏
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Those are the rules-of-the-game words, so read them carefully 🔥
3. Terminology 🧚♀️
In this document, "client" and "server" mean FTP client and server implementations, respectively. An FTP server is an implementation of the FTP protocol running on a server system with a stable address. It waits for clients to connect and issue commands that eventually start data transfers. Clients talk to servers using the FTP protocol, and they store (upload) files to and retrieve (download) files from one or more servers. This happens either interactively under a user's control or as an unattended background process. Most operating systems come with a web browser that includes a basic FTP client, plus a command line client. Third-party FTP clients are widely available too 💅
Other terminology comes from the documents in the References section. This document can't be fully understood on its own. It depends on the background and terminology outlined in those references 📚
4. ALG Overview ✨
okay bestie, so the most robust fix for an IP version mismatch between FTP clients and servers is to update the clients and servers themselves 💅 instead of using an IPv6-to-IPv4 translator for the data channel plus an Application Layer Gateway on the control channel. so it is recommended to update FTP clients and servers as required for IPv6-to-IPv4 translation support where possible, so FTP works properly without needing ALGs 🦋
ngl though, network operators and admins often don't get much say over which FTP client and server software is used on their network 😭 for them, deploying an ALG might be the only way to give users a decent experience. so even though it's not the preferred solution 🙈, this document standardizes what the ALG does so ALGs behave consistently and cause less harm 🫶
Operators and administrators are encouraged to only deploy an FTP ALG for IPv6-to-IPv4 translation when it is clearly needed 🍓 when the ALG is in the picture, EPSV commands that conforming servers could handle directly get translated into PASV commands, which adds complexity and lowers robustness 💀 so a "set and forget" policy on ALGs is not recommended, periodt ✨
translating EPSV through all translators and EPRT through a stateless translator is pretty simple, but EPRT through a stateful translator is hard 🧠 because a translation mapping has to be set up for every data transfer, using parameters learned from the client/server chat over the control channel. that has to happen before EPRT can become a PORT command and get passed on to the server. so an ALG used with a stateful translator MUST support EPSV translation and MAY support EPRT translation. however, an ALG used with a stateless translator MUST support EPSV translation and SHOULD also support EPRT translation 👑
the ALG functionality is described as a function separate from the IPv6-to-IPv4 translation function. however, for EPRT translation the ALG and translator need to be tightly coupled, so if EPRT translation is supported, it is assumed that the ALG and IPv6-to-IPv4 translation are integrated within a single device 🎀
5. Control Channel Translation
the IPv6-to-IPv4 FTP ALG intercepts all TCP sessions heading to port 21 for IPv6 destination addresses that map to IPv4 destinations reachable through an IPv6-to-IPv4 translator 🌈 it implements the Telnet protocol ([RFC0854]), which handles control channel interactions, just enough to interpret commands and responses and re-issue them, modifying them as outlined below 🧚 Telnet option negotiation attempts by either the client or the server, except for those allowed by [RFC1123], MUST be refused by the FTP ALG without relaying those attempts. for Telnet option negotiation, an FTP ALG MUST follow the behavior of an FTP server as specified in [RFC1123], Section 4.1.2.12. this avoids the situation where the client and the server negotiate Telnet options that the FTP ALG doesn't implement 💖
there are two ways to implement the control channel ALG:
- The ALG terminates the IPv6 TCP session, sets up a new IPv4 TCP session towards the IPv4 FTP server, and relays commands and responses back and forth between the two sessions.
- Packets that are part of the control channel are translated individually.
since they ultimately provide the same result, either implementation strategy, or any other that is functionally equivalent, can be used 🦋
in the second case, an implementation MUST have the ability to track and update TCP sequence numbers when translating packets, as well as the ability to break up packets into smaller packets after translation, because control channel translation could change the length of the payload portion of the packets in question 😵💫 also, FTP commands/responses or Telnet negotiations could straddle packet boundaries, so to perform the ALG function it may prove necessary to reconstitute Telnet negotiations and FTP commands and responses from multiple packets 🧩
some FTP clients use the TCP urgent data feature when interrupting transfers. an ALG MUST either maintain the semantics of the urgent pointer when translating control channel interactions, even when crossing packet boundaries, or clear the URG bit in the TCP header 🚨
if the client issues the AUTH command, then it is trying to negotiate ([RFC2228]) security mechanisms that are likely to be incompatible with the FTP ALG function 🙈 for instance, if the client attempts to negotiate Transport Layer Security (TLS) protection of the control channel ([RFC4217]), an ALG can do one of three things:
- Transparently copy data transmitted over the control channel back and forth, so the TLS session works as expected, but the client commands and server responses are now hidden from the ALG.
- Block the negotiation of additional security, which will likely make the client and/or the server break off the session or, if not, perform actions in the clear that were supposed to be encrypted.
- Negotiate with both the client and the server so two separate protected sessions are set up, and the ALG is still able to modify client commands and server responses. again, clients and servers are likely to reject the session because this will be perceived as a man-in-the-middle attack 😱
an ALG MUST adopt the first option and allow a client and a server to negotiate security mechanisms. to keep things consistent, as soon as the initial AUTH command is issued by the client, an ALG MUST stop translating commands and responses, and start transparently copying TCP data sent by the server to the client and vice versa 🔐 the ALG SHOULD ignore the AUTH command and not go into transparent mode if the server response is in the 4xx or 5xx ranges.
it's possible that commands or responses sent through the ALG before the AUTH command was issued changed in length, so TCP sequence numbers in packets entering the ALG and packets exiting the ALG no longer match 🧮 in transparent mode, the ALG MUST continue to adjust sequence numbers if it was doing so before entering transparent mode as the result of the AUTH command. the ALGS command (Section 11) can also be used to disable the ALG functionality, but the control channel MUST then still be monitored for subsequent ALGS commands that re-enable the ALG functionality 👑
5.1. Language Negotiation
[RFC2640] lets clients and servers negotiate the language used between the two of them in the descriptive text that comes with server response codes 🌍 ideally, IPv6-to-IPv4 FTP ALGs would support this feature, so that if a non-default language is negotiated by a client and a server, the ALG also sends its text messages for translated responses in the negotiated language. however, even if the ALG supports negotiating this feature, there is no way to make sure the ALG has text strings for every possible language 😭 so the situation where the client and server try to negotiate a language the ALG doesn't support is unavoidable. the proper behavior for an FTP ALG in this situation may be addressed in a future specification, since the same issue is present in IPv4-to-IPv4 FTP ALGs. for the time being, ALG implementations MAY employ one of the following strategies regarding LANG negotiation:
- Monitor
LANGnegotiation and send text in the negotiated language if text in that language is available. If not, text is sent in the default language. - Not monitor
LANGnegotiation. Text is sent in the default language. - Block
LANGnegotiation by translating theLANGcommand to aNOOPcommand and translating the resulting200response into a502response, which is appropriate for unsupported commands. Text is sent in the default language.
in the first two cases, if a language is negotiated, text sent by the client or the server MUST be assumed to be encoded in UTF-8 ([RFC3629]) rather than limited to 7-bit ASCII 🌸 an ALG that implements the first or second option MUST translate and/or forward commands and responses containing UTF-8-encoded text when those occur. the ALG itself MUST NOT generate characters outside the 7-bit ASCII range unless it implements the first option and a language was negotiated 🚫
note that Section 3.1 of [RFC2640] specifies new handling for spaces and the carriage return (CR) character in pathnames. ALGs that do not block LANG negotiation SHOULD comply with the specified rules for path handling. implementers should especially note that the NUL (%x00) character is used as an escape whenever a CR character occurs in a pathname 🫧
in the sections that follow, a number of well-known response numbers are shown, along with the descriptive text associated with each response number. however, this text is not part of the specification of the response. as such, implementations MAY use the response text shown, or they MAY show a different response text for a given response number. requirements language only applies to the response number ✨
6. EPSV to PASV Translation ✨
okay so bestie, EPSV is this super modern passive mode command, and most IPv4 FTP servers are totally fine with it 💖 but some servers absolutely lose it when they get EPSV, and there's no reliable way to know ahead of time which ones will 😭 (Section 1 has examples if you wanna see the drama). So the FTP ALG SHOULD translate every EPSV from the client into PASV and then reformat the 227 reply into a 229 reply 🎀. The only way out is if the ALG MAY skip the translation, but only if it has positive knowledge that EPSV will work without it. That knowledge can come from admin configuration or be learned dynamically 🧚
Here's how it plays out. If the client sends EPSV (or EPSV 2 to say it wants IPv6 as the network protocol), that gets turned into PASV. Then if the server at 192.0.2.31 replies with:
227 Entering Passive Mode (192,0,2,31,237,19)the FTP ALG rewrites it as:
229 Entering Extended Passive Mode (|||60691|)The ALG SHOULD ignore the IPv4 address in the server's 227 reply 🙈 That's what most clients do anyway, and it's needed for servers that stick [RFC1918] addresses in their 227 replies. Now, if the 227 reply has an IPv4 address that doesn't match the destination of the control channel, the FTP ALG MAY send a 425 reply to the client instead of the 229 reply, like this:
425 Can't open data connectionIt's really important that this reply is in the 4xx range, because that's what says "temporary condition" 💅
If the client sends EPSV with a numeric argument other than 2, the ALG MUST NOT pass that command on to the server. Instead it responds with a 522 error, like:
522 Network protocol not supportedAnd if the client sends EPSV ALL, the FTP ALG MUST NOT pass that to the server either. It responds with a 504 error instead:
504 Command not implemented for that parameterWhy all the fuss? Because some FTP servers react badly to a PASV command after the client already said "EPSV ALL" to mean it's only using EPSV this session 💀 This rule keeps that from happening.
7. EPRT to PORT Translation 🦋
Should the IPv6 client send an EPRT command, the FTP ALG MAY translate it into a PORT command. How it does that depends on whether the translator is stateless (one-to-one) or stateful (one-to-many), so we're splitting it up 🌸
7.1. Stateless EPRT Translation
If the address in the EPRT command is the IPv6 address the client is using for the control channel, the FTP ALG rewrites the EPRT command as a PORT command using the IPv4 address that maps to the client's IPv6 address. The port number MUST be preserved so that stateless translators keep working 🫶 For example, if the client with IPv6 address 2001:db8:2::31 sends this:
EPRT |2|2001:db8:2::31|5282|and 2001:db8:2::31 goes with the IPv4 address 192.0.2.31, the FTP ALG turns it into:
PORT 192,0,2,31,20,162Now, if the address in the EPRT command is an IPv4 address, or an IPv6 address that isn't the one the client is using for the control session, the ALG SHOULD NOT try any translation. It just passes the command along unchanged 🌈
7.2. Stateful EPRT Translation
If the address in the EPRT command is the IPv6 address the client uses for the control channel, the stateful translator picks an unused port number. It pairs that port with the IPv4 address used for the control channel toward the FTP server, and then sets up a mapping from that transport address to the one the client gave in the EPRT command ✨ The PORT command, with the IPv4 address and port from the IPv4 side of the mapping, only gets sent to the server once the mapping exists. At first the mapping accepts either any transport address, or the FTP server's IPv4 address with any port number, as a source. But once the three-way handshake is done, the mapping SHOULD be narrowed down to match only the negotiated TCP session 🔥
Again, if the address in the EPRT command is an IPv4 address, or an IPv6 address that isn't the one the client uses for the control session, the ALG SHOULD NOT attempt any translation and just passes the command along unchanged.
Let's walk through an example. The client with IPv6 address 2001:db8:2::31 sends:
EPRT |2|2001:db8:2::31|5282|and the stateful translator uses 192.0.2.31 on its IPv4 interface. A mapping can be created with destination address 192.0.2.31 and destination port 60192, pointing toward 2001:db8:2::31 port 5282. After that, the FTP ALG rewrites the EPRT command as:
PORT 192,0,2,31,235,328. Default Port 20 Translation 👑
If the client doesn't send an EPSV/PASV or EPRT/PORT command before starting a file transfer, it's using the default active FTP behavior, where the server opens a TCP session toward the client 💜
In this case the source port is the default FTP data port (port 20), and the destination port is whatever port the client used as its source port for the control channel session.
With a stateless translator, this is no problem at all ✨ With a stateful translator, the translator MAY accept incoming connection requests from the server on the IPv4 side, as long as the transport addresses match an existing FTP control channel session. The one difference is that the control channel uses port 21 and the new session uses port 20. When that happens, a mapping is set up toward the same transport address on the IPv6 side that the matching FTP control channel session uses 🦋
An ALG/translator MAY also keep an eye on the progress of FTP control channels, and only try to create a mapping when an FTP client starts a file transfer without issuing the EPSV, PASV, EPRT, or PORT commands 🎀
9. Both PORT and PASV 🙈
[RFC0959] lets a client send both PORT and PASV so it can use non-default ports on both sides of the connection. But that's basically a contradiction 😭 With PASV, the data connection is made from the client to the server, while PORT goes back to the default behavior where the server connects to the client. So the behavior of an ALG is undefined when a client sends both PASV and PORT. Implementations SHOULD NOT try to detect when both PASV and PORT commands have been issued before a command that starts a transfer. They should just translate commands as they show up 💅 So if a client sends PASV, the PASV gets translated to EPSV. If, after that and before any transfers happen, the client sends PORT and the ALG supports PORT translation for that session, the ALG translates the PORT into EPRT.
10. Default Behavior 🌸
Whenever the client sends a command that the ALG isn't set up to translate, the command MUST be passed on to the server without modification, and the server's response MUST be passed on to the client without modification. This applies if the command isn't covered in this document, if it isn't part of any FTP specification, if the ALG functionality is turned off administratively for that command, or if translation doesn't apply for any other reason 🧚 For example, if the client sends PASV, it goes straight to the server, and the server's reply goes straight back to the client, totally transparent ✨
11. The ALGS Command 💖
ALGs MUST support the new ALGS (ALG status) command, which lets clients check and change the ALG's status 🔥 FTP servers (as opposed to ALGs) MUST NOT do anything when they get the ALGS command. But they MUST still send a response. If an FTP server does recognize the ALGS command, the best move would be to return a 202 response:
202 Command not implemented, superfluous at this siteHonestly though, there's no real reason for FTP servers to specifically recognize this command 🙄 Returning any 50x response that's normally used for unrecognized commands is totally fine.
A client can use the ALGS command to ask for the ALG's status, and to turn EPSV to PASV translation on or off, plus EPRT to PORT translation if the ALG has it. There are three possible arguments to the ALGS command:
ALGS STATUS64 The ALG is requested to return the EPSV and EPRT
translation status.
ALGS ENABLE64 The ALG is requested to enable translation.
ALGS DISABLE64 The ALG is requested to disable translation.The ALG MUST enable or disable EPSV to PASV translation as the client asks. If the ALG supports EPRT to PORT translation, ALGS ENABLE64 SHOULD turn that on too, and ALGS DISABLE64 MUST turn it off alongside EPSV to PASV translation. If EPRT to PORT translation isn't supported, ALGS ENABLE64 only enables EPSV to PASV translation. After any ALGS command with one of the three supported arguments, the ALG MUST return a 216 response that says what kind of translation it'll do 🦋
216 NONE Neither EPSV nor EPRT translation is performed.
216 EPSV EPSV is translated to PASV; no EPRT translation is
performed.
216 EPSVEPRT EPSV is translated to PASV; EPRT is translated to
PORT.The translation type MAY be followed by a space and extra descriptive text, running until the end of the line. If the ALG can't set the requested translation mode, say because it's short on certain resources, that's not treated as an error ✨ In that case the ALG returns a 216 response followed by the keyword showing its current translation status.
If there's no argument to the ALGS command, or the argument isn't STATUS64, ENABLE64, or DISABLE64 (or an argument from a supported newer document), a 504 or 502 error SHOULD be returned 💀
Here's the Augmented Backus-Naur Form (ABNF) notation (see [RFC5234]) for the ALGS command and its response:
algs-command = "ALGS" SP algs-token CRLF
algs-token = "STATUS64" / "ENABLE64" / "DISABLE64"
algs-response = (ok-response / error-response) CRLF
ok-response = "216" SP response-token [ freetext ]
response-token = "NONE" / "EPSV" / "EPSVEPRT"
error-response = not-implemented / invalid-parameter
not-implemented = "502" [ freetext ]
invalid-parameter = "504" [ freetext ]
freetext = (SP *VCHAR)12. Timeouts and Translating to NOOP ⏰
Wherever possible, control channels SHOULD NOT time out while there's an active data channel 🫶 A timeout of at least 30 seconds is RECOMMENDED for data channel mappings created by the FTP ALG that are still waiting for their first packets.
Whenever a command from the client doesn't get propagated to the server, the FTP ALG issues a NOOP command instead. That keeps the keepalive state between the client and the server in sync 🧚 The response to that NOOP command MUST NOT be relayed back to the client. An implementation MAY wait for the server to send its 200 response to the NOOP command, then translate that 200 response into whatever response the ALG is required to send to the client. That way the ALG never has to create new packets for the client, and can just modify packets the server sends 💅 If the server answers the NOOP command with anything other than a 200 response, the ALG SHOULD tear down the control channel session and log an error 💀
13. IANA Considerations ✨
okay so IANA is the org that keeps all the official lists for the Internet, and they added a brand new entry to the "FTP Commands and Extensions" registry 📋🎀
Here's the entry, bestie 💅:
Command Name ALGS
FEAT Code -N/A-
Description FTP64 ALG status
Command Type -N/A-
Conformance Requirements o
Reference RFC 6384 Section 11Basically the ALGS command gets its own little spot in the registry, pointing right back at Section 11 🦋
14. Security Considerations 🔐
okay this section is SO important, so let's get into it 😭
In most cases, FTP just gets used with no extra security stuff at all 💀 That means an attacker who can quietly watch the traffic can grab login credentials, and an attacker who can change packets can mess with the data being transferred. Not cute at all!
FTP can be paired with TLS to fix these problems 🔒 IPv6-to-IPv4 translation and the FTP ALG don't change these security issues when FTP runs without TLS. But when FTP is used with TLS as per [RFC4217], or with some other authentication mechanism the ALG knows about, the ALG function is not performed. So only passive transfers will work: a server that implements EPSV, or a client that supports PASV 🫶
For general FTP security stuff, check out [RFC2577] 💜
15. Contributors 🌸
These amazing people contributed ideas and comments: Dan Wing, Kentaro Ebisawa, Remi Denis-Courmont, Mayuresh Bakshi, Sarat Kamisetty, Reinaldo Penno, Alun Jones, Dave Thaler, Mohammed Boucadair, Mikael Abrahamsson, Dapeng Liu, Michael Liu, Andrew Sullivan, Anthony Bryan, Ed Jankiewicz Pekka Savola, Fernando Gont, Rockson Li, and Donald Eastlake ✨
Dan Wing's experiments with a large number of FTP servers were super illuminating 🤩 Many of the choices in this document are based on his results, so he's literally a main character 👑
16. Acknowledgements 🧚
Iljitsch van Beijnum is partly funded by Trilogy, a research project supported by the European Commission under its Seventh Framework Program 💖
17. References 📚
17.1. Normative References
[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2228] Horowitz, M., "FTP Security Extensions", RFC 2228, October 1997.
[RFC2428] Allman, M., Ostermann, S., and C. Metz, "FTP Extensions for IPv6 and NATs", RFC 2428, September 1998.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
17.2. Informative References
[RFC1639] Piscitello, D., "FTP Operation Over Big Address Records (FOOBAR)", RFC 1639, June 1994.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC2389] Hethmon, P. and R. Elz, "Feature negotiation mechanism for the File Transfer Protocol", RFC 2389, August 1998.
[RFC2577] Allman, M. and S. Ostermann, "FTP Security Considerations", RFC 2577, May 1999.
[RFC2640] Curtin, B., "Internationalization of the File Transfer Protocol", RFC 2640, July 1999.
[RFC4217] Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217, October 2005.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
Author's Address 💌
Iljitsch van Beijnum Institute IMDEA Networks Avda. del Mar Mediterraneo, 22 Leganes, Madrid 28918 Spain
EMail: iljitsch@muada.com
That's a wrap on RFC 6384 bestie!! 🎀💖 You made it through the whole thing 🦋✨
📦 where this page comes from
- ietf: rfc6384 2011-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms