FTP – Differences Between Passive and Extended Passive Modes

The only difference is that PORT/PASV are limited to IPv4, while EPRT/EPSV work with any network protocol (although only IPv6 is used in practice).

The standard PORT (active) and PASV (passive) commands in the FTP control protocol exchange address & port information as six 1-byte decimals, from which the other end has to reconstruct a four-byte IP address and two-byte TCP port number.

PORT <address[4]>,<port[2]>

PORT 132,235,1,2,24,131

But then other protocols started appearing. IPv4 was about to be replaced with "IPng", which had quite a few competing replacement proposals (OSI CLNP, TUBA, SIP, SIPP, CATNIP – at various times in history), some with shorter, longer, even variable host address sizes, until IPv6 with 16 byte addresses finally got defined.

Just sending more bytes wouldn't have worked – servers and clients couldn't be expected to know the right protocol based purely on the address length. (For example, what if you have one protocol with 16 byte address + 4 byte port, another with 12 byte address + 12 byte port?)

Besides – even though this was less important 20 years ago – these days there are millions of NAT devices on the Internet, which inspect and mangle FTP control connections so that the "outside" host would only see global IPv4 addresses even if the "inside" host sent a RFC1918 local one. Even without NAT, stateful firewalls often watch the control commands to automatically allow a data connection without manual rules.

This basically means that simply sending more numbers with PORT or PASV is guaranteed to break for many people. Perhaps some firewalls would quietly misinterpret some address bytes as the port and quietly discard the rest; others might drop the connection, or just crash.

To avoid various problems like the above, new commands had to be introduced for multi-protocol support in FTP.

In 1993, RFC 1639 (originally RFC 1545) introduced the "long address" LPRT and LPSV commands, which were like PORT & PASV but with a variable address length; they included the protocol type identifier as well. (It didn't change the syntax though – IPv6 address:port would simply be sent as 21 numbers rather than six.)

LPRT <protocol>,<addr-length>,<address...>,<port-length>,<port...>

LPRT 4,4,132,235,1,2,2,24,131

LPRT 6,16,16,128,0,0,0,0,0,0,0,8,8,0,32,12,65,122,2,20,162

However, that still didn't fix some of the problems, such as asking a server to use a different protocol than for the control connection. The RFC also quickly became out of date as well; when IPv6 came out just a year later, it couldn't be used with LPRT because there was no LPRT protocol identifier assigned for it (only for the various early proposals).

To fix this, RFC 2428 in 1998 added EPRT and EPSV, aka "extended port" and "extended passive", which also had a method for negotiating a protocol that both ends support. The "extended" commands also send addresses in human-readable form – for IPv6, that means using hex & colon notation, rather than a series of separate decimal numbers.

EPRT x<protocol>x<address>x<port>x

EPRT |1|132.235.1.2|6275|

EPRT |2|1080::8:800:200C:417A|5282|

In conclusion, IPv6 support is the only difference.