Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3720

Internet Small Computer Systems Interface (iSCSI)

Pages: 257
Obsoleted by:  7143
Updated by:  3980485050487146
Part 8 of 9 – Pages 187 to 218
First   Prev   Next

ToP   noToC   RFC3720 - Page 187   prevText

12. Login/Text Operational Text Keys

Some session specific parameters MUST only be carried on the leading connection and cannot be changed after the leading connection login (e.g., MaxConnections, the maximum number of connections). This
ToP   noToC   RFC3720 - Page 188
   holds for a single connection session with regard to connection
   restart.  The keys that fall into this category have the use: LO
   (Leading Only).

   Keys that can only be used during login have the use: IO (initialize
   only), while those that can be used in both the Login Phase and Full
   Feature Phase have the use: ALL.

   Keys that can only be used during Full Feature Phase use FFPO (Full
   Feature Phase only).

   Keys marked as Any-Stage may also appear in the SecurityNegotiation
   stage while all other keys described in this chapter are operational
   keys.

   Keys that do not require an answer are marked as Declarative.

   Key scope is indicated as session-wide (SW) or connection-only (CO).

   Result function, wherever mentioned, states the function that can be
   applied to check the validity of the responder selection.  Minimum
   means that the selected value cannot exceed the offered value.
   Maximum means that the selected value cannot be lower than the
   offered value.  AND means that the selected value must be a possible
   result of a Boolean "and" function with an arbitrary Boolean value
   (e.g., if the offered value is No the selected value must be No).  OR
   means that the selected value must be a possible result of a Boolean
   "or" function with an arbitrary Boolean value (e.g., if the offered
   value is Yes the selected value must be Yes).

12.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.
ToP   noToC   RFC3720 - Page 189
   The following table lists cyclic integrity checksums that can be
   negotiated for the digests and that 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 for this digest is given in
   hex-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 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 considered 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 in bit 7 of the lowest numbered byte of the digest
         continuing through to the byte up to the x^24 coefficient in
         bit 0 of the lowest numbered byte, continuing with the x^23
         coefficient in bit 7 of next byte through x^0 in bit 0 of the
         highest numbered byte.
ToP   noToC   RFC3720 - Page 190
      -  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 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:

         a) Y-reversed.vendor.dns_name.do_something=
         b) Y<#><IANA-registered-string>=

   Digests named using the Y- format are used for private purposes
   (unregistered).  Digests named using the Y# format (public extension)
   must be registered with IANA and MUST be described by an
   informational RFC.

   For private extension digests, to identify the vendor, we suggest
   you use the reversed DNS-name as a prefix to the proper digest
   names.

   The part of digest-name following Y- and Y# MUST conform to the
   format for standard-label specified in Section 5.1 Text Format.

   Support for public or private extension digests is OPTIONAL.

12.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.
ToP   noToC   RFC3720 - Page 191
   Initiator and target negotiate the maximum number of connections
   requested/acceptable.

12.3. SendTargets

Use: FFPO Senders: Initiator Scope: SW For a complete description, see Appendix D. - SendTargets Operation -.

12.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 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). TargetName MUST not be redeclared within the login phase.
ToP   noToC   RFC3720 - Page 192

12.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 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. InitiatorName MUST not be redeclared within the login phase.

12.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 12.21 SessionType). 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.
ToP   noToC   RFC3720 - Page 193

12.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 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.

12.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 [RFC2732]. If the TCP port is not specified, it is assumed to be the IANA-assigned default port for iSCSI (see Section 13 IANA Considerations). 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.
ToP   noToC   RFC3720 - Page 194
   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

   Use of the portal-group-tag is described in Appendix D.
   - SendTargets Operation -.  The formats for the port and
   portal-group-tag are the same as the one specified in Section 12.9
   TargetPortalGroupTag.

12.9. TargetPortalGroupTag

Use: IO by target, Declarative, Any-Stage Senders: Target Scope: SW TargetPortalGroupTag=<16-bit-binary-value> Examples: TargetPortalGroupTag=1 The target portal group tag 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. For the complete usage expectations of this key see Section 5.3 Login Phase.

12.10. InitialR2T

