AFRINIC und die Ökonomie der Sichtbarkeit von Sub-Allokationen

Das Missbrauchs-Ticket schien gewöhnlich, bis alle versuchten, die verantwortliche Partei zu benennen. Ein regionaler ISP hatte Beschwerden über Credential-Stuffing-Verkehr aus einem kleinen /27 erhalten, das von einem seiner Geschäftskunden genutzt wurde. Der registrierte Inhaber des übergeordneten IPv4-Blocks war im AFRINIC-Register sichtbar. Der Ursprungs-AS war in BGP sichtbar. Ein Wiederverkäufer befand sich irgendwo in der kommerziellen Kette. Ein Anbieter einer verwalteten Firewall betrieb das Edge-Gerät.

Der Kunde, dessen Server den Verkehr erzeugten, wünschte Vertraulichkeit, teils weil die Maschinen kompromittiert sein könnten, teils weil er nicht wollte, dass seine Hosting-Vereinbarungen seinen Wettbewerbern bekannt werden. Der Upstream-Betreiber wollte Rechenschaftspflicht. Die Bank, die die Beschwerde eingereicht hatte, wollte jemanden, der den Angriff stoppen konnte. Das öffentliche Register nannte den Inhaber, nicht den kleinen operativen Nutzer.

Diese Lücke ist der Gegenstand der Sichtbarkeit von Sub-Allokationen. Das Wort „Sub-Allokation“ hat in der AFRINIC-Politik eine formale Bedeutung: Ein LIR kann Adressraum an nachgelagerte ISPs zur weiteren Verteilung weitergeben, vorbehaltlich Größen-, Dokumentations- und Registrierungsregeln. Das wirtschaftliche Problem geht über die formale Bezeichnung hinaus. IPv4-Adressen, die knapp geworden sind, werden nun von Inhabern, LIRs, nachgelagerten ISPs, Wiederverkäufern, Hosting-Providern, Managed-Service-Providern, Cloud-Plattformen, Brokern, Leasingvereinbarungen, Geschäftskunden und manchmal noch weiter delegierten Nutzern verwendet.

Ein Teil dieser Nutzung ist legitim und gewöhnlich. Ein Teil ist aus Datenschutzgründen sensibel. Ein Teil ist kommerziell vertraulich. Ein Teil verursacht Missbrauch, Betrug, Sanktionsfilterung, Anfragen von Strafverfolgungsbehörden, Geolokalisierungsfehler, Routing-Fehler und Reputationsschäden.

Das öffentliche Register sieht oft nur die erste Schicht. Das Internet funktioniert über viele weitere Schichten. Ein Präfix kann von einer Partei registriert, von einer anderen angekündigt, an eine dritte für Reverse-DNS delegiert, in einem von dem Kontakt eines Brokers gepflegten IRR-Objekt gelistet, durch eine vom offiziellen Inhaber erstellte ROA abgedeckt und von Kunden genutzt werden, deren Namen niemals in RDAP oder WHOIS erscheinen. Nichts davon ist automatisch verdächtig. Die Arbeitsteilung ist im Netzwerkbetrieb normal.

Das Problem beginnt, wenn jeder externe Akteur die Kosten der Ermittlung des verantwortlichen Betreibers tragen muss, nachdem bereits etwas schiefgegangen ist.

AFRINIC ist eine nützliche Fallstudie, da die nachgelagerte Schicht bereits in die Betriebsregeln eingebettet ist, die Netzwerke einhalten müssen, während seine jüngere institutionelle Geschichte zeigt, warum die Sichtbarkeit unterhalb des Inhabers wichtig ist. Das African Network Information Centre (AFRINIC) dient Afrika und einem Teil des Indischen Ozeans als regionales Internet-Register. Es betreibt Dienste, die die Ressourcennutzung in öffentliche Nachweise umwandeln: WHOIS, RDAP, Reverse-DNS, ein Internet Routing Registry und RPKI.

Die einschlägigen Betriebsregeln verlangen, dass Zuteilungen, Zuweisungen und Sub-Allokationen in der AFRINIC-Datenbank registriert werden, und schreiben vor, dass Registrierungsdaten wie Namen, Blöcke, Kontakte und Status korrekt bleiben müssen. Sie binden auch die Reverse-Delegation an registrierte Zuweisungen oder Sub-Allokationen. Diese Regeln sind nicht dekorativ. Sie sind die genauen Punkte, an denen die nachgelagerte Betriebsrealität lesbar werden soll.

Der Druck auf diese Punkte ist gestiegen. AFRINIC trat am 13. Januar 2020 in Phase 2 des IPv4 Soft Landing ein, wobei neue gewöhnliche IPv4-Allokationen und -Zuweisungen auf kleine Blöcke beschränkt wurden, mit einem Minimum von /24 und einem Maximum von /22.

Öffentliche Berichte haben über Vorwürfe der Manipulation von Adressregistrierungen unter Beteiligung von ruhendem afrikanischem IPv4-Adressraum berichtet, über hochkarätige Rechtsstreitigkeiten zwischen AFRINIC und Cloud Innovation bezüglich Ressourcennutzung und -kommerzialisierung, über das gerichtliche Einfrieren von AFRINIC-Mitteln im Jahr 2021, über die Insolvenzverwaltung ab 2023, über Diskontinuitäten im Vorstand und bei Wahlen, über einen annullierten Wahlversuch im Jahr 2025, über die spätere Wiederherstellung des Vorstands und über anhaltende Fragen zur Wiederaufnahme im Jahr 2026.

Diese Ereignisse sollten nicht in eine allgemeine Governance-Fabel umgedeutet werden. Für die Sichtbarkeit von Sub-Allokationen ist ihre Bedeutung enger: Wenn das Register selbst unter Druck steht, verlassen sich die Märkte noch stärker auf klare Belege dafür, wer die knappen Adressen nutzt, wer kontaktiert werden kann und welche Unsicherheit real und nicht nur ein Gerücht ist.

Der unsichtbare Kunde ist nun ein kostspieliger Fakt

In Zeiten des Überflusses war ein verborgener nachgelagerter Kunde oft eher eine Unannehmlichkeit als ein Kostenproblem. Ging der Missbrauch vom Subnetz eines Kunden aus, konnte der Anbieter ihn in seinen eigenen Systemen zurückverfolgen. War ein Kontakt veraltet, konnte eine andere Zuteilung verfügbar sein. War ein kleiner Bereich falsch konfiguriert, war die Umnummerierung mühsam, aber kein kritisches Ereignis. Die IPv4-Adressknappheit hat diese Rechnung verändert.

Ein kleiner Block kann Hosting-Einnahmen, Zahlungsinfrastruktur, Regierungsportale, SaaS-Kunden, VPN-Zugang, Betrugsbekämpfungssysteme, die Reputation von E-Mail-Diensten und die Netzwerkkontinuität stützen. Der Kunde hinter der Adresse ist nicht mehr nur ein Betriebsdetail. Er ist eine Quelle von Risiko, Wert und Verantwortung.

Intransparenz hat einen messbaren wirtschaftlichen Pfad. Sie erhöht die Kosten der Suche, da ein Beschwerdeführer, ein Upstream, ein Käufer, eine Bank, ein Versicherer oder ein Ermittler Zeit darauf verwenden muss, herauszufinden, ob der angegebene Inhaber, der Ursprungs-AS, der Wiederverkäufer, der Managed-Service-Provider oder der Endkunde das Problem lösen kann. Sie erhöht die Kosten von Fehlern, denn wenn das verantwortliche /27 nicht schnell identifiziert werden kann, blockieren Gegenparteien ein /24, ein /22 oder die gesamte Reputation des Inhabers.

Sie erhöht die Vertragskosten, da Kunden und Gegenparteien Garantien, Entschädigungen, Treuhandkonten, Notfallkontakte, Servicegutschriften und zusätzliche Due Diligence verlangen, wenn das öffentliche Register ihnen nicht genug sagt. Sie erhöht die Kapitalkosten, da ein Kreditgeber oder Käufer Einnahmen aus Adressen abschreibt, deren operationelle Verantwortung nicht unabhängig rekonstruiert werden kann.

Der unsichtbare Kunde verändert auch die Anreize innerhalb der Kette. Ein Inhaber, der Einnahmen erzielen kann, während er den nachgelagerten Nutzer nicht registriert, kann zu wenig in Missbrauchsbekämpfung und Kundenüberprüfung investieren. Ein Wiederverkäufer, der die Verantwortung nach upstream schieben kann, kann an riskantere Kunden verkaufen. Ein Managed-Provider, der nicht im Register erscheint, kann Reputationsschäden vermeiden, wenn seine Konfiguration versagt.

Ein Kunde, der aus legitimen Datenschutzgründen nicht öffentlich genannt werden kann, muss möglicherweise dennoch eine nachweisbare Verantwortlichkeit gegenüber dem Inhaber, dem Register oder einem rechtlichen Anforderer unter definierten Bedingungen bereitstellen. Wenn niemand weiß, welche Schicht welche Verpflichtung trägt, hat jeder den Anreiz, den profitablen Teil sichtbar zu machen und den riskanten Teil privat zu halten.

Die Sprache der AFRINIC-Politik deutet die richtige Unterscheidung an. Sub-Allokationen und Zuweisungen sollen registriert werden, denn Einzigartigkeit, Fehlerbehebung und Kontinuität erfordern mehr als den Namen des Inhabers. Gleichzeitig verlangt das Handbuch keine öffentliche Datei über jeden nachgelagerten Nutzer. Der nützliche Mittelweg ist die Sichtbarkeit von Verantwortlichkeiten: genügend öffentliche und authentifizierte Informationen, um die verantwortliche Betriebsschicht zu identifizieren, ohne die Identität jedes Kunden dem gesamten Internet preiszugeben.

