Zusammenfassung

  • LAC-2026-3 wurde am 12. August veröffentlicht und wird noch beraten. Organisationen müssten vor zusätzlichen IPv4- oder IPv6-Ressourcen mindestens 80 Prozent gültige ROA-Abdeckung für ihre bereits von LACNIC zugeteilten oder verteilten Ressourcen nachweisen.
  • Der Entwurf entzieht Inhabern unterhalb der Schwelle nicht automatisch ihre heutigen Bestände. Er nutzt den nächsten Wachstumsantrag als Anlass zur Bereinigung bestehender RPKI-Daten und ist noch keine geltende Regel.
  • Offen sind vor allem Nenner und Maßeinheit, die getrennte Behandlung von IPv4 und IPv6, eine Nachbesserungsfrist sowie eine Stelle, die strittige Berechnungen tatsächlich erneut prüft.

Der Prüfpunkt trifft wachsende Netze zuerst

Die unabhängige Übersicht der RIR-Vorschläge führt LAC-2026-3 als „Under discussion“ mit Änderungsdatum 12. August 2026. Der Vorschlag geht über eine RPKI-Empfehlung hinaus: Wer zusätzliche IPv4- oder IPv6-Ressourcen beantragt, soll zuvor 80 Prozent gültige ROA-Abdeckung für die schon von LACNIC erhaltenen Bestände erreichen.

Der Zeitpunkt schafft den Anreiz. Eine Organisation ohne neuen Bedarf trifft die Prüfung vorerst nicht. Ein Zugangsanbieter mit neuen Kunden, ein Hoster mit zusätzlichem Standort oder ein öffentliches Netz im Ausbau kann dagegen vom Ergebnis abhängen. Aus einer Sicherheitsaufgabe ohne Termin wird ein möglicher Engpass im Ausbauplan.

Das ist keine bereits vollzogene Sanktion. Unter 80 Prozent zu liegen bedeutet nach dem vorliegenden Entwurf nicht den Verlust bestehender Adressen. Weder Annahme noch Umsetzung sind erfolgt. Zur Debatte steht eine künftige Voraussetzung für zusätzliche Ressourcen.

Achtzig Prozent wovon?

Abdeckung kann unterschiedlich gezählt werden. Die RPKI-Anzeigen von Cloudflare Radar bieten sowohl den Anteil abgedeckter Präfixe als auch den Anteil abgedeckten Adressraums und trennen IPv4 von IPv6. Dieselbe Organisation kann je nach Methode bestehen oder scheitern.

Bei einem großen Block und mehreren kleinen Blöcken zählt jedes Präfix gleich, wenn die Präfixzahl der Nenner ist. Nach Adressmenge überwiegt der große Block. Werden nur angekündigte Ressourcen erfasst, fallen Reserven heraus. Werden alle registrierten Ressourcen erfasst, bleibt zu klären, welchen Zweck ein ROA für nicht angekündigten Raum erfüllt. Bei Unterzuweisungen kann zudem ein Kunde die reale Originierung steuern.

IPv4 und IPv6 lassen sich nicht sinnvoll in einer gemeinsamen Adresszahl addieren. Der Text muss sagen, ob beide Familien getrennt 80 Prozent erreichen müssen, ob nur die beantragte Familie zählt und wie das Fehlen einer Familie behandelt wird. Ohne veröffentlichte Formel ist die präzise Zahl nur scheinbar präzise.

Ein ROA bestätigt eine konkrete Origin-Autorisierung

RFC 6482 beschreibt den ROA als signiertes Objekt, mit dem ein Adressinhaber einem autonomen System die Originierung eines oder mehrerer Präfixe erlaubt. maxLength kann zulässige spezifischere Ankündigungen begrenzen. Die Cloudflare-Erklärung für den Betrieb zeigt, wie die verifizierbare Zuordnung von Präfix und Origin-ASN in Routing-Filter einfließt.

Das ist starke, aber begrenzte Evidenz. Ein gültiges Objekt garantiert nicht die Korrektheit jeder beobachteten Route oder den identischen Datenstand aller Validatoren. Ein fehlender ROA beweist umgekehrt keinen Hijack. Die Regel sollte Objektgültigkeit, Bestandsabdeckung und Live-Routenstatus nicht zu einem pauschalen Konformitätsurteil vermischen.

Normale Änderungen erzeugen vorübergehende Abweichungen. Bei einer Migration wechselt der Origin-ASN. Ein spezifischeres Präfix überschreitet einen alten maxLength. Ein ROA läuft aus oder ist während des Austauschs kurz nicht sichtbar. Eine einzelne Momentaufnahme ohne Heilungsfrist kann so ein Repository-Problem in eine Kapazitätsverzögerung verwandeln.

Ein wirksamer Anreiz braucht ein überprüfbares Verfahren

Der erwartete Nutzen ist plausibel. Appelle zur RPKI-Pflege verlieren gegen akute Betriebsaufgaben. Hängt ein Antrag vom Zustand des Bestands ab, werden veraltete Autorisierungen gelöscht, fehlende ROAs ergänzt und Origin-ASNs geprüft. Andere Netze erhalten bessere Daten für die Origin-Validierung.

Sobald die Kennzahl aber einen Antrag anhalten kann, wird sie zur Verwaltungsentscheidung. Die unabhängige Darstellung der LACNIC-Aufgaben nennt Vergabe und Registrierung von Nummernressourcen als Kernfunktion. LAC-2026-3 verbindet diese Funktion mit Sicherheitsnachweisen über frühere Zuteilungen.

Lu Heng unterscheidet im Policy Mirror zwischen einem schlanken, genauen Register und weitergehenden Bedingungen für den Zugang zu knappen Ressourcen. ROAs hängen unmittelbar mit Adressen zusammen; durchgesetzt würde ihre Pflege jedoch bei der nächsten Vergabe. Daher gehören Einsicht, Korrektur und Widerspruch zur technischen Qualität der Regel.

Zu jeder Abweichung gehört ein Reparaturweg

Eine überarbeitete Fassung sollte Zähler, Nenner, Validierungszeit und ein vollständiges Beispiel veröffentlichen. Antragsteller brauchen eine genaue Liste der wertmindernden Ressourcen und getrennte Gründe: kein ROA, ungültiges Objekt, falscher ASN, nicht abgedeckte Länge oder strittige Zuordnung.

Für behebbare Fehler ist eine Frist nötig, ohne dass der Antrag seinen Platz verliert. Störungen des Repositories oder Validators dürfen nicht dem Antragsteller zugerechnet werden. Notwendige Ausnahmen müssen eng, dokumentiert und prüfbar sein statt Ergebnis vertraulicher Verhandlungen.

Die Überprüfung muss Bestand, RPKI-Snapshot und Formel neu ansehen können. Aggregierte Grundcodes würden später zeigen, ob die Regel echte Vernachlässigung behebt, Textlücken offenlegt oder vor allem Verwaltungssperren erzeugt.

Die 80 Prozent können zu einem brauchbaren Wartungsminimum werden. Heute sind sie Teil eines nicht beschlossenen Vorschlags. LAC-2026-3 hat einen wirkungsvollen Moment gewählt: den Wachstumswunsch. Ob daraus nachvollziehbare Korrektur oder ein unerklärtes Nein entsteht, entscheidet die nächste Fassung.

Quellen