Zusammenfassung

  • Das geltende AFRINIC-Handbuch trennt Peering- und Managementadressen, sieht einen eigenen IXP-Peering-Pool vor und beschreibt ein angrenzendes /24, das Wachstum bis /23 ermöglichen soll. Auf der AFRINIC-37 berichteten Mitarbeitende zugleich, dass Mitglieder Präfixe zwischen den Nutzungsarten tauschten und damit gegen die Policy verstießen.
  • Andrew Owens von NAPafrica schilderte die Lage in Johannesburg: zwei /23-Blöcke, eine fast ausgeschöpfte /22 und einen möglichen Bedarf von zwei weiteren /23, um auf /21 zu kommen. Eine vor acht Jahren begonnene Umnummerierung sei noch nicht abgeschlossen. Das ist der Bericht eines Betreibers, keine Erhebung zur afrikanischen IXP-Nachfrage und keine typische Migrationsdauer.
  • Bevor die Reserve von /16 auf /15 vergrößert wird, braucht die Community Verbrauchs- und Betroffenenzahlen sowie einen Plan für zusammenhängendes Wachstum und den Übergang. Ein größerer Pool kann Knappheit mindern; er garantiert für sich genommen nicht, dass der nächste Block dort liegt, wo ein Exchange ihn braucht.

Analyse

„Wie groß?“ ist nur eine der Reservefragen

Die aktuelle Seite des Consolidated Policy Manual führt Version 1.6 als gültig und nennt den 17. November 2020 als Veröffentlichungsdatum. Abschnitt 11 legt nicht nur eine Gesamtmenge fest. Er unterscheidet das Peering-LAN – den zusammenhängenden Adressblock, über den Teilnehmer am gemeinsamen Exchange Verkehr austauschen – vom Managementnetz für Überwachung, Statistiken, E-Mail und weitere Dienste. Managementadressen sollen nicht aus dem Peering-Block stammen. Vorgesehen sind ein eigener, veröffentlichter Peering-Pool und ein angrenzendes /24, damit ein IXP bis /23 wachsen kann, ohne einen neuen Block zu erhalten und umnummerieren zu müssen. Der Abschnitt schlägt ein /16 für Peering und ein gleich großes, getrenntes /16 für Management vor. Das Handbuch

Auf der Sitzung fragte ein Teilnehmer, ob das /16 für die gesamte Region ausreiche oder ein /15 angemessener wäre. Ein /15 umfasst doppelt so viele Adressen wie ein /16. Daraus folgt jedoch weder, wie viele zusammenhängende Zuteilungen noch möglich sind, noch wie schnell der Pool schrumpft oder welche Antragsteller betroffen wären. AFRINIC-Mitarbeitende kündigten Verbrauchsstatistiken an, damit die Community fundierter beraten kann. Ein anderer Teilnehmer bat ausdrücklich um die Zahl der betroffenen Mitglieder, bevor die Dringlichkeit bewertet wird. Das Protokoll der AFRINIC-37

Diese Bitte ist kein Verfahrensdetail. Eine Reserve ist zugleich eine Bestands- und eine Zuteilungsregel. Ihre Größe bestimmt, wie viel Raum zurückgehalten wird. Zuteilungseinheit und Nachbarschaftsregel bestimmen, ob ein Betreiber sein Netz erweitern kann. Eine dritte Frage ist, ob die Unterlagen zeigen, wer den Pool zu welchem Zweck genutzt hat und welcher Spielraum bleibt. Wer nur die erste beantwortet, kann den Bestand vergrößern und trotzdem die nächste Wachstumsstufe offenlassen.

Ein Verstoß ist noch keine Ursachenanalyse

Das Protokoll gibt die Aussage der Mitarbeitenden wieder, Mitglieder tauschten Peering- und Managementpräfixe entgegen der Policy; die Mitarbeitenden arbeiteten mit ihnen daran, die Nutzung anzupassen. Das benennt ein Umsetzungsproblem. Es zeigt nicht, warum der Tausch stattfand, wie viele Mitglieder beteiligt waren oder ob vor allem Regeltext, Registrierungsdaten, Verwaltungsabläufe oder Betriebspraxis die Ursache waren. Das ist wichtig: Wird die Policy geändert, bevor der Fehlermechanismus verstanden ist, kann der Text wandern, während die Praxis bleibt.

Abschnitt 5.6.4 und Abschnitt 11 des Handbuchs hängen zusammen, regeln aber nicht denselben Vorgang. Der erste beschreibt IPv4-Zuweisungen an kritische Infrastruktur, im Regelfall höchstens /24, erlaubt jedoch unter bestimmten Umständen mehrere Zuweisungen. Abschnitt 11 betrifft reservierte IXP-Peering- und Management-Pools; das angrenzende /24 soll einen Schritt auf /23 ohne Umnummerierung erlauben. Das Handbuch definiert einen IXP außerdem als physische Layer-2-Infrastruktur mit einem Betreiber, mindestens drei angeschlossenen Internetdienstanbietern und einer offenen Beitrittspolitik. AFRINICs öffentliche Antragskriterien verlangen Nachweise für eine rechtliche Präsenz in Afrika, ASNs und Kontakte von mindestens drei BGP-Peers oder unterzeichnete Vereinbarungen, Öffentlichkeit und Offenheit sowie eine Betriebslizenz, sofern das jeweilige Land sie verlangt. Die AFRINIC-Kriterien

