Subject: Re: Number of Firewall/NAT Users

From: [email-masked] (Sean Doran)
Date: Mon, 22 Jan 2001 23:53:30 +0100 (CET)

Keith Moore writes:

| at least in those days, gateway proponents didn't insist that people
| shouldn't include email addresses in the bodies of their messages.

You miss the point that including "GRECO::MARYK" as an email address
in a USENET message is about as useful as including 10.0.0.26 in an
IP header -- the local meaning is essentially unusable to a non-local 
recipient.

Nobody really constrains protocols from carrying a local IP address
around any more than anyone constrains from putting local addresses
into a text message.   It's just that communicating by naively replying
to such an embedded address is unlikely to work.

RFC-822 was a great leap forward for embedding a global namespace into
text messages, and I am pleased to say that even my own RFC-822 address
works fine at UKY, despite my NAT stance. :-)

There needs to be an RFC-822 for identifying IP-packet-receivers independtly
from actual network topology analogous to the way that identified mailboxes
independtly from actual network topology (hey, consider that you even
may have had your mail cross different types of small-i internet when
sending mail to places like [email-masked]!).

	Sean.

---

From: Keith Moore <[email-masked]>
Date: Mon, 22 Jan 2001 18:16:25 -0500

> IP header -- the local meaning is essentially unusable to a non-local 

Actually it was sort of useful, if you knew how to translate.
(or could find a local mail expert that did)
  
But you missed the point I was trying to make. in those days, the inability 
of the mail network (or at least parts of it) to support a single global 
address space was correctly recognized as a deficiency in the network - 
and people took action to solve the problem (notably deployng MX records).

Nowadays people often act as if NATs were the way the Internet was supposed 
to work, and that it's the applications and the users of those applications 
who are broken if they want a network that supports a global address space.
Actually it's the other way around, and people are taking action to 
increase the brokenness.

> works fine at UKY, despite my NAT stance. :-)

Yes, and IP was a great leap forward for having a singal global namespace
and a single message format to send over all manner of transmission media.
It worked quite well at this until NATs came along.  

Now you're suggesting that we need yet another layer, presumably something
that runs over NATs.  Given the current state of NAT deployment, it's hard 
to fault that reasoning.  But it really does seem that we've solved that 
problem before, and to solve it again in a less efficient way seems like 
taking one tiny step forward to try to counteract a huge step backward.

Keith

---

From: [email-masked]
Date: Mon, 22 Jan 2001 18:20:19 -0500

> to such an embedded address is unlikely to work.

Actually, NAT *does* constrain protocols from carrying around a local
IP address if it's emitted out into the world.  Remember that if it's
a LOCAL address, it's used *only* behind the NAT, and nobody cares about
that case.

The problem with NAT is the same problem as people who put locally usable
addresses in their .signature files - the NAT *doesnt* fix those up when
it becomes a non-local address BY VIRTUE OF PASSING THROUGH THE NAT.
-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

---

From: Ed Gerck <[email-masked]>
Date: Mon, 22 Jan 2001 23:08:14 -0800

> and people took action to solve the problem (notably deployng MX records).

Which broke DNS.  We can no longer send an email to an IP number, mainly
due to this myopic choice.  This choice also broke layer independency.

So, even though there is no reason why one needs to use DNS in order to send
an email, people must use it nowadays for this purpose.  What was a convenience
became a limitation because of a bad design choice in MX records.  So much for
a "single global address space" that does not respect local flexibility.

NAT boxes are thus just IMO a healthy rebound of the very principles that created
the Internet -- and we must be careful, otherwise pretty soon we are going to have
other things to "solve the problem" (notably as it happened with MX records).

It is time IMO for some at the IETF to stop pretending that the Internet can made into a
homogeneous network.  It wasn't and it won't.  Cooperation is not a bunch of people
doing the same things at the same time, but different people doing different things
at different times and places, for the same objective. Likewise, standardization is not
having the same rules for all at all places but having different rules that interoperate
for the same objective.

Interoperation should be the defining factor for an Internet standard, and the same
applies to NAT boxes.  If they interoperate, what else should be required?  Nothing.

Cheers,

Ed Gerck

---

From: Keith Moore <[email-masked]>
Date: Tue, 23 Jan 2001 03:14:35 -0500

