> From: Geoff Huston <gih(_at_)telstra(_dot_)net>
>> [NAT's] shouldn't have any effect on the *number* of [address]
>> blocks (i.e. things which can potentially produce global routing table
>> entries).
>> ... 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.
Sorry, I didn't follow what you meant by that. Let me press on...
> 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.
I understand that there are pressures to do multihoming, but I just don't see
how NAT (i.e. address sharing) is having much effect one way or the other on
the intensity of the pressure to do multi-homing.
I'm not trying to be argumentative or rhetorical here, but I've carefully read
your whole message, and I genuinely don't see anything that I can latch onto
as a mechanism for what you reckon is going on, and I'd like to figure it all
out.
You said "some [addresses] are used as the front address for an arbitrarily
large number of concealed end device[s]" - but how/why would the pressures you
mention be any less if each host had its own permanent address?
Are you saying that since the NAT box is necessarily a choke point (since we
don't yet have, AKAIK, distributed NAT, where the translations are maintained
in parallel in a number of different devices), there's more pressure to
multi-home it to increase its reliability?
If so (and my apologies if I'm making an incorrect guess), I think it's an
incorrect analysis of the situation to say that the pressure to multi-home
(and this, the impact on the routing) exists because it's a NAT box. To see
this, consider the case where the site has all the addresses it needs, and
there's no NAT at all. There are two alternative sub-cases.
First, the site has one exit router - but I would imagine that in this case
people want it multi-homed for reliability, just as they would with the
single NAT box. How does this have any consequences for the routing which is
different from the NAT case? The only difference is the "size" of the route -
it'll be a /16 (to pick a random size), instead of the /22 (or whatever) with
the NAT box.
Second, let's assume instead that there are multiple exit routers. Again,
each has to advertise those internal addresses - so again, we've still got a
route being propogated over a large scope - only, just like the previous
case, it's a /16 (say) instead of a /22 (say).
> Unless of course you have evidence to present to suggest the contrarfy
> is taking place?
No, I gather a fair amount of multihoming is taking place, and of course that
is causing the number of routes to grow, but I don't see how NAT i) has
anything to do with the amount of multi-homing going on, or ii) how the NAT
multi-homed case is any different, *in terms of the impact on the routing*
(other than the *size* of the route), from the non-NAT multi-homed case.
>> 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.
Of course - but the point is, for the people who are using NAT boxes because
they can't get enough addresses (which, I gather from this thread, is a large
share of the people using NAT), *iff* the provider could give them whatever
size address block the customer needed/wanted, there'd be no incentive for
them to deploy a NAT box (with all its hassles/problems, etc), no?
I'm not blaming the providers, but it's a fact of life, is it not, that they
can't give every customer all the addresses those customers want?
> 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.
Of course - that's because there are more hosts behind a small prefix that is
NAT'ed than behind a small prefix that's not NAT'ed.
But you seem to be assuming that because the NAT'ed entries are small, they
"should" act like other small entries - *and that it's NAT's fault if they
don't*. Neither one of these are accurate.
It is certainly the case that in a network with NAT boxes, for that subset of
routes which refer to destinations behind a NAT box, those prefixes will be
smaller *than they would be without NAT boxes*. However, I see no reason to
think that without NAT there would be any *fewer* routes - and as you know,
it's the total number of routing entries which is an issue, not the size of
each one.
To put it another way, let's imagine an alternate reality in which IPv4 had
48-bit addresses - enough so pretty much everyone could get as many as they
wanted, and nobody used NAT boxes because they couldn't get enough addresses.
Now, think about what the routing table would look like in that alternative
reality. I expect it would have pretty much the same number of entries as we
do now - but on average, each entry would be "bigger".
In other words, the routing system may be running into problems, but those
problems have basically nothing to do with the address space shortage, and the
measures taken to deal with it (i.e. NAT). (I'll leave unstated the obvious
corollary - I'm sure Perry will figure it out! :-)
>> 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
Yes, but I believe that assertion may well be based on a faulty premise (i.e.
the discussion immediately above).
> in reading your note I really don't see anything that would disabuse
> such a belief.
Ditto! :-)
Noel