Port 165 is assigned to the Xerox Network Services (XNS) Courier protocol, a remote procedure call (RPC) system developed at Xerox PARC and published in December 1981.1 Courier let a program on one computer call a function on another computer as if it were local. That idea, which we now take for granted in every microservice and API call, was radical when it first appeared on this port.
What Courier Does
Courier is a remote procedure call protocol. The concept is deceptively simple: your program calls a function, and instead of executing locally, the call travels across the network to another machine, executes there, and returns the result. Your code doesn't need to know the difference.
In the Xerox ecosystem, every application protocol (printing, filing, email) was built on top of Courier.2 Rather than each application inventing its own wire format, they all described their interfaces as Courier procedure calls. The XNS application protocol documents specified only Courier function-call interfaces and module-plus-function binding tuples. If you wanted to print, you called a Courier procedure. If you wanted to send mail, you called a Courier procedure. One protocol to carry them all.
Courier ran on top of SPP (Sequenced Packet Protocol), the XNS equivalent of TCP, which provided reliable ordered delivery. It included a special facility for bulk data transfer, letting a function call stream large amounts of data as part of the call itself.
How It Works
Courier's design drew directly from Xerox's Mesa programming language. The protocol contained primitives that could implement most features of Mesa function calls over a network.2 Applications had to manually serialize and deserialize their function calls into Courier's wire format. There was no automatic "RPC compiler" that could look at a function signature and generate the network code for you.
This was a limitation that Courier's successors would fix. Andrew Birrell and Bruce Jay Nelson, also at PARC, built "Lupine" for the Cedar programming environment, which automatically generated stubs and provided type-safe bindings.3 But Courier came first, and it proved the concept worked.
Courier's security was ahead of its time. Its "Strong credentials" were based on the Needham-Schroeder protocol, the same cryptographic foundation that Kerberos would later use.2 After authenticating with a central service, clients could digitally sign their Courier procedure calls, letting receivers verify the sender's identity across the network.
The History
The story of port 165 begins at Xerox PARC in Palo Alto, where an extraordinary concentration of talent was building the future of computing.
XNS itself evolved from the PARC Universal Packet (PUP) protocol suite, designed in the mid-1970s by David Boggs, John Shoch, Edward Taft, and Robert Metcalfe.4 PUP was one of the two earliest internetworking protocol suites, developed in roughly the same timeframe as TCP/IP. Robert Taylor, who managed PARC throughout the 1970s, later recalled that Xerox's lawyers prevented them from making PUP public, even as Vint Cerf was inviting PARC researchers to protocol design meetings at Stanford.4
In the early 1980s, the Xerox Systems Development Department took PARC's research and turned it into XNS, a commercial protocol suite. Courier was published in December 1981 as Xerox System Integration Standard XSIS 038112.1 That same year, Bruce Jay Nelson, a PhD student at Carnegie Mellon working at PARC, coined the very term "remote procedure call" in his dissertation.5
One of the first business uses of RPC was Xerox's Courier. Nelson and Andrew Birrell would later win the 1994 ACM Software System Award for their work on implementing RPC at PARC.3
The contact person listed in the IANA registry for port 165 is Susie Armstrong, who spent a decade at Xerox implementing data protocols including Ethernet, XNS, and TCP/IP.6 She later joined Qualcomm and became a pioneer in bringing Internet protocols to cellular networks, enabling the first web browsing on a cellular phone in 1997.6 The work she did on XNS at Xerox directly informed the mobile Internet we use today.
The Legacy Xerox Gave Away
XNS and Courier shared the fate of nearly every great invention from Xerox PARC: the company created the future and then watched others profit from it.
The protocol suite was placed in the public domain in 1977.2 A wide variety of proprietary networking systems were directly based on XNS, including 3Com's 3+ (3Com was founded by Robert Metcalfe, who had co-invented Ethernet at PARC), Banyan VINES, and most significantly, Novell's IPX/SPX, which dominated local area networking throughout the late 1980s and 1990s.2
Courier's RPC concept became ubiquitous. Sun Microsystems built Sun RPC (later ONC RPC) as the foundation for the Network File System. Microsoft built DCE/RPC, which powers Windows networking to this day. The lineage continues through CORBA, XML-RPC, SOAP, REST, and today's gRPC. Every time a microservice calls another microservice, the ghost of Courier is in the room.
XNS itself faded as TCP/IP won the protocol wars in the late 1980s. The last known use of XNS was for communication with the Xerox DocuTech 135 Publishing System.2 Port 165 fell silent.
Security Considerations
Port 165 should not be open on modern systems. XNS Courier is a historical protocol with no active implementations in current operating systems. If you see traffic on port 165, it warrants investigation, as it could indicate misconfiguration, legacy equipment that needs updating, or unauthorized use of an unmonitored port.
To check if anything is listening on port 165:
Related Ports
- Port 52 (XNS Time Protocol): Time synchronization within XNS networks
- Port 54 (XNS Clearinghouse): XNS name service, the XNS equivalent of DNS
- Port 111 (ONC RPC / Sun RPC): The next generation of RPC that built on Courier's concepts
- Port 135 (Microsoft RPC): DCE/RPC endpoint mapper, the Windows descendant of the RPC idea
Frequently Asked Questions
Was this page helpful?