Zusammenfassung

  • Die ICMP-Erweiterung für MPLS bewahrt den Label-Stack beim Eingang eines Pakets, den ein gewöhnliches Zitat des IP-Datagramms nicht enthält.
  • Eine ausdrückliche Längenangabe erlaubte längere Zitate, während ältere Programme Erweiterungen nur hinter genau 128 Oktetten fanden.
  • Der zusätzliche Datensatz liefert weder einen vollständigen Pfad noch weltweit eindeutige Label-Identitäten. Seine Sichtbarkeit bleibt von Verarbeitung, Zustellung und Offenlegung abhängig.

Der Preis eines längeren Zitats

Die Entscheidung klingt zunächst eindeutig: Wenn eine Fehlermeldung mehr vom ursprünglichen Paket enthalten darf, sollte der Sender diesen Platz nutzen. Ein längerer Ausschnitt könnte dem Empfänger mehr Zusammenhang liefern.

Bei mehrteiligen ICMP-Nachrichten war diese Verbesserung jedoch mit einer Bedingung verbunden. Manche bereits vorhandenen Programme erwarteten die Zusatzinformationen immer hinter einem Zitat von genau 128 Oktetten. Ein längeres Zitat verschob den Beginn der Erweiterung. Ein neuer Empfänger konnte der mitgesendeten Länge folgen; ein alter suchte weiterhin an seiner vertrauten Stelle.

RFC 4884 beschrieb diesen Konflikt im April 2007. Es ging nicht um eine theoretische Begegnung mit beliebig alter Software. Der Text hielt fest, dass seit 1999 Implementierungen Erweiterungen versandten, die eine feste Position verwendeten und die nun vorgesehene Längenangabe nicht setzten.

Der Standard konnte eine bessere Grenze definieren. Er konnte nicht nachträglich dafür sorgen, dass jeder vorhandene Parser diese Grenze verstand. Wer mit solchen Programmen kompatibel bleiben wollte, musste sein Zitat weiterhin auf genau 128 Oktette begrenzen. Wer darauf verzichten konnte, durfte mehr einschließen, innerhalb der übrigen Nachrichtengrenzen.

Dieser kleine Zielkonflikt erschließt eine größere Geschichte. Die zusätzliche Information war wertvoll, weil die bisherige Fehlermeldung gerade jene Daten ausließ, anhand deren ein MPLS-Router weitergeleitet hätte.

Was vor der Fehlerbehandlung verschwand

Ein MPLS-gekapseltes IP-Datagramm trägt einen Label-Stack vor dem IP-Header. Kann ein Label Switching Router das Datagramm nicht zustellen, kann er den Stack entfernen und das freigelegte IP-Datagramm der Fehlerbehandlung übergeben. Die erzeugte ICMP-Nachricht nennt dann einen Fehler und zitiert den IP-Header samt Anfang des Nutzinhalts.

Nichts daran muss falsch sein. Trotzdem fehlt der eingegangene Label-Stack. Das Zitat bewahrt den Inhalt einer anderen Verarbeitungsebene als jener, die für die Weiterleitung maßgeblich gewesen wäre.

RFC 4950, veröffentlicht im August 2007, machte diese Lücke ausdrücklich zum Gegenstand. Der neue MPLS Label Stack Entität sollte ausgewählten Fehlermeldungen den Stack hinzufügen, wie er am meldenden Router angekommen war. Das IP-Zitat musste weiterhin enthalten sein.

Es war also keine Ablösung eines alten Belegs durch einen vermeintlich besseren. Die beiden Belege ergänzten sich. Das IP-Zitat ordnete den Fehler der ursprünglichen Kommunikation zu; der zusätzliche Stack machte einen Teil des Weiterleitungskontexts sichtbar.

Der ältere Zweck lässt sich in RFC 792 vom September 1981 nachlesen. Für Time Exceeded war dort der IP-Header mit den ersten 64 Datenbits vorgesehen. Diese acht Datenoktette sollten unter anderem helfen, die Nachricht dem richtigen Prozess zuzuordnen. Daraus folgt nicht, dass sämtliche späteren ICMP-Implementierungen immer nur acht Nutzdatenoktette zurückgeben durften. Es erklärt vielmehr, welche Frage die frühe Quote beantworten sollte.

Lokale Zahlen, gemeinsame Darstellung

MPLS-Labels sind keine verkürzten globalen Gerätenamen. RFC 3031 beschrieb sie im Januar 2001 als lokal bedeutsame Kennungen für Weiterleitungsäquivalenzklassen. Ein Label ist auch keine bloße Kodierung der IP-Zieladresse.

Die Bedeutung einer Zahl ergibt sich aus der Bindung im jeweiligen Kontext. Zwei Router können denselben Zahlenwert anzeigen, ohne damit dieselbe Klasse oder denselben Abschnitt einer dauerhaften Verbindung zu bezeichnen. Umgekehrt kann sich eine Weiterleitung über mehrere unterschiedliche Label-Werte erstrecken.

