Zusammenfassung

  • Barrys README nennt ::/0 als standardmäßige IPv6-Ressource eines Trust Anchors; Issue 7 meldet zugleich, dass diese Schreibweise in Ressourcenfeldern von Zertifikat und ROA abgewiesen wird.
  • Im festgehaltenen Code dürfen Doppelpunkt und Schrägstrich in einem bereits begonnenen, nicht zitierten Token vorkommen. Beginnen darf es aber nur mit einem alphanumerischen Zeichen, $ oder . Deshalb passiert 0::/0 den Lexer, ::/0 nicht.
  • RFC 4291 erlaubt ::/0 als legitimes IPv6-Präfix; RFC 5952 macht diese Form zur kanonischen Ausgabe. 0::/0 hat denselben Wert, ist aber nicht maximal komprimiert.
  • Die Quellen belegen weder ein fehlerhaft erzeugtes RPKI-Objekt noch ein Urteil eines Relying Party oder Auswirkungen auf Produktion und Routing. Nötig ist eine versionierte Konformitätstabelle vom Lexer bis DER mit eindeutigen Abbruchstufen.

Eine Null verändert den Eintritt, nicht das Netz

Der gesamte Unterschied ist ein Zeichen:

::/0
0::/0

Beide Zeichenfolgen stehen für die aus 128 Nullbits bestehende IPv6-Adresse mit Präfixlänge null, also für den gesamten IPv6-Adressraum. Das Issue 7 im Repository LACNIC/barry beschreibt trotzdem zwei Programmpfade: Die kanonische Form endet an einem unerwarteten Zeichen; die mit einer Ziffer beginnende Form dient als Umgehung.

Diese Grenze ist bei einem RPKI-Materialgenerator besonders wichtig. Barry kann auch absichtlich fehlerhafte Objekte herstellen, an denen Validatoren geprüft werden sollen. Ein negativer Test beginnt aber erst, wenn eine legitime positive Eingabe in einen bestimmten semantischen Wert und anschließend in identifizierbare Bytes umgewandelt wurde. Erzeugt die Beschreibungssprache nicht einmal ein Token, ist der Fehler weder dem Zertifikat noch dem ROA oder dem Relying Party zuzurechnen. Es gab kein Objekt, über das diese Komponenten entscheiden konnten.

Die stärkste institutionelle Einordnung bleibt zurückhaltend. Die Repository-Metadaten beschreiben einen kleinen Generator, keinen Produktionsdienst. Das am untersuchten Commit fixierte README bezeichnet Projekt und Repository-Descriptor-Spezifikation als work in progress und kündigt mögliche inkompatible Änderungen vor Version 1.0 an. Die erfassten Listen der Releases und Tags sind leer. Ein offenes Issue mit kleinem Beispiel ist für einen Prototypen hilfreiche Transparenz, kein Nachweis eines Betriebsereignisses.

Beispiel und eingefügter Trace sind nicht bytegleich

Das Issue wurde am 28. August 2026 eröffnet. Zum Belegstichtag 6. September war es weiter offen, ohne Labels, Kommentare oder spätere Änderung. GitHub führt die Verbindung des Meldenden zum Repository als NONE. Eine Bestätigung, Diagnose oder Korrektur durch Maintainer liegt nicht vor.

Der Bericht setzt ::/0 an zwei Stellen ein: in die IP-Ressourcenerweiterung eines CA-Zertifikats und in ipAddrBlocks eines ROA. Als vorläufiger Ausweg wird 0::/0 genannt. Innerhalb des Belegs gibt es jedoch eine wichtige Abweichung. Der angezeigte Reproduktions-Descriptor verwendet in beiden Feldern ::/0; der eingefügte Trace gibt den ersten Wert bereits als 0::/0 aus und hält später am ersten : eines anderen Feldes mit Unexpected character: : (0x3a) an.

Diese Abweichung entkräftet das Issue nicht, sie begrenzt die Aussage. Der Trace zeigt unmittelbar ein Scheitern an einem führenden Doppelpunkt. Der Bericht behauptet die Ablehnung der kanonischen Form in beiden Feldern. Das öffentliche Material beweist nicht unabhängig zwei bytegleiche Fehler in einem einzigen Lauf. Genau deshalb sollte ein Konformitätsbeleg die Eingabebytes und ihren Hash bewahren: Schon das Kopieren des Workarounds in ein Feld kann den Versuch unbemerkt verändern.

Ebenso wenig enthält der Trace ein fehlerhaftes Zertifikat oder ROA, ein veröffentlichtes Repository oder ein Validierungsergebnis. Er zeigt keine Routenänderung und keinen Einsatz in LACNICs produktiver RPKI-Umgebung. Solche Ereignisse liegen hinter der beobachteten Grenze.

Die Regel für das erste Zeichen erklärt die Asymmetrie

