Providerunabhängige IP-Adressen: Provider wechseln, IPv4- und IPv6-Adressen behalten

Warum eine feste IP-Adresse allein nicht genügt

Eine statische öffentliche IP-Adresse ist nicht automatisch eine providerunabhängige Adresse.

Bei einem üblichen Internetanschluss stellt der Provider Adressen aus seinem eigenen Bestand bereit, dem PA-Adressraum. Der Provider kündigt diese Adressen innerhalb eines größeren gemeinsamen Adressblocks im Internet an.

Im laufenden Betrieb funktioniert das gut. Die Bindung zeigt sich erst beim Anbieterwechsel: Eine feste Adresse aus dem Bestand des bisherigen Providers ist dem Provider zugeteilt, nicht dem Unternehmen. Die RIPE-Richtlinien unterscheiden deshalb klar zwischen providerbezogenen Zuteilungen und PI-Adressraum für Endnutzerorganisationen.

Die Frage an den Provider lautet also nicht: „Bekommen wir eine feste öffentliche IP-Adresse?“ Sondern: „Ist der Adressblock unserer Organisation unabhängig vom Internetprovider zugeteilt und über einen anderen Anbieter weiter nutzbar?“

Das Prinzip: providerunabhängige IP-Adressen vom Internetzugang trennen

Bei providerunabhängigen Ressourcen trennen wir zwei Aufgaben:

• Die Zuteilung und Registrierung legen fest, welche Organisation den Adressblock nutzen darf.
• Die Internetanbindung stellt sicher, dass dieser Adressblock weltweit erreichbar ist.

Die Zuteilung für IPv6 PI läuft über eine Sponsoring LIR, also eine Mitgliedsorganisation des RIPE NCC, die die Ressource registriert und betreut. Das kann der Internetprovider sein, muss es aber nicht. Die Mindestgröße einer IPv6-PI-Zuteilung ist ein /48.

IPv6 PI ist für die eigene Infrastruktur gedacht. Eigene Präfixe an andere Organisationen weiterzuteilen ist nicht zulässig. Einzelne Adressen auf einem selbst betriebenen Netzsegment, etwa für Besucher oder Geräte Dritter, gelten nach der Richtlinie nicht als Weiterzuteilung. Wer eigenständige Kundennetze versorgen will, braucht ein anderes Ressourcenmodell.

Der Sponsor übernimmt die administrative Betreuung, nicht die Internetleitung. Auch ein Sponsorwechsel ist vorgesehen; Adressverwaltung und Internetanbindung müssen also nicht beim selben Dienstleister liegen.

„Eigener Adressblock“ heißt allerdings nicht Eigentum wie bei einem gekauften Gegenstand. Gemeint ist ein registriertes Nutzungsrecht, das an Richtlinien und vertragliche Anforderungen gebunden ist. Wer diese Voraussetzungen nicht mehr erfüllt, verliert die Unabhängigkeit wieder.

Der wichtigste Vorteil: weniger Änderungen beim Providerwechsel

Mit eigenem Adressblock verschiebt sich die Kernaufgabe eines Providerwechsels: Statt die öffentliche Adressierung der Dienste auszutauschen, machen wir das bestehende Präfix über den neuen Anschluss erreichbar.

Dafür wird das Netz per BGP angekündigt, entweder vom Unternehmen selbst mit eigener ASN oder von einem dafür autorisierten Provider.

Eine eigene ASN ist also kein Muss: Ein autorisierter Provider kann das Präfix über sein autonomes System ankündigen. Für eine eigene ASN verlangt die RIPE-Richtlinie Multihoming und eine eigenständige externe Routing-Policy, die bei der Beantragung dokumentiert wird.

Aus dieser Trennung ergeben sich mehrere praktische Vorteile.

Öffentliche Dienste behalten ihre Adressen

Bleiben die öffentlichen IP-Adressen gleich, entfällt für unverändert betriebene Dienste der adressbedingte Teil der Migration. Das betrifft beispielsweise:

• Öffentliche Webanwendungen und APIs.
• VPN-Gateways für Standorte und Geschäftspartner.
• Eingehende NAT-Regeln auf den Firewalls, die öffentliche Zieladressen auf interne Server übersetzen.
• Öffentlich erreichbare Mail- und Kommunikationssysteme.
• A- und AAAA-Records in den öffentlichen DNS-Zonen.

Das heißt nicht, dass ein Providerwechsel ohne Konfigurationsänderungen auskommt. Es heißt, dass die öffentliche Adressierung bleibt, sofern der neue Provider die Präfixe unterstützt und die Ankündigung sauber eingerichtet ist.

