[arin-ppml] Just a reminder of some quick mathematicsfor IPv4that shows the long term impossibility of it

[Larry Ash]

Hi Chris,
I resisted for so long but I have to reply--

  Chris Engel <cengel at conxeo.com> wrote:
> Mark,
> 
>> NAT isn't up to a matter of opinion. It is a matter of what the
>> Internet's design architecture is, and whether NAT can fit within that
>> architecture. NAT breaks end-to-end reachability and transparency
>> between the edges of the Internet, which is why it doesn't fit the
>> Internet's design architecture.
>> 
> 
> The same can be said of firewalls and spam filters and proxy servers. 
>Guess what, VERY few people actually want "end-to-end reachability and 
>transparency". The survey is out, privacy wins overwhelmingly. I don't WANT 
>the inside of my network reachable and transparent to external users. 
>Neither do the vast majority of endpoint network operators or individual 
>users. We want to expose what we CHOOSE to advertise to the outside 
>world....and keep everything else private....and we are willing to accept 
>extra cost and complexity involved in running certain types of applications 
>in order to do that.
> 
> On the Enterprise side of things, of which I am very familiar, most don't 
>tend to WANT decentralized application models (i.e. peer-to-peer). They 
>want to mandate that applications have to go through a central known point 
>in order to be able to function properly. That facilitates better 
>monitoring and application of policy on said applications, as well as 
>easier support, in many cases.
> 

They sure bitch like mad when they have a voice call with one-way audio or
some other service that they want to "just work" that doesn't until someone
manually configures a work-around into their equipment.

> 
>> The Internet is intended to be a dumb packet switching network, not one
>> that has to have an understanding of the applications that are running
>> over it. That's the fundamental difference between the Internet and a
>> traditional application specific network such as the PSTN - if you want
>> to run something other than voice over the PSTN (e.g. fax), you have to
>> make it look like a phone call. If you want to run an application over
>> the Internet (the no-NAT Internet), you don't have to care what it
>> looks like, because the Internet doesn't care what the application is.
>> The moment you add NAT is the moment "the Internet" needs to care about
>> the applications because it now has to translate any addresses carried
>> in them. You then also introduce a performance bottle neck, another
>> point of application failure and a traffic interception point at the
>> "public server" that is acting as a relay between the true end-points.
>> (Imagine a birthday party where nobody can talk directly to each other,
>> instead, all conversations have to go through the person having the
>> birthday ...)
>> 
>> For those in the pro-NAT camp, have a read of the following. Then if
>> you're still advocating NAT, you'll be more aware as to what
>> you're trading off.
>> 
>> RFC1627 - Network 10 Considered Harmful (Some Practices Shouldn't be
>> Codified)
>> http://tools.ietf.org/html/rfc1627
>> 
>> RFC1958 - Architectural Principles of the Internet
>> http://tools.ietf.org/html/rfc1958
>> 
>> RFC2775 - Internet Transparency
>> http://tools.ietf.org/html/rfc2775
>> 
>> RFC2993 - Architectural Implications of NAT
>> http://tools.ietf.org/html/rfc2993
>> 
>> 
> 
> I know EXACTLY what NAT does. It does EXACTLY what I INTEND it to do. 
> That's true for most network admins I'm familiar with as well as with most 
>private individuals. I work and am friends with alot of other folks in 
>various positions in IT. Not a single one of the people I know DOESN'T run 
>RFC-1918 space on their home networks....and address availability has very 
>little to do with that. The internet isn't one completely homogenous 
>entity....it's thousands upon thousands of individual networks.... each of 
>them has their own rules that they play by. If you don't like the rules 
>that an individual network plays by....guess what...don't go 
>there...chances are you aren't welcome.
> 
Unfortunately NAT is a category not an implementation. Most vendors 
implementation
differ in subtle ways. That's the rub. You can make it work the way you want 
but
does that allow my equipment to know what you've done to compensate? When
a user calls and complains all too often my techs have to find out if NAT is 
in
place, what device is in use, and which version of software in order
to suggest configurations that will allow our systems to know to proxy that 
call
without forcing a proxy of everything including interoffice calls. Sometimes 
proxy everything
is the only answer but I sell bandwidth too so I guess that is ok if it's my 
customer?

Can I make NAT work. Sure, if I get to pick the hardware and certain 
configuration
details I can make it work every time (for my equipment). But as you point 
out it
isn't a homogeneous Internet. I just get tired of paying the support cost 
for someone
else  to buy a $40 box and press the NAT button and now it's my problem 
instead if his.
But he sure is secure!!

Should networks use NAT, probably for many (IPV4), but it requires a good 
deal more skill to
debug issues than many small customers have access to. Should every ISP 
install CGN.
That has potential to cause major problems much like an ISP installing one 
firewall and one
set of policies for all customers. For my mind its more a case of: Do you 
want a date with
the prom queen or just a picture of the prom queen. Sometimes a picture is 
all that there
is but if there is any way I'll take the date.

Seems to me that many pro-NAT voices are more interested in how they do 
something than what they
are trying to accomplish. Weird.

> Christopher Engel
> (representing only my own views)
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

Larry Ash
Network Administrator
Mountain West Telephone
123 W 1st St.
Casper, WY 82601
Office 307 233-8387