Zusammenfassung

  • 0xcf kennzeichnet PPP hinter dem Q.922-Header; ein anderes Byte gilt jedoch nur mit aktivem PFC und bereits ausgehandeltem zugehörigem NCP als komprimiertes PPP Protocol.
  • Antworten mit demselben LCP-Identifier von verschiedenen Framing-Adressen können eine versehentliche Mehrpunktverbindung anzeigen; eine gleichwertige andere Kapselung nach NCP-Erfolg erzwingt den Neustart von Link Establishment.

Die gefährlichste Störung ist kein sauberer Abbruch. Sie lässt die Leitung stehen und trennt nur die Zustände. Eine Seite sendet nach einer ausgehandelten PPP-Regel, die andere ist zur allgemeinen Frame-Relay-Kapselung zurückgekehrt. Beide sehen Frames; keine Seite erhält das erwartete Ergebnis. RFC 1973 entwarf für diesen halben Ausfall eine überprüfbare Reaktion.

Das im Juni 1996 veröffentlichte Dokument beschreibt PPP auf einem als Punkt-zu-Punkt eingerichteten Frame-Relay-Schaltkreis. LCP, NCPs, Authentisierung und Kompression setzen zwei Peers voraus. Frame Relay stellt virtuelle Schaltkreise bereit, kann aber auch Mehrpunktbedingungen abbilden. Deshalb musste die Kapselung nicht nur Protokolle trennen, sondern die bilaterale Zustandsmaschine gegen eine mehrdeutige Grundlage schützen.

Warum zwei Rahmungen nicht zusammenpassten

PPP nutzte gewöhnlich eine an ISO 3309 angelehnte HDLC-like framing. Die Hoffnung, sie gemeinsam mit Frame Relay auf demselben Link zu betreiben, scheiterte an der Adressgrenze. Q.922 kann seine Adresse von einem auf zwei oder vier Oktette erweitern; die DLCI-Unterfelder sind nicht immer eindeutig von der ISO-3309-Lesart zu unterscheiden. Ein Empfänger könnte also den Anfang des nächsten Feldes falsch bestimmen.

RFC 1973 wählte eine sichtbare Reihenfolge: Flag 0x7e, Q.922 Address, Control, NLPID 0xcf, PPP Protocol, danach Information und Padding. Address und Control gehören zum Frame-Relay-Transport. 0xcf wählt PPP. Das Protocol-Feld wählt LCP, einen NCP oder das transportierte Netzprotokoll. Jedes Feld entscheidet über Syntax, nicht über Identität oder Erfolg.

Damit war Address-and-Control-Field-Compression ausgeschlossen. In HDLC-like PPP können konstante Werte entfallen. Im Frame-Relay-Fall sind die Werte nicht konstant und werden durch die Vermittlungsstruktur verändert. Ihre Entfernung hätte variablen Zustellkontext als überflüssig behandelt.

Ein Byte braucht ausgehandelten Kontext

Protocol-Field-Compression bot dagegen einen Nutzen. Sie verkürzte das zweibytige PPP Protocol auf ein Byte. Nach Entfernung des NLPID und dieser Kompression lag Information auf einer 32-Bit-Grenze; deshalb empfahl der RFC PFC, wenn es den Durchsatz verbesserte.

Der Empfang begann mit dem ersten Oktett nach dem Header. Null bedeutete: nach RFC 1490 lesen. 0xcf bedeutete: expliziter PPP-NLPID. Ein anderer Wert durfte nur dann als komprimiertes PPP Protocol erwartet werden, wenn PFC eingeschaltet und der zugehörige NCP bereits ausgehandelt war. Andernfalls galt wieder die Kapselung nach RFC 1490.

Das Byte erhielt seine Bedeutung also aus gespeichertem Zustand. Um bei PFC eine Kollision zu vermeiden, blieb PPP Protocol 0x00cf reserviert. Es durfte höchstens anzeigen, dass ein weiteres PPP-Protocol-Paket folgt. Die IANA-Register halten die Trennung bis heute fest: NLPID 0xCF, reserviertes PPP Protocol 00cf.

Zu viele Antworten für Punkt-zu-Punkt

