Subject: Re: Number of Firewall/NAT Users

From: [email-masked] (Sean Doran)
Date: Tue, 23 Jan 2001 00:45:45 +0100 (CET)

| 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.

Well, the genie is out of the bottle, and if NAT is winning the
fight against NAT-hostile applications, I'd think that applications
writers would be better off taking the existence of NAT into account,
no matter what their NAT politics are.

If a compelling application comes along that is NAT-hostile, that
will be interesting, but I can't imagine it's in anyone's interest
to provoke such a conflict when there are well-known NAT-friendly 
ways of replacing embedded IP addresses in most higher-level protocols
that use them...

For those that are unremittingly unable to use things like the DNS,
perhaps the NSRG will cough up an RFC-822 someday soon, and that will
let you sleep better at night.  :-)

| Now you're suggesting that we need yet another layer, presumably something
| that runs over NATs. 

No, something that runs over a catenet of every conceivable type of
network, including ones which are IP or v6 based.  Why should you care
whether routers are making decisions based on tags, 32-bit addresses,
128-bit addresses (or only 64 bits of a 128 bit address), or 
fully variable-length addresses, or even whether some routers along
the way are using one of these and other routers are doing something
completely different?  Surely you're happy as long as your TCP segment
or UDP datagram gets to the right host with a destination address
which can be used to get a TCP segment or UDP datagram back to you?

IPv4ever ultimately is a UNI philosophy; the NNI is totally up in the air.
For now, it's pretty clearly IPv4.

	Sean.

---

From: Keith Moore <[email-masked]>
Date: Mon, 22 Jan 2001 23:12:44 -0500

> no matter what their NAT politics are.

If you can make your application work as well or nearly as well in
the presense of NATs, you'd be silly not to take the existence of
NAT into account.  However this isn't always feasible.

> will be interesting, 

Several of them already exist, and it is indeed "interesting"...
in the sense of the "may you live in interesting times" curse.

> but I can't imagine it's in anyone's interest

First of all, this is so off the mark as to be completely false.  
Second, you're grossly understating the nature of the NAT problem, 
because inability to embed IP addresses are only one facet of that 
problem.

Look at http://www.cs.utk.edu/~moore/what-nats-break.html

> let you sleep better at night.  :-)

I'm on NSRG, and that's not what it's working on.
And RFC 822 for networks already exists; it's called IP.

> network, including ones which are IP or v6 based.  

To do that you would need yet another name space, and while it might
be useful to separate endpoint names from names for attachment points 
in the network topology, you would still need efficient ways to map
between the two...and DNS-like technology isn't even close to being 
adequate.

> Why should you care
> completely different?  

As an application writer, I don't care so much (though it is sometimes
useful for applications to be able to know about the network topology).

However, as a network administrator, I absolutely want to be able to set 
up my own links between arbitrary points in the network, and having
a variety of network-layer protocols (as opposed to a variety of 
link-layer protocols) doesn't help that in the least.  

What you are proposing sounds like a useless extra layer.  We've already
solved that problem with IP; we don't need to solve it again to try to
accomodate an arbitrary number of network-layer protocols.

> Surely you're happy as long as your TCP segment

No, that's not even close to enough to support distributed applications.  
I also need a global address space, at least from the application's
point of view...and for various reasons applications often need to be 
able to look into the network topology (think logging, and diagnostics,
in addition to location-sensitive selection of resources).

Keith