Subject: NATs *ARE* evil!

From: [email-masked] (Sean Doran)
Date: Thu, 14 Dec 2000 07:55:48 +0100 (CET)

Hi -

I should have waited until Perry had spoken, because now that he has
pointed out the extreme cost of NAT, I have seen the light!

NATs are expensive.  They have gross side-effects.  Even Noel Chiappa,
my guru, says that they are an architectural hack.

So, why are people deploying them?

They are so awful, that it must only happen when people have NO OTHER OPTION.

So, I have to wonder, why is it that they have no option?
Isn't it the job of the Internet Architecture Board to be addressing 
this serious problem, since the IETF's solution doesn't seem to be working???

	Sean.

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 14 Dec 2000 13:46:51 +0000

Sean,

there were several interesting talks in the ietf plenary last night and 
i'd also like to respond

1/ randy's "woah, the DNS is bust" talk
	solution - put your named boot file on your web server and set
up robots.txt right

get the 15 or so most popular search engines to start pulling it

add an option to name resolution libraries to use http and
google/altavista/bla blah to lookup name/address bindings

(i.e. replace lookup with search and update with web crawl - you can
also make your dns update hapen faster by articficially hyping the
searches - yo ucan even include advertisements in the responses)

positive points
i) there are too many levels in the DNS server hierartchy - the name
hierarchy is important, but there is no reaso nto have multiple levels
in the server hierarchy - once upoj a time it was needed for some
scaling (localisation) of traffic - dns traffic is irrelvant compared with
web, so there's no problem doing it with 2 levels local/global - also,
the caching isnt working (as per randy and christian huitema's work)
anyhow so the localisdtion effects  merely add latency to lookups i
nthe current system

ii) there's lots of differt code for differ nt search enginees
this means we have a decent gene pool size compared with the DNS
server space where there's a good chance that like BGP, we are dead in
the water come the first new disease that we have no immunity too...

2/ NATs - 
i thought the comment was that there are too may ways of architecting NATs
which made it expensivce to buy one coz most the NAT box builders are
busy implementing all the varireities which makes them complex instead
of simple - two solutions
i) no ietf standards effort should continue after we have 3 approaches
to a problem - given NAT, IP tunnels and mpls have about 7, 14 and 143
different approaches, this is evidentially a good heuristic for
pruning pointless ietf wgs - of course those mpls watchers amongst us
may have noticed that this is happening there....
(note this doesn't invalidate my approach to fixing name serving about
since that is a single architecture buyt with lots of differnt
detaield implemtnation approaches)

3/ internationalisation - 
its clear that we are making great progress - the gentleman from the
ITU made it clear  in his speaking that are much better at
understanding christian huitema which is a great breakthrough...

4/ those of you who saw geoff huston's excellent 
"the bgp is hosed" talk at the routing area meeting, and its excerpted
comments in the plenary should be very afraid - i did a search on a
citation database on routing research - not to see what work has been
done recently on ways to solve inter-domain scaling, convergence and
correctness problems (though craig labovitz work is distinguised there
by both its quality, and its loneliness!), but also to see if there
was any indication that there was research in universities and
research labs that  was runnign at a level that might indicate clueful
people coming out of their grad schools ready to solve our problems -
there isnt. the research funding agents should be blamed for this:-)
(note that i am not talking about graph theoertizcians - more the
mit/berkeley/usc type research work that is done in a real world
context)

note that a major problem with the little wortk that is done is that
its not often done in realistic topologies - this is a problem with
ISPs who wont let people get at the data (or the traffic traces) so
with a few honourable exceptions, most the smart people trying to do
new stuff go on to other areas where there aren;t intractable barriers
to doig the experimental verficaition of the idea (e.g. transport:-)

 cheers

   jon

p.s. pierro de la francesca or vermeer make better gurus, but if you
want to read about routing and addressing and what we ccould have done
for ipng, i like paul francis' phd work:
(linked from
http://www.cs.ucl.ac.uk/staff/jon/paststudents.html
so you can see my bias:-)
it elegantly included some ideas from nimrod, but had some pragmatic
implementation decisions whioch made it fast and simple and flexible -
it emerged as pip, but was about 95% pruned out in the final v6
decisions...

---

From: "Michael W. Condry" <[email-masked]>
Date: Thu, 14 Dec 2000 08:27:07 -0800

You do not consider IPv6 an option?

>this serious problem, since the IETF's solution doesn't seem to be working???

Michael W. Condry
Director, Internet Strategy
2111 N.E. 25th Ave.
JF3-206
Hillsboro, OR 97124-5961

Phone: (503) 264-9019
FAX: (503) 264-3483
Email: [email-masked]

---

From: Dennis Glatting <[email-masked]>
Date: Thu, 14 Dec 2000 08:30:15 -0800 (PST)

> So, why are people deploying them?

Just to name two...

1) With NAT I ask for much smaller address spaces. Consequently, I don't
have to disclose my network details, deployment is less likely to be
delayed, and both my non-recurring and recurring cost is lower.

