North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: end2end? (was: RE: Where NAT disenfranchises the end-user ...)
> 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.