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