1. Ports
  2. Port 96

What Port 96 Does

Port 96 is assigned to the DIXIE protocol, a lightweight interface for accessing X.500 directory services over TCP/IP.1 A DIXIE server listens on port 96 for both TCP connections and UDP packets. Clients send requests, the server translates them into the heavy OSI-based Directory Access Protocol (DAP), and returns results in a simple format the client can understand.

You will almost certainly never see traffic on port 96 in the wild. DIXIE is obsolete. But what it became is not.

How DIXIE Works

The problem DIXIE solved was one of weight. X.500 was the ITU's grand vision for a global directory service, a universal phone book for the networked world.2 It was powerful, standardized, and comprehensive. It was also built on the OSI networking stack, which meant that any machine wanting to look up a name needed to implement seven layers of protocols that most computers didn't have and most programmers didn't want to touch.

DIXIE cut through this by acting as a gateway. The client sends a simple 16-byte header followed by request data over TCP or UDP to port 96. The server, which does have the full OSI stack, translates that request into proper DAP, queries the X.500 directory, and sends back the results in QUIPU EDB format, a human-readable text representation of directory entries.1

The protocol supports the core directory operations: Read, Search, List, Add, Remove, Modify, and Bind. Modification operations require a TCP connection for basic authentication. Read-only queries can use UDP for speed.1

A Distinguished Name in DIXIE looks like c=US@o=University of Michigan, using @ symbols instead of the comma-separated format that LDAP would later adopt. The bones of the idea are visible, but the syntax is still finding its shape.

The Story of DIXIE

In 1990, Tim Howes was a graduate student at the University of Michigan. The university needed a campus-wide directory service for over 100,000 students, staff, and faculty. X.500 was the obvious choice for the directory model, but the client side was a disaster. You couldn't just write a quick program to look someone up. You needed the full OSI protocol stack, which was enormous, slow, and unavailable on most of the machines people actually used.3

Howes, along with Mark Smith and Bryan Beecher, built DIXIE as a pragmatic solution. Put a DIXIE server on a machine that has the OSI stack. Let Macintoshes, PCs, and Unix workstations talk to it over plain TCP/IP. The university released a complete implementation: a DIXIE server, a client library, and client applications, including one for the Macintosh.1

RFC 1249 was published in August 1991, formally specifying the protocol.1 It reads like what it is: a working solution written by people who needed it yesterday.

From DIXIE to LDAP

Here is the part that matters.

DIXIE worked, but it was tied to a specific implementation. It used QUIPU's data format. It assumed a particular server architecture. Other groups were building similar gateways with similar limitations. The Directory Assistance Service (DAS) was another attempt at the same problem.

By 1993, Howes and his collaborators, Steve Kille of Isode Limited, Colin Robbins of Nexor, and Wengyik Yeong of Performance Systems International, asked a better question: what if the lightweight access protocol was the standard, not a workaround?4

They took what they had learned from DIXIE and built the Lightweight Directory Access Protocol. LDAP. It kept the core idea, TCP/IP clients talking to a directory without the OSI burden, but made it implementation-independent, extensible, and standardized through the IETF.

LDAPv1 appeared in 1993. LDAPv2 in 1995 added referrals and stronger authentication. LDAPv3 in 1997 brought internationalization, access control, and schema discovery.4 By the late 1990s, Netscape had hired Howes, and LDAP was everywhere. Microsoft built Active Directory on it. Every corporate login, every email address lookup, every organizational chart query, LDAP.

In 1997, LDAP won PC Magazine's Technical Excellence Award for Networking.3 Tim Howes went on to co-found Loudcloud with Marc Andreessen and Ben Horowitz.3

Port 96 was where the idea started. Port 389 (LDAP) is where it landed.

Security Considerations

DIXIE's security model is minimal by modern standards. Authentication relies on X.509 simple authentication over TCP, which provides only basic credential verification.1 There is no encryption of data in transit. The protocol was designed for a campus network in 1990, not for the open Internet.

Port 96 has been flagged by some security databases as historically associated with trojan activity, though this is common for many low-numbered ports that see little legitimate traffic. If you see unexpected connections on port 96, investigate. Nothing should be talking DIXIE in production today.

PortProtocolRelationship
95SUPDUPNeighbor, another early remote access protocol
97Swift RVFPNeighbor, Swift Remote Virtual File Protocol
389LDAPDIXIE's successor, the protocol that changed everything
636LDAPSLDAP over TLS
3268Global CatalogActive Directory's LDAP-based global catalog

Frequently Asked Questions

Was this page helpful?

๐Ÿ˜”
๐Ÿคจ
๐Ÿ˜ƒ
Port 96: DIXIE โ€” The Seed That Became LDAP โ€ข Connected