Zusammenfassung

  • Der 64-Bit-Forward-Route-Identifier aus RFC 1475 war nur für den Router verständlich, der ihn seinem unmittelbaren Nachbarn ausgegeben hatte, und wurde normalerweise an jedem Hop ersetzt.
  • Null, ungültige Werte, Aggregation, Routenwechsel, Flows und Protokollkonvertierung konnten eine neue lokale Entscheidung erzwingen.
  • Experimental, die Weiterentwicklung zu CATNIP und der spätere Status Historic belegen eine Dokumentgeschichte, nicht Implementierung, Produktionseinsatz oder den Weg eines konkreten Pakets.

Eine Speicheradresse auf Reisen

Die im Juni 1993 veröffentlichte RFC 1475 beschrieb TP/IX, auch Internet Protocol version 7 genannt. Der Vorschlag verband längere Adressen und veränderte Transportfelder mit schnelleren Routen- und Flowmechanismen. Jedes Datagramm sollte einen 64 Bit breiten forward route identifier enthalten.

Der Name klingt nach einem stabilen Namen für einen vollständigen Pfad. Der Text erlaubt jedoch, dass ein Router als Kennung einen Tabellenindex oder sogar eine tatsächliche Speicheradresse verwendet. Damit ist die Reichweite klar: Die Zahl verweist auf die interne Wirklichkeit genau einer Maschine. Ein anderer Router besitzt weder denselben Adressraum noch dieselbe Tabelle.

Der ausstellende Router teilte seinem vorgelagerten Nachbarn die Kennung mit. Dieser musste sie nicht verstehen, sondern nur in Pakete einsetzen, die er an den Aussteller zurücksandte. Das Feld machte also einen privaten Verweis transportierbar, ohne seine Semantik öffentlich zu machen.

Ein Paketmitschnitt kann die Bits erhalten und dennoch die Bedeutung verlieren. Ohne Aussteller, Generation des Zustands und Gültigkeitszeitpunkt ist eine Speicheradresse außerhalb ihrer Maschine kein Beleg, sondern eine Zahl mit verschwundenem Wörterbuch.

A, B und C verliehen dem Feld jeweils neuen Sinn

Das Beispiel der RFC stellt die Hosts X und Y an die Enden und die Router A, B und C dazwischen. C kündigt B eine Route zu Y an und liefert eine C-interne Kennung. B bewahrt sie als undurchsichtigen Wert auf. Danach richtet B seine Route über C ein und kündigt A eine andere, B-interne Kennung an.

X sendet das erste Datagramm mit Null. A führt eine gewöhnliche Zielsuche aus, wählt B, schreibt Bs Kennung in das Feld und leitet weiter. B kann seinen eigenen Verweis interpretieren, findet die Route über C, überschreibt das Feld mit Cs Kennung und sendet. C verbraucht den von ihm ausgestellten Verweis, setzt das Feld vor dem letzten Stück zurück und leitet an Y. Der Zielhost erkennt seine Adresse und ignoriert die Kennung.

Das Feld blieb an derselben Stelle, doch seine Autorität wechselte. Am Ausgang von A berichtete es, was B A zuvor geliehen hatte. Am Eingang von B konnte es direkt auf Bs Zustand zeigen. Am Ausgang von B gehörte es bereits C. Am Ziel hatte es keine notwendige Funktion.

Derselbe Zahlenwert könnte auf zwei Routern verschiedene Objekte benennen; verschiedene Werte könnten über denselben physischen Link führen. Wer daraus „die Route“ macht, unterschlägt Aussteller, Zielprüfung, Zeit, Ersetzung und tatsächlichen Ausgang.

Null und ungültig waren Wege zurück zur normalen Entscheidung

Null bedeutete nicht „keine Route“. X hatte lediglich keinen brauchbaren geliehenen Verweis für A. Der Router schlug das Ziel in seiner eigenen Tabelle nach und setzte für den nächsten lokalen Übergang eine Kennung ein.

Auch ein ungültiger Wert sollte den Weg nicht automatisch beenden. Gerade bei einer möglichen Speicheradresse musste ein Router Bereich und Ausrichtung prüfen und wohl auch sicherstellen, dass das referenzierte Routenobjekt zum Ziel des Datagramms passte. Scheiterte die Prüfung, sollte er die Kennung still ignorieren und die normale Zielsuche ausführen.

Damit blieb Korrektheit vom schnellen Zugriff getrennt. Der Verweis konnte Arbeit sparen; Zieladresse und lokale Tabelle blieben die Wiederherstellungsinstanz. Eine akzeptierte Kennung belegt weder den tatsächlichen Ausgang noch Empfang beim nächsten Hop oder Zustellung. Eine verworfene Kennung belegt umgekehrt keine Unerreichbarkeit.

Die RFC erklärte zudem, Sicherheitsfragen seien nicht behandelt. Bereichs-, Ausrichtungs- und Zielprüfung sind keine Authentifizierung, Autorisierung oder Integritätssicherung. Ein interner Handle wird durch Plausibilitätsprüfung nicht zum Berechtigungsnachweis.

Aggregation machte die Grenze sichtbar

Eine eingehende Kennung konnte lediglich auf eine aggregierte Route verweisen. Dort, wo sich die Komponenten auf unterschiedliche Ausgänge verteilen, musste der Router das konkrete Ziel untersuchen, eine spezifische Route wählen und die passende Kennung des folgenden Routers einsetzen. Das geliehene Wissen endete, sobald seine Auflösung zu grob wurde.

