On Apr 20, 2010, at 3:55 PM, Joe Abley wrote:
On 2010-04-20, at 15:31, Roger Marquis wrote:
If this were really an issue I'd expect my nieces and nephews, all of whom are big game players, would have mentioned it. They haven't though, despite being behind cheap NATing CPE from D-Link and Netgear.
I have heard it said before that there is significant cooperation and/or software engineering work between some or all of those who make residential gateways and those who make multi-player games to achieve this end result. The opinion I heard vocalised at the time was that it would have been a lot easier to reach this state of affairs if there had been standardisation of NAT in v4 at an early stage. As it is, peer-to-peer apps like games require significant if-then-else to make anything work.
Please go read RFC3235. Also please go read some history. This RFC and others that came out of the NAT working group in the IETF were an attempt to document what NAT was, in its various flavors, and NOT to standardize it in any way. Those of us working on the effort faced voices of opposition at every turn, not for trying to standardize it, but just to DOCUMENT it. During the writing of the drafts that became 3235, I was approached by folks working on gaming, and indeed you will find therein a reference to exactly that. What the gamers wanted was a way to punch a hole out in normal NAT fashion for UDP packets with a given port mapping, but then have less stringent matching on subsequent return packets.
Address conservation aside, the main selling point of NAT is its filtering of inbound session requests.
If that was all that was required, you could sell a stateful firewall that didn't do NAT, and everybody would buy that instead because it would make things like iChat AV break less. Apparently there are other reasons to buy and sell devices that NAT (e.g. my ISP gives me one address, but the laptop and the Wii both want to use the internet).
Implementing stateful inspection firewall code is rather straightforward. Adding NAT functionality to it adds a small number of additional instructions in the forwarding path, enabled only as needed depending on configuration. The NAT part of it is a trivial additional step, nothing more. The point, though, is when dialup and later DSL and cable connections originally came out, ISPs didn't (and in general wouldn't, or wouldn't without a substantial additional fee) give out blocks of addresses to customers. It was the mismatch of customer need and ISP offerings that led to the implementation of NAT in the router products at the vendor I worked at in the early 1990s. In the end, this is all really good lounge discussion, but has nothing to do with network operations and the purpose of the main NANOG list. It doesn't even have anything to do with the subject line of the threat to which it's attached.