Brauchen Sie eine ASN, um geleastes IPv4 anzukündigen? Vier Routing-Wege im Vergleich

Nein. Nicht immer.

Sie brauchen eine ASN irgendwo in der Routing-Kette, denn so erkennt BGP, wer Ihr Präfix originieren darf. Es muss aber nicht Ihre sein. Es gibt vier Ankündigungswege, und drei davon funktionieren, ohne dass Sie je bei einer Regional Internet Registry einen Antrag stellen.

Welcher passt, hängt davon ab, wie viele Upstreams Sie haben, wo der Workload läuft und wie viel Kontrolle über eingehenden Traffic Sie brauchen. Hier die gesamte Entscheidung auf einen Blick.

Der Rest dieses Leitfadens geht jeden Weg durch, die jeweils geänderten Unterlagen und die eine technische Regel, die darüber entscheidet, ob Ihr Subnetz überhaupt geroutet wird. Wenn Sie noch früher im Prozess sind und zuerst das Gesamtbild möchten, beginnen Sie mit dem vollständigen Leasing-Ablauf.

Zuerst der Widerspruch, den in diesem Markt niemand laut ausspricht

Lesen Sie die Dokumentation zweier Leasing-Anbieter nebeneinander, und Sie bekommen auf dieselbe Frage gegensätzliche Antworten.

Manche Leasinggeber behandeln eine ASN als zwingende Voraussetzung. RapidSeedbox schließt kein Leasing ohne ASN ab und rät Kunden ohne ASN, sie bei ihrem VPS- oder Hosting-Provider zu beschaffen. Voldeta stellt klar, dass Sie für Miete und Ankündigung eines IPv4-Subnetzes eine ASN benötigen – eigene oder die eines Dritten –, und ergänzt, dass die ASN eine saubere Reputation haben und nicht bei Spamhaus gelistet sein darf.

Andere Anbieter lassen Sie Ihre eigene nicht nutzen. Leaseweb kündigt Kundenpräfixe ausschließlich aus Leaseweb-AS-Nummern an; die Ankündigung eines Präfixes unter der eigenen ASN des Kunden wird gar nicht angeboten. Stattdessen verlangen sie bei RIPE-Blöcken delegiertes mnt-routes oder einen Letter of Authorization vom registrierten Inhaber.

Keines der beiden Lager liegt falsch. Sie beschreiben zwei unterschiedliche Wege, und jedes hat stillschweigend angenommen, sein Weg sei der einzige. Aus dieser Annahme stammt der größte Teil der Verwirrung rund um geleastes IPv4.

Was eine ASN hier tatsächlich tut

Überspringen Sie diesen Abschnitt, wenn Sie bereits BGP betreiben.

Eine Autonomous System Number identifiziert eine Menge von IP-Präfixen, die unter einer einzigen Routing-Policy betrieben werden. Wenn zwei Netzwerke Routen austauschen, identifizieren sie sich per ASN und kündigen an, welche Präfixe sie erreichen können. RFC 1930 beschreibt eine ASN als Einheit der Routing-Policy im externen Routing – bis heute die präziseste kurze Definition.

Zwei Formate sind im Einsatz. Der ursprüngliche 16-Bit-Raum bot 65.536 Nummern und ist auf RIR-Ebene praktisch erschöpft; neue Zuweisungen stammen aus dem 32-Bit-Raum nach RFC 6793, der RFC 4893 ablöste. Zurückgegebene oder zurückgeholte 16-Bit-Nummern kommen gelegentlich wieder in Umlauf, Sie sollten aber mit einer 32-Bit-ASN planen.

Für ein geleastes Subnetz zählt nur eine Eigenschaft der ASN: Sie ist die Identität, die an der Route hängt. Wer Ihr Präfix in BGP originiert, versieht es mit seiner AS-Nummer. Diese Nummer muss dann mit den Unterlagen übereinstimmen. Alles Folgende ergibt sich aus dieser einen Bedingung.

Weg 1: Ihre eigene ASN, Ihre eigene BGP-Session

Sie beantragen bei Ihrer RIR eine AS-Nummer, bauen BGP-Sessions zu Ihren Upstreams auf und originieren das geleaste Subnetz selbst.

Was sich an den Unterlagen ändert. Der IP-Eigentümer – oder die für ihn handelnde Leasing-Plattform – stellt eine LOA auf Ihre ASN aus, legt das IRR-Route-Objekt an oder aktualisiert es, das den Block an Ihre ASN bindet, und erstellt die ROA, die Ihre ASN zur Originierung des Präfixes autorisiert. Alle drei verweisen auf Sie. Wie diese Autorisierung funktioniert und warum Eigentümer durchgehend die Kontrolle behalten, beschreibt unser Leitfaden Wer die LOA ausstellt und warum Eigentümer die Kontrolle behalten.

Was Sie gewinnen. Echtes Multihoming. Sie können das Subnetz ohne Umnummerierung zwischen Upstreams verschieben, eingehenden Traffic über Präfixlänge und AS-Pfad steuern und den Ausfall eines Transit-Providers überstehen, ohne Ihre Adressen zu verlieren. Für einen ISP oder Telekommunikationsanbieter ist das keine Vorliebe – es ist der Grund, warum das Unternehmen eine Routing-Tabelle hat.

Was es kostet. Nach dem RIPE NCC Charging Scheme 2026 (ripe-848) kostet ein LIR-Konto EUR 1,800 pro Jahr plus EUR 1,000 Aufnahmegebühr, zuzüglich EUR 50 pro ASN-Zuweisung. Die Mitglieder stimmten im Mai 2026 für Option A für 2027: EUR 1,894 pro LIR-Konto, die erste ASN in der Jahresgebühr enthalten und EUR 50 für jede weitere ASN. Wenn Sie keine LIR werden möchten, können Sie eine ASN über eine sponsernde LIR beantragen, die eine eigene Gebühr erhebt, oder den Antrag direkt beim RIPE NCC stellen – ripe-679 erlaubt beide Wege. Wenn Sie eine LIR-Mitgliedschaft gegen eine gesponserte Lösung abwägen, finden Sie bei uns eine vollständige Aufschlüsselung der Kosten einer RIPE NCC Mitgliedschaft.

Wann es die falsche Entscheidung ist. Mit einem Upstream und einem /24 bringt Ihnen eine ASN nur Verwaltungsaufwand. Sie hängen für die Erreichbarkeit weiter von einem einzigen Provider ab, tragen nun Registry-Pflichten und laufende Gebühren, und Ihre Routing-Policy ist identisch mit der Ihres Upstreams. Die meisten IP-Mieter brauchen keine eigene ASN – und wer an Ihrer Antwort verdient, ist der falsche Ansprechpartner für diese Frage.

Wir übernehmen die ASN-Registrierung und das Sponsoring für Kunden, die eine brauchen, und sagen allen anderen, dass sie keine brauchen. Lautet die Antwort Ja, geht es schneller, wenn das Subnetz ebenfalls von uns kommt: Wir stellen den Block von Anfang an in der Form bereit, die die Registrierung verlangt, sodass beide Schritte ineinandergreifen, statt sich gegenseitig zu blockieren. Kunden, die bei uns leasen, erhalten außerdem reduzierte Preise für alle zugehörigen LIR-Services. Die Schritte auf Plattformseite finden Sie unter Subnetz konfigurieren: ASN hinzufügen und ROA einrichten.

Weg 2: Ihr Upstream oder Host kündigt das Subnetz für Sie an

Die häufigste Variante – und die, die die meisten Leasing-Leitfäden komplett ignorieren.

Ihr Hosting-Provider, Ihre Colocation oder Ihr Transit-Anbieter originiert das Präfix aus seinem AS. Sie betreiben kein BGP. Sie fassen keinen Router an. Das Subnetz erscheint auf Ihren Servern, und der Traffic kommt an.

Was sich an den Unterlagen ändert. Die LOA wird an Ihren Provider ausgestellt, nicht an Sie. Route-Objekt und ROA nennen dessen ASN als Origin, nicht Ihre. An diesem Detail scheitern viele: Mieter bitten ihren IP-Eigentümer um eine ROA für eine ASN, aus der sie gar nicht ankündigen, und wundern sich dann, warum nichts geroutet wird.

Praktische Einschränkungen, die Sie vor der Unterschrift prüfen sollten. Die meisten Provider setzen für IPv4 eine minimale ankündbare Größe von /24 – alles Längere wird global gefiltert, egal wer es originiert. Viele aggregieren Ankündigungen und de-aggregieren nicht auf Anfrage. Manche begrenzen die Zahl externer Präfixe pro Kunde oder berechnen eine Einrichtungsgebühr pro Block.

Was Sie aufgeben. Portabilität und Kontrolle. Da die Ankündigung bei Ihrem Provider liegt, bedeutet ein Providerwechsel eine neue LOA, ein neues Route-Objekt, eine neue ROA und eine neue Ankündigung. Die Adressen bleiben Ihre zum Leasen, aber das Routing folgt Ihnen nicht automatisch.

Weg 3: Cloud-BYOIP

Mit Bring-Your-Own-IP-Programmen importieren Sie einen geleasten Block in eine Public Cloud und nutzen ihn auf Cloud-Ressourcen. Hier geht es speziell um die ASN-Frage; den vollständigen Onboarding-Ablauf je Plattform finden Sie in unserem BYOIP-Leitfaden nach Anbietern.

AWS. BYOIP in kommerziellen Regionen autorisiert Ankündigungen aus den Amazon-ASNs 16509 und 14618; die Region AWS GovCloud (US) nutzt die ASN 8987. Für IPv4 muss die ROA mit einer maximalen Länge von /24 angelegt werden. Die Autorisierung hat zwei Teile: Die ROA belegt, dass die Adressen angekündigt werden dürfen, und ein selbstsigniertes X.509-Zertifikat in den RDAP-Remarks des Blocks belegt, dass das AWS-Konto, das sie einbringt, Ihnen gehört. AWS dokumentiert die Prüfung des Ergebnisses über den RIPEstat-Data-Call zur RPKI-Validierung, der unabhängig davon funktioniert, welche RIR den Adressraum verwaltet.

AWS unterstützt auch eine eigene ASN. Über IPAM können Sie eine ASN, die Sie halten, mit einem BYOIP-CIDR verknüpfen und AWS das Präfix unter Ihrem AS statt unter Amazons ankündigen lassen. Das ist der einzige Fall, in dem Cloud-Betrieb und eigene ASN sich nicht ausschließen – gut zu wissen, bevor Sie schließen, dass BYOIP die Aufgabe Ihrer Routing-Identität bedeutet.

Azure. Unterstützt über Custom IP Prefix. Die ROA muss das Origin-AS 8075 für die Public Cloud oder 8070 für US Gov autorisieren und mit dem RPKI Ihrer RIR signiert sein. Ein Unified- oder Parent-IPv4-Präfix muss zwischen /21 und /24 liegen. Nach der Inbetriebnahme kündigt Microsoft den Bereich global aus AS 8075 an – denselben Bereich gleichzeitig von anderswo anzukündigen, riskiert Routing-Instabilität, Migrationen brauchen daher ein Wartungsfenster. Zwei weitere Einschränkungen entscheiden, ob Azure überhaupt infrage kommt: SMTP ist aus Azure-BYOIP-Adressraum nicht erlaubt, dieser Weg eignet sich also nicht für Mail-Workloads; und der Bereich muss außer Betrieb genommen werden, bevor Sie die ROA ändern oder löschen, sonst kündigt Microsoft weiter ein Präfix an, für das es nicht mehr autorisiert ist.

GCP. Unterstützt, mit eigenen Onboarding-Anforderungen.

Worauf Sie bei allen dreien achten sollten. Jede Cloud hat ihre eigene minimale Präfixgröße, regionale Einschränkungen und Validierungsdauer. Da Ihr IP-Eigentümer die Registry-Kontrolle hält, können Sie die Schritte für ROA und RDAP nicht allein erledigen – sie müssen mit dem Eigentümer oder der Leasing-Plattform abgestimmt werden. Und wenn Sie leasen, um einen stabilen Adressbestand hinter Partner-Allowlists zu erhalten, sind die Einschränkungen in diesem Abschnitt wichtiger als sonst – siehe geleaste Adressen in Partner-Allowlists halten.

Weg 4: Ankündigung aus der ASN eines Dritten

Verbreitet bei Proxy-Betrieb, Datenerhebung und kurzlebigen Projekten. Ein Partner, der bereits ein AS betreibt, kündigt das Subnetz im Rahmen einer kommerziellen Vereinbarung für Sie an.

Was sich an den Unterlagen ändert. Gleiche Form wie bei Weg 2 – LOA, Route-Objekt und ROA nennen die ASN des Partners. Der Unterschied: Ihre Beziehung zur ankündigenden Partei ist rein vertraglich und oft kürzer als das Leasing selbst.

Die Frage der Reputation. Die Anforderung von Voldeta gilt für jede Vereinbarung dieser Art: Die ankündigende ASN braucht eine saubere Historie. Ein Subnetz mit makelloser Vergangenheit, angekündigt aus einem AS mit schlechter, übernimmt dessen Probleme – zuerst bei der Mail-Zustellbarkeit, dann beim Filtern. Prüfen Sie die ASN, nicht nur den Block.

Das Ausstiegsrisiko. Endet die Partnerschaft vor dem Leasing, brauchen Sie eine neue ankündigende Partei, eine neue LOA, ein neues Route-Objekt und eine neue ROA – und eine Lücke bei einem davon bedeutet, dass das Subnetz nicht mehr geroutet wird. Regeln Sie die Übergabe in der Vereinbarung, bevor Sie sie brauchen.

Die Regel, die darüber entscheidet, ob irgendetwas davon funktioniert

Die ASN in der ROA muss mit dem AS übereinstimmen, das die Route tatsächlich originiert.

Das ist alles. Jeder der folgenden Fehler ist eine Variante davon.

Eine Route Origin Authorization ist eine signierte Aussage des Ressourceninhabers, welche ASN ein bestimmtes Präfix originieren darf und bis zu welcher Präfixlänge. In der RIPE-Region werden ROAs vom registrierten Inhaber im RIPE NCC RPKI Dashboard angelegt – vom IP-Eigentümer, nicht vom IP-Mieter. Daneben steht das IRR-Route-Objekt, das das inetnum an eine bestimmte ASN bindet und diese damit zur Ankündigung des Blocks autorisiert.

RFC 6811 definiert drei Validierungszustände:

• NotFound – keine ROA deckt das Präfix ab. Die meisten Netzwerke akzeptieren solche Routen noch, doch ihr Anteil schrumpft mit wachsender RPKI-Verbreitung. Beachten Sie, dass RIPEstat diesen Zustand in der API-Ausgabe als „unknown“ meldet – eine häufige Quelle der Verwirrung.

• Valid – ROA vorhanden, Origin-ASN und Präfixlänge stimmen. Das ist das Ziel.

• Invalid – ROA vorhanden, aber die Origin-ASN ist falsch oder das angekündigte Präfix ist länger als die maximale Länge der ROA. Jedes Netzwerk mit Route Origin Validation verwirft die Route. Der Fehler sieht aus wie ein rätselhafter Teilausfall, nicht wie ein Konfigurationsfehler.

Wenn RPKI Neuland für Sie ist, erklärt unser Einsteigerleitfaden So funktionieren RPKI und ROAs die ROA-Erstellung, Fehler bei der maximalen Länge und was eine falsche ROA Sie kostet.

Daraus folgen direkt zwei Konsequenzen:

1. Entscheiden Sie sich für einen Weg, bevor die ROA angelegt wird. Kündigt Ihr Host für Sie an, nennt die ROA dessen ASN. Nutzen Sie Azure Custom IP Prefix, nennt sie 8075. Eine ROA für die eigene ASN anzulegen und dann einen Provider um die Ankündigung zu bitten, ist der häufigste selbst verursachte Routing-Fehler bei geleastem Adressraum.

2. Ändert sich Ihre ASN während des Leasings, müssen ROA und Route-Objekt mitgeändert werden. Das geschieht nicht automatisch. Es ist eine Anfrage an Ihren IP-Eigentümer oder Ihre Leasing-Plattform und muss vor der Umstellung erfolgen, nicht danach.

Kann ein /24 aus Ihrer ASN angekündigt werden, während das übergeordnete Aggregat weiter aus der des Eigentümers angekündigt wird? Ja. Betreiber machen das seit Jahren. Das spezifischere Präfix gewinnt per Longest-Prefix-Match, der Traffic landet also bei Ihnen. Damit es funktioniert, braucht es korrekte Route-Objekte und eine passende ROA für das spezifischere Präfix; es scheitert, wenn ohne sie angekündigt wird und die Route als Hijack gilt. Wenn Sie sich allein auf das spezifischere Präfix verlassen, beachten Sie: Ohne Unterlagen für jeden Pfad können Sie sich nicht zuverlässig per Multihoming vom Upstream des Eigentümers lösen.

Habe ich Anspruch auf eine eigene ASN?

Multihoming ist das Kriterium der Richtlinie, und es ist strenger, als die meisten Artikel nahelegen. ripe-679 Abschnitt 2.0 legt ausdrücklich fest, dass ein Netzwerk multihomed sein muss, um Anspruch auf eine AS-Nummer zu haben, und dass eine neue ASN nur genutzt werden soll, wenn eine neue externe Routing-Policy erforderlich ist. Bei der Beantragung reichen Sie diese Routing-Policy in RPSL ein, und das RIPE NCC kann Ihre Upstreams kontaktieren, um die Vereinbarung zu prüfen.

Das lohnt sich genau festzuhalten, denn das Bild hat sich erst kürzlich verändert. Der Richtlinienvorschlag 2025-01, „ASN assignment criteria revisited“, hätte alle Begründungspflichten für die erste ASN einer Organisation abgeschafft. Seine Autoren argumentierten, 32-Bit-ASNs seien nicht mehr knapp – die RIRs haben rund 88.400 davon vergeben, etwa 0,002 % des verfügbaren Raums – und die Multihoming-Regel sei in der Praxis nicht durchsetzbar, da etwa die Hälfte der vom RIPE NCC vergebenen ASNs sie nicht erfüllt. Der Vorschlag erreichte Version 2.0, wurde bis RIPE 92 im Mai 2026 in Edinburgh diskutiert und am 6. Juli 2026 zurückgezogen. Die bestehenden Kriterien in ripe-679 bleiben in Kraft. Falls Sie anderswo gelesen haben, RIPE werde die erste ASN demnächst auf Anfrage vergeben, ist das nicht mehr zutreffend.

Eine eigene Routing-Policy klingt schwieriger, als sie ist. Sie bedeutet nicht, dass Sie andere Transit-Provider als alle anderen nutzen müssen. Zwei Organisationen mit denselben zwei Upstreams haben dennoch unterschiedliche Routing-Policies, weil jede ihren eigenen Adressraum und ihre eigenen Ankündigungen kontrolliert.

Wenn Sie unsicher sind, ob Ihr Setup das Multihoming-Kriterium erfüllt, fragen Sie vor dem Antrag. Wir bereiten die Routing-Policy in RPSL vor, übernehmen die Einreichung über eine sponsernde LIR oder direkt beim RIPE NCC und begleiten sie bis zur Zuweisung. Die ASN wird auf Sie registriert und bleibt Ihre.