Die Kosten eines Fehlers sind für kleine Netzwerke am höchsten. Große Plattformen können private Vertrauenskanäle mit großen Banken, Transit-Providern, Sicherheitsanbietern und öffentlichen Behörden aufbauen. Kleine ISPs und regionale Hosting-Unternehmen können das nicht. Sie sind auf öffentliche und halböffentliche Register angewiesen, um von Fremden geglaubt zu werden. Wenn die öffentlichen Nachweise dünn sind, zahlen sie mit Verzögerungen, strengerem Filtern, verlorenen Kunden und geringerer Verhandlungsmacht.

Die Intransparenz von Sub-Allokationen wird so zu einer regressiven Steuer für die Netzwerke, die sie am wenigsten verkraften können.

Die nachgelagerte Schicht ist bereits Teil der Allokationsökonomie

Das AFRINIC-Richtlinienhandbuch beschreibt die Adressverteilung nicht als einstufige Transaktion zwischen Register und Endnutzer. Es definiert eine Hierarchie. Ein LIR erhält Zuteilungen von einem regionalen Register und weist hauptsächlich Adressraum an Endnutzer zu. Eine Sub-Allokation ist eine Verteilung durch einen LIR an einen ISP zur weiteren Verteilung. Eine Zuweisung ist ein Block, der von einem LIR einem ISP oder Endnutzer für eine spezifische Nutzung in der von dieser Partei betriebenen Infrastruktur gegeben wird.

Provider-aggregierbarer Raum kann als nicht-portabler Raum an nachgelagerte Netzwerke zugewiesen oder sub-allokiert werden, während provider-unabhängige Zuweisungen nicht für weitere Sub-Allokationen bestimmt sind. Dies ist bereits ein geschichtetes System.

Das Handbuch knüpft dann Verantwortlichkeiten an diese Schichtung. Es gibt an, dass jede Allokation, PI-Zuweisung, PA-Zuweisung, Sub-Allokation und sonstige Ressourcenzuweisung in der AFRINIC-Datenbank registriert werden muss und dass nicht registrierte Ressourcen als ungültig betrachtet werden. Es verlangt, dass die Registrierungsdaten jederzeit korrekt sind. Es legt die minimale formale IPv4-Sub-Allokation auf /24 fest. Es verlangt, dass LIRs Sub-Allokationen innerhalb ihrer Sub-Allokationsfenster vornehmen oder jenseits dieser Fenster die AFRINIC-Genehmigung einholen.

Es macht LIRs dafür verantwortlich sicherzustellen, dass der ihnen zugeteilte und anschließend sub-allokierte Raum in Übereinstimmung mit den Richtlinien und Vorgaben der Community genutzt wird. Es empfiehlt einen langsamen Start für nachgelagerte ISPs. Es behandelt den Raum nachgelagerter ISPs als nicht-portabel innerhalb des aggregierbaren Blocks des LIR.

Diese Regeln offenbaren die institutionelle Logik. AFRINIC muss nicht den Nutzer jedes Pakets kennen, aber es kann der nachgelagerten Struktur nicht gleichgültig gegenüberstehen. Wenn ein nachgelagerter ISP ein /24 erhält, darf die Registerdatenbank nicht blind bleiben. Wenn der öffentliche Adressraum eines Endnutzers nicht nur eine Punkt-zu-Punkt-Infrastruktur ist, gibt das Handbuch an, dass er mit den Kontakten des Endnutzers registriert werden muss, mit einer Ausnahme für die Privatsphäre von Einzelpersonen.

Wenn Reverse-DNS für ein /24 angefordert wird, gibt das Handbuch an, dass mindestens eine Zuweisung oder Sub-Allokation für genau dieses /24 registriert sein muss. Die Registerdienste selbst setzen registrierte Betriebsfakten voraus.

Die moderne Schwierigkeit besteht darin, dass die kommerzielle Realität Schichten schafft, die nicht immer den alten Kategorien entsprechen. Ein Hosting-Unternehmen kann /29er, /28er oder /27er innerhalb eines registrierten /24 zuweisen. Ein Firewall-Anbieter kann Sicherheits-Appliances für viele Kunden innerhalb des Aggregats eines Anbieters betreiben. Ein Wiederverkäufer kann virtuelle private Server verkaufen, ohne eine formale /24-Sub-Allokation zu erhalten. Ein Broker kann bei der Organisation der Nutzung helfen, ohne als technischer Betreiber zu erscheinen.

Eine Leasing-Plattform kann den Kundenzugang koordinieren, während der registrierte Inhaber unverändert bleibt. Ein Managed-Service-Provider kann die Missbrauchsbekämpfung steuern, aber nicht den Ursprung der Routen. Die nachgelagerte Schicht ist feingranularer als die Politikeinheit.

Diese Diskrepanz sollte nicht zu zwei schlechten Antworten führen. Die erste besteht darin, so zu tun, als könne das öffentliche Register alles unterhalb des registrierten Inhabers ignorieren. Das macht Fehlerbehebung, Missbrauchsbekämpfung, Due Diligence und Strafverfolgungs-Routing zu teuer. Die zweite besteht darin, zu verlangen, dass jeder kleine Kundenbereich und jeder Kundenname öffentlich ist. Das schafft Datenschutz- und Sicherheitsnachteile und kann legitime Betreiber zu privaten Vereinbarungen drängen, die weniger, nicht mehr offenlegen.

Eine bessere Antwort geht von funktionaler Sichtbarkeit aus. Das Register sollte den vom Inhaber betriebenen Raum von Kundenzuweisungen, Sub-Allokationen nachgelagerter ISPs, von Wiederverkäufern verwaltetem Raum, Managed-Service-Betrieb, Leasing-Betrieb, durch Datenschutz geschützter Endnutzernutzung und dem Status „bestritten“ oder „veraltet“ unterscheiden. Es ist nicht immer notwendig, den rechtlichen Namen des Kunden zu veröffentlichen. Es sollte genug veröffentlichen, um zu zeigen, welche Schicht für die Betriebsreaktion verantwortlich ist und welches Gewicht dieser Aussage beizumessen ist.

Der Inhaber bleibt für die Beziehung zum Register verantwortlich. Der nachgelagerte Betreiber wird für betriebliche Fragen auffindbar. Der Kunde kann geschützt bleiben, wenn Gesetz, Sicherheit oder Geschäftsgeheimnis dies rechtfertigen.

Diese Registrierungslogik stützt bereits eine Verantwortlichkeitskarte. Die Registrierung existiert, um Einzigartigkeit zu gewährleisten und Informationen zur Fehlerbehebung bereitzustellen. Auf einem IPv4-Knappheitsmarkt umfasst Fehlerbehebung nun die Erreichbarkeit von Missbrauchskontakten, die Erklärung des Routenursprungs, die Konsistenz von Reverse-DNS, Nachweise der Subdelegation, die Due Diligence bei Transfers, die Beschaffung im öffentlichen Sektor und die Fähigkeit von Außenstehenden, einen versteckten Kunden von einer aufgegebenen Registrierung zu unterscheiden.

Ein öffentliches Register ist keine private Kundenliste

Die institutionelle Grenze ist einfach zu formulieren und schwer umzusetzen. Ein öffentliches Register darf nicht zu einer Kundenliste werden. Es muss zu einer Verantwortlichkeitskarte werden. Die Unterscheidung ist wichtig. Eine Kundenliste legt offen, wer Dienstleistungen von wem kauft. Eine Verantwortlichkeitskarte legt offen, welche Rolle für einen Ressourcenabschnitt verantwortlich ist, welcher Kontaktkanal aktiv ist, welche Nachweise die Rolle stützen und wie viel Vertrauen Außenstehende ihr entgegenbringen sollten.

Für öffentliche Nutzer ist die minimal nützliche Registrierung nicht die vollständige Identität des Kunden. Es sind Rolle und Erreichbarkeit. Eine öffentliche Registrierung kann angeben, dass ein /24 vom Inhaber betrieben, einer Organisation zugewiesen, einem nachgelagerten ISP sub-allokiert, über einen verwalteten Dienst genutzt, einem durch Datenschutz geschützten Endnutzer delegiert, unter der Verantwortung des Inhabers kommerziell geleast oder delegiert wurde oder Gegenstand eines Streits oder einer veralteten Bestätigung ist.

Sie kann die Rollenkontakte veröffentlichen: Inhaberkontakt, technischer Kontakt, Missbrauchskontakt, Routing-Kontakt und Reverse-DNS-Kontakt. Sie kann Zeitstempel ausweisen: erste Registrierung, letzte Validierung, letzte materielle Aktualisierung und Ablauf der Validierung. Sie kann anzeigen, ob die nachgelagerte Rolle vom Inhaber selbst beglaubigt, von AFRINIC validiert, aus Routing-Nachweisen abgeleitet, durch eine Reverse-DNS-Delegation bestätigt oder aus Datenschutzgründen geschwärzt wurde.

Für authentifizierte Gegenparteien können mehr Details angemessen sein. Ein Transit-Provider, der eine Route bewertet, ein Käufer, der eine Transfer-Due-Diligence durchführt, ein Register, das eine Überprüfung bearbeitet, oder eine öffentliche Stelle mit einem Rechtshilfeersuchen benötigt möglicherweise die rechtliche Identität des nachgelagerten Betreibers, ein Autorisierungsschreiben, vertragliche Nachweise, Notfallkontakte, die Betriebsgeografie, die Kundenkategorie, Eskalationsfenster und den Nachweis, dass der Inhaber die Zusammenarbeit durchsetzen kann. Diese Details müssen nicht für jeden lesbar sein.

Sie können vom Inhaber aufbewahrt, in begrenztem Umfang beim Register hinterlegt, unter Vertraulichkeitsvereinbarung geteilt oder per Gerichtsbeschluss oder Rechtshilfeersuchen offengelegt werden.

Für Gerichte und Strafverfolgungsbehörden sollte die Schwelle höher, die Informationen aber tiefgehender sein. Wenn ein Rechtshilfeersuchen die Identität hinter einer durch Datenschutz geschützten Zuweisung sucht, sollte das System die Ermittler nicht dazu zwingen, durch fünf Zwischenhändler zu raten. Der Inhaber sollte in der Lage sein, die Kette zurückzuverfolgen. Das Register sollte wissen, ob der Inhaber eine solche Rückverfolgbarkeit beansprucht.

