RFC 3720
Internet Small Computer Systems Interface (iSCSI)
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
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.
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.
- 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.
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.
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.
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.
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
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.
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)>
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.
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>
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>
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>=
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.
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.
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.
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
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.
[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.
[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
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.
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.
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.
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.
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 | | | +------------------+-----------------------+----------------------+
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 | | | +------------------+-----------------------+---------------------+
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 | | | +------------------+-----------------------+----------------------+
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 | | | +------------------+-----------------------+----------------------+
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).
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
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