IPv4 hat einen Lebenszyklus: Was Registry-Daten zeigen können und was nicht
Ein verständlicher Leitfaden zum IPv4-Lebenszyklus: Transfers, Wiederverwendung, Routing, RPKI, Vermietung, Historie und die Grenzen von Registry-Daten.
Der eingetragene Inhaber, der betriebliche Nutzer, die Route und die Historie sind unterschiedliche Sichtweisen auf dieselbe Adressressource. Kein einzelner Datensatz erzählt die ganze Geschichte.
IPv4-Knappheit ist längst nicht mehr die ganze Geschichte. Die nützlichere Frage lautet, was mit einem Adressblock geschieht, nachdem er bereits zugeteilt wurde.
Ein Block kann übertragen, aufgeteilt, von einem anderen Netzwerk angekündigt, durch eine andere Routing-Autorisierung abgedeckt, an einen anderen Betreiber vermietet und erneut übertragen werden. Die Nummer kann gleich bleiben, während sich die Organisationen, Netzwerke, geografischen Bezüge und Nachweise um sie herum ändern.
Dieser Artikel zeigt Ihnen, wie Sie solche Veränderungen einordnen können. Er trennt vier Fragen, die häufig miteinander vermischt werden: Wer ist in der Registry eingetragen, wer betreibt die Ressource, welche ASN kündigt ihre Route als Ursprung an, und welche Nachweise erklären, ob der aktuelle Zustand autorisiert ist und die Kontinuität gewahrt bleibt?
Mit vier unterschiedlichen Fragen beginnen
Ein Registry-Eintrag beantwortet eine Registry-Frage: Welche Organisation wird nach den Regeln der Registry für diese Ressource anerkannt? Für sich allein beantwortet er nicht, wer die Ressource heute nutzt, wohin der Datenverkehr geroutet wird oder welches Netzwerk berechtigt ist, sie als Ursprung anzukündigen.
- Registry-Zustand: der eingetragene Inhaber und seine Beziehung zur Ressource.
- Betriebszustand: die Organisation, der Anbieter oder der Kunde, der den Block tatsächlich nutzt.
- Routing-Zustand: die ASN, die derzeit in BGP als Ursprung des Präfixes beobachtet wird.
- Autorisierung und Historie: die ROAs, IRR-Objekte, Transfernachweise und Änderungshistorie, die den Zustand erklären.
Diese Ebenen können sich gemeinsam ändern, müssen es aber nicht. Sie auseinanderzuhalten ist der erste Schritt, um die Daten zu verstehen.
Was die Daten von 2026 zeigen
Die Zahlen für 2026 in diesem Artikel sind Beobachtungen aus dem bisherigen Verlauf eines noch nicht abgeschlossenen Jahres. Die von RIPE NCC veröffentlichten Monatszahlen für Januar bis Juli ergeben in dessen Dienstleistungsregion insgesamt rund 16,72 Millionen übertragene IPv4-Adressen. Ein einziger Monat mit hohem Volumen kann die Summe verändern. Das belegt also anhaltende Bewegung und ist keine Prognose für das Gesamtjahr.
Ebenso wichtig ist der längere Betrachtungszeitraum. Die Analyse globaler RIR-Daten von APNIC erfasste für 2025 insgesamt 33,4 Millionen IPv4-Adressen in 5.619 registrierten Transfertransaktionen. Sie schätzte, dass seit 2012 etwa 342 Millionen Adressen in den Transferprotokollen der RIRs aufgetaucht waren. Manche Adressen erscheinen mehr als einmal. Das ist bereits ein Hinweis darauf, dass eine Adresse mehrere registrierte Übergänge durchlaufen kann.
Die Transferdokumentation erzählt somit von Bewegung nach der Erschöpfung des freien Vorrats. Sie erzählt nicht die ganze Geschichte der aktuellen Nutzung.
Aus Zuteilung ist Wiederverwendung geworden
Als ungenutzter Adressraum leicht zu bekommen war, war die Vorstellung einfach: Eine Registry teilt einen Block zu, und ein Netzwerk setzt ihn ein. In einem ausgereiften IPv4-Markt kann ein bestehender Block stattdessen von einer Organisation zur nächsten wechseln und ein neues betriebliches Leben beginnen.
Ein zwanzig Jahre altes Präfix kann heute einen anderen Inhaber, Anbieter, eine andere Ursprungs-ASN, Reverse-DNS-Regelung, einen anderen Missbrauchskontakt und eine andere RPKI-Konfiguration haben als bei seiner ursprünglichen Zuteilung. Die Adressnummer bleibt stabil, die Infrastruktur um sie herum jedoch nicht.
Deshalb braucht der aktuelle Eintrag seine Historie. Der heutige Inhaber ist wichtig, aber er markiert nur einen Zeitpunkt im Leben der Ressource.
Aus einem großen Block können mehrere Historien werden
Transfers können auch verändern, welche Einheit verwaltet wird. Ein Block, der als /16 begann, kann später durch kleinere Ressourcen wie /18, /18, /19 und /20 abgebildet sein. Jedes daraus hervorgehende Präfix kann einen eigenen Inhaber, eine eigene Route, ROA, Reverse-DNS-Konfiguration, einen eigenen betrieblichen Nutzer und eine spätere Transferhistorie erhalten.
Veröffentlichte Transferprotokolle sind nützlich, weil sie die erfasste Ressource und den Übergang bewahren. Sie sollten als Historie von Zustandsänderungen gelesen werden, nicht als Zusicherung, dass die ursprüngliche Zuteilung die einzige sinnvolle betriebliche Einheit bleibt.
Registry-Geografie ist nicht Routing-Geografie
Eine Adresse kann zwischen Registry-Regionen wechseln, ohne dass die Datenpakete sofort in ein anderes Land gelangen. Ein Registry-Transfer ändert die anerkannte administrative Beziehung. BGP beschreibt, wie Erreichbarkeit angekündigt wird. IP-Geolokalisierung wiederum beschreibt eine andere Schlussfolgerung.
Diese drei Beschreibungen können in unterschiedliche Richtungen weisen, ohne dass eine davon falsch sein muss. Wer ein in der Registry verzeichnetes Land, den Hauptsitz eines Unternehmens, einen Rechenzentrumsstandort und einen Routenursprung als austauschbar behandelt, erzeugt falsche Gewissheit.
Miete und Delegation schaffen eine weitere Ebene
Eine Miete oder betriebliche Delegation kann einer anderen Organisation erlauben, einen Block zu nutzen und anzukündigen, während der eingetragene Inhaber unverändert bleibt. Ein Transferprotokoll zeigt möglicherweise keinen neuen Inhaber, obwohl sich betrieblicher Nutzer, Anbieter, Reverse DNS, Kontakte und Reputation geändert haben.
Deshalb messen Transferdaten erfasste Registry-Übergänge und nicht jede Nutzungsänderung. Eine vollständige Untersuchung benötigt Registry-Eintrag, betriebliche Autorisierung und Routing-Nachweise gemeinsam.
RPKI verleiht der Route einen eigenen Sicherheitszustand
Wenn sich die vorgesehene Ursprungs-ASN ändert, sollten die betreffenden Route Origin Authorizations überprüft werden. Eine Registry kann den Inhaber korrekt erfassen, während die relevante ROA noch eine alte Routing-Autorisierung widerspiegelt. Umgekehrt beweist eine gültige ROA nicht, dass die Route aktuell angekündigt wird.
Lesen Sie die Ebenen der Reihe nach: Die Registry benennt die anerkannte Beziehung, RPKI benennt eine Autorisierung, und BGP zeigt die Route, die Netzwerke beobachten. Jede Ebene beantwortet eine andere Frage.
Was Registry-Daten nicht beweisen können
Ein Transfernachweis legt weder den Transaktionspreis noch den geschäftlichen Grund der Änderung, jedes Mietverhältnis, jede Delegation oder die vollständige Routing-Historie offen. Zudem veröffentlichen RIRs Daten mit unterschiedlichen Definitionen und zu unterschiedlichen Zeitpunkten.
Die sorgfältige Schlussfolgerung ist deshalb enger gefasst und belastbarer: Registry-Daten bieten eine überprüfte Sicht auf wichtige erfasste Zustandsübergänge. BGP, RPKI, IRR-Einträge, Verträge und Betriebsprotokolle liefern andere Sichtweisen. Verlässlichkeit entsteht durch ihren Vergleich und nicht dadurch, dass ein einzelner Datensatz jede Frage beantworten soll.
Eine praktische Lebenszyklusdokumentation
Führen Sie für ein Präfix, das für einen laufenden Geschäftsbetrieb wichtig ist, eine Dokumentation, die ein anderer Betreiber überprüfen kann:
- aktueller Registry-Inhaber und relevante Transferhistorie;
- aktueller betrieblicher Nutzer, Anbieter und Kontakte;
- Ursprungs-ASN und historische Routing-Änderungen;
- ROAs, IRR-Objekte und Zuständigkeit für Reverse DNS;
- wesentliche Änderungen, Genehmigungen und Kontrollnachweise; und
- der Kontinuitäts- oder Ausstiegsplan für den Fall, dass sich die Beziehung erneut ändert.
Das ist Lebenszyklusmanagement. Es ist die praktische Antwort auf ein Internet, in dem alte Kennungen immer wieder neue Organisationen und Netzwerke durchlaufen.
Weiter durch die drei Ebenen
Der nächste Artikel verfolgt die Registry-Ebene über RIR-Grenzen hinweg. Der dritte widmet sich einer anderen Art von Veränderung: Ein Präfix behält seine Nummer, während sich seine BGP-Ursprungs-ASN ändert.