RFC 3032 zeigt, warum das eingegangene Exemplar dennoch nützlich ist. Der oberste Stack-Eintrag wird nachgeschlagen; das Ergebnis bestimmt unter anderem den nächsten Hop und die Operation am Stack. Ein Eintrag kann ersetzt oder entfernt werden, weitere Einträge können hinzukommen. Wer nur den IP-Inhalt zitiert, berichtet nicht automatisch über diese Entscheidung.

Der Stack liegt zwischen Sicherungsschicht- und Netzwerkschicht-Header. Jeder Eintrag umfasst vier Oktette. Der oberste steht zuerst; das S-Bit kennzeichnet den letzten Eintrag. Das sind Anordnungsregeln, keine weltweite Zuständigkeitsordnung.

RFC 4950 registrierte einen gemeinsamen Berichtstyp: Class-Num 1 und C-Type 1 für den eingehenden MPLS-Stack. Die gemeinsame Nummer sagt dem Empfänger, wie er den Datensatz lesen soll. Sie vergibt nicht die darin enthaltenen lokalen Label-Werte.

Eine Momentaufnahme mit klarer Zeitrichtung

Die Erweiterung kann Time Exceeded und Destination Unreachable beigefügt werden, bei ICMPv4 ebenso wie bei ICMPv6. Daraus sollte man keine Erlaubnis ableiten, sie beliebigen ICMP-Typen anzuhängen. Auch die allgemeinere Erweiterungsstruktur von RFC 4884 hat ihre festgelegten Anwendungsbereiche.

Ein einzelnes Stack-Objekt stellt den gesamten eingegangenen Stack in seiner ursprünglichen Reihenfolge dar. Entscheidend ist das Wort eingegangen. Der Datensatz behauptet nicht, den nach einer erfolgreichen Verarbeitung ausgesandten Stack zu zeigen. Er bildet ebenso wenig eine später ausgelesene Konfiguration ab.

Die Objektlänge beträgt vier Oktette für den Objektheader und weitere vier je Eintrag. Drei Einträge ergeben damit ein Objekt von 16 Oktetten. Das ist ein Rechenbeispiel zur Struktur, kein beobachtetes Paket. Der davorliegende allgemeine Erweiterungsheader ist in diesen 16 Oktetten nicht enthalten.

Ein Eintrag enthält ein 20-Bit-Label, drei damals EXP genannte Bits, ein S-Bit und acht TTL-Bits. Im Februar 2009 benannte RFC 5462 EXP in Traffic Class, kurz TC, um und präzisierte die Verwendung. Die Breite des Eintrags blieb unverändert. Die alte Beschriftung in einem Beispiel von 2007 ist deshalb historisch zu lesen und kein Freibrief für beliebige heutige Experimente mit diesen Bits.

Diese Details verhindern eine häufige Verschiebung: Aus einem zeitlich begrenzten Befund wird auf dem Bildschirm schnell eine allgemeine Eigenschaft des Netzes. Ein Label ohne Eingangsbezug, Routerkontext und Zeitpunkt ist leichter zu drucken als zuverlässig auszulegen.

Die neue Grenze und die alte Gewohnheit

RFC 4884 zerlegt die betreffenden ICMP-Nachrichten in das Zitat des ursprünglichen Datagramms und eine Erweiterungsstruktur. Diese enthält genau einen Erweiterungsheader sowie ein oder mehrere Objekte.

Die Länge des Zitatbereichs wird durch ein acht Bit breites Attribut angegeben, dessen Platz zuvor reserviert war. Bei ICMPv4 zählt es 32-Bit-Wörter, bei ICMPv6 64-Bit-Wörter. Der Bereich wird entsprechend ausgerichtet. Sobald Erweiterungen angehängt werden, muss er mindestens 128 Oktette umfassen; war das Original kürzer, wird aufgefüllt.

Die Zahl 128 ist in dieser Regel eine Mindestgröße. Für einen älteren Empfänger mit festem Offset war dieselbe Zahl dagegen eine unveränderliche Positionsannahme. Genau daraus entstand die Unvereinbarkeit zwischen einem längeren Zitat und der alten Auswertung.

Klassische Anwendungen, die überhaupt keine Erweiterungen kennen, können die angehängten Bytes als Teil des Originalzitats ansehen. RFC 4884 untersucht mögliche Folgen und beschreibt die damals identifizierten Auswirkungen als begrenzt. Das ist keine allgemeine Zusicherung, jede ältere Anwendung werde jeden erweiterten Bericht unverändert verarbeiten.

Auch ein moderner Parser sollte nicht beliebig zwischen Lesarten wechseln. Ist das Längenattribut null, muss eine konforme Anwendung im Standardbetrieb davon ausgehen, dass keine Erweiterung vorhanden ist. Für traceroute verlangte der RFC zusätzlich einen nicht voreingestellten Kompatibilitätsmodus. Dieser darf ausreichend lange Nachrichten ohne Länge an der alten festen Position auf einen gültigen Erweiterungsheader samt Version und Prüfsumme untersuchen.

Die Ausnahme bleibt damit sichtbar. Interoperabilität entsteht nicht durch stilles Raten, sondern durch eine benannte Betriebsart mit eigenen Voraussetzungen.

Prüfen ist noch nicht authentifizieren

Der allgemeine Erweiterungsheader verwendet Version 2 und besitzt eine Prüfsumme. Ein Nullwert des Prüfsummenfeldes bedeutet, dass keine Prüfsumme übertragen wurde. Objektheader geben ihre Länge in Oktetten einschließlich Header und Nutzinhalt an.

Ein unbekanntes Objekt macht die gesamte ICMP-Nachricht nicht allein deshalb syntaktisch ungültig. Anwendungen dürfen manche Objekte auswerten und andere ignorieren. Sie müssen jedoch die Struktur und Längen sorgfältig prüfen; eine unkontrollierte Längenangabe kann mehr als eine falsche Diagnose verursachen.

Auch ein formal korrektes Objekt bleibt eine Aussage innerhalb einer empfangenen Nachricht. Eine Prüfsumme begründet keine kryptografische Identität des meldenden Routers. Ein vollständig aussehender Datensatz sollte deshalb nicht ohne weitere Grundlage als authentifizierte Bestätigung eines Pfades behandelt werden.

Das schmälert seinen Nutzen nicht. Es trennt nur unterschiedliche Prüfziele: Ist die Struktur lesbar? Worauf bezieht sich der Befund? Ist die Herkunft verlässlich belegt? Eine einzelne erfolgreiche Prüfung beantwortet nicht automatisch die übrigen Fragen.

Derselbe Stack kann eine andere Aufgabe haben

Ein zweiter Zusammenhang mit Labels steht bereits in RFC 3032. Ein Router innerhalb einer MPLS-Domäne kennt unter Umständen keinen direkten Rückweg zur Quelle des ursprünglichen IP-Pakets. Der RFC beschreibt für bestimmte Situationen ein Verfahren, die erzeugte ICMP-Nachricht zunächst in Richtung des ursprünglichen Ziels durch die Domäne zu transportieren, bis ein Router den Weg zur Quelle kennt.

Dafür können Label-Werte kopiert werden; die TTL-Werte werden für die Reise der neu erzeugten Nachricht gesetzt. Diese äußeren Labels steuern tatsächlich den Transport des Fehlerberichts. Sie sind nicht das innere RFC-4950-Objekt, das den Eingangszustand des fehlgeschlagenen Pakets dokumentiert.

Beide Rollen müssen getrennt bleiben. Aus dem im Bericht enthaltenen Stack folgt nicht, dass der Bericht auf demselben Weg zurückkam. Entsprechend lässt sich eine angezeigte Laufzeit nicht allein anhand dieses Zusatzes einem einzelnen Vorwärtsabschnitt zuschreiben.

Sichtbarkeit beginnt vor dem Parser

RFC 4950 warnt selbst davor, von der Erweiterung eine neue Reichweite für traceroute zu erwarten. Verhindert die jeweilige TTL-Behandlung schon den Grundmechanismus, hilft ein reichhaltigeres Format nicht. Es kann nur mehr aus einer passenden empfangenen Nachricht machen.

RFC 3443 erläutert die TTL-Behandlung für MPLS-Modelle. Im Uniform-Modell werden innere und äußere TTL an Ein- und Ausgang aufeinander abgestimmt. Bei Pipe-Modellen kann der äußere Anfangswert vom inneren Wert unabhängig sein. Innere Probes lösen dann nicht notwendig an jedem verborgenen Transitschritt jene Zeitüberschreitung aus, die ihr Sender erwartet.

Das bedeutet nicht, dass äußere TTLs unbegrenzt wären oder dass ein Pipe-Modell jede mögliche ICMP-Nachricht ausschlösse. Es bedeutet, dass Darstellung nicht die Voraussetzungen ihrer eigenen Datenerhebung ersetzen kann.

Hinzu kommt die Offenlegung. RFC 4950 nennt unter anderem die Zieladresse des ICMP-Berichts, einen globalen Schalter und die Tiefe des eingegangenen Stacks als mögliche Kriterien für das Beifügen der Information. Ein Betreiber kann etwa Managementadressen anders behandeln als externe Empfänger.

Eine fehlende MPLS-Zeile beweist daher keine MPLS-freie Strecke. Die Daten könnten nicht erzeugt, nicht zugestellt, nicht freigegeben oder nicht erkannt worden sein. Der RFC schrieb 2007, der Mechanismus sei bereits breit eingesetzt. Das ist eine damalige Aussage, keine heutige Bestandsaufnahme und kein Beleg für einen gleichzeitigen weltweiten Start.

Der Fortschritt bestand darin, ein bestimmtes fehlendes Stück Kontext transportierbar zu machen. Seine Grenzen blieben Teil der Aussage, nicht ein Fehler, den die nächste schönere Anzeige einfach beseitigen würde.