Zusammenfassung

  • RFC 3355 legte L2TP auf eine ATM-AAL5-Verbindung, verlangte aber, dass jede L2TP-PDU in genau eine AAL5-PDU passt; die äußere MTU begrenzte Tunnel und sämtliche PPP-Sitzungen.
  • Kapselungswahl, Verbindungsaufbau, Schutz und Löschung blieben Trägerfakten. Eine erfolgreiche Auswahl bewies keine innere Zustellung, und das Löschen der SVC beendete die Sitzungen.

Ein Tunnel macht aus komplizierter Infrastruktur eine scheinbar einfache Verbindung. Für PPP konnten ATM-Signalisierung, Zellen und Vermittlung unsichtbar werden. Unsichtbar bedeutete nicht grenzenlos: Die vollständige innere Einheit brauchte weiterhin einen äußeren Behälter mit endlicher Größe.

RFC 3355 wurde im August 2002 auf dem Standards Track veröffentlicht und spezifizierte L2TP über ATM Adaptation Layer 5. Die L2TP-Basisspezifikation wollte weitgehend unabhängig vom Medium sein und verlangte nur paketorientierte Punkt-zu-Punkt-Konnektivität. Eine AAL5-VC zwischen LAC und LNS konnte diese Rolle erfüllen.

Die entscheidende Abbildung verlangte eine L2TP-PDU pro AAL5-PDU. Damit begrenzte die MTU der AAL5-Verbindung die Tunnel-MTU und anschließend die MRU aller PPP-Verbindungen im Tunnel. Mehrere logische Sitzungen benutzten denselben äußeren Rahmen.

Mindestens 1500 Oktette PPP-MRU mussten unterstützt werden. Empfohlen war Platz für ein IP-Paket von mindestens 9180 Oktetten in der PPP-PDU. Das waren Implementierungsfähigkeit und Entwurfsziel, keine Beobachtung einer konkreten Verbindung. PVC-Provisionierung, SVC-Parameter und PPP-Aushandlung konnten kleinere Werte erzeugen.

Eine Herstellerangabe von 9180 beweist daher kein übertragenes Paket. Tatsächliche VC-Grenze, zusätzliche Header, ausgehandelte MRU, weitere Pfadgrenzen, Fragmentierung und Verluste brauchen eigene Messungen. Ein kleiner Test ist kein Beleg für die große Grenze.

AAL5 wurde als bitsynchrone, vollduplexe Punkt-zu-Punkt-Verbindung behandelt. Die VC durfte permanent provisioniert oder als SVC bei Bedarf aufgebaut sein. Verlangt wurde nicht zugesicherter Nachrichtenmodus ohne beschädigte Zustellung; an der Grenze gab es ganze Oktette.

Nachrichtengrenze, Länge und CRC bewiesen nur Rahmeneigenschaften. Sie authentifizierten keinen Sender, schützten keine Vertraulichkeit und bestätigten weder L2TP-Steuerung noch Anwendungsempfang.

Die Protokollidentität wurde auf zwei Arten getragen. LLC/SNAP nannte L2TP in jeder AAL5-PDU durch die IANA-Kennung. VC-Multiplexing ließ diesen Header weg, weil die Endpunkte den Inhalt der Verbindung vereinbart hatten. Bedeutung lag im Paket oder im Kontext.

LLC auf PVCs musste unterstützt werden; LLC auf SVCs und VC-Multiplexing waren optional. PVC-Endpunkte mussten gleich konfiguriert sein. Zwei L2TP-fähige Geräte konnten dieselben Bytes unterschiedlich deuten, wenn ihr Verbindungskontext nicht übereinstimmte.

Bei SVCs übernahm die ATM-Steuerung die Auswahl durch B-LLI-Elemente. Der Anrufer bot LLC, VC-Multiplexing oder beide nach Präferenz. Bei Annahme eines Doppelangebots wählte die Gegenseite genau eine Methode. Ein nur aus nicht unterstützter Form bestehendes Angebot musste abgelehnt werden.

Eine erfolgreiche Auswahl bewies lediglich die Nutzlastgrammatik dieses Aufbaus. Sie bewies nicht, dass die L2TP-Steuerverbindung entstand, PPP authentifizierte, Größen passten oder Nutzdaten ankamen.

Der Reset machte die verborgene Abhängigkeit sichtbar. Wurde ein SVC-getragener Tunnel zurückgesetzt, mussten beide Enden die SVC löschen; alle Benutzersitzungen endeten. Eine spätere Kundenanfrage konnte einen neuen Aufbau auslösen, setzte die alten Sitzungen aber nicht unbemerkt fort.

Ebenso musste eine Meldung über eine gelöschte AAL5-SVC den Tunnel abbauen und die Steuerverbindung in Idle versetzen. Der äußere Lebenszyklus entfernte die Grundlage des inneren Zustands. Medienunabhängigkeit war keine Fehlerunabhängigkeit.

Nach Aufbaufehlern waren Erreichbarkeitsannahme und Wiederverfügbarkeit Implementierungsentscheidungen. Ohne aktive Sitzungen konnte jede Seite die SVC optional löschen. Anzeigen wie unerreichbar, gelöscht und idle brauchten daher Quelle, Ereignis und Generation.

Für unterschiedliche Dienstgüten konnten mehrere AAL5-Verbindungen verwendet werden. Inverses Multiplexing eines Tunnels über mehrere VCs blieb offen. PVC-Parameter wurden vereinbart, SVC-Parameter angefordert. Beides war Absicht, nicht gemessene Leistung.

Sicherheit entstand nicht aus korrekter Kapselung. RFC 3355 warnte vor Angriffen auf das ATM-Netz und verwies auf Authentisierungsheader, verschlüsselte Nutzlasten oder ATM-Sicherheitsdienste. PID, B-LLI und CRC ersetzten keine kryptografische Kontrolle.

RFC 2661 definiert L2TP-Tunnel und Sitzungen, RFC 1661 PPP und MRU, RFC 2684 LLC und VC über AAL5, RFC 2364 direktes PPP über AAL5 und RFC 2331 ATM-Signalisierung. RFC 3070 bildet L2TP auf Frame Relay ab. RFC 3193 fügt IPsec-Zustand hinzu. RFC 4459 behandelt später MTU und Fragmentierung allgemein.

Das IANA-Register koordiniert L2TP-Werte, belegt aber keine Implementierung. Die Quellen zeigen weder eine konkrete Nutzung noch Adoption, Störung, Verkehrsmenge oder Wiederherstellung.

RFC 3355 zeigt Abstraktion ohne Selbsttäuschung. PPP durfte ATM ignorieren; der AAL5-Träger bestimmte weiterhin Größe, Identität und Lebensdauer des Behälters. Der Träger verschwand aus der Sicht, nicht aus der Wirkung.

Sources