Summary

  • RFC 3721 let an iSCSI target have a durable protocol name, a changeable network address and a non-unique human alias—three values that answer different questions.
  • Discovery could find target names and paths, but it did not discover SCSI logical units or prove login, authorization or successful I/O.

“Local Disk” is a reassuring thing to see in a storage console. It is also a poor protocol identity. The label might help a person pick a row, but it cannot tell a remote system which target to contact, establish who is connecting, or decide what that connection may use. In April 2004, RFC 3721 made those distinctions explicit for Internet Small Computer Systems Interface (iSCSI) naming and discovery.

The document’s central design move was to keep a node’s Name separate from its Address. A logical iSCSI node was assigned one permanent, location-independent name for its lifetime. An address combined that name with a TCP location—such as a host and port. A node could have multiple addresses, and those network coordinates could change. Moving an adapter between machines was one reason not to make the adapter itself the identity: the logical storage node could retain its SCSI state and authorization configuration while its path changed.

The qualified name format, iqn., used a date and a reversed domain name to identify the naming authority, followed by an optional local suffix. That syntax gives a name a structured namespace; it does not turn the domain string into proof of current ownership, nor does it encode where a target is presently reachable. RFC 3721 also described an eui. form based on an IEEE EUI-64 identifier. In both cases, the protocol name is meant to identify the node, not to serve as a network route.

An Alias sits on another layer. It is an optional UTF-8 display string and need not be unique. RFC 3721’s example pairs a “Local Disk” label with the actual target name. The alias is for human recognition; the protocol must not use it to identify, address or authenticate an initiator or target. Two systems can show the same friendly phrase without being the same target. A name can remain stable while its address changes. A route can point to a target without answering whether a particular user is allowed in.

That separation matters most when storage moves. If a node name were bound to a particular interface or address, a network reconfiguration could look like a new storage identity. Keeping the name stable lets configuration refer to the logical node, while addresses describe where a session can be attempted. This is a continuity mechanism, not an automatic migration guarantee: the RFC defines names and discovery behavior, not evidence that every implementation preserves state correctly during a move.

Discovery was similarly bounded. Its goal was to let an initiator find targets to which it had access and obtain one or more addresses for them. Static configuration could provide the information in advance. SendTargets let an initiator contact a known network entity and request target information. Zero-configuration frameworks, including SLP and iSNS, offered broader ways to locate resources. These are mechanisms in a specification, not a census of what storage networks deployed.

Most importantly, finding a target is not finding its disks. RFC 3721 treats discovery of SCSI Logical Units (LUNs) as a SCSI-layer task, distinct from discovering iSCSI targets. A returned name and address are not a completed login, an authentication result, an authorization grant, a visible LUN or proof that application data moved. Each step has its own decision and evidence.

The security section reinforces that distinction. A claimed initiator node name alone is not trustworthy in an untrusted environment. The target authenticates a security identifier—using mechanisms such as CHAP, SRP or Kerberos in the document’s examples—and then authorizes access, generally through an access-control list. The authenticated identifier may differ from the claimed iSCSI name; policy must explicitly map one to the other. Authentication answers who proved a credential. Authorization answers what that identity may do. Neither question is answered by a friendly alias or a discovery reply.

The later standards record adds a useful, limited coda. RFC 4171 made iSNS optional for iSCSI, while requiring it for iFCP. RFC 7143, which consolidated the iSCSI protocol in 2014, said equipment needing discovery beyond SendTargets should implement iSNS for extended discovery management and interoperability. It also noted that SLP had not been widely implemented or deployed for iSCSI and said implementations should not rely on SLP-based discovery interoperability. That is a bounded statement about iSCSI practice in the later RFC—not a claim about every storage product or every service-discovery technology.

RFC 3721 is Informational and complements, rather than replaces, the protocol specification in RFC 3720. Its historical contribution is a vocabulary of non-interchangeable records: a stable node name, a current address, an optional display alias, an authenticated security identity, an authorization rule and a discovered target. A useful console can put all of them on one screen. Reliable operations begin by refusing to treat them as the same thing.

Sources