Zusammenfassung

  • RFC 5398 reserviert zwei ASN-Blöcke für Dokumentation; die aktuelle IANA-Tabelle führt Zweck, RFC-Referenz und Registrierungsdatum als überprüfbare Metadaten.
  • Ein Zahlenbereich ohne Quellenstand erklärt weder, warum ein Treffer problematisch ist, noch ob er in Dokumentation, Labor oder Produktion zulässig ist.
  • Validatoren brauchen versionierte Registry-Regeln, semantische Felder, reproduzierbare Entscheidungen und eine getrennte Prüfung des tatsächlich angewandten Zustands.

Die Zahlentabelle ist nicht die ganze Regel

Eine technische Umsetzung beginnt oft mit zwei Intervallen. Das ist nötig, aber nicht hinreichend. Die entscheidende Information lautet nicht nur, welche Zahlen dazugehören. Sie lautet, wofür sie reserviert sind.

RFC 5398 begründet die Reservierung mit dem Risiko, dass realistische Beispiele wörtlich in produktive Routing-Konfiguration übernommen werden. Öffentliche ASNs wären ungeeignet, weil sie reale Betreiber bezeichnen können. Private-Use-ASNs wären ebenfalls ungeeignet, weil sie in internen Netzen tatsächlich verwendet werden. Die Dokumentationsbereiche schaffen eine eigene Zweckklasse.

Der eingefrorene IANA-Stand führt 64496–64511 und 65536–65551 als für Dokumentation und Beispielcode reserviert und verweist auf RFC 5398. Er führt daneben die Private-Use-Bereiche mit RFC 6996 und AS_TRANS 23456 mit RFC 6793. Diese Nachbarschaft zeigt, warum ein generisches Merkmal reserved nicht genügt.

Ein Validator muss daher die Klasse, den zulässigen Kontext und die Handlung kennen. In einer RFC-Datei ist 64496 erwartbar. In einem produktiven local-AS-Feld ist derselbe Wert ein Ablehnungsgrund. In einer Telemetrie-Aufzeichnung ist er zunächst ein Untersuchungsindikator. Die Registry liefert die Zweckbindung; der Feld- und Umgebungskontext liefert die Entscheidung.

Historische Spezifikation und laufende Registry

RFC 5398 dokumentiert die ursprüngliche Reservierung aus dem Jahr 2008. Die IANA-Registry ist eine laufend gepflegte Sicht. Beide Evidenzschichten sind wichtig. Das RFC erklärt Absicht, Auswahl und operative Motivation. Die Registry zeigt den aktuellen klassifizierten Zustand zum erfassten Zeitpunkt.

Eine Implementierung, die nur hart codierte Zahlen besitzt, kann zwar heute richtig entscheiden, aber ihren Ursprung nicht erklären. Eine Implementierung, die bei jeder Prüfung unversioniert die aktuelle Webseite abfragt, kann spätere Entscheidungen nicht reproduzieren. Die belastbare Lösung friert einen Registry-Stand ein, versieht ihn mit Zeit und Hash und bindet die daraus erzeugte Regel an eine Version.

Ein Update wird dann zu einer kontrollierten Änderung. Die Organisation vergleicht alte und neue Klassifikationen, prüft betroffene Felder, führt Grenztests aus und aktiviert die Regel mit nachvollziehbarer Freigabe. Sie aktualisiert nicht still ein Ergebnis, das rückwirkend anders aussieht.

Das ist keine Forderung, die Registry selbst neu zu interpretieren. Im Gegenteil: Die Provenienz schützt davor, eine lokale Vermutung mit dem registrierten Zweck zu verwechseln.

Private Use hat eine andere Betriebsgeschichte

RFC 6996 beschreibt 64512–65534 und 4200000000–4294967294 als Private Use. Solche ASNs können innerhalb einer Organisation echte BGP-Rollen tragen. Sie sind nicht global eindeutig und müssen vor globaler Ankündigung aus Pfadattributen entfernt werden. Das RFC beschreibt sogar Implementierungsprobleme bei gemischten privaten und nicht privaten Pfaden.

Diese Anforderungen passen nicht auf Dokumentations-ASNs. Ein privater ASN kann in einem genehmigten internen Design zulässig sein; ein Dokumentations-ASN dient nicht als Ersatzinventar. Umgekehrt ist ein Dokumentations-ASN in Lehrmaterial korrekt, wo ein privater ASN mit einem realen internen Aufbau kollidieren könnte.

Wer beide Klassen in einer Regel „nicht öffentlich“ zusammenführt, verliert die passende Reaktion. Er könnte Dokumentationswerte produktiv zulassen oder Private Use pauschal verbieten, ohne den Ausgangsfilter zu prüfen. Governance beginnt mit genauer Klassifikation.

