Zusammenfassung

  • Draft 1 wurde am 27. Februar 2019 eingereicht, am 7. März von AFRINIC angekündigt und blieb „Under Discussion“. Es war weder eine angenommene noch eine wirksame Regel. Die archivierte Seite zeigt zudem die Kennung AFPUB-2019-ASN-DRAFT01, während die spätere Mitarbeiterbewertung AFPUB-2019-ASN-001-draft-01 nennt; für die Einordnung wird die normalisierte Kette AFPUB-2019-ASN-001-DRAFT01 verwendet, ohne die Abweichung zu verschweigen.
  • Der Vorschlag ersetzte die bisherige kumulative Logik durch zwei alternative Wege: Ein Mitglied in gutem Stand sollte entweder multihomed sein oder einen Bedarf an der Verbindung mit einem anderen AS haben; auch ein zeitnaher Plan zur Erfüllung eines der beiden Kriterien sollte genügen. Hinweise auf private ASNs und auf RFC 1930 oder Nachfolger blieben bestehen.
  • Die praktische Stärke des Entwurfs lag darin, eine weltweit eindeutige Routing-Identität von einer vorgeschriebenen redundanten Anschlusstopologie zu trennen. Seine Schwäche lag im unbestimmten Wort „Bedarf“. Die Debatte im März und die Mitarbeiterbewertung vom 8. April machten sichtbar, dass ein einzelner Upstream manchmal mit statischer Route auskommt, während providerunabhängiger Adressraum, ein IXP, private Interconnection oder ein späterer Providerwechsel dennoch einen öffentlichen ASN sinnvoll machen können.
  • Eine begrenzte technische Prüfschwelle ist legitim: AFRINIC darf als private Registerstelle Duplikate vermeiden, Identität und Bedarf prüfen und unnötige lokale Nutzung auf private ASNs verweisen. Es darf aber weder den Kauf eines zweiten Upstreams erzwingen noch aus einem alten Engineering-Proxy eine Befugnis zur Gestaltung fremder Netze ableiten.
  • Erst spätere Fassungen veränderten den Vorschlag weiter. Draft 4 wurde im Februar 2020 durch Resolution 202002.552 gemeinsam mit einem anderen IPv6-Vorschlag ratifiziert und laut Lebenszyklusaufzeichnung am 29. Mai 2020 in CPM 1.5 umgesetzt. Diese späteren Akte dürfen Draft 1 nicht rückwirkend zu einer angenommenen Regel machen.

Wenn der zweite Anschluss zur falschen Eintrittskarte wird

Stellen wir uns einen Betreiber außerhalb eines großen Ballungsraums vor. Er verfügt über einen brauchbaren Transitanschluss, vielleicht sogar über providerunabhängigen Adressraum oder eine konkrete Möglichkeit zum Peering an einem Internet Exchange. Ein zweiter physischer Upstream wäre teuer, geographisch kaum zu beschaffen oder für den aktuellen Betrieb schlicht ohne zusätzlichen Nutzen.

Gleichwohl kann der Betreiber eine öffentliche, weltweit eindeutige Autonomous System Number benötigen: um seine eigene Routing-Identität gegenüber einem IXP zu führen, um eine private Interconnection mit einem anderen autonomen System aufzubauen, um Adressen stabil anzukündigen oder um die spätere Wahl eines anderen Providers nicht von einer vollständigen Umnummerierung abhängig zu machen.

Die alte Zugangshürde stellte ihm eine andere Frage. Sie fragte nicht zuerst, ob für diese konkrete Kommunikationsbeziehung ein global eindeutig koordinierter ASN gebraucht wurde. Sie behandelte eine bestimmte sichtbare Netzform – physisches Multihoming – als Stellvertreter für diesen Bedarf. Wer nur einen Transitpartner hatte, konnte dadurch gezwungen sein, die Kosten eines zweiten Anschlusses zu übernehmen, bevor die Registerstelle überhaupt den eigentlichen technischen Grund für eine eindeutige Routing-Identität würdigte. Das war kein abstrakter Schönheitsfehler.

Transit, Zugang, Ausrüstung, Konfiguration und laufender Betrieb verursachen Kosten. In manchen Regionen ist ein zweiter Anbieter gar nicht erreichbar. Eine Regel, die dasselbe physische Merkmal bei einem großen urbanen Carrier und bei einem kleinen abgelegenen Netz verlangt, verteilt ihre Last daher höchst ungleich.

