An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation
Extracted elements (33)
EPRT translation through stateful translators is significantly more complex than EPSV translation because a translation mapping must be set up from parameters learned from the control channel before the PORT command can be issued to the server, requiring tight ALG/translator coupling.
The ALG SHOULD ignore the IPv4 address embedded in the server's 227 PASV response because most clients also ignore it, and this is needed to work with servers that include RFC 1918 private addresses in their 227 responses.
The ALG translates EPSV to PASV (rather than leaving EPSV in place) because a survey found only ~65% of FTP servers support EPSV successfully vs ~96% for PASV, and some servers react adversely to EPSV with connection resets, possibly due to EPSV-unaware application firewalls blocking the data channel.
When a client command is not relayed to the server, the ALG sends a NOOP instead so that keepalive state between client and server remains synchronized and the server session does not time out unexpectedly.
When EPSV ALL is received, the ALG MUST NOT pass it to the server and instead returns 504, because if the server accepts EPSV ALL it would reject subsequent PASV commands that the ALG needs to issue as part of EPSV-to-PASV translation.
If the address specified in an EPRT command is an IPv4 address or an IPv6 address that is not the client's control channel IPv6 address, the ALG SHOULD NOT attempt any translation but pass along the command unchanged.
The behavior of an ALG is undefined when a client issues both PASV and PORT before a transfer command. Implementations SHOULD NOT try to detect this situation but rather translate commands as they occur sequentially.
The document does not address the LPRT and LPSV commands from RFC 1639 as these commands do not appear to be in significant use.
When an FTP client uses AUTH to negotiate TLS (RFC 4217) or another security mechanism, the ALG enters transparent mode and can no longer translate FTP commands, meaning only passive transfers from a server that implements EPSV or a client that supports PASV will succeed.
After an ALGS command with any of the three supported arguments, the ALG MUST return a 216 response indicating the type of translation that will be performed. The ALG MUST enable or disable EPSV to PASV translation as requested.
ALGs MUST support the new ALGS command that allows clients to query and set the ALG's status. FTP servers MUST NOT perform any actions upon receiving the ALGS command but MUST still send a response.
An ALG MUST adopt the first option (transparent copy) and allow a client and server to negotiate security mechanisms. 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.
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.
An ALG used with a stateful translator MUST support EPSV translation and MAY support EPRT translation. An ALG used with a stateless translator MUST support EPSV translation and SHOULD also support EPRT translation.
An FTP ALG SHOULD translate all occurrences of the EPSV command issued by the client to the PASV command and reformat a 227 response as a corresponding 229 response. An ALG MAY forego this translation if it has positive knowledge that EPSV will succeed without translation.
Control channels SHOULD NOT time out while there is an active data channel. A timeout of at least 30 seconds is RECOMMENDED for data channel mappings created by the FTP ALG that are waiting for initial packets.
For stateful EPRT translation, once the three-way handshake is complete, the mapping SHOULD be narrowed to only match the negotiated TCP session.
For stateless EPRT translation, the port number MUST be preserved for compatibility with stateless translators when reformatting an EPRT command into a PORT command.
If the client issues an EPSV command with a numeric argument other than 2, the ALG MUST NOT pass the command on to the server but rather respond with a 522 error. If the client issues EPSV ALL, the FTP ALG MUST NOT pass this command to the server, but respond with a 504 error.
In language negotiation, if a language is negotiated, text transmitted by the client or the server MUST be assumed to be encoded in UTF-8. An ALG that implements the first or second option MUST translate and/or forward commands and responses containing UTF-8-encoded text.
In the packet-translation implementation strategy, 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.
Telnet option negotiation attempts by either the client or the server, except for those allowed by RFC 1123, MUST be refused by the FTP ALG without relaying those attempts. For the purpose of Telnet option negotiation, an FTP ALG MUST follow the behavior of an FTP server as specified in RFC 1123 Section 4.1.2.12.
The ALG SHOULD ignore the AUTH command and not go into transparent mode if the server response is in the 4xx or 5xx ranges. In transparent mode, the ALG MUST continue to adjust sequence numbers if it was doing so before entering transparent mode.
Whenever a command from the client is not propagated to the server, the FTP ALG instead issues a NOOP command to keep keepalive state synchronized. The response to the NOOP command MUST NOT be relayed back to the client.
Whenever the client issues a command that the ALG is not set up to translate, the command MUST be passed on to the server without modification, and the server response MUST be passed on to the client without modification.
EPRT-to-PORT translation for stateful translators: the ALG selects an unused port on its IPv4 interface, creates a mapping to the client's IPv6 transport address, and only issues the PORT command to the server after the mapping is established.
EPRT-to-PORT translation for stateless translators: the ALG maps the client's IPv6 address to its corresponding IPv4 address and preserves the port number, reformatting `EPRT |2|ipv6addr|port|` into `PORT a,b,c,d,p1,p2`.
EPSV-to-PASV translation: when the client issues EPSV (or EPSV 2), the ALG translates it to PASV toward the server and reformats the 227 response (with embedded IPv4 address and port) into a 229 response containing only the port number in the extended passive mode format `(|||port|)`.
The ALGS (ALG status) command allows FTP clients to query and set the translation status of an FTP ALG. It takes one of three arguments: STATUS64 (query status), ENABLE64 (enable translation), or DISABLE64 (disable translation).
The ALGS command returns a 216 response with one of three keywords: NONE (no translation), EPSV (EPSV to PASV only), or EPSVEPRT (both EPSV-to-PASV and EPRT-to-PORT translation active).
IANA has added the ALGS command to the 'FTP Commands and Extensions' registry with FEAT Code -N/A-, description 'FTP64 ALG status', Command Type -N/A-, Conformance Requirements 'o', referencing RFC 6384 Section 11.
FTP is commonly used without security mechanisms, allowing passive interception of credentials and active modification of transferred data. FTP over TLS (RFC 4217) addresses these issues, and IPv6-to-IPv4 translation and the FTP ALG do not impact these security properties. However, when TLS is negotiated, the ALG exits translation mode and only extended-passive-capable servers or PASV-capable clients will succeed.
The ALGS command syntax (ABNF): `algs-command = "ALGS" SP algs-token CRLF` where `algs-token = "STATUS64" / "ENABLE64" / "DISABLE64"`. The response is `"216" SP response-token [ freetext ] CRLF` where `response-token = "NONE" / "EPSV" / "EPSVEPRT"`.