Zusammenfassung

  • RFC 2153 reserviert einen proprietären Umschlag, damit Hersteller keine kollidierenden PPP-Codes und Option-Types heimlich selbst vergeben.
  • Die OUI nennt den Verwalter der Bedeutung; Kind und Values bleiben privat, sodass ein gültiger Rahmen unbekannt oder verboten sein kann.
  • Configure-Ack akzeptiert eine exakte Anfrage. Aktivierung, beidseitige Nutzung, Verkehr und Dienstergebnis benötigen weitere Belege.

Der Parser war fertig, die Entscheidung nicht

Code 0, gültige Länge, OUI und Kind lassen sich sauber anzeigen. Damit ist ein Umschlag sortiert. Ob das Gegenüber die passende Implementierung besitzt, die Values dieser Version versteht oder sie verwenden darf, bleibt offen.

RFC 2153 löste 1997 ein enges Koordinationsproblem: Hersteller sollten keine normalen LCP/NCP-Codes oder Configuration-Option-Types heimlich belegen. Der gemeinsame Namensraum standardisierte nicht den proprietären Algorithmus.

Das Vendor-Specific-Control-Paket nutzt Code 0, einen für jedes neue Paket wechselnden Identifier, Magic-Number, OUI, Kind und optionale Values. Es darf vor LCP Opened eintreffen. Empfang erzeugt RXR oder RUC, die Antwort bleibt herstellerspezifisch; Code-Reject führt zum erlaubten Ereignis RXJ+. Das belegt Zustandsmaschinenarbeit, nicht Einigung.

Die Vendor-Specific-Option nutzt Type 0. Vor Annahme muss die Implementierung prüfen, ob OUI und Kind einen bekannten Mechanismus bezeichnen und ob alle Verhandlungswerte vollständig verstanden werden. Syntax, Semantik und Entscheidung sind getrennt.

OUI ist keine Berechtigung

Die OUI nennt die Organisation, die die Bedeutung verwaltet. Kind ist nicht OUI-übergreifend standardisiert, Values sind implementierungsspezifisch. Die OUI authentisiert den Absender nicht. RFC 1661 erlaubt Peer-Authentisierung nach Linkaufbau, während das proprietäre Paket vorher eintreffen kann; RFC 2153 diskutiert Sicherheit nicht.

Für reine Softwareanbieter gab es die CF0000-Serie. RFC 5342 schloss neue Vergaben, RFC 7042 behielt dies ohne technische Formatänderung bei. Das IANA-PPP-Register belegt Nummernprovenienz, nicht installierte Fähigkeiten.

Configure-Ack verlangt erkennbare Optionen und akzeptable Werte und kopiert die Anfrage exakt. Nak bedeutet bekannte Option, unakzeptable Werte. Reject bedeutet unbekannt oder administrativ nicht verhandelbar. Danach braucht es Belege für Wörterbuchversion, lokale Autorität, installierte Parameter, erstes verarbeitetes Paket, NCP Opened, Netzverkehr und Anwendungsergebnis.

RFC 3772 ergänzte später eigene PPP-Protokollnummern und beließ deren Sicherheit beim jeweiligen Protokoll. RFC Editor, Datatracker und Errata belegen das Dokument. Running-Code Primacy, Minimum Initial Specification und Reality Layers trennen gemeinsame Spezifikation, Ausführung und Ergebnis.

Quellen