The End-To-End Internet (was Re: Blocking MX query)

Thu Sep 6 04:08:29 UTC 2012

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