Summary

  • RFC 1924 represented every 128-bit IPv6 address as exactly twenty base-85 characters. The arithmetic was sound and the conversion reversible, but neither property guaranteed recognition by people, URLs, logs or search tools.
  • Its alphabet deliberately reserved nine printable ASCII characters for surrounding syntax. That choice showed that an address never travels as mathematics alone: it must coexist with quotation, lists, paths, brackets and escaping.
  • Later standards kept colon-separated hexadecimal, added brackets for URI literals and recommended one canonical output form. They improved comparison without pretending that a matching string proved assignment, routing, identity or delivery.

The missing search result

An operator does not normally compare 128-bit integers. The operator copies a string from a ticket, pastes it into a log search, scans a diagram, reads a Whois response or asks whether two alerts concern the same address. Each step depends on a visible representation. If one system writes hexadecimal and another writes base 85, equality survives inside a decoder while disappearing at the human surface.

That distinction is the useful historical subject of RFC 1924. Published on 1 April 1996 as an Informational document, it did not specify an Internet standard. It proposed treating an IPv6 address as one unsigned integer and expressing it with an alphabet of 85 printable ASCII characters. The result was always twenty characters long. The RFC's example turned 1080:0:0:0:8:800:200C:417A into 4)+k&C#VzJ4br>0wv%Yp.

Nothing was lost. A correct decoder could recover the original 128 bits. Yet an exact inverse function answered only one question: can the value be reconstructed? It did not answer whether an operator could recognize the address, whether a URL parser would delimit it correctly, whether an inventory would normalize it, or whether a literal-text search would find every occurrence.

Eighty-five was an arithmetic boundary

The proposal was not arbitrary ornament. IPv6 had (2^{128}) possible values. Twenty base-85 digits covered that space, whereas twenty base-84 digits did not: (84^{20} < 2^{128} \leq 85^{20}). Even an alphabet of 94 or 95 printable characters would still require twenty positions. Base 85 therefore reached the shortest fixed width available in that range while leaving nine printable characters unused.

Fixed width carried real advantages. It retained leading zeroes, avoided the several legal compression choices of hexadecimal text and made field sizing predictable. A machine could compare decoded values without caring about presentation. In a record whose boundary was already known, the representation was compact and complete.

But the boundary was the problem. Address text rarely occupies a field alone. It appears in prose, headers, route notation, commands and identifiers. The RFC excluded double and single quotation marks, comma, period, slash, colon, square brackets and backslash. Those characters were useful outside the address: for quoting, lists, sentence endings, CIDR suffixes, URLs, literal delimiters and escaping. The alphabet design quietly admitted that compression succeeds only when the surrounding grammar remains able to see where the compressed value starts and stops.

Flexible hexadecimal had accumulated social meaning

The preceding IPv6 addressing specification allowed eight 16-bit hexadecimal pieces separated by colons, omission of leading zeroes, one :: compression of a zero run and a mixed IPv4 decimal tail. Those choices could produce many spellings of one value, but they also preserved a visual family resemblance. Colons announced an IPv6 literal. Hexadecimal pieces exposed structure that operators had learned to scan.

That familiarity is not a mathematical property, and it should not be romanticised. Flexible spelling later caused genuine operational trouble. Two applications could print the same address differently. A spreadsheet could treat them as different strings. A search for one form could miss another. A diagram and a log could disagree without any disagreement in the underlying bits.

RFC 1924 removed that flexibility by replacing the entire surface. The later standards path solved narrower interface problems while retaining the recognisable form. For URLs, the colon already separated a scheme from later syntax and also appeared within IPv6. The bracket convention enclosed an IPv6 literal so it could be copied and pasted with minimal editing. The generic URI grammar subsequently preserved brackets as the unique URI location for an IP literal.

Canonical output made equality visible

By 2010, RFC 5952 described the costs of multiple legal hexadecimal spellings in search, text files, spreadsheets, Whois systems, diagrams, logs, audits and verification. Its answer was asymmetric. Parsers still had to accept every legitimate form allowed by the IPv6 addressing architecture, but writers were asked to emit a canonical form.

The output rules were specific: remove leading zeroes, use lowercase hexadecimal, compress the longest run of zero fields with ::, choose the first run when lengths tie, and never compress a single zero field. These rules did not make the address shorter in every case. They made independent systems more likely to leave the same textual evidence for the same value.

That is a different optimization. Base 85 minimized width. Canonical hexadecimal minimized representational disagreement while preserving an established human and syntactic surface. Brackets dealt with one delimiter collision without demanding a new alphabet. Together, those choices treated notation as shared operational infrastructure rather than mere serialization.

A spelling is one rung on an evidence ladder

The ladder begins with the 128 bits. A parser may convert a string to that value. A formatter may choose a normalized display. A logger may or may not preserve it. A search may or may not retrieve it. Only then can an operator correlate the record with an observed network outcome.

Each rung proves less than people often assume. Equal decoded values prove representational equivalence. Equal canonical strings show that two formatters followed the same convention. A log occurrence shows that a component recorded text. None of those facts proves that the address was assigned to a claimant, originated by an authorized network, present in a live route, bound to a reachable interface, serving an authenticated application or responsible for delivered packets.

The primary chronology is recorded in RFC 1884, RFC 1924, RFC 2732, RFC 3986, RFC 4291 and RFC 5952. They document specifications, not a census proving that base 85 had no implementation or that later authors formally rejected it.

Running-Code Primacy supplies a later discipline for reading this history: test what parsers, logs and operator workflows actually accept and preserve. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption suggests why a small common notation can coordinate more effectively than a maximal redesign. Neither note states the intent of the earlier RFC authors.

RFC 1924's twenty characters were perfectly capable of carrying an address. Their historical value lies in the question they leave behind: when the same bits must cross people, files and tools, is the shortest representation also the shortest path to shared evidence?