Re: ocean: do not boil

[Rob Austein <sra+v6ops@hactrn.net>]

At Tue, 24 Sep 2002 00:27:15 +0200, Hesham Soliman (EAB) wrote:
> 
>> The same approach would "work" for large v6 clouds, but the result
>> would not be useful, because it'd require so many IPv4 addresses
>> that there'd be no point to the exercise.
> 
> Wouldn't it require the same number of addresses?  Eventually you
> are translating from a private (be it v6 or 1918 addresses) space to
> public one. The public space would need public v4 addresses. So I'm
> not sure why you would run out of addresses in one case but not the
> other.

In the case where you're adding IPv6 to an existing IPv4 edge site,
you already have IPv4 addreses for the IPv4 site.  They may be screwed
up shared RFC 1918 IPv4 addresess, but they're already there, you
don't need to do anything new with them, and adding IPv6 addresses on
top of that is easy because IPv6 addresses are plentiful.

In the reverse case (the one discussed in the text quoted above) you
have IPv6 addressses already but don't yet have IPv4 addresses.  Of
course you can get IPv4 addresses, but when you've done that much of
the argument for having a v6-only cloud in the first place is gone.

BTW, I was -really- impressed by the model underlying Miyakawa-san's
explanation of how NTT/Verio is combining stable IPv6 /48 allocations
with very small numbers of dynamic IPv4 address.  Their approach
requires no translation, drops very neatly into a number of existing
configurations, and carefully avoids any change to the status quo for
IPv4, so it doesn't violate the Principal of Least Astonishment.  Yay!