Zusammenfassung

  • RFC 3145 ergänzte Call-Disconnect-Notify um einen PPP-spezifischen Grund, hielt das AVP aber optional, nicht verpflichtend und rein informativ.
  • Code, Control-Protocol-Nummer und Richtung verorten eine Aussage eines Peers; sie beweisen weder physische Ursache noch Verantwortung, Nutzeranzeige oder Abrechnung.
  • Die Erweiterung machte Diagnosen über Eigentümergrenzen hinweg vergleichbar, ohne Registerbedeutung, geschützten Transport und Betriebswahrheit zu vermischen.

Zwei gültige Protokolluhren, eine fehlende Erklärung

L2TP verband den Access Concentrator LAC mit dem Network Server LNS und transportierte dazwischen PPP-Sitzungen. Der Tunnel sollte nicht alle Einzelheiten der eingeschlossenen PPP-Zustandsmaschinen kennen. Deshalb konnte seine Steuerung eine Sitzung sauber entfernen, obwohl der entfernte Peer nicht wusste, welcher PPP-Schritt zuletzt gescheitert war.

Call-Disconnect-Notify führte bereits Result Code und Error Code. Sie beschrieben L2TP. Ein Echo-Timeout, eine fehlgeschlagene LCP-Aushandlung, ein unbrauchbares NCP oder eine administrative Trennung gehörten dagegen zur PPP-Sicht. Besonders problematisch wurde diese Lücke, wenn LAC und LNS verschiedenen Unternehmen gehörten. Der eine Betreiber hatte den Kundenzugang, der andere den entscheidenden Zustandswechsel.

RFC 3145 definierte ein knappes Übergabestück: das PPP Disconnect Cause Code AVP mit Vendor ID 0 und Attribute Type 46, ausschließlich in CDN. Es enthielt Cause Code, PPP Control Protocol Number, Direction und optionalen UTF-8-Text.

Das neue AVP durfte die L2TP-Codes nicht ersetzen. Es sollte neben ihnen stehen. Die Aussage „L2TP beendete die Sitzung mit diesem Ergebnis“ und die Aussage „dieser Peer meldete diese PPP-Bedingung“ behielten getrennte Herkunft. Eine einzige normalisierte Fehlerursache würde genau diese Differenz vernichten.

Pflichtbit null, Wirkung null

Das Mandatory-Bit musste null sein. Ein Empfänger ohne Kenntnis der Erweiterung konnte das AVP ignorieren und den Abbruch weiter verarbeiten. Diagnosefortschritt zwang also nicht alle Teilnehmer gleichzeitig zur Aufrüstung.

Ebenso ausdrücklich war die Wirkungsgrenze. Das Attribut diente Information und Protokollierung und sollte weder Tunnel noch PPP-Sitzung beeinflussen. Bestehende Zustandsmaschinen entschieden die Aktion. Ein Peer lieferte eine lokale Deutung. Erst eine spätere Auswertung konnte entscheiden, was daraus folgte. Der Bericht erhielt keinen zweiten Steuerkanal.

Das Hidden-Bit durfte gesetzt sein; RFC 3193 beschrieb später L2TP-Schutz durch IPsec. Ein geschützter Kanal stärkt Vertraulichkeit, Integrität und Peer-Zuordnung. Er beweist jedoch nicht die Vollständigkeit der lokalen Diagnose. Die Identität des Absenders und die Wahrheit seiner Schlussfolgerung sind verschiedene Prüfungen.

Richtung erhält Perspektive

Direction null bedeutete global, eins „at peer“, zwei „at local“. Local war der Host, der das AVP erzeugte. Ein zentrales System darf daraus nicht stillschweigend Kunde und Anbieter oder Schuldiger und Betroffener machen.

Ohne Richtung wären mehrere Codes mehrdeutig. Bei normaler LCP-Trennung zeigt sie, welche Seite Terminate-Request sendete. Bei verpflichtender Verschlüsselung oder Callback unterscheidet sie Fordernden und Ablehnenden. In der Authentifizierung trennt sie lokal angebotene, vom Peer abgelehnte Verfahren von Verfahren, die der Peer forderte und lokal nicht unterstützt wurden. Ablehnung kann korrekte Policy sein; der letzte sichtbare Akt ist nicht automatisch Ursache.

Die Control-Protocol-Nummer setzte eine zweite Koordinate. Globale Fehler nutzten null, Linkfehler LCP, Authentifizierungsfehler das jeweilige Verfahren und NCP-Fehler das betroffene Netzprotokoll. Mehrere fehlgeschlagene NCPs konnten mehrere AVPs erzeugen. Bei nur einem sollte der zuletzt fehlgeschlagene NCP genannt werden. Zuletzt heißt ausgewählt, nicht allein verantwortlich.

