Zusammenfassung

  • PPP musste die Network-Layer Protocol Phase erreichen und IPv6CP danach Opened; Kontrollpakete trugen 0x8057, zugelassene IPv6-Datagramme 0x0057.
  • Unterschiedliche Interface-Token galten nur für die beiden Enden dieses Links. Sie authentifizierten keinen Peer und belegten keine weltweite Eindeutigkeit, Adressrechte, Route oder Zustellung.

Der aufschlussreichste Randfall von RFC 2023 beginnt mit null. Bat ein Peer um ein Interface-Token mit dem Wert null, konnte die Gegenstelle einen anderen, von null verschiedenen Vorschlag in einem Configure-Ack zurückgeben. RFC 2472 änderte diese Antwort später in Configure-Nak. Damit wurde wieder sichtbar, ob eine Anfrage angenommen oder durch einen Vorschlag ersetzt worden war.

Mehrere Zustände lagen vor dem ersten IPv6-Paket

RFC 1661 teilte PPP in Phasen. LCP stellte den Datenlink her, konfigurierte und testete ihn. Danach konnte Authentisierung folgen. Erst in der Network-Layer Protocol Phase konfigurierte ein eigenes NCP jedes Netzwerkprotokoll.

Für IPv6 hieß dieses NCP in RFC 2023 IPv6CP. Seine Kontrollpakete verwendeten den PPP-Wert 8057 und durften vorher nicht ausgetauscht werden. IPv6-Datagramme verwendeten 0057 und warteten zusätzlich darauf, dass IPv6CP Opened erreichte.

LCP Opened war folglich kein IPv6-Zertifikat. Die Netzwerkphase erlaubte IPv6CP den Beginn, nicht den Erfolg. IPv6CP Opened hob eine Protokollsperre auf; es schuf weder eine Route noch den Beleg für ein gesendetes Paket.

Die Kollision entstand im Vergleich

Interface-Token war Optionstyp 1 mit Länge 6 und einem 32-Bit-Wert. Beide Enden wählten zunächst einen Kandidaten. Mehrere Quellen für Unterschiedlichkeit sollten einen Wert ungleich null liefern; eine einzelne Link-Adresse konnte unzureichend sein. Ohne gute Quelle durfte null gesendet werden, damit der Peer half.

Die Gegenstelle verglich den empfangenen Wert mit dem Wert ihrer letzten eigenen Configure-Request. Verschiedene Nichtnullwerte konnten bestätigt werden. Gleiche Nichtnullwerte zeigten eine lokale Kollision und erforderten Configure-Nak mit einem anderen Vorschlag. Zwei Nullwerte beendeten die automatische Aushandlung per Configure-Reject; ein Standardwert existierte nicht.

Kreuzten beide Seiten denselben Vorschlag, musste ein neuer Kandidat gewählt werden. Unterschied sich der empfangene Nak-Vorschlag vom zuletzt an den Peer gesendeten Vorschlag, konnte er in eine neue Anfrage eingehen. Nicht eine zentrale Vergabestelle, sondern sichtbarer Widerspruch und Wiederholung erzeugten die Trennung.

Jede Antwort hatte eine eigene Reichweite

Ein Configure-Ack für einen Nichtnullwert akzeptierte eine bestimmte Anfrage in einer Richtung. Er beendete nicht automatisch die Gegenrichtung und sagte nichts über die Identität des Peers. RFC 2023 behandelte Sicherheitsfragen nicht; Interface-Token war keine Authentisierung.

Configure-Nak dokumentierte einen ungeeigneten Wert und einen Alternativvorschlag. Es bewies nicht dessen Übernahme, eine neue Anfrage oder ein späteres Opened. Configure-Reject entfernte die Option. Er konnte fehlende Unterstützung oder das Null-gegen-null-Scheitern anzeigen, nicht aber eine gelungene Ersatzkonfiguration.

Auch „eindeutig“ war räumlich begrenzt: innerhalb des PPP-Links. Die Werte unterschieden die beiden Enden dieser Aushandlung. Sie waren keine globale Zuteilung, kein dauerhafter Gerätename und kein Rechtstitel an einer daraus gebildeten IPv6-Adresse.

Empfangsfähigkeit war noch keine Nutzung

Optionstyp 2 handelte ein IPv6-Kompressionsprotokoll als Empfangsfähigkeit aus. Für beide Richtungen mussten beide Enden getrennt anfragen; standardmäßig gab es keine Kompression. Eine angenommene Option war noch kein komprimiertes Paket, geschweige denn erfolgreiche Dekompression oder Zustellung.

RFC 2472 ersetzte das 32-Bit-Token durch einen 64-Bit-Interface-Identifier und korrigierte den Nullfall. RFC 5072 löste später RFC 2472 ab. Das heutige IANA-Register führt 0057 und 8057 weiter, verweist für IPv6CP aber auf RFC 5072 und markiert 004f als historisch. RFC 2023 beschreibt daher eine historische Entwurfsstufe.

Selbst ein beobachteter 0057-Frame belegt nur, dass am Messpunkt ein Frame als Träger eines IPv6-Pakets klassifiziert wurde. Zustellung benötigt korrelierte Empfangsdaten, Integritätsprüfung und eine Transport- oder Anwendungsbestätigung. Identität und Berechtigung brauchen eigene Nachweise.

Die bleibende Einsicht ist die Begrenzung. IPv6CP machte Gleichheit sichtbar, widersprach und wiederholte die Aushandlung, bis die Werte auseinanderliefen. Damit war eine lokale Koordinationsaufgabe gelöst. Alles Weitere blieb offen.

Quellen