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

Text archives Help


Re: [SCTP-Discussion] Multihoming


Chronological Thread 
  • From: Roland Gloeckler <gloeckle AT ind.uni-stuttgart.de>
  • To: bidulock AT openss7.org
  • Cc: discussion AT sctp.de
  • Subject: Re: [SCTP-Discussion] Multihoming
  • Date: Thu Feb 21 13:17:01 2002
  • List-id: SCTP Discussions <discussion.sctp.de>
  • Organization: University of Stuttgart, IND
Dear Mr. Bidulock, dear all:

My question is not completely answered by your response.

My problem (a little bit more detailed) is the following:

A has two interfaces with distinct IP addresses (A_1 and A_2).
B sends an INIT to one of them, e.g., A_2. The other interface A_1 is not
known to B yet.

In the sctp implementation A sends the INIT_ACK via the interface which is
the default entry in the IP routing table, e.g., A_1.

Now there are two error scenarios:

A has initialised a multihomed instance with both IP addresses.
For sending the INIT ACK it uses A_1 which is not known to B before it reads
the address list (with A_1 and A_2) in this INIT ACK chunk.
B responds with an ABORT.

or

A has initialised a singlehomed instance with the address A_2, which receives
the INIT.
For sending the INIT ACK it uses A_1 which is not even initialised in the
SCTP instance. In the cookie it uses A_2.
So it is obvious that SCTP has no control over the IP source address.
An association cannot be initialized.

To resume:

If the INIT_ACK chunk of an instance A uses in its IP header a source IP
address that is different from the destination address of the INIT chunk from
B, B refuses to accept it.


Section 5.1.2.c of the RFC says:

"IMPLEMENTATION NOTE: In some cases (e.g., when the implementation doesn't
control the source IP address that is used for transmitting), an endpoint
might need to include in its INIT or INIT ACK all possible IP addresses from
which packets to the peer could be transmitted."

B would have to read the list of IP addresses in the INIT ACK before it
searches in its association list to know the chunk belongs to A.

Or should the implementation force its IP layer to use the INIT destination
address as the source address for the INIT ACK? The RFC tries to cover cases
where this is not the case.

Regards,

Roland



On Friday 01 February 2002 20:38, Brian F. G. Bidulock wrote:
> 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


Archive powered by MHonArc 2.6.19+.

Top of page