Port 156: SQL Service — The Reserved Table Nobody Claimed

Port 156 is registered with IANA as sqlsrv, assigned to "SQL Service" for both TCP and UDP.¹ If that surprises you, you're not alone. In a world where MySQL listens on 3306, PostgreSQL on 5432, and Microsoft SQL Server on 1433, almost nobody remembers that someone once tried to give SQL its own canonical port in the well-known range.

That someone was Craig Milo Rogers, a systems programmer at USC's Information Sciences Institute (ISI),² the same research lab where Paul Mockapetris invented the Domain Name System. Rogers registered port 156 with IANA, staking out a spot in the privileged 0-1023 range for a generic SQL service. The idea was straightforward: if HTTP could have port 80 and SMTP could have port 25, then SQL, the language that was rapidly becoming the universal tongue of databases, deserved its own well-known port.

It never caught on.

What Port 156 Was Supposed to Be

The registration dates to the era when IANA assignments were managed by Jon Postel and his team at ISI. Port numbers in the well-known range (0-1023) required formal registration and carried weight. They were reserved for protocols and services deemed important enough to deserve system-level access on Unix machines, where only root processes could bind to ports below 1024.

Port 156 was meant to be a universal entry point for SQL database services. A client connecting to port 156 on any host would expect to find a SQL-capable database server answering queries. This was the vision: one port, one language, any database.

Why Nobody Showed Up

The problem was timing and fragmentation. By the time networked database access became common in the late 1980s and early 1990s, the database market was already splintering.

SQL itself had a clear origin story. Donald Chamberlin and Raymond Boyce developed it at IBM's San Jose Research Laboratory in the early 1970s, building on Edgar Codd's relational model.³ It became an ANSI standard in 1986 and an ISO standard in 1987.⁴ But standardizing the language did nothing to standardize the network protocol for accessing it.

Each database vendor built their own wire protocol:

• Oracle chose port 1521 (TNS Listener)
• Microsoft SQL Server chose port 1433
• MySQL chose port 3306
• PostgreSQL chose port 5432
• IBM DB2 used ports 446-448 for its Distributed Data Management (DDM) architecture⁵

Even IBM, whose researchers invented SQL and whose Distributed Data Management Architecture (DDM) was one of the earliest attempts at networked database access, didn't use port 156. IBM registered its own DDM ports (446, 447, 448) under a separate assignment by Steven Ritland.

The ISO tried to solve this with the Remote Database Access (RDA) protocol, published as a standard in 1993.⁶ RDA was supposed to be the universal protocol for remote SQL access. Despite proof-of-concept implementations for Oracle, Rdb, NonStop SQL, and Teradata, no major vendor adopted it commercially. The standard was eventually withdrawn.

Port 156 and RDA shared the same fate: the industry preferred proprietary solutions over universal ones.

The Well-Known Range

Port 156 sits in the system port range (0-1023), also called the well-known range. These ports are assigned by IANA through IETF Review or IESG Approval processes described in RFC 6335.⁷ On most operating systems, binding to a port in this range requires elevated privileges.

Being in the well-known range was supposed to confer authority. Port 80 means HTTP. Port 443 means HTTPS. Port 22 means SSH. Port 156 was supposed to mean SQL. Instead, it means nothing to almost everyone who works with databases today.

Checking What Listens on Port 156

On the off chance something is using port 156 on your system:

# macOS / Linux
sudo lsof -i :156

# Linux with ss
ss -tlnp | grep :156

# Windows
netstat -an | findstr :156

# Scan a remote host
nmap -p 156 <host>

If you find something listening on port 156, it's likely either a legacy IBM system running DDM-related SQL services, or something that chose port 156 precisely because nobody else was using it.

Security

Port 156 doesn't carry unique security risks beyond those of any open database port. If a SQL service is genuinely listening on port 156, the standard precautions apply: strong authentication, encrypted connections (TLS), network segmentation, and protection against SQL injection.

The greater risk with obscure ports like 156 is the assumption that they're unused. Attackers sometimes bind malicious services to little-known assigned ports, counting on the fact that security scanners and administrators won't look there. An open port 156 on a system that shouldn't have one is worth investigating.

Related Ports