Externe IP-Freischaltungen können bestehen bleiben

Viele Unternehmensverbindungen hängen nicht nur von DNS-Namen ab. Geschäftspartner und externe Dienste erlauben Zugriffe häufig anhand bestimmter Quell-IP-Adressen.

Bleiben die für ausgehende Verbindungen verwendeten öffentlichen Adressen erhalten, müssen solche Freischaltungen nicht allein wegen eines Providerwechsels geändert werden. Dasselbe gilt für VPN-Gegenstellen, deren Konfiguration auf eine feste öffentliche Zieladresse verweist.

Das funktioniert nur, wenn nach der Umstellung tatsächlich dieselben Quell- und Zieladressen verwendet werden. Ein neuer Anschluss allein garantiert das nicht; NAT, Routing und die Nutzung des eigenen Präfixes gehören deshalb ins Migrationskonzept.

IPv6-Netze müssen nicht wegen des Providers neu nummeriert werden

Bei IPv6 kann die Providerbindung besonders weit reichen, weil öffentliche Adressen unmittelbar auf Systemen und in internen Netzsegmenten verwendet werden können.

Ein eigenes IPv6-PI-Präfix macht den internen Adressplan unabhängig vom Internetzugang. Ein /48 bietet Platz für 65.536 /64-Subnetze; ob mehr nötig ist, entscheidet der tatsächliche Bedarf nach den Zuteilungsrichtlinien. Den Adressplan führen wir in NetBox als Source-of-Truth, damit Präfixe, Standorte und Zuständigkeiten an einer Stelle dokumentiert sind.

Damit richtet sich die IPv6-Adressplanung an der Unternehmensstruktur aus, nicht am Lebenszyklus eines Providervertrags.

Mehr als Portabilität: BGP Multihoming mit mehreren Providern

Ein eigener Adressblock ist auch die Grundlage für Multihoming, also die gleichzeitige Anbindung an mehrere Internetprovider.

Die folgende Architektur zeigt zwei Internetprovider, die das Unternehmensnetz mit eigenem Adressraum und eigener ASN an das Internet anbinden:

Dieselben Unternehmenspräfixe werden dabei über mehrere Upstream-Provider angekündigt; BGP wählt anhand der verfügbaren Routen und der Routing-Policy den Weg. Wer Multihoming selbst betreibt, braucht BGP-Sessions zu jedem Provider, saubere Filter und eine konsistente Autorisierung der Präfixankündigungen.

Redundanz ohne unterschiedliche Dienstadressen

Der wesentliche architektonische Vorteil: Die öffentlich erreichbaren Dienste müssen nicht für jeden Provider andere Adressen erhalten.

Fällt eine Anbindung aus, bleibt derselbe Adressraum über die andere erreichbar. Unterbrechungsfrei ist die Umschaltung damit aber nicht automatisch: BGP-Konvergenz, Fehlererkennung (etwa per BFD) und das Verhalten zustandsbehafteter Firewalls und NAT-Systeme planen und testen wir separat.

Ein portabler Adressblock löst die Adressabhängigkeit. Nicht automatisch alle Hochverfügbarkeitsprobleme.

Providerwechsel lassen sich kontrollierter vorbereiten

Auch ohne dauerhaftes Multihoming lohnt sich eine zeitweise parallele Anbindung: Wir richten den neuen Provider ein, solange der alte Anschluss noch läuft.

Unser Migrationsablauf:

1. Unterstützung des eigenen IPv4- und IPv6-Präfixes mit dem neuen Provider verbindlich klären.
2. BGP- und Routingparameter abstimmen.
3. Präfixfilter und erforderliche Routingregistrierungen vorbereiten.
4. Routingautorisierungen prüfen und gegebenenfalls für das neue ankündigende autonome System ergänzen.
5. Erreichbarkeit sowie ein- und ausgehende Verkehrspfade testen.
6. Erst nach erfolgreicher Prüfung die alte Anbindung zurückbauen.

Für die Autorisierung ist RPKI entscheidend. Eine ROA legt fest, welche Origin-ASN ein Präfix ankündigen darf und bis zu welcher maximalen Präfixlänge.

RPKI-basierte Route Origin Validation prüft den Ursprung einer Route, nicht den gesamten BGP-Pfad. Eine passende Autorisierung ergibt den Status „Valid“. Eine durch vorhandene Autorisierungen nicht gedeckte Origin-ASN oder Präfixlänge kann „Invalid“ ergeben. Gibt es keine abdeckende Autorisierung, lautet der Status „NotFound“. Wie ein Netz mit diesen Ergebnissen umgeht, bestimmt seine Routingrichtlinie; eine fehlende ROA bedeutet deshalb nicht automatisch eine ungültige Route.

