RE: Supporting 4 way connections in LKSCTP

[David Laight]

> > In normal operation, IP-A sends INIT to IP-X, IP-X returns INIT_ACK to
> > IP-A. IP-A then sends HB to IP-X, IP-X then returns HB_ACK to IP-A. In
> > the meantime, IP-B sends HB to IP-Y and IPY returns HB_ACK.
> >
> > In case of the path between IP-A and IP-X is broken, IP-B sends INIT
> > to IP-X, NODE-B uses IP-Y to return INIT_ACK to IP-B. Then IP-B sends
> > HB to IP-X, and IP-Y returns HB_ACK to IP-B. In the meantime, the HB
> > communication between IP-B and IP-Y follows the normal flow.
> >
> > Can I confirm, is it really valid?
> 
> As long as NODE-B knows about both IP-A and IP-B, and NODE-A knows about
> both IP-X and IP-Y (meaning all the addresses were exchanged inside INIT
> and INIT-ACK), then this situation is perfectly valid.  In fact, this
> has been tested an multiple interops.

There are some network configurations that do cause problems.
Consider 4 systems with 3 LAN segments:
A) 10.10.10.1 on LAN X and 192.168.1.1 on LAN Y.
B) 10.10.10.2 on LAN X and 192.168.1.2 on LAN Y.
C) 10.10.10.3 on LAN X.
D) 10.10.10.4 on LAN X and 192.168.1.2 on LAN Z.
There are no routers between the networks (and none of the systems
are running IP forwarding).

If A connects to B everything is fine - traffic can use either LAN.

Connections from A to C are problematic if C tries to send anything
(except a HB) to 192.168.1.1 before receiving a HB response.
One of the SCTP stacks we've used did send messages to an
inappropriate address, but I've forgotten which one.

Connections between A and D fail unless the HB errors A receives
for 192.168.1.2 are ignored.

Of course the application could explicitly bind to only the 10.x address
but that requires the application know the exact network topology
and may be difficult for incoming calls.

	David

èº{.nÇ+‰·Ÿ®‰­†+%ŠËlzwm…ébëæìr¸›zX§»®w¥Š{ayºÊÚë,j­¢f£¢·hš‹àz¹®w¥¢¸¢·¦j:+v‰¨ŠwèjØm¶Ÿÿ¾«‘êçzZ+ƒùšŽŠÝj"ú!¶iO•æ¬z·švØ^¶m§ÿðÃnÆàþY&—