Port 164: CMIP/TCP Agent — The Future That Never Arrived

The Port That Was Promised

Port 164 was supposed to be important. It was assigned the service name cmip-agent and designated for the Common Management Information Protocol (CMIP) agent over TCP/IP. Its companion, port 163 (cmip-man), handled the manager side. Together, they were the infrastructure for what the Internet's governing body officially declared would be the long-term future of network management.¹

That future never materialized. Port 164 is one of the Internet's most interesting relics: a well-known port, formally assigned by IANA, with almost nothing listening on it anywhere in the world.

What CMIP Was

CMIP was the OSI network management protocol, defined in ITU-T Recommendation X.711 and ISO/IEC 9596-1.² It provided the services specified by the Common Management Information Service (CMIS), allowing network management applications to communicate with agents running on managed devices: routers, switches, servers, anything that needed monitoring and control.

Where SNMP gave you two operations (GET a value, SET a value), CMIP gave you a rich object-oriented framework. Managed objects could have attributes, emit events, and perform arbitrary actions. Objects were described using GDMO (Guidelines for the Definition of Managed Objects) and identified using X.500 distinguished names. CMIP implemented all of this on top of two other OSI Application Layer protocols: ACSE for managing connections and ROSE for data exchange.³

It was, by any technical measure, more capable than SNMP. It had built-in security with authorization, access control, and audit logs, features SNMP would not gain until version 3, years later. It used event-based notification instead of polling, making it more efficient for large networks. It could model complex relationships between managed objects through inheritance.⁴

It was also enormously complex.

The Two-Track Decision

In March 1988, the Internet Activities Board convened an ad hoc committee to decide the future of Internet network management. The Internet was growing fast and needed management tools. Two protocols were competing: SNMP, which had evolved from the Simple Gateway Monitoring Protocol (SGMP), and CMIP, which was being developed within the ISO/OSI framework.

On April 1, 1988, Vint Cerf published RFC 1052, which laid out the IAB's decision: a two-track strategy.¹ SNMP would be the short-term solution, deployed quickly because it was simple and implementations already existed. CMIP over TCP/IP (CMOT) would be the long-term solution, developed carefully and deployed once ready.

The RFC was explicit. Two IETF working groups would handle SNMP. A third, the "Netman" group, would develop CMOT. All three would coordinate to ensure the Management Information Base (MIB) stayed compatible, so the transition from SNMP to CMIP would be smooth.

Ports 163 and 164 were assigned for this long-term future. Port 163 for the CMIP manager. Port 164 for the CMIP agent.⁵

CMOT: The Bridge That Nobody Crossed

RFC 1095, published in April 1989, defined the initial specification for CMIP over TCP/IP. RFC 1189, published in October 1990, revised and replaced it.⁵ The architecture was clever: instead of requiring the full OSI protocol stack, CMOT used a Lightweight Presentation Protocol (LPP) to carry CMIP protocol data units over TCP and UDP.

The protocol suite for CMOT consisted of seven protocols: ISO ACSE, ISO ROSE, ISO CMIP, LPP, UDP, TCP, and IP. For comparison, SNMP needed exactly one transport (UDP) and one protocol (itself).

CMOT had very few implementors. The telecommunications industry adopted CMIP natively as part of the Telecommunications Management Network (TMN), where the full OSI stack was already in use. But TCP/IP network equipment vendors never adopted CMOT. Why would they? SNMP was already working, it was simple to implement, and their customers were already using it.

Why Simplicity Won

The CMIP-versus-SNMP rivalry was a microcosm of the larger OSI-versus-TCP/IP protocol wars of the 1980s and 1990s.⁴ The two camps reflected fundamentally different philosophies about protocol design.

The Internet community valued simplicity. In the early days, network devices had limited memory and processing power. A protocol that required ten times the resources to implement was not a protocol that would get implemented. SNMP's initial specification fit in a few dozen pages. A competent engineer could implement it in weeks.

The OSI community valued completeness. They believed protocols should be designed to handle every foreseeable requirement from day one. CMIP was thorough, flexible, and extensible. It was also expensive. One widely cited estimate suggested that supporting CMIP would require increasing network device resources by a factor of ten.⁴

SNMP shipped. CMIP was still being specified. SNMP got deployed on hundreds of vendor platforms. CMIP got deployed on telecommunications switches. SNMP became universal. CMIP became a footnote.

The "interim" protocol won by showing up.

Port 164 Today

Port 164 sits in the well-known port range (0-1023), meaning it is assigned by IANA and on most systems can only be bound by privileged processes. It remains formally registered to cmip-agent for both TCP and UDP.⁶

In practice, you will almost never find anything listening on port 164. The protocol it was reserved for lost a standards war that ended decades ago. CMIP persists in some legacy telecommunications management systems, but those typically run the full OSI stack rather than CMOT over TCP.

If you want to check whether anything is listening on port 164:

# Linux
sudo ss -tlnp | grep :164
sudo netstat -tlnp | grep :164

# macOS
sudo lsof -iTCP:164 -sTCP:LISTEN

# Windows
netstat -an | findstr :164

# Remote scan
nmap -p 164 target_host

If something is listening on port 164, it is almost certainly not CMIP. Investigate immediately.

Security Considerations

Port 164 has been flagged in some security databases as having historical associations with trojan or malware communication. This is not because CMIP itself is malicious but because attackers sometimes repurpose obscure, rarely-monitored ports for command-and-control traffic. An unmonitored well-known port that nobody expects to see traffic on makes an attractive covert channel.

Any unexpected traffic on port 164 should be treated as suspicious and investigated. Firewall rules should block inbound traffic on port 164 unless you have a specific, documented reason to allow it.

The Lesson of Port 164

Port 164 teaches something that the Internet keeps re-teaching: the technically superior solution does not always win. CMIP was more powerful, more secure, more expressive, and more carefully designed than SNMP. The Internet's own governing body declared it the future. It had ports assigned, RFCs written, working groups chartered, and a transition plan documented.

None of that mattered as much as the fact that SNMP was simple enough to actually ship.

SNMP, originally approved "based on a belief that it was an interim protocol," is still managing the Internet's infrastructure over three decades later.⁷ Port 161 (SNMP) and port 162 (SNMP Trap) carry billions of management messages every day. Port 164 carries silence.

Sometimes the placeholder becomes the monument, and the monument becomes the placeholder.

Related Ports