Zusammenfassung

  • Ein geöffneter LCP-Zustand bedeutete nicht, dass jede PPP-Protocol-Nummer unterstützt wurde. Auf einen unbekannten Wert musste in Opened mit Protocol-Reject, LCP-Code 8, reagiert werden.
  • Die Antwort nannte das abgelehnte Protokoll in zwei Oktetten und gab einen durch die MRU begrenzten Teil der Information zurück, ohne Link-Layer-Header und FCS.
  • Die Ablehnung eines NCP konnte als RXJ+ im normalen Betrieb bleiben. Die Ablehnung von LCP war RXJ- und damit katastrophal, weil sie die Kontrollsprache des Links selbst verwarf.

Der Link war offen, der Katalog nicht

Der RFC 1134 stellte PPP 1989 als Verfahren vor, Datagramme mehrerer Netzwerkschichtprotokolle über Punkt-zu-Punkt-Verbindungen zu übertragen. LCP verwaltete den gemeinsamen Link; eine Familie von Network Control Protocols konfigurierte die einzelnen Netzwerkschichten. Mehrere Protokolle konnten nebeneinander bestehen, ohne dass jede Implementierung zwangsläufig alle kannte.

So entstand ein Fehlerfall erst nach erfolgreicher Linköffnung. Eine Gegenstelle erhielt ein Paket mit einem unbekannten Wert im PPP-Protocol-Feld. Befand sich LCP im Open-Zustand, sollte sie nicht pauschal den Träger verwerfen, sondern ein LCP-Paket mit Code 8 senden: Protocol-Reject. Der Widerspruch erhielt einen engeren Geltungsbereich als der Link.

Der RFC 1331 unterschied 1992 zusätzlich zwischen Unkenntnis und falscher Phase. Ein unterstütztes Protokoll, dessen NCP noch nicht Opened war, wurde still verworfen. Ein unbekannter Protocol-Wert löste bei geöffnetem LCP die Ablehnung aus. Das eine war eine Zustandsfrage, das andere eine Fähigkeitsgrenze.

Schweigen beweist deshalb keine Unterstützung. LCP oder der NCP kann im falschen Zustand sein, ein Paket kann verloren gehen oder eine Implementierung kann abweichen. Ebenso beweist Code 8 keinen physischen Leitungsbruch und keine fehlgeschlagene Authentisierung. Er belegt zunächst nur, dass ein bestimmter Protokollwert im vorhandenen LCP-Kontext nicht akzeptiert wurde.

Auch die Fehlermeldung musste in den Empfangsrahmen passen

Im RFC 1661 trägt Protocol-Reject den Code 8. Der Identifier muss sich für jede gesendete Ablehnung ändern. Rejected-Protocol ist genau zwei Oktette lang und enthält das PPP-Protocol-Feld des verworfenen Pakets.

Rejected-Information beginnt mit dessen Information-Feld. Link-Layer-Header und FCS fehlen. Die Rückgabe muss außerdem so gekürzt werden, dass sie die für die Gegenstelle festgelegte Maximum-Receive-Unit nicht überschreitet. Eine Diagnose durfte den ausgehandelten Größenvertrag nicht verletzen, nur weil sie über dessen Verletzung oder Nichtunterstützung berichtete.

Das zurückgesandte Material ist daher kein vollständiges Frame-Abbild. Es kann gekürzt sein und lässt die äußeren Felder bewusst weg. Auch der Identifier ist keine dauerhafte Vorgangsnummer. Die Aussage ist präzise, aber schmal: Dieser Protocol-Wert wurde abgelehnt, und so viel des auslösenden Inhalts passte in die erlaubte Antwort.

Der RFC 1548 behielt das Verfahren 1993 bei; RFC 1661 stabilisierte es 1994. Diese Kontinuität belegt die Rolle im Standard, nicht die korrekte Umsetzung in jedem Produkt.

Die Pflicht zum Aufhören lag beim Sender

Nach Empfang eines Protocol-Reject muss die Implementierung Pakete des genannten Protokolls bei der frühesten Gelegenheit nicht mehr senden. Bereits eingereihte oder unterwegs befindliche Pakete können noch sichtbar sein. Eine unbegrenzte Wiederholung unter der Annahme eines bloß vorübergehenden Verlusts ist dagegen nicht mit der Vorgabe vereinbar.

Der RFC 1332 definiert IPCP zur Einrichtung und Konfiguration von IP über PPP. Der RFC 5072 beschreibt IPv6CP. Beide veranschaulichen die NCP-Familie, ohne ihren Einsatz auf einem konkreten Link zu beweisen. Wird ein NCP abgelehnt, ist der dazugehörige Dienst nicht allein deshalb verfügbar, weil LCP offen bleibt. Andere Protokolle benötigen jeweils eigene Unterstützung und Konfiguration.

Protocol-Reject darf nur in LCP Opened gesendet werden. In einem anderen LCP-Zustand empfangene Ablehnungen sollten still verworfen werden. Die Zustandsbedingung ist eine Autoritätsgrenze: Erst ein gemeinsam eingerichteter Kontrollkanal gibt der Erklärung „dieses Protokoll unterstütze ich nicht“ operative Wirkung.

Das abgelehnte Protokoll bestimmte den Ausgang

RFC 1331 bezeichnete einen zulässigen Ablehnungsempfang als RXJ+. Ein Protocol-Reject für einen NCP war das ausdrückliche Beispiel. Er lag im Rahmen normalen Betriebs; der betreffende Pakettyp wurde gestoppt, LCP musste aber nicht geschlossen werden.

RXJ- war katastrophal. Ein Protocol-Reject für LCP selbst galt als nicht behebbarer Fehler und beendete die Verbindung. Nicht das Format von Code 8 war anders, sondern die verworfene Ebene. Nach dem Verlust eines NCP konnte LCP weiterhin erklären, welcher Teil nicht funktionierte. Wurde LCP für unbekannt erklärt, fehlte die gemeinsame Sprache zum Konfigurieren, Testen und Eingrenzen.

Ein fortbestehender Link ist deshalb kein ausreichender Verfügbarkeitsnachweis. Wenn eine Anwendung genau den abgelehnten NCP benötigt, kann sie vollständig ausfallen, obwohl LCP Opened bleibt. Trägerkontinuität und Dienstkontinuität sind getrennte Beobachtungsgrößen.

Ein Registereintrag war keine Implementierungszusage

Das IANA-Register der PPP-Nummern führt LCP-Code 8 als Protocol-Reject und veröffentlicht Zuweisungen des Protocol-Feldes. Es übersetzt Nummern in standardisierte Bedeutungen. Es sagt nicht, ob ein Gerät das Protokoll implementiert, ein NCP geöffnet ist oder gegenwärtiger Verkehr darüber läuft.

Der RFC 3818 ordnete die Zuweisungspolitik für PPP-Namensräume einem IETF-Konsensverfahren zu. Das zeigt Verwaltung eines erweiterbaren Raums, keine Verbreitungsstatistik. Für eine Betriebsbehauptung müssen Register, Konfiguration, Zustände, Paketspur und Verhalten nach der Ablehnung zusammenpassen.

Quellen