Auch Ausnahmen müssen klassenspezifisch sein. Ein isoliertes Konformitätslabor darf RFC-5398-Werte verwenden, weil es genau ihre dokumentarische Funktion nachbildet. Diese Erlaubnis darf nicht zu einem globalen Flag werden, das die Bereiche auf jedem Ziel akzeptiert.

Breitentests ohne fremde Identität

Der untere Block lässt sich als 16-Bit-ASN darstellen. Der obere beginnt bei 65536 und prüft damit das Vier-Oktett-Modell. RFC 6793 legt die Erweiterung fest und definiert AS_TRANS für einen besonderen Übergangszweck. AS_TRANS ist kein frei verfügbares Beispiel.

Die zwei RFC-5398-Blöcke ermöglichen realistische Tests von Speicherung, Anzeige, Serialisierung und Richtlinien. Ein System, das Werte auf 16 Bit kürzt, kann mit dem oberen Block zuverlässig auffallen. Ein Beispiel mit einer real vergebenen großen Zahl wäre ebenso technisch wirksam, würde aber einen Dritten in die Versuchsanordnung ziehen.

RFC 3849 mit 2001:DB8::/32 und RFC 5737 mit den TEST-NET-Bereichen folgen demselben Muster. Dokumentation benötigt strukturtreue Ressourcen, deren registrierter Zweck eine reale Zuweisung verhindert. „Derzeit frei“ wäre keine dauerhafte Eigenschaft für lang lebende Handbücher und Tests.

Reproduzierbare Zulassung statt grüner Vorstufen

Quelltextprüfung, Template-Test, Review und Dry Run liefern wertvolle, aber begrenzte Nachweise. Die Produktionseinlassprüfung muss das vollständig gerenderte Artefakt für ein konkretes Ziel sehen. Erst dort sind Feldbedeutung, Umgebung und Wirkung gemeinsam bekannt.

Die Entscheidung sollte Wert, Feld, Ziel, Regelversion, Registry-Snapshot und Konfigurationshash festhalten. Bei Ablehnung muss sie zur Herkunft im Template oder Inventar zurückführen. So ist das Ergebnis nicht nur korrekt, sondern reparierbar.

Nach der Aktivierung braucht es eine zweite Sicht. Exportierte Konfiguration, Nachbarzustand und Routenbeobachtung zeigen, was wirksam wurde. Ein erfolgreicher Versand beweist nicht, dass das Gerät genau diesen Stand übernommen hat. Ein erfolgreicher Nachbar beweist nicht, dass die verwendete Identität autorisiert war.

Die Nachweise dürfen nicht zu einem einzigen Status verschmelzen. Sonst wird aus einer Kette verschiedener Prüfungen ein grünes Symbol, das keine der entscheidenden Fragen eindeutig beantwortet.

Ein Registry-Treffer ist noch keine Attribution

Taucht 65536 in einem AS_PATH auf, sagt die Registry, dass die Zahl dokumentarisch reserviert ist. Sie sagt nicht, ob der Datensatz synthetisch ist, ob ein Labor speist, ob Anonymisierung vorliegt oder ob Konfiguration entkommen ist.

Die Untersuchung muss Kollektor, Peer, Zeitpunkt, Attributposition, Transformationen und Reichweite bewahren. Erst die Verbindung mit Change-Daten und Gerätezustand erlaubt eine belastbare Ursache.

Intelligence-Systeme sollten für diese Bereiche keine Betreiberentität erzeugen. Die Zahl ist gerade kein Hinweis auf einen rechtmäßigen Inhaber. Sie kann als beobachtetes Token mit Unsicherheit erfasst werden, nicht als Organisation mit erfundenen Beziehungen.

Auch nach einer technischen Korrektur müssen abgeleitete Daten bereinigt werden. Eine falsche Zuordnung in Inventar oder Berichten überlebt sonst den Konfigurationsfehler und erhält durch Wiederholung scheinbare Glaubwürdigkeit.

Wartung ist Teil der Kontrollwirkung

Regeln altern. Ein Scanner ohne Updateprozess kann korrekte Bereiche übersehen oder alte Klassifikationen fortschreiben. Die Organisation braucht einen Eigentümer, einen Aktualisierungsrhythmus, Grenzwerttests und eine sichtbare Anzeige des Regelstands.

Der Validator sollte die beiden Dokumentationsblöcke, die getrennten Private-Use-Blöcke und AS_TRANS ausdrücklich testen. Tests unmittelbar unter, auf und über den Grenzen verhindern typische Off-by-one-Fehler. Feldtests stellen sicher, dass ein Treffer in einer Dokumentationsdatei anders behandelt wird als in Produktionsidentität.

Damit wird Registry-Governance zu einer überprüfbaren Betriebseigenschaft statt zu einer versteckten Konstantendatei.