Anfängliche LCP-Pakete tragen nach dem Header cf-c0-21: den PPP-NLPID und das unkomprimierte LCP Protocol c021. Wird ein LCP Configure-Request erkannt, tritt der Link in Link Establishment ein. Er ist damit nicht Opened, und weder Authentisierung noch NCP sind bewiesen.

Besonders aufschlussreich ist die Diagnose einer falschen Topologie. Speist ein vermeintlicher Punkt-zu-Punkt-Link versehentlich ein Mehrpunktnetz oder eine Multicastgruppe, können mehrere Stationen auf denselben Configure-Request antworten. Mehrere Antworten mit demselben LCP-Identifier, aber verschiedenen Framing-Adressen sollten eine Fehlkonfiguration melden.

Der Identifier korreliert Antwort und Anfrage. Die Adressen zeigen beobachtete Verschiedenheit. Erst die Kombination ist stark. Eine einzelne Antwort beweist keinen einzigen Peer; ein DLCI ist keine global dauerhafte Identität; und eine fehlende Meldung beweist keine korrekte Topologie. Manche Implementierungen konnten die Framing-Adresse physisch nicht protokollieren oder melden.

Die alternative Kapselung als Gedächtnisverlust

In Link Establishment durften keine Pakete mit anderen NLPID gesendet werden. Empfangene Pakete waren bis zur Network-Layer Protocol phase still zu verwerfen. Eine noch unvollständige PPP-Aushandlung sollte nicht von Daten in einer anderen Grammatik überholt werden.

Nach erfolgreicher NCP-Aushandlung änderte sich die Bedeutung einer gleichwertigen RFC-1490-Kapselung. Sie war nun ein Hinweis, dass der Peer den PPP-Zustand verloren haben könnte. Der Link musste zu Link Establishment zurückkehren und einen neuen LCP Configure-Request senden. Sonst folgte die eine Seite einer Vereinbarung, an die sich die andere nicht mehr erinnerte, und Verkehr verschwand im schwarzen Loch.

Der Neustart bestimmte keine Ursache. Er bewies weder Reboot noch Umkonfiguration, stellte keine verworfenen Daten wieder her und garantierte keine zweite Einigung. Er machte aus einem mehrdeutigen Datensymptom einen beobachtbaren Kontrollversuch.

Bei Fehlschlag gab es eine lokale Verzweigung. Benötigte die Implementierung PPP-Konfiguration oder ausgehandelte Merkmale wie Authentisierung, durfte sie in Termination gehen. Andernfalls musste sie nach Erreichen von Max-Configure nur noch RFC-1490-Frames senden. Stillstand zum Schutz einer Eigenschaft und Weiterbetrieb mit geringeren Eigenschaften sind nicht dasselbe Ergebnis.

Grenzen der damaligen Hardware

Der Link musste full-duplex sein, dauerhaft oder geschaltet. Frame-Relay-Kontrollsignale konnten LCP Up und Down liefern, doch ihr Ausfall durfte die korrekte PPP-Funktion nicht zerstören. Magic Number und PFC waren empfohlen. Die anfängliche MRU betrug 1600 Oktette; die Netzwerk-MTU sollte ohne ausdrücklich ausgehandelte Peer-MRU von mindestens 2048 nicht über 1500 liegen.

Einige Switches konnten nur 262-Oktett-Frames verarbeiten. Bis zum Abschluss von LCP mussten Implementierungen daher eine Begrenzung auf 259 Oktette anbieten, damit NLPID und Protocol Platz fanden. XID und Inverse ARP waren für diese PPP-Links nicht erforderlich, weil die NCP-Aushandlung die Funktion lieferte. Diese Regeln sind auf die konkrete Verbindung beschränkt.

RFC 2427 ersetzte später RFC 1490 und RFC 1294 für allgemeines Multiprotokoll-Frame-Relay, nicht RFC 1973. Nummernzuweisungen und Standards belegen keine heutige Nutzung, Herstellerkonfiguration, Störung oder Dienstleistung. Da RFC 1973 Sicherheitsfragen ausdrücklich nicht behandelt, darf die Rahmung nicht als Integritäts-, Vertraulichkeits- oder Authentisierungsnachweis gelesen werden.

Quellen