Die Codebetrachtung ist auf Commit 994a598321336baf1767f0fbfb460ed96c29fe4f vom 1. September festgelegt. Dessen Betreff betrifft authorityCertIssuer im AKI und beansprucht keine Lösung für Issue 7. Die jüngere Commit-Historie fixiert den Beobachtungszeitpunkt, nicht die Entstehung des Verhaltens.

In src/rpki_tree.c beginnt next_token eine nicht zitierte Zeichenfolge nur, wenn ihr erstes Zeichen alphanumerisch, $ oder ist. Ein Doppelpunkt erfüllt keine dieser Bedingungen. Der Ablauf gelangt zu try_emoji; ein gewöhnliches : wird danach als unerwartet abgewiesen.

Ist die Zeichenfolge einmal begonnen, gilt eine breitere Regel. Doppelpunkte und Schrägstriche dürfen in ihr verbleiben, weil vor allem Leerraum und strukturelle Trennzeichen ausgeschlossen werden. Die führende Null von 0::/0 bringt also keine IPv6-Bibliothek dazu, ein anderes Netz zu akzeptieren. Sie erfüllt nur die Startbedingung; der Rest bleibt im bereits geöffneten Token.

Das README selbst macht die Grenze sichtbar. Es zeigt auch 2001:db8::/64, das mit einer Hexadezimalziffer anfängt und deshalb die Eingangskontrolle passiert. Zugleich listet es ::/0 als Standard-IPv6-Ressource des Trust Anchors. Die pauschale Aussage „komprimiertes IPv6 wird unterstützt“ wäre ungenau: Kompression nach einer Ziffer und Kompression ab dem ersten Zeichen nehmen unterschiedliche lexikalische Wege.

Der eigentliche IP-Präfixparser liegt weiter hinten. In src/field.c trennt parse_ip_node am /, erkennt IPv6 am Doppelpunkt, ruft inet_pton auf und liest anschließend die Präfixlänge. Die abgewiesene Schreibweise erreicht diese Funktion nie. Ein Fehler von inet_pton, der Längenprüfung oder Feldbindung ist daher nicht belegt.

Die kanonische Form gehört auf den gewöhnlichen Pfad

RFC 4291 erlaubt :: zur Kompression aufeinanderfolgender Nullgruppen und verwendet :: selbst für die vollständig leere IPv6-Adresse. Ein Präfix verbindet eine legitime Adressform mit / und einer Länge. ::/0 ist somit eine zulässige IPv6-Eingabe.

RFC 5952 trennt Annahme und Ausgabe. Implementierungen sollen legitime RFC-4291-Formen annehmen und beim Erzeugen von Text die kanonische, maximal komprimierte Darstellung verwenden. 0::/0 behält dieselbe Familie, denselben Wert und dieselbe Länge, lässt aber eine Nullgruppe stehen, die eine kanonische Ausgabe entfernt.

Eine begrenzte lokale Gegenprobe mit Rubys IPAddr normalisierte ::/0, 0::/0, 0000::/0 und die ausgeschriebene Nulladresse auf denselben Wert und Bereich. Das war kein Barry-Lauf und hat keine normative Autorität. Die Probe stützt lediglich die Entscheidung, die lexikalische Grenze statt eines erfundenen semantischen Unterschieds zu untersuchen.

Auf Objektebene verwendet RFC 3779 DER-BIT-STRINGs für IP-Ressourcen. Der Block aller Adressen mit Präfixlänge null wird zu 03 01 00. Die ursprüngliche Schreibweise bleibt keine Eigenschaft des Zertifikats oder ROA. Stoppt die Eingabe am Lexer, gibt es keinen DER-Wert, den ein Relying Party annehmen oder ablehnen könnte.

Eine kleine Tabelle hält die Entscheidungswege auseinander

Statt eines allgemeinen Kompatibilitätsversprechens genügt eine versionierte Tabelle. Jede Zeile bindet die exakten Descriptor-Bytes und ihren Hash, das Zielfeld, das Token-Ergebnis, normalisierte Adressfamilie/Wert/Präfixlänge, die kanonische Ausgabe, Parser- und Generator-Commit sowie den Objekthash, falls die Konstruktion erreicht wurde.

Die Endstufe sollte aus einer festen Liste stammen: descriptor-tokenize, prefix-parse, field-bind, object-build, DER-encode oder RP-validate. Dann kann eine Ablehnung im Generator nicht als Validatorfehler gezählt werden. Die zentrale Invariante lautet parse(format(parse(input))): Familie, Wert und Länge bleiben erhalten. Gleichwertige legitime Eingaben müssen bei erfolgreicher Erzeugung auf denselben DER-Präfixwert zulaufen.

Dieses Instrument zertifiziert weder Barry noch die gesamte IPv6-Verarbeitung. Es beantwortet eine kleine, lokal prüfbare Frage: Welche Bytes wurden angenommen, welcher Wert wurde verstanden, welches Objekt entstand und welche Stufe traf die letzte Entscheidung? Für einen Generator negativer Tests ist gerade diese Trennung der belastbare Vertrag.

Quellen