Port 1306 is registered for RE-Conn-Proto (Reconnection Protocol), a protocol from the early ARPANET era designed to solve session mobility—the ability to hand off a network connection from one host to another without interrupting the user.1
The protocol was visionary for 1973. The problem was real. The solution never took hold.
What RE-Conn-Proto Was Supposed to Do
Reconnection Protocol, defined in RFC 426 and refined in RFC 671, addressed a practical constraint of early networking: users needed to move between hosts without losing their session.23
Three scenarios drove the design:
Resource sharing — Terminal Interface Processor (TIP) users had limited local resources. They'd connect to a larger host for authentication and program access, then need to transfer seamlessly to another host for actual work.
Centralized authentication — Instead of duplicating credentials across every system, a user connecting to an unfamiliar host could be redirected to a central authentication service, then handed back to the original host.
Dynamic reconfiguration — Distributed simulations like the McROSS air traffic control system needed to reorganize computational components across different computers during runtime without breaking connections.
The protocol introduced four commands: RRQ (Reconnect Request), ROK (Reconnect OK), RNO (Reconnect No), and RDO (Reconnect Do). These operated at the Telnet protocol layer rather than the lower Host-Host protocol level—a pragmatic choice acknowledging that modifying core network infrastructure would face resistance.
Why It Didn't Win
Session mobility is everywhere now. Your phone switches between WiFi and cellular mid-call. Your cloud desktop follows you across devices. Your video conference survives network changes. But none of this uses RE-Conn-Proto.
The protocol was technically sound but culturally premature. The ARPANET was experimental. Resource constraints were temporary. Authentication evolved toward distributed systems like Kerberos and LDAP, not connection redirection. And when session mobility finally became critical decades later, the Internet had moved on to different solutions—Mobile IP, SCTP multihoming, application-layer session management.
Port 1306 remains registered to RE-Conn-Proto, but the traffic has long since stopped.
The Ghost in the Port
This is the strange fate of protocols that were right about the problem but wrong about the solution. Reconnection Protocol saw the future—sessions that could move fluidly between hosts, users unbound from single machines, distributed systems that could reorganize themselves dynamically.
It just didn't see how we'd actually get there.
Today, if you scan port 1306, you're unlikely to find anything listening. The protocol belongs to history. But the problem it tried to solve? That's more alive than ever. We just call it cloud computing now.
How to Check What's Using Port 1306
On Linux or macOS:
On Windows:
If you find something listening here, it's probably not RE-Conn-Proto. Registered ports like 1306 sometimes get repurposed by applications that need a port number and pick one that looks available. The protocol may be dead, but the port remains usable.
Why Registered Ports Matter
Port 1306 falls in the registered ports range (1024–49151). These ports are assigned by IANA to specific services upon request, but unlike well-known ports (0–1023), they don't require root privileges to bind to.
The registered ports range is a record of what people thought the Internet would need. Some predictions were correct—MySQL at 3306, PostgreSQL at 5432, MongoDB at 27017. Others, like RE-Conn-Proto at 1306, turned out to be beautiful ideas whose time never quite came.
Every registered port is a bookmark in the history of networking. Some mark protocols we use every day. Others mark roads not taken.
Port 1306 is the latter. A protocol that saw where we were going but never made it there itself.
Questa pagina è stata utile?