Operational challenges of no NAT

[Ted Mittelstaedt]

On 10/29/2010 10:54 AM, David Conrad wrote:
> On Oct 28, 2010, at 8:45 PM, Ted Mittelstaedt wrote:
>>> Is there some documented list of the usual requirements that NAT
>>> is used to satisfy and the corresponding IPv6 method to satisfy
>>> that requirement?
>>>
>>> Lots of IT managers really like NAT for managing the interface
>>> between their network and the big bad world outside.
>>
>> I don't know about you but to me the phrase "really like" is an
>> emotional, not logical, description.
>
> To me and in this context, it is a shorthand folks use that describes
> the shortest path to get v6 deployed.
>
>> But with IPv6 that paradigm [NAT] is no longer needed and we must
>> shed it.
>
> As has been documented several places, NAT provides functionality
> (e.g., increased provider independence, reduced administrative
> overhead/cost, topology hiding, etc.) that many folks find useful.

All of that is not dependent on NAT and can be supplied by correct
IPv6 deployment and a properly designed firewall.  You see this is
exactly what I'm talking about.  You believe those things are tied to
NAT because NAT is all you know because that's what you have been
raised with.  But if you do the research you will
see that these things are independent of NAT.  Others do all these
things without NAT.  They did these things before NAT with IPv4.

> Until that functionality can be replicated (or folks feel the costs
> of loss of that functionality is overridden by the benefits), people
> are going to continue to want NAT.
>

Since it isn't functionality dependent on NAT this statement is
utterly illogical.  NAT replicated this functionality from what
people were doing before, not the other way around.

This statement is kind of like the kid raised in the plastic bubble that 
someone painted the inside of the top of the bubble blue - and he won't 
come out of the bubble and see the real sky until the real sky
replicates the blue color.

>> This is all about paradigm shifts.  If you have never heard that
>> term used then look it up, your going to be dealing with a lot of
>> them with IPv6.  I daresay that if a network manager cannot deal
>> with these then he shouldn't be working in the high technology
>> field at all in the first place, because high tech is full of
>> them.
>
> It's this sort of condescension that results in less than useful
> discussions.
>

So in other words just because you cannot understand it your going to
label it "condescension" so you can feel all superior and ignore it? 
That's a real grown up attitude.  Just how old are you, boy?  I wasn't 
being condescending before but I am now because you obviously never in 
your life ran into real condescension.  I'm frankly amazed you can spell 
the word.  Sorry that shaking your reality is so tough on you, boy.

> Most folks

Oh, you know what "most folks" want?  Do tell!

See, THAT is being condescending.

> simply aren't interested in "paradigm shifts" in utility
> infrastructure. The Internet is a tool like telephones and
> electricity. Most businesses and IT shops are quite conservative.
> They will actively resist 'innovation' that breaks the processes and
> systems their business relies on, even if those processes and systems
> are sub-optimal from one perspective or another. NAT is something
> that folks use, are comfortable with, and largely understand the
> operational implications of (at least as they apply to themselves).
> It demonstrably works so why should they break it?
>

"they" aren't breaking it.  NAT today exists because of two reasons:

1) A tremendous amount of programming hours have gone into making it 
work.  A modern NAT engine has tons of special routines in it to handle 
all sorts of different types of applications.

2) Since there is a "de-facto" IPv4 NAT standard, all of the network
software vendors who write network applications test with the major
NAT implementations out there.  And there are a lot fewer NAT engines
in use than you think - most small routers are Linux based and use
the same NAT engine.  And the Linux engine was ripped off of BSD
so those are the same, also.

With IPv4 NAT, we could get all of the network admins to agree on IPv4 
NAT because you cannot argue with a shortage of IP numbers.  That is
why IPv4 NAT became a de-facto standard in the first place.  Everyone
has to use it.

But there is no shortage of numbers under IPv6 and so we will never see
the kind of agreement among network admins over the necessity of IPv6
NAT.  For every admin out there like you who is willing to lay down cash 
for an IPv6 NAT solution, there will be one who isn't willing
to do that.  And there is no real interest in the Open Source community
on standardizing on an IPv6 NAT implementation.  Sure, people will
continue to write them as add-ons, but there isn't likely to be 
agreement on a single implementation to stick into BusyBox Linux anytime 
soon.

As a result IPv6 NAT deployment will be very spotty with a lot of
competing implementations.  And a lot of network admins simply won't
use it at all, since they won't need to since they can get everything
from IPv6 that your attributing to NAT.

So, network application vendors will see the IPv6-NAT users like 
yourself as niche users and won't bother testing their stuff with most
implementations.  They probably will test with Cisco's - assuming
Cisco even writes one - just so when people like you call up and
complain that their app breaks with your $49.95 Linksys Linux-based
IPv6 NAT box, they can tell you that they tested with the $5,000.00
Cisco firewall and it works fine with that - so if you want IPv6
NAT then buy one of those Cisco ones.

> The original poster described operational challenges of running a
> network without NAT. If you believe those operational challenges can
> be/are addressed in IPv6, describing how this is so would be useful.

Well, as the first respondent said, those challenges are artificially
manufactured by the decision of the one party to have an access list 
that is overly granular.

Even the OP pointed out that using NAT he can put 2000 hosts behind
a single IPv4 number so the notion that restricting the access list
to a single IP number just to reduce the number of hosts that can
hit their system is sheer lunacy.

So for the OP the obvious solution is to wait until his vendor replaces
the oatmeal in their head with some brains.  He even said something like 
that, although without the oatmeal.  Same sentiments, though.

In fact, read between the lines, the OP wasn't really even looking for a 
PERMANENT hack.  He wanted a TEMPORARY hack he could use until his 
vendor wised up.  And there were several temporary hacks posted in 
response that fit the bill fine.

> Sticking your fingers in your ears and saying "La la la IPv6 means
> you don't need NAT" isn't helping anyone.
>

The information is out there, just dig it up.  Or, don't.  I'm only 
telling you what is going to end up happening, it's your choice what
to do.

Until there is a IPv6 NAT that everyone agrees is the defacto IPv6
NAT, just like everyone agrees that the gold standard for IPv4 NAT
is the BusyBox Linux based Linksys/Cisco WRT54G, this is really
kind of an academic discussion.  The de-facto deployment in IPv6
today is NATless.  Sticking your fingers in your ears and refusing
to deploy IPv6 until that gold standard comes around - if it ever
does, which is unlikely because there's no real need for it - isn't
going to help you or anyone.

Ted

> Regards, -drc
>
>
>