Zusammenfassung

  • draft-ietf-lisp-site-external-connectivity-05 erlaubt eine nicht leere pETR-RLOC-Menge, wenn ein Ziel extern, unbekannt oder bekannt, aber nicht registriert ist.
  • Die Antwort bestimmt einen Ausgang innerhalb eines IID und einer Policy. Sie entdeckt weder das Ziel noch bestätigt sie den nativen Pfad hinter dem pETR oder das Anwendungsergebnis.
  • Registrierung, Auswahl, Cache-Zustand, Entkapselung, externe Weiterleitung und Dienstabschluss brauchen getrennte Nachweise.

RFC 9301 kennt Negative Map-Replies ohne Locator und mit einer zeitlich begrenzten Aktion. Die am 30. September 2026 eingereichte Revision 05 nutzt weiterhin das Verfahren zur Berechnung eines non-LISP „hole“, verlangt in der Antwort aber eine RLOC-Anzahl größer null. Die RLOCs zeigen auf Proxy-ETRs, die externen Verkehr übernehmen sollen.

Damit wird das fehlende EID nicht registriert. Der Mapping-Dienst hat eine Regel für die Klasse „extern oder unbekannt“ gefunden. Das ähnelt einer dynamischen Default Route. Die betriebliche Wirkung ist nützlich; die semantische Grenze muss sichtbar bleiben.

Das Loch bleibt unbekannt

Eine korrekte Speicherung enthält sowohl unknown_or_unregistered als auch external_exit_selected. Ein pauschales resolved=true würde die Unsicherheit löschen, die den Mechanismus überhaupt ausgelöst hat.

Das zeigt sich im Fehlerfall. Der Map-Reply kann korrekt sein, obwohl Pakete hinter dem pETR scheitern: Native Route, Upstream-Filter, Gegenstellen-Policy, Überlast oder Anwendung können die Ursache sein. Eine erneute erfolgreiche Abfrage belegt nur erneut die Ausgangswahl.

Mindestens fünf Belege bleiben getrennt. Die pETR-Registrierung zeigt eine Kandidatenbehauptung. Die Mapping-Entscheidung zeigt die Serverauswahl. Ein Cache-Readback zeigt den beabsichtigten ITR-Zustand. Entkapselungszähler zeigen Ankunft am Gateway. Ein Anwendungsbeleg zeigt einen entfernten Erfolg. Kein früherer Beleg unterschreibt den nächsten Schritt.

Registrierung ist eine Eignungsbehauptung

Ein pETR mit externer Verbindung kann sich pro VPN Instance ID registrieren. Die Nachricht enthält einen konfigurierbaren Distinguished Name, ein RLOC-Set und gegebenenfalls VPN-Kontext. Vendor-spezifisches LCAF darf Angaben zu Standort, Ressourcen oder Performance tragen.

Authentifizierung sagt, wer diese Angaben gesendet hat. Eine eigene Zulassungsregel muss klären, ob dieser Akteur für das IID handeln durfte, die RLOCs kontrollierte und welche Prüfung die externe Verbindung bestätigte. Eine signierte, aber unberechtigte Registrierung bleibt falsch; eine berechtigte Registrierung kann nach einem Upstream-Ausfall veralten.

RFC 9306 definiert den Behälter für Vendor-Formate, nicht eine gemeinsame Messsemantik. „Verfügbarkeit“ kann Konfiguration, lokale Beobachtung oder Controller-Schätzung bedeuten. Ohne Produzent, Schema, Einheit, Zeitfenster, Methode, Konfidenz und Gültigkeit ist der Wert ein Policy-Hinweis, keine objektive Wegmessung.

Priority und Weight drücken Absicht aus

RFC 9300 bevorzugt niedrigere Priority-Werte und verteilt bei gleicher Priority anhand relativer Weights. Diese Felder steuern die Auswahl, beweisen aber weder Kapazität noch Latenz, Kosten, Pfadunabhängigkeit oder die tatsächliche Verteilung.

Mehrere RLOCs können auf dasselbe Gerät oder denselben Provider zulaufen. 70/30 kann eine Geschäftsregel statt gemessener Bandbreite sein. Ein prüfbarer Entscheidungsbeleg bewahrt deshalb Kandidaten vor der Filterung, Ausschlussgründe, Metadaten-Snapshot, Policy-Version, Tie-Break und Sollverteilung. Per-pETR-Zähler zeigen anschließend die Istverteilung.

Wenn Gateways ihre eigenen Leistungswerte liefern, entsteht zudem ein Anreiz zur optimistischen Selbstdarstellung. Herkunft und Messmethode sind daher Governance-Daten, keine dekorativen Details.

Map-Notify-Ack endet in der Steuerungsebene

RFC 9437 erlaubt abonnierte Updates per Map-Notify, geschützt durch Nonce und Security Association und bestätigt durch Map-Notify-Ack. Ohne Pub/Sub empfiehlt Revision 05 kürzere TTLs.

Das ACK bestätigt eine Kontrollnachricht, nicht die Programmierung jeder Forwarding-Struktur und nicht die Paketzustellung. Eine kurze TTL begrenzt das gewünschte Alter, garantiert aber keinen Refresh.

Die Automationskette sollte einzeln protokollieren: Update authentifiziert, Scope akzeptiert, Write ausgeführt, Readback identisch, Daten-Canary erreicht pETR, externer Canary passiert das Gateway, Anwendung antwortet. Der erste fehlende Beleg lokalisiert die Untersuchung.

Default bedeutet größter Wirkungsbereich

Der ITR darf einen hole prefix oder einen Default-Map-Cache-Eintrag installieren. Bekannte EID-Blöcke sollen als spezifischere Einträge weiterhin Map-Requests erzwingen. Sonst könnte die breite externe Regel normale EID-Auflösung verschlucken.

Ein Default spart Arbeit, verschiebt mit einer Änderung jedoch viele unabhängige Flüsse. Damit wechseln möglicherweise Beobachtungspunkt, Kosten, Jurisdiktion und Sicherheitskontrolle. Der Rollout sollte mit engem IID, geschützten Präfixen, Canary-ITRs und begrenzter TTL beginnen. Der Rollback demotiert nur den betroffenen pETR, statt fremde Caches zu leeren.

Der Datatracker-Eintrag beschreibt einen Experimental Internet-Draft, keinen RFC und keinen Implementierungs- oder Interoperabilitätsbericht. Der AI-Infrastruktur-Fall ist eine Motivation, kein Nachweis für den Einsatz in einem benannten Netz.

Lu Hengs Reality Layers liefern die passende Prüfsprache: Distinguished Name ist Symbol, Map-Reply Entscheidung, Cache Zustand, Paket physische Wirkung und Remote-Antwort Ergebnis. Vertrauen entsteht, wenn die Verbindungen erhalten bleiben, nicht wenn alles als „resolved“ erscheint.

Quellen