Eine Routenänderung erzeugte dieselbe Grenze in der Zeit. RFC 1475 schrieb, bei Änderungen während des Fluges müsse ein Router entscheiden, wie jedes Datagramm wieder auf ein Gleis gesetzt werde. Das paketgetragene Feld fror die Routingtabellen nicht ein. Zwischen Ausgabe und Nutzung konnte der private Zustand veralten.

Der Mechanismus rückte Zustand näher an das Paket, ohne zu behaupten, der Zustand habe das Routing verlassen. Er konnte Wissen zwischen zwei Nachbarn bewahren. Er konnte aus einer Folge veränderlicher lokaler Entscheidungen keine dauerhafte globale Tatsache machen.

Auch ein Flow blieb privater Zustand

TP/IX erlaubte, die Routenkennung durch eine Flowkennung zu ersetzen. Jeder Router konnte ein privates Flowobjekt halten, das auf die beim Aufbau verwendete Route zeigte. Datagramme konnten in einen Flow eintreten oder ihn verlassen.

Wie ein Router seine Routen- von seinen Flow-IDs unterschied, blieb intern. Für den Absender war der Wert undurchsichtig und implizit nur für den nächsten Hop bestimmt. Ein Wert ungleich Null bewies daher weder Reservierung noch Kapazität, Dienstgüte oder Erfolg. Dazu wären Objekttyp, Generation, verknüpfte Route, Nutzungszeit und Weiterleitungsergebnis des Ausstellers nötig.

Diese Privatheit war eine Stärke: Implementierer mussten ihre internen Strukturen nicht standardisieren. Sie setzt aber auch eine Beweisgrenze. Ein externer Sammler darf den Wert nicht zum selbstbeschreibenden Protokollobjekt erheben.

RAP verband den Handle mit einer zeitgebundenen Aussage

Die begleitende RFC 1476 beschrieb das Route Access Protocol. Add Route musste eine Route anbieten, die zum Zeitpunkt der Ankündigung tatsächlich in der Weiterleitungsdatenbank des Senders geladen war. Der empfangende Peer setzte die angebotene 64-Bit-Kennung in Datagramme ein, die er zurücksandte.

Das war mehr als eine Absicht, aber weniger als Dauerhaftigkeit. „Beim Angebot geladen“ heißt nicht „für immer geladen“. Purge Route sollte die Route löschen und bei Peers widerrufen, an die sie weitergegeben worden war. Die Spezifikation bevorzugte den Versand der Löschung vor der lokalen Entfernung, räumte aber ein, dass diese Reihenfolge nicht vorgeschrieben werden konnte.

Zwischen lokaler Löschung, Purge-Versand, Verbreitung und fliegenden Paketen lagen mehrere Uhren. Eine Kennung konnte ein früheres Angebot korrekt dokumentieren und für den gegenwärtigen Zustand nutzlos sein. Der Informationsdatensatz zu RFC 1476 bestätigt die Dokumentidentität, nicht die operative Zeitlinie eines Netzes.

Konvertierung setzte die Kennung bewusst auf Null

TP/IX sollte IPv4- und IPv7-Systeme in beliebiger Reihenfolge aufrüstbar machen. Konvertierungspunkte wurden damit zu Verwahrungsgrenzen. Die Option „Don't Convert“ regelte das Verhalten von Routern auf dem Draht, während ein Host intern weiterhin umwandeln konnte. Fragmente, die verschiedene Wege nahmen und unterschiedliche Konverter erreichten, konnten verloren gehen. Eine hybride IPv7-Adresse belegte noch keine native IPv7-Implementierung.

Bei der Umwandlung von IPv4 zu IPv7 wurde die Vorwärtskennung auf Null gesetzt. Der Konverter kopierte keinen unverständlichen privaten Verweis in eine andere Architektur, um Kontinuität vorzutäuschen. Er verlangte vom nächsten Bereich eine neue Entscheidung. Adresse, Version, Konvertierungsaktion, Fragmente, Kennung und Zustellung blieben getrennte Tatsachen.

Der Status Historic beantwortet eine andere Frage

Der RFC-Editor-Datensatz führt RFC 1475 heute als Historic. RFC 1752 hielt fest, dass TP/IX in CATNIP überging, bewertete CATNIP als zu unvollständig für die Auswahl und empfahl das 128-Bit-SIPP als Grundlage für IPng. RFC 6814 setzte RFC 1475 später bei der Bereinigung veralteter IPv4-Optionen formell außer Kraft. RFC 791 blieb die IPv4-Grundlage.

Diese Kette belegt Vorschlag, Bewertung und Dokumentstatus. Sie belegt nicht, dass nie eine Komponente implementiert wurde oder ein bestimmtes Versuchsnetz nichts davon nutzte. Umgekehrt bewiesen Veröffentlichung und der Titel „The Next Internet“ keinen Produktionseinsatz.

Spezifikation, Empfehlung, laufender Code, Gerätezustand, beobachtetes Paket und Zustellergebnis gehören zu verschiedenen Realitätsebenen. Sorgfältige Technikgeschichte lässt jede davon ihre eigene Aussage tragen.

Quellen