Declarative Public Extension Key for Internet Small Computer Systems Interface (iSCSI) Node Architecture

The key is declarative and purely informational — functional iSCSI behavior must not depend on it and it must not be used for interoperability decisions — to ensure that nodes which do not implement or understand the key continue to operate correctly and that the key cannot be used to exclude non-implementing nodes.

The key was modeled after the HTTP 'Server' and 'User-Agent' header fields (RFC 2616 Sections 14.38 and 14.43), with text-values roughly equivalent to HTTP Product Tokens, because this pattern provides a well-understood mechanism for communicating implementation identity information.

http

A valid behavior for this key is that a node is completely silent — it does not transmit any key value and simply discards any key values it receives without issuing a NotUnderstood response. This is permissible under the implementation options.

All implementations of this extension key MUST provide an administrative mechanism to disable sending the key, and SHOULD provide an administrative mechanism to configure a verbosity level of the key value to control the amount of information sent.

security

Any logging method used for key values MUST keep the information secure from intruders. Display of the log MUST only be possible with administrative rights to the node, and options to disable logging to disk and keep logs for a fixed duration SHOULD be provided.

security

Each node choosing to transmit key values MUST be prepared to handle the response of RFC 3720 compliant nodes that do not understand the key; RFC 3720 states that compliant nodes MUST respond with X#NodeArchitecture=NotUnderstood.

Functional behavior of the iSCSI node MUST NOT depend on the presence, absence, or content of the X#NodeArchitecture key. The key MUST NOT be used by iSCSI nodes for interoperability or exclusion of other nodes.

Key values SHOULD be set by the node itself, and there SHOULD NOT be provisions for the key values to contain user-defined text, to ensure proper use.

Nodes implementing this key MUST choose one of three implementation options: only transmit the key, only log received key values, or both transmit and log key values.

The length of the key value (total length of the list-of-values) MUST NOT be greater than 255 bytes.

The X#NodeArchitecture key MUST only be sent on the leading connection, MUST NOT be changed after the leading connection login, and MUST only be sent after the security negotiation login stage has completed (during operational negotiation login stage).

X#NodeArchitecture MUST NOT be redeclared within a session.

X#NodeArchitecture is a declarative Public Extension Key with use 'LO' (Leading Only) and scope 'SW', sent by both initiator and target during operational parameter negotiation of the iSCSI login phase. It communicates architecture details such as iSCSI vendor software, firmware, hardware versions, OS version, or hardware architecture.

IANA registered the X#NodeArchitecture key with key name 'X#NodeArchitecture' and description 'Node architecture details', referencing RFC 4850. This document also updates RFC 3720 so that iSCSI extension items (X# text keys, Y# digest algorithms, Z# authentication methods) may be defined by standards track, experimental, or informational RFCs.

registry

The X#NodeArchitecture key transmits specific implementation details that may be sensitive; if a software or firmware version is known to contain security weaknesses, announcing it may be undesirable. Countermeasures include sending less detailed information, not sending the key at all, or using IPsec to provide confidentiality for the iSCSI connection.

security