Zusammenfassung

  • Resolution 202002.552 ratifizierte im Februar 2020 mit Multihoming Not Required for ASN Draft 4 und Adjusting IPv6 PI zwei technisch verschiedene Regeln in einem privaten Körperschaftsakt. Das gemeinsame Beschlussformat war nicht an sich problematisch; es verringerte allenfalls Wiederholung auf Entscheidungsebene.
  • Der ASN-Strang betraf den Nachweis, wann globale Koordination eine eindeutige öffentliche Routing-Identität verlangt, ohne den Kauf eines zweiten physischen Upstreams zur absoluten Voraussetzung zu machen. Der IPv6-Strang betraf dagegen die Gefahr, legitime nicht öffentlich angekündigte PI-Nutzung mit Nichtnutzung zu verwechseln. Prüfung, Textfassung und Umsetzung des einen Strangs beweisen daher nichts für den anderen.
  • Ein belastbarer öffentlicher Nachweis hätte über dem gemeinsamen Beschluss zwei getrennte Akten geführt: jeweils mit exakter Fassung, eigener Prüfhistorie, offenen Vorbehalten, verantwortlicher Umsetzung, betroffenen Formularen oder CPM-Abschnitten, Inkraftsetzungsdatum und späterer Verifikation. Der 29. Mai 2020 ist eine gemeinsame Veröffentlichungsgrenze, aber kein gemeinsamer Sachbeweis.
  • AFRINIC handelte dabei ausschließlich als privater technischer Registerführer und Koordinator. Der Beschluss verlieh weder Souveränität noch regulatorische, polizeiliche, staatsanwaltschaftliche, strafende, enteignende oder rechtsprechende Gewalt. Er konnte die Verwaltung privater technischer Dienstregeln freigeben, nicht Netzarchitekturen beherrschen oder öffentliches Recht schaffen.

L3 — Ein Beschluss, zwei technische Akten

Die praktische Asymmetrie hinter einer knappen Registerzeile

Die Kürze von Resolution 202002.552 täuscht über die Spannweite ihrer beiden Gegenstände hinweg. Auf der einen Seite stand ein Antragsteller, der eine weltweit eindeutige öffentliche ASN für seine Routing-Identität benötigte, aber nicht zwingend zwei physische Verbindungen zu zwei Upstreams unterhielt. Auf der anderen Seite stand ein Endnutzer von IPv6-PI-Raum, dessen Adressen in einem privaten Netz oder auf dem Peering-LAN eines Internet Exchange Point sinnvoll eingesetzt werden konnten, ohne im globalen Routing sichtbar zu sein. Beides sind Fragen der technischen Registerführung.

Doch sie verlangen andere Tatsachen, andere Unterlagen und andere Prüfungen.

Das Boardregister verzeichnet den Beschluss unter Februar 2020. Es nennt Multihoming Not Required for ASN Draft 4 und Adjusting IPv6 PI als gemeinsam ratifizierte Vorschläge. Mehr lässt sich aus der knappen öffentlichen Zeile nicht machen. Der genaue Tag der Beschlussfassung ist in der vorliegenden öffentlichen Beleglage ebenso wenig festgestellt wie eine Stimmenverteilung, individuelle Beweggründe oder der Inhalt etwaiger Boardunterlagen. Diese Lücken sind keine Anklage. Sie setzen lediglich die Grenze dessen, was der Registereintrag beweist: einen privaten körperschaftlichen Ratifikationsakt, in dem zwei Instrumente benannt wurden.

Gerade weil die Zeile nur einen Akt belegt, muss die technische Rekonstruktion zweigleisig bleiben. Eine gemeinsame Ratifikation bedeutet nicht, dass beide Vorschläge denselben Problemkern, dieselben Einwände, dieselbe Textgeschichte oder dieselben Arbeitsschritte hatten. Sie bedeutet auch nicht, dass einer ungeprüft geblieben wäre. Der sachgerechte Schluss ist enger: Wo das zentrale Register zwei Instrumente zusammenfasst, müssen die instrumentbezogenen Belege außerhalb dieser Zeile so klar bleiben, dass Leser jedes Instrument vom Ausgangsproblem bis zur laufenden Dienstregel verfolgen können.