Das öffentliche Register sollte anzeigen, dass ein durch Datenschutz geschützter nachgelagerter Nutzer existiert und dass die gerichtliche Eskalation einen definierten Pfad hat, nicht dass der Kunde für alle unsichtbar ist.

Evidenzlabel sind unabdingbar, doch sie sollten sparsam und klar verwendet werden. Derselbe sichtbare Fakt hat einen unterschiedlichen Wert, je nachdem, wie er gewonnen wurde. Ein vom Inhaber attestierter nachgelagerter ISP ist nicht dasselbe wie ein vom Register validierter ISP. Ein durch Routing beobachteter Ursprung ist nicht dasselbe wie ein registrierter operativer Nutzer. Eine Reverse-DNS-Delegation ist kein Nachweis der Missbrauchsverantwortung. Ein aus Datenschutzgründen geschwärzter Nutzer ist nicht dasselbe wie ein unbekannter Nutzer.

Eine letzte Aktualisierung im letzten Monat ist nicht dasselbe wie ein Eintrag, der zuletzt 2014 angefasst wurde. Ein Register, das diese Unterschiede ausweist, senkt die Interpretationskosten, ohne zu behaupten, mehr zu wissen, als es weiß.

Dieselbe Struktur schützt das Register vor Machtüberschreitungen. Indem AFRINIC die Rolle, die Kontaktierbarkeit, den Evidenzstatus und die Unsicherheit veröffentlicht, kann es das öffentliche Vertrauen verbessern, ohne das Recht zu beanspruchen, jeden Kunden auf Richtlinienkonformität zu überprüfen. Es kann sagen: Hier ist der anerkannte Inhaber; dieser Block wird nachgelagert betrieben; der verantwortliche Betriebskanal ist hier; die rechtliche Identität wird nicht öffentlich bekannt gegeben, ist aber unter definierten Bedingungen rückverfolgbar; das letzte Validierungsdatum ist aktuell oder abgelaufen.

Ein solches Register ist schlanker als eine Kundendatenbank und gehaltvoller als ein bloßer Inhabereintrag. Es ist die wirtschaftlich nützliche Mitte.

Die IPv4-Knappheit macht Intransparenz zu einem Marktabschlag

Die Intransparenz von Sub-Allokationen ist nicht nur ein Sicherheitsproblem. Sie ist ein Marktabschlag. Wenn eine knappe Ressource nicht vom Inhaber zur tatsächlichen betrieblichen Verantwortung zurückverfolgt werden kann, bepreist jede Gegenpartei die Lücke. Der Käufer eines Blocks möchte wissen, ob nicht offengelegte nachgelagerte Nutzer einer Migration standhalten werden. Der Leasingnehmer möchte wissen, ob der Leasinggeber Routen-, Reverse-DNS- und Missbrauchsänderungen über jeden zwischengeschalteten Wiederverkäufer hinweg unterstützen kann.

Die Bank möchte wissen, ob adressbezogene Einnahmen von Kunden abhängen, deren Verträge nicht überprüft werden können. Der öffentliche Beschaffer möchte wissen, ob ein kritischer Dienst auf Adressen beruht, deren Autoritätskette uneindeutig ist. Der Upstream möchte wissen, ob er die Route akzeptieren kann, ohne zur ersten ansprechbaren Partei für jede Beschwerde zu werden.

AFRINICs Knappheitsdaten machen den Abschlag konkret. Seine Erschöpfungsmitteilung gab an, dass Phase 2 begann, als nicht mehr als ein /11 an nicht reserviertem Raum im letzten /8 übrig war. In Phase 2 ist der Umfang der gewöhnlichen Allokation oder Zuweisung klein, mit einem Minimum von /24 und einem Maximum von /22. Solche Grenzen beseitigen die Nachfrage nicht; sie verlagern die Nachfrage hin zu Wiederverwendung, Transfers, Leasing, Hosting-Angeboten, Kundenumverteilung und betrieblicher Delegation. Je mehr die Nachfrage durch bestehende Inhaber wandert, desto wichtiger wird es zu wissen, was unterhalb dieser Inhaber geschieht.

Intransparenz macht auch alte Registrierungen gefährlicher. KrebsOnSecurity berichtete 2019 über Vorwürfe, dass wertvoller afrikanischer IPv4-Adressraum, der mit ruhenden oder verschwundenen Organisationen in Verbindung stand, über Unternehmen, die mit einem ehemaligen hochrangigen AFRINIC-Funktionär verbunden waren, abgezweigt oder verkauft worden sei; der Forscher Ron Guilmette schätzte, dass der betroffene Raum einen Marktwert von über 50 Millionen US-Dollar darstelle. Die Bedeutung für die Sichtbarkeit von Sub-Allokationen liegt nicht nur in der mutmaßlichen Korruption.

Sie liegt darin, dass ruhende Registrierungen und schwache Autoritätsketten wertvoll werden, wenn IPv4 einen Preis hat. Eine Registrierung, die nicht klar erkennen lässt, wer für die nachgelagerte Nutzung sprechen kann, lädt sowohl zu Betrug als auch zu defensiven Abschlägen ein.

Die Auseinandersetzung um Cloud Innovation zeigt die entgegengesetzte Seite desselben Problems. Öffentliche Analysen beschrieben einen Konflikt über Millionen von IPv4-Adressen, kommerzielles Leasing, tatsächliche Nutzung versus registrierte oder erwartete Nutzung sowie AFRINICs beanspruchte Fähigkeit, die Anerkennung von Ressourcen zu überprüfen oder zu beenden. Cloud Innovation bestritt AFRINICs Theorie, und der Rechtsstreit eskalierte. Für die Sichtbarkeit von Sub-Allokationen lautet die Lehre nicht, dass jedes Leasing schlecht oder jede Registeruntersuchung legitim ist.

Die Lehre lautet, dass, wenn die tatsächliche nachgelagerte Nutzung undurchsichtig ist, das Register versucht sein kann, allgemeine Kundeninformationen zu verlangen, während der Inhaber unter Berufung auf Geschäftsgeheimnisse widerstehen kann. Beide Seiten können teilweise recht haben und dennoch ein schlechtes Gleichgewicht hervorbringen.

In einem guten Gleichgewicht legen die Inhaber strukturierte Verantwortung offen, ohne rohe Kundenlisten preiszugeben. In einem schlechten Gleichgewicht legen sie wenig offen, das Register verlangt zu viel, es kommt zu Rechtsstreitigkeiten und der Markt schlägt das gesamte Portfolio ab. Die IPv4-Knappheit macht diesen Abschlag groß genug, um das Verhalten zu ändern. Ein Inhaber mit geringer nachgelagerter Sichtbarkeit sieht sich mit geringerem Käufervertrauen, höheren Rechtskosten, schlechterer Reputation nach Missbrauch und geringerer Akzeptanz im öffentlichen Sektor konfrontiert.

Ein Register mit schlechter Sichtbarkeit steht unter Druck, breite Prüfungen einzusetzen, weil engere Nachweise nicht verfügbar sind. Der Mangel an Sichtbarkeit schafft so das Argument der Diskretion.

Das wirtschaftliche Ziel sollte sein, verantwortliche Nutzung billiger zu machen als versteckte Nutzung. Ein Inhaber, der validierte nachgelagerte Rolleneinträge, aktive Kontakte, durch Datenschutz geschützte, aber rückverfolgbare Kunden und klare Unsicherheitslabel pflegt, sollte bei Transaktionen und Vorfällen weniger Reibung erfahren. Ein Inhaber, der nicht erklären kann, wer seinen Adressraum nutzt, sollte mit Abschlägen, langsameren Genehmigungen und strengerer Prüfung bezahlen. Das ist keine Bestrafung. Es ist die Bepreisung von Informationsqualität.

Die Beweislage ist vielschichtig, und jede Oberfläche hat ihre Grenzen

Keine einzelne Datenquelle kann die Frage der nachgelagerten Verantwortung beantworten. RDAP und WHOIS liefern die Daten des registrierten Inhabers und Kontakte. BGP zeigt, welches autonome System eine Route ankündigt. IRR-Objekte drücken die Routing-Politik und Routenautorisierungsvereinbarungen aus. RPKI und ROAs können die Ursprungsautorität validieren. Reverse-DNS kann Benennungsmuster, Kundendelegationen und die Betriebshistorie offenbaren.

Geolokalisierungsdatenbanken, Traceroute, Latenz, TLS-Zertifikate, Missbrauchshistorien, DNS-Zonen, E-Mail-Reputation, Hosting-Banner, Unternehmensregister und Kundenverträge können jeweils Hinweise hinzufügen. Keines ist für sich allein schlüssig.

Diese vielschichtige Beweislage ist sowohl nützlich als auch gefährlich. Sie ist nützlich, weil die nachgelagerte Verantwortung oft erst dann zutage tritt, wenn die Signale kombiniert werden. Ein /24, das von einem Inhaber registriert ist, von einem Hosting-ASN angekündigt wird, durch eine ROA für diesen ASN abgedeckt ist, mit einem Reverse-DNS-Muster eines Wiederverkäufers benannt ist, in einem von einem Dritten gepflegten IRR-Objekt gelistet ist und eine Missbrauchshistorie mit VPS-Kunden aufweist, wird wahrscheinlich nicht vom Inhaber im einfachen Sinne betrieben.

Aber sie ist gefährlich, weil die Schlussfolgerung über die Beweise hinausschießen kann. Ein Reverse-DNS-Label kann veraltet sein. Ein IRR-Objekt ist möglicherweise nicht autorisiert. Eine Geolokalisierungsdatenbank kann falsch sein. Eine ROA kann die Ursprungsautorität der Route belegen, nicht die Identität des Kunden. Ein Ursprungs-AS kann ein Transit- oder Managed-Service-Betreiber sein, nicht der Endnutzer.

