Jimmy Hess wrote:
NAT would fall under design flaw, because it breaks end-to-end connectivity, such that there is no longer an administrative choice that can be made to restore it (other than redesign with NAT removed).
The end to end transparency can be restored easily, if an administrator wishes so, with UPnP capable NAT and modified host transport layer. That is, the administrator assigns a set of port numbers to a host behind NAT and sets up port mapping. (global IP, global port) <-> (local IP, global port) then, if transport layer of the host is modified to perform reverse translation (information for the translation can be obtained through UPnP): (local IP, global port) <-> (global IP, global port) Now, NAT is transparent to application layer. The remaining restrictions are that only TCP and UDP are supported by UPnP (see draft-ohta-e2e-nat-00.txt for a specialized NAT box to allow more general transport layers) and that a set of port numbers available to the application layer is limited (you may not be able to run a SMTP server at port 25). The point of the end to end transparency is: The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. quoted from "End-To-End Arguments in System Design", the original paper on the end to end argument written by Saltzer et. al. Thus, The NAT function can completely and correctly be implemented with the knowledge and help of the host protocol stack. Masataka Ohta