Draft 1 setzte genau an diesem Punkt an. Die archivierte AFRINIC-Seite datiert Version 1.0 auf den 27. Februar 2019, nennt Jordi Palet Martinez als Autor und führt den Status „Under Discussion“. Erst am 7. März teilte AFRINIC auf der RPD-Liste mit, der Vorschlag sei eingegangen, solle Multihoming als Voraussetzung einer ASN-Zuteilung entfernen und stehe zur Diskussion. Einreichung und öffentliche Ankündigung sind somit zwei verschiedene dokumentierte Akte. Weder die Ankündigung noch die anschließende Diskussion machte den Text verbindlich.

Auch die Kennung verlangt Genauigkeit. Auf der archivierten Entwurfsseite steht AFPUB-2019-ASN-DRAFT01, also ohne die Ziffernfolge „001“. Die am 8. April veröffentlichte Mitarbeiterbewertung schreibt hingegen AFPUB-2019-ASN-001-draft-01; die spätere Fassungsfolge verwendet ebenfalls die normalisierte Grundform mit „001“. Es gibt in den vorliegenden Unterlagen keine Erklärung für diesen Unterschied. Ihn stillschweigend zu bereinigen hieße, dem Dokumentenbestand eine Einheitlichkeit zuzuschreiben, die er nicht hat. Für die gemeinsame Identifikation des Vorhabens ist AFPUB-2019-ASN-001-DRAFT01 sinnvoll, doch die abweichende Anzeige der ersten Seite bleibt Teil der Überlieferung.

Was sich im ersten Redline tatsächlich änderte

Die alte Klausel war kumulativ aufgebaut. Ein Antragsteller musste sämtliche vier aufgeführten Bedingungen erfüllen; zu den prägenden Elementen gehörten eine eigenständige Routing-Policy und eine multihomed Site beziehungsweise ein kurzfristiger Plan, die verlangten Kriterien zu erfüllen. Hinzu kam die Stellung als AFRINIC-Mitglied in gutem Stand. Diese AND-Logik bündelte unterschiedliche Fragen: Ist die Organisation im Registerverhältnis ordnungsgemäß erfasst? Betreibt sie eine eigene Routing-Policy? Wie viele externe Anschlüsse hat sie? Und benötigt ihre technische Kommunikation einen global eindeutigen Namen?

Draft 1 schlug eine deutlich andere logische Struktur vor. Ein Mitglied in gutem Stand sollte die technische Voraussetzung erfüllen, wenn es entweder multihomed war oder mit einem anderen autonomen System interconnecten musste. Ein zeitnaher Plan, eines dieser alternativen Kriterien zu erfüllen, sollte ebenfalls ausreichen. Das ist keine Abschaffung jeder Prüfung. Es ist auch keine Behauptung, jedes single-homed Netz müsse eine öffentliche Nummer erhalten. Die Änderung löste lediglich die notwendige Eindeutigkeit von der zwingenden Existenz eines zweiten physischen Upstreams.

Multihoming blieb ein möglicher Nachweis, verlor aber seine Monopolstellung als Nachweis.

Zwei Begrenzungen blieben im Text stehen. Erstens verwies der Entwurf Netze, die keine eindeutige ASN brauchten, weiterhin auf private Nummern. Die erste Fassung druckte dabei die ältere private Spanne; die heute als technischer Kontext relevante Dokumentation privater Bereiche findet sich in RFC 6996. Diese spätere technische Referenz darf nicht so dargestellt werden, als habe Draft 1 bereits ihren Wortlaut übernommen. Zweitens behielt der Entwurf die Prüfung nach RFC 1930 oder dessen Nachfolgern bei.

Der Text entfernte also weder die technische Beurteilung noch die Möglichkeit, einen Antrag abzulehnen, wenn nur eine lokale Kennung erforderlich war.

Draft 1 wollte außerdem einen vorhandenen einleitenden Unterabschnitt löschen und Abschnitt 7 zusammenführen beziehungsweise neu nummerieren. Diese redaktionellen Eingriffe gehörten zum Vorschlag, waren aber nicht sein entscheidender institutioneller Mechanismus. Der Mechanismus lag in einem einzigen Wechsel der Logik: von mehreren gemeinsam zwingenden Eigenschaften zu alternativen Wegen, die einen Bedarf an öffentlicher Routing-Identität anzeigen konnten.

