Port 16 is unassigned. No protocol runs here. No RFC defines a service for it. IANA's registry lists it simply as "Unassigned" for both TCP and UDP.
But the reason it's empty is more interesting than most assigned ports.
Why Port 16 Is Empty
Port 16 belongs to the well-known port range (0-1023), the most restricted address space in networking. These ports require root or administrator privileges to bind on Unix-like systems, and new assignments require formal IETF review or IESG approval.1 They are valuable real estate.
So why has this prime real estate sat vacant for over fifty years?
The answer lives in RFC 349, published by Jon Postel on May 30, 1972.2 This document proposed the first standard socket numbers for the ARPANET, and every assigned service received an odd number: Telnet got 1, File Transfer got 3, Remote Job Entry got 5, Echo got 7, Discard got 9.
This wasn't arbitrary. Under the ARPANET's Network Control Protocol (NCP), connections were simplex, meaning data could only flow in one direction per connection.3 To have a two-way conversation, you needed two connections: one to send, one to receive. The odd-numbered socket handled one direction. The even-numbered socket directly above it handled the other.
Port 16 was the silent partner in a pair that was never assigned. When TCP replaced NCP in January 1983 during the famous "flag day" switchover, it brought full-duplex communication. A single port could now handle traffic in both directions.4 The even-numbered shadows became unnecessary.
IANA never went back to fill them in. The gaps remain, like the spaces left in Mendeleev's periodic table, except these elements were never discovered because they were never needed.
The Well-Known Port Range
Port 16 sits in the well-known range (0-1023). This matters for three reasons:
- Privilege required. On Unix and Linux systems, only processes running as root can bind to ports below 1024. This is a security boundary.5
- IANA controlled. Assignments in this range require formal review. You cannot simply register a service here.
- Implicit trust. When you connect to a well-known port, you're trusting that only a privileged process could have claimed it. An unassigned well-known port that suddenly starts answering is a signal worth investigating.
Security Considerations
Because port 16 has no legitimate assigned service, any traffic on it deserves scrutiny.
The Skun backdoor trojan has been documented using TCP port 16.6 This is a common pattern: malware authors favor unassigned well-known ports precisely because they're unlikely to conflict with legitimate services, yet they carry the implicit authority of the privileged range.
Additionally, a denial-of-service vulnerability has been observed on UDP port 16 in the Observer network monitoring tool, involving a NULL pointer dereference triggered by specially crafted SNMP SetRequest PDUs.7
If you see traffic on port 16, investigate it. On a properly configured system, nothing should be listening here.
How to Check What's Listening on Port 16
On macOS:
On Linux:
On Windows:
If any of these return a result, find out what process owns it. On a clean system, silence is the correct answer.
Why Unassigned Ports Matter
Every unassigned port in the well-known range is a decision. IANA could have recycled these even-numbered gaps decades ago. The fact that they didn't reflects a conservative philosophy: the port numbering system works because it's stable. Services assigned to port numbers in the 1980s still run on those same numbers today. FTP is still on 21. SSH is still on 22. SMTP is still on 25.
Leaving gaps empty is cheaper than the chaos of reassignment. Port 16 costs nothing by being vacant. But if IANA assigned it to something and a conflict emerged with legacy systems still treating even ports specially, the debugging would be endless.
Sometimes the most important thing an address can do is stay empty.
Frequently Asked Questions
Was this page helpful?