AFRINICs öffentliche Dienste decken einen großen Teil dieser Beweislage ab. Das Register bietet WHOIS-, RDAP-, Reverse-DNS-, IRR- und RPKI-bezogene Dienste. Sein Richtlinienhandbuch verknüpft die Reverse-Delegation mit registrierten Zuweisungen oder Sub-Allokationen. Seine Missbrauchskontakt-Politik schafft einen Ort für Missbrauchsinformationen, räumt aber gleichzeitig ein, dass das Objekt, wie andere Objekte auch, mit dem Problem der Datengenauigkeit konfrontiert ist. Ehrlichkeit zählt. Ein Feld kann einen Kanal schaffen, ohne zu beweisen, dass der Kanal korrekt ist.

Eine ROA kann einen Ursprung autorisieren, ohne den nachgelagerten Kunden zu beweisen. Eine Zuweisung kann einen Endnutzerbereich identifizieren, ohne jedes spätere Betriebsdetail zu beweisen.

Das öffentliche Register sollte daher den Nachweistyp ausweisen. Eine nachgelagerte Rolle kann registriert sein, vom Inhaber attestiert, vom Register validiert, durch Routing beobachtet, konsistent mit Reverse-DNS, vertraglich hinterlegt, durch gerichtliche Eskalation rückverfolgbar, veraltet, bestritten oder aus Datenschutzgründen geschwärzt sein. Diese Label mögen bürokratisch erscheinen, wenn sie zu häufig verwendet werden. Richtig eingesetzt, haben sie wirtschaftlichen Wert.

Sie verhindern, dass ein schwaches Signal als starkes Signal behandelt wird, und verhindern, dass das Fehlen einer öffentlichen Identität als Fehlen von Verantwortung behandelt wird.

Evidenzlabel verringern auch den Anreiz für private Mythologie. Auf undurchsichtigen Märkten füllen Broker und Gegenparteien die Lücken mit Behauptungen: sauberer Block, durch Gerichtsurteil gestützt, aus erster Hand, Afrika-konform, missbrauchsfrei, vollständig autorisiert, sicher für den Einsatz im öffentlichen Sektor. Einige Behauptungen mögen wahr sein. Einige mögen Marketing sein. Ein Registereintrag, der strukturierte Nachweise ausweist, gibt Käufern und Betreibern ein Mittel, Behauptungen zu testen, ohne AFRINIC in einen kommerziellen Schiedsrichter zu verwandeln. Das Register kann sagen, was es validiert hat und was nicht.

Der Markt kann den Rest bepreisen.

Dies ist in Zeiten institutionellen Stresses besonders wichtig. Während einer Insolvenzverwaltung, bei Wahlstreitigkeiten oder Rechtsstreitigkeiten werden Gerüchte zu Ersatz für Registrierungen. Wenn die öffentliche Datenbank nicht zwischen einem gewöhnlichen nachgelagerten Betrieb und einer bestrittenen Delegation oder zwischen einem Datenschutzschutz und einer unbekannten Nutzung unterscheiden kann, werden Gegenparteien aus den Schlagzeilen schlussfolgern. Ein leichtgewichtiges Evidenzlabel kann kostspielige Überreaktionen verhindern. Das Register muss nicht jeden Betriebsfakt garantieren.

Es muss den Status der Fakten offenlegen, die es innehat.

Die Beweislage sollte als Wahrscheinlichkeitskarte gelesen werden. Je stärker die Kombination aus registrierter Sub-Allokation, validiertem Kontakt, passendem Routenursprung, aktueller ROA, konsistentem Reverse-DNS und jüngster Bestätigung ist, desto geringer ist die Mehrdeutigkeitssteuer. Je schwächer die Kombination, desto mehr Vorsicht ist gerechtfertigt. So verhalten sich die Märkte bereits informell. AFRINIC kann den Markt verbessern, indem es die informelle Wahrscheinlichkeitskarte expliziter macht.

Die Erreichbarkeit bei Missbrauch ist eine Folge, nicht die ganze Geschichte

Missbrauchsbeschwerden sind oft der Zeitpunkt, an dem die Intransparenz von Sub-Allokationen sichtbar wird. Eine Bank sieht Angriffe. Ein Sicherheitsanbieter sieht Malware-Callbacks. Ein E-Mail-Betreiber sieht Spam. Ein Urheberrechtsinhaber sieht Hosting. Eine öffentliche Stelle sieht einen Scan gegen einen Regierungsdienst. Der Beschwerdeführer fragt das Register ab und schickt eine Mail an den angegebenen Kontakt.

Wenn der angegebene Inhaber nicht der tatsächliche Betreiber ist, beginnt das Ticket seitlich zu wandern: vom Inhaber zum Wiederverkäufer, vom Wiederverkäufer zum Hosting-Provider, vom Hosting-Provider zum Managed-Firewall-Provider, vom Provider zum Kunden. Jeder Sprung fügt Verzögerungen und Fehler hinzu.

Es ist verlockend, den Missbrauchskontakt zum alleinigen Thema zu machen. Das wäre zu eng. Die Erreichbarkeit bei Missbrauch ist ein Ergebnis der nachgelagerten Sichtbarkeit, nicht die gesamte Ökonomie. Dieselbe Sichtbarkeit beeinflusst die Routenakzeptanz, die Transaktions-Due-Diligence, die Kundenkontinuität, die öffentliche Beschaffung, die Sanktionsfilterung, die Reaktion der Strafverfolgungsbehörden, die Geolokalisierung, Reverse-DNS, die RPKI-Wartung und das Reputationsmanagement. Ein Missbrauchsticket ist lediglich der Zeitpunkt, an dem die verborgene Struktur teuer genug wird, um bemerkt zu werden.

AFRINICs Missbrauchskontakt-Politik ist ein nützlicher Beleg für diese begrenzte Rolle. Sie spezifiziert ein dediziertes Objekt als bevorzugten Ort zur Veröffentlichung öffentlicher Missbrauchskontaktinformationen, das in inetnum-, inet6num- und aut-num-Objekten referenziert wird. Sie zielt darauf ab, Missbrauchsmeldungen zu helfen, den richtigen Netzkontakt zu erreichen. Sie räumt auch einen Nachteil ein: Das Objekt steht vor demselben Datengenauigkeitsproblem wie andere Objekte und verbessert nicht an sich die Genauigkeit der Datenbank. Das ist genau das Problem.

Eine Mailbox löst die nachgelagerte Intransparenz nicht, wenn die Mailbox der falschen Schicht gehört oder wenn der Inhaber den nachgelagerten Betreiber nicht zum Handeln zwingen kann.

Eine bessere Struktur verknüpft die Missbrauchserreichbarkeit mit der Rollensichtbarkeit. Wenn ein Block vom Inhaber betrieben wird, sollte die Missbrauchsstelle des Inhabers der hauptsächliche öffentliche Kanal sein. Wenn er einem nachgelagerten ISP sub-allokiert ist, sollte der validierte Missbrauchskanal des nachgelagerten ISP sichtbar sein, wobei die Eskalation zum Inhaber erhalten bleibt. Wenn er einem Geschäftskunden zugewiesen ist, dessen Identität aus Datenschutzgründen geschützt ist, sollte das öffentliche Register eine verantwortliche Betriebsstelle oder einen Proxy sowie einen gerichtlichen Eskalationspfad veröffentlichen.

Wenn er von einem Firewall- oder Hosting-Provider verwaltet wird, sollte das öffentliche Register zeigen, welche Betriebsschicht Missbrauch zuerst entgegennimmt. Wenn die Verantwortung bestritten oder veraltet ist, sollte das Register dies sagen.

Dies vermeidet zwei häufige Misserfolge. Der erste ist das Problem der falschen Stelle, bei dem Beschwerden den rechtlichen Inhaber erreichen, aber nicht den Betreiber, der Abhilfe schaffen kann. Der zweite ist das Problem des nicht zurechenbaren Kunden, bei dem sich der Inhaber auf Vertraulichkeit oder Wiederverkäuferdistanz beruft und keine ansprechbare Partei handelt. In beiden Fällen werden die Kosten auf Dritte abgewälzt. Banken blockieren übermäßig. Upstreams drohen mit Aussetzung. Reputationsdienste markieren benachbarten Raum. Strafverfolgungsbehörden eskalieren über langsamere Kanäle. Unschuldige Nutzer teilen die Strafe.

Missbrauchssichtbarkeit schützt auch die Inhaber. Ein Inhaber, der eine validierte nachgelagerte Verantwortung vorweisen kann, kann seine eigene Exposition reduzieren. Er kann einem Beschwerdeführer sagen: Dieser Bereich wird von dieser nachgelagerten Rolle betrieben; hier ist der Missbrauchskanal; der Inhaber bleibt für die Eskalation verfügbar, falls die nachgelagerte Stelle versagt. Das ist besser, als jedes Ticket zu erhalten, einige zu verpassen und als nachlässig behandelt zu werden. Es ist auch besser, als rohe Kundenidentitäten in einer Weise zu veröffentlichen, die Datenschutz- oder Sicherheitsrisiken schafft.

Die Ökonomie besteht also nicht darin, dass jeder Inhaber eine große Missbrauchsabteilung betreibt. Es geht darum, den Weg zur Verantwortung kurz genug zu machen, damit die Fixkosten von Vorfällen nicht auf zufällige Dritte abgewälzt werden. Die Sichtbarkeit von Sub-Allokationen ist die breitere Infrastruktur, die es der Missbrauchskontakt-Politik ermöglicht zu funktionieren.

Verantwortungsvolle Schwärzung ist der Datenschutz-Kompromiss

Der stärkste Einwand gegen nachgelagerte Sichtbarkeit ist der Datenschutz. Er verdient es, ernst genommen zu werden. Ein öffentliches Register, das jeden nachgelagerten Kunden nennt, könnte gefährdete Organisationen, Sicherheitsoperationen, Whistleblower-Infrastrukturen, politische Gruppen, öffentliche Auftragnehmer, Finanzinstitute, Gesundheitsdienstleister und gewöhnliche Unternehmen bloßstellen. Es könnte das Register auch in ein Aufklärungsinstrument verwandeln. Angreifer könnten Kunden kartieren, Lieferbeziehungen ableiten, Managed-Security-Provider identifizieren, Migrationsfenster ins Visier nehmen oder Druck auf Dienstleister ausüben.