Dass dieser Wechsel praktisch bedeutsam war, zeigt sich an der Funktion eines ASN. Ein ASN unterscheidet ein administratives Routing-Domain im globalen Austausch. Es ist kein Gütesiegel für Redundanz und keine Bescheinigung, dass ein Betreiber ein bestimmtes Geschäftsmodell gewählt hat. Physisches Multihoming kann starkes Indiz für eine eigenständige öffentliche Routing-Policy sein. Es ist aber weder mit dieser Policy identisch noch der einzige Umstand, in dem ein eindeutiger ASN für Kommunikation zwischen autonomen Systemen benötigt wird.

Die Gegenfrage der statischen Route

Die RPD-Debatte im März zeigte, warum die Reform nicht mit dem einfachen Satz „single-homed braucht ASN“ begründet werden konnte. Jaco Kroon brachte den stärksten naheliegenden Einwand vor: Ein Standort mit nur einem Upstream könne über eine statische Route versorgt werden. Wenn der Provider die Route kontrolliere und kein eigenständiger externer Routing-Austausch erforderlich sei, gebe es möglicherweise keinen technischen Grund für eine öffentliche ASN. Dieser Einwand schützt nicht AFRINICs Macht, sondern die Genauigkeit des Registers.

Öffentliche Identifikatoren sollten nicht vergeben werden, wenn private Nummern oder eine statische Konfiguration denselben Zweck erfüllen.

Fernando Frediani antwortete nicht mit einer pauschalen Gegenbehauptung. Er nannte Konstellationen, in denen ein einziger Transit-Upstream nicht die ganze Routing-Wirklichkeit beschreibt: stabiler providerunabhängiger Adressraum, die spätere Wahl eines weiteren Providers, die Teilnahme an einem IXP oder eine private Interconnection. Ein Netz kann also hinsichtlich des Transitbezugs single-homed sein und zugleich eine andere Beziehung unterhalten, für die eine eindeutige öffentliche Routing-Identität erforderlich ist.

Ebenso kann die Stabilität einer eigenen Ankündigung verhindern, dass der Wechsel eines Lieferanten den Betreiber in dessen Nummerierungsraum einschließt.

Beide Positionen treffen einen Teil der Wahrheit. Kroon erinnert daran, dass ein ASN kein Selbstzweck ist. Frediani zeigt, dass die Zahl physischer Transitlieferanten den Bedarf nicht vollständig beschreibt. Der entscheidende Prüfgegenstand ist daher nicht „eins oder zwei Anschlüsse“, sondern „lokale Kennung oder global koordinierte Identität“. Genau dort lag die überzeugende Intuition von Draft 1. Doch die Formulierung „need to interconnect“ sagte noch nicht präzise, welche Interconnection zählt, welches Protokoll oder welche administrative Trennung einen öffentlichen ASN verlangt und welche Belege ein Antragsteller vorlegen sollte.

Am 30. März schlug Owen DeLong deshalb eine einfachere Formulierung rund um eine eigenständige Routing-Policy oder eine Interconnection mittels eines Exterior-Gateway-Protokolls vor, das eine eindeutige ASN verlangt. Sander Steffann unterstützte diese Richtung. Diese Beiträge gehören zur zeitgenössischen Diskussion und erklären den Klärungsbedarf. Sie dürfen aber nicht in den veröffentlichten Wortlaut von Draft 1 hineingelesen werden. Ein Diskussionsvorschlag ist nicht identisch mit dem Redline, und Zustimmung zu einer Richtung ist kein Nachweis eines formellen Konsenses.

Der Vergleich mit APNICs prop-128 lieferte einen weiteren zeitgenössischen Bezugspunkt. Draft 1 verwies auf diesen Vorstoß zur Entfernung des verpflichtenden Multihoming im APNIC-Kontext. Der Vergleich zeigt, dass das Problem nicht nur als individuelle afrikanische Ausnahme wahrgenommen wurde. Er beweist jedoch weder, dass AFRINIC denselben Text übernehmen musste, noch dass ein anderer RIR-Prozess eine Entscheidung für AFRINIC getroffen hätte. Vergleichende Praxis kann eine technische Heuristik infrage stellen; sie kann die interne Prüfung einer privaten Registerstelle nicht ersetzen.

Wer die Kosten eines Proxys trägt