Ein Ereignis „Code 16“ reicht daher nicht. Benötigt werden berichtender Peer, Tunnel, Sitzung, CDN-Fingerabdruck, Zeit, Schutzkontext, Protokoll und Richtung. Erst diese Koordinaten machen den Registerwert zu verwertbarer Evidenz.

Ein Fehlerkatalog ist kein Sachverständigengutachten

Die anfänglichen Werte 0 bis 20 reichten von keiner Information über administrative und normale Trennung bis zu Timeouts, unkenntlichen LCP-Paketen, möglicher Schleife, Echo-Ausfall, Multilink-Abweichungen, abgelehntem Callback oder Zwangsverschlüsselung, Authentifizierungsfehlern, fehlenden NCPs und gescheiterter Adresskonvergenz.

Das gemeinsame Vokabular beseitigte Herstellerunterschiede bei der Benennung. Es beseitigte nicht die Mehrdeutigkeit eines Symptoms. Ein Echo-Timeout passt zu Verlust, Überlastung, gesperrtem Rückweg, ausgefallenem Peer oder lokaler Blockade. Ein Authentifizierungsfehler ist ein Protokollergebnis und keine öffentliche Bestätigung, welcher Teil eines Geheimnisses richtig war.

RFC 3145 warnte deshalb vor zukünftigen Unterscheidungen, die einem Angreifer verraten würden, dass ein Name stimmt und nur das Passwort falsch ist. Mehr Diagnosegranularität kann zum Abfrage-Orakel werden. Die kleinste interoperable Spezifikation begrenzt nicht nur Komplexität, sondern auch Informationsabfluss.

Optionaler UTF-8-Text blieb ebenfalls eine Aussage. Lesbarkeit machte ihn weder kanonisch noch für jedes Publikum sicher. Dass ein Peer Text mitsendet, beweist nicht, dass ein Nutzer ihn empfing. Original, Übersetzung und strukturierter Code brauchen getrennte Herkunft.

Vom Herstellerwert zur IETF-Zuordnung

Ein Entwurf hatte Vendor ID 43 von 3Com verwendet. Empfänger durften diese alte Form als gleichwertig akzeptieren, Sender sollten sie nicht mehr erzeugen. So blieb bestehende Interpretation möglich, während die zukünftige Drahtform zur IETF-Zuordnung wechselte.

IANA pflegt den Namensraum und stabilisiert damit die Lesart eines Werts. Das Register bestätigt keine Implementierungsquote und keinen einzelnen Vorfall. Der Peer erzeugt die Behauptung; das Register normiert ihre Sprache; laufender Code und beobachtete Pakete liefern die Berufungsinstanz.

Abrechnung hatte eigene Belege

Der Abbruchgrund konnte laut RFC für Accounting nützlich sein. RADIUS-Tunnel-Accounting führte jedoch eigene Sitzungsbezüge, Start-, Zwischen- und Stop-Datensätze sowie Zähler. Ein PPP-Grund kann eine Stop-Situation erklären helfen. Er beweist weder Eingang des Stop-Datensatzes noch vollständige Zähler oder eine richtige Rechnung.

Auch der Datenpfad benötigt eigene Messung. Echo-Timeout gehört neben Paketstatistik, Alarmen und Erreichbarkeit. Authentifizierungsursachen gehören neben Zustandsfolgen, ohne Geheimnisse zu verbreiten. Normale Trennung gehört neben den tatsächlichen LCP-Austausch. Der Code öffnet eine Untersuchung; er schließt sie nicht.

Für die Nutzeranzeige gilt dasselbe. Text zu erzeugen, auszuliefern und gelesen zu werden sind drei Ereignisse. Das AVP belegt höchstens das erste als Möglichkeit.

Betriebsrealität als Berufungsgericht

RFC 3145 standardisierte nicht eine allwissende Ursache, sondern eine begrenzte Aussage. Code und Register liegen auf der Symbolebene; CDN ist ein dokumentierter Akt; PPP-Zustand und Pakete sind Betrieb; Accounting und Nutzerwirkung sind Folgen. Keine Ebene darf sich durch eine offizielle Nummer als die andere ausgeben.

Heutige Observability-Systeme entfernen oft Absender und Richtung aus einem reason, formulieren lesbaren Text und machen daraus die globale Incident-Ursache. Das kleine Protokoll von 2001 war vorsichtiger. Ein Grund konnte den Tunnel überqueren. Urteilsmacht war nicht Teil seines Formats.

Quellen