First login?
Lost password?
 
 
sctp-discussion AT lists.franken.de 
SCTP Discussions

Text archives Help


[SCTP-Discussion] Multihoming


Chronological Thread 
  • From: Roland Gloeckler <gloeckle AT ind.uni-stuttgart.de>
  • To: discussion AT sctp.de
  • Subject: [SCTP-Discussion] Multihoming
  • Date: Fri Feb 1 19:12:00 2002
  • List-id: SCTP Discussions <discussion.sctp.de>
  • Organization: University of Stuttgart, IND
Dear all,

when I was working with SCTPlib 1 pre14 I found an interesting behaviour.
I had one PC (let's call it "A") with two network cards (let's call them A_1
and A_2) connected to another one (let's call it "B") with only one (B_1).
The configuration was: Interfaces A_1 and B_1 were connected to the same LAN
and A_2 was connected to the LAN via a router.

After some minor changes to testengine.c I was able to use test_tool to
initialise an SCTP multihoming instance on A for the addresses A_1 and A_2.
In the script for B I tried to start an association with A, but only included
one IP address, e.g., A_2.
B successfully sent an INIT message to A_2, which responded with a valid
INIT_ACK.
If A responded via A_2 all went well.

BUT: When A used the other interface A_1 to send the INIT_ACK (which
included the list of its own addresses A_1 and A_2 belonging to that
instance) to B,
B was not able to find the address A_1 in its association list, since
it didn't know it yet, and answered with an ABORT message to A.

If I change the destination address in B's script to A_1 and change the
routing table in A to send packets to B via A_2 the result is the same.

To summarize:
If the INIT_ACK chunk of a multihomed instance A uses a source IP address
that is different from the one B sent the INIT chunk to, B refuses to accept
it.

When I was looking into the RFC to search for more details, I only found out
that the behaviour is according to the rules that no INIT_ACK is to be
accepted which uses an unknown source transport address.
Now I wonder if this is a general problem not answered by the RFC.
I can think of several ways to come around the problem for my purposes, but
they are not adequate for general purposes.

Has anyone heard of this situation before? Please tell me.

Regards,

Roland


Archive powered by MHonArc 2.6.19+.

Top of page