Kommerzielle Wettbewerber könnten wissen, wer wen hostet. Eine Sichtbarkeitspolitik, die diese Nachteile ignoriert, würde sich selbst sabotieren.

Aber Datenschutz rechtfertigt keine völlige Undurchsichtigkeit. Das Internet erlegt Außenstehenden bereits externe Effekte auf. Pakete aus einem Bereich können eine Bank angreifen, ein Krankenhaus scannen, Phishing-Seiten hosten, die E-Mail-Reputation verschmutzen, eine Sanktionsüberprüfung auslösen oder einen öffentlichen Dienst beeinträchtigen. Wenn die verantwortliche Partei hinter einer Datenschutzsprache versteckt ist und kein rückverfolgbarer Kanal existiert, wird Datenschutz zu einem Mittel, um Kosten zu exportieren. Die Gestaltungsaufgabe besteht darin, den Datenschutz zu wahren und gleichzeitig die Verantwortlichkeit zu erhalten.

Die praktische Antwort ist eine mehrstufige Offenlegung. Öffentliche Registrierungen sollten die Rolle, die Kontaktierbarkeit, den Status, das Validierungsdatum und die Nachweisstärke enthalten. Sie sollten nicht unbedingt jeden rechtlichen Kundennamen veröffentlichen. Authentifizierte Gegenparteien können vertraglich oder aufgrund betrieblicher Notwendigkeit mehr Details erhalten. Das Register kann begrenzte Nachweise aufbewahren oder überprüfen, ohne sie öffentlich bekannt zu geben. Strafverfolgungsbehörden und Gerichte können tiefere Identitätsinformationen durch ein Rechtshilfeersuchen erlangen.

Für drohenden Schaden können Notfallkanäle existieren, ohne die Notfalloffenlegung zur Routine zu machen. Einzelpersonen können stärker geschwärzt werden als nachgelagerte Unternehmens-ISPs. Öffentliche Stellen können benannte Sicherheitskontakte verwenden, anstatt jeden Subunternehmer bloßzustellen.

Die Schwärzung muss gekennzeichnet sein, nicht still. „Kundenidentität aus Datenschutzgründen zurückgehalten; der Inhaber unterhält einen rückverfolgbaren Kontakt; validierter Missbrauchsproxy“ ist wirtschaftlich anders als „keine nachgelagerten Informationen“. Es sagt Außenstehenden, dass eine verantwortliche Struktur existiert, auch wenn der Name nicht öffentlich ist. Es schafft auch eine Verantwortung für den Inhaber: Wenn der Inhaber eine datenschutzgeschützte Rückverfolgbarkeit beansprucht, muss er in der Lage sein, zurückzuverfolgen.

Die Unfähigkeit, unter definierten Bedingungen zurückzuverfolgen, sollte Konsequenzen haben, denn sonst wird Datenschutz zu einem falschen Status.

Das Label muss auch Datenschutz von Geschäftsgeheimnissen trennen. Die sensible Infrastruktur einer Bank, eine Menschenrechtsgruppe und die Kundenliste eines Wiederverkäufers mögen alle Schutz verdienen, aber aus unterschiedlichen Gründen und gegenüber unterschiedlichen Offenlegungsstufen. Ein nachgelagerter ISP, der eine formale /24-Sub-Allokation erhält, ist nicht in derselben Lage wie ein einzelner Kunde, der eine kleine Zuweisung erhält. Das öffentliche Interesse, ein Betriebsnetz zu identifizieren, ist höher als das öffentliche Interesse, jeden Endnutzer zu benennen.

Das AFRINIC-Richtlinienhandbuch enthält bereits eine begrenzte Datenschutzregelung, wenn der Endnutzer eine Einzelperson ist: Der Adressraum kann mit den Kontaktdaten des Providers registriert werden, während der Endnutzer im Datenbankobjekt referenziert wird. Diese Logik kann mit Vorsicht erweitert werden.

Der institutionelle Test besteht darin, ob das System eine enge Frage beantworten kann: Wer kann im Falle eines Schadens, eines Rechtsstreits oder eines Rechtshilfeersuchens handeln? Es muss nicht jede Neugier befriedigen. Es muss nicht jeden Kunden veröffentlichen. Es darf nicht zulassen, dass Datenschutz die Verantwortung auslöscht. Auf einem knappen IPv4-Markt ist das funktionierende Datenschutzdesign nicht Geheimhaltung. Es ist verantwortungsvolle Schwärzung.

Routing, IRR und RPKI belegen die Autorität, nicht die Nutzung

Routing-Nachweise sind mächtig, weil sie beobachtbar sind. Wenn ein Präfix von einem bestimmten AS angekündigt wird, kann das operative Internet es sehen. Wenn ein IRR-Routenobjekt existiert, können Netzwerke eine behauptete Routing-Politik ableiten. Wenn eine ROA einen Ursprungs-AS autorisiert, können nutzende Parteien die Ursprungsautorität der Route validieren. Diese Signale sind wichtig für die nachgelagerte Sichtbarkeit, aber sie dürfen nicht mit einem vollständigen Nutzungsbericht verwechselt werden.

Der BGP-Ursprung identifiziert das Netz, das die Route ankündigt, nicht notwendigerweise den Kunden, der die Adressen nutzt. Ein Hosting-Provider kann Adressraum für viele Kunden ankündigen. Ein Managed-Service-Provider kann ein Präfix im Auftrag eines Unternehmens ankündigen. Ein Leasinggeber kann den AS eines Leasingnehmers autorisieren, während der Leasingnehmer Tausende kleiner Nutzer bedient. Ein Transit-Provider kann aufgrund der Routenbehandlung in den Nachweisen erscheinen, nicht aufgrund der Kundenverantwortung. Der Ursprungs-AS ist ein Hinweis auf die Betriebskontrolle, keine rechtliche Identität für jeden nachgelagerten Nutzer.

IRR-Objekte haben ähnliche Grenzen. Sie können Upstreams und Peers helfen, Filter zu bauen. Sie können zeigen, dass jemand ein Routen- oder Routen-Set-Objekt erstellt hat, das mit einem beanspruchten Ursprung übereinstimmt. Aber IRR-Daten können veraltet, dupliziert, in verschiedenen Datenbanken mit unterschiedlichen Authentifizierungsstandards erstellt oder von einer Partei gepflegt sein, die betrieblich nicht mehr verantwortlich ist. Ein IRR-Objekt, das vom technischen Kontakt eines Brokers gepflegt wird, kann helfen zu erklären, wie die Route akzeptiert wurde, beweist aber nicht, wer Missbrauch oder Kundenverträge verwaltet.

RPKI und ROAs sind für die Ursprungsautorität stärker, aber für die Verantwortung enger. Eine gültige ROA kann besagen, dass ein bestimmter AS autorisiert ist, ein Präfix anzukündigen. Sie kann nicht sagen, warum der AS den Adressraum nutzt, wer der nachgelagerte Kunde ist, ob die Nutzung regional ist, ob ein Wiederverkäufer beteiligt ist, ob Missbrauchsmeldungen die richtige Stelle erreichen oder ob eine Kundenzuweisung unter dem abgedeckten Präfix existiert. RPKI ist ein Sicherheitswerkzeug für den Routenursprung, kein Kundenidentitätssystem.

Diese Unterscheidung ist für AFRINIC wichtig, da RPKI- und IRR-Dienste der Registeranerkennung nahestehen. Ein Inhaber kann möglicherweise eine ROA für den AS eines Leasingnehmers erstellen. Das verleiht der Route aus Sicherheitssicht ein legitimes Erscheinungsbild. Es macht die nachgelagerte Kette nicht sichtbar. Umgekehrt kann das Fehlen einer ROA eine betriebliche Verzögerung oder geringe Akzeptanz widerspiegeln und nicht eine nicht autorisierte Nutzung. Wenn das öffentliche Register RPKI als einzigen Nachweis behandelt, wird es das eigentliche Problem der Verantwortung verfehlen.

Die korrekte Verwendung von Routing-Nachweisen ist Triangulation. Ein nachgelagerter Rolleneintrag kann besagen, dass der registrierte Inhaber den AS X autorisiert hat, das Präfix Y anzukündigen; dass eine ROA existiert oder nicht; dass ein IRR-Objekt existiert und aktuell oder veraltet ist; dass der Missbrauchskontakt für die Betriebsrolle erreichbar ist; und dass die Kundenidentität öffentlich, nur authentifiziert oder aus Datenschutzgründen geschwärzt ist. Dies kombiniert die Routing-Autorität mit der Verantwortungssichtbarkeit. Es überlastet kein kryptografisches oder routingpolitikalisches Artefakt mit Fakten, die es nicht beweisen kann.

Die institutionelle Wiederherstellung von AFRINIC würde von dieser Präzision profitieren. Das Register muss kein allwissender Richter der nachgelagerten Nutzung werden. Es muss aufhören, zuzulassen, dass sich eine Nachweisart für eine andere ausgibt. Routing zeigt Erreichbarkeit. RPKI zeigt Ursprungsautorität. IRR zeigt Politikbehauptung. RDAP und WHOIS zeigen registrierte Anerkennung und Kontakte. Reverse-DNS zeigt Benennungsdelegation. Nachgelagerte Sichtbarkeit zeigt, wer unterhalb des Inhabers verantwortlich ist, und mit welchem Grad an Gewissheit.

Reverse-DNS ist ein Hinweis, kein Beweis

Reverse-DNS wird oft als technischer Nebendienst behandelt, hat aber bei der nachgelagerten Sichtbarkeit ein unverhältnismäßig hohes praktisches Gewicht. Ein PTR-Eintrag kann eine Hosting-Marke, ein Wiederverkäufermuster, ein Kundenlabel, einen Länderhinweis, eine E-Mail-Dienstidentität oder eine alte Nutzung offenbaren, die vor Jahren hätte entfernt werden sollen. E-Mail-Systeme, Sicherheitstools, Kundensupportteams und Ermittler konsultieren regelmäßig Reverse-DNS, weil es einen menschenlesbaren Hinweis liefert, wenn der Registereintrag zu abstrakt ist.

