Developer tools · UUID generator
From Apollo NCS to RFC 9562: A Short History of the UUID
· Background
uuid cryptography browser-apis
The odd 8-4-4-4-12 layout and the 128-bit size are inherited from 1980s distributed computing. This post traces the UUID from Apollo's Network Computing System through DCE, Microsoft's GUID and two IETF standards.
Why 128 bits and why those hyphens? — the questions every newcomer asks and history answers
The 8-4-4-4-12 hyphenated format and 128-bit size of a UUID are design choices that historians immediately question. Why not 96 bits for easier math? Why that specific segment layout? Why base-16 with hyphens instead of base-64 or a simpler encoding? The answers lie in the Apollo Network Computing System of the early 1980s, a distributed computing platform that faced a genuine problem: systems in a network needed to allocate unique identifiers without a central authority, and those identifiers had to be globally unique with overwhelming probability. Apollo NCS solved this problem by combining a timestamp, a network address and a clock sequence into a 128-bit identifier that could be generated independently by any machine.
Apollo Network Computing System — the 1980s origin of unique identifiers built from time and a network address
The current standard records a lineage from Apollo NCS through the OSF Distributed Computing Environment and later Microsoft platforms. That history explains why modern systems share a recognizable 128-bit family while preserving variant markers for older layouts. It does not establish an absolute uniqueness guarantee: each version has its own generation rules and failure modes. The durable achievement is interoperability without a central registration service. A browser, database and operating system can exchange the same canonical hexadecimal form, inspect its variant and version fields, and decide whether the producing recipe fits the receiving system's needs.
OSF DCE and the variant field — how the Distributed Computing Environment formalised the layout and added the variant bits
The layout accommodates multiple generation strategies through version and variant fields that were embedded from the start of the design. Time-based generation, random generation and name-based generation can all coexist in the same identifier space. Modern applications have different requirements than 1980s NCS—databases that want sortable keys, cloud systems that want privacy, distributed systems that want collision resistance—yet the same 128-bit structure still accommodates them. Versions 6 and 7 which were added in RFC 9562 in 2024 prove that the original designers left room for future evolution without breaking backward compatibility.
Microsoft's GUID — COM, the registry and the braces-and-uppercase style that persists today
The Apollo Network Computing System was a distributed computing platform that ran on Apollo Computer workstations in the 1980s. It relied on globally unique identifiers for remote procedure calls, data replication and naming services. The nodes in the network had no way to coordinate ID assignment because you could not contact a central server if the network might be partitioned or disconnected. So Apollo designers created a 128-bit format combining a timestamp 60 bits, a node identifier usually derived from the network card MAC address 48 bits, and a clock sequence 14 bits to handle clock changes. This approach let nodes generate identifiers independently by combining time, a clock sequence and a node field; its behavior still depended on clocks and node selection.
RFC 4122 (2005) — the IETF standard that defined versions 1 to 5 and the URN namespace, aligned with ITU-T X.667
When the OSF later standardized this for their Distributed Computing Environment around 1992, they kept the same layout and added the variant field to distinguish different UUID types. The design was already proven in production systems. The IETF standardized RFC 4122 in 2005, nearly twenty years after Apollo NCS and about thirteen years after DCE standardization. RFC 4122 codified versions 1 through 5: version 1 for time-based generation, version 3 for name-based with MD5, version 4 for random, and version 5 for name-based with SHA-1. The standard was stable and widely adopted because it was already ubiquitous in Microsoft Windows, DNS infrastructure and distributed systems. By the time RFC 4122 was published, the UUID was already so embedded in infrastructure that standardization was almost academic.
RFC 9562 (2024) — the revision that obsoleted RFC 4122, added versions 6, 7 and 8, and wrote down modern advice on randomness
In 2024, the IETF published RFC 9562, which obsoletes RFC 4122 and adds versions 6, 7 and 8. Version 6 reorders the time fields of version 1 for better B-tree locality and sortability. Version 7 uses a Unix timestamp modern and familiar instead of the 1582-based count, improving sortability and fitting modern database requirements. Version 8 reserves space for custom implementations and experimental UUID designs. The new versions address problems that emerged over forty years of UUID deployment: the poor database performance of random keys, the privacy leak of version 1, and the desire for sortable identifiers in cloud systems. Yet the core 128-bit structure, the variant and version fields and the overall layout remain intact.
What this does not cover — implementation details of each version, which have their own posts
Microsoft's adoption of UUIDs as GUIDs Globally Unique IDentifiers in the Component Object Model embedded them deeply in Windows systems starting in the 1990s. GUID appeared in the registry, in COM interfaces and in ActiveDirectory infrastructure. Microsoft added a minor variation: they stored GUIDs in little-endian byte order for some components, departing from the network-byte-order standard. That quirk persists in some Windows APIs: if you export a GUID from Windows and import it to a Unix system, byte-order issues can cause apparent mismatches. But the format itself is the same, and the confusion is a footnote in the standard, not a fundamental difference. The braces-and-uppercase style {3FA85F64-5717-4562-B3FC-2C963F66AFA6} comes from Windows conventions; other systems prefer lowercase and hyphens without braces.
Takeaway: a forty-year design that still works — the ToolAcre generator produces the random (version 4) UUIDs that RFC 9562 still defines for cases where ordering is not needed
A worked timeline shows the longevity and stability of the design: 1980s Apollo NCS invents the concept; 1992 OSF's DCE standardizes the layout; 2000s Microsoft embeds it in Windows; 2005 IETF publishes RFC 4122; 2024 IETF publishes RFC 9562 with modern versions. That is one of the longest standardization efforts in computing, not because of disputes but because the original design was so robust and adaptable. It has accommodated waves of architectural change—from distributed NFS systems to cloud databases, from Windows COM to mobile devices, from 1980s 64-bit machines to modern systems—without fundamental redesign. The practical impact is that UUIDs are ubiquitous and stable; when you generate a UUID with the ToolAcre generator, you are generating an identifier whose format was established in the 1980s, standardized internationally in 2005 and maintained in 2024 with lasting relevance.