Use: LO Senders: Initiator and Target Scope: SW Irrelevant when: SessionType=Discovery InitialR2T=<boolean-value> Examples: I->InitialR2T=No T->InitialR2T=No
ToP   noToC   RFC3720 - Page 195
   Default is Yes.
   Result function is OR.

   The InitialR2T key is used to turn off the default use of R2T for
   unidirectional 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).

12.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.
ToP   noToC   RFC3720 - Page 196
   The following table is a summary of unsolicited data options:

   +----------+-------------+------------------+--------------+
   |InitialR2T|ImmediateData|    Unsolicited   |Immediate Data|
   |          |             |   Data Out PDUs  |              |
   +----------+-------------+------------------+--------------+
   | No       | No          | Yes              | No           |
   +----------+-------------+------------------+--------------+
   | No       | Yes         | Yes              | Yes          |
   +----------+-------------+------------------+--------------+
   | Yes      | No          | No               | No           |
   +----------+-------------+------------------+--------------+
   | Yes      | Yes         | No               | Yes          |
   +----------+-------------+------------------+--------------+

12.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).

12.13. MaxBurstLength

Use: LO Senders: Initiator and Target Scope: SW Irrelevant when: SessionType=Discovery MaxBurstLength=<numerical-value-512-to-(2**24-1)>
ToP   noToC   RFC3720 - Page 197
   Default is 262144 (256 Kbytes).
   Result function is Minimum.

   The initiator and target negotiate 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 one.

12.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 Kbytes). 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.

12.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.
ToP   noToC   RFC3720 - Page 198

12.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.

12.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. 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 6.1.4.1 Recovery Within-command) is encountered for that data sequence.

12.18. DataPDUInOrder

Use: LO Senders: Initiator and Target Scope: SW Irrelevant when: SessionType=Discovery DataPDUInOrder=<boolean-value>
ToP   noToC   RFC3720 - Page 199
   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.

12.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 one. 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 MaxOustandingR2T MUST be set to 1.

12.20. ErrorRecoveryLevel

Use: LO Senders: Initiator and Target Scope: SW ErrorRecoveryLevel=<numerical-value-0-to-2>
ToP   noToC   RFC3720 - Page 200
   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 6.1.5 Error Recovery Hierarchy describes the
   mapping between the classes and the levels.

12.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.

12.22. The Private or Public Extension Key Format

Use: ALL Senders: Initiator and Target Scope: specific key dependent X-reversed.vendor.dns_name.do_something= or X<#><IANA-registered-string>=
ToP   noToC   RFC3720 - Page 201
   Keys with this format are used for public or private extension
   purposes.  These keys always start with X- if unregistered with IANA
   (private) or X# if registered with IANA (public).

   For unregistered keys, to identify the vendor, we suggest you use the
   reversed DNS-name as a prefix to the key-proper.

   The part of key-name following X- and X# MUST conform to the format
   for key-name specified in Section 5.1 Text Format.

   For IANA registered keys the string following X# must be registered
   with IANA and the use of the key MUST be described by an
   informational RFC.

   Vendor specific keys MUST ONLY be used in normal sessions.

   Support for public or private extension keys is OPTIONAL.

13. IANA Considerations

