Zusammenfassung

  • RFC 10040 ist ein Experimental RFC im IETF Stream. Er beruht auf IETF-Konsens, öffentlicher Prüfung und IESG-Genehmigung, gehört aber nicht zum Internet Standards Track. Laut Dokument bezeichnet Experimental hier die Reife der Technik, nicht ein bereits definiertes Feldexperiment.
  • Das aktuelle IANA-Register führt LCAF-Typ 5 weiterhin als Geo-Coordinates (DEPRECATED) und weist Geo-Location getrennt davon Typ 17 zu. Abgekündigt heißt nicht gelöscht; eine Nummernzuweisung beweist weder Implementierung noch Interoperabilität.
  • Ein belastbarer Migrationsnachweis muss Dokumentstatus, alte und neue Kennzahl, Implementierungs- und Peer-Fähigkeit, tatsächlich gesendete und gelesene Pakete, Fallback, unbekannte Typen sowie Herkunft, Genauigkeit und Zugriffspolitik der Standortdaten getrennt erfassen.

Eine Veröffentlichung, mehrere Beweisketten

Der RFC Editor veröffentlichte RFC 10040 am 15. September 2026. Das Dokument aktualisiert Abschnitt 4.3 von RFC 8060, setzt die als LCAF-Typ 5 definierte Geo-Coordinates-Codierung ab und führt Geo-Location als Typ 17 ein.

Hinter diesem Satz stehen verschiedene Zustände. Die LISP-Arbeitsgruppe brachte einen Text zum Abschluss. Das IESG genehmigte die Veröffentlichung am 15. März. Sechs Monate später erschien der endgültige RFC. IANA bildete die Registeränderung ab. Ob eine konkrete Softwareversion Typ 17 beherrscht und ob zwei produktive Knoten ihn erfolgreich austauschen, ist damit noch nicht beantwortet.

Der Statusblock zieht diese Grenze selbst. RFC 10040 dokumentiert IETF-Konsens, öffentliche Prüfung und IESG-Genehmigung. Zugleich ist er ausdrücklich keine Spezifikation des Internet Standards Track. Konsens beantwortet, welcher Text den IETF-Prozess abgeschlossen hat. Er ersetzt keine Messung laufender Systeme.

Experimental ohne festgelegtes Experiment

Die Einleitung enthält einen ungewöhnlich klaren Satz: Die Arbeit sei nicht Teil eines „Experiments“, denn nicht jeder Experimental RFC müsse zu einem Experiment gehören. Die Einstufung beziehe sich auf den Reifegrad der Technik.

Damit fallen zwei Kurzschlüsse weg. Experimental bedeutet weder grundsätzlich unsicher noch bereits unter kontrollierten Bedingungen erprobt. RFC 7841 beschreibt Untersuchung, experimentelle Implementierung und Bewertung. Für RFC 10040 legt er jedoch keine Hypothese, Testgruppe, Telemetrie, Dauer oder Erfolgsschwelle fest.

Die öffentliche Entstehungsgeschichte enthält Fragen nach früheren Implementierungen, dem Einsatzbedarf, Datenschutz und Positionsgenauigkeit. Der veröffentlichte RFC ist das genehmigte Ergebnis dieser Prüfung. Die noch offenen Betriebsfragen werden dadurch aber nicht zu beobachteten Tatsachen.

Abgekündigt ist nicht verschwunden

Im IANA-Register der LISP-Parameter bleibt Typ 5 als Geo-Coordinates (DEPRECATED) mit Verweisen auf RFC 8060 und RFC 10040 erhalten. Daneben steht Typ 17 als Geo-Location.

Diese Trennung koordiniert die künftige Präferenz, ohne die Vergangenheit umzuschreiben. RFC 10040 behauptet weder, Typ 5 sei aus dem Register entfernt, noch müssten alle Empfänger ihn nun ablehnen, noch hätten alle Sender gewechselt. Die alte Kennzahl bleibt interpretierbar, damit historische Pakete und Software nicht mehrdeutig werden.

Die Abkündigung beginnt daher eine betriebliche Aufgabe. Ein Sender, der nur Typ 17 ausgibt, braucht einen Grund für die Annahme, dass sein Peer ihn verwenden kann. Eine Flotte kann mehrere Versionen enthalten. Ein Controller kann das neue Format schreiben, während ein Analysewerkzeug oder nachgelagerter Validator Typ 5 erwartet. Da RFC 10040 keinen universellen Fähigkeitenaustausch definiert, muss der Nachweis aus Versionsbestand, bilateraler Konfiguration, Testaustausch oder begrenztem Rollout stammen.

Die Kompatibilität ist nicht symmetrisch

