NAME

  DupInitInCookieEchoed2.seq - Duplicate INIT chunk is received in COOKIE-ECHOED state (MUST NOT change state)


PURPOSE

  To check that if INIT chunk is received in COOKIE-ECHOED state then the
  endpoint should respond with an INIT-ACK using the same parameters it
  sent in its original INIT chunk. After that, the endpoint MUST NOT
  change its state, the T1-cookie timer shall be left running.


SYNOPSIS

  ./DupInitInCookieEchoed2.seq [-tooloption ...] -pkt ./DupInitInCookieEchoed2.def
    -tooloption : v6eval tool option
  See Also: ../common/STD_PKT_COMMON.def
            ../common/SCTP_COMMON.def


PRE-TEST CONDITION

  Association not established between endpoint A and B. Also arrange the
  data in endpoint B such that upper layers send Associate primitive to
  startup an association with endpoint A.


TEST PROCEDURE

  Endpoint A                           Endpoint B                ULP
  (CLOSED)                             (CLOSED)
                                                   <-----    Associate
                <-----------------      INIT
  INIT-ACK      ----------------->
                <-----------------      COOKIE-ECHO
  INIT          ----------------->
                <-----------------      INIT-ACK
  COOKIE-ACK    ----------------->
                                                   <-----    Send
                <-----------------      DATA
  SACK          ----------------->
  TEST DESCRIPTION:
  1. Start normal association procedure by sending associate primitive 
     from ULP in endpoint B and from ULP in endpoint A at the same time.
     Record the message sequence using a signal emulator.
  2. Check A: After send INIT ACK, the endpoint B MUST NOT change its state.
  3. Check B: Association is established.


NOTE

  None


REFERENCE

  RFC 4960
  5.2.1.  INIT Received in COOKIE-WAIT or COOKIE-ECHOED State (Item B)
    This usually indicates an initialization collision, i.e., each
    endpoint is attempting, at about the same time, to establish an
    association with the other endpoint.
    Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST
    respond with an INIT ACK using the same parameters it sent in its
    original INIT chunk (including its Initiate Tag, unchanged).  When
    responding, the endpoint MUST send the INIT ACK back to the same
    address that the original INIT (sent by this endpoint) was sent.
    Upon receipt of an INIT in the COOKIE-ECHOED state, an endpoint MUST
    respond with an INIT ACK using the same parameters it sent in its
    original INIT chunk (including its Initiate Tag, unchanged), provided
    that no NEW address has been added to the forming association.  If
    the INIT message indicates that a new address has been added to the
    association, then the entire INIT MUST be discarded, and NO changes
    should be made to the existing association.  An ABORT SHOULD be sent
    in response that MAY include the error 'Restart of an association
    with new addresses'.  The error SHOULD list the addresses that were
    added to the restarting association.
    When responding in either state (COOKIE-WAIT or COOKIE-ECHOED) with
    an INIT ACK, the original parameters are combined with those from the
    newly received INIT chunk.  The endpoint shall also generate a State
    Cookie with the INIT ACK.  The endpoint uses the parameters sent in
    its INIT to calculate the State Cookie.
    After that, the endpoint MUST NOT change its state, the T1-init timer
    shall be left running, and the corresponding TCB MUST NOT be
    destroyed.  The normal procedures for handling State Cookies when a
    TCB exists will resolve the duplicate INITs to a single association.
    For an endpoint that is in the COOKIE-ECHOED state, it MUST populate
    its Tie-Tags within both the association TCB and inside the State
    Cookie (see Section 5.2.2 for a description of the Tie-Tags).