Zusammenfassung

  • IPv4-Option 7 reservierte eine endliche Folge von Vier-Oktett-Feldern, in die kooperierende Weiterleitungssysteme Adressen eintragen konnten, ohne den Weg zu bestimmen.
  • Begrenzter Platz, fehlende Authentisierung und die Offenlegung der Topologie führten von der Verarbeitung als Routerstandard zur späteren Empfehlung, solche Pakete standardmäßig zu verwerfen.

Vier Oktette pro Eintrag

Der Absender legte Länge und Datenbereich vor dem Versand fest und initialisierte die Felder mit Nullen. Nach Typ und Länge zeigte ein Zeiger auf den nächsten freien Platz. Sein kleinster zulässiger Wert war 4; nach jeder 32-Bit-Adresse rückte er um vier Oktette weiter.

Ein Internetmodul, das das Datagramm weiterleitete, trug laut RFC 791 seine Adresse so ein, wie sie in der Umgebung der Weiterleitung bekannt war. RFC 1812 konkretisierte dies für Router: einzutragen war die IP-Adresse der logischen Ausgangsschnittstelle oder bei einer unnummerierten Schnittstelle eine stabile Router-ID. Der Eintrag bezeichnete damit die bei diesem Ausgang verwendete Identität, nicht zwingend das gesamte physische Gerät.

Der Bereich konnte unterwegs nicht wachsen. Stand der Zeiger hinter der Länge, war er voll und das Paket wurde ohne weiteren Eintrag weitergeleitet. Blieben nur ein bis drei Oktette übrig, war zwar Platz vorhanden, aber nicht für eine vollständige Adresse. RFC 791 erklärte das ursprüngliche Datagramm dann für fehlerhaft und verlangte das Verwerfen; eine ICMP-Parameter-Problem-Meldung durfte folgen. Die Option erschien höchstens einmal und wurde bei Fragmentierung nur im ersten Fragment geführt.

Auch die Obergrenze von neun Adressen ergibt sich aus dem Format. Ein IPv4-Header ist höchstens 60 Oktette lang, 20 davon sind der feste Teil. Nutzt Record Route fast alle übrigen 40, bleiben nach Typ, Länge und Zeiger 37 Oktette—genug für neun vollständige Adressen. Das ist eine rechnerische Höchstzahl ohne konkurrierende Optionen, keine Zusage über neun sichtbare Hops.

Beobachten, ohne zu lenken

Loose und Strict Source and Record Route enthielten vom Absender vorgegebene Zwischenziele und beeinflussten die Weiterleitung. Typ 7 tat das nicht. Das normale Routing bestimmte den Weg; Record Route bat lediglich die tatsächlich beteiligten Systeme um einen Eintrag.

Eine solche Liste war kein authentisierter Nachweis. Weder Signatur noch dauerhafte Geräteidentität oder Vollständigkeitsbeleg gehörten zum Format. Leere Felder konnten einen kurzen Pfad bedeuten, aber ebenso Filterung, unverändertes Durchreichen, fehlende Implementierung, Fragmentierung oder einen unerwarteten Weg. Ein Eintrag belegt die Mitwirkung eines Systems an einer beobachteten Reise; ein fehlender Eintrag belegt nicht dessen Abwesenheit.

RFC 1122 stellte Erzeugung und Verarbeitung für Hosts frei. Bei ICMP Echo sollte eine empfangene Record-Route-Option jedoch aktualisiert und ungekürzt in die Antwort übernommen werden, sodass eine Hin-und-Rück-Aufzeichnung entstand. Dieser Diagnosewert hing bereits von vielen unabhängigen Verwaltungsentscheidungen ab.

Die Umkehr des Standards

RFC 1812 verpflichtete Router 1995 zur Unterstützung in weitergeleiteten Paketen. Eine Einstellung durfte Record Route unverändert lassen, musste aber standardmäßig die Aufzeichnung aktivieren. Die mögliche Offenlegung der Netztopologie wurde anerkannt, ohne die Kooperation als Normalfall aufzugeben.

RFC 7126 setzte 2014 einen anderen Ausgangspunkt. Typ 7 konnte beim Kartieren eines Netzes helfen, auch wenn der knappe Headerplatz den Nutzen begrenzte. Blockierung zerstörte RR-abhängige Diagnoseverfahren, nicht gewöhnliches Ping; durch verbreitetes Verwerfen waren solche Verfahren auf beliebigen Pfaden ohnehin nahezu unbrauchbar. Empfohlen wurde daher ein eigener Schalter für Verwerfen, Ignorieren oder vollständiges Verarbeiten—mit dokumentiertem Standardwert „verwerfen“.

Quellen