Subject: Re: multihoming (was Re: draft-ietf-nat-protocol-complications-02.txt)

From: Sean Doran <[email-masked]>
Date: Wed, 26 Apr 2000 18:21:47 +0200 (CEST)

Thomas Narten writes:

| The point of the IPv6 addressing architecture is to make that
| sort of multihoming a _possibility_ and an _optimization_ rather
| than a _requirement_.

In a purely technical sense, redundancy of any sort is
an _optimization_ rather than a _requirement_.   There
is absolutely nothing in IPv4 that _requires_ any entity to
be multiply homed or multiply connected at all.

It seems out of touch with reality to rest on the argument that
multihoming by entities too small to qualify for a (scarce) TLA
needn't be considered from first principles because such a multihoming
is an _optimization_ and isn't really required.

| In contrast, today's
| IPv4 has lots of long prefixes in the DFZ with no clear way of placing
| an upper bound on the number of prefixes that must be maintained in
| the DFZ to provide reachability to all sites. In IPv6, the small
| number (8K's worth) of TLAs should do the trick.

This sounds like virtue without sacrifice - ecologically
correct routing at zero cost, except to "polluters" who
are in it only for themselves, out to _optimize_ their
perfectly sound single connectivity.

Great!  In this polluter-pays world, if you have a TLA assignment
and you change your topology so that your TLA prefix is announced
to my network from two directions instead of one, you are able to
influence my routing decision in how traffic I generate will return
to you.

If you do not have a TLA assignment and you change
your topology, I cannot see that, because I implement
the standardized /19 (oops, TLA) filter.  Unless you pay me.

Cool.  

Obviously, I cannot be too critical of this approach,
because it is precisely what I tried (and failed) to
do with the /19 (and earlier /18) filters in Sprintlink.

The horrendous failure of those filters was the inability
on my part to add economics to the mix, and to allow
organizations to offer some consideration in exchange for
a relaxing of the filtering policy.

This failure turns out not to be simply local -- there is no
reasonable scheme available to settle with one, two or three
filtering networks, let alone tens or hundreds or thousands.  So
when someone has a reason to want to pay for an _optimization_,
there is no practical means to do so, and therefore, technical
reasons for not imposing them as well as merely really bad P.R.  ones.

In the absence of a market, it is very hard to argue that
"the market" will sort things out.   Engineers shouldn't
resort to belief in the divine Invisible Hand when the
mechanisms and rules of a market do not exist yet.

There was also a backing-away from the original filtering policy.
The step back from /18 to /19 happened because the place where
economics was working best -- the RIPE registry -- was allocating
nothing smaller than /19s.   /19s were chosen because they
best fit the size of an initially-multihoming entity, and
/18s seemed to be much too big an allocation.   The initial
allocation of a /19 was based on a simple market principle:
if you were willing to pay $x to the registry, you get a /19.
Come back when you want more, we'll talk about it.

As the registries converged on the model of charging for
registering standard-or-shorter prefixes, the /19 filters
merely became a self-defensive measure to avoid hearing
accidentally-announced long prefixes.

The TLAs are much too big for most initially-multihoming
entities, and thus the TLAs themselves are essentially 
irrelevant and ultimately meaningless, in the same way
that the /18s were.    Today's TLAs are tomorrow's /8s,
as observed by Bill Manning.

| As others have pointed out, IPv6 is also developing a multiple
| addresses per end-node approach to multihoming.

This is pushing the NAT function of multihoming-using-NATs-and-PA-space
into the end hosts.  The problem is that each time a new TLA is
connected-to, a multihomed entity that does not qualify for a 
large enough allocation will have to convince all the devices
covered by the original address space to now adopt a 2nd, 3rd or
nth address.  In a sizable NLA, where the devices are not all
under the control of the NLA's administrators, this seems pretty
challenging.   (It's really cool for a sizable dialup provider!)

Worse, the NLA's administrators are STILL bereft of a way to 
influence the routing decision made by a distant TLA towards 
the multiply-addressed end hosts.   That is, if I want traffic
from AboveNet's TLA to come in via Sprintlink and traffic
from Exodus's TLA to come in via GTEI, how do I get the multiply-
addressed hosts that I do not control, and the various TLAs
and NLAs, to cooperate in that?  (For example, how could I get
a host owned by some customer's dialup customer to use an address
with Sprintlink's TLA when talking to www.above.net, and
to use an address with GTEI's TLA when talking to www.exodus.net?)

Section 5 of draft-ietf-ipngwg-default-addr-select-00.txt doesn't
have very much meat on this topic...

| >     IPv6 does not solve the multihoming problem.  Instead, it tries
| >     to minimize the damage by:
| >     
| >     1. discouraging the use of multihoming, primarily may making
| >     multihomed customers pay more for it.
| >     2. forcing paths to multihomed sites to be less efficient (at
| >     least for all but one of the ISP connection points) and or,
| >     3. limiting the regions of the internet for which multihoming
| >     is effective for a given customer.
|
| > Is this an accurate representation?
|
| Absolutely not, as I hope has now been made clear.

Actually, as I read your answer, the "not" must be a typo.

	Sean.