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

Text archives Help


Re: [Tsvwg] RE: [SCTP-Discussion] Multihoming


Chronological Thread 
  • From: Randall Stewart <randall AT stewart.chicago.il.us>
  • To: Ivan.Arias-Rodriguez AT nokia.com
  • Cc: bidulock AT openss7.org, Michael.Tuexen AT icn.siemens.de, tsvwg AT ietf.org, discussion AT sctp.de
  • Subject: Re: [Tsvwg] RE: [SCTP-Discussion] Multihoming
  • Date: Fri Feb 22 15:07:02 2002
  • List-id: SCTP Discussions <discussion.sctp.de>
Ivan:

Well you hit the nail on the head as ususal... without
doing this setup between multi-homed hosts does not
work very well... consider

Host-A Host-Z
IP-1 IP-5
IP-2 IP-6

---INIT(IP-1,IP-2)---\ /--INIT(IP-5,IP-6)---
X
toIP-1<-frm-IP-5-----/\------frm-IP-2------>toIP-6

Now unless inspection is done of the INIT/INIT-ACK the
two will NOT realize they are both setting up a association
at the same time.

Another consideration is Address filtering. Often times
a host MUST use the IP address of the interface that you
are sending from.. or get the packet filtered so in the above

----Frm-IP-1:INIT(IP-1,IP-2)------to(IP-5)----------->
(route to IP-1 points out
intf
of IP6.. note this may
be
from either only one
allowed
default route.. or some
other
reason).
<----------to(IP-1)--INIT-ACK(IP-5,IP-6)--------From-IP-6

And we have the same secenario..

As far as looking for this text in the RFC .. sadly the full text
was chopped in one of the IESG passes (due to my lack of communication
skills as to why it is there)... and now all that is left is the
trival little statement of:

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

I think we will need to add a few lines to the implementors guide...
Also
there is NOTHING in the spec that makes this illegal as you point out.
I remember we discussed this amongst the many emails and I addressed
just
these points.

Well more grist for the implementors guide :>

R

Ivan.Arias-Rodriguez AT nokia.com
wrote:
>
> Hi all!
>
> I also consider that situation to be legal. When I receive an INIT
> ACK I always look inside the parameters to see if it belongs to any open
> association (or in the COOKIE WAIT state). Moreover, I also do it with INIT
> chunks, to realize about establishment collisions or restart...
>
> If you don't allow this, I think it would be quite hard to detect
> INIT collisions in multihomed hosts... :-/
>
> I must admit that I forgot about this possibility until after
> having tested my implementation in a "brakeoff". But, could you Brian point
> to the section of the RFC that forbids this possibility? In my
> understanding it is a logical thing to do...
>
> Thanks!
>
> BR Iván Arias Rodríguez
>
> > -----Original Message-----
> > From: ext Brian F. G. Bidulock
> > [mailto:bidulock AT openss7.org]
> > Sent: 22. February 2002 5:39
> > To: Randall Stewart
> > Cc: Tuexen Michael;
> > 'tsvwg AT ietf.org';
> >
> > 'discussion AT sctp.de'
> > Subject: Re: [Tsvwg] RE: [SCTP-Discussion] Multihoming
> >
> >
> > Randall,
> >
> > On Thu, 21 Feb 2002, Randall Stewart wrote:
> >
> > > Now the above case IS legal and there is specific wording in
> > > the RFC that covers this.
> >
> > Could you point to the section of the RFC that requires
> > that this scenario be permitted?
> >
> > --brian
> >
> >
> >
> > --
> > 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 ¦
> >
> > _______________________________________________
> > tsvwg mailing list
> > tsvwg AT ietf.org
> > https://www1.ietf.org/mailman/listinfo/tsvwg
> >

--
Randall R. Stewart
randall AT stewart.chicago.il.us
815-342-5222 (cell phone)


Archive powered by MHonArc 2.6.19+.

Top of page