Microsoft iSCSI Software Target 3.3 Implementation Notes
Microsoft® iSCSI Software Target 3.3 was implemented to comply with the industry standards that are specified by RFC 3720 and RFC 5048. To verify this compliance, iSCSI Software Target 3.3 was tested by a compliance testing organization. This document lists the issues that were found during the testing.
iSCSI initiator: A computer that requests access to a remote storage device. An iSCSI initiator issues small computer system interface (SCSI) commands to request services from components, which are logical units of a server known as "targets." For more information concerning iSCSI initiators and targets, see RFC 3720.
iSCSI Software Target: A software implementation of the iSCSI technology that is specified in RFC3720, along with supporting functionality.
iSCSI session: A group of TCP connections that link an iSCSI initiator with a target. For more information, see RFC 3720, section 3.4.
The following are the known issues with this update of Microsoft iSCSI Software Target 3.3.
RFC 3720, section 10.7.1, specifies the following:
DataSegmentLength MUST not exceed MaxRecvDataSegmentLength for the direction it is sent and the total of all the DataSegmentLength of all PDUs in a sequence MUST not exceed MaxBurstLength (or FirstBurstLength for unsolicited data).
The behavior implemented by the Microsoft iSCSI Software Target 3.3:
The iSCSI Software Target was observed to send a data sequence that was larger than the MaxBurstLength. In the case where the initiator negotiates MaxRecvDataSegmentLength=512/MaxBurstLength=1024 and issues a read of 2048 bytes, the iSCSI Software Target replies with four PDUs, which have 512 bytes of data each, and it sets the F bit only on the last PDU.
RFC 3720, section 10.5.1, specifies the following:
The Task Management functions provide an initiator with a way to explicitly control the execution of one or more Tasks (SCSI and iSCSI tasks).
The behavior implemented by the Microsoft iSCSI Software Target 3.3:
The iSCSI Software Target was observed to never send a response to a Task Management function request to ABORT TASK on an outstanding Write command.
RFC 3720, section 10.6.1, specifies the following:
For the TARGET COLD RESET and TARGET WARM RESET functions, the target cancels all pending operations across all Logical Units known to the issuing initiator. For the TARGET COLD RESET function, the targets MUST then close all of its TCP connections to all initiators (terminates all sessions).
The behavior implemented by the Microsoft iSCSI Software Target 3.3:
The iSCSI Software Target does not terminate the connections, and it responded with 0 (indicating that the function was complete) when it received a Cold Reset command.
RFC 3720, section 10.17.3, specifies the following:
StatSN, ExpCmdSN and MaxCmdSN: These fields carry their usual values and are not related to the rejected command. StatSN is advanced after a Reject.
The behavior implemented by the Microsoft iSCSI Software Target 3.3:
The iSCSI Software Target was observed to send the value in host native byte order for StatSN for the Reject PDU.
RFC 3720, section 10.7.1, specifies the following:
DataSegmentLength MUST not exceed MaxRecvDataSegmentLength for the direction it is sent and the total of all the DataSegmentLength of all PDUs in a sequence MUST not exceed MaxBurstLength (or FirstBurstLength for unsolicited data).
The behavior implemented by the Microsoft iSCSI Software Target 3.3:
The iSCSI Software Target was observed to transmit a Data-In PDU with the DataSegmentLength exceeding the MaxRecvDataSegmentLength of the iSCSI initiators, regardless of whether the request was set to be immediate or non-immediate.
RFC 3720, section 10.19.1, specifies the following:
If the target is sending a NOP-In as a Ping (intending to receive a corresponding NOP-Out), this field is set to a valid value (not the reserved 0xffffffff).
The behavior implemented by the Microsoft iSCSI Software Target 3.3:
The iSCSI Software Target periodically sends a NOP-In as a ping, with the Target Transfer Tag field set to the reserved value of 0xffffffff.
RFC 3720, section 3.2.4.2, specifies the following:
It is also an error for an initiator to send more unsolicited data, whether immediate or as separate PDUs, than FirstBurstLength.
The behavior implemented by the Microsoft iSCSI Software Target 3.3:
When responding to a Write command with more immediate data than specified by the FirstBurstLength, the iSCSI Software Target sends a SCSI Response PDU with a status of Good.
RFC 3720, section 6.2.1, specifies the following:
By resending the same iSCSI command PDU ("retry") in the absence of a command acknowledgment (by way of an ExpCmdSN update) or a response, an initiator attempts to "plug" (what it thinks are) the discontinuities in CmdSN ordering on the target end.
The behavior implemented by the Microsoft iSCSI Software Target 3.3:
Based on the implementation behavior that is described in Duplicate CmdSN, the iSCSI Software Target closed the connections when the duplicate Write command was issued.
RFC 3720, section 10.11.1, specifies the following:
A Text Response with the F bit set to 1 in response to a Text Request with the F bit set to 0 is a protocol error.
The behavior implemented by the Microsoft iSCSI Software Target 3.3:
The Microsoft iSCSI Software Target was observed to set F bit with 1 in the Text Response PDU when the text request has the F bit set to 0.
RFC 3720, section 3.5.3.1, specifies the behavior of Text Request and Text Response as follows:
Text requests and responses are designed as a parameter negotiation vehicle and as a vehicle for future extension.
In the data segment, Text Requests/Responses carry text information using a simple "key=value" syntax.
Text Request/Responses may form extended sequences using the same Initiator Task Tag. The initiator uses the F (Final) flag bit in the text request header to indicate its readiness to terminate a sequence. The target uses the F (Final) flag bit in the text response header to indicate its consent to sequence termination.
Text Request and Responses also use the Target Transfer Tag to indicate continuation of an operation or a new beginning. A target that wishes to continue an operation will set the Target Transfer Tag in a Text Response to a value different from the default 0xffffffff.
An initiator willing to continue will copy this value into the Target Transfer Tag of the next Text Request. If the initiator wants to restart the current target negotiation (start fresh) will set the Target Transfer Tag to 0xffffffff.
Although a complete exchange is always started by the initiator, specific parameter negotiations may be initiated by the initiator or target.
The behavior implemented by the Microsoft iSCSI Software Target 3.3:
The iSCSI Software Target was observed to disconnect the session after it received a Text Request during a normal session, when the following conditions existed:
F bit was set to 0
There was an attached MaxRecvDataSegmentLengthKey
This happened with or without a valid ITT (Initiator Task tag).
RFC 3720, section 3.3, specifies the following:
Discovery-session - a session only opened for target discovery. The target MUST ONLY accept text requests with the SendTargets key and a logout request with the reason "close the session". All other requests MUST be rejected.
The behavior implemented by the Microsoft iSCSI Software Target 3.3:
The iSCSI Software Target was observed to disconnect after receiving a text request with an attached MaxRecvDataSegmentLength key during a Discovery session.
RFC 3720, Appendix D, specifies the following:
If the SendTargets value is nothing in the Text Request, “The session should only respond with addresses for the target to which the session is logged in. This MUST be supported on operational sessions, and MUST NOT return targets other than the one to which the session is logged in.”
The behavior implemented by the Microsoft iSCSI Software Target 3.3:
The iSCSI Software Target was observed to disconnect after receiving a text request with an attached “SetTargets=” key during a discovery session and during a normal session.
RFC 3720, Appendix D, specifies the following:
If the SendTargets value is “All” in the Text Request, “The initiator is requesting that information on all relevant targets known to the implementation be returned. This value MUST be supported on a discovery session, and MUST NOT be supported on an operational session.”
The behavior implemented by the Microsoft iSCSI Software Target 3.3:
The iSCSI Software Target was observed to disconnect after receiving a text request with an attached “SetTargets=All” key during a normal session.
RFC 3720, Section 6.10, specifies the following:
A negotiation failure is considered to be one or more of the following:
None of the choices, or the stated value, is acceptable to one of the sides in the negotiation.The text request timed out and possibly terminated.The text request was answered with a Reject PDU.
The behavior implemented by the Microsoft iSCSI Software Target 3.3:
The iSCSI Software Target was observed to disconnect the session after receiving a text request with the F bit set to 0, and an attached MaxRecvDataSegmentLengthKey.
RFC 3720, Section 5.2, specifies the following:
A target receiving a Text or Login Request with the C bit set to 1 MUST answer with a Text or Login Response with no data segment (DataSegmentLength 0).
The behavior implemented by the Microsoft iSCSI Software Target 3.3:
The iSCSI Software Target was observed to disconnect after receiving a text request with C bit set to 1.
RFC 3720, section 10.13.3, specifies the following:
For a new session, the target MUST generate a non-zero TSIH and ONLY return it in the Login Final-Response.
The behavior implemented by the Microsoft iSCSI Software Target 3.3:
When the iSCSI initiator performed a standard login and negotiated the login parameters, the iSCSI Software Target was observed to set the TSIH field in the first Login Response PDU.
RFC 3720, section 5.2, specifies the following:
All keys in this document, except for the X extension formats, MUST be supported by iSCSI initiators and targets when used as specified here. If used as specified, these keys MUST NOT be answered with NotUnderstood.
The behavior implemented by the Microsoft iSCSI Software Target 3.3:
The iSCSI Software Target was observed to not respond to the OFMarker, IFMarker, IFMarkerInt, and IFMarkerInt keys.
RFC 3720, section 3.2.2.1 specifies the following:
The target MUST silently ignore any non-immediate command outside of this range or non-immediate duplicates within the range. The CmdSN carried by immediate commands may lie outside the ExpCmdSN to MaxCmdSN range.
The behavior implemented by the Microsoft iSCSI Software Target 3.3:
The iSCSI Software Target closes the connection when it receives a command out of the range.
RFC 3720, section 3.2.2.1 specifies the following:
The target MUST silently ignore any non-immediate command outside of this range or non-immediate duplicates within the range.
The behavior implemented by the Microsoft iSCSI Software Target 3.3:
The iSCSI Software Target closes the connection after it receives a PDU with duplicate CmdSN.
RFC 3720, section 6.7, specifies the following:
When a target receives any iSCSI PDU with a payload digest error, it MUST answer with a Reject PDU with a reason code of Data-Digest-Error and discard the PDU.
The behavior implemented by the Microsoft iSCSI Software Target 3.3:
The iSCSI Software Target closes the connection when it receives a PDU with a data digest error.
RFC 3720, section 10.4.7.2, specifies the following:
The target reports the ‘Incorrect amount of data’ condition if during data output the total data length to output is greater than FirstBurstLength and the initiator sent unsolicited non-immediate data but the total amount of unsolicited data is different than FirstBurstLength. The target reports the same error when the amount of data sent as a reply to an R2T does not match the amount requested.
The behavior implemented by the Microsoft iSCSI Software Target 3.3:
The iSCSI Software Target responds with status of 0x00 (good) after receiving more than 512 bytes of data when FirstBurstLength=512.
The iSCSI Software Target responds with R2T command when it receives a Write request with ExpectedDataTransferLength=2048 and only 512 bytes of data attached.
RFC 3720, section 10.6.1, specifies the following:
The target provides a Response “1” for Task does not exist.
The behavior implemented by the Microsoft iSCSI Software Target 3.3:
The iSCSI Software Target was observed to respond with 0 (function complete) when receiving a non-existent RefrencedTaskTab and a RefCmdSN outside the valid CmdSN window.
RFC 3720, section 3.3, specifies the following:
Discovery-session - a session only opened for target discovery. The target MUST ONLY accept text requests with the SendTargets key and a logout request with the reason "close the session". All other requests MUST be rejected.
The behavior implemented by the Microsoft iSCSI Software Target 3.3:
During the discovery session, the iSCSI Software Target sends a response code of 0x00 (success) in response to a logout request with reason code 2 (remove connection with recovery).
RFC 3720, section 10.14, specifies the following:
When receiving a Logout Request with the reason code of "close the connection" or "close the session", the target MUST terminate all pending commands, whether acknowledged via ExpCmdSN or not, on that connection or session respectively.
The behavior implemented by the Microsoft iSCSI Software Target 3.3:
The iSCSI Software Target sends a response code of 0x00 (success) in response to a logout request with reason code 1 (closes the connection) for a non-existent CID.
RFC 3720, section 6.7, specifies the following:
When a target receives any iSCSI PDU with a payload digest error, it MUST answer with a Reject PDU with a reason code of Data-Digest-Error and discard the PDU.
The behavior implemented by the Microsoft iSCSI Software Target 3.3:
The iSCSI Software Target closes the connection when it receives a PDU with a data digest error.
RFC 3720, section 10.4.2, specifies the following:
If a SCSI device error is detected while data from the initiator is still expected (the command PDU did not contain all the data and the target has not received a Data PDU with the final bit Set), the target MUST wait until it receives a Data PDU with the F bit set in the last expected sequence before sending the Response PDU.
The behavior implemented by the Microsoft iSCSI Software Target 3.3:
The iSCSI Software Target was observed to issue a Reject PDU with reason 0x09 (invalid PDU field) and closed the connection when it received invalid ITT (Initiator Task tag) in the Data-out PDUs.
RFC 3720, section 10.13.2, specifies the following:
If the target does not support a version within the range specified by the initiator the target rejects the login and [the Version-Active] field indicates the lowest supported version of the target.
The behavior implemented by the Microsoft iSCSI Software Target 3.3:
The iSCSI Software Target was observed to accept a login request and proceed with the login when receiving a unsupported iSCSI version parameter.
RFC 3720, section 5.2, specifies the following:
Any key not understood by the acceptor may be ignored by the acceptor without affecting the basic function. However, the answer for a key not understood MUST be key=NotUnderstood.
The behavior implemented by the Microsoft iSCSI Software Target 3.3:
The iSCSI Software Target was observed to ignore a received key of ImmediateDate=Yes, and not offer a response.
RFC 3720, section 3.2.3, specifies the following:
Once the Login phase has started, if the target receives any PDU except a Login request, it MUST send a Login reject (with Status "invalid during login") and then disconnect.
The behavior implemented by the Microsoft iSCSI Software Target 3.3:
The iSCSI Software Target 3.3 was observed to disconnect after receiving an invalid PDU during login.
RFC 3720, Section 5.2, specifies the following:
Any key not understood by the acceptor may be ignored by the acceptor without affecting the basic function. However, the answer for a key not understood MUST be key=NotUnderstood.
The behavior implemented by the Microsoft iSCSI Software Target 3.3:
The iSCSI Software Target was observed to ignore the received vendor-specific X keys without giving a response.
RFC 3720, section 5.2, specifies the following:
Any key not understood by the acceptor may be ignored by the acceptor without affecting the basic function. However, the answer for a key not understood MUST BE key=NotUnderstood.
In RFC 5048, section 9.1:
The following table describes the semantics that an iSCSI target MUST support for respective negotiated key values. Whenever this key is negotiated, at least the RFC3720 and ResponseFence values MUST be offered as options by the negotiation originator.
The behavior implemented by the Microsoft iSCSI Software Target 3.3:
The iSCSI Software Target was observed to not offer a response to the TaskReporting key.
RFC 3720, section 5.2, specifies the following:
All keys in this document, except for X extension formats, MUST be supported by iSCSI initiators and targets when used as specified here. If used as specified, these keys MUST NOT be answered with NotUnderstood.
The behavior implemented by the Microsoft iSCSI Software Target 3.3:
The iSCSI Software Target was observed to send a login success message when it received a request with the TargetPortalGroupTag=NotUnderstood key.
RFC 3720, section 12.11, specifies the following:
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.
The behavior implemented by the Microsoft iSCSI Software Target 3.3:
When the ImmediateData is set to No, and InitialR2T is set to Yes, the iSCSI Software Target was observed to respond with the status Good when it received a Write command with unexpected unsolicited data.
RFC 3720, section 5.3, specifies the following:
Neither the initiator nor the target should attempt to declare or negotiate a parameter more than once during login except for responses to specific keys that explicitly allow repeated key declarations (e.g., TargetAddress). An attempt to renegotiate or redeclare parameters not specifically allowed MUST be detected by the initiator and target. If such an attempt is detected by the target, the target MUST respond with Login Reject (initiator error).
The behavior implemented by the Microsoft iSCSI Software Target 3.3:
The iSCSI Software Target was observed to allow renegotiation of the following parameters during the login phase:
ImmediateData key=value pair to yes
MaxBurstLength key=value pair to 32524
DataDigest key=value pair to CRC32C
Double negotiation of DataDigest key=value pair in the same PDU
When it receives the previous parameters twice in the negotiation phase, the iSCSI Software Target proceeds with the login request.
RFC 3720, section 10.13.5, specifies the table of currently allocated status codes, including the following:
0205 indicates the requested iSCSI version range is not supported by the target.
The behavior implemented by the Microsoft iSCSI Software Target 3.3:
When it receives an unsupported version during a login request, the iSCSI Software Target was observed to not provide the Status Detail of 0205 (unsupported version) because of the implementation described in Version Active Field During Login.
[RFC3720] Satran, J., Meth, K., Sapuntzakis, C., et al., "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004, https://www.ietf.org/rfc/rfc3720.txt
[RFC5048] M. Chadalapaka, et al., "Internet Small Computer Systems Interface (iSCSI) Corrections and Clarifications", RFC 5048, October 2007, https://www.ietf.org/rfc/rfc5048.txt