Port 39: RLP — The Internet Learns to Ask for Help

Port 39 carries the Resource Location Protocol (RLP), one of the Internet's earliest service discovery mechanisms. When a machine needed to find a gateway, a name server, or any other service on the network, RLP gave it a way to ask.

What RLP Does

The Resource Location Protocol solves a problem that sounds simple until you think about it: how does a computer find another computer that provides a specific service?

Today, we take service discovery for granted. DNS, mDNS, Bonjour, UPnP — there are layers of infrastructure dedicated to answering the question "where is the thing I need?" In 1983, much of that infrastructure didn't exist yet. RLP was one of the first attempts to build it.

The protocol works over UDP on port 39¹. A host broadcasts a message to the network, and hosts that can help respond. That's the core of it. The elegance is in the message types.

The Protocol: A Conversation in Four Parts

RLP defines a small vocabulary for machines to negotiate who can help whom¹:

Who-Provides? — A broadcast question. "I need a host that understands this protocol. Anyone?" Only hosts that actually provide the requested resource reply. This is the most common message type, designed for networks that support broadcast addressing.

Do-You-Provide? — A direct question to a specific host. "You, specifically. Do you have this?" The target must always respond, even if the answer is no. This message cannot be broadcast, because doing so would flood the querying host with responses from every machine on the network.

Who-Anywhere-Provides? — A third-party variant. "Does anyone know of a host, anywhere on the network, that provides this?" A host can reply on behalf of another host it knows about.

I-Provide — The answer. "Yes. I have what you need. Here's my address."

There's something almost conversational about it. The Internet, still young, learning to ask politely.

The History

Mike Accetta wrote RFC 887 at Carnegie Mellon University in December 1983¹. CMU was one of the original ARPANET nodes, connected since the early 1970s, and its Computer Science Department was a crucible for networking research².

Accetta was deeply embedded in systems research at CMU. He would go on to be the lead author of the Mach kernel paper in 1986, describing the operating system that would eventually become the foundation for macOS, NeXTSTEP, and OSF/1³. But in 1983, he was solving a more immediate problem: the ARPA Internet was growing, and hosts needed a way to find each other's services without hardcoded address tables.

The RFC itself is pragmatic and direct. It opens with a clear statement of the problem: "In almost all cases the resource location problem is simply a matter of finding the IP address of some one (usually any) host, either on the directly connected network or elsewhere on the Internet, which understands a given protocol."¹

And then it delivers a warning that feels almost urgent: "Hosts failing to implement the Resource Location Protocol risk being ignored by other hosts which are attempting to locate resources on the Internet."¹

In other words: if you don't answer when the network asks, you might as well not exist.

Why RLP Faded

RLP was published as a draft standard. It never became an Internet standard. The timing tells the story: DNS was being designed in the same period (RFC 882 and RFC 883 were published just a month before, in November 1983), and it would prove to be a far more scalable solution to the service discovery problem⁴.

RLP was designed for broadcast networks, where you could shout a question and everyone on the local network would hear it. That works on an Ethernet segment. It doesn't scale to the Internet. DNS, with its hierarchical distributed database, could.

By the late 1980s, DNS had won. RLP quietly receded into the historical record, its port number still reserved but its protocol unused.

Security

Port 39 is not commonly targeted by attackers, largely because nothing runs on it in modern networks. However, precisely because nothing should be running on it, an open port 39 on your network is worth investigating. Unexpected listeners on unused well-known ports can indicate compromise.

If you see traffic on port 39, don't assume it's RLP. Check what's actually listening:

# Check if anything is listening on port 39
sudo lsof -i :39

# Scan port 39 on a remote host
nmap -p 39 <target>

# Check for both TCP and UDP
sudo netstat -tulnp | grep ':39 '

The Significance of the Gap

Port 39 occupies a particular kind of space in the port registry. It's assigned, not empty. Someone cared enough to write an RFC and request a well-known port number. A protocol was designed, documented, and given its place in the system. And then the world moved on.

But that's not failure. RLP was part of the conversation that led to the service discovery mechanisms we use today. It asked the right question ("how do machines find each other's services?") even if a different answer ultimately prevailed. Every protocol that didn't survive still contributed to the thinking that shaped the ones that did.

Port 39 is a well-known port (range 0-1023), assigned by IANA. These numbers are the prime real estate of the Internet's addressing system, reserved for protocols important enough to warrant permanent allocation. That RLP earned one of these slots, even as a draft standard, speaks to how urgent the service discovery problem felt in 1983.