Subject: Re: NATs *ARE* evil!

From: "J. Noel Chiappa" <[email-masked]>
Date: Sun, 17 Dec 2000 02:28:40 -0500

> From: Geoff Huston <[email-masked]>
 
    >> [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

---

From: Bradley Dunn <[email-masked]>
Date: Sun, 17 Dec 2000 02:39:17 -0800

>corollary - I'm sure Perry will figure it out! :-)

I'm with you in that I do not see a causal relationship between the 
availability and deployment of NATs and the increase in routing table size.

However, I do think that there is a definite causal relationship between 
the address space shortage and the number of prefixes in the routing tables.

People who allocate addresses (registries and ISPs) use slow-start 
algorithms in their allocation policies due to the shortage of addresses. 
Therefore many organizations end up announcing several non-aggregatable 
prefixes which they have acquired over time.

If we did have an address space where "pretty much everyone could get as 
many [addresses] as they wanted," there would be fewer prefixes in the 
routing tables. If everyone could get "enough" addresses the first time, 
we'd be much closer to the ideal of one prefix per AS.

Bradley

---

From: Jon Crowcroft <[email-masked]>
Date: Sun, 17 Dec 2000 16:25:48 +0000

>>the intensity of the pressure to do multi-homing.

NATs allow users to be irresponsible about the addressing since they
dont require you to multihome hosts, but dynamically pick which way to
enter and leave your domain - this means people can be stupid and run
multihomed. for example.

incentives are important wen resources are scarce y'know:-)

anyhow, i think the old 8+8 v6 scheme would have sorted this out just
dandily....and i dont understand the vitriol people our on it -
antyhing else (liek yo usuggest coordinaging the addresses allocated
to NATs on the outside so they aggregate ) is the SAME thing. involves
the same requirements for a protocol to coordinate it....

nats for securtyy thru obscrurity are about as relavent to real
security failures and risk and loss of face and revenue as postits on
your keyboard saying do not touch...the most common failure we get is
via applicatio nlevel messes (e.g. mail attachements) and user
education is the only way to solve those. 

but of course, with pip....

 cheers

   jon