Zusammenfassung

  • Resolution 200605.27 ist als Billigung des Übergangs zu Vier-Oktett-AS-Nummern und als Umsetzungsauftrag an die Mitarbeitenden verzeichnet. Sie ist aber nicht der einzige einschlägige Akt: Das Protokoll von AFRINIC-4 beschreibt am 17. Mai 2006 erst einen Konsens zum weiteren Vorgehen, das Richtlinienarchiv nennt einen Last Call vom 13. bis 28. November, und Resolution 200611.34 verzeichnet erneut eine Billigung. Diese Dokumente dürfen nicht zu einem scheinbar widerspruchsfreien Stichtag verschmolzen werden.
  • Der Übergang war keine Anordnung an Router oder Netzbetreiber. Ab 1. Januar 2007 gab es eine nur mit ausdrücklicher Anforderung vergebene Vier-Oktett-ASN, während Zwei-Oktett-Werte Standard blieben; ab 1. Januar 2009 kehrte sich der Standard um; ab 1. Januar 2010 sollte aus einem nicht mehr nach Breite unterschiedenen Vier-Oktett-Pool vergeben werden. Die Richtlinie erklärte ausdrücklich, dass sie keine weitere Änderung der ASN-Vergabepolitik mit sich brachte.
  • Praktisch tragen Fähigkeitsaushandlung, AS_TRANS und zusätzliche Pfadinformationen den Übergang. Sie erlaubten ein schrittweises Zusammenspiel neuer und älterer BGP-Sprecher, beseitigten aber weder Geräteinkompatibilität noch Informationsverlust bei Aggregation, zu schmale Datenfelder, veraltete Filter oder doppelte Identitäten durch asdot- und asplain-Schreibweisen.
  • AFRINIC blieb bei diesem Vorgang privater Buchführer und Koordinator. Es konnte ein eindeutiges Register führen, Standardwerte in seinem Antragsprozess ändern, Bestände verwalten und Nachweise veröffentlichen. Daraus entstanden weder Eigentum an einer ASN noch gesetzgeberische, regulatorische, polizeiliche, staatsanwaltschaftliche, richterliche, strafende oder enteignende Befugnisse. Wirksam wurde die Umstellung dort, wo kompatibler laufender Code, überprüfbare Tests und freiwillige Entscheidungen von Betreibern tatsächlich Interoperabilität herstellten.

Zwei Billigungen, ein offener Widerspruch

Der Eintrag zur Resolution 200605.27 wirkt auf den ersten Blick eindeutig. Auf der öffentlichen Übersichtsseite der AFRINIC-Vorstandssitzungen von 2006 wird festgehalten, der Vorstand habe vier Richtlinien ratifiziert, darunter den vorgeschlagenen Wechsel von Zwei-Byte- zu Vier-Byte-AS-Nummern, und die Mitarbeitenden mit der Umsetzung beauftragt. Wer nur diesen Eintrag liest, könnte die Geschichte im Mai enden lassen: Antrag, Billigung, Ausführung. Gerade die übrigen zeitnahen Unterlagen verhindern jedoch eine solche Vereinfachung.

Der Bericht zu AFRINIC-4 behandelt den Vorschlag am 17. Mai noch als Gegenstand der Beratung. Die Diskussion war dem Bericht zufolge begrenzt, aber überwiegend zustimmend. Einige Teilnehmende hielten die Frage zu diesem Zeitpunkt offenbar noch nicht für besonders dringlich. Als Ergebnis wird ein Konsens genannt, mit dem Vorschlag weiterzugehen. Das ist ein wichtiger Verfahrensschritt, aber sprachlich und sachlich nicht dasselbe wie die in der Vorstandsübersicht verzeichnete abgeschlossene Ratifizierung mit Umsetzungsauftrag. Das Richtlinienarchiv ergänzt eine weitere Ebene: Es ordnet den Konsens ebenfalls dem 17.

Mai zu, verzeichnet aber anschließend einen Last Call vom 13. bis 28. November 2006. Auf derselben Vorstandsseite erscheint schließlich Resolution 200611.34, die die Vier-Oktett-ASN-Richtlinie abermals als ratifiziert aufführt. Der Bericht zu AFRINIC-5 stützt die spätere Zeitspur, denn er sagt, der Vorstand habe die Richtlinie wenige Tage vor dem Treffen Ende November beziehungsweise Anfang Dezember gebilligt und sie werde ab 1. Januar 2007 verfügbar sein.