This section conforms to [RFC2434]. The well-known user 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 use of port 860, as 3260 is the only allowed default. Extension keys, authentication methods, or digest types for which a vendor or group of vendors intend to provide publicly available descriptions MUST be described by an RFC and MUST be registered with IANA. The IANA has set up the following three registries: a) iSCSI extended key registry b) iSCSI authentication methods registry c) iSCSI digests registry [RFC3723] also instructs IANA to maintain a registry for the values of the SRP_GROUP key. The format of these values must conform to the one specified for iSCSI extension item-label in Section 13.5.4 Standard iSCSI extension item-label format.
ToP   noToC   RFC3720 - Page 202
   For the iSCSI authentication methods registry and the iSCSI digests
   registry, IANA MUST also assign a 16-bit unsigned integer number (the
   method number for the authentication method and the digest number for
   the digest).

   The following initial values for the registry for authentication
   methods are specified by the standards action of this document:

    Authentication Method                   | Number |
   +----------------------------------------+--------+
   | CHAP                                   |     1  |
   +----------------------------------------+--------+
   | SRP                                    |     2  |
   +----------------------------------------+--------+
   | KRB5                                   |     3  |
   +----------------------------------------+--------+
   | SPKM1                                  |     4  |
   +----------------------------------------+--------+
   | SPKM2                                  |     5  |
   +----------------------------------------+--------+

   All other record numbers from 0 to 255 are reserved.  IANA will
   register numbers above 255.

   Authentication methods with numbers above 255 MUST be unique within
   the registry and MUST be used with the prefix Z#.


   The following initial values for the registry for digests are
   specified by the standards action of this document:

    Digest                                  | Number |
   +----------------------------------------+--------+
   | CRC32C                                 |     1  |
   +----------------------------------------+--------+

   All other record numbers from 0 to 255 are reserved.  IANA will
   register numbers above 255.

   Digests with numbers above 255 MUST be unique within the registry and
   MUST be used with the prefix Y#.

   The RFC that describes the item to be registered MUST indicate in the
   IANA Considerations section the string and iSCSI registry to which it
   should be recorded.

   Extension Keys, Authentication Methods, and digests (iSCSI extension
   items) must conform to a number of requirements as described below.
ToP   noToC   RFC3720 - Page 203

13.1. Naming Requirements

Each iSCSI extension item must have a unique name in its category. This name will be used as a standard-label for the key, access method, or digest and must conform to the syntax specified in Section 13.5.4 Standard iSCSI extension item-label format for iSCSI extension item-labels.

13.2. Mechanism Specification Requirements

For iSCSI extension items all of the protocols and procedures used by a given iSCSI extension item must be described, either in the specification of the iSCSI extension item itself or in some other publicly available specification, in sufficient detail for the iSCSI extension item to be implemented by any competent implementor. Use of secret and/or proprietary methods in iSCSI extension items are expressly prohibited. In addition, the restrictions imposed by [RFC1602] on the standardization of patented algorithms must be respected.

13.3. Publication Requirements

All iSCSI extension items must be described by an RFC. The RFC may be informational rather than Standards-Track, although Standards Track review and approval are encouraged for all iSCSI extension items.

13.4. Security Requirements

