DupInitInEstab.seq - Unexpected INIT chunk is received in ESTABLISHED state
To check that if unexpected INIT chunk is received in ESTABLISHED state
then the endpoint should response with an INIT-ACK chunk.
./DupInitInEstab.seq [-tooloption ...] -pkt ./DupInitInEstab.def
-tooloption : v6eval tool option
See Also: ../common/STD_PKT_COMMON.def
../common/SCTP_COMMON.def
Arrange the data in Endpoint A such that an INIT message is sent
to Endpoint B when association is established between endpoint A
and endpoint B. Also source IP address and destination IP address
are same as in the established association.
Endpoint A Endpoint B ULP
(ESTABLISHED) (ESTABLISHED)
INIT ----------------->
<----------------- INIT-ACK
DATA ----------------->
<----------------- SACK
TEST DESCRIPTION:
1. Attempt to make an association from endpoint A to endpoint B when
both endpoints have an association between them.
2. Check A: INIT-ACK message is sent in response to INIT message.
3. Check B: In the INIT-ACK message, verification tag field is set to
the peer's new tag value received in the duplicate INIT message.
4. Check C: In the INIT-ACK message, Init Tag is not equal to the Init
Tag in the existing association and it is a new value generated
randomly.
5. Check D: Cookie, sent in the INIT-ACK message, is the newly generated
Cookie with the information in the duplicate INIT message with local
tie tag and peer tie tag equal to current verification tag and peer
verification tag.
6. Check E: After sending INIT-ACK message,no other action is taken i.e.
existing association is not disturbed.
None
RFC 4960
5.2.2. Unexpected INIT in States Other than CLOSED, COOKIE-ECHOED,
COOKIE-WAIT, and SHUTDOWN-ACK-SENT
Unless otherwise stated, upon receipt of an unexpected INIT for this
association, the endpoint shall generate an INIT ACK with a State
Cookie. Before responding, the endpoint MUST check to see if the
unexpected INIT adds new addresses to the association. If new
addresses are added to the association, the endpoint MUST respond
with an ABORT, copying the 'Initiate Tag' of the unexpected INIT into
the 'Verification Tag' of the outbound packet carrying the ABORT. In
the ABORT response, the cause of error MAY be set to 'restart of an
association with new addresses'. The error SHOULD list the addresses
that were added to the restarting association. If no new addresses
are added, when responding to the INIT in the outbound INIT ACK, the
endpoint MUST copy its current Tie-Tags to a reserved place within
the State Cookie and the association's TCB. We shall refer to these
locations inside the cookie as the Peer's-Tie-Tag and the Local-Tie-
Tag. We will refer to the copy within an association's TCB as the
Local Tag and Peer's Tag. The outbound SCTP packet containing this
INIT ACK MUST carry a Verification Tag value equal to the Initiate
Tag found in the unexpected INIT. And the INIT ACK MUST contain a
new Initiate Tag (randomly generated; see Section 5.3.1). Other
parameters for the endpoint SHOULD be copied from the existing
parameters of the association (e.g., number of outbound streams) into
the INIT ACK and cookie.
After sending out the INIT ACK or ABORT, the endpoint shall take no
further actions; i.e., the existing association, including its
current state, and the corresponding TCB MUST NOT be changed.
Note: Only when a TCB exists and the association is not in a COOKIE-
WAIT or SHUTDOWN-ACK-SENT state are the Tie-Tags populated with a
value other than 0. For a normal association INIT (i.e., the
endpoint is in the CLOSED state), the Tie-Tags MUST be set to 0
(indicating that no previous TCB existed).