On Sep 5, 2012, at 21:08 , Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
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.
This is every bit as much BS as it was the first 6 times you pushed it.
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.
Never mind the fact that all the hosts trying to reach you have no way to know what port to use. http://www.foo.com fed into a browser has no way for the browser to determine that it needs to contact 192.0.200.50 on port 8099 instead of port 80.
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).
You're demanding an awful lot of changes to the entire internet to partially restore IPv4 transparency when the better solution is to deploy IPv6 and have real full transparency.
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.
That is one purpose. A more accurate definition of the greater purpose of end-to-end transparency would be: An application can expect the datagram to arrive at the remote destination without any modifications not specified in the basic protocol requirements (e.g. TTL decrements, mac layer header rewrites, reformatting for different lower-layer media, etc.) An application should be able to expect the layer 3 and above addressing elements to be unaltered and to be able to provide "contact me on" style messages in the payload based on its own local knowledge of its addressing.
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
It could be argued, if one considers "contact me on" style messages to be valid, that the function cannot be completely and correctly implemented in the presence of NAT. Moreover, since NAT provides no benefit other than address compression and the kind of additional effort on NAT of which you speak would be a larger development effort than IPv6 at this point, why bother? Owen