end2end? (was: RE: Where NAT disenfranchises the end-user ...)

Fri Sep 7 22:13:07 UTC 2001

> But NAT goes further.

well, the distinction between delivery information and content
(not to mention their layering in the packet itself) is pretty
clear with most protocols.  to be more clear, if there were
an encrypted data transmission protocol that you wanted to use,
you could expect that the content of the packet (the data portion
of the packet) wouldn't be modified -- it would make it impossible
for the recipient to decrypt -- but that some of the delivery information
(source addr/port, dest addr/port) might be modified, say, by your
ISP if it were to their (and perhaps even your) advantage.  so if
your packet travels from your box to the remote box that you intend,
you should be happy.  the content is unmodified, it got there, you
probably don't care terribly much about the path it took (as long
as it got there quickly enough), or even whether any of the non-data
portions of the packet were rewritten.

the only time NAT should (and does, really) rewrite the data portion
of the packet is if the protocol includes intended delivery information
in the data portion of the packet.  since NAT will keep your packet
from getting from point A to point B in that case, it rewrites only
the portions of the packet needed to keep parties at A and B communicating
merrily along.  i'm sure that an ISP you threatened with legal action
for modifying your data would be perfectly happy to leave the data
portion untouched, but then your protocol might not work so well.

when you write a protocol, regardless of the application, that tries
to make requirements _in the data portion_ about how the remote side
should write its _header portion_, you really are asking for trouble.

anyone that wants these protocols to work over firewalls is going to
have to explain to the world where to look in the packet for the
appropriate information, and is going to have to expect that it's
likely to be rewritten.  the same goes for NAT.  setting up a server
of any kind behind a NATted address isn't impossible -- and if the
protocol requires header information to be specified in the data
portion of the packet, they need to let people know how to rewrite
it so that it can merrily move from point A to point B.

imagine that, say, a TCP-based protocol for delivering email specified
the _route_ that it required a packet to take in the data portion of the
packet.  or that the data portion required that the return packet have
a particular breed of frame wrapped around it.  i don't think that many
ISPs would find this reasonable, because those decisions are typically
left up to the ISP to make.

NAT != evil, so let's try to be a little bit more evenhanded about this.

anytime you try to compensate for a limited resource, you're going to
have to make sacrifices.  the main sacrifice i can see with NAT, really,
is that people who want to write protocols need to make sure that they
get the word out about anything in the data portion (or in the protocol
itself) that places restrictions upon headers in the packet.  and the
understanding that if there are such restrictions, it might be a little
while (i.e. until all NAT implementations everywhere plug in a handler
for the new protocol in question) before all networks in the world are
going to be able to pass their packets around with ease and zen-like
harmony.  is that really so much to ask?  

s.