RFC 7143
Internet Small Computer System Interface (iSCSI) Protocol (Consolidated)
Pages: 295
Proposed Standard
Obsoletes: 3720 3980 4850 5048
Updates: 3721
Proposed Standard
Obsoletes: 3720 3980 4850 5048
Updates: 3721
Part 9 of 10 – Pages 230 to 260
13.1. HeaderDigest and DataDigest
Use: IO Senders: Initiator and target Scope: CO HeaderDigest = <list-of-values> DataDigest = <list-of-values> Default is None for both HeaderDigest and DataDigest. Digests enable the checking of end-to-end, non-cryptographic data integrity beyond the integrity checks provided by the link layers and the covering of the whole communication path, including all elements that may change the network-level PDUs, such as routers, switches, and proxies. The following table lists cyclic integrity checksums that can be negotiated for the digests and MUST be implemented by every iSCSI initiator and target. These digest options only have error detection significance. +---------------------------------------------+ | Name | Description | Generator | +---------------------------------------------+ | CRC32C | 32-bit CRC |0x11edc6f41| +---------------------------------------------+ | None | no digest | +---------------------------------------------+ The generator polynomial G(x) for this digest is given in hexadecimal notation (e.g., "0x3b" stands for 0011 1011, and the polynomial is x**5 + x**4 + x**3 + x + 1). When the initiator and target agree on a digest, this digest MUST be used for every PDU in the Full Feature Phase. Padding bytes, when present in a segment covered by a CRC, SHOULD be set to 0 and are included in the CRC. The CRC MUST be calculated by a method that produces the same results as the following process: - The PDU bits are considered as the coefficients of a polynomial M(x) of degree n - 1; bit 7 of the lowest numbered byte is considered the most significant bit (x**n - 1), followed by bit 6 of the lowest numbered byte through bit 0 of the highest numbered byte (x**0).
- The most significant 32 bits are complemented.
- The polynomial is multiplied by x**32, then divided by G(x). The
generator polynomial produces a remainder R(x) of degree <= 31.
- The coefficients of R(x) are formed into a 32-bit sequence.
- The bit sequence is complemented, and the result is the CRC.
- The CRC bits are mapped into the digest word. The x**31
coefficient is mapped to bit 7 of the lowest numbered byte of the
digest, and the mapping continues with successive coefficients and
bits so that the x**24 coefficient is mapped to bit 0 of the lowest
numbered byte. The mapping continues further with the x**23
coefficient mapped to bit 7 of the next byte in the digest until
the x**0 coefficient is mapped to bit 0 of the highest numbered
byte of the digest.
- Computing the CRC over any segment (data or header) extended to
include the CRC built using the generator 0x11edc6f41 will always
get the value 0x1c2d19ed as its final remainder (R(x)). This value
is given here in its polynomial form (i.e., not mapped as the
digest word).
For a discussion about selection criteria for the CRC, see [RFC3385].
For a detailed analysis of the iSCSI polynomial, see [Castagnoli93].
Private or public extension algorithms MAY also be negotiated for
digests. Whenever a private or public digest extension algorithm is
part of the default offer (the offer made in the absence of explicit
administrative action), the implementer MUST ensure that CRC32C is
listed as an alternative in the default offer and "None" is not part
of the default offer.
Extension digest algorithms MUST be named using one of the following
two formats:
1) Y-reversed.vendor.dns_name.do_something=
2) New public key with no name prefix constraints
Digests named using the Y- format are used for private purposes
(unregistered). New public keys must be registered with IANA using
the IETF Review process ([RFC5226]). New public extensions for
digests MUST NOT use the Y# name prefix.
For private extension digests, to identify the vendor we suggest
using the reversed DNS-name as a prefix to the proper digest names.
The part of digest-name following Y- MUST conform to the format for standard-label specified in Section 6.1. Support for public or private extension digests is OPTIONAL.13.2. MaxConnections
Use: LO Senders: Initiator and target Scope: SW Irrelevant when: SessionType=Discovery MaxConnections=<numerical-value-from-1-to-65535> Default is 1. Result function is Minimum. The initiator and target negotiate the maximum number of connections requested/acceptable.13.3. SendTargets
Use: FFPO Senders: Initiator Scope: SW For a complete description, see Appendix C.13.4. TargetName
Use: IO by initiator, FFPO by target -- only as response to a SendTargets, Declarative, Any-Stage Senders: Initiator and target Scope: SW TargetName=<iSCSI-name-value> Examples: TargetName=iqn.1993-11.com.disk-vendor:diskarrays.sn.45678 TargetName=eui.020000023B040506 TargetName=naa.62004567BA64678D0123456789ABCDEF
The initiator of the TCP connection MUST provide this key to the remote endpoint in the first Login Request if the initiator is not establishing a Discovery session. The iSCSI Target Name specifies the worldwide unique name of the target. The TargetName key may also be returned by the SendTargets Text Request (which is its only use when issued by a target). The TargetName MUST NOT be redeclared within the Login Phase.13.5. InitiatorName
Use: IO, Declarative, Any-Stage Senders: Initiator Scope: SW InitiatorName=<iSCSI-name-value> Examples: InitiatorName=iqn.1992-04.com.os-vendor.plan9:cdrom.12345 InitiatorName=iqn.2001-02.com.ssp.users:customer235.host90 InitiatorName=naa.52004567BA64678D The initiator of the TCP connection MUST provide this key to the remote endpoint at the first login of the Login Phase for every connection. The InitiatorName key enables the initiator to identify itself to the remote endpoint. The InitiatorName MUST NOT be redeclared within the Login Phase.13.6. TargetAlias
Use: ALL, Declarative, Any-Stage Senders: Target Scope: SW TargetAlias=<iSCSI-local-name-value> Examples: TargetAlias=Bob-s Disk TargetAlias=Database Server 1 Log Disk TargetAlias=Web Server 3 Disk 20
If a target has been configured with a human-readable name or description, this name SHOULD be communicated to the initiator during a Login Response PDU if SessionType=Normal (see Section 13.21). This string is not used as an identifier, nor is it meant to be used for authentication or authorization decisions. It can be displayed by the initiator's user interface in a list of targets to which it is connected.13.7. InitiatorAlias
Use: ALL, Declarative, Any-Stage Senders: Initiator Scope: SW InitiatorAlias=<iSCSI-local-name-value> Examples: InitiatorAlias=Web Server 4 InitiatorAlias=spyalley.nsa.gov InitiatorAlias=Exchange Server If an initiator has been configured with a human-readable name or description, it SHOULD be communicated to the target during a Login Request PDU. If not, the host name can be used instead. This string is not used as an identifier, nor is it meant to be used for authentication or authorization decisions. It can be displayed by the target's user interface in a list of initiators to which it is connected.13.8. TargetAddress
Use: ALL, Declarative, Any-Stage Senders: Target Scope: SW TargetAddress=domainname[:port][,portal-group-tag] The domainname can be specified as either a DNS host name, a dotted- decimal IPv4 address, or a bracketed IPv6 address as specified in [RFC3986]. If the TCP port is not specified, it is assumed to be the IANA- assigned default port for iSCSI (see Section 14).
If the TargetAddress is returned as the result of a redirect status
in a Login Response, the comma and portal-group-tag MUST be omitted.
If the TargetAddress is returned within a SendTargets response, the
portal-group-tag MUST be included.
Examples:
TargetAddress=10.0.0.1:5003,1
TargetAddress=[1080:0:0:0:8:800:200C:417A],65
TargetAddress=[1080::8:800:200C:417A]:5003,1
TargetAddress=computingcenter.example.com,23
The use of the portal-group-tag is described in Appendix C. The
formats for the port and portal-group-tag are the same as the one
specified in TargetPortalGroupTag.
13.9. TargetPortalGroupTag
Use: IO by target, Declarative, Any-Stage
Senders: Target
Scope: SW
TargetPortalGroupTag=<16-bit-binary-value>
Example:
TargetPortalGroupTag=1
The TargetPortalGroupTag key is a 16-bit binary-value that uniquely
identifies a portal group within an iSCSI target node. This key
carries the value of the tag of the portal group that is servicing
the Login Request. The iSCSI target returns this key to the
initiator in the Login Response PDU to the first Login Request PDU
that has the C bit set to 0 when TargetName is given by the
initiator.
[SAM2] notes in its informative text that the TPGT value should be
non-zero; note that this is incorrect. A zero value is allowed as a
legal value for the TPGT. This discrepancy currently stands
corrected in [SAM4].
For the complete usage expectations of this key, see Section 6.3.
13.10. InitialR2T
Use: LO Senders: Initiator and target Scope: SW Irrelevant when: SessionType=Discovery InitialR2T=<boolean-value> Examples: I->InitialR2T=No T->InitialR2T=No Default is Yes. Result function is OR. The InitialR2T key is used to turn off the default use of R2T for unidirectional operations and the output part of bidirectional commands, thus allowing an initiator to start sending data to a target as if it has received an initial R2T with Buffer Offset=Immediate Data Length and Desired Data Transfer Length=(min(FirstBurstLength, Expected Data Transfer Length) - Received Immediate Data Length). The default action is that R2T is required, unless both the initiator and the target send this key-pair attribute specifying InitialR2T=No. Only the first outgoing data burst (immediate data and/or separate PDUs) can be sent unsolicited (i.e., not requiring an explicit R2T).13.11. ImmediateData
Use: LO Senders: Initiator and target Scope: SW Irrelevant when: SessionType=Discovery ImmediateData=<boolean-value> Default is Yes. Result function is AND. The initiator and target negotiate support for immediate data. To turn immediate data off, the initiator or target must state its desire to do so. ImmediateData can be turned on if both the initiator and target have ImmediateData=Yes.
If ImmediateData is set to Yes and InitialR2T is set to Yes
(default), then only immediate data are accepted in the first burst.
If ImmediateData is set to No and InitialR2T is set to Yes, then the
initiator MUST NOT send unsolicited data and the target MUST reject
unsolicited data with the corresponding response code.
If ImmediateData is set to No and InitialR2T is set to No, then the
initiator MUST NOT send unsolicited immediate data but MAY send one
unsolicited burst of Data-OUT PDUs.
If ImmediateData is set to Yes and InitialR2T is set to No, then the
initiator MAY send unsolicited immediate data and/or one unsolicited
burst of Data-OUT PDUs.
The following table is a summary of unsolicited data options:
+----------+-------------+------------------+-------------+
|InitialR2T|ImmediateData| Unsolicited |ImmediateData|
| | | Data-Out PDUs | |
+----------+-------------+------------------+-------------+
| No | No | Yes | No |
+----------+-------------+------------------+-------------+
| No | Yes | Yes | Yes |
+----------+-------------+------------------+-------------+
| Yes | No | No | No |
+----------+-------------+------------------+-------------+
| Yes | Yes | No | Yes |
+----------+-------------+------------------+-------------+
13.12. MaxRecvDataSegmentLength
Use: ALL, Declarative
Senders: Initiator and target
Scope: CO
MaxRecvDataSegmentLength=<numerical-value-512-to-(2**24 - 1)>
Default is 8192 bytes.
The initiator or target declares the maximum data segment length in
bytes it can receive in an iSCSI PDU.
The transmitter (initiator or target) is required to send PDUs with a
data segment that does not exceed MaxRecvDataSegmentLength of the
receiver.
A target receiver is additionally limited by MaxBurstLength for solicited data and FirstBurstLength for unsolicited data. An initiator MUST NOT send solicited PDUs exceeding MaxBurstLength nor unsolicited PDUs exceeding FirstBurstLength (or FirstBurstLength- Immediate Data Length if immediate data were sent).13.13. MaxBurstLength
Use: LO Senders: Initiator and target Scope: SW Irrelevant when: SessionType=Discovery MaxBurstLength=<numerical-value-512-to-(2**24 - 1)> Default is 262144 (256 KB). Result function is Minimum. The initiator and target negotiate the maximum SCSI data payload in bytes in a Data-In or a solicited Data-Out iSCSI sequence. A sequence consists of one or more consecutive Data-In or Data-Out PDUs that end with a Data-In or Data-Out PDU with the F bit set to 1.13.14. FirstBurstLength
Use: LO Senders: Initiator and target Scope: SW Irrelevant when: SessionType=Discovery Irrelevant when: ( InitialR2T=Yes and ImmediateData=No ) FirstBurstLength=<numerical-value-512-to-(2**24 - 1)> Default is 65536 (64 KB). Result function is Minimum. The initiator and target negotiate the maximum amount in bytes of unsolicited data an iSCSI initiator may send to the target during the execution of a single SCSI command. This covers the immediate data (if any) and the sequence of unsolicited Data-Out PDUs (if any) that follow the command. FirstBurstLength MUST NOT exceed MaxBurstLength.
13.15. DefaultTime2Wait
Use: LO Senders: Initiator and target Scope: SW DefaultTime2Wait=<numerical-value-0-to-3600> Default is 2. Result function is Maximum. The initiator and target negotiate the minimum time, in seconds, to wait before attempting an explicit/implicit logout or an active task reassignment after an unexpected connection termination or a connection reset. A value of 0 indicates that logout or active task reassignment can be attempted immediately.13.16. DefaultTime2Retain
Use: LO Senders: Initiator and target Scope: SW DefaultTime2Retain=<numerical-value-0-to-3600> Default is 20. Result function is Minimum. The initiator and target negotiate the maximum time, in seconds, after an initial wait (Time2Wait), before which an active task reassignment is still possible after an unexpected connection termination or a connection reset. This value is also the session state timeout if the connection in question is the last LOGGED_IN connection in the session. A value of 0 indicates that connection/task state is immediately discarded by the target.13.17. MaxOutstandingR2T
Use: LO Senders: Initiator and target Scope: SW MaxOutstandingR2T=<numerical-value-from-1-to-65535>
Irrelevant when: SessionType=Discovery Default is 1. Result function is Minimum. The initiator and target negotiate the maximum number of outstanding R2Ts per task, excluding any implied initial R2T that might be part of that task. An R2T is considered outstanding until the last data PDU (with the F bit set to 1) is transferred or a sequence reception timeout (Section 7.1.4.1) is encountered for that data sequence.13.18. DataPDUInOrder
Use: LO Senders: Initiator and target Scope: SW Irrelevant when: SessionType=Discovery DataPDUInOrder=<boolean-value> Default is Yes. Result function is OR. "No" is used by iSCSI to indicate that the data PDUs within sequences can be in any order. "Yes" is used to indicate that data PDUs within sequences have to be at continuously increasing addresses and overlays are forbidden.13.19. DataSequenceInOrder
Use: LO Senders: Initiator and target Scope: SW Irrelevant when: SessionType=Discovery DataSequenceInOrder=<boolean-value> Default is Yes. Result function is OR. A data sequence is a sequence of Data-In or Data-Out PDUs that end with a Data-In or Data-Out PDU with the F bit set to 1. A Data-Out sequence is sent either unsolicited or in response to an R2T. Sequences cover an offset-range. If DataSequenceInOrder is set to No, data PDU sequences may be transferred in any order.
If DataSequenceInOrder is set to Yes, data sequences MUST be transferred using continuously non-decreasing sequence offsets (R2T buffer offset for writes, or the smallest SCSI Data-In buffer offset within a read data sequence). If DataSequenceInOrder is set to Yes, a target may retry at most the last R2T, and an initiator may at most request retransmission for the last read data sequence. For this reason, if ErrorRecoveryLevel is not 0 and DataSequenceInOrder is set to Yes, then MaxOutstandingR2T MUST be set to 1.13.20. ErrorRecoveryLevel
Use: LO Senders: Initiator and target Scope: SW ErrorRecoveryLevel=<numerical-value-0-to-2> Default is 0. Result function is Minimum. The initiator and target negotiate the recovery level supported. Recovery levels represent a combination of recovery capabilities. Each recovery level includes all the capabilities of the lower recovery levels and adds some new ones to them. In the description of recovery mechanisms, certain recovery classes are specified. Section 7.1.5 describes the mapping between the classes and the levels.13.21. SessionType
Use: LO, Declarative, Any-Stage Senders: Initiator Scope: SW SessionType=<Discovery|Normal> Default is Normal. The initiator indicates the type of session it wants to create. The target can either accept it or reject it.
A Discovery session indicates to the target that the only purpose of this session is discovery. The only requests a target accepts in this type of session are a Text Request with a SendTargets key and a Logout Request with reason "close the session". The Discovery session implies MaxConnections = 1 and overrides both the default and an explicit setting. As Section 7.4.1 states, ErrorRecoveryLevel MUST be 0 (zero) for Discovery sessions. Depending on the type of session, a target may decide on resources to allocate, the security to enforce, etc., for the session. If the SessionType key is thus going to be offered as "Discovery", it SHOULD be offered in the initial Login Request by the initiator.13.22. The Private Extension Key Format
Use: ALL Senders: Initiator and target Scope: specific key dependent X-reversed.vendor.dns_name.do_something= Keys with this format are used for private extension purposes. These keys always start with X- if unregistered with IANA (private). New public keys (if registered with IANA via an IETF Review [RFC5226]) no longer have an X# name prefix requirement; implementers may propose any intuitive unique name. For unregistered keys, to identify the vendor we suggest using the reversed DNS-name as a prefix to the key-proper. The part of key-name following X- MUST conform to the format for key-name specified in Section 6.1. Vendor-specific keys MUST ONLY be used in Normal sessions. Support for public or private extension keys is OPTIONAL.13.23. TaskReporting
Use: LO Senders: Initiator and target Scope: SW Irrelevant when: SessionType=Discovery TaskReporting=<list-of-values> Default is RFC3720.
This key is used to negotiate the task completion reporting semantics from the SCSI target. The following table describes the semantics that an iSCSI target MUST support for respective negotiated key values. Whenever this key is negotiated, at least the RFC3720 and ResponseFence values MUST be offered as options by the negotiation originator. +--------------+------------------------------------------+ | Name | Description | +--------------+------------------------------------------+ | RFC3720 | RFC 3720-compliant semantics. Response | | | fencing is not guaranteed, and fast | | | completion of multi-task aborting is not | | | supported. | +--------------+------------------------------------------+ | ResponseFence| Response Fence (Section 4.2.2.3.3) | | | semantics MUST be supported in reporting | | | task completions. | +--------------+------------------------------------------+ | FastAbort | Updated fast multi-task abort semantics | | | defined in Section 4.2.3.4 MUST be | | | supported. Support for the Response | | | Fence is implied -- i.e., semantics as | | | described in Section 4.2.2.3.3 MUST be | | | supported as well. | +--------------+------------------------------------------+ When TaskReporting is not negotiated to FastAbort, the standard multi-task abort semantics in Section 4.2.3.3 MUST be used.13.24. iSCSIProtocolLevel Negotiation
The iSCSIProtocolLevel associated with this document is "1". As a responder or an originator in a negotiation of this key, an iSCSI implementation compliant to this document alone, without any future protocol extensions, MUST use this value as defined by [RFC7144].13.25. Obsoleted Keys
This document obsoletes the following keys defined in [RFC3720]: IFMarker, OFMarker, OFMarkInt, and IFMarkInt. However, iSCSI implementations compliant to this document may still receive these obsoleted keys -- i.e., in a responder role -- in a text negotiation. When an IFMarker or OFMarker key is received, a compliant iSCSI implementation SHOULD respond with the constant "Reject" value. The implementation MAY alternatively respond with a "No" value.
However, the implementation MUST NOT respond with a "NotUnderstood" value for either of these keys. When an IFMarkInt or OFMarkInt key is received, a compliant iSCSI implementation MUST respond with the constant "Reject" value. The implementation MUST NOT respond with a "NotUnderstood" value for either of these keys.13.26. X#NodeArchitecture
13.26.1. Definition
Use: LO, Declarative Senders: Initiator and target Scope: SW X#NodeArchitecture=<list-of-values> Default is None. Examples: X#NodeArchitecture=ExampleOS/v1234,ExampleInc_SW_Initiator/1.05a X#NodeArchitecture=ExampleInc_HW_Initiator/4010,Firmware/2.0.0.5 X#NodeArchitecture=ExampleInc_SW_Initiator/2.1,CPU_Arch/i686 This document does not define the structure or content of the list of values. The initiator or target declares the details of its iSCSI node architecture to the remote endpoint. These details may include, but are not limited to, iSCSI vendor software, firmware, or hardware versions; the OS version; or hardware architecture. This key may be declared on a Discovery session or a Normal session. The length of the key value (total length of the list-of-values) MUST NOT be greater than 255 bytes. X#NodeArchitecture MUST NOT be redeclared during the Login Phase.13.26.2. Implementation Requirements
Functional behavior of the iSCSI node (this includes the iSCSI protocol logic -- the SCSI, iSCSI, and TCP/IP protocols) 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
for exclusion of other nodes. To ensure proper use, key values
SHOULD be set by the node itself, and there SHOULD NOT be provisions
for the key values to contain user-defined text.
Nodes implementing this key MUST choose one of the following
implementation options:
- only transmit the key,
- only log the key values received from other nodes, or
- both transmit and log the key values.
Each node choosing to implement transmission of the key values MUST
be prepared to handle the response of iSCSI nodes that do not
understand the key.
Nodes that implement transmission and/or logging of the key values
may also implement administrative mechanisms that disable and/or
change the logging and key transmission details (see Section 9.4).
Thus, a valid behavior for this key may be that a node is completely
silent (the node does not transmit any key value and simply discards
any key values it receives without issuing a NotUnderstood response).
14. Rationale for Revised IANA Considerations
This document makes rather significant changes in this area, and this
section outlines the reasons behind the changes. As previously
specified in [RFC3720], iSCSI had used text string prefixes, such as
X- and X#, to distinguish extended login/text keys, digest
algorithms, and authentication methods from their standardized
counterparts. Based on experience with other protocols, [RFC6648],
however, strongly recommends against this practice, in large part
because extensions that use such prefixes may become standard over
time, at which point it can be infeasible to change their text string
names due to widespread usage under the existing text string name.
iSCSI's experience with public extensions supports the
recommendations in [RFC6648], as the only extension item ever
registered with IANA, the X#NodeArchitecture key, was specified as a
standard key in a Standards Track RFC [RFC4850] and hence did not
require the X# prefix. In addition, that key is the only public
iSCSI extension that has been registered with IANA since RFC 3720 was
originally published, so there has been effectively no use of the X#,
Y#, and Z# public extension formats.
Therefore, this document makes the following changes to the IANA
registration procedures for iSCSI:
1) The separate registries for X#, Y#, and Z# public extensions
are removed. The single entry in the registry for X#
login/text keys (X#NodeArchitecture) is transferred to the main
"iSCSI Login/Text Keys" registry. IANA has never created the
latter two registries because there have been no registration
requests for them. These public extension formats (X#, Y#, Z#)
MUST NOT be used, with the exception of the existing
X#NodeArchitecture key.
2) The registration procedures for the main "iSCSI Login/Text
Keys", "iSCSI digests", and "iSCSI authentication methods" IANA
registries are changed to IETF Review [RFC5226] for possible
future extensions to iSCSI. This change includes a deliberate
decision to remove the possibility of specifying an IANA-
registered iSCSI extension in an RFC published via an RFC
Editor Independent Submission, as the level of review in that
process is insufficient for iSCSI extensions.
3) The restriction against registering items using the private
extension formats (X-, Y-, Z-) in the main IANA registries is
removed. Extensions using these formats MAY be registered
under the IETF Review registration procedures, but each format
is restricted to the type of extension for which it is
specified in this RFC and MUST NOT be used for other types.
For example, the X- extension format for extension login/text
keys MUST NOT be used for digest algorithms or authentication
methods.
15. IANA Considerations
The well-known TCP port number for iSCSI connections assigned by IANA
is 3260, and this is the default iSCSI port. Implementations needing
a system TCP port number may use port 860, the port assigned by IANA
as the iSCSI system port; however, in order to use port 860, it MUST
be explicitly specified -- implementations MUST NOT default to the
use of port 860, as 3260 is the only allowed default.
IANA has replaced the references for ports 860 and 3260, both TCP and
UDP, with references to this document. Please see
http://www.iana.org/assignments/service-names-port-numbers.
IANA has updated all references to RFC 3720, RFC 4850, and RFC 5048
to instead reference this RFC in all of the iSCSI registries that are
part of the "Internet Small Computer System Interface (iSCSI)
Parameters" set of registries. This change reflects the fact that
those three RFCs are obsoleted by this RFC. References to other RFCs that are not being obsoleted (e.g., RFC 3723, RFC 5046) should not be changed. IANA has performed the following actions on the "iSCSI Login/Text Keys" registry: - Changed the registration procedure to IETF Review from Standard Required. - Changed the RFC 5048 reference for the registry to reference this RFC. - Added the X#NodeArchitecture key from the "iSCSI extended key" registry, and changed its reference to this RFC. - Changed all references to RFC 3720 and RFC 5048 to instead reference this RFC. IANA has changed the registration procedures for the "iSCSI authentication methods" and "iSCSI digests" registries to IETF Review from RFC Required. IANA has removed the "iSCSI extended key" registry, as its one entry has been added to the "iSCSI Login/Text Keys" registry. IANA has marked as obsolete the values 4 and 5 for SPKM1 and SPKM2, respectively, in the "iSCSI authentication methods" subregistry of the "Internet Small Computer System Interface (iSCSI) Parameters" set of registries. IANA has added this document to the "iSCSI Protocol Level" registry with value 1, as mentioned in Section 13.24. All the other IANA considerations stated in [RFC3720] and [RFC5048] remain unchanged. The assignments contained in the following subregistries are not repeated in this document: - iSCSI authentication methods (from Section 13 of [RFC3720]) - iSCSI digests (from Section 13 of [RFC3720]) This document obsoletes the SPKM1 and SPKM2 key values for the AuthMethod text key. Consequently, the SPKM_ text key prefix MUST be treated as obsolete and not be reused.
16. References
16.1. Normative References
[EUI] "Guidelines for 64-bit Global Identifier (EUI-64(TM))", <http://standards.ieee.org/regauth/oui/tutorials/ EUI64.html>. [FC-FS3] INCITS Technical Committee T11, "Fibre Channel - Framing and Signaling - 3 (FC-FS-3)", ANSI INCITS 470-2011, 2011. [OUI] "IEEE OUI and "company_id" Assignments", <http://standards.ieee.org/regauth/oui>. [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996. [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996. [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998. [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998. [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", RFC 2945, September 2000. [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002. [RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, September 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004. [RFC3722] Bakke, M., "String Profile for Internet Small Computer Systems Interface (iSCSI) Names", RFC 3722, April 2004. [RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F. Travostino, "Securing Block Storage Protocols over IP", RFC 3723, April 2004. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005. [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005. [RFC4171] Tseng, J., Gibbons, K., Travostino, F., Du Laney, C., and J. Souza, "Internet Storage Name Service (iSNS)", RFC 4171, September 2005. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC4304] Kent, S., "Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP)", RFC 4304, December 2005. [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, May 2006.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, June 2013. [RFC7144] Knight, F. and M. Chadalapaka, "Internet Small Computer System Interface (iSCSI) SCSI Features Update", RFC 7144, April 2014. [RFC7145] Ko, M. and A. Nezhinsky, "Internet Small Computer System Interface (iSCSI) Extensions for the Remote Direct Memory Access (RDMA) Specification", RFC 7145, April 2014. [RFC7146] Black, D. and P. Koning, "Securing Block Storage Protocols over IP: RFC 3723 Requirements Update for IPsec v3", RFC 7146, April 2014. [SAM2] INCITS Technical Committee T10, "SCSI Architecture Model - 2 (SAM-2)", ANSI INCITS 366-2003, ISO/IEC 14776-412, 2003. [SAM4] INCITS Technical Committee T10, "SCSI Architecture Model - 4 (SAM-4)", ANSI INCITS 447-2008, ISO/IEC 14776-414, 2008. [SPC2] INCITS Technical Committee T10, "SCSI Primary Commands - 2", ANSI INCITS 351-2001, ISO/IEC 14776-452, 2001. [SPC3] INCITS Technical Committee T10, "SCSI Primary Commands - 3", ANSI INCITS 408-2005, ISO/IEC 14776-453, 2005. [UML] ISO, "Unified Modeling Language (UML) Version 1.4.2", ISO/IEC 19501:2005. [UNICODE] The Unicode Consortium, "Unicode Standard Annex #15: Unicode Normalization Forms", 2013, <http://www.unicode.org/unicode/reports/tr15>.
16.2. Informative References
[Castagnoli93] Castagnoli, G., Brauer, S., and M. Herrmann, "Optimization of Cyclic Redundancy-Check Codes with 24 and 32 Parity Bits", IEEE Transact. on Communications, Vol. 41, No. 6, June 1993. [FC-SP-2] INCITS Technical Committee T11, "Fibre Channel Security Protocols 2", ANSI INCITS 496-2012, 2012. [IB] InfiniBand, "InfiniBand(TM) Architecture Specification", Vol. 1, Rel. 1.2.1, InfiniBand Trade Association, <http://www.infinibandta.org>. [RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for Uniform Resource Names", RFC 1737, December 1994. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999. [RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update ", RFC 2743, January 2000. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3385] Sheinwald, D., Satran, J., Thaler, P., and V. Cavanna, "Internet Protocol Small Computer System Interface (iSCSI) Cyclic Redundancy Check (CRC)/Checksum Considerations", RFC 3385, September 2002. [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003.
[RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004. [RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K., and M. Krueger, "Internet Small Computer Systems Interface (iSCSI) Naming and Discovery", RFC 3721, April 2004. [RFC3783] Chadalapaka, M. and R. Elliott, "Small Computer Systems Interface (SCSI) Command Ordering Considerations with iSCSI", RFC 3783, May 2004. [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2", RFC 4121, July 2005. [RFC4297] Romanow, A., Mogul, J., Talpey, T., and S. Bailey, "Remote Direct Memory Access (RDMA) over IP Problem Statement", RFC 4297, December 2005. [RFC4806] Myers, M. and H. Tschofenig, "Online Certificate Status Protocol (OCSP) Extensions to IKEv2", RFC 4806, February 2007. [RFC4850] Wysochanski, D., "Declarative Public Extension Key for Internet Small Computer Systems Interface (iSCSI) Node Architecture", RFC 4850, April 2007. [RFC5046] Ko, M., Chadalapaka, M., Hufferd, J., Elzur, U., Shah, H., and P. Thaler, "Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA)", RFC 5046, October 2007. [RFC5048] Chadalapaka, M., Ed., "Internet Small Computer System Interface (iSCSI) Corrections and Clarifications", RFC 5048, October 2007. [RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method", RFC 5433, February 2009. [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, "Deprecating the "X-" Prefix and Similar Constructs in Application Protocols", BCP 178, RFC 6648, June 2012. [SAS] INCITS Technical Committee T10, "Serial Attached SCSI - 2.1 (SAS-2.1)", ANSI INCITS 457-2010, 2010.
[SBC2] INCITS Technical Committee T10, "SCSI Block Commands - 2 (SBC-2)", ANSI INCITS 405-2005, ISO/IEC 14776-322, 2005. [SPC4] INCITS Technical Committee T10, "SCSI Primary Commands - 4", ANSI INCITS 513-201x. [SPL] INCITS Technical Committee T10, "SAS Protocol Layer - 2 (SPL-2)", ANSI INCITS 505-2013, ISO/IEC 14776-262, 2013.
Appendix A. Examples
A.1. Read Operation Example
+------------------+-----------------------+---------------------+ |Initiator Function| PDU Type | Target Function | +------------------+-----------------------+---------------------+ | Command request |SCSI Command (read)>>> | | | (read) | | | +------------------+-----------------------+---------------------+ | | |Prepare Data Transfer| +------------------+-----------------------+---------------------+ | Receive Data | <<< SCSI Data-In | Send Data | +------------------+-----------------------+---------------------+ | Receive Data | <<< SCSI Data-In | Send Data | +------------------+-----------------------+---------------------+ | Receive Data | <<< SCSI Data-In | Send Data | +------------------+-----------------------+---------------------+ | | <<< SCSI Response |Send Status and Sense| +------------------+-----------------------+---------------------+ | Command Complete | | | +------------------+-----------------------+---------------------+
A.2. Write Operation Example
+------------------+-----------------------+---------------------+ |Initiator Function| PDU Type | Target Function | +------------------+-----------------------+---------------------+ | Command request |SCSI Command (write)>>>| Receive command | | (write) | | and queue it | +------------------+-----------------------+---------------------+ | | | Process old commands| +------------------+-----------------------+---------------------+ | | | Ready to process | | | <<< R2T | write command | +------------------+-----------------------+---------------------+ | Send Data | SCSI Data-Out >>> | Receive Data | +------------------+-----------------------+---------------------+ | | <<< R2T | Ready for data | +------------------+-----------------------+---------------------+ | | <<< R2T | Ready for data | +------------------+-----------------------+---------------------+ | Send Data | SCSI Data-Out >>> | Receive Data | +------------------+-----------------------+---------------------+ | Send Data | SCSI Data-Out >>> | Receive Data | +------------------+-----------------------+---------------------+ | | <<< SCSI Response |Send Status and Sense| +------------------+-----------------------+---------------------+ | Command Complete | | | +------------------+-----------------------+---------------------+
A.3. R2TSN/DataSN Use Examples
A.3.1. Output (Write) Data DataSN/R2TSN Example
+-------------------+------------------------+---------------------+ |Initiator Function | PDU Type and Content | Target Function | +-------------------+------------------------+---------------------+ | Command request |SCSI Command (write)>>> | Receive command | | (write) | | and queue it | +-------------------+------------------------+---------------------+ | | | Process old commands| +-------------------+------------------------+---------------------+ | | <<< R2T | Ready for data | | | R2TSN = 0 | | +-------------------+------------------------+---------------------+ | | <<< R2T | Ready for more data | | | R2TSN = 1 | | +-------------------+------------------------+---------------------+ | Send Data | SCSI Data-Out >>> | Receive Data | | for R2TSN 0 | DataSN = 0, F = 0 | | +-------------------+------------------------+---------------------+ | Send Data | SCSI Data-Out >>> | Receive Data | | for R2TSN 0 | DataSN = 1, F = 1 | | +-------------------+------------------------+---------------------+ | Send Data | SCSI Data >>> | Receive Data | | for R2TSN 1 | DataSN = 0, F = 1 | | +-------------------+------------------------+---------------------+ | | <<< SCSI Response |Send Status and Sense| | | ExpDataSN = 0 | | +-------------------+------------------------+---------------------+ | Command Complete | | | +-------------------+------------------------+---------------------+
A.3.2. Input (Read) Data DataSN Example
+------------------+-----------------------+----------------------+ |Initiator Function| PDU Type | Target Function | +------------------+-----------------------+----------------------+ | Command request |SCSI Command (read)>>> | | | (read) | | | +------------------+-----------------------+----------------------+ | | |Prepare Data Transfer | +------------------+-----------------------+----------------------+ | Receive Data | <<< SCSI Data-In | Send Data | | | DataSN = 0, F = 0 | | +------------------+-----------------------+----------------------+ | Receive Data | <<< SCSI Data-In | Send Data | | | DataSN = 1, F = 0 | | +------------------+-----------------------+----------------------+ | Receive Data | <<< SCSI Data-In | Send Data | | | DataSN = 2, F = 1 | | +------------------+-----------------------+----------------------+ | | <<< SCSI Response |Send Status and Sense | | | ExpDataSN = 3 | | +------------------+-----------------------+----------------------+ | Command Complete | | | +------------------+-----------------------+----------------------+
A.3.3. Bidirectional DataSN Example
+------------------+-----------------------+---------------------+ |Initiator Function| PDU Type | Target Function | +------------------+-----------------------+---------------------+ | Command request |SCSI Command >>> | | | (Read-Write) | Read-Write | | +------------------+-----------------------+---------------------+ | | | Process old commands| +------------------+-----------------------+---------------------+ | | <<< R2T | Ready to process | | | R2TSN = 0 | write command | +------------------+-----------------------+---------------------+ | * Receive Data | <<< SCSI Data-In | Send Data | | | DataSN = 0, F = 0 | | +------------------+-----------------------+---------------------+ | * Receive Data | <<< SCSI Data-In | Send Data | | | DataSN = 1, F = 1 | | +------------------+-----------------------+---------------------+ | * Send Data | SCSI Data-Out >>> | Receive Data | | for R2TSN 0 | DataSN = 0, F = 1 | | +------------------+-----------------------+---------------------+ | | <<< SCSI Response |Send Status and Sense| | | ExpDataSN = 2 | | +------------------+-----------------------+---------------------+ | Command Complete | | | +------------------+-----------------------+---------------------+ * Send Data and Receive Data may be transferred simultaneously as in an atomic Read-Old-Write-New or sequentially as in an atomic Read-Update-Write (in the latter case, the R2T may follow the received data).
A.3.4. Unsolicited and Immediate Output (Write) Data with DataSN Example
+------------------+------------------------+----------------------+ |Initiator Function| PDU Type and Content | Target Function | +------------------+------------------------+----------------------+ | Command request |SCSI Command (write)>>> | Receive command | | (write) |F = 0 | and data | |+ immediate data | | and queue it | +------------------+------------------------+----------------------+ | Send Unsolicited | SCSI Write Data >>> | Receive more Data | | Data | DataSN = 0, F = 1 | | +------------------+------------------------+----------------------+ | | | Process old commands | +------------------+------------------------+----------------------+ | | <<< R2T | Ready for more data | | | R2TSN = 0 | | +------------------+------------------------+----------------------+ | Send Data | SCSI Write Data >>> | Receive Data | | for R2TSN 0 | DataSN = 0, F = 1 | | +------------------+------------------------+----------------------+ | | <<< SCSI Response |Send Status and Sense | | | | | +------------------+------------------------+----------------------+ | Command Complete | | | +------------------+------------------------+----------------------+A.4. CRC Examples
Note: All values are hexadecimal. 32 bytes of zeroes: Byte: 0 1 2 3 0: 00 00 00 00 ... 28: 00 00 00 00 CRC: aa 36 91 8a
32 bytes of ones:
Byte: 0 1 2 3
0: ff ff ff ff
...
28: ff ff ff ff
CRC: 43 ab a8 62
32 bytes of incrementing 00..1f:
Byte: 0 1 2 3
0: 00 01 02 03
...
28: 1c 1d 1e 1f
CRC: 4e 79 dd 46
32 bytes of decrementing 1f..00:
Byte: 0 1 2 3
0: 1f 1e 1d 1c
...
28: 03 02 01 00
CRC: 5c db 3f 11
An iSCSI - SCSI Read (10) Command PDU:
Byte: 0 1 2 3
0: 01 c0 00 00
4: 00 00 00 00
8: 00 00 00 00
12: 00 00 00 00
16: 14 00 00 00
20: 00 00 04 00
24: 00 00 00 14
28: 00 00 00 18
32: 28 00 00 00
36: 00 00 00 00
40: 02 00 00 00
44: 00 00 00 00
CRC: 56 3a 96 d9
(next page on part 10)