Re: [nat66] Necessity for NAT remains in IPv6

[Brian E Carpenter <[e-mail]>]

Sigh, I've been keeping my fingers off the keyboard, but a few
points in this thread really need clarification. Apologies
for prolonging the off-topic thread, I will shut up after this.

On 2009-11-03 08:15, Chris Engel wrote:
...
> First, by way of introduction...I'm a Network Manager in
> charge of operations at a small ASP. 

Hi. I used to be in charge of network operations at a large
site (cern.ch), then I spent 10 years in industry, and
now I'm an academic but working with our university's
IT operations people on IPv6 deployment. I was also the
instigator of and a contributor to RFC4864. So...

...
> I do NOT feel that RFC 4864 adequately addresses the utility
> of NAT.... nor adequately provides a acceptable substitutes
> for it.

We worked as hard as we could to make the list complete.Can you
identify exactly which benefits of NAT are not mentioned in
section 2 of the document?

...
> 
> In section 2.2.  of RFC 4864 "Simple Security Due to Tasteful
> Filter Implementation" the authors contend that NAT's utility
> for Security is not particularly compelling because it
> incomplete and can be bypassed through techniques such as
> Trojans.... and that filtering via a FW offers a more robust
> solution. Respectfully, it's difficult for me to fathom that
> anyone well versed in security would find these arguments
> compelling.

Well, how about any large site manager who runs a firewall
but no NAT? This is a very common scenario, although I agree
that many sites run boxes that are simultaneously NATs
and firewalls.

On 2009-11-04 15:14, Roger Marquis wrote:
...
> Given that somewhere over 90% of devices connected to the IPv4 Internet are
> NAT'd, allegations of "NAT harm" would seem to be like those funded by
> insurance interest against single payer i.e., without basis but repeated
> often in the hope that someone will believe them. 

The problem here is that NATs (especially the $99 kind
misleadingly described as ADSL routers) lose session state
and abort user sessions when they run out of resource. Then
the user sees a glitch or a timeout, or occasionally an
aborted credit card or banking transaction. But there is no
logging and no diagnosis. So we simply have no data about
how many hours of user time and help desk time are wasted
on NAT-induced glitches. If every domestic user ran Wireshark
continuously, and every glitch was carefully analysed, we'd
have data. But that isn't going to happen.

That's not to mention the performance and complexity cost
for applications that have to work around NATs, which
is a constant tax on everybody.

So we know that there is a large dollar cost here, but
we have no reasonable way to measure it. As far as the
IT managers and ISPs who choose to put users behind
NATs are concerned, it's an externality that they have
no interest in pricing. The problem with NATs is basically
one of economics: the incentives to NAT act on one group
(IT managers) and the costs of NAT lie on another group (users).

On 2009-11-04 15:19, Roger Marquis wrote:
> Mark Andrews wrote:
>> NAT44 was a necessary evil as we had effectively run out IPv4 addresses.
> 
> This is false.  NAT was implemented long, long before there were widespread
> concerns regarding the number of addresses.  

Absolutely not. The concern about the number of address dates
back to about 1991, and was formally documented in November 1992
(RFC1380, section 2.1.3):

   There is considerable uncertainty regarding the timeframe
   when we might exceed the limits of the IP address space.
   However, the issue is serious enough that it deserves our
   earliest attention.  It is very important that we develop
   solutions to this potential problem well before we are in
   danger of actually running out of addresses.

IPv6 is the result of that paragraph.

But NAT (at least for IP) was first documented in 1994
(RFC1631).

> A larger reason for NAT was
> that many of us were using non-routable addresses, 

You were only using them because they were defined in 1994
(RFC1597), 2 months before NAT.

> as there was (and still
> is) no business case for any of our internal addresses to be publically
> routable.

Actually that is a side issue. I agree that it's a very
reasonable business argument. But whether you use ambiguous
(RFC1597/RFC1918) addresses, IPv6 ULAs, or globally unique
addresses is completely orthogonal to whether they are routed
on the public Internet. There are many cases of organisations
with globally unique addresses used internally that are not
routed externally. (The same goes for DNS names, although there
is quite a bit of allergy in the IETF to two-faced DNS.)

   Brian