Zusammenfassung

  • Ein Configure-Ack durfte weder Wert noch Reihenfolge einer Anfrage verbessern. Identifier und Optionsliste mussten exakt zur letzten Configure-Request passen, damit Zustimmung prüfbar blieb.
  • LCP führte zwei Richtungen getrennt. Nak schlug annehmbare Werte vor, Reject beendete die Verhandlung über eine Option, und Opened setzte ein gesendetes wie ein empfangenes Ack voraus.

Ein korrigiertes Ja war kein Ja

Ein Ende nennt die größte Rahmengröße, die es empfangen möchte. Der Partner versteht die Maximum-Receive-Unit, hält einen ähnlichen Wert für günstiger und setzt ihn in Configure-Ack ein. Menschlich wirkt das wie ein vernünftiger Kompromiss. Im PPP-Zustandsautomaten ist die Antwort ungültig.

RFC 1661 verlangt, dass das Ack den Identifier der jüngsten Anfrage kopiert und die Optionen unverändert in derselben Reihenfolge wiedergibt. Nur wenn jede Option bekannt und jeder Wert akzeptabel ist, darf die Antwort Ack heißen. Zustimmung enthält keine Änderungsbefugnis.

Die Genauigkeit beseitigt eine verteilte Mehrdeutigkeit. Könnte das Ack die Vorlage bearbeiten, müsste der Absender erraten, ob sein Antrag bestätigt, ersetzt oder mit einer dritten Konfiguration vermischt wurde. Verlust, Wiederholung und gekreuzte Nachrichten würden zwei verschiedene Erinnerungen erzeugen. Die exakte Kopie liefert dagegen eine schmale Evidenz: Genau diese Bytes wurden angenommen.

Der Identifier bindet die Antwort an einen Versuch. Er ändert sich mit dem Optionsinhalt und nach einer gültigen Antwort; bei bloßer Wiederholung darf er gleich bleiben. Er authentifiziert keinen Teilnehmer. Er verhindert, dass ein altes Gespräch einen neuen Antrag beherrscht.

Gegenvorschlag und Grenze erhielten eigene Formen

Configure-Nak gilt für eine bekannte, verhandelbare Option mit unannehmbarem Wert. Die Antwort lässt bereits akzeptable Optionen weg, nennt die strittigen und darf Werte einsetzen, die ihr Absender akzeptieren würde. Eine lokal vorgeschriebene, aber fehlende Option kann hinzugefügt werden.

Der Nak verändert den offenen Antrag nicht. Der ursprüngliche Absender entscheidet, ob er mit neuem Inhalt und neuem Identifier eine weitere Configure-Request stellt. Auch diese neue Vorlage wird erst durch ein identisches Ack wirksam.

Configure-Reject zieht eine härtere Grenze. Die Option ist unbekannt, nicht implementiert oder durch lokale Administration von der Verhandlung ausgeschlossen. Reject kopiert den abgelehnten Teil, statt einen Ersatz anzubieten; die nächste Anfrage soll ihn entfernen. Boolesche Optionen ohne alternativen Wert werden ebenfalls abgelehnt, nicht genakt.

Damit bezeichnet Ack Bestätigung, Nak möglichen Spielraum und Reject fehlenden Verhandlungsspielraum. Keine der drei Antworten darf eine lokale Pflicht unbemerkt umschreiben.

Auf einer Leitung liefen zwei Verhandlungen

Wenn eine Option nichts anderes festlegt, wirkt sie halbduplex und betrifft gewöhnlich die Empfangsrichtung des Configure-Request-Absenders. A beschreibt B also, wie A empfangen kann. B stellt einen eigenen Antrag für die Gegenrichtung.

Die Anträge dürfen sich kreuzen. A kann sein Ack bereits erhalten haben, während es Bs Liste noch prüft. RFC 1171 nannte diesen Zustand Ack-Received: Zustimmung wurde empfangen, aber noch nicht gesendet. Ein Ja in einer Richtung erzeugt keines in der anderen.

RFC 1331 machte die Schwelle ausdrücklich: Die Link-Establishment-Phase ist erst abgeschlossen, wenn Configure-Ack gesendet und empfangen wurde. Ein physisches Trägersignal oder ein einzelnes Ack erlaubt keinem Ende, die gesamte PPP-Verbindung allein zu öffnen.

Die Doppelspur berücksichtigt reale Asymmetrie. Empfangsgrenzen, Authentisierungsanforderungen, Kompression und Steuerzeichenbehandlung können verschieden sein. Interoperabilität bedeutete einen verträglichen Zustand pro Richtung, nicht identische Geräte.

Weglassen bedeutete Standard, nicht Unwissen