Die Quellen erklären nicht, warum beide Resolutionen Ratifizierungssprache verwenden. Es wäre daher unbelegt, die Mai-Resolution als bloß vorläufig, die November-Resolution als rein formell oder beide als Teile eines bekannten juristischen Zweischritts auszugeben. Zulässig ist eine schmalere Aussage: Im Mai ist eine Vorstandsentscheidung samt Umsetzungsauftrag öffentlich verzeichnet; zugleich zeigt das erhaltene Archiv, dass die Verfahrensspur bis zu einem Last Call und einer gesondert verzeichneten Billigung Ende November weiterlief. Ob dies ein Dokumentationsfehler, ein zweistufiger interner Vorgang oder etwas anderes war, bleibt offen.

Sogar die Entstehungsmetadaten des Vorschlags mahnen zur Vorsicht. Das Richtlinienarchiv nennt als Datum den 22. September 2005, während seine Verlaufsliste als erste Veröffentlichung auf der Richtlinien-Mailingliste den 9. Dezember 2005 angibt. Auch diese Angaben sind nicht still zu harmonisieren. Ein belastbares Protokoll speichert beide Felder mit ihrer jeweiligen Quelle und Bedeutung. Es entscheidet nicht nachträglich, welches Datum „wirklich“ das Geburtsdatum der Richtlinie gewesen sein müsse.

Diese Genauigkeit ist mehr als Archivpflege. Wenn Meeting-Konsens, Vorstandsbeschluss, Last Call und spätere Ratifizierung in einem Datenfeld namens „genehmigt“ zusammenfallen, kann später niemand mehr prüfen, welche Fassung zu welchem Zeitpunkt umgesetzt werden sollte. Ein Ausführungsauftrag ist außerdem noch kein Nachweis dafür, dass Formulare, Zuteilungssoftware, WHOIS, delegierte Statistiken, Supportabläufe oder Netzbetreiber bereit waren. Die Chronologie ist deshalb der erste Kontrollpunkt der technischen Umsetzung: Jeder Akt braucht Datum, Wortlaut, Status, Quellenherkunft und eine unveränderte historische Kopie.

Drei Stufen statt eines Schalters

Der sachliche Kern der Richtlinie lag in der Staffelung. Der darstellbare Zahlenraum eines Zwei-Oktett-Felds reicht von 0 bis 65535, der gesamte Vier-Oktett-Raum von 0 bis 4294967295. Die Richtlinie bezeichnete den Bereich von 65536 bis 4294967295 als denjenigen, der nur mit vier Oktetten darstellbar ist. Diese Grenzen beschreiben Zahlenformate; sie bedeuten nicht, dass jeder Wert frei zuteilbar wäre. Protokoll- und Registerreservierungen bleiben möglich, und die Erweiterung eines Feldes erzeugt weder Eigentum noch einen hoheitlichen Titel.

Am 1. Januar 2007 begann die erste Stufe. Eine Organisation konnte ausdrücklich eine ASN aus dem nur vier Oktett breit darstellbaren Bereich anfordern; ohne eine solche Präferenz blieb eine Zwei-Oktett-ASN der Standard. Diese Reihenfolge gab Betreibern mit neuer Technik die Möglichkeit, reale Erfahrungen zu sammeln, ohne Betreiber älterer Infrastruktur sofort zum Wechsel zu zwingen. Sie schonte zugleich den engeren Bestand nicht maximal, sondern nahm einen begrenzten Verbrauch weiter hin, um Kompatibilität Zeit zu geben.

Am 1. Januar 2009 kehrte sich die Voreinstellung um. Nun sollte AFRINIC standardmäßig eine Vier-Oktett-ASN vergeben. Wer aus Kompatibilitätsgründen noch einen nur zwei Oktett breiten Wert benötigte, musste dies ausdrücklich beantragen. Der Übergang verlagerte damit die Begründungslast: 2007 musste der frühe Anwender den weiteren Zahlenraum wählen, 2009 musste der Betreiber mit Alttechnik den engeren Wert wählen. Ein Implementierungsbericht aus dem Jahr 2008 erinnerte an diese zweite Stufe und beschrieb die Zuordnung der Bestände.

Er belegt, wie AFRINIC den anstehenden Schritt öffentlich darstellte; er belegt nicht, dass jeder Router und jede Gegenstelle ihn beherrschte.

