FTP's Long Evolution: From ARPANET File Sharing to RFC 959
Trace FTP from its 1971 ARPANET proposal through RFC 959, its two-connection design, later IPv6 and TLS extensions, and the limits of the original security model.
File Transfer Protocol (FTP) is older than the TCP/IP Internet most people associate with it. Its history began in the ARPANET era, when a network protocol had to make file operations possible across hosts with different operating systems, storage conventions, and character representations. The modern FTP specification is therefore not a single invention frozen in 1985, but one point in a documented sequence of proposals, revisions, and extensions.
That history matters operationally. FTP’s separation of command control from bulk data transfer solved a real interoperability problem, but it left clients and network equipment managing multiple connections. Later IPv6, firewall, and TLS extensions adapted the protocol without erasing that architectural shape.
1971: a protocol for sharing files across unlike hosts
Abhay Bhushan’s RFC 114, published on April 16, 1971, proposed a file-transfer protocol for the ARPANET. The motivation was broader than copying bytes: network users wanted indirect access to remote systems without first learning each host’s local conventions. RFC 114 describes requests such as retrieve, store, append, delete, rename, and execute, and recognizes that cooperating hosts may represent data differently.
This was a proposal for the network and computing environment of its time, not the FTP service later carried over TCP. The protocol used the ARPANET’s then-current networking mechanisms and described transactions between cooperating host processes. It treated file naming, data types, records, and errors as protocol concerns because a PDP-10, Multics system, or another host could have different local rules. RFC 114 also explicitly presents itself as an initial design intended to be extendible; it should not be read as though its commands and transport details were already the modern protocol.
The next years produced a chain of revisions and comments. RFC 959’s historical appendix lists RFC 114, RFC 141, RFC 172, RFC 265, and other FTP-related documents, preserving evidence that this was iterative standards work rather than a one-time specification. RFC 542, published in 1973, became another major specification in that lineage and was later superseded by RFC 765.
1980: the protocol is described for TCP/IP networking
Jon Postel’s RFC 765, published in June 1980, describes FTP with its control connection established over TCP and assigns the server’s control service port 21. It defines the protocol interpreter (PI), which exchanges commands and replies, separately from the data transfer process (DTP), which moves file data. The distinction lets a client keep a control conversation while establishing and closing data connections for individual transfers.
FTP also had to negotiate what the bytes meant. RFC 765 distinguishes a file’s logical byte size from the eight-bit transfer byte size, and defines representation types such as ASCII, EBCDIC, and image. ASCII is the required default for interoperability, but it is not a promise that every file is an opaque sequence of bytes: the sending and receiving systems can translate text representations. Image (binary) representation is the usual choice when the goal is to preserve the file’s byte content. The protocol additionally describes file, record, and page structures and stream, block, and compressed transmission modes, although many everyday implementations use the simpler file-structure and stream-mode defaults.
These choices show the environment RFC 765 was designed for: machines might disagree about character encodings, record boundaries, and storage conventions. FTP attempted to make those differences explicit and negotiable instead of silently assuming every host stored files in the same way.
1985: RFC 959 consolidates the familiar FTP model
RFC 959, authored by Jon Postel and Joyce Reynolds and published in October 1985, obsoleted RFC 765 and became the familiar base specification. It describes FTP’s model, command syntax, reply codes, data-transfer functions, and state diagrams. The control connection carries commands such as USER, TYPE, PORT, PASV, RETR, and STOR; file contents travel on a separate data connection.
In active operation, the client tells the server which client-side endpoint to use for the data connection, traditionally with PORT; the server initiates that connection. With passive operation, the client asks the server to listen for a data connection with PASV, then connects to the endpoint the server reports. The separate connection made transfer behavior explicit and supported server-to-server transfers, but it also meant that a firewall or address translator could not always reason about a session from the control connection alone. Firewalls had to handle a dynamically negotiated data endpoint, and active mode could require inbound connectivity toward the client.
The design is often summarized as “FTP uses two connections,” but that shorthand needs precision: there is a long-lived control connection and a data connection associated with transfer activity; the data connection’s direction and endpoint setup depend on the selected mode. It is this control/data split - not simply the use of TCP - that explains many of FTP’s NAT and firewall complications.
Extensions adapted the design rather than replacing it
RFC 2428, published in 1998, introduced EPRT and EPSV so FTP could express data endpoints for protocols beyond IPv4 and work better with address translation. In particular, extended passive mode can avoid placing a full IPv4 address and port tuple in the control-channel response, which helps when the control peer’s visible address differs from the server’s local address. These commands extend endpoint negotiation; they do not collapse the control and data channels into one.
Other extensions filled gaps in the original specification. RFC 2228 defined security commands and negotiation mechanisms for authentication, integrity, and confidentiality. RFC 4217 later specifies how to use TLS with FTP through commands such as AUTH, PBSZ, and PROT. A client and server must actually negotiate and apply the intended protection: merely using FTP, or seeing a successful login, does not establish that either channel is encrypted. Similarly, support for one secure control channel does not by itself prove that the data channel is protected; the negotiated data-protection level matters.
RFC 959 was also updated by specifications covering internationalization, extensions, security, and virtual-host selection. This is why “FTP” can refer to a family of compatible behaviors, not just the base 1985 document. For a production deployment, the server’s supported extensions and the client’s configuration are more informative than the protocol name alone.
What the history teaches about compatibility and security
FTP’s longevity came from a clear separation of responsibilities and a protocol that made data representation and file operations explicit. Those same features created lasting costs: a second connection complicates routing through NATs and firewalls, and the original specification did not provide modern transport confidentiality. RFC 2577 later catalogued security concerns, while RFC 4217 provides a standards-based TLS mechanism; neither fact means every server enables those protections by default.
For historical or operational work, distinguish three questions: which specification generation is being discussed, how its data channel is established, and whether both control and data traffic receive the required protection. RFC 114 is evidence of an early ARPANET proposal; RFC 765 documents the TCP-based architecture; RFC 959 consolidates the classic model; later RFCs describe specific extensions. Keeping those layers separate avoids common myths, such as treating the 1971 proposal as though it already used today’s TCP port 21, or assuming that every FTP session is encrypted because a secure FTP extension exists.
Related:
- How to Read and Understand Old Internet RFCs
- NTP: How David Mills Made Distributed Computers Agree on Time
Sources: