Warum ein Teilausfall so lange unentdeckt bleibt
Die übliche Überwachung beantwortet eine einzige Frage: Antwortet die Adresse? Wer diese Frage von einem Punkt aus stellt, bekommt eine Antwort über genau einen Weg durch das Netz. Ist dieser Weg in Ordnung, meldet die Prüfung grün, während ein anderer Teil des Internets dieselbe Adresse gar nicht erreicht. Der Fehler ist damit nicht unsichtbar, sondern nur an der falschen Stelle gemessen. Warum ein einzelner Prüfpunkt für diese Klasse von Störungen zu wenig ist, beschreibt Multi-Location-Monitoring: warum ein Standort nicht reicht ausführlich; für Routing-Fehler gilt das in verschärfter Form, weil die Störung dort per Definition ortsabhängig ist.
Der zweite Grund für die späte Entdeckung liegt im Verhalten der Beschwerden. Betroffene Besucher sitzen hinter einem bestimmten Zugangsnetz, oft in einer bestimmten Region. Sie melden sich selten, und wenn sie sich melden, klingt ihre Beschreibung nach einem Problem auf ihrer Seite. Wer aus mehreren Netzen misst, sieht stattdessen ein Muster: dieselbe Adresse, dieselbe Sekunde, unterschiedliche Ergebnisse je Prüfpunkt. Dieses Muster von echtem Rauschen zu trennen, ist eine eigene Aufgabe; wie sich wiederkehrende Auf-und-ab-Meldungen zähmen lassen, ohne die echten zu verlieren, steht in Flapping-Alerts zähmen.
- Nach Zahl der Präfixe waren 55,8 Prozent der gerouteten IPv4-Präfixe und 60,4 Prozent der gerouteten IPv6-Präfixe durch eine signierte Herkunftsangabe abgedeckt (ACM IMC 2025).
- Nach Adressraum gerechnet waren es 51,5 Prozent bei IPv4 und 61,7 Prozent bei IPv6, Stand April 2025 (ACM IMC 2025).
- 49,3 Prozent der Organisationen mit eigener Adresszuteilung hatten Anfang 2025 mindestens eine ROA ausgestellt, 44,9 Prozent für ihren gesamten Adressraum (ACM IMC 2025).
- In der RIPE-Region waren im April 2025 fast 80 Prozent des gerouteten IPv4-Adressraums abgedeckt (ACM IMC 2025).
- Weniger als 5 Prozent der als RPKI-invalid eingestuften Präfixe erreichten eine Sichtbarkeit von mehr als 40 Prozent der Sammelpunkte, während mehr als 90 Prozent der gültigen und der nicht erfassten Präfixe von mehr als 80 Prozent der Sammelpunkte gesehen wurden (ACM IMC 2025).
Diese Zahlen beschreiben den Zustand des globalen Routings, nicht den einer einzelnen Website. Sie sind trotzdem die Grundlage für eine praktische Einschätzung: 40 bis 50 Prozent des gerouteten Adressraums sind weiterhin nicht durch ROAs abgedeckt (ACM IMC 2025). Für ein Präfix ohne solche Angabe fällt eine falsche Ankündigung nirgends selbsttätig auf; für ein Präfix mit Angabe verwerfen viele große Netze eine widersprüchliche Ankündigung, andere nehmen sie an. Genau daraus entsteht das Bild eines nur teilweise erreichbaren Dienstes.
Präfix, autonomes System, Ankündigung
Das Internet ist kein einzelnes Netz, sondern ein Verbund eigenständiger Netze. Jedes dieser Netze trägt eine Nummer, die Nummer des autonomen Systems, und ist für die Erreichbarkeit eines oder mehrerer Adressbereiche zuständig. Ein solcher Adressbereich heißt Präfix und wird als Adresse mit Längenangabe geschrieben, etwa 203.0.113.0/24. Über das Border Gateway Protocol teilt ein Netz seinen Nachbarn mit, welche Präfixe es erreichbar macht und über welche Kette von Netzen der Weg dorthin führt. Diese Mitteilung heißt Ankündigung, und sie ist die Grundlage jeder Verbindung, die über mehr als ein Netz läuft. RFC 7454 beschreibt das Protokoll als praktisch alleinigen Weg, auf dem Netze im Internet Routing-Informationen austauschen.
Der für den Betrieb entscheidende Punkt: Es gibt keine zentrale Liste, gegen die eine Ankündigung geprüft würde. Jedes Netz entscheidet selbst, welche Ankündigung es annimmt und welche es weitergibt. Ein Netz kann deshalb einen anderen Weg kennen als sein Nachbar, und beide können recht haben. Dieselbe Eigenschaft macht das Internet robust und die Fehlersuche mühsam. Sie erklärt auch, warum ein Dienst über IPv4 erreichbar sein kann und über IPv6 nicht oder umgekehrt: Beide Adressfamilien werden getrennt angekündigt und getrennt bewertet. Wer beide Wege überwacht, findet diese Fälle; wie das aussieht, steht in IPv6-Erreichbarkeit im Dual-Stack überwachen.
Prefix-Hijacking bezeichnet die unerlaubte Annoncierung eines IP-Präfixes, das einem anderen autonomen System zugeordnet ist.
— BSI, Veröffentlichungen zur Cyber-Sicherheit, How-To: RPKI
Wie eine falsche Ankündigung entsteht
Die häufigste Ursache ist kein Angriff, sondern ein Tippfehler oder eine vergessene Zeile in der Konfiguration eines Nachbarnetzes. Aus einer Ziffer zu viel wird ein Präfix, das jemand anderem zugeteilt ist; aus einer fehlenden Filterregel wird eine Ankündigung, die nur intern hätte gelten sollen. Solche Fehler wandern in Minuten durch weite Teile des Internets und sind für den Betroffenen von einer absichtlichen Übernahme zunächst nicht zu unterscheiden. Dass Angriffe auf die Namensauflösung ein ähnliches Bild erzeugen, macht die Einordnung nicht leichter; die Unterschiede beschreibt DNS-Hijacking erkennen und verhindern.
- Zu spezifische Ankündigung: Ein fremdes Netz kündigt einen kleineren Ausschnitt des Präfixes an. Weil der genauere Eintrag in der Regel gewinnt, zieht er den Verkehr an sich, ohne dass die ursprüngliche Ankündigung verschwindet.
- Falsches Herkunfts-AS: Das Präfix wird korrekt angekündigt, aber unter einer Nummer, die dazu nicht autorisiert ist. Ohne signierte Herkunftsangabe fällt das an keiner Stelle selbsttätig auf.
- Weitergabe über die Grenze: Ein Netz reicht Ankündigungen weiter, die es nur für den eigenen Gebrauch erhalten hat. Der Verkehr nimmt dann einen Umweg über eine Leitung, die für diese Menge nicht ausgelegt ist.
- Zurückgezogene Ankündigung: Nach einer Umstellung fehlt die Ankündigung für einen Teil des Adressbereichs. Der Rest bleibt erreichbar, der fehlende Teil verschwindet lautlos.
- Filter beim Nachbarn: Eine korrekte Ankündigung wird von einem einzelnen Netz verworfen, etwa weil dort eine veraltete Filterliste steht. Betroffen ist dann genau ein Zugangsnetz.
Für die Wirkung ist die Ursache zunächst zweitrangig. Ob Tippfehler, veralteter Filter oder Absicht: Der Weg zu einem Teil der Besucher fehlt, während die eigene Infrastruktur unauffällig weiterläuft. Die Gemeinsamkeit mit anderen still ausfallenden Schichten ist die fehlende Rückmeldung, denn was den normalen Abruf nicht stört, fällt im Betrieb lange nicht auf. Ein offen stehender Zonentransfer im DNS gehört in dieselbe Familie; wie er sich finden lässt, steht in Offener Zonentransfer per AXFR.
Wenn zwei von acht Prüfpunkten eine Adresse nicht erreichen und die übrigen sechs im Millisekundenbereich antworten, ist das kein Messfehler, der sich glätten lässt. Ein Konsensverfahren, das erst bei einer Mehrheit ausfallender Punkte meldet, unterdrückt genau diesen Fall. Sinnvoll ist eine zweite Regel neben dem Konsens: Alarm auch dann, wenn ein Prüfpunkt über mehrere Runden hinweg abweicht, während die anderen stabil antworten.
RPKI: die signierte Herkunftsangabe
Die Resource Public Key Infrastructure schließt genau eine Lücke: Sie hinterlegt kryptografisch signiert, welches autonome System ein bestimmtes Präfix ankündigen darf und bis zu welcher Länge. Dieses Objekt heißt Route Origin Authorisation, kurz ROA. Es enthält das autorisierte autonome System, das Präfix und die maximal zulässige Präfixlänge. Ein Netz, das die Herkunft prüft, vergleicht jede eingehende Ankündigung mit den hinterlegten Angaben und kommt zu einem von drei Ergebnissen. Das Verfahren steht in RFC 6811, die Betriebsempfehlungen dazu in RFC 7454.
| Zustand der Ankündigung | Was er bedeutet | Was im Netz damit geschieht |
|---|---|---|
| NotFound | Es gibt keine hinterlegte Herkunftsangabe, die dieses Präfix abdeckt | Die Ankündigung wird in der Regel wie bisher angenommen |
| Valid | Eine Herkunftsangabe passt zu Präfix, Länge und Herkunfts-AS | Die Ankündigung gilt als bestätigt |
| Invalid | Eine Herkunftsangabe deckt das Präfix ab, passt aber nicht zu AS oder Länge | Netze mit Herkunftsprüfung verwerfen die Ankündigung typischerweise |
Wichtig ist, was aus dem Ergebnis folgt und was nicht. RFC 6811 legt die drei Zustände fest, überlässt die Entscheidung darüber aber dem einzelnen Netz: Eine Ankündigung fällt wegen ihres Zustands nicht selbsttätig aus der Verarbeitung, solange das nicht ausdrücklich eingerichtet ist. In der Praxis verwerfen viele große Transitnetze invalide Ankündigungen inzwischen, kleinere Netze oft nicht. Genau daraus entsteht die geteilte Sicht: Weniger als 5 Prozent der invaliden Präfixe erreichten in der Messung eine Sichtbarkeit von mehr als 40 Prozent der Sammelpunkte, während mehr als 90 Prozent der gültigen und der nicht erfassten Präfixe von über 80 Prozent der Sammelpunkte gesehen wurden (ACM IMC 2025). Eine falsche Ankündigung wird also nicht überall geglaubt, aber auch nicht überall verworfen.
Wie weit die Abdeckung heute reicht
Mit Stand April 2025 waren 51,5 Prozent des gerouteten IPv4-Adressraums und 61,7 Prozent des gerouteten IPv6-Adressraums durch ROA-Zertifikate abgedeckt; nach Zahl der Präfixe waren es 55,8 Prozent für IPv4 und 60,4 Prozent für IPv6 (ACM IMC 2025). Auf Ebene der Organisationen sieht das Bild ähnlich aus: Anfang 2025 hatten 49,3 Prozent der Organisationen mit eigener Adresszuteilung mindestens eine ROA ausgestellt, 44,9 Prozent für ihren gesamten Adressraum (ACM IMC 2025). Regional verteilt sich das ungleich. In der RIPE-Region, zu der auch Deutschland gehört, waren im April 2025 fast 80 Prozent des gerouteten IPv4-Adressraums abgedeckt (ACM IMC 2025).
Der Rest ist weniger eine technische als eine organisatorische Aufgabe. Dieselbe Untersuchung ordnet 47 Prozent der IPv4-Präfixe und 71 Prozent der IPv6-Präfixe ohne RPKI-Eintrag als mit geringem technischem Aufwand abdeckbar ein (ACM IMC 2025). Sie rechnet außerdem vor, dass die weltweite Abdeckung um 7 Prozent für IPv4 und 19 Prozent für IPv6 steigen könnte, wenn zehn Organisationen die nötigen Schritte gingen (ACM IMC 2025). Für einen Website-Betreiber heißt das vor allem eines: Die Frage an den Hoster ist berechtigt und in der Regel ohne großen Aufwand zu beantworten.
Die Anteile nach Adressraum und Präfixzahl stammen aus einer Messung gerouteter Präfixe, die die öffentlichen Sammelpunkte von RouteViews und RIPE RIS auswertet und dabei Präfixe spezifischer als /24 bei IPv4 und /48 bei IPv6 ebenso ausschließt wie Präfixe, die von weniger als 1 Prozent der Sammelpunkte gesehen werden; Stichtag ist April 2025. Die Anteile auf Ebene der Organisationen beruhen dagegen auf dem Bulk-WHOIS-Bestand von fünf RIRs und drei NIRs, aus dem die Untersuchung über die Präfix-Hierarchie die Direktzuteilungen bestimmt; Stichtag dort ist Anfang 2025 (ACM IMC 2025). Sie beschreiben damit den globalen Bestand, nicht die Lage eines einzelnen Netzes. Für die eigene Adresse zählt allein, ob für das Präfix, unter dem die Website erreichbar ist, eine passende Herkunftsangabe hinterlegt ist.
maxLength: der Schalter, der zu viel erlaubt
Eine ROA kann neben dem Präfix eine maximale Länge tragen. Damit erlaubt sie dem autorisierten autonomen System, auch kleinere Ausschnitte des Bereichs anzukündigen, ohne dass für jeden Ausschnitt ein eigenes Objekt nötig wäre. Das ist bequem und hat eine Nebenwirkung: Jeder Ausschnitt, der erlaubt, aber nicht angekündigt ist, steht als zulässiger Eintrag bereit, ohne dass ihn eine echte Ankündigung besetzt. Wer ihn unter der autorisierten Nummer ankündigt, erzeugt eine Ankündigung, die die Herkunftsprüfung besteht und den Verkehr an sich zieht.
Wie verbreitet das ist, hat RFC 9319 ausgewertet. Eine Messung vom Juni 2017 ergab, dass 12 Prozent der in ROAs autorisierten Präfixe eine maximale Länge tragen, die über ihre eigene Präfixlänge hinausgeht (RFC 9319). Von diesen waren 84 Prozent nicht minimal, weil sie Ausschnitte einschlossen, die vom berechtigten autonomen System gar nicht angekündigt werden (RFC 9319). Die Empfehlung des Dokuments ist entsprechend knapp: minimale ROAs verwenden, wo es geht, und die maximale Länge nur dort setzen, wo die kleineren Ausschnitte tatsächlich angekündigt werden. Für ein Gespräch mit dem Hoster ist das eine konkrete, prüfbare Frage.
Teilausfall erkennen und einordnen
Der erste Schritt ist unspektakulär: dieselbe Adresse zur selben Zeit von mehreren Punkten aus abfragen und die Ergebnisse nebeneinanderlegen. Erst der Vergleich macht aus vier Einzelmessungen eine Aussage. Wie eng die Runden dafür liegen sollten, hängt an der gewünschten Erkennungszeit; die Rechnung dazu steht in Prüfintervall und Erkennungszeit. Für Routing-Störungen kommt eine zweite Anforderung dazu: Die Prüfpunkte sollten in unterschiedlichen Netzen liegen, nicht nur an unterschiedlichen Orten. Zwei Rechenzentren am selben Verbund sehen dieselbe Ankündigung und liefern deshalb dieselbe Antwort.
Die vier Aufrufe trennen vier Ebenen. Die Namensauflösung liefert eine Adresse, die Verbindung kommt nicht zustande, der Weg bricht nach dem neunten Zwischenschritt ab, und die Gegenstelle antwortet auch auf ein einfaches Echo nicht. Wichtig ist dabei der Rückgabewert 000 in der zweiten Zeile: Das ist kein Statuscode, sondern die Angabe, dass keine Antwort kam. Ein Wert, der aus einem gescheiterten Abruf entsteht, gehört nicht in dasselbe Feld wie ein echter Messwert, sonst wird aus einem Ausfall der Messung ein Messergebnis. Dieselbe Folge von einem Punkt in einem anderen Netz aus liefert im Teilausfall ein vollständiges Bild mit Statuscode 200.
Uptime-Monitoring fragt dieselbe Adresse von mehreren EU-Standorten ab und bildet aus den Einzelergebnissen einen Konsens. Weicht ein Standort dauerhaft ab, ist das ein eigener Befund und kein Rauschen.
DNS- und Domain-Monitoring vergleicht die Antworten mehrerer Auflöser. So lässt sich früh trennen, ob die Adresse falsch ist oder der Weg zur richtigen Adresse fehlt.
API-Monitoring prüft angebundene Dienste getrennt von der Website. Fällt eine Schnittstelle nur aus einer Richtung aus, steht die Richtung im Protokoll.
Alarmierung nennt im Text der Meldung, welche Prüfpunkte betroffen sind. Eine Meldung ohne Ortsangabe kostet beim Einordnen mehr Zeit, als die Prüfung gespart hat.
Was ohne eigenes Netz möglich ist
Wer eine Website betreibt, besitzt in der Regel weder ein autonomes System noch eigene Adressbereiche. Die Adressen gehören dem Hoster, und damit liegen auch die Herkunftsangaben in dessen Verantwortung. Handlungsfähig ist man trotzdem, und zwar an drei Stellen: bei der Auswahl, bei der Messung und bei der Meldung. Die folgenden Fragen lassen sich vor einem Vertragsabschluss stellen und später wiederholen. Sie sind ohne Netzwerkwissen verständlich und haben eine kurze, prüfbare Antwort.
- Sind für die Präfixe, aus denen unsere Adressen stammen, Herkunftsangaben hinterlegt? Die Antwort lautet ja oder nein und lässt sich unabhängig nachsehen.
- Wird bei der maximalen Länge sparsam verfahren? Gemeint ist die Frage, ob die Objekte nur die Ausschnitte erlauben, die tatsächlich angekündigt werden.
- Prüft der Anbieter eingehende Ankündigungen auf ihre Herkunft? Das betrifft den Weg in die andere Richtung und wirkt darauf, ob die eigenen Besucher auf einen falschen Weg geraten können.
- Gibt es einen benannten Weg für Routing-Meldungen? Eine Adresse, an die ein Verdacht mit Messprotokoll gehen kann, ist im Ernstfall mehr wert als eine allgemeine Störungsnummer.
- Wie wird eine regionale Störung kommuniziert? Sinnvoll ist eine Statusmeldung, die den betroffenen Bereich benennt, statt eine Störung entweder ganz zu melden oder gar nicht.
- Sind IPv4 und IPv6 gleich abgedeckt? Beide Adressfamilien werden getrennt angekündigt; eine Angabe nur für IPv4 lässt die zweite Hälfte offen.
Zeitraum mit Zeitzone, betroffene Prüfpunkte mit Netznummer und die unveränderte Ausgabe der Messung. Fehlt eine davon, beginnt beim Empfänger die Rückfrage, und der Verdacht altert. Wer diese drei Angaben aus dem laufenden Protokoll ziehen kann, meldet erfahrungsgemäß in Minuten statt in Stunden.
Einen Verdacht sauber belegen
Eine Meldung, die aus einer Vermutung besteht, erzeugt beim Anbieter eine Rückfrage und sonst wenig. Belastbar wird sie durch ein Protokoll mit drei Eigenschaften: Es nennt die Messpunkte einzeln, es unterscheidet zwischen gemessenem Wert und ausgefallener Messung, und es trägt Zeitstempel in einer Zone, die auch der Empfänger versteht. Der letzte Punkt klingt nebensächlich und ist eine der häufigsten Quellen für Missverständnisse in Störungsmeldungen.
{
"adresse": "https://www.example.invalid/",
"praefix": "203.0.113.0/24",
"beobachtet_von": "2026-09-24T08:12:00Z",
"beobachtet_bis": "2026-09-24T09:41:00Z",
"standorte": [
{ "ort": "Frankfurt", "netz": "AS64496", "status": "erreichbar", "http": 200, "ms": 41 },
{ "ort": "Amsterdam", "netz": "AS64497", "status": "erreichbar", "http": 200, "ms": 53 },
{ "ort": "Madrid", "netz": "AS64498", "status": "ohne Route", "http": null, "ms": null },
{ "ort": "Mailand", "netz": "AS64499", "status": "ohne Route", "http": null, "ms": null }
],
"konsens": "teilweise erreichbar",
"dns_antwort_identisch": true,
"messausfall_als_null": false
}Zwei Details in diesem Protokoll tragen die Beweislast. Erstens stehen für die nicht erreichbaren Standorte keine Nullwerte, sondern leere Felder mit dem Vermerk, dass keine Route bestand; eine 0 im Feld für die Antwortzeit wäre eine Behauptung über etwas Ungemessenes. Zweitens sind die Zeitstempel in UTC notiert. Wer im Herbst mit lokalen Zeiten arbeitet, bekommt eine Stunde, die zweimal vorkommt, und damit eine Reihenfolge, die sich nicht mehr rekonstruieren lässt; was daraus im Monitoring folgt, steht in Zeitumstellung im Monitoring.
Ein Protokoll aus Prüfpunkten zeigt, dass eine Adresse aus bestimmten Netzen nicht erreichbar war. Es zeigt nicht, warum. Die Zuordnung zu einer bestimmten Ankündigung, einem bestimmten Netz oder gar einer Absicht ist eine Aussage über Dritte und gehört ohne Belege nicht in eine Meldung. Sinnvoll ist die Formulierung als Beobachtung: Zeitraum, Prüfpunkte, Ergebnis, Bitte um Klärung. Die Ursachenanalyse liegt bei dem, der die Ankündigungen sieht.
Alarm und Statusseite bei regionaler Störung
Ein Alarm für einen Teilausfall braucht eine andere Schwelle als einer für einen vollständigen Ausfall. Sinnvoll ist eine Regel, die zwei Fälle kennt: Fällt die Mehrheit der Prüfpunkte aus, ist das ein Ausfall; weicht ein Prüfpunkt über mehrere Runden ab, während die übrigen stabil antworten, ist das eine regionale Störung mit eigener Meldung. Beide Meldungen brauchen die Ortsangabe im Text, sonst beginnt die Einordnung beim Empfänger mit einer Suche. Nach außen gehört derselbe Unterschied auf die Statusseite: Ein öffentlicher Statusbericht, der einen regional begrenzten Vorfall auch als solchen benennt, erspart einen Teil der Anfragen und ist ehrlicher als eine grüne Ampel.
Für die Historie lohnt sich die standortgenaue Aufzeichnung. Erst sie beantwortet die Frage, die nach einem Vorfall regelmäßig kommt: War das schon einmal so, und traf es dieselben Netze? Ein Verlauf, der je Prüfpunkt geführt wird, zeigt Wiederholungen, die in einer zusammengefassten Verfügbarkeitszahl verschwinden. Dieselbe Zahl kann bedeuten, dass alle Besucher kurz betroffen waren, oder dass zwei von acht Prüfpunkten über Stunden nicht durchkamen. Für die Bewertung ist das ein Unterschied, für die Kennzahl nicht.
Routing-Erreichbarkeit in den Betriebsalltag holen
Die Routing-Schicht lässt sich von außen nicht steuern, aber beobachten, und beobachtbar zu sein ist der halbe Weg. Wer aus mehreren Netzen misst, Ergebnisse je Standort aufhebt und den Unterschied zwischen Messwert und Messausfall im Protokoll führt, erkennt einen Teilausfall typischerweise in derselben Stunde und nicht in der übernächsten Woche. Der Rest ist Kommunikation: eine Meldung mit drei Angaben, ein benannter Weg zum Anbieter und eine Statusseite, die regionale Störungen benennt. Dass ein Anbieter angekündigte Änderungen rechtzeitig sichtbar macht, gehört in dieselbe Erwartung; wie sich das bei Schnittstellen messen lässt, zeigt Sunset- und Deprecation-Header überwachen. Wer den Aufbau erst einmal ohne eigene Einrichtung sehen möchte, findet in der Demo-Ansicht die Sicht auf mehrere Standorte.
- Prüfpunkte in mindestens drei verschiedenen Netzen eingerichtet, nicht nur an drei Orten
- IPv4 und IPv6 getrennt geprüft und getrennt ausgewertet
- Konsensregel um eine zweite Regel für dauerhaft abweichende Einzelpunkte ergänzt
- Messausfall und Messwert im Protokoll unterscheidbar, keine Nullwerte für Ungemessenes
- Zeitstempel in UTC geführt, Ortszeit nur in der Anzeige
- Ansprechweg beim Hoster für Routing-Meldungen benannt und einmal erprobt
- Statusseite kennt den Zustand teilweise erreichbar
- Fragen zu Herkunftsangaben und maximaler Länge im letzten Anbietergespräch gestellt
Die Anteilswerte stammen aus der Untersuchung ru-RPKI-ready: the Road Left to Full ROA Adoption, veröffentlicht auf der ACM Internet Measurement Conference 2025. Die Werte zur maximalen Präfixlänge stehen in RFC 9319 (BCP 185). Die drei Zustände der Herkunftsprüfung stehen in RFC 6811, die Betriebsempfehlungen in RFC 7454 (BCP 194). Die Begriffsbestimmung stammt aus dem How-To RPKI der Veröffentlichungen des BSI zur Cyber-Sicherheit. Alle Anteile beziehen sich auf den jeweils genannten Stichtag und ändern sich laufend.