Am 1. Januar 2010 endete laut Zeitplan die Unterscheidung bei der Vergabe. AS-Nummern sollten aus einem gemeinsamen, nicht mehr nach Zwei- und Vier-Oktett-Werten getrennten Vier-Oktett-Pool zugeteilt werden. Der Stichtag war eine Registerregel, kein Netzbefehl. Er konnte bestimmen, welchen Standard der Buchführer bei einer neuen Vergabe anlegte. Er konnte aber kein Feld in einem fremden CRM verbreitern, keine Firmware aktualisieren, keine Filterregel reparieren und keinem alten BGP-Sprecher eine neue Fähigkeit verleihen.

Zudem hielt die Richtlinie ausdrücklich fest, dass aus diesem Übergang keine sonstige Änderung der ASN-Vergabepolitik folgte. Sie betraf die Breite beziehungsweise die Wahl des Zahlenbereichs, nicht die hier bewusst ausgeklammerten Voraussetzungen dafür, wer eine ASN erhalten sollte.

Der Zeitplan war also ein System aus Voreinstellungen und dokumentierbaren Anträgen. Eine Voreinstellung ist ein wirksames Koordinationsinstrument, weil viele Beteiligte ihr folgen und sich Anbieter auf bekannte Termine vorbereiten können. Sie ist gleichwohl keine Verfügung über den Betreiber. Ein belastbares Verfahren musste Ausnahmen zulassen, die technische Ursache erfassen und sichtbar machen, ob eine beantragte Zwei-Oktett-ASN tatsächlich wegen überprüfter Inkompatibilität benötigt wurde.

Gerade weil der schmalere Bestand knapp war, durfte eine Ausnahme nicht bloß zur Gewohnheit werden; gerade weil AFRINIC keine öffentliche Gewalt ausübte, durfte der weitere Wert aber auch nicht gegen nachgewiesene betriebliche Sicherheit erzwungen werden.

Die Kompatibilität lag auf vier verschiedenen Flächen

Die Umstellung wird unverständlich, wenn „Vier-Oktett-Unterstützung“ als einzelnes Ja-Nein-Merkmal behandelt wird. Tatsächlich musste sie mindestens auf vier Flächen funktionieren: im BGP-Protokoll zwischen Sprechern, in den Geräten und Betriebswerkzeugen eines Betreibers, in den Daten- und Anzeigeformaten des Registers sowie in der Beweiskette zwischen Antrag, Zuteilung, öffentlichem Datensatz und beobachteter Nutzung. Ein grünes Signal auf einer Fläche konnte einen Fehler auf einer anderen nicht aufheben.

Auf Protokollebene war der entscheidende Entwurf inkrementell. Ein BGP-Sprecher konnte in der Aushandlung anzeigen, dass er Vier-Oktett-AS-Nummern unterstützt. Zwei neue Sprecher konnten dann die breitere Darstellung nutzen; traf ein neuer Sprecher auf einen älteren, war ein kompatibler Austausch ohne netzweiten Umschalttag vorgesehen. Eine nicht in zwei Oktetten abbildbare ASN erschien gegenüber dem älteren Sprecher im herkömmlichen AS_PATH als AS_TRANS mit dem Zahlenwert 23456.

Zusätzliche, optional transitive Pfadinformationen konnten durch ältere Sprecher weitergereicht werden, damit ein späterer Vier-Oktett-tauglicher Sprecher mehr vom ursprünglichen Pfad rekonstruieren konnte.

Die Namen dieser Hilfsattribute gehören selbst zur Chronologie. Der einschlägige Internet-Draft vom November 2005 war ein Arbeitsentwurf und sprach von NEW_AS_PATH und NEW_AGGREGATOR. Erst RFC 4893, veröffentlicht im Mai 2007 und damit nach der AFRINIC-Entscheidung von 2006, standardisierte die Bezeichnungen AS4_PATH und AS4_AGGREGATOR. Wer die späteren Namen in einen Bericht über den Stand von 2005 hineinliest, macht aus einer Entwicklung einen scheinbar zeitlosen Standard.

Umgekehrt darf die damalige technische Idee durchaus erklärt werden: Fähigkeitsanzeige, Stellvertreterwert und ergänzende Pfadinformationen waren bereits als Mechanismus für den schrittweisen Übergang angelegt. RFC 4893 wurde später abgelöst; hier dient es als Beleg für den damals standardisierten Übergangsmechanismus und seine dokumentierten Grenzen, nicht als Behauptung über den heutigen Normstand.

