DATAHUB-IX
Docs

RPKI ROV.

Jedes Routen-Announcement, das die DATAHUB-IX-Route-Server empfangen, wird gegen RPKI validiert. Invalid-Announcements werden verworfen – Punkt.

So funktioniert es

Wir betreiben drei unabhängige Routinator-Instanzen (eine pro Live-PoP), die jeweils von den fünf RIR Trust Anchors ziehen. Die Validatoren versorgen die Route Server über das RPKI-RTR-Protokoll mit einer SLURM-fähigen Aktualisierung alle 5 Minuten.

Das Validierungsergebnis wird als Community auf akzeptierten Prefixen kodiert:

  • 202192:2000 — RPKI valid
  • 202192:2001 — NotFound (keine abdeckende ROA)
  • Invalid-Announcements werden verworfen, bevor das Prefix in die RIB gelangt.

Live-Zähler (letzte 24 h)

1.2M
Routes evaluated / day
640
Average invalid drop / day
3 nodes
Validators (Routinator)
< 5 min
Cache freshness

Eigene ROAs publizieren

Mitglieder sind verpflichtet, ROAs für jedes announcete Prefix zu publizieren. Die meisten RIRs bieten Hosted RPKI in ihren Mitgliederportalen an:

Stolperfalle maxLength

Setzen Sie maxLength nicht weiter als Ihr spezifischstes Announcement. Ein häufiger Fehler ist, eine einzelne ROA mit maxLength=24 für ein /22 anzulegen – das öffnet Forged-Origin-Angriffe für jedes Sub-Prefix, das Sie nie announcen. Halten Sie ROAs so eng wie Ihre tatsächlichen Announcements.

Validierungsstatus prüfen

# Öffentliche Validatoren, die RIR-Daten spiegeln:
$ dig +short txt 198.51.100.0/24.origin.asn.cymru.com
$ curl -s https://rpki-validator.ripe.net/api/v1/validity/AS65500/198.51.100.0/24

# Oder via DATAHUB-IX Looking Glass:
rs1.fks> show route 198.51.100.0/24 | match validation

BGPSec & ASPA

BGPSec wird auf den Route Servern noch nicht erzwungen. Die ASPA-Validierung (Autonomous System Provider Authorization) steht für 2026 Q4 auf der Roadmap – sobald der IETF-Entwurf zum RFC wird.