Zusammenfassung

  • RFC 1924 interpretierte die gesamten 128 Bit einer IPv6-Adresse als Zahl und schrieb sie mit 85 druckbaren ASCII-Zeichen in fester Länge. Rückrechenbarkeit garantierte weder menschliche Wiedererkennung noch Textsuche und Werkzeugkompatibilität.
  • Neun Zeichen blieben bewusst frei, weil Anführungen, Listen, Satzzeichen, CIDR, URLs, Klammern und Escaping sie außerhalb der Adresse benötigten. Auch die umgebende Grammatik gehört zum Darstellungsvertrag.
  • Spätere Standards behielten Doppelpunkt-Hexadezimal bei, begrenzten URI-Literale mit eckigen Klammern und vereinheitlichten die Ausgabe. Ein kanonischer Treffer beweist Darstellungsgleichheit, nicht Zuweisung, Route, Erreichbarkeit, Identität oder Zustellung.

Der angenehme Datensatz und das unsichtbare Ereignis

Eine Anwendung speichert eine IPv6-Adresse in einem Feld mit exakt zwanzig Stellen. Eine andere druckt denselben 128-Bit-Wert als Hexadezimalgruppen. Der Ermittler kopiert die zweite Schreibweise in die Volltextsuche der ersten und erhält keinen Treffer. Beide Systeme sind intern korrekt; ihre Beweisspuren sind füreinander unsichtbar.

RFC 1924 erschien am 1. April 1996 als Informational und legte keinen Internetstandard fest. Der Text behandelte die Adresse als eine einzige vorzeichenlose Ganzzahl und kodierte sie mit einem Alphabet aus 85 druckbaren ASCII-Zeichen. Aus 1080:0:0:0:8:800:200C:417A wurde im Beispiel 4)+k&C#VzJ4br>0wv%Yp. Führende Nullen blieben erhalten, die Ausgabe war stets zwanzig Zeichen lang.

Ein korrekter Decoder gewinnt daraus den ursprünglichen Wert. Das ist ein starkes, aber enges Versprechen. Es sagt nichts darüber, ob ein URI-Parser die Grenze erkennt, ein Index beide Formen zusammenführt, ein Mensch IPv6 vermutet oder alle Altwerkzeuge den neuen Zeichensatz beherrschen.

Die Rechnung bestimmte das Alphabet

Der IPv6-Raum umfasst (2^{128}) Werte. Zwanzig Stellen zur Basis 84 reichen nicht; zwanzig zur Basis 85 reichen: (84^{20} < 2^{128} \leq 85^{20}). Selbst Basis 94 oder 95 würde weiterhin zwanzig Stellen verlangen. Basis 85 erreichte also die minimale feste Breite und konnte neun druckbare Zeichen für andere Zwecke freihalten.

Feste Breite ist nicht bloß ästhetisch. Felder lassen sich planen, führende Nullen verschwinden nicht, und die verschiedenen erlaubten Nullkompressionen der Hexadezimalschreibweise fallen weg. Wo der äußere Datensatz die Feldgrenze schon vorgibt und jeder Teilnehmer decodieren kann, ist das Verfahren kompakt und eindeutig.

Die neun ausgelassenen Zeichen zeigen jedoch, wie selten diese ideale Isolation vorkommt: doppeltes und einfaches Anführungszeichen, Komma, Punkt, Schrägstrich, Doppelpunkt, beide eckigen Klammern und Rückwärtsschrägstrich. Sie dienen Zitaten, Listen, Satzenden, CIDR-Erweiterungen, URLs, Literalen und Escape-Regeln. Eine Darstellung muss nicht nur ihren Inhalt tragen, sondern der Umgebung erlauben, dessen Anfang und Ende zu erkennen.

Wiedererkennung und Eindeutigkeit waren getrennte Probleme

Die frühere IPv6-Architektur beschrieb acht durch Doppelpunkte getrennte 16-Bit-Hexadezimalgruppen. Führende Nullen durften fehlen, eine Nullfolge durfte einmal als :: erscheinen, und ein dezimales IPv4-Ende war möglich. Dadurch entstanden mehrere legale Schreibweisen desselben Wertes. Zugleich signalisierten Doppelpunkt und Gruppenstruktur weithin erkennbar eine IPv6-Adresse.

