Re: Multihoming by IP Layer Address Rewriting (MILAR)

[Iljitsch van Beijnum <iljitsch@muada.com>]

On Tue, 4 Sep 2001, Ramakrishna Gummadi wrote:

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

That is why I want this information to be in (somewhat) arbitrary places
in the reversed mapping zone, so it is not necessary for each host to have
DNS entries for all addresses.  (Which is very unlikely for hosts
implementing RFC 3041.) I think doing reverse lookups for the /128, /64
and /48 in question should do it.  Requiring someone to run a reverse DNS
with one entry so an entire /48 can be multihomed doesn't seem like a
problematic requirement to me.

On the other hand, ICMP and IP option based solutions could work well too.

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

Generally, the communication over TCP/IP works like this: an application
connects to a remote host, of which it almost always knows the host name
(but sometimes just a (one) IP address). The remote host accepts the
connection, communication happens, the connection is torn down. In this
scenario it would be best if the originating side knows all (or at least:
more than one) of the addresses of the "server" it wants to connect to,
but it is not necessary for this server to know any addresses of the other
side before the connection is established: the fact that a connection
request comes in means that there is enough connectivity to negotiate
additional addresses.

If we want to keep the multihoming in layer 3, it is good to remember that
additional address discovery / address status discovery mechanisms are not
tied to a single session.