Re: Multihoming by IP Layer Address Rewriting (MILAR)

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

On Tue, 4 Sep 2001, Eric Gauthier wrote:

> I might be a bit confused here, but it seems that people are talking
> about two different things.

Just two? We're making progress.  :-)

> (ie - please connect to IP x.x.x.x on port z).  This seems to be
> the DNS side of things where you are determining what that layer
> 3 address should be.  Second, there is a pure layer 3 issue of how
> do various layer 3 devices build their routing tables.

I think I'm the one who inadvertently opened this can of worms, so let me
explain where it all came from.

My proposal is to let layer 3 rewrite destination addresses in some cases,
so that both higher layers and other layer 3 entities can go about their
business as usual and there is still scalable multihoming.

There is one caveat, though: you need to know what the new destination
address should be. Obviously, this information can't come from the routing
table, since keeping the routing table small is exactly the problem we're
trying to solve. Also, receiving alternate addresses from the remote host
is problematic if all you have is a primary address that is unreachable.

So using the DNS seemed like logical choice. PTR records would get a
neighbor, something like AP (alternative prefix). That way, a host
can find out the way the address should be rewritten without too much
trouble.

Earlier I said the regular way of using multiple AAAA records would
suffice to enable a host to connect to another host when a path is broken,
but this is problematic. A host could do this, since it can decide to
break off TCP session establishment if it's getting nowhere and try to
start one to another address without seeming to break off the session to
the application.

But a router would not be able to do that on behalf of a host without a
full NAT implementation, and I think we should avoid introducing that much
state in routers. Finding a AP record and rewriting the destination
addresses for all packets to the original address (prefix) is much
cleaner.

> If I've got this right, it seems like this is more of a debate on what
> direction we should take rather than about a specific technology.  Should
> we focus on the translations like, for example, the way Mail service was
> implemented by using multiple MX records to handle failover of a service
> to a different IP.  Or, should we handle this solely within layer 3
> like, for example, how site multihoming is done using BGP?

Any consensus on BGP changes is a long way off (or has been carefully
hidden) so I guess we have to solve the problem, or at least lessen the
impact, elsewhere. There are basically three choices:

- application
- transport
- IP

Changing applications is next to impossible: there are too many of them.
(Unfortunately, the socket API doesn't hide the layer 3 addresses so
applications need to be changed for IPv6 as well. We can all see how fast
this is happening.)

Changing transport protocols is hard: there are many of them and changing
them imposes changes on the applications as well and repeating the same
steps for each session is somewhat wasteful of resources. And not all
transport protocol lend themselves equally well for this.

Changing IP processing seems doable, at least compared to the
alternatives.

So: what do we change in IP? There are several drafts and not-so-drafty
proposals. They all have stronger and weaker points, and most of them seem
to gravitate towards some kind of address rewriting scheme.

Maybe we should come up with some more specific requirements for multiple
addresses / address rewriting solutions. Or we can just wait and see who
is the first to produce code.  :-)

Iljitsch van Beijnum