Can anyone simply explain the differences between Passive mode FTP (PASV) and Extended Passive mode FTP (EPSV)?

  • 2
    @DavidPostill Sorry, I was really only interested in PASV vs EPSV. – CGCampbell Aug 22 '14 at 13:41

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||6275|

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

In conclusion, IPv6 support is the only difference.

  • Wow, all the sites I read and it didn't click until this one. Thank you for that. I'll accept it (probably) in an hour or two, want to see if anyone else does it different. Also, the reason I asked for Active as well was that due to the tagging working well with google, this question/answer will be found in searches. If no one adds to the answer (making it more totally complete for a google answer) I'll edit my original question and body to reflect the contents of your answer, essentially fitting my question to your answer. – CGCampbell Aug 22 '14 at 13:34
  • 3
    Another difference is that the EPSV response does not include the IP address (what PASV response does). This is to avoid common problem when the FTP server located behind a NAT does not know it's external IP address and confuses the FTP client by sending it its internal address. – Martin Prikryl Jan 7 '15 at 13:33
  • To add to what @MartinPrikryl says, another reason is when using FTP-over-TLS, the firewall/NAT can't intercept the IP address in the PASV command to rewrite it (at least without MITMing the control connection.) While in the Unix world people generally use SFTP instead of FTP-over-TLS, FTP-over-TLS is commonly used with IBM mainframes, since FTP has support for record-oriented files (STRU R, MODE B), while SFTP only supports stream-oriented files – Simon Kissane Oct 30 '18 at 1:42

Difference between active and passive is already answered. Extented passive (EPSV) is just passive with IPv4 and IPv6, because the syntax of the response to PASV was specific to IPv4 and and thus a new command was needed for IPv6. Same with EPTR vs. PORT in active mode. There is a slightly different behavior with EPRT and EPSV in that they can only contain the port,not IP and port like PORT and PASV do. Thus data transfer can only be done between the systems which have the control connection. With PORT and PASV it is possible to create a data connection between other systems (although this is today considered bad design and a security risk).

  • 2
    This was the kind of answer I didn't want. It tells me exactly as much as I could find elsewhere, which is that EPSV was created for IPv6, but not explaining why. (i.e. I don't accept your reason as a good enough explanation) I'm telling you this in the hope you'll maybe make your answer even better. – CGCampbell Aug 22 '14 at 13:36
  • Edited response to make it clear, that the response to the PASV command to not support IPv6 and thus a new command was needed. – Steffen Ullrich Aug 22 '14 at 18:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.