Zusammenfassung

  • RFC 2516 trennte eine sitzungszustandslose Discovery-Phase von der Punkt-zu-Punkt-PPP-Sitzung. Erst nach deren Aufbau mussten Host und Zugangskonzentrator Ressourcen für eine virtuelle Schnittstelle zuweisen.
  • Ein optionaler AC-Cookie ließ den Konzentrator prüfen, ob ein an eine Quelladresse gesendeter Wert zurückkam. Host-Uniq und Relay-Session-Id dienten anderen, jeweils vom Host oder Relay verwalteten Zuordnungen.
  • Die undurchsichtigen Tags transportierten begrenzten Paketkontext. Keines authentifizierte eine Person oder belegte spätere PPP-Konfiguration, Datenverkehr oder kommerzielle Leistung.

Broadcast ohne Sitzungstabelle

RFC 2516 beschrieb im Februar 1999, wie PPP über ein Ethernet geführt werden konnte, das sich mehrere Hosts und Zugangskonzentratoren teilten. Der Host sendete PADI als Broadcast; geeignete Konzentratoren konnten mit PADO antworten. Der Host wählte ein Angebot aus und schickte PADR gezielt an den ausgewählten Konzentrator. PADS bestätigte den angenommenen Dienst und vergab eine Sitzungskennung. Die Spezifikation unterschied Discovery und PPP Session ausdrücklich: Discovery blieb ohne Sitzungszustand, bis die PPP-Sitzung aufgebaut war. Dann mussten sowohl Host als auch Konzentrator Ressourcen für eine virtuelle PPP-Schnittstelle zuweisen.

So wurde nicht jede auf einem gemeinsam genutzten Netz sichtbare Anfrage automatisch zur dauerhaften Ressourcenbindung. „Zustandslos“ besagt nicht, dass die Paketverarbeitung keinerlei Rechenaufwand verursacht; gemeint ist der Zeitpunkt, an dem der eigentliche Sitzungszustand der ausgewählten PPP-Verbindung entsteht.

Der Wert musste zurückkommen

Der Konzentrator durfte PADO einen optionalen AC-Cookie beifügen. Der Host musste ihn in PADR unverändert zurücksenden und interpretierte seine Bytes nicht. RFC 2516 empfahl, dass der Konzentrator den Wert anhand der Quelladresse von PADR erneut berechnen kann. Damit ließ sich prüfen, ob eine Adresse, die das Angebot empfangen hatte, den Wert auch zurücksenden konnte; für diese Adresse konnten parallele Sitzungen begrenzt werden.

Als Beispiel nennt der Text einen HMAC über die MAC-Adresse des Hosts mit einem nur dem Konzentrator bekannten Schlüssel. Vorgeschrieben ist das Verfahren nicht. RFC 2516 stellt ausdrücklich klar, dass ein Cookie nicht gegen alle Denial-of-Service-Angriffe schützt. Er verschiebt eine Ressourcenentscheidung bis zum Rücklauf eines Werts, weist aber niemandem hinter einer Adresse eine Identität zu.

Die übrigen Tags haben andere Eigentümer. Host-Uniq wählt der Host, um Antworten seinen eigenen Anfragen zuzuordnen; der Konzentrator spiegelt es, ohne es auszuwerten. Relay-Session-Id kann ein Zwischen-Relay ergänzen, und beide Enden behandeln den Wert als undurchsichtig und geben ihn unverändert zurück. Zuordnung ist keine Identifizierung.

PADS ändert die Ressourcenzuordnung

Ein akzeptierendes PADS enthält eine von null verschiedene SESSION_ID und den angenommenen Dienstnamen. Bei einer Ablehnung stehen Fehler-Tag und Sitzungskennung null. Die PPPoE-Sitzung wird gemeinsam durch Quell-MAC, Ziel-MAC und SESSION_ID bezeichnet; die 16-Bit-Kennung allein genügt nicht.

PADS leitet die PPP-Session-Phase ein, ersetzt aber nicht LCP-Aushandlung, optionale Authentifizierung oder Netzwerkkonfiguration durch NCPs, die RFC 1661 beschreibt. Dieser Beitrag wiederholt weder RFC 4638 noch die benachbarte Frage der 1492-Byte-Nutzlastgrenze. Es geht um den Zeitpunkt der Ressourcenzuweisung und die Reichweite dreier Tags, nicht um einen Nachweis späterer Dienstauslieferung.

RFC 2516 dokumentiert eine Ressourcenschutz-Idee und deren ausdrücklich genannte Grenzen. Der Text quantifiziert keine Speicherersparnis, belegt keine heutige Verbreitung und weist keine konkrete Authentifizierung oder Datenübertragung nach.

Quellen: RFC 2516; RFC 1661; RFC 2104; RFC 4638 (benachbartes Nutzlastthema, hier ausgeklammert).