Abschnitt 8 trennt EID- und RLOC-Datensätze. Geo-Location-EID-Datensätze setzen Knoten voraus, die Registrierung und Lookup unterstützen. Geo-Location-RLOC-Datensätze können dagegen an einen Knoten zurückgegeben werden, der sie nicht kennt; dieser ignoriert den Datensatz.

Ein unbekannter Typ kann protokollkonform ignoriert werden und die gewünschte Funktion trotzdem ausfallen. Der Sender kann einen gültigen Typ-17-Inhalt erzeugen, das Mapping-System kann ihn transportieren und der Empfänger kann ihn ordnungsgemäß verwerfen. Jeder Baustein folgt seiner lokalen Regel, aber die standortabhängige Entscheidung findet nicht statt.

Der Nachweis muss deshalb gerichtet sein: Welche Komponente und Version sendete welchen Typ? Welcher Peer empfing ihn? Wurde er erkannt, ignoriert oder verwendet? Welcher Fallback hielt die Funktion aufrecht? Die pauschale Aussage „unterstützt RFC 10040“ kann einen gemischten Bestand nicht erklären.

Höhere Feldauflösung schafft keine wahre Position

Typ 17 ergänzt eine explizite Unsicherheit, Millisekundenanteile für Breiten- und Längengrad, Einheiten für die Höhe und einen Radius zur Unterscheidung von Geo-Point und Geo-Prefix. Das verbessert die Darstellung. Die Quelle und Richtigkeit der Koordinaten werden dadurch nicht beglaubigt.

Ein fein aufgelöster Wert kann aus einem veralteten Inventar, einer Fehleingabe oder einer groben Schätzung stammen. Das Unsicherheitsfeld überträgt eine Behauptung zur Genauigkeit; es ist keine unabhängige Messung. Ebenso beweist eine Koordinate weder Einwilligung noch Zugriffsberechtigung oder rechtmäßige Speicherung.

RFC 10040 behandelt lokale Zugriffsregeln, die Durchsetzung durch einen Mapping Service Provider, signierte oder verschlüsselte Antworten, Geo-Prefix zur Datenminimierung und kurze TTLs zur Begrenzung der Exposition. Als typische Objekte nennt er öffentliche Bauwerke, Orte und Landmarken statt Personen, Fahrzeuge oder Geräte. Wirksam sind diese Grenzen erst, wenn sie konfiguriert und beobachtet werden.

Ein Reife- und Migrationsbeleg

Die erste Ebene hält die Dokumentprovenienz fest: IETF Stream, Kategorie Experimental, Genehmigungs- und Veröffentlichungsdatum, Abschnitt 4.3 von RFC 8060, abgekündigter Typ 5 und zugewiesener Typ 17. Ein späteres Erratum oder eine Statusänderung kommt als neues datiertes Ereignis hinzu.

Die zweite Ebene beschreibt die Kompatibilität: Implementierung und Version, unterstützte Datensatzrollen, Methode zur Feststellung der Peer-Fähigkeit, tatsächlich gesendete und gelesene Codierung, Ergebnis bei unbekanntem Typ, Dual-Read- oder Fallback-Zeitraum, Testumfang, Fehler, Korrekturverantwortung und Ausstiegskriterium. „Akzeptiert beide Typen“ muss zwischen reinem Parsing, produktiver Nutzung und aktivem Rückfall unterscheiden.

Die dritte Ebene beschreibt die Standortnutzung: Herkunft der Koordinaten, behauptete und gemessene Genauigkeit, Geo-Point oder Geo-Prefix, Zugriffsregel, Autorisierungsmechanismus, TTL oder Aufbewahrung, nachgelagerte Nutzer und Korrekturweg. Nicht beobachtet, nicht getestet, nicht unterstützt, ignoriert und Parsing-Fehler dürfen nicht zu einem einzigen Status zusammenfallen.

Die Veröffentlichung schafft ein Koordinationsartefakt. IANA koordiniert die Kennzahl. Erst wenn Software sie ausführt, Peers interoperieren und Betreiber die Folgen in einem benannten Beobachtungsfenster akzeptieren, ist Migration eine belegte Tatsache.

Quellen und Grenzen

Die wesentlichen Quellen sind RFC 10040, die Mitteilung des RFC Editor, die Datatracker-Historie, das IANA-Register, RFC 8060, RFC 7841 und RFC 6973. Die Errata-Suche zu RFC 10040 lieferte am 21. September 2026 keine Treffer.

Diese Quellen belegen Dokument-, Register- und Protokollzustände. Sie enthalten keine vollständige Implementierungsmatrix, keine Einsatzstatistik, keine Paketmitschnitte, keinen Migrationskalender, kein Genauigkeitsaudit und keinen Einwilligungsnachweis. Diese Lücke begrenzt die Aussage; sie beweist nicht, dass es keine Implementierung gibt.