Port 572: SONAR — The proximity service that never launched

Port 572 sits in the well-known ports range (0-1023) with an official assignment—but for a protocol that never quite made it.

What SONAR Was Supposed to Be

SONAR (a pun on the 'ping' utility) was designed to solve a genuine problem: when you have multiple servers offering the same resource, which one is closest to you?¹

The protocol would accept a list of IP addresses and return them ordered by proximity—helping applications choose the server that would likely give the best performance. Need a file? Ask SONAR which mirror is nearest. Need to connect? Ask which endpoint has the lowest latency.

How It Worked

SONAR used UDP port 572 for a simple request-response exchange. A client would send a single UDP datagram containing:

• A list of IP addresses to evaluate
• The type of proximity metric desired (delay, bandwidth, packet loss)

The server would respond with proximity estimates, not claiming absolute accuracy but promising "good choices" among the alternatives.¹

What Happened

Keith Moore of the University of Tennessee drafted the SONAR specification in 1998.¹ It made it to version 3 as an Internet-Draft but never achieved RFC status. The draft expired, the protocol was never widely implemented, and port 572 became a reservation for something that didn't arrive.

The problem SONAR tried to solve is still real—CDNs and anycast routing handle it now, using different approaches. But in 1998, someone thought UDP port 572 and a clever pun might be the answer.

Well-Known But Unused

Port 572 belongs to the well-known ports range (0-1023), which means it was assigned through formal IANA procedures. These ports are reserved for system services and require IETF review or IESG approval to assign.

Getting a well-known port number is significant—it means the protocol was considered important enough to deserve a permanent, low-numbered reservation. But assignment doesn't guarantee adoption. Port 572 holds its place in the registry, waiting for traffic that rarely comes.

Security Considerations

Because SONAR never saw widespread deployment, port 572 is rarely used legitimately. If you see traffic on this port:

• Check what's actually listening: lsof -i :572 (Unix/Linux) or netstat -ano | findstr :572 (Windows)
• Investigate unexpected listeners—legitimate use is uncommon
• Be aware that some sources describe port 572 as used for "remote execution of commands," which likely refers to unofficial or malicious uses rather than the SONAR protocol²

An unused well-known port can be attractive to malware or unauthorized services precisely because it's not monitored as closely as actively-used ports.

Checking What's Listening

To see if anything is using port 572 on your system:

Linux/macOS:

sudo lsof -i :572
sudo netstat -tulpn | grep :572

Windows:

netstat -ano | findstr :572

No output usually means nothing is listening—which is the expected state for port 572.

Why Unassigned Ports Matter

Wait—port 572 is assigned, not unassigned. But it behaves like an unassigned port because the protocol it was assigned to never materialized.

This illustrates something important: the difference between formal assignment and actual use. The IANA registry is a statement of intent, not a guarantee of deployment. Ports can be officially reserved while remaining practically empty.

In a way, these ghost assignments are useful. They document the history of what the Internet community thought might matter. Port 572 tells us that in 1998, someone believed network proximity services needed a dedicated port. They were wrong about the solution, but right about the problem.

Related Ports

• Port 7 (Echo) — Simple network diagnostic, still in use
• Port 37 (Time) — Another simple service that saw actual deployment
• Port 13 (Daytime) — Network time service, deployed but largely obsolete

SONAR wanted to be like these—a simple, useful network diagnostic service. But while Echo and Time found their purpose, SONAR remained a draft.