Diese Kriterien klären die Förderfähigkeit eines Antrags, aber nicht die künftige Nachfrage. Sie zeigen auch nicht, ob verfügbare Blöcke zum Wachstumsweg eines konkreten Exchanges passen. Und der Hinweis auf zweckwidrig genutzte Präfixe sagt nichts darüber aus, ob Mitarbeitenden die Daten und Werkzeuge vorliegen, um den Wechsel zu erkennen, bevor er zur betrieblichen Abhängigkeit wird.

Johannesburg zeigt die Geometrie, nicht den Kontinentalbedarf

Owens sagte, NAPafrica verfüge in Johannesburg über zwei /23, nutze ein /22 nahezu vollständig aus und benötige bei weiterem Bedarf zwei zusätzliche /23, um ein /21 zu erreichen. Er erklärte auch, die Umnummerierung des Johannesburg-Standorts habe vor acht Jahren begonnen und sei noch nicht fertig. Das Protokoll dokumentiert einen konkreten Betreiberbericht. Es liefert weder einen Nenner noch vergleichbare Daten anderer Exchanges, eine unabhängige Kostenschätzung oder einen Zeitplan, der die lange Dauer erklärt.

Der Fall ist trotzdem aufschlussreich, weil eine reine Adresssumme das Layout verdeckt. Vier /23 ergeben nur dann ein /21, wenn sie an der relevanten Grenze zusammenhängend ausgerichtet sind. Ein IXP, der über getrennte Zuteilungen gewachsen ist, braucht daher mehr als eine Zahl von Adressen: eine brauchbare Folge angrenzender Blöcke, einen Weg, den Betrieb während des Wechsels aufrechtzuerhalten, und Zeit für die Abstimmung mit den Teilnehmern. Das angrenzende /24 im Handbuch zielt ausdrücklich auf den ersten Schritt bis /23. Owens’ Beispiel wirft die Anschlussfrage auf: Wie geht ein Exchange, der diesen Schritt geschafft hat, danach weiter?

Es beweist kein Scheitern der Policy, macht aber deutlich, dass die nächste Stufe nicht einfach vorausgesetzt werden sollte.

In derselben Sitzung wurde RFC 8950 als mögliche Option für einen Dual-Stack-Betrieb genannt. Der IETF-Standard erlaubt IPv4-Routen mit einem IPv6-Next-Hop, sofern BGP-Peers die entsprechende Fähigkeit aushandeln. Das ist eine technische Möglichkeit, aber kein Nachweis, dass sämtliche Route Server und Teilnehmer sie bereits unterstützen oder dass ein reserviertes IPv4-Peering-LAN entbehrlich wäre. RFC 8950

Erst die Belege veröffentlichen, dann die größere Zahl wählen

Das Protokoll zeigt zwei verschiedene Fragen: Wie viel Raum braucht die regionale Reserve, und wie kann ein einzelner Exchange ohne wiederholtes Umnummerieren wachsen? Die Mitarbeitenden nahmen die Bitte um Verbrauchs- und Betroffenenzahlen auf und sagten zu, relevante Statistiken künftig auf der Mailingliste zu teilen. Aus den öffentlichen Unterlagen, die für diesen Artikel geprüft wurden, ließ sich nicht feststellen, ob oder wann dies geschah. Das ist eine Grenze dieser Recherche und kein Beweis, dass Zahlen nie veröffentlicht wurden.

Ein nächster Bericht sollte die Fragen gemeinsam, aber getrennt beantworten: für Peering- und Management-Pools jeweils Anfangsbestand, Zuteilungen, Rückgaben und Restbestand; die Zahl eingeschränkter Anträge; die vergebenen Blockgrößen und deren Zusammenhang. Er sollte genehmigte Zuteilungen von Prognosen unterscheiden und erklären, ob „Nutzung“ bereits zugeteilt, in Betrieb, im Routing angekündigt oder lediglich gehalten bedeutet. Eine datierte Tabelle mit Methode sagt mehr aus als ein einzelner Nutzungsprozentsatz.

Dazu gehört ein Übergangsplan: Welche Wachstumsschritte erlaubt die Policy? Wie wird Nachbarschaft gesichert? Was gilt, wenn ein zusammenhängender Block nicht verfügbar ist? Wer koordiniert eine Umnummerierung? Welche Schutzvorkehrungen oder Ausnahmen gibt es? Es geht nicht darum, einen Nachbarblock für jeden Antrag zu garantieren. Der Zielkonflikt zwischen Bestandsschutz und vermeidbarer Migration muss sichtbar werden, bevor ein Einzelfall Mitarbeiter und Betreiber vor vollendete Tatsachen stellt.

Zeigen die Zahlen, dass sich das /16 für weitere /23-Zuteilungen erschöpft, kann ein größerer Pool gerechtfertigt sein. Konzentriert sich die Nachfrage auf wenige Exchanges mit größeren zusammenhängenden Wachstumsschritten, könnten dieselben Daten für eine andere Reservegeometrie oder einen gestuften Übergang sprechen. Sind zweckübergreifende Präfixtausche das Hauptproblem, bringen bessere Register und Unterstützung bei der Einhaltung womöglich mehr als eine Verdoppelung des Bestands. Aus dem Protokoll allein folgt keine dieser Antworten.

Die verantwortliche Reihenfolge ist einfach: veröffentlichen, was im Pool bleibt, welche Anträge er nicht erfüllen kann und welche Wachstums- und Migrationswege die Policy eröffnet. Dann kann die Community zwischen mehr IPv4, einer anders geschnittenen Reserve, besseren Unterlagen oder einer Kombination wählen. Der NAPafrica-Bericht macht die möglichen Folgen einer falschen Reihenfolge greifbar. Wie oft sie auftreten, lässt sich nur mit breiteren, veröffentlichten Daten beurteilen.

Quellen