Die Übergangstechnik war nicht verlustfrei. Aggregierte ein älterer Sprecher Routen, konnte Information verloren gehen, die für eine vollständige Rekonstruktion des ursprünglichen Pfads benötigt wurde. Widersprachen sich der herkömmliche AS_PATH und die ergänzende Vier-Oktett-Pfadinformation, konnten Schleifen- oder Sicherheitsrisiken entstehen. AS_TRANS war daher nicht einfach ein Zeichen dafür, dass „alles funktioniert“, sondern ein beobachtbares Signal einer gemischten Umgebung. Ein sinnvoller Betrieb musste sein Auftreten, die Konsistenz der Attribute und das Verhalten in Topologien mit alten und neuen Sprechern überwachen.

Rohdaten von Updates waren wertvoll, weil eine nachträglich geglättete Ansicht den ursprünglichen Widerspruch verbergen konnte.

Auf Geräteebene lag die Verantwortung dort, wo die Software tatsächlich lief. Der standardisierte Mechanismus nahm an, dass die BGP-Sprecher innerhalb eines autonomen Systems aktualisiert würden, bevor dieses System eine Vier-Oktett-ASN nutzte. Die Zuteilung eines neuen Werts konnte diesen Schritt nicht ersetzen. Neben Routern mussten Provisionierung, Netzmanagement, Monitoring, Alarmierung und Konfigurationsgeneratoren geprüft werden.

Filter und Community-Konventionen, die eine 16-Bit-Annahme in Aufbau oder Syntax eingebaut hatten, verlangten besondere Aufmerksamkeit; RFC 4893 verwies für vergleichbare Zwecke auf Vier-Oktett-AS-spezifische Extended Communities. Eine Anwendung konnte einen Zahlenwert korrekt speichern und ihn trotzdem in einer Filtervorlage abschneiden. Ein Router konnte BGP korrekt sprechen, während das Ticketing die ASN ablehnte. „Unterstützt“ war deshalb nur eine belastbare Aussage, wenn Komponente, Version, Testfall und Gegenstelle genannt wurden.

Eine Zahl darf nicht zu zwei Identitäten werden

Die dritte Fläche war die Datendarstellung. Der ursprüngliche Richtlinientext verwendete asdot-Beispiele: Der dezimale Wert 65546 konnte als 1.10 erscheinen. RFC 5396 wählte später für alle AS-Nummern die einheitliche dezimale asplain-Darstellung, gerade weil gemischte Schreibweisen im Betrieb Verwirrung erzeugten. Auch diese Entscheidung darf nicht rückwirkend dem Jahr 2006 zugeschrieben werden. Sie liefert aber eine klare Lehre für die Aufzeichnungen: Darstellung und Identität müssen getrennt werden.

Der kanonische Datensatz sollte den ganzzahligen Wert unabhängig von seiner Anzeigeform speichern. Historische Eingaben bleiben als Beleg erhalten, werden aber einer einzigen Identität zugeordnet. Suche, WHOIS, Routing-Collector, Tickets, Filter, Abrechnung und Kundenverwaltung müssen 1.10 und 65546 als dieselbe ASN erkennen. Geschieht das nicht, entstehen scheinbare Dubletten: Ein Supportfall findet den Registereintrag nicht, ein Filter greift auf die falsche Schreibweise zu, oder eine Prüfung zählt zwei Zuteilungen, obwohl nur eine existiert.

Eine Migration, die bloß sämtliche Punkte entfernt, wäre ebenso gefährlich wie gar keine Normalisierung; erforderlich ist eine definierte Umrechnung mit Hin- und Rücktest und erhaltener Originaldarstellung.

Noch grundsätzlicher ist die Feldbreite. Ein altes Datenbankschema, eine API oder ein Überwachungswerkzeug kann auf 16 Bit begrenzt sein. Dann wird ein höherer Wert möglicherweise sichtbar abgelehnt, unbemerkt abgeschnitten oder bei einem Überlauf in einen anderen Wert verwandelt. Ein solcher Fehler verletzt nicht nur die Anzeige, sondern die Eindeutigkeit. Jede Schnittstelle muss daher mit Grenzwerten geprüft werden: größter Zwei-Oktett-Wert, erster nur vier Oktett darstellbarer Wert, höhere reale Werte und ungültige Eingaben.

