> From: Michael Thomas <mat(_at_)cisco(_dot_)com>
> we're being driven as a community to do both with the ensuing insanity
> of two broken models being forced to cohabitate, all the while neither
> meeting the actual requirements.
Time to hit the "reset" button on our current direction, I would say.
> So just saying that NAT is here get used to it is, architecturally, not
> helpful. .. more importantly the net is becoming more and more
> incomprehensible because of it, both intellectually as well as
> operationally.
> ..
> saying "get used to it" is a weird position because it discounts the
> problems of the status quo and doesn't really express any vision for
> what the architecture *ought* to be
Look, in my comments about NAT, I'm *not* saying "just get used to the
current level of poor design", we're stuck. What I am saying is that it's
time to stop acting like NAT is this awful icky thing that we refuse to touch
in any way because it's so bad, and that if we stick our heads in the sand
hard enough it will go away. It won't.
Here, again, is the nub of what we have to deal with:
>> The notion of a system with a single, globally unique namespace at the
>> lowest level is a really nice one, one we had for a while - and *one
>> we think we can reclaim*. I now think we've been deluding ourselves;
>> that past .. is gone for good.
How would I move forward from there, constructively, to try and produce a
less broken architecture/system?
The very first thing I would so would be to actually write a "NAT spec" (or
perhaps a small number of them, for different flavours that are useful in
different ways).
There are many different flavors of NAT, and so it's hard to make an
application "work with NAT" when you don't know exactly what the NAT box is
going to do. E.g. the recent point about most NAT boxes being port mappers,
not address mappers - I don't know about that, actually, and none of the NAT
boxes I've seen come with specs that say *exactly* what they do.
For another example:
> Voice is one trend and it pretty fundamentally challenges one of the
> base assumptions of NAT: private-client/public-server. But instead of
> realizing that NAT is architecturally incapable of dealing with private
> servers
That's true of the current crop of NAT boxes, but the first NAT boxes (both
Paul Tsuchuchiya's and Van Jacobsen's) did indeed handle incoming connections
(albeit in a really ugly way, by intercepting incoming DNS requests and
modifying the responses, and setting up external->internal mappings based on
that.) The little boxes people running home networks use don't do that.
We first need to really get a definitive handle on what these things are
doing.
The next step would be to add a "NAT considerations" section to all protocol
specifications, just like the "Security considerations" we have now.
Protocols can be designed to be less NAT-hostile - e.g. no giving addresses
to third parties as a way to contact someone, etc.
NAT boxes are here, and are very widespread, and will be for a long time to
come, and it's doing the users (not to mention the IETF) a tremdous
disservice to roll out protocols that won't work with NAT boxes.
Finally, there are some hard technical issues involved with NAT we need to
think about.
We can, if we feel its needed, define a new namespace which is used for
long-term identification of entities, and deploy that on an
application-by-application basis for new applications.
(I've thought about how to modify existing transport protocols on an
upwardly-compatible basis to use such a global namespace for entities, and it
can be done [I have a complete draft spec for TCP]. However, I don't think
that's very useful - too many old installations will remain. I think the same
logic applies to old applications. So only new applications, I think.)
The big problem is incoming connections - how do you set up the mappings they
will need? Wiretapping DNS is ugly, but it doesn't require changing anything
(for existing applications). On the other hand, if you only want to support
incoming connections for new applications, you can define them to include
some sort of MidCom-like setup.
> We want an architecture that meets all of the requirements, not a
> hodgepodge of half solutions which fall over in the first stiff breeze.
Nothing positive can happen as long as we keep acting as NAT i) is too
disgusting to seriously try and deal with, and ii) will go away if we stick
our heads in the sand hard enough
Noel