Zusammenfassung

  • RFC 4950 schließt eine Diagnose-Lücke: Ein gewöhnlicher ICMP-Fehler kann das sichtbare IP-Datagramm melden, aber den MPLS-Stack auslassen, der die Weiterleitung beeinflusst hat.
  • Die Erweiterung gilt für ICMPv4 und ICMPv6 und nutzt die Erweiterungsstruktur sowie Objekt-Header aus RFC 4884.
  • Das MPLS-Label-Stack-Objekt darf Time Exceeded und Destination Unreachable begleiten; der ursprüngliche IP-Header und die führenden Payload-Oktette bleiben erhalten.

Jeder Stack-Eintrag umfasst exakt vier Oktette: ein 20-Bit-Label, drei Bits für experimentelle Verwendung in der Benennung des Textes von 2007, ein Bottom-of-Stack-Bit und eine 8-Bit-TTL. Gemeldet wird der vollständige Stack, wie er am berichtenden Router eingegangen ist. Das ist kein Beweis für den gesamten Ende-zu-Ende-Pfad und keine automatische Ursachenzuweisung.

Enhanced Traceroute kann damit sowohl besuchte Knoten als auch den MPLS-Kapselungszustand des ursprünglichen Datagramms an jedem antwortenden Knoten darstellen. RFC 4950 definiert jedoch weder die allgemeine MPLS/ICMP-Beziehung noch eine kapselungsspezifische TTL-Manipulation. Verfahren, die bereits klassisches Traceroute durch TTL-Behandlung vereiteln, können daher auch die erweiterte Variante vereiteln. Das Objekt ist nicht mit TTL-Propagation, Load-Balancing, BFD oder BGP-Session- und Ankündigungsautorität gleichzusetzen.

Analyse von Elias Ward — keine RFC-Vorgabe: Betreiber und Troubleshooter profitieren vom Label-Kontext, den klassisches ICMP nicht liefert. Der meldende LSR kann die Daten anhängen; ob sie offengelegt werden, entscheidet der Betreiber nach lokaler Policy. Der Preis ist zusätzliche betriebliche Sichtbarkeit. Teilunterstützung, Filter, Kompatibilität und TTL-Verhalten können die Evidenz unvollständig machen und Schweigen fälschlich wie einen Negativbefund wirken lassen. Im Gegenfaktum bleiben ICMP und Traceroute ohne Erweiterung nutzbar und zeigen Fehler sowie sichtbare Knoten, aber die Analyse stützt sich stärker auf interne Telemetrie und Gerätespeicher.

Das Fehlen eines Label-Stack-Objekts beweist nicht, dass das Paket nicht MPLS-kapsuliert war. Unterstützung, Policy, Filterung und TTL-Verhalten können die Beobachtung unterdrücken. Ein gemeldeter Stack beweist weder den vollständigen Pfad noch die Ursache des Fehlers oder gleichartige Antworten an jedem Hop. Labelwerte sind keine Erlaubnis, Forwarding zu ändern, und kein Beleg für Eigentum, Absicht oder Policy-Konformität. Die historische Aussage des RFC über weite Verbreitung belegt weder heutige flächendeckende Unterstützung noch einheitliches Herstellerverhalten oder aktuelle Offenlegungsdefaults.

Operator-Entscheidung und konkrete Prüfungsfixtures

  1. ICMP-Version, Mehrteil-Struktur nach RFC 4884 und Objekt-Header prüfen; eine verkürzte ICMP-Nachricht darf nicht überinterpretiert werden.
  2. Erhalt von IP-Header und führenden Payload-Oktetten kontrollieren und jeden Vier-Oktett-Eintrag in 20-Bit-Label, drei Experimentalbits, S-Bit und 8-Bit-TTL zerlegen.
  3. Mehrere kontrollierte Time-Exceeded- und Destination-Unreachable-Antworten vergleichen; Quellknoten, Filter, Disclosure-Policy und TTL-Verhalten protokollieren.
  4. Vorhandene Stacks als Eingrenzung für interne Untersuchung verwenden, nicht als Befehl für Route, LSP oder Zugriff. Bei Abwesenheit interne Telemetrie und Gerätespuren anfordern, statt MPLS auszuschließen.

Quellen