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

Text archives Help


Re: [SCTP-Discussion] Multihoming


Chronological Thread 
  • From: "Brian F. G. Bidulock" <bidulock AT openss7.org>
  • To: Roland Gloeckler <gloeckle AT ind.uni-stuttgart.de>
  • Cc: discussion AT sctp.de
  • Subject: Re: [SCTP-Discussion] Multihoming
  • Date: Fri Feb 1 20:42:01 2002
  • Dsn-notification-to: <bidulock AT openss7.org>
  • List-id: SCTP Discussions <discussion.sctp.de>
  • Organization: http://www.openss7.org/
Roland,

The effect your describe was discussed on TSVWG. The
defficiency of SCTP was characterized as RFC2960's inability
to provide for reliable initialization of an association.

The effect you describe is required by RFC 2960 section 5.1
paragraph (B): "... The destination IP address of the INIT ACK
MUST be set to the source IP address of the INIT to which this
INIT ACK is responding."

The behavior exhibited by SCTPlib is correct. The
implementation should reply with an ABORT in response to the
INIT ACK sent to the wrong address.

--brian

On Fri, 01 Feb 2002, Roland Gloeckler wrote:

> 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
> _______________________________________________
> discussion mailing list
> discussion AT sctp.de
> http://www.sctp.de/mailman/listinfo/discussion

--
Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦
bidulock AT openss7.org
¦ world; the unreasonable one persists in ¦
http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦
¦ Therefore all progress depends on the ¦
¦ unreasonable man. -- George Bernard Shaw ¦


Archive powered by MHonArc 2.6.19+.

Top of page