At 12/16/00 10:02 PM -0500, J. Noel Chiappa wrote:
> > From: Geoff Huston <[EMAIL PROTECTED]>
>
> > There are strong indications that NAT is one factor behind this part of
> > the BGP table.
>
>I'm afraid I'm missing the logic here. As you point out below, NAT's may have
>caused people to use *smaller* blocks of the global address space:
>
> > much of the recent growth in the deployed Internet has happened behind
> > NATs of various forms and the side effect is low levels of overall
> > address space growth as reflected in the span of address space
> > advertised in the BGP tables
>
>but they shouldn't, assuming all else being equal (a possibly bad assumption,
>as I'll note below),
and I believe that this possibly bad assumption is indeed a probably bad
assumption
as I;'ll note below as well.
> have any effect on the *number* of blocks (i.e. things
>which can potentially produce global routing table entries). The blocks are
>just smaller, again as you point out:
>
> > but an increasing finer level of granularity in the routing table.
>
>So the number of distinct "local areas" is still the same, yes? And NAT's
>should, all else being equal, not have a negative effect on the
>aggregatability of those addresses.
well I fail to see that - how does a NAT gateway gain the appearance
of greater resiliency of service supply. With NAT all addresses are not
exactly equal as some are used as the front address for an arbitrarily large
number of concealed end device addresses. The pressures to using multihoming
of a prefix that enconmpasses the NAT gateway does appear to be quite common.
Unless of course you have evidence to present to suggest the
contrarfy is taking place?
>E.g. if provider X has a /12 out of which they have to support N customers,
>without NAT they'd have to give each customer, say, a /18; but with NAT, each
>customer can get a /22.
As far as I have seen things, its the customer who is using NAT, not the
provider. I'd be interested in seeing further details of a provider model
as suggested in the above lines, as its relatively novel to me.
> But there are still the same number of subsidiary
>blocks (i.e. N sub-blocks), and outside X they can, all else being equal,
>still be aggregate into that single /12.
>
>Now, if some subset M of those customers are multi-homed, so you can't
>aggregate into a single /16, that's an issue - but that has nothing to do
>with NAT - it has to do with the multihoming. The effect on the routing table
>is the same, whether those people are behind NAT boxes or not.
I think you may have missed my point that the motive for multihoming
a small prefix is far greater for a NAT network than a small
non-NAT network.
>Am I missing something?
hard to say.
>There are some second-order ways in which NAT boxes might actually help
>aggregation, now that I think about it.
>
>The simplest one is when customers switch providers, and don't want to
>renumber. E.g. company X is a customer of ISP P, and has addresses (either
>from P, or their own). X switches to ISP Q, which wants them to renumber
>so they won't have to be separately advertised. X declines, saying it's
>a hassle.
>
>If, however, a NAT box is installed (assuming X's applications don't run
>afoul of NAT limitations), so that externally X's addresses become part of
>Q's existing block, in this instance deployment of a NAT box will actually
>reduce the routing table by one entry.
I believe ease of renumbering under NAT is well trodden ground.
>I gather this use of NAT boxes (to avoid renumbering) is not unknown, if not
>the most common cause for installing a NAT. Does anyone have any idea how
>often it happens?
>
>Another way in which NAT boxes might reduce the number of routes has to do
>with how many customers a provider can fit into an address block before it
>has to go back to the registry for another discontiguous block.
>
>To use the case about, with ISP X and a /12, if they are giving out a /18 to
>each customer, then they only get to support 64 customers before they have to
>go back for another block. If they are giving each customer a /22, then they
>get 1024 customers to a /12 block.
>
>
>I doubt any of these are major factors when you look at routing table growth,
>though. But I expect that growth is principally due to other factors, and
>NAT doesn't play a big role (either pro or con).
I have said co0nsistently that it is a factor, and in reading your note I
really don't see anything that would disabuse such a belief.
