> | 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 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.
> If a compelling application comes along that is NAT-hostile, that
> 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
> 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...
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
> 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. :-)
I'm on NSRG, and that's not what it's working on.
And RFC 822 for networks already exists; it's called IP.
> | 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.
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
> 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?
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
> 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?
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
