[97248] in North American Network Operators' Group
Enterprise IPv6 (Was: Cool IPv6 Stuff/Security gain from NAT)
daemon@ATHENA.MIT.EDU (Nathan Ward)
Mon Jun 4 22:19:43 2007
In-Reply-To: <4663E0F9.2090604@spacething.org>
From: Nathan Ward <nanog@daork.net>
Date: Tue, 5 Jun 2007 14:18:58 +1200
To: Nanog <nanog@nanog.org>
Errors-To: owner-nanog@merit.edu
On 4/06/2007, at 9:52 PM, Sam Stickland wrote:
>
> Jared Mauch wrote:
>>
>> http://www.icann.org/meetings/lisbon/presentation-doering-=20
>> ipv6-25mar07.pdf
>>
> In answer to two questions at the end of this document:
>
> =95 what are enterprises waiting for?
> =95 should we ditch IPv6, and live with IPv4 + NAT forever?
>
> Personally I hate NAT. But I currently work in a large enterprise =20
> environment and NAT is suprisingly popular. I came from a service =20
> provider background and some of the attitudes I've discovered =20
> towards private addresses in enterprise environments are quite =20
> surprising. Aside for the usual proponents of using NAT to hide =20
> your internal address infrastructure (which security always seem to =20=
> insist upon) quite a popular design rule of from seems to be "Only =20
> carry public addresses on the public Internet and only carry =20
> private addresses on your private network" :-|
>
> If an Enterprise doesn't have a great deal for IP addresses that =20
> need to be routed on the public internet, and they thing that NAT =20
> is a _good_ design choice, it seems to me that they don't have a =20
> great deal of pressure to move to IPv6.
While those are valid concerns, stateless inspection fills the "gap" =20
that NAPT provides in terms of filtering packets, and the privacy =20
extensions for stateless autoconfiguration (RFC3041 and further work, =20=
enabled by default on Windows, disabled by default on Mac, BSD, not =20
sure about Linux.) address the "lack" of anonymity.
What this thread fails to mention is that NAPT is a band-aid. It =20
won't help us forever, as it still requires one IPv4 address per site =20=
(however that is defined), unless it is proposed that ISPs start to =20
put many customers behind a single NAPT - which I strongly hope it's =20
not.
While it's entertaining [1] to debate the pros/cons of NAPT's ability =20=
to provide security for the 500th time, we're essentially debating =20
the pros/cons of a "technology" that is going to (hopefully) be =20
outdated soon. I suggest we move on.
Sam, have you heard any concerns, other than that "NAPT provides us =20
security" one?
--
Nathan Ward
[1] Ok, it's actually not.