Verlustbehaftete Schreibvorgänge sind abzulehnen; Migrationsprotokolle müssen zeigen, welche Datensätze verändert wurden und ob sich die kanonische Zahl erhalten hat.

Eine Behauptung AFRINICs, Zuteilungs- und WHOIS-Systeme unterstützten den ganzen Zahlenraum, ist in diesem Rahmen eine überprüfbare Implementierungsbehauptung. Sie beweist weder, dass alle internen Komponenten bereits zum frühesten politischen Stichtag umgestellt waren, noch dass externe Router, Formulare oder Datenbanken mithielten. Genau diese Grenze ist für die spätere Evidenz wichtig: Ein öffentlicher Eintrag kann korrekt sein, während ein Netzbetreiber wegen eines unpassenden Geräts die Nummer nicht einsetzen kann; ein im Routing sichtbarer Wert kann existieren, während ein Kundensystem seine Darstellung falsch führt.

Vom vorgelagerten Bestand bis zum gemeldeten Tausch

Die Umsetzung hinterließ einzelne, zeitlich verteilte Kontrollpunkte. Das IANA-Register verzeichnet den Block 327680 bis 328703 am 29. November 2006 für AFRINIC. Dieser Eintrag ist ein nützlicher Abgleich für den vorgelagerten Bestand kurz vor der ersten Richtlinienstufe. Er beweist, dass das Register an diesem Datum diese Zuordnung enthält. Er beweist nicht, wann AFRINIC erstmals eine einzelne ASN daraus weitergab, wann ein Betreiber sie akzeptierte oder wann sie erstmals in einer Route erschien.

Für eine Bestandsprüfung muss der Block vielmehr mit lokal verfügbaren, zugeteilten, reservierten und ausnahmsweise behandelten Werten abgeglichen werden.

Der Bericht zu AFRINIC-9 aus dem Jahr 2008 zeigt, dass die Übergangsfrage zwei Jahre nach den Beschlüssen weiter als Umsetzungsaufgabe kommuniziert wurde. Er beschreibt Bestandszuordnungen und erinnert an die bevorstehende Umkehr des Standards am 1. Januar 2009. Das ist bedeutsam, weil es die politische Zeitachse mit einer späteren operativen Darstellung verbindet. Doch auch ein Implementierungsbriefing bleibt Selbstauskunft. Es ersetzt keine Änderungsaufträge für das Antragsformular, keine Tests des Zuteilungsmoduls und keine Belege aus Netzen.

Der AFRINIC-Jahresbericht 2012 berichtet, die Auswahlmöglichkeit zwischen 16- und 32-Bit-AS-Nummern sei 2011 aus dem Formular entfernt worden; anschließend sei aus einem gemeinsamen 32-Bit-Pool zugeteilt worden. Die Jahreszahl fällt auf. Die Richtlinie hatte die ungeteilte Vergabe für Anfang 2010 vorgesehen, während der berichtete Formulareingriff erst 2011 erfolgte. Daraus darf nicht automatisch geschlossen werden, die Richtlinienphase von 2010 sei gescheitert: Ein Formular kann später bereinigt werden als die dahinterliegende Vergabelogik. Es wäre aber ebenso unzulässig, die Differenz zu ignorieren.

Ein Auditor müsste Änderungsprotokolle, Formularversionen und Zuteilungsentscheidungen heranziehen, um zu klären, welcher Teil wann tatsächlich geändert wurde.

Am 11. Mai 2012 kündigte ein öffentlicher Beitrag auf der RPD-Liste an, AFRINICs Systeme unterstützten einen nicht unterschiedenen Pool und die asplain-Darstellung nach RFC 5396. Der Beitrag datiert eine öffentliche Implementierungsbehauptung. Er markiert nicht zwingend den ersten Tag der technischen Unterstützung und garantiert nicht die Einsatzbereitschaft der Betreiber. Im selben zeitlichen Umfeld meldete der Jahresbericht 145 zugeteilte AS-Nummern, davon sechs 32-Bit-Werte.

Er hielt außerdem fest, dass inkompatible Geräte zu fallweisen Tauschvorgängen führten: höherwertige 32-Bit-AS-Nummern wurden gegen niedrigere 32-Bit-AS-Nummern ausgewechselt. Diese Formulierung ist wichtig, weil „32 Bit“ als Speicherkategorie nicht automatisch bedeutet, dass ein Gerät den gesamten Bereich in jeder Funktion verarbeiten konnte.

