Summary
- RFC 3980 added the
naa.form so an existing Network Address Authority identifier could become the basis of an iSCSI node name shared with Fibre Channel and SAS naming practice. - The name identified a persistent logical node. It did not encode a network portal, IP address, TCP port, current route, discovery result, login, authorization decision or successful storage operation.
The useful thing about a durable name is that it can survive the disappearance of the path on which it was first seen. That principle sounds obvious in a directory. It was less obvious inside storage networking, where a device might have Fibre Channel ports, SAS ports and iSCSI access over ordinary IP. Each transport already had its own conventions. Without a common representation, the same storage system could acquire several administrative identities and leave operators to decide whether they referred to one device or several.
RFC 3980 solved a small but consequential part of that problem. It added one iSCSI name type: naa. followed by an INCITS T11 Network Address Authority identifier encoded as hexadecimal text. The document's status record, errata record and Datatracker history bound that 2005 change to the Standards Track. The syntax could carry a 64-bit or 128-bit NAA value; even the larger value needed only 32 hexadecimal characters after the designator, comfortably within the iSCSI name limit.
The historical point was not the prefix. It was the reuse of an authority already present in other storage transports. Fibre Channel and SAS used NAA-form identifiers. By admitting the same identifier form into iSCSI, a target with several kinds of port could base one SCSI device name on one assigned identifier. The device did not need to be administratively reborn each time traffic crossed a transport boundary.
That is a representation bridge, not a discovery service. The original iSCSI specification, RFC 3720, distinguished the node name from the addresses through which the node could be reached. RFC 3721 treated naming and discovery as related but separate work. A SendTargets exchange or a discovery system could associate a target name with one or more portals; the name alone did not produce that association. RFC 4171 later specified iSNS discovery and management, again preserving the need for a separate mapping surface.
The consolidated iSCSI specification makes the boundary explicit. RFC 7143 says an iSCSI name does not imply a location or address. A node can move, can have several addresses and can replace an interface without changing its name. Network portals are different objects: they carry IP addresses and, for a target, listening TCP ports. Its status, errata and Datatracker record show that RFC 7143 later obsoleted and consolidated RFC 3980 while retaining the naa. form.
Persistence therefore belonged to the logical node, not to a NIC, HBA, cable, portal or session. Two portals could be paths to one target. One portal could be unavailable while the target name remained valid. Conversely, possessing a syntactically valid name did not prove that any portal was reachable. This was the same design discipline expressed by the URN requirements in RFC 1737: global scope and persistence are valuable precisely because the identifier is not a locator.
Stable comparison was another bounded function. RFC 3722 defined string preparation for iSCSI names so implementations could normalize and compare them consistently. Canonical text can show that two presented strings are equivalent. It cannot show that the naming authority assigned the underlying NAA value correctly, that the presenter controls the named node or that the device is still in service.
Authentication did not collapse those distinctions. The consolidated specification calls the iSCSI name a principal object used in authentication, but a principal name is not a credential. RFC 3723 placed authentication, integrity and confidentiality controls in their own security architecture. A name can be supplied in a login request while authentication fails. Authentication can succeed while authorization denies a resource. Both can succeed while the selected portal or storage operation later fails. RFC 3980's security section made no broader promise; it said the additional naming form introduced no new concern beyond other iSCSI name formats.
Later correction and consolidation preserved the lineage without turning it into operational proof. RFC 4850 corrected iSCSI node architecture, and RFC 5048 collected protocol corrections before RFC 7143 absorbed the earlier documents. The IANA iSCSI Parameters registry is current registry evidence. None of those records demonstrates a vendor deployment, a particular assignment, a live route, a completed login, healthy multipath or durable data.
RFC 3980 matters because it reduced identity churn without pretending to solve location. One worldwide naming convention could span three storage transports. Address selection, discovery, authentication, session establishment and I/O still had to earn their own evidence.
Sources
- RFC 3980 — official text
- RFC 3980 — status
- RFC 3980 — errata
- RFC 3980 — Datatracker
- RFC 7143 — consolidated iSCSI
- RFC 7143 — status
- RFC 7143 — errata
- RFC 7143 — Datatracker
- RFC 3720 — iSCSI
- RFC 3721 — naming and discovery
- RFC 3722 — string profile
- RFC 3723 — securing block storage
- RFC 4171 — iSNS
- RFC 1737 — URN requirements
- RFC 4850 — iSCSI node architecture correction
- RFC 5048 — iSCSI corrections
- IANA iSCSI Parameters
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
