Zusammenfassung

  • Uniform führt den TTL-Zustand über die Label-Grenze hinweg fort; dadurch bleiben Transit-LSR für Verkehr außerhalb des LSP sichtbar.
  • Pipe soll den Tunnel unabhängig von der Zahl seiner LSR als einen Hop erscheinen lassen. Short Pipe unterscheidet sich an dessen Ausgang.
  • RFC 3443 definiert keine Signalisierung des Modells. Die Auswahl liegt beim Betreiber und wird über eine Management- oder Kommandozeilenschnittstelle konfiguriert.

Was die Operation tatsächlich macht

Beim Push unter Pipe und Short Pipe erhält das neue Label einen vom Betreiber konfigurierten TTL-Wert, statt den TTL-Wert des darunterliegenden Headers zu kopieren. RFC 3443 erwähnt, dass 255 zum Zeitpunkt der Veröffentlichung in vielen Implementierungen verwendet wurde; daraus folgt kein universelles Muss. Die gewöhnliche Regel bleibt: Der ausgehende TTL ist der eingehende TTL minus eins, sofern das Modell nichts anderes für den jeweiligen Vorgang festlegt. Schlägt die Prüfung des ausgehenden TTL fehl, wird das Paket nicht weitergeleitet.

Am Ingress ist der initiale Push samt Headerwert zu prüfen. Im Transit müssen Swap, Dekrement und Prüfung zusammenpassen. Am Egress ist zu kontrollieren, was Pop und gegebenenfalls PHP mit dem getragenen Paket machen. Short Pipe behandelt den Paket-Header am Tunnelausgang so, als wäre der Egress ein gewöhnlicher Weiterleitungs-Hop, einschließlich des vorgesehenen Dekrements. RFC 3443 beschreibt dabei ein gleichwertiges Ende-zu-Ende-Dekrement mit und ohne Penultimate-Hop-Popping in der entsprechenden Situation.

Hierarchische Label-Stacks schaffen zusätzliche Grenzen. Werden Push, Swap oder Pop auf einer Ebene unvollständig umgesetzt, kann der TTL-Zustand an einer Label-Grenze inkonsistent werden. Ein Traceroute ohne interne Tunnel-Hops beweist deshalb weder die Konfiguration von Pipe noch den tatsächlich genommenen Pfad noch eine konsistente Umsetzung auf allen Geräten. TTL-Unsichtbarkeit ist keine Verschlüsselung, keine Vertraulichkeit, keine Authentisierung und keine Sicherheitsgrenze.

RFC 3443 präzisiert die TTL-Verarbeitung und aktualisiert RFC 3032; RFC 3032 beschreibt die Kodierung des MPLS-Label-Stacks. RFC 3270 behandelt MPLS-Unterstützung für Differentiated Services und ist nicht mit einer TTL-Modellsignalisierung oder einer Fehlererkennung gleichzusetzen. Kein Modell erstellt einen LSP, autorisiert eine Route, authentisiert einen Peer, erteilt Zugriff oder überschreibt Weiterleitungsrichtlinien. Die RFCs legen auch keine allgemeine Betriebspolitik fest, wann verborgene Transit-Hops besser sind als sichtbare.

Entscheidungsweg für Betreiber

  1. Lege fest, ob Transit-Hops sichtbar bleiben, der Tunnel als ein Hop erscheinen oder die Short-Pipe-Ausgangsbehandlung gelten soll.
  2. Dokumentiere Modell und initialen TTL in der Betreiberkonfiguration. Leite die Auswahl weder aus dem Wert 255 noch aus fehlenden Traceroute-Hops ab.
  3. Verwende konkrete Fixtures: einen Header mit bekanntem TTL, einen einstufigen Stack, anschließend einen hierarchischen Stack mit und ohne PHP. Erfasse TTL nach Ingress, Transit, Egress und Pop.
  4. Vergleiche jede Beobachtung mit RFC 3443. Trenne Liveness-Prüfungen anderer Mechanismen von TTL-Verarbeitung; RFC 3443 erkennt selbst keinen Ausfall.

Quellen