Vertrautheit löste das Vergleichsproblem nicht. Unterschiedliche Nullkompressionen erzeugten falsche Duplikate in Tabellen, verfehlte Suchtreffer und scheinbare Abweichungen zwischen Whois, Netzplan und Log. Base85 machte die Darstellung eindeutig, indem es die gesamte Oberfläche austauschte. Der spätere Standardweg suchte Eindeutigkeit, ohne diesen Wiedererkennungswert aufzugeben.

Beim URI-Konflikt genügte eine kleine Grenzregel. Weil Doppelpunkte sowohl in IPv6 als auch in der umgebenden URL-Syntax vorkamen, setzte RFC 2732 das Literal in eckige Klammern. Einfaches Kopieren und Einfügen mit möglichst wenig Bearbeitung war ein erklärtes Ziel; Implementierungen in IPv6-Versionen von Internet Explorer, Mozilla und Lynx wurden genannt. RFC 3986 behielt den geklammerten IP-literal-Ort bei.

Kanonische Ausgabe war ein Beweisabkommen

RFC 4291 übernahm die flexiblen Hexadezimalformen. RFC 5952 dokumentierte später deren Folgen für Suche, Textdateien, Tabellen, Whois, Diagramme, Protokolle, Audits und Verifikation. Die Lösung trennte Eingabe von Ausgabe: Parser mussten jede legitime RFC-4291-Form akzeptieren, Schreiber sollten eine kanonische Form erzeugen.

Für die Ausgabe galten kleine Hexadezimalbuchstaben, keine führenden Nullen, maximale Kompression der längsten Nullfolge, die erste Folge bei Gleichstand und kein :: für nur eine Nullgruppe. Nicht jede Ausgabe wurde absolut kürzestmöglich. Dafür hinterließen unabhängige Systeme mit größerer Wahrscheinlichkeit denselben sichtbaren Beleg für denselben Wert.

Das ist eine andere Optimierung als maximale Dichte. Weite Eingabe schützt vorhandene Daten. Enge Ausgabe verbessert künftige Vergleichbarkeit. Klammern lösen die äußere Mehrdeutigkeit. Jede Regel bleibt auf der Schicht, deren Problem sie tatsächlich behebt.

Gleichheit endet vor der Behauptung über das Netz

Sechs Stufen sollten getrennt bleiben: die 128 Bit, der geparste Wert, die normalisierte Anzeige, die gespeicherte Logzeichenfolge, der Suchtreffer und das beobachtete Netzwerkereignis. Zwei gleich dekodierte Zeichenfolgen beweisen Darstellungsgleichheit. Zwei gleiche kanonische Ausgaben beweisen eine Formatkonvention. Ein Logeintrag beweist, dass eine Komponente Text aufgezeichnet hat.

Keiner dieser Belege weist eine Adresszuteilung, eine autorisierte Routenankündigung, eine aktive Route, eine erreichbare Schnittstelle, einen authentifizierten Dienst oder eine Paketzustellung nach. Normalisierung erhöht die Auffindbarkeit von Evidenz, nicht deren logische Reichweite.

Die Primärquellen sind RFC 1884, RFC 1924, RFC 2732, RFC 3986, RFC 4291 und RFC 5952. Sie sind keine Einsatzstatistik, die null Base85-Implementierungen beweist, und belegen keine ausdrückliche formale Ablehnung durch spätere Autoren.

Running-Code Primacy liefert eine spätere Prüfperspektive: Entscheidend ist, was reale Parser, Logs und Abläufe annehmen und bewahren. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption erklärt die Koordinationskraft eines kleinen gemeinsamen Kerns neben lokalen Entscheidungen. Beides darf nicht als damalige Absicht der RFC-Autoren ausgegeben werden.

RFC 1924 verkürzte die Adresse. Die Kette aus Erkennen, Speichern, Finden und Beurteilen blieb genauso lang wie zuvor.