Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR)

From: Coene Lode <[email-masked]>
Date: Tue, 4 Sep 2001 15:57:25 +0200

A few observations:

> -----Original Message-----
> From: Ramakrishna Gummadi [mailto:[email-masked]]
> Sent: dinsdag 4 september 2001 15:27
> To: Greg Maxwell
> Cc: Iljitsch van Beijnum; Peter Tattam; [email-masked]
> 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.
> >
> >
> >
> >
> >
> 
>

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 4 Sep 2001 12:45:00 -0700

> From: RJ Atkinson [mailto:[email-masked]]
> At 15:16 04/09/01, Christian Huitema wrote:
> >Game stations, and PC running video-games, obtain
> >incoming connectivity by registering their address in a game lobby.
> 
> Christian,
> 
>         A few special cases != generally.

We are not speaking of a few special cases here. Game players are in the
tens of millions, at least. Last time I looked at the IM market, there
were at least 150 million users. Many of us hope to see Internet
telephony grow to the size of the existing telephone network. Napster
had at one point 70 million users... I will grant you that the vast
majority of web servers can be reached on the DNS. But that is
definitely not a reason to build a dependency between IP and the DNS. I
want to support game users, I want to let then multi-home between DSL
and Cable.

There is also a practicality issue. The current DNS practice would hit
any DNS based scheme in multiple ways: many reverse (PTR) entries, and
in fact many direct (A, AAAA) entries are "pro-forma", such as
"64-5-6-7.example.net"; many server entries use multiple A records for
load balancing, with addresses pointing at different servers. You will
get maximum confusion if you try to use the existing data for
multi-homing.

Then, there is a performance issue. Last time I checked, about 25% of
DNS queries took more than 3 seconds to complete. In fact, if you look
at http://www.netsizer.com/daily/quality_today.html, you observe that at
least 5% of queries for the addresses of large servers don't complete in
less than 3 seconds, and that 5% of queries for the addresses of small
servers don't complete in less than 6 seconds! I don't believe that
adding more load to the DNS is a good idea, when the infrastructure is
so obviously strained.

There is an obvious alternative to DNS discovery of peer addresses,
which is, have the peer tell you. We obviously have to wrestle with the
security implications, but there have to be solutions -- nonce, s-key,
self signed certificates, etc. We don't need to throw a server in the
mix.

-- Christian Huitema

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 04 Sep 2001 16:06:16 -0400

At 15:45 04/09/01, Christian Huitema wrote:
>There is also a practicality issue. 

Good point.  

>adding more load to the DNS is a good idea, when the infrastructure is

If DNS is about to collapse, that's a pretty urgent problem to fix,
because it is the primary way folks find the peer in the first place
these days.

>which is, have the peer tell you. 

One must find the peer somehow before the peer can give you their
other addresses.  Or are you suggesting that just using IP addresses 
in host files is user-friendly and scales to the current Internet ?

Ran

---

From: "Michel Py" <[email-masked]>
Date: Tue, 4 Sep 2001 17:35:29 -0700

I agree with that. Routing should not rely on DNS because DNS needs
routing.

Christian Huitema wrote:
>> There is no dependency between connectivity and the DNS, and there
>> should not be. A multi-homing solution that depends on the DNS is a
>> non starter.

---

From: "Michel Py" <[email-masked]>
Date: Tue, 4 Sep 2001 18:38:11 -0700

IMHO, DNS servers would be prime canditates to be multihomed by a
layer3 (OSI, also called the network layer or the Internet layer)
solution.

Part of the current DNS problems is that lots of them are not
multihomed.

RJ Atkinson wrote:
>> I wouldn't be bothered if requiring at least one AAAA/A6 record
>> to exist was a precondition to multihoming working.  I might even
>> be comfortable with requiring more than one in DNS, if explained
>> as part of a detailed proposal (not sure, but open minded).  Clearly
>> you and Christian would be bothered and that has been noted.

---

From: "Nigel Bragg" <[email-masked]>
Date: Wed, 5 Sep 2001 11:01:12 +0100

Hi,
> From:	marcelo bagnulo [SMTP:[email-masked]]
> Sent:	Wednesday, September 05, 2001 4:46 AM
> To:	Peter Tattam
> Cc:	multi6
> Subject:	RE: Multihoming by IP Layer Address Rewriting (MILAR)
> 
 ----------------------- >8 -----------------------

> > Is it worth pursuing the reachability cache idea?
> 
> I find it interesting. I think that bragg draft proposed something
> related,
> and reachability information was comunicated through redundant information
> on the routing protocol. A similar mechanism  could be used to inform a
> host
> about which of their own addresses are reachable from the outside.
> 
It did.  Design intent was to use Routing and Host Renumbering mechanisms
to allow the Host initiating a communication to select a reachable Source
Address.  The selection of a reachable Destination Address was left to
the normal mechanisms (assuming a DNS lookup, return of multiple AAAA / A6
records, and retry with another address on lack of response).

The proposal assumed strict hierarchical addressing;  I recall that at about
the same time we were informed that we should consider Provider Addressing
to be dead within the Service Provider community.  So, while this proposal
and others have the potential to address multi-homed enterprises, they do
not help the problem of route proliferation in a highly meshed internet.

Regards,

     Nigel