Zusammenfassung

  • Beim PPP-Zugang folgt IPv6CP auf LCP, während RADIUS-Authentifizierung und -Autorisierung schon vor der Adressvergabe abgeschlossen sein können. Der NAS weiß daher womöglich noch nicht, ob der Host IPv4, IPv6 oder beides verwenden wird.
  • RFC 3162 erlaubte Attribute beider Familien in derselben RADIUS-Nachricht und überließ dem NAS, nur für den Client nutzbare Werte anzuwenden. Ein autorisierter Wert beweist nicht, dass Adresse, Präfix, Route oder Dienst bereits funktionieren.

Die Antwort kam vor der Frage

Ein Zugangsserver braucht eine Richtlinienentscheidung, bevor er die Sitzung eines Teilnehmers öffnet. Doch wenn er einen RADIUS-Server fragt, ob der Benutzer zugelassen werden soll, kann die endgültige Netzwerkschichtkonfiguration des Hosts noch offen sein. Diese Reihenfolge ist der aufschlussreichste Aspekt von RFC 3162, „RADIUS and IPv6“, veröffentlicht im August 2001.

Das Dokument behandelt zwei verwandte, aber getrennte Aufgaben. RADIUS kann über IPv6 laufen; davon getrennt können RADIUS-Nachrichten Attribute zur Bereitstellung von IPv6-Netzzugang für einen Benutzer übertragen. Eine IPv6-Adresse als Transport für RADIUS bedeutet nicht, dass dem Teilnehmer ein IPv6-Präfix zugewiesen wurde. Die Norm beschreibt beides, doch das zeitliche Problem betrifft die zweite Aufgabe.

RFC 3162 macht die Reihenfolge am Point-to-Point Protocol deutlich. Das Link Control Protocol (LCP) läuft vor dem IPv6 Control Protocol (IPv6CP). RADIUS-Authentifizierung und -Autorisierung können abgeschlossen sein, bevor Adressen zugewiesen werden. Wenn der Network Access Server (NAS) deshalb einen Access-Request sendet, weiß er womöglich noch nicht, ob der Host IPv4, IPv6 oder beide Familien nutzen wird.

Damit scheidet ein einfacher Entwurf aus: erst die gewünschte Adressfamilie erfragen und dann nur die passenden Attribute zurückgeben. Der NAS braucht die Entscheidung, bevor die spätere Aushandlung die Antwort liefert. RFC 3162 löst das nicht durch Raten. IPv4- und IPv6-bezogene Attribute dürfen in derselben RADIUS-Nachricht stehen; der NAS wählt, was anwendbar ist. Er sollte nur Adressen und Präfixe zuweisen, die der Client tatsächlich nutzen kann.

Autorisierung ist keine Konfiguration

Schon die Attribute trennen die Funktionen. NAS-IPv6-Address identifiziert das Gerät, das eine Authentifizierung anfordert. Framed-Interface-Id betrifft einen IPv6-Schnittstellenbezeichner. Framed-IPv6-Prefix liefert ein Präfix samt zugehöriger Route, die für den Benutzer einzurichten ist. Framed-IPv6-Route enthält Routinginformationen, während Framed-IPv6-Pool einen konfigurierten Pool bezeichnet, aus dem ein Präfix vergeben werden kann. Das sind unterschiedliche Kontrollpunkte und keine austauschbaren Konnektivitätsbelege.

Manche Werte sind ausdrücklich Hinweise. Wird die IPv6CP-Option Interface-Identifier erfolgreich ausgehandelt, nimmt der NAS seinen bevorzugten Bezeichner in den Access-Request auf. Der RADIUS-Server sollte den Hinweis berücksichtigen, muss es aber nicht. Der NAS kann auch ein bevorzugtes IPv6-Präfix anfragen; der Server darf diesen Wunsch ignorieren. Ein Access-Accept ist eine Richtlinienantwort und kein Protokoll, das zeigt, dass die Host-Schnittstelle den Wunsch angenommen hat oder Pakete nun das Internet erreichen.