Das AFRINIC-Richtlinienhandbuch gibt Reverse-DNS eine formale Verbindung zur nachgelagerten Registrierung. Es besagt, dass AFRINIC Reverse-Delegationsanträge von aktiven LIRs akzeptiert und dass keine Reverse-Delegation von verwaltetem oder zugeteiltem IP-Adressraum erlaubt ist, es sei denn, eine Zuweisung oder Sub-Allokation dieser spezifischen Allokation ist ordnungsgemäß in der AFRINIC-Datenbank registriert. Für eine /24-Reverse-Delegation muss mindestens eine Zuweisung oder Sub-Allokation für dieses spezifische /24 registriert sein.

Diese Regel ist eine diskrete Anerkennung, dass Reverse-DNS nicht frei schwebend gegenüber den registrierten Betriebsfakten sein sollte.

Der Hinweis kann dennoch irreführend sein. Reverse-DNS ist oft veraltet, nachdem ein Kunde abgewandert ist. Benennungskonventionen können generische Labels verwenden, die den tatsächlichen Betreiber verbergen. Ein Inhaber kann Reverse-DNS an einen Wiederverkäufer delegieren, dessen Kunde den Dienst kontrolliert. Ein Sicherheitsanbieter kann neutrale Namen verwenden, um die Bloßstellung von Kunden zu vermeiden. Ein E-Mail-Betreiber kann Namen eher für die Zustellbarkeit als für die Identität festlegen. Ein böswilliger Nutzer kann irreführende Namen erstellen.

Reverse-DNS kann daher nicht als Nachweis der nachgelagerten Identität behandelt werden.

Dennoch hat veraltetes oder undurchsichtiges Reverse-DNS wirtschaftliche Folgen. Reputationssysteme für E-Mail können einem Bereich misstrauen. Kunden fragen möglicherweise, warum die Namen auf einen alten Anbieter verweisen. Sicherheitsteams können Beschwerden an die falsche Organisation senden. Geolokalisierungs- und Hosting-Intelligence-Anbieter können alte Labels in Risikosysteme übernehmen. Ein Kunde des öffentlichen Sektors kann bei einer Beschaffungs- oder Sicherheitsprüfung durchfallen, weil die Adressbenennung nicht mit dem deklarierten Dienst übereinstimmt.

Ein Käufer kann Preisnachlässe verlangen, wenn die Kontrolle über Reverse-DNS unsicher erscheint. Ein Leasingnehmer kann entdecken, dass der Leasinggeber Namen nicht schnell aktualisieren kann, weil die registrierte Zuweisungsspur unvollständig ist.

Die Antwort ist nicht, aussagekräftige Namen in jeden PTR-Eintrag zu zwingen. Betriebliche Benennung hat Sicherheits- und Datenschutzkompromisse. Die Antwort ist, Reverse-DNS als eine Nachweisoberfläche zu behandeln. Eine öffentliche Verantwortungskarte kann anzeigen, ob Reverse-DNS vom Inhaber kontrolliert, nachgelagert delegiert, vom Kunden verwaltet, veraltet, datenschutzneutral oder inkonsistent mit der registrierten Rolle ist. Das ist nützlicher, als zu versuchen, alles aus den Namen selbst abzuleiten.

Reverse-DNS veranschaulicht auch, warum die Sichtbarkeit von Sub-Allokationen nicht allein in RDAP oder WHOIS gelöst werden kann. Die Registerdatenbank kann einen Inhaber und eine Sub-Allokation zeigen. Der Reverse-Baum kann eine andere Betriebsgeschichte zeigen. Die Route kann eine dritte zeigen. Der Missbrauchskontakt kann eine vierte zeigen. Ein ernsthaftes Sichtbarkeitsregime bringt diese Oberflächen in Einklang. Es meldet Inkonsistenzen, ohne anzunehmen, dass jede Inkonsistenz ein Fehler ist. Es fragt, ob die Inkonsistenz für die Erreichbarkeit, die Reputation, die gerichtliche Eskalation oder das Marktvertrauen von Bedeutung ist.

Für AFRINIC wäre eine bescheidene Verbesserung wertvoll: Wenn eine Reverse-Delegation mit einer registrierten Zuweisung oder Sub-Allokation verknüpft ist, sollte das öffentliche Register die Verknüpfung lesbar machen. Wenn ein /24 delegiertes Reverse-DNS hat, weil eine nachgelagerte ISP-Zuweisung existiert, sollten Außenstehende sehen können, dass die Reverse-Delegation nicht zufällig ist. Wenn Reverse-DNS unter der Kontrolle des Inhabers bleibt, während die betriebliche Nutzung nachgelagert ist, sollte das Register anzeigen, wer Namensänderungen und die Missbrauchseskalation verwaltet. Dies stellt keine Kunden bloß.

Dies stellt die Verantwortung für einen Dienst bloß, der sie bereits betrifft.

Behauptungen regionaler Nutzung erfordern Demut

Die Region von AFRINIC verleiht der Sichtbarkeit von Sub-Allokationen eine besondere politische Aufladung. Das Register bedient Afrika und einen Teil des Indischen Ozeans. Seine Erschöpfungsdokumente und sein Richtlinienhandbuch rahmen Ressourcen um die AFRINIC-Dienstregion herum. Seine Soft-Landing-Politik enthält Sprache zur regionalen Nutzung von Ressourcen während der Erschöpfungsperiode. Öffentliche Analysen der Cloud-Innovation-Auseinandersetzung beschrieben AFRINICs Bedenken hinsichtlich Diskrepanzen zwischen registrierten Nutzungsbeschreibungen und tatsächlichen Nutzungsländern sowie hinsichtlich Diensten, die von der Region ausgehen.

Cloud Innovation und gleichgesinnte Kritiker bestritten diese Auslegung und machten geltend, dass der Betrieb eines globalen Netzwerks nicht auf eine einfache geografische Regel reduziert werden könne.

Für die nachgelagerte Sichtbarkeit ist der entscheidende Punkt, dass die regionale Nutzung nicht immer direkt sichtbar ist. Die Routing-Geografie ist nicht die Kundengeografie. Ein Präfix, das von einem AS in Europa angekündigt wird, kann afrikanische Nutzer über eine Content- oder Sicherheitsplattform bedienen. Ein Server in Johannesburg kann Kunden weltweit unterstützen. Ein auf den Seychellen registrierter Inhaber kann Adressen an ein Netzwerk mit Kunden in China, Nigeria und Südafrika verleasen.

Eine Geolokalisierungsdatenbank kann einen Block aufgrund der Registerdaten in ein Land legen, aufgrund des Routings in ein anderes und aufgrund von Nutzermeldungen in ein drittes. Reverse-DNS kann aus betrieblichen Gründen Ländercodes verwenden. Die Latenz kann anzeigen, wo der Verkehr ins Netz eintritt, nicht wo der wirtschaftliche Dienst erbracht wird.

Das bedeutet nicht, dass Nachweise regionaler Nutzung nutzlos sind. Es bedeutet, dass sie als Vertrauensgrad, nicht als Gewissheit ausgedrückt werden sollten. Ein Verantwortungseintrag kann die deklarierte Dienstregion, den beobachteten Routenursprung, den Geolokalisierungskonsens, die Kundenkategorie, die afrikanische Abhängigkeit, den außerregionalen Betrieb und den unbekannten Status unterscheiden.

Er kann anzeigen, ob ein Inhaber selbst attestiert hat, dass die Nutzung die Konnektivität zur AFRINIC-Region unterstützt, ob das Register eine spezifische Behauptung regionaler Nutzung validiert hat, ob die Nachweise nur durch Routing beobachtet werden oder ob die Frage bestritten ist. Das ist ehrlicher, als so zu tun, als würde ein einzelnes Länderfeld die Frage klären.

Demut ist auch wirtschaftlich effizient. Wenn das Register eine schwache Schlussfolgerung als Beweis behandelt, werden sich Inhaber der Offenlegung widersetzen und klagen. Wenn Inhaber die Geografie als nicht erkennbar behandeln, werden das Register und öffentliche Interessengruppen Ausweichverhalten unterstellen. Ein vertrauensbasierter Eintrag gibt beiden Parteien ein weniger explosives Vokabular. Er ermöglicht es AFRINIC, Muster zu erkennen, ohne rohe Kundenlisten für jeden Block zu verlangen. Er ermöglicht es Inhabern, regionale Relevanz offenzulegen, ohne jeden Kunden bloßzustellen.

Er ermöglicht es den Märkten, Unsicherheit zu bepreisen, anstatt eine konform/nicht-konform-Binärlogik zu erfinden.

Die Ableitung regionaler Nutzung ist auch für Entwicklungsbehauptungen von Bedeutung. Einige argumentieren, dass von Afrika ausgegebene IPv4-Adressen die afrikanische Konnektivität unterstützen sollten. Andere argumentieren, dass globale Märkte und interregionale Nachfrage wichtiger sein werden als der Schutz des verbleibenden regionalen Bestands. Das öffentliche Register sollte diese Debatte nicht durch undurchsichtige Felder entscheiden. Es sollte Nachweise liefern: wo die nachgelagerte Verantwortung liegt, welche Nutzung deklariert ist, was beobachtet wird, was validiert ist und was unsicher bleibt.

Gute Nachweise können die Politik informieren. Schlechte Ableitung wird zur Kapitalkontrolle durch Mutmaßung.

Die Norm sollte kühl und praktisch sein. Die deklarierte Rolle und Region auf der richtigen Detailebene veröffentlichen. Beobachtete Signale kennzeichnen. Datenschutz wahren, wo gerechtfertigt. Nur eskalieren, wenn Nachweise materiell mit der Politik oder dem öffentlichen Vertrauen kollidieren. In einer Region, in der das Register bereits mit Rechtsstreitigkeiten über Nutzung und Kontrolle konfrontiert war, ist diese Demut keine Schwäche. Sie ist Risikomanagement.

