Port 2091: PRP — A Registered Port Nobody Can Find

Port 2091 sits in the registered ports range (1024–49151). IANA officially assigned it to a protocol called "PRP," registered by someone named Amir Peless. Beyond that, the trail goes cold. No RFC. No documentation. No software that announces itself as PRP. A port with a name and a registrant and nothing else.

What the Registered Ports Range Means

The Internet has 65,535 ports. They're divided into three bands:

• Well-known ports (0–1023): Reserved for major protocols. HTTP, HTTPS, SSH, DNS. These require root/administrator privileges to bind on most systems.
• Registered ports (1024–49151): Available for applications to claim through IANA. Less prestigious, but still formally assigned.
• Dynamic/ephemeral ports (49152–65535): Used for temporary connections — the "return address" your OS picks when you make an outbound connection.

Port 2091 is registered, which means someone went through the process of claiming it. They filled out the form. They submitted a name. IANA put it in the list. And then, apparently, nothing happened — or whatever happened was quiet enough that no one wrote it down.

What Actually Runs Here

The only documented real-world use of port 2091 is PalTalk, a voice and video chat application popular in the early 2000s. PalTalk used a cluster of ports around this range, with each carrying a different stream:

• UDP 2090: voice audio
• UDP 2091: control stream
• TCP 2090: file transfer
• TCP 2091: video

Go2Call, an H.323-compatible video application, also used UDP ports 2090–2091 for incoming calls.

Neither of these is the "PRP" protocol IANA has recorded. They just happened to land on the same port. This is common in the registered range — the formal assignment and the actual usage don't always match, especially for ports that were registered but never widely deployed.

How to Check What's Using This Port

If you see traffic on port 2091 and want to know what's actually there:

On Linux/macOS:

# Show what process is listening on port 2091
ss -tlnp | grep 2091
# or
lsof -i :2091

On Windows:

netstat -ano | findstr :2091

The PID in the output maps to a running process. Cross-reference it in Task Manager or with tasklist to find the application.

With a packet capture:

tcpdump -i any port 2091

Watch a few packets. The payload will usually identify the protocol faster than any port registry.

Why Unassigned and Obscure Ports Still Matter

Port numbers are a coordination mechanism. The registry exists so that when software listens on a port, there's at least a chance that another piece of software expecting something different won't show up and get confused.

When a port is registered but the protocol disappears — as seems to have happened with PRP — the port sits in an odd state. It's technically claimed. Other applications are supposed to avoid it. But since no one knows what it was for, no one's quite sure whether to respect the claim.

In practice, ports like 2091 become available by default — the PalTalk era is mostly past, Go2Call is long gone, and whatever PRP was going to be never arrived. If you see unexpected traffic here, the most likely culprit is a legacy application, a misconfigured service, or something scanning for open ports.