![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
On Tue, 30 Nov 1999 13:37:33 PST, "Tony Hain (Exchange)" said: > This is the kind of BS that keeps these debates running. NAT problems exist > anytime a connection originates on the public side and there is not a > preexisting clear mapping to the private side. I didn't pick on Real Player I said: > Well.. Urm... TCP and UDP both assume that one endpoint is talking > directly in real time to another endpoint. The NAT problems only > start when the protocol carries IP address/port information (such > as the FTP 'PORT' command), and the NAT isn't aware of that protocol's > translation requirements (If you see *this* at offset 80 of *that* > packet, smash it to read *foobar* instead). I think we're actually saying the same thing here, and are violently in agreement, from different viewpoints. A 'pre-existing clear mapping' is what the NAT needs in order to do the datastream manipulations needed. Of course, if there exists such a mapping, but your NAT is older or for other reasons doesn't understand/implement it, you're still stuck. I meant "the problems only start" in the context of the breakage a NAT renders on a single connection that is assuming it's able to make an unmangled, unmodified end-to-end connection. If the NAT is able to handle the translation, the connection still suceeds. If the NAT doesn't do it, the connection loses. As Keith Moore pointed out in http://www.cs.utk.edu/~moore/what-nats-break.html there are other contexts *outside* that context that NAT has an impact on... -- Valdis Kletnieks Operating Systems Analyst Virginia Tech
Attachment:
pgpKVtgFzMiKS.pgp
Description: PGP signature
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.