Any known security issues that arise from the use of the iSCSI extension item must be completely and fully described. It is not required that the iSCSI extension item be secure or that it be free from risks, but that the known risks be identified. Publication of a new iSCSI extension item does not require an exhaustive security review, and the security considerations section is subject to continuing evaluation. Additional security considerations should be addressed by publishing revised versions of the iSCSI extension item specification. For each of these registries, IANA must record the registered string, which MUST conform to the format rules described in Section 13.5.4 Standard iSCSI extension item-label format for iSCSI extension item-labels, and the RFC number that describes it. The key prefix (X#, Y# or Z#) is not part of the recorded string.
ToP   noToC   RFC3720 - Page 204

13.5. Registration Procedure

Registration of a new iSCSI extension item starts with the construction of an Internet Draft to become an RFC.

13.5.1. Present the iSCSI extension item to the Community

Send a proposed access type specification to the IPS WG mailing list, or if the IPS WG is disbanded at the registration time, to a mailing list designated by the IETF Transport Area Director for a review period of a month. The intent of the public posting is to solicit comments and feedback on the iSCSI extension item specification and a review of any security considerations.

13.5.2. iSCSI extension item review and IESG approval

When the one month period has passed, the IPS WG chair or a person nominated by the IETF Transport Area Director (the iSCSI extension item reviewer) forwards the Internet Draft to the IESG for publication as an informational RFC or rejects it. If the specification is a standards track document, the usual IETF procedures for such documents are followed. Decisions made by the iSCSI extension item reviewer must be published within two weeks after the month-long review period. Decisions made by the iSCSI extension item reviewer can be appealed through the IESG appeal process.

13.5.3. IANA Registration

Provided that the iSCSI extension item has either passed review or has been successfully appealed to the IESG, and the specification is published as an RFC, then IANA will register the iSCSI extension item and make the registration available to the community.

13.5.4. Standard iSCSI extension item-label format

The following character symbols are used iSCSI extension item-labels (the hexadecimal values represent Unicode code points): (a-z, A-Z) - letters (0-9) - digits "." (0x2e) - dot "-" (0x2d) - minus "+" (0x2b) - plus "@" (0x40) - commercial at "_" (0x5f) - underscore
ToP   noToC   RFC3720 - Page 205
   An iSCSI extension item-label is a string of one or more characters
   that consist of letters, digits, dot, minus, plus, commercial at, or
   underscore.  An iSCSI extension item-label MUST begin with a capital
   letter and must not exceed 63 characters.

13.6. IANA Procedures for Registering iSCSI extension items

The identity of the iSCSI extension item reviewer is communicated to the IANA by the IESG. Then, the IANA only acts in response to iSCSI extension item definitions that are approved by the iSCSI extension item reviewer and forwarded by the reviewer to the IANA for registration, or in response to a communication from the IESG that an iSCSI extension item definition appeal has overturned the iSCSI extension item reviewer's ruling.

References

Normative References

[CAM] ANSI X3.232-199X, Common Access Method-3. [EUI] "Guidelines for 64-bit Global Identifier (EUI-64)", http: //standards.ieee.org/regauth/oui/tutorials/EUI64.html [OUI] "IEEE OUI and Company_Id Assignments", http://standards.ieee.org/regauth/oui [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987. [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts- Communication Layer", STD 3, RFC 1122, October 1989. [RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. [RFC1737] Sollins, K. and L. Masinter "Functional Requirements for Uniform Resource Names"RFC 1737, December 1994.
ToP   noToC   RFC3720 - Page 206
   [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.

   [RFC2025]      Adams, C., "The Simple Public-Key GSS-API Mechanism
                  (SPKM)", RFC 2025, October 1996.

   [RFC2045]      Borenstein, N. and N. Freed, "MIME (Multipurpose
                  Internet Mail Extensions) Part One: Mechanisms for
                  Specifying and Describing the Format of Internet
                  Message Bodies", RFC 2045, November 1996.

   [RFC2119]      Bradner, S. "Key Words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2279]      Yergeau, F., "UTF-8, a Transformation Format of ISO
                  10646", RFC 2279 October 1996.

   [RFC2373]      Hinden, R. and S. Deering, "IP Version 6 Addressing
                  Architecture", RFC 2373, July 1998.

   [RFC2396]      Berners-Lee, T., Fielding, R. and L. Masinter "Uniform
                  Resource Identifiers", RFC 2396, August 1998.

   [RFC2401]      Kent, S. and R. Atkinson, "Security Architecture for
                  the Internet Protocol", RFC 2401, November 1998.

   [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.

   [RFC2407]      Piper, D., "The Internet IP Security Domain of
                  Interpretation of ISAKMP", RFC 2407, November 1998.

   [RFC2409]      Harkins, D. and D. Carrel, "The Internet Key Exchange
                  (IKE)", RFC2409, November 1998.

   [RFC2434]      Narten, T. and H. Alvestrand, "Guidelines for Writing
                  an IANA Considerations Section in RFCs.", BCP 26, RFC
                  2434, October 1998.
ToP   noToC   RFC3720 - Page 207
   [RFC2451]      Pereira, R. and R. Adams " The ESP CBC-Mode Cipher
                  Algorithms", RFC 2451, November 1998.

   [RFC2732]      Hinden, R., Carpenter, B. and L. Masinter, "Format for
                  Literal IPv6 Addresses in URL's", RFC 2451, December
                  1999.

   [RFC2945]      Wu, T., "The SRP Authentication and Key Exchange
                  System", RFC 2945, September 2000.

   [RFC3066]      Alvestrand, H., "Tags for the Identification of
                  Languages", STD 47, RFC 3066, January 2001.

   [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.

   [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, March
                  2004.

   [RFC3723]      Aboba, B., Tseng, J., Walker, J., Rangan, V. and F.
                  Travostino, "Securing Block Storage Protocols over
                  IP", RFC 3723, March 2004.

   [SAM2]         T10/1157D, SCSI Architecture Model - 2 (SAM-2).

   [SBC]          NCITS.306-1998, SCSI-3 Block Commands (SBC).

   [SPC3]         T10/1416-D, SCSI Primary Commands-3.

   [UNICODE]      Unicode Standard Annex #15, "Unicode Normalization
                  Forms", http://www.unicode.org/unicode/reports/tr15
ToP   noToC   RFC3720 - Page 208

Informative References

[BOOT] P. Sarkar, et al., "Bootstrapping Clients using the iSCSI Protocol", Work in Progress, July 2003. [Castagnoli93] G. Castagnoli, S. Braeuer and M. Herrman "Optimization of Cyclic Redundancy-Check Codes with 24 and 32 Parity Bits", IEEE Transact. on Communications, Vol. 41, No. 6, June 1993. [CORD] Chadalapaka, M. and R. Elliott, "SCSI Command Ordering Considerations with iSCSI", Work in Progress. [RFC3347] Krueger, M., Haagens, R., Sapuntzakis, C. and M. Bakke, "Small Computer Systems Interface protocol over the Internet (iSCSI) Requirements and Design Considerations", RFC 3347, July 2002. [RFC3385] Sheinwald, D., Staran, J., Thaler, P. and V. Cavanna, "Internet Protocol Small Computer System Interface (iSCSI) Cyclic Redundancy Check (CRC)/Checksum Considerations", RFC 3385, September 2002. [RFC3721] Bakke M., Hafner, J., Hufferd, J., Voruganti, K. and M. Krueger, "Internet Small Computer Systems Interface (iSCSI) Naming and Discovery, RFC 3721, March 2004. [SEQ-EXT] Kent, S., "IP Encapsulating Security Payload (ESP)", Work in Progress, July 2002.
ToP   noToC   RFC3720 - Page 209

Appendix A. Sync and Steering with Fixed Interval Markers

This appendix presents a simple scheme for synchronization (PDU boundary retrieval). It uses markers that include synchronization information placed at fixed intervals in the TCP stream. A Marker consists of: Byte / 0 | 1 | 2 | 3 | / | | | | |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| +---------------+---------------+---------------+---------------+ 0| Next-iSCSI-PDU-start pointer - copy #1 | +---------------+---------------+---------------+---------------+ 4| Next-iSCSI-PDU-start pointer - copy #2 | +---------------+---------------+---------------+---------------+ The Marker scheme uses payload byte stream counting that includes every byte placed by iSCSI in the TCP stream except for the markers themselves. It also excludes any bytes that TCP counts but are not originated by iSCSI. Markers MUST NOT be included in digest calculation. The Marker indicates the offset to the next iSCSI PDU header. The Marker is eight bytes in length and contains two 32-bit offset fields that indicate how many bytes to skip in the TCP stream in order to find the next iSCSI PDU header. The marker uses two copies of the pointer so that a marker that spans a TCP packet boundary should leave at least one valid copy in one of the packets. The structure and semantics of an inserted marker are independent of the marker interval. The use of markers is negotiable. The initiator and target MAY indicate their readiness to receive and/or send markers during login separately for each connection. The default is No.

A.1. Markers At Fixed Intervals

A marker is inserted at fixed intervals in the TCP byte stream. During login, each end of the iSCSI session specifies the interval at which it is willing to receive the marker, or it disables the marker altogether. If a receiver indicates that it desires a marker, the sender MAY agree (during negotiation) and provide the marker at the desired interval. However, in certain environments, a sender that does not provide markers to a receiver that wants markers may suffer an appreciable performance degradation.
ToP   noToC   RFC3720 - Page 210
   The marker interval and the initial marker-less interval are counted
   in terms of the bytes placed in the TCP stream data by iSCSI.

   When reduced to iSCSI terms, markers MUST indicate the offset to a
   4-byte word boundary in the stream.  The least significant two bits
   of each marker word are reserved and are considered 0 for offset
   computation.

   Padding iSCSI PDU payloads to 4-byte word boundaries simplifies
   marker manipulation.

A.2. Initial Marker-less Interval

To enable the connection setup including the Login Phase negotiation, marking (if any) is only started at the first marker interval after the end of the Login Phase. However, in order to enable the marker inclusion and exclusion mechanism to work without knowledge of the length of the Login Phase, the first marker will be placed in the TCP stream as if the Marker-less interval had included markers. Thus, all markers appear in the stream at locations conforming to the formula: [(MI + 8) * n - 8] where MI = Marker Interval, n = integer number. For example, if the marker interval is 512 bytes and the login ended at byte 1003 (first iSCSI placed byte is 0), the first marker will be inserted after byte 1031 in the stream.

A.3. Negotiation

The following operational key=value pairs are used to negotiate the fixed interval markers. The direction (output or input) is relative to the initiator.

A.3.1. OFMarker, IFMarker

Use: IO Senders: Initiator and Target Scope: CO OFMarker=<boolean-value> IFMarker=<boolean-value> Default is No. Result function is AND.
ToP   noToC   RFC3720 - Page 211
   OFMarker is used to turn on or off the initiator to target markers
   on the connection.  IFMarker is used to turn on or off the target to
   initiator markers on the connection.

   Examples:

     I->OFMarker=Yes,IFMarker=Yes
     T->OFMarker=Yes,IFMarker=Yes

   Results in the Marker being used in both directions while:

     I->OFMarker=Yes,IFMarker=Yes
     T->OFMarker=Yes,IFMarker=No

   Results in Marker being used from the initiator to the target, but
   not from the target to initiator.

A.3.2. OFMarkInt, IFMarkInt

Use: IO Senders: Initiator and Target Scope: CO OFMarkInt is Irrelevant when: OFMarker=No IFMarkInt is Irrelevant when: IFMarker=No Offering: OFMarkInt=<numeric-range-from-1-to-65535> IFMarkInt=<numeric-range-from-1-to-65535> Responding: OFMarkInt=<numeric-value-from-1-to-65535>|Reject IFMarkInt=<numeric-value-from-1-to-65535>|Reject OFMarkInt is used to set the interval for the initiator to target markers on the connection. IFMarkInt is used to set the interval for the target to initiator markers on the connection. For the offering, the initiator or target indicates the minimum to maximum interval (in 4-byte words) it wants the markers for one or both directions. In case it only wants a specific value, only a single value has to be specified. The responder selects a value within the minimum and maximum offered or the only value offered or indicates through the xFMarker key=value its inability to set and/or receive markers. When the interval is unacceptable the responder answers with "Reject". Reject is resetting the marker function in the specified direction (Output or Input) to No.
ToP   noToC   RFC3720 - Page 212
   The interval is measured from the end of a marker to the beginning of
   the next marker.  For example, a value of 1024 means 1024 words (4096
   bytes of iSCSI payload between markers).

   The default is 2048.

Appendix B. Examples

B.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   noToC   RFC3720 - Page 213

B.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   noToC   RFC3720 - Page 214

B.3. R2TSN/DataSN Use Examples

Output (write) data DataSN/R2TSN Example +------------------+-----------------------+----------------------+ |Initiator Function| PDU Type & 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   noToC   RFC3720 - Page 215
   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   noToC   RFC3720 - Page 216
   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 = 1, F=0     |                      |
   +------------------+-----------------------+----------------------+
   | * Receive Data   |   <<< SCSI Data-In    |   Send Data          |
   |                  |   DataSN = 2, F=1     |                      |
   +------------------+-----------------------+----------------------+
   | * Send Data      |   SCSI Data-Out >>>   |   Receive Data       |
   | for R2TSN 0      |   DataSN = 0, F=1     |                      |
   +------------------+-----------------------+----------------------+
   |                  |   <<< SCSI Response   |Send Status and Sense |
   |                  |   ExpDataSN = 3       |                      |
   +------------------+-----------------------+----------------------+
   | 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   noToC   RFC3720 - Page 217
   Unsolicited and immediate output (write) data with DataSN Example

   +------------------+-----------------------+----------------------+
   |Initiator Function|    PDU Type & 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 |                       |                      |
   +------------------+-----------------------+----------------------+

B.4. CRC Examples

N.B. 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
ToP   noToC   RFC3720 - Page 218
      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