Configure-Request ist keine vollständige Fähigkeitsliste. Sie beschreibt Änderungen von Standardwerten; RFC 1661 rät davon ab, Optionen mit ihrem Default überhaupt zu senden. Eine fehlende Option trägt daher Information: Ihr definierter Standard bleibt gültig.

Wer nur explizite Optionen protokolliert, kann die effektive Verbindung nicht rekonstruieren. Die akzeptierte Liste muss mit Defaults verbunden und richtungsabhängig ausgelegt werden.

Alle Optionen eines Antrags werden gemeinsam bewertet. Ack bestätigt die ganze geordnete Liste, Nak meldet nur strittige Werte, Reject nur nicht verhandelbare Teile. So bleibt die Entscheidung atomar, ohne sämtliche Fähigkeiten offenlegen zu müssen.

Die Kontrollsprache blieb trotz Kompressionsstreit lesbar

Einige Optionen verändern das spätere Rahmenformat. Beginnt A mit Kompression, weil es den Abschluss annimmt, während B noch Standardfelder erwartet, könnten sogar die Reparaturnachrichten unlesbar werden.

RFC 1548 und RFC 1661 halten deshalb einen festen Pfad frei: LCP-Pakete für Konfiguration, Beendigung und Code-Reject werden so gesendet, als wäre keine Option aktiv. Address-, Control- und Protocol-Feldkompression gilt dort nicht.

Diese Regel behauptet keine Einigkeit. Sie erhält eine gemeinsame Sprache, in der Uneinigkeit sichtbar und korrigierbar bleibt. Effizienz im Datenpfad darf den Kontrollpfad nicht abschneiden.

Schweigen und endloses Feilschen wurden begrenzt

Configure-Request nutzt Restart-Timer und Zähler gegen Paketverlust. Max-Configure muss einstellbar sein; RFC 1661 empfiehlt zehn Sendungen. Ein ausgeschöpfter Zähler ist eine lokale Begründung zum Abbruch, aber kein Beweis für Angriff oder Leitungsbruch.

Auch Antworten können ohne Annäherung eintreffen. Max-Failure zählt aufeinanderfolgende Naks und hat den empfohlenen Wert fünf. Danach werden weitere Naks zu Rejects, und die lokale Seite fügt ihre gewünschten Optionen nicht mehr an. Nicht konvergierende Wünsche dürfen die Zustandsmaschine nicht unbegrenzt besetzen.

Offenes LCP war noch kein offenes IP

Die vier Codes standen bereits im RFC 1134 vom November 1989. Sie blieben über RFC 1171, RFC 1331 und RFC 1548 bis zum Basisstandard RFC 1661 vom Juli 1994 erhalten. Zugleich wurden die Phasen klar getrennt.

Zuerst meldet die untere Schicht physische Verfügbarkeit. LCP regelt netzschichtunabhängige Werte. Eine ausgehandelte Authentisierung folgt danach. Anschließend öffnet je ein Network Control Protocol IP oder andere Netzprotokolle. Erst der passende NCP-Zustand erlaubt deren Verkehr.

Configure-Ack beweist daher weder Identität noch Authentisierung, IP-Adresse, Route oder Anwendungserreichbarkeit. Es belegt nur, dass der Antwortende einen bestimmten LCP-Antrag exakt akzeptierte.

Das heutige IANA-PPP-Register führt Request, Ack, Nak und Reject weiterhin als Codes 1 bis 4 und verwaltet die Optionen. Registrierung belegt gemeinsames Vokabular, nicht aktuelle Verbreitung oder Produktkonformität.

Schmale Zustimmung verband unterschiedliche Systeme

PPP zerlegte vage Einigkeit in prüfbare Tatsachen: exakte Kopie für Annahme, eigene Nachrichten für Vorschlag und Grenze, eigener Zustand je Richtung sowie Grenzen für Schweigen und Wiederholung. Höhere Schichten mussten ihre Bereitschaft selbst verdienen.

Keine zentrale Instanz bestimmte Größe, Kompression oder Authentisierung einer einzelnen Leitung, und kein Ende erhielt Befehlshoheit über das andere. Der gemeinsame Standard definierte wenige lokale Tests; die Politik blieb bei der Seite, die ihr Risiko trug.

Quellen und Grenzen

RFC 1134, RFC 1171, RFC 1331, RFC 1548 und RFC 1661 belegen Entwicklung, Formate, Zustände und Grenzen; IANA belegt die heutigen Zuweisungen. Sie messen weder gegenwärtige Nutzung noch Herstellerkonformität, Leistung, Betreiberpraxis oder einen universellen Timeout. Die Deutung als schmale bilaterale Autorität ist eine redaktionelle Ableitung.