> due to this myopic choice.  This choice also broke layer independency.

What the heck are you talking about?  Sending email to an IP address never 
was deprecated, and still works just fine...  not that it is now or ever 
was widely used.  Sending mail to domains with only A records works just 
fine also.  Folks who have native IP connectivity and don't want to set 
up MX records don't have to do so for their servers. 

There was a switch from HOSTS.TXT to DNS, but this had nothing to do with
MX records.  And not many people miss the days when everybody needed
to be in the HOSTS.TXT file in order to receive mail reliably.

Yes there are broken implementations that cannot send mail to IP addresses,
and cannot send mail to domains without an MX record.  But they are quite
clearly broken, and this is clear from both RFC 974 and the recent revision
to RFC 821/974 that is now in the RFC Editor's queue.  Don't confuse
broken implementations with bad design decisions.  

> It is time IMO for some at the IETF to stop pretending that the Internet 
> can made into a homogeneous network.  

The Internet never has been homogeneous, and I don't know anyone who
has been around IETF very long who pretends that it is.  It has always, 
however, had some minimum standards for addressing and message format 
which not only allowed consenting folks to choose whatever other 
protocols and applications that they wanted to run, and allowed the 
same host and application software to be reused from anywhere in the 
network, and to reach well-known services from anywhere in the network.  

But take away that little bit of uniformity - really the minimum necessary -
and all bets are off.  People who use NATs - especially those using them
on a large scale - are discovering this the hard way.

> Cooperation is not a bunch of people doing the same things at the same 
> time, but different people doing different things at different times and 
> places, for the same objective. Likewise, standardization is not
> having the same rules for all at all places but having different rules that
> interoperate for the same objective.

The whole point of the Internet has always been to allow folks to run
any of a wide variety of networked applications they wanted to run.  
IP is fundamentally designed to give the maximum utility and flexibility
with a minimum of constraints on the networks and hosts supporting it.

By contrast, while folks can clearly do whatever they like with their 
own networks, folks that put NATs on their networks are limiting the 
set of applications that they can run.  Now maybe you're right that 
the existence of NATs is just another example of people doing what 
they like with their networks - just as they always have.  Maybe NATs
are the Internet's adolescence.  But just like adolescents don't always 
understand the consequences of their actions, neither do the folks who 
install NATs on their networks.

IETF cannot compel people to stop using NATs, and it shouldn't try.
But it can and should develop solutions to the problems that NATs 
purport to solve, which work better than NAT.

---

From: "Kyle Lussier" <[email-masked]>
Date: Tue, 23 Jan 2001 03:53:51 -0500

> homogeneous network.  It wasn't and it won't.  

Ip address space will continues to tighten, exponentially increasing
the pain of dealing with such a small number of IPs.  Then throw 200 
million cell phones with their own IP, and you network everything 
in your house, plus all the PDA's and other gadgets coming.

It is a horried idea to start setting up NATs on cell phones,
on PDA's and only god knows what else we be plugged into the net
(I liked the ip addressible coffee machine I saw that you could
telnet into).  Do you really want to put and configure a NAT in 
your coffee maker?

As the pain of limited IP address space tightens we'll move more
and more to IPv6 and it'll level itself out.  While NATs *work*
they are horribly inelegant.  I'm very much reminded of the days
when there was a PC limit of 640k RAM, and the manufacturers
places all the video RAM and support stuff above 640k because
"no one would ever need it".  This caused huge problems for
years and years as we all fought to get back to an open address
space... if then...we had only just invested in a good design.

As the pain of limited IP space increases, so shall we switch
and NAT's will someday be no more.

The question is, how much will we inflict upon ourselves in the
pursuit of making NAT's work?  I hope this time around we
fix the problem earlier....

Kyle Lussier
www.AutoNOC.com

---

From: "David R. Conrad" <[email-masked]>
Date: Tue, 23 Jan 2001 02:58:15 -0800

Kyle,

>It is a horried idea to start setting up NATs on cell phones,

Hmm.  We should probably tell that to the existing 17+ million users of 
i-Mode in Japan.  Better hurry as i-Mode is moving into Europe.

>telnet into).  Do you really want to put and configure a NAT in