2014 berichtete die NRO RIR-übergreifend, inkompatible Router hätten manche Kunden dazu veranlasst, Vier-Oktett-AS-Nummern zurückzugeben oder gegen Zwei-Oktett-AS-Nummern zu tauschen. Diese spätere Zusammenfassung bestätigt die Art der Reibung über eine einzelne Region hinaus. Sie erlaubt aber nicht, jeden genannten Tausch AFRINIC zuzurechnen. Zusammengenommen zeigen die AFRINIC- und NRO-Unterlagen nicht das Scheitern der Staffelung, sondern etwas analytisch Wertvolleres: Die Registerumstellung ging voran, während reale Ausnahmen und Nacharbeiten fortbestanden.

Politischer Meilenstein und vollständige technische Bereitschaft waren verschiedene Zustände.

Die Umsetzung muss sich von außen rekonstruieren lassen

Eine belastbare Prüfung stellt nicht die pauschale Frage, ob AFRINIC „die Richtlinie umgesetzt“ habe. Sie fragt, ob ein unabhängiger Prüfer den Weg von der Fassung des Vorschlags über Verfahrensakte und Bestand bis zu Antrag, Entscheidung, öffentlichem Registereintrag, Betreiberannahme, Routingnutzung, Ausnahme und gegebenenfalls Tausch rekonstruieren kann, ohne die Schlussfolgerung der Institution übernehmen zu müssen.

Am Anfang stehen genaue, datierte Kopien: Text, Referenz, Fassung und Veröffentlichungsmetadaten des Vorschlags; Bericht und Tagesordnung von AFRINIC-4; festgehaltener Konsens; Last-Call-Daten; die beiden Resolutionen 200605.27 und 200611.34; sowie eine ausdrückliche Notiz, dass die öffentliche Chronologie nicht widerspruchsfrei ist. Ein Hash oder eine gleichwertig datierte, unveränderbare Kopie schützt davor, dass spätere Seitenänderungen die damalige Fassung überschreiben.

Die Methode der zeitgebundenen Registerprüfung verlangt dabei, Organisation, Kontakte, Datumsangaben und Werte als Momentaufnahme festzuhalten, statt eine heute sichtbare Seite als unveränderte Vergangenheit zu behandeln.

Danach folgen die internen Umsetzungsspuren: Arbeitsaufträge und Änderungen für Antragsformulare, Zuteilungsmaschine, WHOIS-Schema, delegierte Statistiken, öffentliche Dokumentation und Support. Der am 29. November 2006 verzeichnete IANA-Block ist gegen das lokale Inventar zu rechnen. Die Summe aus verfügbar, zugeteilt, reserviert und als Ausnahme gebunden muss sich nach dokumentierten Anpassungen mit dem vorgelagerten Bestand decken. Eine Differenz ist keine Einladung zum stillen Korrigieren, sondern ein Prüfpunkt mit Ursache, verantwortlicher Rolle und Reparaturnachweis.

Für jede einzelne Zuteilung braucht es die Anforderung, die zu diesem Zeitpunkt geltende Standardphase, eine geäußerte Präferenz, die zugeteilte kanonische Dezimalzahl, die historische Anzeigeform, Zeitstempel und die verantwortliche betriebliche Rolle. Die Methode der Zuteilungsakte verbindet Anfrage, Bewertung, Entscheidung, Bestand und öffentlichen Datensatz. Sie importiert keine fremden Skandalbehauptungen in diesen Fall; sie stellt eine nüchterne Frage: Kann die Entscheidungskette vollständig belegt werden, oder steht am Ende lediglich eine Nummer in einer Tabelle?

Die Betreiberseite ergänzt Versionen von Router und Software, Fähigkeitsaushandlung, Labor- oder begrenzte Einsatztests, Prüfung von Filtern und Communities, Peer-Kompatibilität, Wartungsfenster und Rückfallplan. Antragsticket, Zuteilungsdatenbank, WHOIS beziehungsweise aut-num-Datensatz, delegierte Statistik und beobachtete Route werden nach Wert und Datum abgeglichen. Die Abwesenheit einer Route darf dabei nicht automatisch als ungültige Zuteilung gelten; nicht jede zugeteilte ASN muss zu jedem Prüfzeitpunkt sichtbar im Routing sein. Umgekehrt beweist Routing-Sichtbarkeit allein nicht die Richtigkeit der gesamten Vergabeakte.

