FTP Extensions for IPv6 and NATs
Extracted elements (24)
EPRT and EPSV replace PORT and PASV rather than extending them because the original commands assume 32-bit IPv4 addresses and cannot accommodate variable-length addresses required by IPv6 or future network protocols. RFC 1639 (FOOBAR) was found to fail in multi-protocol environments.
EPSV was designed to omit the network address from its response (unlike PASV) so that NATs do not need to rewrite the data portion of control-connection segments. Using EPSV means NATs only need to track the port, not translate embedded addresses.
The 'EPSV ALL' command was introduced to allow NATs to place the FTP connection on a 'fast path' through the translator: since EPRT will never be used after this command, NATs know they will never need to translate data-portion addresses.
The EPSV response format deliberately includes placeholder fields for future network protocol and address information (the two leading blank fields inside parentheses), allowing the same parsing routines to handle both EPRT arguments and EPSV responses.
EPSV is preferred over PORT/EPRT for firewall traversal because firewalls generally do not allow incoming connections required by the active (PORT/EPRT) mode; passive mode (EPSV) uses only outgoing connections from the client.
RFC 1639 (FTP Operation Over Big Address Records) provided earlier extensions for non-IPv4 FTP but was found to fail in multi-protocol environments during IPv4-to-IPv6 transition; RFC 2428 supersedes that approach for IPv6.
For all FTP transfers where the control and data connections are established between the same two machines, the EPSV command MUST be used (not PORT/PASV).
If a client has issued 'EPSV ALL' but later needs to perform a three-way FTP transfer, a new FTP session MUST be started.
If the server returns a protocol via EPSV that is not supported by the connecting host, the client MUST issue an ABOR command to allow the server to close the listening connection before requesting a specific protocol.
In an EPSV data connection, the network protocol and network address used MUST be the same as those used for the control connection; only the port is specified in the response.
The <net-addr> for address family 1 (IPv4) MUST be in dotted-decimal format (e.g., 132.235.1.2), and for address family 2 (IPv6) MUST use the IPv6 string representations defined in RFC 2373.
The response code for entering passive mode via EPSV MUST be 229 (Extended Passive Mode Entered).
Upon receipt of a valid EPRT command, the server MUST return response code 200 (Command OK).
Upon receipt of an 'EPSV ALL' command, the server MUST reject all data connection setup commands other than EPSV (including EPRT, PORT, PASV, and similar commands).
When a client only expects to perform two-way FTP transfers, it SHOULD issue the 'EPSV ALL' command as soon as possible to enable NAT fast-path optimization.
When EPSV is issued with a specific protocol argument and the server supports it, the server SHOULD use that protocol. If unsupported, the server MUST return the 522 error.
When returning a 522 error, the response text MUST indicate which network protocols are supported, with the supported protocol list as comma-separated address family numbers enclosed in parentheses. The textual message before the '(' MUST NOT include the characters '(' or ')'.
Response code 522 (Extended Port Failure - unknown network protocol) is defined to indicate the server does not support the requested network protocol specified in an EPRT command.
The EPRT command replaces PORT for extended address data connections. Its format is: EPRT<space><d><net-prt><d><net-addr><d><tcp-port><d>, where <d> is a delimiter character and <net-prt> is an IANA address family number.
The EPSV command replaces PASV for extended passive mode. It takes an optional argument (a network protocol number or 'ALL') and returns only the TCP port number in its response, not the network address.
The <net-prt> field in EPRT/EPSV uses IANA address family numbers from the Assigned Numbers RFC (RFC 1700). This document registers usage of AF number 1 (IPv4) and AF number 2 (IPv6) for FTP extended commands.
The authors state that the EPRT/EPSV extensions do not introduce new security problems beyond those already present in FTP. A companion document (Work in Progress at time of publication) addressed general FTP security issues.
The EPRT delimiter character MUST be a single ASCII character in the range 33-126 inclusive; '|' (ASCII 124) is recommended. The <net-prt> field is an IANA address family number; <net-addr> is a protocol-specific string; <tcp-port> is the decimal TCP port number.
The EPSV response text MUST match the format: <text>(<d><d><d><tcp-port><d>). The first two fields inside the parentheses MUST be blank; the third field MUST be the TCP port number string. Example: 'Entering Extended Passive Mode (|||6446|)'.