I would imagine that you'd have a household gateway/NAT, not a NAT on every 
device in your household (and I'd argue if you have to configure anything 
network related on your coffee maker other than perhaps its name, something 
is seriously wrong).

>and more to IPv6 and it'll level itself out.

IPv6 is not a magic wand.  Because v6 uses provider based addressing, 
non-transit providers will still need to renumber in v6 as they do in 
v4.  Renumbering can be expensive.  NATs are seen by many enterprises as a 
way of removing the need to renumber should they change providers.  Until 
the issue of renumbering is addressed, NATs will not go away.

Rgds,
-drc

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 23 Jan 2001 11:52:25 +0000

o'dell's GSE draft addressed renumbering perfectly.

In message <5.0.2.1.2.20010123015631.02bbba30@localhost>, "David R. Conrad" typ

 >>the issue of renumbering is addressed, NATs will not go away.

 cheers

   jon

---

From: Ed Gerck <[email-masked]>
Date: Tue, 23 Jan 2001 20:00:19 -0800

Keith Moore wrote:

> was deprecated, and still works just fine...

Perhaps we agree that DNS names depend on IP numbers as part of their trusted
context, but IP numbers do not depend on DNS names.

However, certain design choices in the evolution of the DNS,
since long ago, have made users fully dependent on the DNS for
certain critical Internet services -- which choices further
strengthened the position of DNS name registration as the single
handle of information control in the Internet.  And, in a
reverse argument, its single point of failure.

Indeed, the DNS was never intended to be essential to the
Internet, since all Internet hosts are accessible by their
IP numbers alone -– however, those engineering choices in the
design of the resource records and various e-mail protocols make
it nowadays impossible for an average user to send or receive
e-mail in the Internet without a DNS service.  In short, DNS names
have become the addresses of mailboxes and the addresses of
e-mail forwarders in MX resource records.  Or, you are required to
have a matching reverse DNS that you do not have. Which is
another misplaced requirement, since why should you trust a second
query to a system you do not trust in the first place? This is also
relevant in terms of failure and control analysis because the e-mail is
by far, the most important application on the Internet for many users.

Thus, contrary to usual folklore in the Internet, the DNS is
nowadays essential to Internet usage -- as anyone can verify
simply by trying to send an email to an IP number.

Further, by placing the decisions of network address assignment
(IP numbers) together with DNS matters under the ruling of one
private policy-setting company (ICANN), we see another example
of uniting and making all depend on what is, by design, separate.
The needs of network traffic (IP) are independent of the needs
of user services (DNS). They also serve different goals, and
different customers. One is a pre-defined address space which
can be bulk-assigned and even bulk-owned (you may own the right to
use one IP, but not the right to a particular IP), the other is
a much larger and open-ended name space which cannot be either
bulk-assigned or bulk-owned. They do not belong together.

BTW, these were all decisions that the IETF helped put in place.
But, are they helpful?  I don't think so and I suggest you question
yourself based on what we see today.  While they may seem difficult
to change (ICANN?), at least they may show us what not to repeat
with IPv6 for example -- the syndrome of seeking a global solution to
local problems.

> network, and to reach well-known services from anywhere in the network.

Yes.

> on a large scale - are discovering this the hard way.

This is where we disagree. These people are having the best time and making
the most out of *their* networks.  They would be worse without NATs.

> any of a wide variety of networked applications they wanted to run.

Not only applications, but also protocols.

> with a minimum of constraints on the networks and hosts supporting it.

Yes, but why constrain it to IPv6?  It can -- and should -- interoperate with
IPv4.  And NATs may help there as well, not just with IPv4.

> set of applications that they can run.

Not applications  -- they may be limiting the set of addresses they are using
for sending and receiving.  Which might be the whole idea ;-)

> Now maybe you're right that

well.. you kiddies just do not know what we are doing .. you need adult
supervision.  Well, who names the adults? Who supervises the adults?

> purport to solve, which work better than NAT.

Yes, that is good.  But, I suggest, that are problems which NATs solve
that you cannot solve otherwise ... unless you again advocate a homogeneous
Internet.

Cheers,

Ed Gerck

---

From: Keith Moore <[email-masked]>
Date: Wed, 24 Jan 2001 00:03:59 -0500

