tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7143

 
 
 

Internet Small Computer System Interface (iSCSI) Protocol (Consolidated)

Part 9 of 10, p. 230 to 260
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 230 
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).

Top      Up      ToC       Page 231 
   - 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.

Top      Up      ToC       Page 232 
   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

Top      Up      ToC       Page 233 
   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

Top      Up      ToC       Page 234 
   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).

Top      Up      ToC       Page 235 
   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.

Top      Up      ToC       Page 236 
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.

Top      Up      ToC       Page 237 
   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.

Top      Up      ToC       Page 238 
   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.

Top      Up      ToC       Page 239 
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>

Top      Up      ToC       Page 240 
   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.

Top      Up      ToC       Page 241 
   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.

Top      Up      ToC       Page 242 
   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.

Top      Up      ToC       Page 243 
   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.

Top      Up      ToC       Page 244 
   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

Top      Up      ToC       Page 245 
   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.

Top      Up      ToC       Page 246 
   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

Top      Up      ToC       Page 247 
   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.

Top      Up      ToC       Page 248 
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.

Top      Up      ToC       Page 249 
   [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.

Top      Up      ToC       Page 250 
   [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>.

Top      Up      ToC       Page 251 
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.

Top      Up      ToC       Page 252 
   [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.

Top      Up      ToC       Page 253 
   [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.

Top      Up      ToC       Page 254 
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 |                       |                     |
   +------------------+-----------------------+---------------------+

Top      Up      ToC       Page 255 
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 |                       |                     |
   +------------------+-----------------------+---------------------+

Top      Up      ToC       Page 256 
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  |                        |                     |
   +-------------------+------------------------+---------------------+

Top      Up      ToC       Page 257 
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 |                       |                      |
   +------------------+-----------------------+----------------------+

Top      Up      ToC       Page 258 
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).

Top      Up      ToC       Page 259 
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

Top      Up      ToC       Page 260 
   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 RFC Part