> From: Michael Thomas <mat@cisco.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