Jeder Tausch oder jede Rückgabe muss eine zweiseitige, unveränderbare Spur behalten: alte und neue ASN, Grund, betroffene Systeme, Autorisierung, Aktualisierung öffentlicher Einträge, Migration der Routen und Abschlussnachweis. Wird der alte Datensatz einfach überschrieben, verlieren Betreiber die Möglichkeit, frühere Peer-Konfigurationen, Verträge, Störungen oder Beobachtungen zuzuordnen. Eine Reparatur, die ihre eigene Ursache auslöscht, erzeugt eine neue Kontinuitätslücke.

Notwendige Koordination, reale Kosten

Der stärkste Fall für den Beschluss beginnt nicht bei institutioneller Legitimität, sondern bei einer endlichen technischen Kapazität. Ohne vorhersehbaren Übergangsplan hätten Anbieter und Betreiber weniger Vorlauf erhalten. Der engere Zahlenraum hätte sich weiter gefüllt, während Formate, Software und Betriebsabläufe erst unter größerem Zeitdruck angepasst worden wären. Die drei Stufen waren vernünftig konstruiert: zunächst freiwillige Anforderung, zwei Jahre später Umkehr des Standards, danach Aufhebung der Bestandsunterscheidung. Das Protokoll vermied einen einzigen netzweiten Umschalttag.

Diese Kombination ist ein starkes Beispiel dafür, wie eine dünne gemeinsame Koordinationsschicht notwendige Arbeit leisten kann.

Der stärkste Einwand richtet sich nicht gegen den erweiterten Zahlenraum, sondern gegen Übervertrauen in Kalender und Register. Schon bei AFRINIC-4 gab es Stimmen, die das Thema noch nicht für relevant hielten. Die Verfahrensunterlagen reichen bis November, und spätere Berichte dokumentieren inkompatible Ausrüstung und Tauschfälle. Eine private Registerorganisation hätte künstliche Ausgrenzung erzeugt, wenn sie 2006 sofort eine technisch nicht nutzbare Nummer erzwungen hätte. Eine Voreinstellung kann Verhalten lenken; sie kann aber keine unerfüllte Protokollfähigkeit herbeibeschließen.

Wer die Richtlinie als hinreichenden Beweis der Betriebsbereitschaft behandelte, verlagerte Risiken auf diejenigen, die Wartungsfenster, Ersatzgeräte, Personal und Peer-Abstimmung finanzieren mussten.

Die Kosten waren ungleich verteilt. Große Netze konnten Labore, Ersatzhardware und Spezialisten eher vorhalten. Kleinere Betreiber waren möglicherweise länger an Geräte gebunden, deren Routing zwar stabil lief, deren Software aber höhere Werte, neue Pfadattribute oder angepasste Communities nicht vollständig beherrschte. Hinzu kamen Änderungen an Monitoring, Provisionierung, Ticketing, Berichten und kommerziellen Systemen. Ein missglückter Einsatz konnte Peerings oder Erreichbarkeit beeinträchtigen; ein Tausch verlangte neue Konfigurationen und Abstimmung.

Die Entscheidung eines Registers hatte somit reale infrastrukturelle und wirtschaftliche Folgen, ohne dadurch regulatorische Gewalt zu erlangen.

Die bessere Auflösung verbindet den gestuften Standard mit messbarer Bereitschaft. AFRINIC konnte Komponentenstatus, offene Testergebnisse, bekannte Inkompatibilitäten, Anzahl der Ausnahmen und dokumentierte Tauschverfahren veröffentlichen. Betreiber konnten den Einsatz anhand ihres laufenden Codes und ihrer Gegenstellen terminieren, mussten dabei aber die tatsächlichen Zwänge der Zusammenschaltung anerkennen. „Freiwillig“ bedeutet nicht folgenlos: Wer mit Peers Daten austauschen will, muss kompatible Semantik verwenden.

Es bedeutet, dass die konkrete Einführung nicht aus dem Prestige einer Resolution folgt, sondern aus informierter Zustimmung, funktionsfähiger Technik und transparent behandelten Abhängigkeiten.

Der Buchführer ist nicht der Herrscher

Der Übergang zeigt besonders klar, welche Macht ein Register tatsächlich besitzt. AFRINIC konnte innerhalb seines vorgelagerten Bestands eine eindeutige ASN-Liste führen. Es konnte den Standard im Antragsformular ändern, Zuteilungen eintragen, öffentliche Daten pflegen und Kompatibilitätsinformationen veröffentlichen. Diese Tätigkeiten sind bedeutsam, weil doppelte oder widersprüchliche Identifikatoren den Betrieb stören würden. Die Autorität des Datensatzes reicht jedoch nicht weiter als die eng begrenzte Aufgabe, Eindeutigkeit und Anschlussfähigkeit zu koordinieren.