Die entscheidende Unterscheidung lautet deshalb nicht „ein Beschluss oder zwei Beschlüsse“. Sie lautet „eine oder zwei nachprüfbare Akten“. Ein einziges Abstimmungs- oder Ratifikationsereignis kann effizient sein. Zwei technische Akten bleiben dennoch unverzichtbar, weil die Ursache eines Fehlers, die betroffene Nutzergruppe und die Art der Abhilfe nicht austauschbar sind. Wer diese Trennung aufgibt, kann später zwar noch sehen, dass etwas ratifiziert wurde, aber nicht mehr zuverlässig, was für wen und durch welche konkrete Änderung wirksam wurde.

Die ASN-Spur endet nicht bei Draft 1

Der erste Strang begann am 27. Februar 2019 mit der Einreichung von Version 1 von Multihoming Not Required for ASN; am 7. März wurde sie gesondert angekündigt. Ihr Anstoß war die Frage, ob physisches Multihoming als zwingender Stellvertreter für den Bedarf an einer öffentlichen autonomen Systemnummer taugt. Ein Netz kann einen legitimen Bedarf an einer global eindeutigen öffentlichen Routing-Identität haben, ohne bereits einen zweiten physischen Upstream erworben zu haben. Umgekehrt folgt aus dieser Feststellung nicht, dass jede lokale Nutzung eine öffentliche ASN braucht.

Private ASNs und eine sachbezogene Anspruchsprüfung verschwinden nicht.

Die Mitarbeiterbewertung vom 8. April 2019 gehört zu diesem ASN-Strang. Sie stellte einen Konflikt zwischen einer Route mit nur einer Verbindung und Abschnitt 5.1 von RFC 1930 fest, prüfte vier Fälle mit einem vorhandenen oder erst geplanten Peer, verlangte terminologische Änderungen, betrachtete den großen 32-Bit-Namensraum und listete Arbeit an Formularen, Prüflisten und Dokumentation auf. Außerdem verzeichnete sie keinen Kommentar eines Rechtsberaters. Damit liefert sie einen gehaltvollen Einblick in die frühe Prüfung des ASN-Vorschlags.

Sie ist aber weder eine Bewertung des IPv6-Vorschlags noch ein vollständiger Beweis für die spätere Endfassung.

Diese Einschränkung ist wichtig, weil zwischen der ersten Bewertung und der Ratifikation weitere Versionen lagen. Draft 2 folgte am 10. April, Draft 3 am 3. November und Draft 4 am 25. November 2019. Resolution 202002.552 ratifizierte Draft 4. Wer die Formulierungen von Draft 1 als Wortlaut der beschlossenen Regel ausgibt, überspringt drei dokumentierte Revisionsschritte. Wer die Bewertung vom 8. April als alleinige Abschlussprüfung behandelt, verwechselt einen belegten Abschnitt der Entstehungsgeschichte mit dem gesamten Weg bis zur beschlossenen Fassung.

Das bedeutet nicht, dass die frühe Bewertung unwichtig wäre. Sie zeigt vielmehr, welche Arten von Problemen in der ASN-Spur ausdrücklich erkannt wurden: die Beziehung zu einer etablierten technischen Empfehlung, die Behandlung verschiedener Verbindungssituationen, die Angemessenheit von Begriffen, die Verfügbarkeit des Nummernraums und die Anpassung operativer Unterlagen. Genau diese Punkte gehören in die Prüfakte des ASN-Instruments.

Zu derselben Akte gehören anschließend die Fassungsfolge bis Draft 4, die Identifikation dieser Fassung im Ratifikationsbeschluss und die Zuordnung der endgültigen Regel zu den veränderten ASN-Abschnitten und Antragsabläufen.