Ein Proxy wirkt neutral, solange nur sein Ja-Nein-Ergebnis betrachtet wird. Seine ökonomische Wirkung wird erst sichtbar, wenn man fragt, was ein Antragsteller tun muss, um „Ja“ sagen zu können. Bei verpflichtendem Multihoming kann dies einen zusätzlichen Transitvertrag, eine neue Zugangsstrecke, weitere Routerkapazität, Konfigurationsarbeit, Monitoring und laufende Betriebsbereitschaft bedeuten. Die vorhandenen Quellen beziffern diese Kosten nicht, und sie nennen keinen konkreten Antragsteller, der wegen der alten Regel abgewiesen oder abgeschreckt wurde.

Es wäre daher unzulässig, eine bestimmte Schadenssumme oder Zahl betroffener Netze zu behaupten.

Die Richtung des Mechanismus lässt sich dennoch zuverlässig beschreiben. Ein fixer Nachweisaufwand belastet kleine Betreiber stärker, weil er sich auf weniger Kunden, geringere Umsätze und eine dünnere technische Mannschaft verteilt. In entlegenen Regionen kann die relevante Alternative nicht „zweiter günstiger Anbieter“ heißen, sondern „teure Sonderverbindung oder gar kein zweiter Anschluss“. Heng Lus Analyse der „Poverty Penalty“ schärft genau diesen Blick: Gleich aussehende Compliance- und Verzögerungskosten sind wirtschaftlich nicht gleich, wenn die Ausgangslage der Antragsteller höchst verschieden ist.

Der Punkt ist keine Vermutung über einen bestimmten Fall, sondern eine institutionelle Lastenprüfung.

Gleichzeitig hat die Ausgabe unnötiger öffentlicher ASNs eigene Kosten. Das Register muss korrekte Datensätze führen, Zuordnungen nachvollziehbar halten und die Verwendung öffentlicher gegenüber privater Kennungen sauber trennen. Auch das Routing gewinnt nicht dadurch, dass jede lokale Beziehung eine globale Nummer erhält. RFC 6996 erläutert reservierte private ASN-Bereiche gerade für Kontexte, in denen Eindeutigkeit nur innerhalb eines begrenzten administrativen Umfelds benötigt wird.

Ein reformierter Test muss deshalb zwei Fehler vermeiden: Er darf weder eine nicht benötigte Topologie erzwingen noch einen globalen Identifier verteilen, wenn eine private Kennung genügt.

RFC 6793 dokumentiert die Erweiterung auf vier Oktette und damit den erheblich größeren 32-Bit-Nummernraum. Das ist wichtiger technischer Hintergrund für die spätere Einschätzung, dass ein höherer Verbrauch auf absehbare Zeit kein Erschöpfungsproblem verursachen würde. Draft 1 selbst zitierte RFC 6793 jedoch nicht und enthielt auch keine spätere, konkretisierte Langfristberechnung. Die größere Nummernmenge kann den Knappheitseinwand abschwächen; sie ersetzt nicht den Nachweis, dass ein öffentlicher ASN im einzelnen Fall gebraucht wird.

LARUS ordnet aus Betreiberperspektive ein, warum eine Registerentscheidung weit über ein Formular hinausreichen kann. Verzögerungen, wechselnde Auslegung und Zuteilungskriterien wirken auf Lieferantenwahl, Kontinuität und Infrastrukturplanung. Diese Einsicht macht aus jeder Ablehnung noch keinen bewiesenen Schaden. Sie erklärt aber, warum die Qualität eines Prüfverfahrens für den Betrieb zählt: Ein Antragsteller muss planen können, welche Unterlagen benötigt werden, welche technische Eigenschaft bewertet wird und wie eine ablehnende Begründung überprüft werden kann.

Der Ausgangspunkt bleibt deshalb praktisch. Wer eine eindeutige Routing-Identität für eine reale Außenbeziehung braucht, sollte nicht einen unnötigen zweiten Transit kaufen müssen, nur um die Form eines überlieferten Tests zu erfüllen. Wer dagegen ausschließlich innerhalb eines Provider- oder Unternehmenskontexts routet und mit statischer Route oder privater ASN auskommt, hat keinen automatischen Anspruch auf eine öffentliche Nummer. Draft 1 öffnete den Raum zwischen diesen beiden Fällen. Seine weitere Prüfung musste ihn erst vermessen.