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: Thu Feb 21 13:57:02 2002
  • Dsn-notification-to: <bidulock AT openss7.org>
  • List-id: SCTP Discussions <discussion.sctp.de>
  • Organization: http://www.openss7.org/
Roland,

IMO Section 5.1.2.c is not for INIT/INIT_ACK.

B's behaviour is correct. If it receives an INIT_ACK with a source
address different from the address to which it sent the INIT, it
should reply to the INIT_ACK with an abort.

If you want more opinions, ask the question on
tsvwg AT ietf.org

--brian


On Thu, 21 Feb 2002, Roland Gloeckler wrote:

> 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

--
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