Re: Multihoming by IP Layer Address Rewriting (MILAR)

[Ramakrishna Gummadi <ramki@cs.berkeley.edu>]

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.

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.

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