[125675] in North American Network Operators' Group
Re: Rate of growth on IPv6 not fast enough?
daemon@ATHENA.MIT.EDU (Daniel Senie)
Wed Apr 21 01:06:11 2010
From: Daniel Senie <dts@senie.com>
In-Reply-To: <AE8D3790-EB82-40C0-99DE-74D898A10A2D@hopcount.ca>
Date: Wed, 21 Apr 2010 00:58:27 -0400
To: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Apr 20, 2010, at 3:55 PM, Joe Abley wrote:
>=20
> On 2010-04-20, at 15:31, Roger Marquis wrote:
>=20
>> 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.
>=20
> 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.
>=20
>> Address conservation aside, the main selling point of NAT is its =
filtering of inbound
>> session requests.
>=20
> 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.=
