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

[Owen DeLong <owen () delong com>]

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