RE: Multihoming by IP Layer Address Rewriting (MILAR)

[Coene Lode <Lode.Coene@siemens.atea.be>]

A few observations:

> -----Original Message-----
> From: Ramakrishna Gummadi [mailto:ramki@cs.berkeley.edu]
> Sent: dinsdag 4 september 2001 15:27
> To: Greg Maxwell
> Cc: Iljitsch van Beijnum; Peter Tattam; multi6@ops.ietf.org
> Subject: Re: Multihoming by IP Layer Address Rewriting (MILAR)
> 
> 
> Hi,
> I don't think that it is a good idea to assume that every 
> multihomed host
> has a DNS entry (for whatever reason); such an "anonymous" 
> multihomed host
> may initiate a connection, and  a multihoming solution must
> work (redundancy, transport layer survivability, etc.) for these
> connections as well. This is my primary complaint with DNS-based
> solutions.
> 
> My second complaint, and this applies to SCTP as well, is that we are
> implicitly assuming here that one end can do DNS lookups to learn the
> addresses of the other end---this may be impossible with busy servers.
> 
I thought this was standard practice. Have a name of the other side, do a
DNS lookup.
And anyway, the busy servers are a DNS problem, not a SCTP problem.

> Also, I don't think it is a good idea to mandate every 
> application to be
> aware of all multi-address details, which SCTP requires. We 
> must remember
> that SCTP was invented primarily for carrying signaling messages (the
> abstract says as much), and one of its co-authors I talked to says he
> thinks that general applications should *not* have to deal 
> with all these
> details.

As far as I know multihoming, having multiple addresses is the only way for
SCTP to multihome. If we had had the ability for a single identifier to
specify the multihomed association, I(amongst others) would have been more
than joyfull. Unfortunally, that not how multihoming works in the internet.
You have to come up with more than one IP address and each sour_destination
pair should(in theory) have its own path between the 2 endnodes. and each of
these paths should((which again in theory) not overlap wholly or partly.
If multihoming is done via multiple addresses, then we have to live by its
consequences.

Yours sincerly,
Lode Coene

> 
> -ramki
> 
> On Tue, 4 Sep 2001, Greg Maxwell wrote:
> 
> > On Tue, 4 Sep 2001, Iljitsch van Beijnum wrote:
> >
> > > On Tue, 4 Sep 2001, Peter Tattam wrote:
> > >
> > > > The discovery of the alternative destination address is 
> the crux of the problem
> > > > and needs to be handled in such a manner as to prevent 
> spoofing attacks.  IPsec
> > > > is too heavy to deal with the issue - my lightwieght 
> proposal of a SYN/ACK
> > > > exchange like TCP works but is subject to address list 
> explosion issues which I
> > > > hope to resolve through sending compressed address 
> trees instead of lists or
> > > > sets.
> > >
> > > Doing this in the SYN/ACK handshake has the disadvantage 
> that you have to
> > > do it over and over again for each TCP session. One 
> popular application
> > > comes to mind that uses many short lived TCP sessions...
> >
> > Intestingly enough SCTP addresses these applications (such 
> as HTTP) rather
> > well without overhead of assoication communication for every stream.
> >
> >
> >
> >
> >
> 
>