Checkliste vor der Ankündigung

Gehen Sie sie durch, bevor Traffic auf das Subnetz gelenkt wird – unabhängig vom Weg. Wenn Sie laufende Dienste umziehen statt etwas Neues aufzubauen, ergänzt der vollständige Ablauf für eine Migration ohne Ausfallzeit diese Schritte um DNS-TTL-Vorbereitung und Parallelbetrieb.

• [ ] LOA ausgestellt, auf die ankündigende ASN, gültig für die Leasinglaufzeit

• [ ] IRR-Route-Objekt für das Präfix mit der richtigen Origin-ASN angelegt

• [ ] ROA angelegt, richtige ASN, maximale Präfixlänge passend zur Ankündigung

• [ ] Präfix validiert als Valid – prüfen Sie über den RIPEstat-Data-Call zur RPKI-Validierung, eine Routinator-Instanz oder eine andere gepflegte Relying-Party-Implementierung wie rpki-client oder FORT. Verwenden Sie nicht den RIPE NCC RPKI Validator: Er wird seit dem 1. Juli 2021 nicht mehr gepflegt, und der öffentliche Dienst unter rpki-validator.ripe.net wurde im September 2021 auf Routinator umgestellt.

• [ ] Präfix von mehreren Messpunkten aus sichtbar – RIPE RIS, BGPView oder das Hurricane Electric Toolkit

• [ ] Die tatsächlich beobachtete Origin-ASN entspricht der ASN in der ROA

• [ ] Reverse DNS delegiert

• [ ] Reputation des Blocks gegen die großen Blocklists geprüft – und die Reputation der ankündigenden ASN ebenfalls

Sobald das Subnetz live ist, wird das Routing-Setup zu einer Inventarfrage: Ablaufdaten der Leasings, Reputationsprüfungen und Subnetzzuweisungen müssen über die gesamte Laufzeit nachverfolgt werden.

FAQ

Kann ich IPv4 ohne ASN leasen?

Ja. Drei der vier Wege oben erfordern keine eigene ASN. Was nicht geht: das Subnetz routen, ohne dass irgendeine ASN es originiert.

Können zwei verschiedene ASNs Teile desselben Blocks ankündigen?

Ja. Ein spezifischeres Subnetz kann aus einer ASN angekündigt werden, während das übergeordnete Aggregat aus einer anderen angekündigt wird. Beide brauchen korrekte Route-Objekte, und das spezifischere braucht eine ROA, deren maximale Präfixlänge es erlaubt.

Spielt die Reputation der ankündigenden ASN eine Rolle?

Ja, und sie wird zu selten geprüft. Blocklist-Betreiber und Mail-Empfänger betrachten das Origin-AS ebenso wie die Adresshistorie. Manche Leasinggeber verweigern die Autorisierung einer Ankündigung aus einer ASN mit schlechter Historie.

Was, wenn sich meine ASN während des Leasings ändert?

ROA und IRR-Route-Objekt müssen vom IP-Eigentümer aktualisiert werden, bevor Sie aus dem neuen AS ankündigen. Planen Sie ein Zeitfenster; stellen Sie nicht einfach um und hoffen.

Kann ich ein geleastes /24 aus der größeren Zuteilung eines anderen ankündigen?

Ja, mit LOA und korrekten Registry-Objekten. Das ist gängige Praxis, keine Ausnahme.

Schafft RIPE die Multihoming-Anforderung demnächst ab?

Nein. Der Vorschlag, der das getan hätte, 2025-01, wurde am 6. Juli 2026 zurückgezogen. ripe-679 gilt unverändert.

Kann ich geleastes IPv4 in Azure für den E-Mail-Versand nutzen?

Nein. Azure erlaubt kein SMTP aus BYOIP-Adressraum. Wenn Mail der Anwendungsfall ist, wählen Sie einen anderen Bereitstellungsweg.