Vermittler benötigen Verantwortungs-Labels

Die moderne nachgelagerte Kette ist selten eine gerade Linie. Ein Inhaber kann mit einem Broker zusammenarbeiten. Der Broker kann einen Wiederverkäufer vermitteln. Der Wiederverkäufer kann Adressen in VPS-, E-Mail-, VPN- oder Managed-Firewall-Produkte verpacken. Ein Hosting-Provider kann den Ursprungs-AS betreiben. Ein Kunde kann den Server kontrollieren. Ein Drittanbieter für Missbrauchsbekämpfung kann Beschwerden sichten. Ein Managed-DNS-Provider kann die Reverse-Zonen kontrollieren. Das öffentliche Register zeigt möglicherweise nur den Inhaber und vielleicht den Ursprungs-AS.

Wenn Probleme auftreten, kann jede Schicht sagen, eine andere Schicht verfüge über die Betriebsfakten.

Broker und Wiederverkäufer sind nicht von Natur aus schlecht. Sie senken die Suchkosten, gleichen ungenutzte Kapazitäten mit der Nachfrage ab, bieten technische Integration, stellen Dokumentation zusammen und helfen kleinen Netzwerken, Adressen zu erhalten, die sie sonst nicht finden könnten. Managed-Service-Provider lösen ebenfalls echte Probleme. Viele Kunden wollen Routing, Reverse-DNS, Missbrauchsstellen oder RPKI nicht selbst verwalten. Outsourcing kann die Qualität verbessern. Das Sichtbarkeitsproblem ist nicht die Vermittlung. Es ist die ungekennzeichnete Vermittlung.

Ein Verantwortungs-Label ist eine schmale Offenlegung der Rolle. Es sagt nicht, dass der Broker den Block besitzt oder dass der Wiederverkäufer der Endkunde ist. Es kann besagen, dass ein kommerzieller Vermittler beteiligt ist, aber nicht der betriebliche Kontakt ist. Es kann besagen, dass ein Wiederverkäufer für die Kundenüberprüfung verantwortlich ist. Es kann besagen, dass ein Managed-Service-Betreiber Missbrauch zuerst entgegennimmt. Es kann besagen, dass der Inhaber für Registeränderungen verantwortlich bleibt. Es kann besagen, dass ein nachgelagerter ISP die Kundenzuweisungen kontrolliert.

Es kann besagen, dass die Kundenidentität aus Datenschutzgründen geschwärzt, aber über den Betreiber rückverfolgbar ist. Labels sagen Außenstehenden, wohin sie die falsche Anfrage nicht schicken sollen.

Solche Labels würden häufige Misserfolge reduzieren. Ein Upstream, der eine Route bewertet, wüsste, ob der Ursprungs-AS als Leasingnehmer, Managed-Betreiber oder Inhabernetz agiert. Ein Beschwerdeführer wüsste, ob die öffentliche Missbrauchs-Mailbox den dem Kunden nächstgelegenen Betreiber erreicht. Ein Käufer wüsste, ob nicht offengelegte Wiederverkäufer Ansprüche auf Kundenkontinuität haben könnten. Ein öffentlicher Beschaffer wüsste, ob die Adressbeschaffung eines Subunternehmers von einer zwischengeschalteten Kette abhängt.

Das Register wüsste, ob ein Inhaber, der Vertraulichkeit beansprucht, zumindest seine Verantwortungskette kartiert hat.

Verantwortungs-Labels helfen auch, Leasing von der Sichtbarkeit von Sub-Allokationen zu unterscheiden, ohne Leasing zum Hauptrahmen zu machen. Leasing ist ein Kanal, durch den Intransparenz entsteht. Die relevante Frage ist hier nicht der private Rechtsbehelf oder der kommerzielle Leasingpreis. Sie ist, ob das Leasing oder eine andere kommerzielle Delegation ändert, wer den Adressraum nutzt und wer kontaktiert werden kann. Ein Leasing mit klaren Verantwortungs-Labels kann weniger riskant sein als eine gewöhnliche Hosting-Zuweisung ohne Rückverfolgbarkeit.

Ein Verkauf mit versteckten nachgelagerten Kunden kann problematischer sein als eine transparente zeitlich begrenzte Delegation.

Dieselbe Logik gilt für den Kundendatenschutz. Ein Label kann sagen „Endnutzer datenschutzgeschützt, rückverfolgbar durch den Inhaber“, ohne den Endnutzer zu nennen. Es kann sagen „Strafverfolgungskontakt verfügbar über Inhabereskalation“, ohne sensible Kanäle zu veröffentlichen. Es kann sagen „Kundenliste wird von Wiederverkäufer kontrolliert“, damit Gegenparteien wissen, dass der Inhaber möglicherweise keine unmittelbaren Protokolle hat. Das ist keine Kundenliste. Das ist eine Karte, wer welche betriebliche Pflicht hat.

Vermittler werden wirtschaftlich sicherer, wenn ihre Rollen lesbar sind. Wenn sie sich jeder Rollenoffenlegung widersetzen, werden die Märkte das Schlimmste annehmen. Wenn das Register vollständige Kundenoffenlegung verlangt, werden sich legitime Vermittler widersetzen. Labels bieten eine kostengünstigere Alternative: sichtbare Verantwortung, geschützte Identität und bepreiste Unsicherheit.

Die Abhängigkeit des öffentlichen Sektors macht Intransparenz zu einem Risiko für die staatliche Handlungsfähigkeit

Die Intransparenz von Sub-Allokationen wird gravierender, wenn öffentliche Systeme von der Adresskette abhängen. Ein Ministerium kann Bürgerdienste bei einem lokalen Provider hosten, der Adressen eines regionalen Inhabers nutzt. Ein öffentliches Krankenhaus kann Managed Security von einem Anbieter beziehen, dessen Firewall-Knoten sich in einem geleasten oder sub-allokierten Block befinden. Eine Cybercrime-Einheit der Polizei benötigt nach einem Vorfall möglicherweise Teilnehmer- oder Kundeninformationen. Ein nationales Bildungsnetzwerk kann für Campusse auf nachgelagerte Provider angewiesen sein.

Ein Gericht muss möglicherweise Beweise sichern, während ein Dienst online bleibt. In jedem Fall weiß die öffentliche Stelle möglicherweise nicht, dass ihre Kontinuität von einer mehrschichtigen Adresskette abhängt.

Für gewöhnliche kommerzielle Kunden ist Intransparenz ein Problem der Risikoallokation. Für Kunden des öffentlichen Sektors kann es zu einem Problem der staatlichen Handlungsfähigkeit werden. Ein Steuerportal, das die E-Mail-Zustellbarkeit verliert, weil Reverse-DNS veraltet ist, eine öffentliche Beschaffungsplattform, die blockiert wird, weil benachbarte Adressen missbräuchlich sind, oder ein Notdienstleister, der die Routenautorität nicht nachweisen kann, steht nicht vor einer einfachen IT-Unannehmlichkeit. Die Kosten werden von Bürgern und öffentlichen Einrichtungen getragen, die die versteckte Adressstruktur nicht gewählt haben.

Die Bedürfnisse der Strafverfolgungsbehörden sind ebenfalls spezifisch. Ermittler beginnen oft mit einer IP-Adresse, einem Zeitstempel und einem Port. Wenn das öffentliche Register nur den Inhaber nennt, muss der Ermittler die Kette ablaufen: Inhaber, Wiederverkäufer, Managed-Provider, Kunde, Endnutzer. NAT, CGNAT, VPS-Leasing und kurzzeitiges Hosting machen die Zeit kritisch. Wenn der Inhaber keine Rückverfolgbarkeit pflegt oder der Wiederverkäufer nicht registriert ist, können Rechtshilfeersuchen zu spät oder bei der falschen Partei eintreffen.

Eine zu weitgehende öffentliche Offenlegung ist nicht die Antwort, aber ein strukturierter Eskalationspfad ist es.

AFRINICs Krisengeschichte erhöht die Einsätze, da öffentliche Behörden das Register bereits als Institution betrachten können. Die Berichterstattung über die mauritianische Insolvenzverwaltung beschrieb einen Auftrag zur Aufrechterhaltung des Betriebs und zur Wiederherstellung der Governance, während spätere Berichterstattungen den anhaltenden Gerichtsdruck, versagende Wahlmechanismen, Fragen der Vorstandswiederherstellung, Klagen und Rechtsstreitigkeiten über die Behandlung von Nummernressourcen beschrieben.

In einem solchen Umfeld benötigen öffentliche Nutzer den Nachweis, dass die Adresskontinuität nicht von privaten, nicht registrierten Vereinbarungen abhängt, die bei Rechtsstreitigkeiten oder Governance-Wechseln zusammenbrechen.

Eine Beschaffungsnorm für den öffentlichen Sektor könnte einfach sein. Anbieter, die von AFRINIC verwaltete IPv4-Adressen für öffentliche Dienste nutzen, sollten in der Lage sein, den registrierten Inhaber, das Betriebsnetz, die Routenursprungsautorität, die Reverse-DNS-Kontrolle, die Missbrauchs- und Sicherheitskontakte, die nachgelagerten Verantwortungs-Labels, die Datenschutzvereinbarungen, die Eskalation für Rechtshilfeersuchen und jegliche den Adressraum betreffenden Rechtsstreitigkeiten vorzuweisen. Die öffentliche Version muss nicht jeden Kunden enthüllen.

Die für den Beschaffer bestimmte Akte sollte ausreichend vollständig sein, um Kontinuität und Verantwortung zu untermauern.

Die Abhängigkeit des öffentlichen Sektors verschiebt somit das Datenschutzgleichgewicht. Die Öffentlichkeit braucht nicht jeden Kundennamen. Sie braucht die Gewissheit, dass kritische Dienste eine rückverfolgbare Adressverantwortung haben. Ein Register, das hilft, diese Gewissheit zu schaffen, wird nicht zur Aufsichtsbehörde. Es reduziert das Risiko der öffentlichen Beschaffung in einem Markt, in dem Adressknappheit und institutionelle Instabilität die Adressschicht sichtbar gemacht haben.

