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.