Kündigt das autonome System des Providers an, zählt die Reihenfolge: Die neue Origin-ASN muss in der ROA stehen, bevor sie das Präfix ankündigt. Sonst verwerfen viele Netze mit RPKI-Validierung die Route als „Invalid“.

IPv4 und IPv6: gleiche Zielsetzung, unterschiedliche Beschaffung

Die Idee ist bei beiden Protokollen gleich: Der Adressraum soll unabhängig vom Internetprovider nutzbar sein. Die Beschaffung unterscheidet sich jedoch deutlich.

Auch IPv4 PI ist weiterhin möglich, aber nicht mehr neu vom RIPE NCC. Der Weg führt über bestehende Ressourcen: In der Praxis kaufen Unternehmen einen Block auf dem IPv4-Transfermarkt und lassen ihn per registriertem Transfer beim RIPE NCC auf sich übertragen. Ein Kaufvertrag allein genügt nicht; erst der registrierte Transfer überträgt das Nutzungsrecht. Die administrative Betreuung übernimmt danach eine Sponsoring LIR. Der Kauf ist der typische, aber nicht der einzige Weg; auch bei einer Unternehmensübernahme wird übertragen.

Zur Größenordnung: Ein /24 kostet auf dem Transfermarkt derzeit einmalig etwa 5.000 bis 8.000 Euro, zuzüglich Makler- und Transfergebühren. Übertragener IPv4-Adressraum darf nach der Transfer-Richtlinie des RIPE NCC 24 Monate lang nicht weiter übertragen werden. Wer einen Block kauft, plant ihn also langfristig ein.

Ein IPv4-/24 enthält 256 Adressen. Entscheidend ist aber nicht nur die Anzahl: Ein kleinerer Block kann zwar registriert sein, als eigenständig angekündigtes Netz jedoch an den Filtern anderer Internetbetreiber scheitern.

Umgekehrt bedeutet ein /24 oder IPv6-/48 keine automatische Erreichbarkeitsgarantie. Providerunterstützung, Registrierung und Routing müssen zusammenpassen. Die genannten Präfixgrenzen sind verbreitete betriebliche Filtergrenzen, keine universelle Regel für alle Internetnetze. Bei mehreren Standorten muss außerdem geplant werden, welche Präfixe an welchem Standort angekündigt werden: Eine Aufteilung eines IPv6-/48 in längere Präfixe garantiert keine weltweit akzeptierten Einzelankündigungen.

Für IPv4 empfehlen wir deshalb, nicht pauschal „neue PI-Adressen“ zu bestellen, sondern zuerst Ressourcenstatus und Beschaffungsmodell zu prüfen. Neben dem Transfer bestehender PI-Ressourcen kann eine eigene LIR-Struktur mit einer eigenen Allocation infrage kommen. Eine Allocation ist ein an eine Internetregistrierungsstelle vergebener Adressbestand und nicht dasselbe wie eine PI-Zuteilung an einen Endnutzer. Auch ein auf die eigene LIR registrierter PA-Adressbestand kann unabhängig vom gewählten Internettransit genutzt werden; er ist nicht mit einer PA-Zuteilung aus dem Adressbestand eines fremden Anschlussproviders gleichzusetzen.

Für berechtigte LIRs sieht die IPv4-Richtlinie außerdem eine Warteliste für eine /24-Allocation vor. Die Summe der vom RIPE NCC unter dieser Regelung vergebenen Allocations ist auf 256 Adressen je LIR begrenzt; eine Wartezeit wird nicht garantiert. Eine eigene LIR-Mitgliedschaft bietet daher keinen Anspruch auf sofort verfügbare IPv4-Adressen.

Was für den Betrieb erforderlich ist

Providerunabhängigkeit reduziert die Bindung an einen Anschlussanbieter. Dafür liegt die Verantwortung für die eigenen Internetressourcen jetzt beim Unternehmen selbst.

Ein Provider, der eigene Präfixe unterstützt

Nicht jeder Internetanschluss eignet sich dafür. Vor Vertragsabschluss klären wir mit dem Provider ausdrücklich:

• Werden kundeneigene IPv4- und IPv6-Präfixe unterstützt?
• Ist eine BGP-Anbindung möglich?
• Wer übernimmt die Ankündigung, und welche ASN erscheint als Origin-ASN?
• Welche Registrierungen und Autorisierungen verlangt der Provider?
• Wie werden Redundanz, Störungen und Änderungen abgewickelt?

