tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 3720

 
 
 

Internet Small Computer Systems Interface (iSCSI)

Part 8 of 9, p. 187 to 218
Prev RFC Part       Next RFC Part

 


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


Next RFC Part