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.
Terminology
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.
Known Issues
The following are the known issues with this update of Microsoft iSCSI Software Target 3.3.
Data-in F bit Multiple Bursts
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.
Immediate TMF Request
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.
Task Management Response Target Cold Reset
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.
Reject Data-out
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.
NOP-In Ping Response with Excess Ping Data
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.
NOP-In Ping Response on Timeout
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.
SCSI Response Excess Immediate Data
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.
Handling SCSI Response Retry
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.
Handling Text Response Text Field in Discovery Session
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.
Handling Text Request During Normal Session
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).
Handling Text Request During Discovery Session
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.
Handling Text Request with SendTarget=
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.
Handling Text Request with SendTarget=All during 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.
Text Response Negotiation Failure
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.
Handling Test Request with C bit
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.
Standard Login Key Negotiation
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.
Marker Negotiation
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.
Out of Range CmdSN
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.
Duplicate CmdSN
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.
Command Retry
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.
Incorrect Amount of Data Condition
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.
Task Management Response for Non-Existent Task
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.
Incorrect Logout Reason Code Being Accepted During Discovery
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).
Logout Response Non-existent Connection
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.
Handling Data Digest Error
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.
SCSI Response Error Detection
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.
Version Active Field During Login
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.
Handling Invalid Key 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 a received key of ImmediateDate=Yes, and not offer a response.
Invalid PDU During Login
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.
Handling NotUnderstood Key
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.
Handling Irrelevant Keys
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.
Handling NotUnderstood for Required Keys
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.
Handling Unexpected Unsolicited Data
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.
Handling Re-negotiation During Login
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.
Status Detail
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.
References
[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