Zusammenfassung

  • RFC 3980 führte die Form naa. ein, damit ein vorhandener Network-Address-Authority-Bezeichner als iSCSI-Knotenname dienen und dieselbe Identität wie in Fibre Channel und SAS ausdrücken konnte.
  • Der Name bezeichnete einen dauerhaften logischen Knoten, aber weder Netzwerkportal, IP-Adresse und TCP-Port noch aktuellen Pfad, Discovery-Ergebnis, Anmeldung, Berechtigung, Sitzung oder I/O-Erfolg.

Mehrere Wege zu einem Speicherziel sind nur dann Redundanz, wenn die Verwaltung hinter ihnen dasselbe Ziel wiedererkennt. Ein Array kann Fibre-Channel-Ports, SAS-Anschlüsse und iSCSI über IP anbieten. Werden die drei Zugangsarten zu drei Identitäten, zerfällt die Historie des Geräts genau dort, wo die Technik Kontinuität schaffen sollte. Ein austauschbarer Adapter erhält dann mehr Dauer als das logische System, dem er dient.

RFC 3980 setzte 2005 an dieser schmalen Trennlinie an. Das Dokument ergänzte iSCSI um den Namenstyp naa.; darauf folgt ein INCITS-T11-Bezeichner der Network Address Authority in hexadezimaler Darstellung. Status, Errata und Datatracker-Historie belegen die Standards-Track-Änderung. Die Form nahm 64- oder 128-Bit-NAA-Werte auf. Selbst die größere Variante beanspruchte nach dem Kennzeichner nur 32 Hexadezimalzeichen und blieb damit deutlich unter der iSCSI-Namensgrenze.

Entscheidend war nicht die neue Vorsilbe, sondern die fortgesetzte Zuweisungshoheit. NAA-Bezeichner existierten bereits für Fibre Channel und SAS. Indem iSCSI dieselbe Form zuließ, konnte ein Gerät mit unterschiedlichen Portarten seinen SCSI-Namen auf denselben vergebenen Wert stützen. Ein Transportwechsel erforderte keine neue administrative Biografie des Knotens.

Aus einem gemeinsamen Namen wurde jedoch kein Verzeichnis. Schon die ursprüngliche iSCSI-Spezifikation RFC 3720 unterschied den Knotennamen von den Adressen, über die der Knoten erreichbar war. RFC 3721 behandelte Benennung und Discovery als verwandte, aber getrennte Aufgaben. SendTargets oder ein Discovery-Dienst konnte einen Zielnamen einem oder mehreren Portalen zuordnen; der Name selbst enthielt diese Zuordnung nicht. RFC 4171 schuf mit iSNS wiederum eine eigene Discovery- und Verwaltungsfläche.

Die konsolidierte Spezifikation formuliert die Grenze ausdrücklich. Nach RFC 7143 impliziert ein iSCSI-Name weder Standort noch Adresse. Ein Knoten kann umziehen, mehrere Adressen besitzen und eine Schnittstelle austauschen, ohne umbenannt zu werden. Netzwerkportale sind andere Objekte: Sie tragen IP-Adressen und beim Ziel die lauschenden TCP-Ports. Status, Errata und Datatracker zeigen, wie RFC 7143 RFC 3980 später ablöste und konsolidierte, die naa.-Form und ihre Trennung aber beibehielt.

Die Beständigkeit gehörte damit dem logischen Knoten, nicht Netzwerkkarte, HBA, Kabel, Portal oder Sitzung. Zwei Portale können zu einem Ziel führen; fällt eines aus, bleibt der Zielname gültig. Umgekehrt beweist ein syntaktisch gültiger Name kein erreichbares Portal. Dieselbe Disziplin liegt den URN-Anforderungen in RFC 1737 zugrunde: Globale Geltung und Persistenz sind gerade deshalb nützlich, weil ein Bezeichner kein Locator ist.

Auch die kanonische Zeichenfolge löste nur eine begrenzte Aufgabe. RFC 3722 definierte die Zeichenkettenaufbereitung für iSCSI-Namen, damit Implementierungen Darstellungen konsistent vergleichen konnten. Daraus lässt sich ableiten, ob zwei präsentierte Formen denselben Namen ausdrücken. Nicht ableiten lässt sich, ob die zuständige Autorität den NAA-Wert korrekt vergeben hat, der Präsentierende den Knoten kontrolliert oder das Gerät noch betrieben wird.

Authentisierung hebt diese Grenzen nicht auf. Die konsolidierte Spezifikation verwendet den iSCSI-Namen als Principal-Objekt, doch ein Principal-Name ist kein Berechtigungsnachweis. RFC 3723 regelte Authentisierung, Integrität und Vertraulichkeit in einer eigenen Sicherheitsarchitektur. Eine Anmeldung kann den richtigen Namen nennen und an der Authentisierung scheitern. Sie kann authentisiert und dennoch nicht autorisiert werden. Selbst nach beidem können Sitzung oder Speicheroperation fehlschlagen. RFC 3980 versprach in seinem Sicherheitsteil lediglich, dass die zusätzliche Namensform keine neue Sorge gegenüber anderen iSCSI-Namensformen einführte.

Spätere Korrekturen bewahrten die Abstammung, ohne einen Betriebszustand zu bescheinigen. RFC 4850 korrigierte die iSCSI-Knotenarchitektur, RFC 5048 sammelte Protokollkorrekturen, bevor RFC 7143 die älteren Texte zusammenführte. Das aktuelle Register IANA iSCSI Parameters belegt die Registrierung. Keines dieser Dokumente belegt eine konkrete Herstellerimplementierung, eine einzelne rechtmäßige Zuweisung, eine lebende Route, eine abgeschlossene Anmeldung, gesundes Multipathing oder dauerhafte Daten.

RFC 3980 machte Identität transportfähiger, ohne Ortung vorzutäuschen. Ein weltweiter Namensmechanismus konnte Fibre Channel, SAS und iSCSI überspannen. Adresse, Discovery, Authentisierung, Sitzungsaufbau und I/O mussten weiterhin jeweils ihren eigenen Nachweis erbringen.

Quellen