Die bloße Zuteilung eines Adressblocks stellt noch keine Internetanbindung her; die technische Umsetzung stimmen wir mit dem Upstream-Provider ab.

Zum Betriebsübergang gehören außerdem Reverse-DNS-Delegationen, Kontakt- und Registrierungsdaten und gegebenenfalls route- und route6-Objekte in einer IRR, aus denen viele Provider ihre Präfixfilter erzeugen. Die Anforderungen klären wir vorab mit dem neuen Anbieter.

Saubere Routingautorisierung

Für den Betrieb der RPKI-Autorisierungen gilt:

• Die ROAs müssen zu den tatsächlich verwendeten Origin-ASNs passen.
• Bei einem Wechsel des ankündigenden Provider-Netzes sind die Autorisierungen anzupassen.
• Bei mehreren autorisierten Origin-ASNs müssen alle beabsichtigten Ankündigungen abgedeckt sein.
• RPKI ergänzt die Routingabsicherung, ersetzt aber keine sauberen BGP-Filter.

Kontrollierte BGP-Richtlinien

Das Unternehmensnetz darf weder fremde Präfixe noch zwischen zwei Upstream-Providern gelernte Routen weiterverteilen, sonst wird es ungewollt zum Transitnetz. Exportfilter lassen deshalb nur die eigenen Präfixe zu; Importfilter und Maximum-Prefix-Limits gehören ebenso zum Betriebskonzept.

Ein eigener Adressblock ist damit mehr als ein Eintrag in der RIPE-Datenbank. Er wird Teil der betriebenen Infrastruktur: Präfixe, ASN, ROAs und IRR-Objekte dokumentieren wir in NetBox, BGP-Sessions und Präfix-Erreichbarkeit überwacht CheckMK, und die BGP-Ereignisse der Edge-Router laufen in Graylog zusammen.

Wirtschaftlicher Nutzen: weniger Abhängigkeit, planbarere Migrationen

Der wirtschaftliche Mehrwert liegt vor allem darin, dass Internetzugang und öffentliche Adressierung nicht mehr als untrennbares Paket betrachtet werden müssen.

Konkret heißt das: Providerangebote lassen sich nach Preis und Leistung vergleichen, ohne jede Entscheidung mit einer kompletten Umadressierung zu verbinden. Migrationen kommen mit deutlich weniger Changes an eigenen Diensten und bei externen Gegenstellen aus. Und eine zweite Anbindung lässt sich ergänzen, ohne dieselben Dienste unter zusätzlichen Adressen zu veröffentlichen.

Dem stehen Transferkosten, die laufende Betreuung durch die Sponsoring LIR und der Betrieb der Routing-Infrastruktur gegenüber. Die Rechnung ist trotzdem schnell gemacht: Ein /24 kostet einmalig einen mittleren vierstelligen Euro-Betrag. Ohne eigenen Adressraum kostet jeder Providerwechsel eine erneute Umadressierung, dazu kommt das Risiko, dass eine vergessene IP-Freischaltung bei einem Partner eine geschäftskritische Schnittstelle stilllegt.

IPv4 und IPv6 rechnen wir dabei getrennt: IPv6 PI kostet vor allem Betreuung, IPv4 zusätzlich den Blockpreis.

Fazit: stabile Adressen, austauschbare Anbindungen

Providerunabhängige IP-Adressen entkoppeln die öffentliche Adressierung eines Unternehmens vom Internetzugang. Das ist die Grundlage für Providerwechsel, parallele Anbindungen und eine Netzwerkplanung, die länger hält als ein Providervertrag.

Voraussetzung ist, dass Registrierung, Nutzungsrecht und Routing zusammenpassen: Der Adressblock muss tatsächlich unabhängig nutzbar sein, und der neue Provider muss ihn korrekt ankündigen können. Für IPv6 PI gibt es eine neue Zuteilung, für IPv4 führt der Weg über einen registrierten Transfer.

So wird ein Providerwechsel vor allem zu einer Änderung der Anbindung und nicht zu einer umfassenden Änderung der öffentlichen IP-Adressen.

Häufige Fragen zu providerunabhängigen IP-Adressen

Glossar

PI-Adressraum (Provider Independent)

Providerunabhängiger IP-Adressraum, der einer Organisation unabhängig von ihrem Internetprovider zugeteilt ist. IPv6 PI kann neu beantragt werden, IPv4 PI wird per registriertem Transfer übernommen.

PA-Adressraum (Provider Aggregatable)

Adressraum aus dem Bestand eines Providers, den dieser innerhalb eines größeren gemeinsamen Präfixes ankündigt. Die Zuteilung ist an den Provider gebunden.

BGP (Border Gateway Protocol)

Routingprotokoll, mit dem autonome Systeme ihre Erreichbarkeit austauschen. Darüber wird der eigene Adressblock über einen oder mehrere Provider angekündigt.

AS / ASN (Autonomous System Number)

Ein AS ist ein Netz oder eine Gruppe von Netzen unter gemeinsamer Routingverwaltung; die ASN ist seine eindeutige Nummer im BGP-Routing.

Origin-ASN

Die ASN des autonomen Systems, das ein Präfix ursprünglich in BGP ankündigt: das eigene Unternehmensnetz oder ein autorisierter Provider.

RPKI (Resource Public Key Infrastructure)

Infrastruktur zur kryptografischen Absicherung von Routingautorisierungen. Sie bestätigt den Ursprung einer Route, nicht deren gesamten Weg.

ROA (Route Origin Authorization)

Signierte Autorisierung in der RPKI: welche ASN ein Präfix ankündigen darf und bis zu welcher Präfixlänge.

Route Origin Validation

Prüfung einer empfangenen Route gegen die ROAs mit den Ergebnissen „Valid“, „Invalid“ oder „NotFound“.

RIPE NCC

Regionale Internetregistrierungsstelle für Europa, den Nahen Osten und Teile Zentralasiens. Vergibt und registriert IP-Adressen und ASNs.

LIR / Sponsoring LIR (Local Internet Registry)

Lokale Registrierungsstelle einer RIPE-NCC-Mitgliedsorganisation. Als Sponsoring LIR betreut sie die PI-Ressourcen einer Endnutzerorganisation, ohne zwingend deren Provider zu sein.

Allocation

Adressbestand, der an eine LIR zur weiteren Nutzung und Verteilung vergeben wird. Nicht dasselbe wie eine PI-Zuteilung an einen Endnutzer.

IRR (Internet Routing Registry)

Routingregister mit route- und route6-Objekten, aus denen Provider ihre Präfixfilter erzeugen. Ergänzt RPKI, ersetzt sie aber nicht.

IXP (Internet Exchange Point)

Internetknoten, an dem Netze Datenverkehr direkt miteinander austauschen.

Multihoming

Gleichzeitige Anbindung eines Netzes an mehrere Internetprovider.

Upstream-Provider

Anbieter, der das Unternehmensnetz mit weiteren Netzen im Internet verbindet und dessen Routen weiterverbreitet.

Transitnetz

Netz, das Verkehr zwischen fremden Netzen weiterleitet. Ein Unternehmensnetz soll das nie ungewollt werden.

Maximum-Prefix-Limit

Obergrenze für die Anzahl der Präfixe, die eine BGP-Session annimmt. Schützt vor Fehlkonfigurationen beim Nachbarn.

BFD (Bidirectional Forwarding Detection)

Protokoll zur schnellen Erkennung ausgefallener Verbindungen, deutlich schneller als die BGP-eigenen Timer.

NAT (Network Address Translation)

Übersetzung von IP-Adressen auf der Firewall, etwa einer öffentlichen Zieladresse auf die interne Adresse eines Servers.

Source-of-Truth

Zentrale, verbindliche Dokumentation des Netzes, aus der Konfiguration und Betrieb ihre Daten beziehen.

Renumbering

Umadressierung von Systemen und Netzen. Genau das soll providerunabhängiger Adressraum beim Providerwechsel vermeiden.

Quellen und fachliche Grundlage

Fachliche Prüfung: 09.10.2026. Die Aussagen beziehen sich auf den RIPE-NCC-Zuständigkeitsbereich. Richtlinien, Vertragsmodelle und Provideranforderungen sind vor einer konkreten Umsetzung ggf. erneut zu prüfen.

• RIPE NCC: IPv6 Address Allocation and Assignment Policy (RIPE-738)
• RIPE NCC: IPv4 Address Allocation and Assignment Policies (RIPE-826)
• RIPE NCC: Autonomous System Number Assignment Policies (RIPE-679)
• RIPE NCC: RIPE Resource Transfer Policies (RIPE-807)
• RIPE NCC: How to Request an IPv6 PI Assignment
• RIPE NCC: Using the Hosted Certification Authority (RPKI und ROAs)
• RIPE NCC: Transfers in the RIPE NCC Service Region

Weiterführend

• SD-WAN-Implementierung im Mittelstand: Roadmap und Rollout-Planung
• Firewall-Migration im Mittelstand: von der portbasierten Firewall zur Palo Alto Networks NGFW
• Netzwerk-Lösungen für WAN & DC

Bilder: KI-generiert.