2) I don't have to renumber my entire enterprise should I change service
providers, rather only the Internet interface devices. True IPv6 *may*
change this if it is ever routed across the Internet, all of my vendors
incorporate IPv6 into their products, and everyone on the Internet changes
their equipment, too (sans IPv4/IPv6 gateways).

---

From: [email-masked]
Date: Thu, 14 Dec 2000 14:19:22 -0500

> They are so awful, that it must only happen when people have NO OTHER OPTION.

A quick analysis of most of the evils of the last 2 millenia or so would
reveal that most were perpetrated for one of several reasons:

1) "God told me to do it".  This includes evil by reason of mental defect.
Examples: too numerous to mention...

2) "I didn't know better".  Examples: Deforestation by the locals.

3) "I was just following orders". (only for orders from non-deities - see 1)
Examples: Anything you've had to install because a VP saw an 8x11 glossy.

4) "It seemed like a good idea at the time". Examples: Deforestation by
large corporations, anything you asked the VP for money for, but wasn't worth
it but now it's an albatross you can't kill....

I haven't decided which of the four NAT should be blamed on. Probably all.
-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

---

From: "Scott Brim" <[email-masked]>
Date: Thu, 14 Dec 2000 11:41:43 -0800

I see we're about to embark on the 7th iteration of the NAT mail wars.
I don't believe anything new is going to come out of it.  Last night's
arguments at the microphones were quoted from previous mail.  Could you
take it somewhere else?  Is there an alt.nat group?

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 14 Dec 2000 19:45:12 +0000

i can just see it when the aliens land and  ask how to connect to our
infrastructure, we'll have to say

oh we used to have an internet, but it 
lost something in the translation

j.

---

From: [email-masked]
Date: Fri, 15 Dec 2000 06:03:51 +0900

>You do not consider IPv6 an option?

	ipv6 is working just fine even here at IETF49 venue, it's so much more
	convenient than IPv4, for couple of reasons.
	- DHCPv4 lease time is set to 10 minutes, and we keep changing IPv4
	  address.  if I suspend my laptop, go to bathroom and resume, i'll
	  have to reconnect all of IPv4 TCP sessions I had.
	  we do not have the problem with IPv6.
	- we have no problem reaching IPv4 world with IPv6, we have IPv6-to-
	  IPv4 translator here (http://www.kame.net/ietf49/).

	so, migrate to IPv6.  you will be happier.

itojun

---

From: Keith Moore <[email-masked]>
Date: Thu, 14 Dec 2000 18:22:09 -0500

> I don't believe anything new is going to come out of it.

I wish I were so optimistic to think that nothing new would come
of NATs...unfortunately, the NAT group keeps inventing more cruft.

Keith

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 15 Dec 0 11:20:19 JST

Itojun;

> 	convenient than IPv4, for couple of reasons.

We can't use IPv6 until multihoming issues are properly solved
and global routing table size and the number of ASes are
controlled to be below reasonable upper bound.

IETF is intensively working on the issue that a new WG (multi6) will
be created to draft a framwork document.

So, you can expect lengthy framework document effectively stating nothing
more than that the issue is hard, within a year or two.

Well, I have a solution. But, last time I tried this kind of thing
(proposed that subscribers be assigned /48 IPv6 address ranges or
renumbering and other things are too hard just before IPv6 went to
PS), it was rejected with a reason that it is too late.

As you can see, 5 years are wasted until IAB and IESG make the same
statement that assignments should be /48.

							Masataka Ohta

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Fri, 15 Dec 2000 04:41:17 +0100 (CET)

> controlled to be below reasonable upper bound.

If I am reading this right you want a upper bound for routing table size?
Well,considering the problems some operators have to aggreagate maybe that
would be a good idea...:) 

- kurtis -

---

From: M Dev <[email-masked]>
Date: Fri, 15 Dec 2000 10:09:35 +0530

hi all,

i'm late in giving my contribution to this subject, as i'm on the other side of
world...
regarding NAT, its not horrible at all. as u all must be knowing its the solution
that was provided to the problem of reducing IPv4 addresses. Yes, there is a
shortage of  ipv4 addresses. Initially they were allocated to big organisations
without thinking anything, now they are crying that 'sorry boss! its all over'.
In this condition, NAT comes to rescue. You might have had bad experiences, but i
think it depends on implementation. As there is no fixed standard, so it depends
on the implementation.

happy natting...
M. Dev

--
Munish Dev
Nortel Networks

---

From: Keith Moore <[email-masked]>
Date: Fri, 15 Dec 2000 04:05:01 -0500

the problems with NAT are not generally due to implementation.
they are inherent in the very idea of NAT, which destroys the
global Internet address space.

Keith

---

From: Matt Holdrege <[email-masked]>
Date: Fri, 15 Dec 2000 10:19:16 -0800

Folks should read and *refer* to the NAT WG documents before commenting. An 
awful lot of work was put into the content and wording of these documents.

RFC 2663
draft-ietf-nat-protocol-complications-06.txt
&
RFC 2993

