At 12/16/00 10:02 PM -0500, J. Noel Chiappa wrote:
> From: Geoff Huston <gih(_at_)telstra(_dot_)net>
> 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.