Der technische Sinn der Reform lässt sich daher nur begrenzt, aber klar beschreiben. Der Nachweis sollte sich darauf richten, ob die globale Koordination eine eindeutige öffentliche ASN erfordert, anstatt einen zweiten physischen Upstream als ausnahmslose Eintrittskarte zu verlangen. Daraus folgt weder eine Abschaffung aller Zulassungskriterien noch ein Recht auf eine öffentliche ASN für rein lokale Zwecke. Vor allem folgt daraus keine Befugnis von AFRINIC, Redundanz vorzuschreiben, Lieferanten auszuwählen oder eine Netzarchitektur moralisch zu bewerten.

Die Aufgabe des Registers bleibt, die Notwendigkeit einer eindeutigen Kennung anhand technischer Tatsachen zu prüfen und den Datensatz korrekt zu führen.

Die IPv6-Spur beginnt früher und fragt etwas anderes

Der zweite Strang hat eine eigene Vorgeschichte. Am 28. März 2018 wurde V6-004, das IPv6 PI Update, veröffentlicht. Es eröffnete einen Weg für Endnutzer, behielt aber eine Formulierung bei, die die fehlende Bekanntgabe des zugeteilten Raums nach zwölf Monaten mit einer Rücknahmefolge verbinden konnte. Bei AFRINIC-28 am 6. Juni 2018 wurden die Bedingung einer Bekanntgabe innerhalb von zwölf Monaten, die Beobachtung des Routings, eine HD-Ratio-Formulierung und der Übergang in die letzte Kommentierungsphase diskutiert. Resolution 201808.449 ratifizierte V6-004 am 8. August 2018 und wies die Mitarbeiter zur Umsetzung an. Am 29.

November 2018 meldete AFRINIC eine teilweise Umsetzung, während bestimmte Automatisierung noch ausstand.

Diese Abfolge belegt, dass die spätere Anpassung keine bloße sprachliche Fingerübung war. Eine schon behandelte und teilweise in den Dienst überführte Regel enthielt weiterhin eine Verknüpfung, die im Betrieb zu weit reichen konnte. Legitime IPv6-PI-Nutzung ist nicht in jedem Fall identisch mit einer sichtbaren Route im globalen Internet. Ein Peering-LAN an einem IXP oder ein privates Netz kann Adressraum produktiv verwenden, ohne ihn global anzukündigen. Aus dem Ausbleiben einer globalen Bekanntgabe allein lässt sich deshalb weder Nichtnutzung beweisen noch eine automatische Rücknahmefolgerung rechtfertigen.

Adjusting IPv6 PI griff genau diesen eigenständigen Defekt auf. Die lokal belegte inhaltliche Lebenszyklusseite ist Draft 2. Der ausgewählte Registerbezug bezeichnet das ratifizierte Instrument dagegen als Draft 1. Daraus folgt eine strikte Formulierungsdisziplin: Die sachliche Klarstellung und ihr späterer Lebenszyklus sind durch Draft 2 belegt, doch nicht jedes dort stehende Wort darf rückwirkend zur Formulierung des zuvor benannten Draft 1 erklärt werden. Am sichersten bleibt die Bezeichnung des ratifizierten Instruments als Adjusting IPv6 PI, solange nicht gerade die Fassung im Register beschrieben wird.

Auch die älteren IPv6-Unterlagen haben einen begrenzten Beweiswert. Die Diskussion von 2018 zeigt, dass Bekanntgabe und Routingbeobachtung schon im Vorgängerprozess als Fragen sichtbar waren. Die Resolution von August 2018 belegt die Ratifikation von V6-004. Die Umsetzungsmitteilung von November 2018 belegt die teilweise Umsetzung dieses Vorgängers. Keine dieser Unterlagen beweist, dass die Anpassung von 2019 bereits ratifiziert oder vorweg umgesetzt gewesen wäre. Sie erklären die Herkunft des Problems; sie schließen die spätere Korrektur nicht ab.

