RFC 478

FTP Server-Server Interaction-II ✨

Okay bestie, here's the header info 🎀. This is RFC 478, "FTP Server-Server Interaction-II," from the Network Working Group. It was written by B. Bressler and B. Thomas at BBN (NIC 14947) and dated 26 March 1973. The title block doesn't list anything it obsoletes or updates, so it's a standalone doc 💅.

At the recent FTP meeting at BBN in Cambridge, server-server interaction came up as a topic 🫶. The typical setup is a user (A) chatting with two servers (B, C) who wants to grab a file from one site (B) and send it to the other (C).

                      +------+
                      | USER |
                      |   A  |
                     /+------+\
               control        control
                  /              \
            +------+            +------+
            |SERVER|    DATA    |SERVER|
            |   B  |----------->|  C   |
            +------+            +------+

The meeting consensus was that B and C needed some way to be aware of each other 👀. They also needed to set up a data connection without making each other queue up RFCs for local sockets that don't exist yet. Totally fair, no cap 🙈.

The solution everyone liked was a command called PASSIVE (PASV?) 🦋. Here's what we figured it means and how it'd get used.

Third party connections would be set up with the SOCK command, which says "Be prepared to use socket S at Host H to establish your data connection." Then there's PASV, which says "open your data socket for listening, and upon receipt of a transfer command wait for an RFC rather than initiating one." 🧚

A positive acknowledgement (ACK) to PASV means the data socket is open for listening 🌸. When an RFC for that data socket shows up after the server has ACKed a PASV, the server should respond with a matching RFC to open the data connection. This assumes the incoming RFC matches any previous SOCK commands, if there were any. Main character energy, but make sure the details line up 💖.

           +---------------+
           |               |
   +-------| USER PROCESS  |-------+
   |       |       A       |       |
 telnet    +---------------+    telnet
   |                              |
   |                              |
+-----------+              +-------------+
|           |-------->  -------->|             |
|  SERVER   |data sockets  data socket|   SERVER    |
|     B     |    Sb           Sc      |     C       |
|           |<--------  <--------|             |
+-----------+              +-------------+

USER A TO SERVER B                     USER A TO SERVER C
__________________                     __________________

A->B   SOCK  HOST-C  SKT- Sc           A->C   SOCK  HOST-B  SKT-  Sb

B->A       ACK                         C->A      ACK

A->B   PASV

B->A       ACK

A->B   STOR                            A->C   RTRV

Here's the play-by-play 🎬:

1. Once PASV has been ACKed, the two data transfer commands can be sent in either order. The LISTENING action happens with the PASV command, so the order doesn't matter 🔥.
2. The user knows the socket numbers Sc and Sb as the data sockets, as the protocol specifies 🍓.
3. A SOCK command doesn't have to go to the same Host that gets the PASV. Still, sending it to him gives you security, since the incoming RFC can be checked 🫶.

Heads up: sending the SOCK command to the same Host that gets the PASV is what lets the incoming RFC be checked. That's the security perk, so don't skip it if you care about that 🔐.

RB/nlg 💜

[This RFC was put into machine readable form for entry] [into the online RFC archives by Helene Morin, Via Genie 12/1999]