Ed,

without getting too long-winded

- I think you're overstating the degree to which the Internet
  protocols depend on DNS (with the notable exception of NATs 
  that use DNS ALG to fake things out).  Users who aren't 
  behind NATs can still use IP addresses directly if they want to,
  and more importantly, so can their applications.

  Sending email to moore@[128.169.94.1] works just fine, and has
  worked just fine for at least 14 years.

- The flaws in DNS notwithstanding, I think you're grossly 
  understating the tremendous advantage that DNS brings to the 
  Internet.  Name-to-address mapping (via HOSTS.TXT and other
  schemes) was regarded as an essential service even before DNS;
  DNS made the job a lot more managable and has survived, what - 
  four to five orders of magnitude of growth in Internet user 
  population?  Without DNS or something like it, the Internet 
  would never have been anywhere nearly this successful.

- A service that maps names of distant resources to addresses 
  is not a local problem by any stretch of the imagination.

- I agree that the Internet architecture should not depend on DNS,
  but that doesn't mean that DNS is not an essential service.
  We might disagree about the reasons that the architecture should
  not depend on DNS - I would say that we need to be able to build
  other name lookup services that work alongside DNS (rather than 
  having to go through the existing DNS protocol) either because
  they are providing a very different service or because we might
  want to replace DNS someday.  And appliations which don't work well 
  through DNS due to performance reasons should not be constrained to 
  have to use it.

- You're grossly overstating ICANN's authority or responsibility
  in either DNS name or IP address assignment, and also the degree 
  to which IETF was able to influence the structure of ICANN.

Keith

---

From: Stephen Kent <[email-masked]>
Date: Wed, 24 Jan 2001 10:31:12 -0500

Ed,

><snip>

>by far, the most important application on the Internet for many users.

Prior to the existence of DNS, we relied on the hosts.txt file which 
was maintained at a central site and downloaded (typically daily) by 
all the hosts. There has long been a reliance on a name to address 
translation facility because addresses are unacceptable as human user 
inputs to applications and because network management requires an 
ability to change the address of a host.  (In the ARPANET days, the 
host addresses were derived from IMP port numbers, so any move of a 
host from one port to another, e.g., due to a local hardware or comm 
line failure, required changing the address of the host.) So I can't 
agree with your assertion that the DNS (or an equivalent name to 
address mapping service) was never intended to be essential to the 
Internet

>bulk-assigned or bulk-owned. They do not belong together.

They are separated one level down from ICANN, where we have TLDs for 
names that are distinct from regional registries for addresses and 
other numbers. Having one group coordinate these two distinct 
assignment activities offers benefits, since both need some central 
management authority, as well as drawing criticism.

Steve

---

From: Ed Gerck <[email-masked]>
Date: Wed, 24 Jan 2001 11:47:34 -0800

> without getting too long-winded

me too :-)

- I did not say the DNS is not useful.  I said it has design flaws, and
I named some of them.  These flaws are examples of what NOT to do
with IP.

- A service that maps names of local resources to distant addresses
  is  a local problem.

- I did not say the DNS is worse than the HOSTS.TXT table it replaced.
In fact, it clearly isn't.  But the DNS is not a magic wand either, besides its
design flaws.

- I do not think the DNS can be phased out any time soon, or foreseeable.

- However, one must ask what comes after DNS -- because something will.
I fully expect this "something" to interoperate with DNS.

- The same arguments apply to IP -- what comes after IPv4, IPv6? Something
will, and I expect they all to interoperate.  NATs help.

- I think ICANN is a mistaken way to solve a non-existing problem.  The
non-existing problem is how to govern the Internet.  The mistaken way is
by central control.

- The Internet depends on the DNS, it should be the other way around.
Further, this dependence creates an "ideal" control handle, which is
useful for some that do want to unduly control many aspects of the
Internet for their special interests -- and to their detriment, paradoxically.
If a technical system can be designed that would negate such a handle
to all, this would be intrinsically fair and defuse much of the "problems"
we have with DNS and its control (ICANN).

- The IETF abhors liability. However, its actions have defined the DNS,
its flaws, helped shape ICANN, its flaws, and are now trying to shape IP,
and its flaws.  It is time we all think a bit about the highly leveraged game
being played here, with near 800 million Internet users.  MIME's rule of
requiring the least and accepting the most is the best impedance matching
rule we can have, IMO, to allow different systems to interface.

