> From: Matt Holdrege <holdrege(_at_)lucent(_dot_)com>
>> The basic key *architectural* problem with NAT ... is that when you
>> have a small number of external addresses being shared by a larger
>> number of hosts behind some sort of "address-sharing" device, there's
>> no permanent association between an address and a host. It's *that*
>> that causes many of the worst problems - problems for which there *is*
>> no good work-around (because the problem is fundamental in nature).
>> ... if you have a site which has more hosts than it can get external
>> IPv4 addresses for .. *deploying IPv6 internally to the site does the
>> site basically no good at all*.
> we've been through all this already ... at the IAB Network Layer
> Workshop. One of the conclusions is that an IPv6 network NAT'ed to
> the IPv4 Internet isn't any better than what we have today with
Well, my statement is broader than that. It says that *any* IPv6<->IPv4
interoperability mechanism is going to have the same fundamental problems as
IPv4<->IPv4 NAT. I think that's a pretty powerful statement, one that puts a
hard ceiling on what one can hope to accomplish (in any moderate timeframe)
with *any* alternative to IPv4<->IPv4 NAT (including IPv4 RSIP).
> So if you are NAT'd to the public Internet today, you shouldn't have
> a problem with converting internally to IPv6. At least from an
> architectural sense. :)
Sure, you're going to have basically the same service externally, if you are
using IPv6 internally, as you are if you are using IPv4 internally.
So, you're the CIO for Foondoggle Corp, and you're trying to figure out
whether to spend any of your Q3 funds on IPv6 conversion. Let's see, benefits
are not very many (autoconfig may be the best one), and the cost is
substantial. OK, let's put it off till the next quarter. Go back to step 1.