---

From: [email-masked]
Date: Thu, 14 Dec 2000 12:34:24 -0500

>>>>> "Jon" == Jon Crowcroft <[email-masked]> writes:
    Jon> note that a major problem with the little wortk that is done is that
    Jon> its not often done in realistic topologies - this is a problem with
    Jon> ISPs who wont let people get at the data (or the traffic traces) so
    Jon> with a few honourable exceptions, most the smart people trying to do
    Jon> new stuff go on to other areas where there aren;t intractable
    Jon> barriers to doig the experimental verficaition of the idea
  
  This is even a problem for most non-major vendors.
  Both at the BGP layer and at the forwarding layer. 

  I've even heard that some people at major's can't get at that info
because of inter-divisional politics. 

  CAIDA has produced lots of interesting data though. The problem for
vendors is finding enough to time to read it.
  If someone knows of a grad school that has money to do BGP research :-)

] Train travel features AC outlets with no take-off restrictions|gigabit is no[
]   Michael Richardson, Solidum Systems   Oh where, oh where has|problem  with[
]     [email-masked]   www.solidum.com   the little fishy gone?|PAX.port 1100[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [

---

From: Michael Richardson <[email-masked]>
Date: Thu, 14 Dec 2000 12:19:03 -0500

>>>>> "Sean" == Sean Doran <[email-masked]> writes:
    Sean> I should have waited until Perry had spoken, because now that he
    Sean> has pointed out the extreme cost of NAT, I have seen the light!

    Sean> NATs are expensive.  They have gross side-effects.  Even Noel
    Sean> Chiappa, my guru, says that they are an architectural hack.

    Sean> So, why are people deploying them?

    Sean> They are so awful, that it must only happen when people have NO
    Sean> OTHER OPTION.

  Let's seperate things as public networks vs private networks. 

"Public networks"
  IP addresses cost money and the people deploying NATs in places like
hotels are not smart enough to buy a pool of IP addresses and use host
routing. 

  For private network (e.g. corporate networks) there are other reasons.
But, availability of IP addresses is a major one.   

  My suggestion is that all NAT products should provide IPv6 with 6to4
support. Instead of doing ESPUDP to get IPsec around NATs, we should do 
put ESP over IPv6. This requires the same amount of effort (new clients, new
servers), but leverages IPv6 into the equation. 6to4 is very cool.

---

From: "Perry E. Metzger" <[email-masked]>
Date: 16 Dec 2000 20:44:13 -0500

> So, I have to wonder, why is it that they have no option?

Maybe because I hear from folks like you and others that you're
ideologically opposed to deploying v6 instead of against it for
technical reasons?

-- 
Perry E. Metzger		[email-masked]
--
"Ask not what your country can force other people to do for you..."

---

From: Fred Baker <[email-masked]>
Date: Thu, 21 Dec 2000 16:07:24 -0800

At 02:19 PM 12/14/00 -0500, [email-masked] wrote:
>I haven't decided which of the four NAT should be blamed on.

let's be fair. There was an excellent reason for NAT at the time. Postel 
suggested that private address spaces could be used rather than assigning 
precious IP Address space to networks that had no intention of attaching to 
the network, and NATs wound up being a way to couple that with topological 
address space management to try it out. We knew it was a short term hack at 
the time, and many of us still think that.

As Yakov is prone to point out, in a perfect world wherein all applications 
are client/server and address space is uniformly available, there are 
enough addresses around so that NATs are all we need. There are a few problems:

         - the world is not perfect
         - all applications are not client/server
         - address space is not uniformly available

Hence, NATs don't solve every problem.

The reference to IPv6 is interesting. Up until a year ago, I didn't 
particular push IPv6 as a solution. Reason: it wasn't in anybody's 
operational game plan. IPv6 had a serious chicken/egg problem - numerous 
people wanted to be the second to deploy it, but nobody wanted to be first, 
and vendors generally didn't see the point in implementing it apart from 
somebody waving cash to buy it. As a proposal, it solved some interesting 
things, like more bits in the address, better autoconfiguration, more 
scalable mobility, more efficient VJ Header Compression, re-introduces the 
end to end model so we can support non-client/server applications well, and 
so on. However, being "good" isn't enough unless is it "good enough to 
deploy" - good enough to replace the old stuff, or good. When 3G put the 
proposal on the table, it became viable. At the moment, globally, we have 
perhaps half a dozen to a dozen commercial networks running IPv6 and 
upwards of 50 research networks. That's an insignificant dent in the great 
wide Internet, but it is not "nothing" either. We have some pretty large 
countries that have stated an intention to move in that direction. Now that 
folks have the opportunity to be second - someone else has gone first - 
anyone who is having trouble getting addresses from a registry is thinking 
seriously about IPv6.

In short, things had to get worse before they could get better.

We'll see where things go, but whatever my opinions on IPv6 are (and I am 
on record as saying it isn't all we might have liked it to be, my voice 
being one among many), I am not at all convinced that it is a washout.