Question on HB in SCTP Multihoming

Hi Experts,
The following question is related to SCTP multihoming with Two IP
addresses in each Node (Client and the Server). 
I need to know the correct behavior of Heart beat response when one of
the IP addresses are not reachable.

Pls look at the example below;

Local Node							Remote
Node
(Client, Port 2905) 						(Server,
Port 2906)
(Primary)   10.114.4.132  Ip Interface1(Link1)		<---------->
10.102.232.7
(Secondary) 10.114.4.140 Ip Interface2(Link2)		<---------->
10.102.232.39
SCTP is Configured as Multihomed.

In the above configuration SCTP port address 10.114.4.140 is down, and
local node sends ICMP response as below;

2008-08-12 15:09:32.666577	10.102.232.39	10.114.4.140	SCTP
HEARTBEAT 
2008-08-12 15:09:32.667161	10.114.4.140	10.102.232.39	ICMP
Destination unreachable (Port unreachable)
ICMP:
Type: Destination Unreachable
Code: protocol Unreachabel

This causes the Remote Node to react badly , that is, Remote node sends
SCTP abort to the primary link (10.114.4.132  ) taking down the whole
SCTP user.
We donot have the full internal visibility to Remote Node as it belongs
to another Vendor. But what  we do know is that the  Remote Node does
not like the ICMP message as a response to the HB request.

According to RFC 4960 ICMP handling is Defined in Appendix C, we may
argue that the Local behaves correctly in sending the ICMP message. But
the question remains not answered is that "can the Local node sends ICMP
message as a response to HB request?". Is this specifically mentioned in
RFC 4960. What is the equivalent NAK message to HB request in SCTP?
Other Argument we had there related to ICMP message was that Remote node
does not support ICMP messages, meaning follows RFC 2960 , where ICMP
handling is not defined.
In this case what would be the Response to HB request? Should the local
Node Silently Discard the HB message?

Pls would you discuss this issues with respect relevant RFCs.
Thanks in Advance.



According to 
Best Regards 
Janaka Sooriyaaratchi

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