Port 1: TCPMUX — The First Door

Port 1 is the first assigned port in the entire Internet port registry. While port 0 is reserved as a wildcard, a placeholder the operating system uses when you say "give me any available port," port 1 is the first door that was deliberately given a name and a purpose. It runs TCPMUX, the TCP Port Service Multiplexer, a protocol that lets a client connect to a single port and ask for any service by name.

The idea was simple: instead of memorizing that FTP lives on port 21 and SMTP lives on port 25, you could connect to port 1, type the name of the service you wanted, and the server would either connect you or tell you no.

Almost nobody ever used it. But the story of why it exists, and who wrote it, is the story of the early Internet itself.

How TCPMUX Works

The protocol is so simple it fits on a single page¹. A client connects to TCP port 1 and sends the name of the service it wants, followed by a carriage return and line feed. The server responds with a single character: + for yes, - for no. If the answer is yes, the requested service takes over the connection. If the answer is no, the connection closes.

That's it. The entire handshake is one line of text and one character of response.

There's one reserved command: HELP. Send it, and the server responds with a list of every service it offers, one per line, then closes the connection. It's a directory. A table of contents for a machine's capabilities, accessible to anyone who knocks on the first door.

Service names are never case sensitive. Private protocols should be prefixed with the organization's name to avoid collisions. Multiple versions of a protocol can append a version number to the service name. These are the kinds of pragmatic details that reveal a protocol designed by someone who had actually built things and watched them break.

The History

RFC 1078 was published in November 1988 by Mark K. Lottor of SRI-NIC, the Network Information Center at SRI International in Menlo Park, California¹.

To understand what that means, you need to know what SRI was. SRI International was one of the four original nodes on the ARPANET. On October 29, 1969, the first successful host-to-host message was sent from UCLA to SRI². Programmer Charley Kline typed "login," and the system crashed after two characters. The first message ever transmitted on what would become the Internet was "lo." An hour later, they tried again and it worked.

SRI's Network Information Center was the place that kept the names. Before DNS existed, every host on the network was registered with SRI-NIC, and a file called HOSTS.TXT mapped names to addresses³. If you wanted to add a new machine to the Internet, you sent an email to HOSTSMASTER@SRI-NIC.ARPA and asked for an address. One file. One organization. One building in Menlo Park that held the directory of the entire network.

Mark Lottor worked there as a systems programmer for seven years, starting in 1982⁴. He was steeped in the problem of naming and finding things on a growing network. He would go on to create the Internet Domain Survey, the longest-running survey of Internet hosts, which tracked the network's growth from a few hundred machines to over a billion⁵. He wrote the ZONE program that crawled the DNS to discover and count every host. He founded Network Wizards and later Catalog.Com, one of the first web hosting services.

This was the person who wrote RFC 1078. Someone who spent his career watching the Internet grow and understood, viscerally, that port numbers were a scarce resource. In 1988, well-known ports occupied the range 0 to 255. There were only 256 addresses, and they were assigned exclusively to official Internet protocols. Lottor's proposal was a pressure valve: let services share a single port, identified by name instead of number.

The Problem It Solved (Almost)

The elegance of TCPMUX was that it turned port allocation from a political problem into a technical one. As one veteran sysadmin wrote in 2010: choosing a port number for a new service becomes "a non-technical deadlock" when you factor in firewall policies, access control lists, and organizational politics⁶. TCPMUX offered an alternative. One port, any service, just ask by name.

On Unix systems, TCPMUX was integrated into inetd, the Internet "super-server" that managed incoming connections⁷. The implementation worked like "inetd inside inetd." Classic inetd dispatched connections based on port numbers. TCPMUX dispatched based on service names. An entry in /etc/inetd.conf might look like:

tcpmux/+date stream tcp nowait guest /bin/date date

That single line made the date command available to anyone who connected to port 1 and typed "date." The + prefix told inetd to send the positive acknowledgment automatically, so even programs that knew nothing about TCPMUX could be wired up as services.

Why Nobody Used It

The Internet chose a different path. Instead of multiplexing services through one door, it built more doors. The well-known port range expanded. The registered port range (1024-49151) opened up. IANA developed formal procedures for assigning port numbers⁸. The scarcity that motivated TCPMUX largely evaporated.

There were also real problems with the approach. RFC 7805, published in April 2016, formally moved RFC 1078 to Historic status and laid out the case⁹:

Connection limits. All services funneled through a single port, which constrained the number of simultaneous connections between two machines.

Firewall complications. TCPMUX made port-based firewall rules meaningless. If every service is reachable through port 1, blocking port 25 to stop SMTP doesn't help. Security policy becomes impossible to express in terms of port numbers.

Three-way handshake semantics. TCPMUX completed the TCP three-way handshake even when a service wasn't available, which violated the expected behavior where an unreachable service would simply not respond.

Minimal adoption. RFC 7805 noted that the only reported production use was SGI's Data Migration Facility (DMF), and even that was confined to private networks⁹. DMF was a hierarchical storage system that automatically migrated data between fast disk and cheap tape. NASA used it at the Ames Research Center to manage 40 petabytes of data¹⁰. Every remote DMF client command consumed one TCPMUX connection, and SGI's documentation specifically warned administrators to increase the tcpmux instance limit in xinetd configuration.

That was it. One protocol. One vendor. One use case. Running on private networks, not the public Internet.

Security

Port 1 has a troubled security history, which is inevitable for a protocol designed to be a directory of everything a machine can do.

Service enumeration. The HELP command is a built-in reconnaissance tool. Connect to port 1, type HELP, and the server hands you a list of every service it offers. This is equivalent to a port scan, handed over willingly.

Firewall bypass. Because TCPMUX tunnels any service through port 1, traditional port-based access controls become ineffective. Blocking a specific service port accomplishes nothing if that service is also reachable through TCPMUX.

Privilege escalation (CVE-2013-4342). When TCPMUX was enabled in xinetd with a tcpmux-server configured, an attacker could connect to port 1 and access services running with root privileges¹¹.

Denial of service. On BSDI 4.0 systems, a remote attacker could crash inetd entirely if TCPMUX was enabled in /etc/inetd.conf¹².

Trojan usage. Port 1 has been associated with the "Sockets des Troie" trojan, which exploited the port for backdoor access.

Modern systems disable TCPMUX by default. OpenBSD dropped support for it entirely. The consensus is clear: a protocol that advertises your services and bypasses your firewall is not a protocol you want running.

The Protocol's Legacy

TCPMUX is a protocol from a more trusting era. It assumed you wanted to be found. It assumed the network was a community of researchers, not a battlefield of automated scanners. In 1988, when Mark Lottor wrote RFC 1078, the Internet had roughly 56,000 hosts⁵. Everyone was, in a meaningful sense, a neighbor.

The idea itself wasn't wrong. Modern service discovery mechanisms like DNS SRV records, service meshes, and API gateways all solve variations of the same problem: how do you find a service without memorizing its address? TCPMUX just tried to solve it at the TCP layer, with a protocol so minimal it could be implemented in a few dozen lines of code.

Port 1 is the first door. Behind it was an answer to the question: "What if you could connect to one port and ask for anything?" The Internet decided it preferred 65,535 separate doors instead. But for a moment, in a building in Menlo Park where the entire Internet's directory fit in a single file, the simplicity of that first door made perfect sense.

Related Ports