Damit stehen sich zwei deutlich unterschiedliche Kontrollflächen gegenüber. Bei der ASN-Regel geht es um die Fassung von Draft 4, die richtige Bestimmung einer öffentlichen Routing-Identität, die ASN-spezifische Bewertung sowie um Antragsformular, Prüfliste, Dokumentation und den betreffenden Manualabschnitt. Bei Adjusting IPv6 PI geht es um die genaue Fassung des eigenen Instruments, die aus der Vorgängerregel stammende Bekanntgabe- und Rücknahmefrage, die IPv6-spezifische Beratung, den korrigierten Satz im CPM und den Nachweis, dass diese Änderung im Dienst tatsächlich angewandt wurde. Der Beschlusskopf kann gemeinsam sein.

Diese Kontrollflächen können es nicht.

Warum die Trennung für Betreiber zählt

Für einen ASN-Antragsteller liegt das Risiko einer unscharfen Umsetzung darin, dass ein überholter Topologie-Stellvertreter praktisch fortlebt. Dann mag der öffentliche Text eine genauere Prüfung des Bedarfs an globaler Identität vorsehen, während Formular oder Prüfliste weiterhin nach einem zweiten physischen Upstream fragen. Die formale Änderung wäre sichtbar, die alte Kostenhürde bliebe aber in der Dienstpraxis bestehen. Alternativ könnte eine klare Voraussetzung durch offene Ermessensfragen ersetzt werden, die zu mehrfachen Nachforderungen und Verzögerung führen.

Beides betrifft die ASN-Bahn und muss dort nachgewiesen oder widerlegt werden.

Für einen IPv6-PI-Nutzer ist der Mechanismus ein anderer. Eine unklare oder unvollständig angepasste Manualformulierung kann eine legitime private oder exchangebezogene Nutzung weiterhin als verdächtige Nichtnutzung erscheinen lassen. Daraus entsteht Unsicherheit über Kontinuität, Adressplanung, Lieferantenentscheidungen und mögliche Neunummerierung, ohne dass für diese konkrete Episode eine tatsächliche Rücknahme oder ein gemessener Verlust belegt wäre. Hier muss der Nachweis zeigen, dass die beanstandete Verknüpfung im IPv6-Text korrigiert und von den zuständigen Mitarbeitern entsprechend verstanden wurde.

Diese Unterschiede machen Resolution 202002.552 institutionell interessant. Sie verbindet nicht zwei Varianten derselben Prüfung, sondern zwei Kostenmechanismen. Der ASN-Strang kann die Beschaffung eines zweiten Anschlusses als Eintrittshürde oder wiederholte Nachweislast berühren. Der IPv6-Strang kann aus einer Sichtbarkeitsannahme ein Kontinuitätsrisiko machen. In beiden Fällen trifft feste Dokumentationsarbeit kleinere und entferntere Betreiber tendenziell härter, weil sie weniger Personal, weniger Lieferantenauswahl und weniger zeitlichen Puffer haben.

Doch die wirtschaftliche Ähnlichkeit der Belastung ersetzt nicht die technische Unterscheidung ihrer Ursachen.

Der unmittelbare L3-Befund lautet deshalb: Der gemeinsame Akt ist real, aber sein Inhalt ist nur über zwei Akten verständlich. Die ASN-Unterlagen dürfen den IPv6-Weg nicht beglaubigen. Die IPv6-Unterlagen dürfen nicht beweisen sollen, dass Draft 4 der ASN-Regel angemessen geprüft oder in Formulare übertragen wurde. Wer beide Stränge nebeneinander liest, kann Effizienz anerkennen und zugleich die Beweislast richtig verteilen. Wer sie vermischt, gewinnt keine zusätzliche Gewissheit, sondern erzeugt einen blinden Fleck in beiden Diensten.