Cheers,

Ed Gerck

---

From: Keith Moore <[email-masked]>
Date: Wed, 24 Jan 2001 15:31:05 -0500

> I named some of them.  These flaws are examples of what NOT to do

DNS does have design flaws, but I don't think you've identified any of them.

> - A service that maps names of local resources to distant addresses

whatever.  mapping local resources onto distant addresses is not a problem
that a lot of people are interested in solving.  if DNS cannot do this
well, it's hardly DNS's fault - that's not the purpose for which it was
designed.

> But the DNS is not a magic wand either, besides its design flaws.

I agree that DNS is not sutable for every conceivable purpose.  For
example, DNS is not suitable as a means for mapping service names
to connection endpoints within distributed applications.

> I fully expect this "something" to interoperate with DNS.

I think there might be multiple somethings - both successors to DNS
(that provide the same function, probably supporting the same query 
protocol for backward compatibility) and other lookup services that
map names (say common names, as in CNRP) to service locations.

(in some of the early work I did on URN resolution systems I discovered
that the resolution system really needed to return the IP addresses
of the resource locations that it found, and not just the URLs of
those resources - otherwise the entire system slowed to a crawl.)

> will, and I expect they all to interoperate.  NATs help.

NATs (specifically NAT-PTs) do help interoperate between IPv4 and IPv6.  
If one end only speaks IPv4 and the other end only speaks IPv6, NATs
are the only way to get them connected.  However this approach still has
the problems common to all NATs.  It's not a general solution, it's just
the best that can be doen.

> non-existing problem is how to govern the Internet.  The mistaken way is

You obviously don't understand ICANN's intent or function, but it's not
to govern the Internet.  You also don't understand just how little power
ICANN has.

> Internet for their special interests -- and to their detriment, 

The URN group spent a lot of time thinking about how to administer
a centralized namespace with minimal potential for control.  A 
system like DNS which has multiple root servers, a federated name
space, with lookup also federated along delegation boundaries,
is nearly ideal - it gives the roots the minimum degree of control.
Other systems that relied on centralized lookup or which delegated
lookups via other means (say using a hash of the name) were much
more vulnerable to this kind of exploit.  Which is not to say that
there's no risk, but that the DNS structure minimizes the risk 
to the extent that we know how to do it.

Moreover, having a organization like ICANN - i.e. one which has no other 
function besides administering top-level name and number assignments -
in charge of the roots, seems far preferable to having either
a government or a commercial organization in charge of the roots.
The latter two are far more of a threat to Internet users than ICANN.
The biggest danger associated with ICANN is mission creep - because
they are centralized people are constantly tempted to saddle them with
other aspects of "internet governance" that seem to demand centralization.
I hope that ICANN will discourage and be discouraged from taking on
such roles.  Only time will tell.

> we have with DNS and its control (ICANN).

Perhaps.  But nobody has found a way to do this that (a) prevents naming
conflicts and (b) makes lookups of those names visible to the entire
Internet.  Both of these are desirable features of the current DNS system.
I agree that it should be possible to build other kinds of lookup systems,
but it's hard to solve the problem that DNS tries to solve without having
at least a minimal root.

> and its flaws.  It is time we all think a bit about the highly leveraged 
> game being played here, with near 800 million Internet users.  

Be assured that it *is* being thought about and has been for several years.
ICANN is the best we could do under the circumstances, given the size of 
some of the gorillas involved.    If you want to get rid of ICANN, think
about who is likely to take its place if they go under, and see if you 
really think the Internet would be better off.  

As you realize, DNS is going to be around for a long time, it's going 
to have a root, and someone is going to be controlling that root.
Who is most likely to do so fairly? 

> MIME's rule of

Actually, that's a good analogy.  DNS requires the least - a minimal root,
and delegates the vast majority of lookups and assignments to others.

Keith

---

From: "David R. Conrad" <[email-masked]>
Date: Wed, 24 Jan 2001 07:52:00 -0800

>o'dell's GSE draft addressed renumbering perfectly.

And look how far it got.

Rgds,
-drc