Valdis,
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 at random. My house is connected through a NATPT, and my wife couldn't get a video stream opened back to her machine. If I had pre-mapped those ports to her machine, then my son would not have been able to get them on his. If I pre-map them, all the bogus security arguments about NAT become invalid. Clearly NAT has allowed me to create an environment which is not sustainable, but at least I know enough to know what the problem is, the average guy on the street doesn't stand a chance.
Yes there are problems with protocols that carry addresses, but ignoring encrypted traffic that really amounts to acquiring and synchronizing deployments of ALGs. In the early stages this doesn't sound hard, but will vendors be willing to add new ALGs to 3 year old NAT hardware? Will they create an update process that is easy enough for the average user? Will the average user be able to figure out which NAT needs updating, and what version it needs? Add the fact that people want to encrypt their traffic for privacy, and one wonders why so much effort is spent on this dead-end technology.
Tony
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 30, 1999 12:05 AM
To: Ian King
Cc: [EMAIL PROTECTED]
Subject: Re: IP network address assignments/allocations information?
On Mon, 29 Nov 1999 22:45:17 PST, Ian King said:
> any "lack" because of it. I don't play UDP-based games or employ any of the
> other relatively new protocols that are so sensitive to end-to-end-ness
> (should they be? was that a valid assumption?), so a NAT is a great solution
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'll grant FTP an exemption, it came well before NAT units became
prevalent (Was there an FTP-over-NCP before The Great IP Deployment?).
However, I do agree that anybody designing a protocol in the last 3-4
years *should* have designed it to be firewall and NAT friendly.
(Yes, I know that can be difficult in practice. I guess that's today's
"Welcome to Reality").
Valdis Kletnieks
Operating Systems Analyst
Virginia Tech