Die Wiederherstellung wird unterhalb der Inhaber-Linie beurteilt werden

AFRINIC braucht kein Regime maximaler Transparenz. Es braucht einen Sichtbarkeitspakt, der festlegt, wozu nachgelagerte Sichtbarkeit dient: Einzigartigkeit, Fehlerbehebung, Missbrauchserreichbarkeit, Due Diligence bei der Routenautorität, Reverse-DNS-Konsistenz, gerichtliche Eskalation, Transaktionsvertrauen und Kontinuität für Kunden, die auf knappe IPv4-Adressen angewiesen sind.

Es sollte auch festlegen, wozu Sichtbarkeit nicht dient: zur Veröffentlichung roher Kundenlisten, zur Beurteilung jeder kommerziellen Vereinbarung, zur Bloßstellung sensibler Nutzer oder zur Nutzung von Registrierungsfeldern als Hebel in nicht zusammenhängenden Streitigkeiten.

Der Pakt könnte mit einigen Registrierungstypen beginnen. Formale Sub-Allokationen an oder über der politischen Mindestschwelle sollten öffentlich mit der Identität des nachgelagerten ISP, den Kontakten, dem Status, dem Validierungsdatum und der Eskalation zum Inhaber sichtbar sein. Zuweisungen an Endnutzer, die öffentliche betriebliche Verantwortung erfordern, sollten den Endnutzer oder einen datenschutzgeschützten Proxy mit klaren Rollen-Labels identifizieren.

Kleinere Kundenbereiche unterhalb der öffentlichen Sub-Allokationsschwellen müssen nicht öffentlich benannt werden, aber die Inhaber sollten die Rückverfolgbarkeit aufrechterhalten und Verantwortungs-Labels veröffentlichen, wenn Missbrauch, Routing, Reverse-DNS oder Rechtshilfeersuchen die Rolle bedeutsam machen.

Jede Registrierung sollte einen Nachweis-Status tragen: vom Register validiert, vom Inhaber attestiert, von der Gegenpartei bestätigt, durch Routing beobachtet, aus Datenschutzgründen geschwärzt, aber rückverfolgbar, veraltet, bestritten oder durch Gerichtsbeschluss eingeschränkt. Diese Labels würden verhindern, dass ein öffentliches Feld vorgibt, sicherer zu sein, als es ist. Sie würden es den Märkten auch ermöglichen, bessere Nachweise zu belohnen.

Ein Block mit aktueller nachgelagerter Verantwortung sollte billiger zu routen, zu transferieren, zu leasen, zu finanzieren und zu erwerben sein als ein Block mit veralteten Daten, der nur den Inhaber enthält.

Der Pakt sollte Validierungszyklen enthalten. Kontakte und Rollen-Labels sollten verfallen, wenn sie nicht aktualisiert werden. Materielle Änderungen, wie ein neuer nachgelagerter ISP, ein neuer Ursprungs-AS, eine Übernahme durch einen Managed Service, ein Wechsel der Reverse-DNS-Delegation oder eine bedeutende Kundenmigration, sollten Aktualisierungspflichten auslösen. Das Versäumnis der Aktualisierung sollte zunächst sichtbare Unsicherheit und Korrekturverfahren hervorrufen, nicht einen sofortigen Eingriff in die Ressourcen.

Schwerwiegende Abhilfen sollten falschen Angaben, nicht rückverfolgbaren Hochrisikonutzungen, Betrug, Gerichtsbeschlüssen oder der wiederholten Weigerung, minimale Verantwortung aufrechtzuerhalten, vorbehalten bleiben.

Es sollte auch eine private Nachweisschicht geben. Inhaber sollten Aufzeichnungen über Kundenzuweisungen, Autorisierungen, Wiederverkäuferverträge, Missbrauchseskalation, Routing-Autorisierungen und Datenschutzbegründungen aufbewahren. AFRINIC sollte nicht standardmäßig jedes Dokument benötigen. Es sollte in der Lage sein, verhältnismäßige Nachweise anzufordern, wenn eine formale Sub-Allokation, eine Abhängigkeit des öffentlichen Sektors, ein Transfer, ein Rechtsstreit, ein größeres Missbrauchsmuster oder ein Reverse-DNS/RPKI-Konflikt die nachgelagerte Rolle bedeutsam macht.

Die Anforderung sollte spezifisch, zeitlich begrenzt und enger sein als eine Prüfung aller Kunden, es sei denn, die Beweise rechtfertigen mehr.

Der Pakt sollte Korrekturen belohnen. Wenn ein Inhaber freiwillig eine veraltete nachgelagerte Verantwortung aktualisiert, sollte die Standardreaktion die Korrektur der Registrierung sein, nicht eine breit angelegte Durchsetzung. Andernfalls werden sich rationale Inhaber verstecken. Betrug und vorsätzliche Falschangaben erfordern eine andere Behandlung, aber gewöhnliche Korrekturen sollten gefördert werden. Ein Register, das sich von einer Geschichte der Registrierungsverfälschung erholt, muss entschieden gegen Falschheit und sicher für die Wahrheit sein.

Die öffentliche Wiederherstellung von AFRINIC wird oft durch Vorstände, Budgets, Insolvenzverwaltung, Gerichtsbeschlüsse, ICANN-Intervention und institutionelle Legitimität diskutiert. Diese Fragen sind real. Aber für viele Betreiber wird der praktische Test unterhalb der Inhaber-Linie liegen. Kann ein Kunde, ein Upstream, ein Käufer, eine öffentliche Stelle, eine Strafverfolgungsbehörde oder ein Missbrauchsmelder verstehen, wer für eine bestimmte Nutzung knapper IPv4-Adressen verantwortlich ist, wenn diese Nutzung nicht vom registrierten Inhaber ausgeht? Wenn nicht, bleibt die Wiederherstellung der Governance zu abstrakt.

Das Register kann rechtlich bewahrt werden und dennoch die nachgelagerte Verantwortung undurchsichtig lassen. Es kann einen Vorstand wählen und nur die Inhaber-Einträge offenlegen. Es kann RDAP, WHOIS, Reverse-DNS, IRR und RPKI betreiben, ohne diese Oberflächen zu einer Verantwortungskarte zu verknüpfen. Es kann Richtlinien verkünden und dennoch die Märkte raten lassen, ob ein geroutetes Präfix vom Inhaber, von einem Wiederverkäufer betrieben, geleast, sub-allokiert, zugewiesen, datenschutzgeschützt oder bestritten ist. In einem knappen Markt ist dieses Raten teuer.

AFRINICs jüngere Geschichte gibt ihm sowohl einen Grund als auch eine Verpflichtung, es besser zu machen. Berichte über Adressdiebstahl zeigen die Gefahr schwacher Registrierungsautorität. Die Cloud-Innovation-Auseinandersetzung zeigt die Gefahr, wenn undurchsichtige kommerzielle Delegation und weites Registerermessen kollidieren. Die Insolvenzverwaltung zeigt die Notwendigkeit von Kontinuität, wenn die Unternehmensführung versagt. Die Wahldiskontinuität zeigt, dass Mitgliederautorität und institutionelle Legitimität selbst zu Marktfakten werden können.

Andauernde Rechtsstreitigkeiten zeigen, dass öffentliche Behauptungen über Leasing, Kommerzialisierung und gerichtliche Anerkennung das Vertrauen erschüttern können. Die Sichtbarkeit von Sub-Allokationen wird all dies nicht lösen. Sie wird eine bedeutende Unsicherheit reduzieren, die sonst den Rest anheizt.

Die richtige institutionelle Haltung ist bescheiden. AFRINIC sollte nicht vorgeben, jeden Kunden zu kennen. Es sollte nicht zum wirtschaftlichen Regulierer jedes nachgelagerten Dienstes werden. Es sollte keine Kundenlisten als Ersatz für klare Politik verlangen. Es sollte Sichtbarkeit nicht nutzen, um unpopuläre kommerzielle Vereinbarungen ohne angemessene Schutzvorkehrungen zu bestrafen. Aber es sollte darauf bestehen, dass registrierte Inhaber die nachgelagerte Verantwortung auf der Ebene erklären und nachweisen können, auf der sich Dritte auf die Adressregistrierung stützen.

Das ist der Unterschied zwischen einem Register und einem privaten Nebelfeld.

Der Gewinn ist praktisch: gezieltere Missbrauchsmeldungen, weniger grobmaschiges Filtern, sauberere Reverse-DNS- und RPKI-Änderungen, eine Due Diligence, die weniger von Brokern abhängt, solidere öffentliche Beschaffung und geschützte Kunden mit verantwortlicher Rückverfolgbarkeit. Die Märkte würden geprüfte Verantwortung anstelle von Gerüchten bepreisen.

Der Pakt würde auch die Inhaber disziplinieren. Ein Inhaber, der knappe IPv4-Kapazität verleast, zuweist, sub-allokiert oder delegiert, sollte nicht nur sagen können: Das öffentliche Register nennt mich, also muss mir jeder vertrauen. Der Inhaber ist der Anker, nicht die ganze Geschichte. Wenn er von der nachgelagerten Nutzung profitiert, Kunden schützt oder Vermittler einsetzt, muss er wissen, wer handeln kann. Wenn er das nicht kann, hat der Markt Recht, den Block abzuschreiben.

AFRINIC ist eine Fallstudie, weil das afrikanische Register den vollständigen Zusammenprall von Knappheit, Registrierungsintegrität, kommerzieller Delegation, Rechtsstreitigkeiten und institutioneller Wiederherstellung erlebt hat. Die Lehre ist nicht, dass jeder nachgelagerte Nutzer öffentlich sein sollte. Sie ist, dass Verantwortung nicht privat bleiben kann, wenn die Kosten ihrer Abwesenheit öffentlich sind. Ein nützliches Register legt nicht die Kundenliste offen. Es legt genug von der Verantwortungskette offen, damit Außenstehende handeln können, ohne sich dem Kampf anzuschließen.