Eine ASN ist in diesem Vorgang weder Grundstück noch Eigentumstitel, Lizenz, staatliche Konzession oder von AFRINIC geschaffenes Recht. Die Organisation besaß deshalb keine Souveränität über das Netz, dem sie eine Nummer zuordnete. Sie konnte nicht gesetzgeberisch oder staatlich regulierend handeln, nicht polizeilich ermitteln, nicht anklagen, richten, bestrafen oder konfiszieren. Das Wort „Konsens“ in einem internen Prozess erzeugte keine Gemeinwohlhoheit. Ebenso wenig machten IANA-Register, IETF-Dokumente oder NRO-Berichte ihre Herausgeber zu Staaten.

Diese Quellen belegen genaue technische oder institutionelle Aussagen; sie ersetzen keine Rechtsgrundlage und keinen Nachweis universeller Legitimität.

Die leitende Doktrin ist daher die des privaten Buchführers: Wer das Adressbuch pflegt, darf die eindeutige Eintragung nicht mit Urheberschaft, Eigentumsschöpfung oder Gerichtsbarkeit verwechseln. Die gemeinsame Schicht bleibt dünn. Sie umfasst stabile Identifikatorsemantik, deterministische Gültigkeitsregeln, Eindeutigkeit, Konfliktbehandlung, Interoperabilität auf dem Draht, portable Nachweise und versionierte Erweiterungen. Entscheidungen darüber, wann Geräte ersetzt, Filter geändert oder interne Systeme migriert werden, verbleiben grundsätzlich beim Betreiber, soweit wirkliche Interoperabilitätsanforderungen keine Abstimmung erzwingen.

Running Code ist in diesem Fall keine Entwicklerparole, sondern die Grenze zwischen Aufzeichnung und Wirklichkeit. Eine Resolution konnte AFRINICs Vergabeprozess festlegen. Sie konnte keinen alten Router befähigen, eine Vier-Oktett-ASN zu verstehen. Der effektive Übergang existierte erst in getesteten Implementierungen und williger Bereitstellung: in der korrekt ausgehandelten Fähigkeit, im erhaltenen Pfad, in der breiten Datenbankspalte, im passenden Filter und in der Gegenstelle, die dasselbe versteht. Genau deshalb ist die spätere Reibung kein Nebensatz.

Sie ist der Beweis, dass Koordination nur dann ihren Zweck erfüllt, wenn Dokument und Betrieb miteinander abgeglichen werden.

NRS hat in dieser Ordnung eine andere, ebenfalls begrenzte Rolle. NRS kann forschen, für ausdrücklich autorisierte Mitglieder eintreten, Akteure zusammenbringen und deren Interessen vertreten. Es betreibt weder Register noch RPKI, WHOIS oder RDAP, keine Beschwerde- oder Vergleichsinstanz, keine Wahlen, Verwahrung oder Kontinuitätsfunktion. Seine Evidenzmethode — datierte Registerstände sichern, Organisationsdaten, Kontakte und Zeitangaben vergleichen und Aussagen zeitlich begrenzen — unterstützt Betreiber und Prüfer, ersetzt aber nicht die operative Registerführung.

LARUS' Betreiberperspektive macht die Kontinuitätskosten sichtbar; die BTW-Methode ordnet die Zuteilungsakte. Keine dieser Rollen begründet öffentliche Gewalt.

So gelesen war Resolution 200605.27 weder belanglos noch allmächtig. Sie war ein dokumentierter Koordinationsakt innerhalb eines widersprüchlich überlieferten Verfahrens. Ihr Nutzen lag in Vorlauf, Voreinstellungen und einer nachvollziehbaren Übergangsrichtung. Ihre Grenze lag dort, wo fremde Systeme, betriebliche Entscheidungen, rechtliche Verhältnisse und öffentliche Gewalt beginnen. Die bleibende Leistung war nicht, einen größeren Zahlenraum zu „beherrschen“, sondern eine schrittweise Konvention anzustoßen, deren Erfolg an kompatibler Technik, sauberen Aufzeichnungen und erhaltenen Wahlmöglichkeiten messbar bleibt.