Re: Re: regarding INIT ACK from different destination IP.

Brian,

In the same section please see the following explanation:

***********************

   An endpoint MUST NOT send any chunks to an UNCONFIRMED address, with
   the following exceptions:

   - A HEARTBEAT including a nonce MAY be sent to an UNCONFIRMED
     address.

   - A HEARTBEAT-ACK MAY be sent to an UNCONFIRMED address.

   - A COOKIE-ACK MAY be sent to an UNCONFIRMED address, but it MUST be
     bundled with a HEARTBEAT including a nonce.  An implementation that
     does NOT support bundling MUST NOT send a COOKIE-ACK to an
     UNCONFIRMED address.

   - A COOKE-ECHO MAY be sent to an UNCONFIRMED address, but it MUST be
     bundled with a HEARTBEAT including a nonce, and the packet MUST NOT
     exceed the path MTU.  If the implementation does NOT support
     bundling or if the bundled COOKIE-ECHO plus HEARTBEAT (including
     nonce) would exceed the path MTU, then the implementation MUST NOT
     send a COOKIE-ECHO to an UNCONFIRMED address.

************************

Thanks,
Bhanuprakash.



Brian F. G. Bidulock wrote:

>Bhanu,
>
>That passage does not say to drop the INIT-ACK.
>
>--brian
>
>Bhanu Prakash wrote:                                                 (Tue, 26 Sep 2006 13:16:27)
>  
>
>>   Brian,
>>   Please refer RFC-4460:
>>   ************************************************
>>   2.36.2.  Text Changes to the Document
>>      ---------
>>      Old text: None
>>      ---------
>>      ---------
>>      New text: (Section 5.4)
>>      ---------
>>      5.4.  Path Verification
>>      During association establishment, the two peers exchange a list of
>>       addresses.   In  the  predominant  case,  these  lists  accurately
>>   represent
>>      the addresses owned by each peer.  However, it is possible that a
>>      misbehaving peer may supply addresses that it does not own.  To
>>       prevent  this, the following rules are applied to all addresses of
>>   the
>>      new association:
>>       1) Any address passed to the sender of the INIT by its upper layer
>>   is
>>         automatically considered to be CONFIRMED.
>>       2)  For the receiver of the COOKIE-ECHO the only CONFIRMED address
>>   is
>>         the one that the INIT-ACK was sent to.
>>      3) All other addresses not covered by rules 1 and 2 are considered
>>         UNCONFIRMED and are subject to probing for verification.
>>   ******************************************************************
>>   In  this  case  since  the  INIT-ACK  is received from an un-confirmed
>>   address, should
>>   it be accepted or not..?
>>   Thanks
>>   Bhanuprakash.
>>   Brian F. G. Bidulock wrote:
>>
>>Padmalochan,
>>
>>Padmalochan Moharana wrote:         (Tue, 26 Sep 2006 00:17:42)
>>  
>>
>>Hi Brian
>>
>>please suggest for the following doubt.
>>
>>Should endoint (in case of Multi-homed), encode COOKIE
>>ECHO on receive the INIT_ACK from a different
>>destination IP of the INIT or it should  ignores the
>>INIT_ACK.
>>    
>>
>>If the INIT_ACK corresponds to an INIT that was sent (addresses
>>in the address list, verification tag, parameters and a cookie),
>>send the COOKIE ECHO.
>>
>>Why would you think otherwise?
>>
>>--brian
>>
>>  
>>    
>>
>
>  
>

_______________________________________________
Sigtran mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/sigtran