Port 21: FTP Control — The Internet's First Filing Cabinet

Port 21 is the command channel for the File Transfer Protocol. Every time an FTP client connects to a server, this is the port that answers. It handles the login, takes the instructions, reports the results. But port 21 never touches a file. The actual data travels on a separate connection entirely. Port 21 only carries the conversation.

FTP is the oldest application-layer protocol still recognizable on the modern Internet. It was written in 1971. It predates email, the World Wide Web, and the very TCP/IP stack it runs on today.

How FTP Works

FTP does something unusual: it uses two separate connections where every other protocol uses one.

Port 21 is the control channel. It stays open for the entire session. The client sends commands ("give me this file," "list that directory," "delete this") and the server responds with three-digit status codes. No file data ever crosses this connection. It is purely conversational.

Port 20 (or a negotiated alternative) is the data channel. It opens temporarily when a file needs to move, then closes when the transfer completes. This separation means you can browse directories, rename files, and check permissions without ever opening a data connection.

This dual-channel architecture was elegant in 1971. It became a headache by 2001, when firewalls became standard and the protocol's assumptions about who connects to whom started breaking down.

Active Mode vs. Passive Mode

In active mode, the client tells the server "I'm listening on port X, connect to me." The server then initiates a connection from port 20 back to the client. This worked when both machines sat on the same open network. It fails catastrophically when the client sits behind a firewall or NAT device, because an unsolicited inbound connection looks indistinguishable from an attack.¹

Passive mode reverses the flow. The client sends the PASV command, the server opens a random high-numbered port and says "connect to me here." Now the client initiates both connections, outbound, which firewalls generally permit. Passive mode is why FTP still works at all in the modern Internet.¹

The Reply Code System

FTP's three-digit reply codes were designed for both machines and humans. The first digit tells the client what happened: 2xx means success, 4xx means temporary failure, 5xx means permanent failure. The rest of the digits, and the human-readable text that follows, are for the person watching the terminal.²

220 Welcome to the FTP server
331 Username OK, need password
230 User logged in, proceed
250 Directory changed to /pub
150 Opening data connection
226 Transfer complete

This design pattern, numeric codes for machines with text for humans, became the template for SMTP, HTTP, and nearly every command-response protocol that followed.

The History

1971: Before Everything

On April 16, 1971, Abhay Bhushan, a graduate student at MIT's Project MAC, published RFC 114: the first specification for the File Transfer Protocol.³

Bhushan was born in Allahabad, India, in 1944. He graduated top of his class in electrical engineering from IIT Kanpur in 1965, one of the institute's first graduating classes, then came to MIT where he earned master's degrees in both electrical engineering and management.⁴

To understand what Bhushan built and why, you need to understand what didn't exist yet. In 1971, the ARPANET connected roughly 15 computers at universities and research labs across the United States. There was no email (Bhushan would help create that too, authoring early mail protocol RFCs). There was no web. There was no TCP/IP. The network ran on NCP, the Network Control Protocol. If you wanted to move a file from a PDP-10 at MIT to a machine at UCLA, you needed to understand both operating systems, their file formats, and whatever ad hoc transfer method someone had cobbled together.

Bhushan's insight was standardization. Define a common set of commands. Define how files are represented during transfer (ASCII or binary). Let the protocol handle the translation between heterogeneous systems. RFC 114 proposed exactly this: a universal language for machines to exchange files across a network.³

It worked. FTP became one of the first working applications on the ARPANET, arriving two years after Telnet and before nearly everything else we now take for granted.

1973-1985: Evolution

The protocol evolved rapidly through the 1970s. RFC 354 (1972) was a major revision by Bhushan himself. RFC 542 (1973) became the "official" specification. In 1980, as the ARPANET prepared its historic transition from NCP to TCP/IP, RFC 765 adapted FTP to run on TCP.⁵

The version that still governs today arrived on October 1, 1985. Jon Postel and Joyce Reynolds published RFC 959, the definitive FTP specification.⁵ It added commands like MKD (make directory), RMD (remove directory), and PWD (print working directory), commands that will look familiar to anyone who has used a Unix terminal. RFC 959 has never been replaced. Every FTP server running today still speaks the language Postel and Reynolds codified nearly forty years ago.

The Anonymous Convention

In the early Internet, before the web, FTP was how public software was distributed. Archive sites would create a special account with the username "anonymous" and, by convention, users would enter their email address as the password.⁶ No one verified it. It was an honor system. You typed your email so the server administrator could see who was downloading what, and in return, you got access to public files.

This convention was so universal it received its own RFC. RFC 1635, published in May 1994, was titled simply "How to Use Anonymous FTP."⁶ For a generation of programmers and researchers, ftp anonymous@ftp.example.edu was the primary way to download software, papers, and data. Anonymous FTP was the web before the web.

Security

FTP sends everything in plaintext. Your username. Your password. Every byte of every file. Readable by anyone on the network path between client and server.

This is not a bug that was later discovered. The protocol was designed this way. In 1971, the ARPANET was a trusted network of university researchers. Encryption would have been an unnecessary complication. The threat model assumed cooperative participants.

That threat model has not been valid for decades.

The Plaintext Problem

When you type your password into an FTP client, it travels across the network as readable text. An attacker positioned anywhere between you and the server, on your local WiFi, at your ISP, at any intermediate router, can read it. This is not theoretical. Network sniffing tools can capture FTP credentials in seconds.⁷

RFC 2577, published in 1999, formally documented FTP's security problems. Its title was simply "FTP Security Considerations," and it reads as a catalog of vulnerabilities: plaintext credentials, bounce attacks, brute force susceptibility, spoofing, port stealing.⁷

The Bounce Attack

FTP's PORT command tells the server where to send data. The specification places no restriction on what address you provide. An attacker can instruct an FTP server to connect to a completely different machine and port, effectively using the FTP server as a proxy to scan networks, bypass firewalls, or attack services that trust the FTP server's IP address.⁷

This is not a bug in an implementation. It is a feature of the protocol, used as designed, for a purpose nobody anticipated. RFC 2577 notes with remarkable understatement that the bounce attack is "RFC compliant."⁷

FTPS: The Bandage

RFC 4217, published in 2005, defined how to layer TLS encryption onto FTP. The client sends an AUTH TLS command on the control channel, and both sides negotiate encryption before any credentials are transmitted.⁸ This is FTPS (FTP Secure), not to be confused with SFTP (which is a completely different protocol running over SSH on port 22).

FTPS solves the plaintext problem, but the dual-channel architecture makes it painful. The control channel and data channel are separate TCP connections, and both need to be encrypted. Firewalls that inspect traffic to understand FTP's PORT/PASV negotiation can no longer read the commands when they're encrypted. The protocol's 1971 architecture fights its 2005 security requirements at every turn.⁸

The Twilight

FTP is in decline, and the decline is accelerating.

Google Chrome removed built-in FTP support entirely, citing negligible usage and security concerns.⁹ Firefox followed. The browsers decided that a protocol which cannot protect its users does not deserve a place in the address bar.

SFTP (SSH File Transfer Protocol, port 22) and SCP have replaced FTP for most server administration. Cloud storage services (S3, Google Cloud Storage, Azure Blob) have replaced it for file distribution. HTTPS handles what anonymous FTP used to handle. The web itself was FTP's successor for public file access, and it won completely.

Yet FTP persists. Legacy systems in hosting, industrial automation, and enterprise file exchange still rely on it. Some will continue to for years. The protocol is too deeply embedded to disappear overnight.

Related Ports