RFC 3162 begrenzt auch die Verwendung zurückgegebener Werte. Für einen ausschließlich IPv6-fähigen Host muss keine IPv4-Adresse reserviert werden; ein Host, der nur IPv4 oder 6to4 nutzt, braucht ebenso wenig ein IPv6-Präfix. Dieser begrenzte Hinweis ordnet Verantwortung zu: Der RADIUS-Server liefert Richtlinienattribute; der NAS sieht die ausgehandelte Sitzung und sollte keine Adressfamilie konfigurieren, die der Client nicht verwenden kann.

Der Autorisierungsaustausch toleriert Unsicherheit also durch eine breitere mögliche Antwort und schränkt dann die tatsächliche Verwendung dort ein, wo mehr Sitzungskontext vorliegt. Das ist nicht bloß eine Frage des Paketformats. Es ist die Grenze zwischen dem, was ein zentraler Richtlinienserver im Voraus autorisieren kann, und dem, was das Zugangsgerät erst nach der Protokollverhandlung erfährt.

Die Ebenen bleiben getrennt

Danach folgen weitere Schritte. Eine Anfrage kann eine NAS-Präferenz enthalten; eine Antwort kann ein Präfix autorisieren oder zurückgeben; IPv6CP kann einen Schnittstellenbezeichner aushandeln; der NAS kann schließlich Adresse oder Route konfigurieren. Ob ein Dienst erreichbar ist, zeigt erst ein anschließender Ende-zu-Ende-Test. RFC 3162 definiert Attribute und ihren Platz im Austausch, berichtet aber keine echte Teilnehmersitzung und garantiert nicht das Ergebnis der späteren Schritte.

Das ist wichtig, weil Authentifizierung, Autorisierung und Abrechnung oft in einem Wort verschwimmen: „Zugang“. Eine erfolgreiche Authentifizierungsantwort ist jedoch keine konfigurierte Adresse, und ein eingerichtetes Präfix bedeutet noch keinen funktionierenden Dienst. Wer Protokolle prüft, muss wissen, welche Systemebene die jeweilige Evidenz wirklich abdeckt.

RFC 3162 reservierte sechs RADIUS-Attributnummern, 95 bis 100, für IPv6-bezogene Informationen. Spätere Standards ergänzten das Vokabular: RFC 4818 definiert ein Delegated-Prefix-Attribut, RFC 6911 fügt weitere Attribute für IPv6-Zugangsnetze hinzu, und RFC 8044 aktualisiert Hinweise zu RADIUS-Datentypen. Das Dokument aus dem Jahr 2001 ist daher kein vollständiger Katalog moderner Zugangskonfiguration. Sein historischer Beitrag ist genauer umrissen: duale Autorisierung zu ermöglichen, bevor die Adressfamilie der Sitzung feststeht.

Lu Hengs Note 20 bietet eine redaktionelle Deutungsperspektive: formale Beschreibung und beobachtbarer Systemzustand sind verschiedene Ebenen. Auf RFC 3162 angewandt dokumentiert ein Attribut, was ein Server angefordert, bevorzugt oder autorisiert hat; es beweist nicht allein, was der NAS eingerichtet hat oder was der Benutzer erreichen konnte. Das ist eine redaktionelle Einordnung und keine Aussage der RFC-Autoren.

Quellen

  1. RFC 3162 — RADIUS and IPv6
  2. RFC-3162-Eintrag beim RFC Editor
  3. RFC 2865 — Remote Authentication Dial In User Service (RADIUS)
  4. RFC 2866 — RADIUS Accounting
  5. RFC 2868 — RADIUS Attributes for Tunnel Protocol Support
  6. RFC 2472 — IP Version 6 over PPP
  7. RFC 2460 — Internet Protocol, Version 6 Specification
  8. RFC 3056 — Connection of IPv6 Domains via IPv4 Clouds
  9. RFC 4818 — RADIUS Delegated-IPv6-Prefix Attribute
  10. RFC 6911 — RADIUS Attributes for IPv6 Access Networks
  11. RFC 8044 — Data Types in RADIUS
  12. RFC 2044 — UTF-8, a Transformation Format of Unicode and ISO 10646
  13. Lu Heng, Note 20 — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile