Subject: RE: ocean: do not boil

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Tue, 24 Sep 2002 00:27:15 +0200

> Hah, I knew someone would spot that.
  > 
  > Because you don't use 'em for a large v4 cloud.  You use 'em for a
  > little v4 edge site behind some kind of combination NAPT/NAT-PT box
  > and use some kind of v6-over-v4 tunneling over the rest of the v4
  > cloud.  So you've got a lot of little translators converting to IPv6
  > as early as possible, which scales much better than big honking
  > translators at the border between the cloud and the rest of 
  > the world.

=> ok, I thought you eliminated NA(P)T-PTs but I obviously
misunderstood that. There were several discussions in 
our DT meeting in Sunnyvale to make NAT-PT scale in a 
similar manner by having "translator clusters". 
Essentially, it all boils down to removing the DNS ALG
from NAT-PT and different ways were proposed. 

I think we can make it scale with very little effort actually.

  > 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.

Hesham

---

From: Rob Austein <[email-masked]>
Date: Mon, 23 Sep 2002 19:19:10 -0400

At Tue, 24 Sep 2002 00:27:15 +0200, Hesham Soliman (EAB) wrote:
>> 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!

---

From: [email-masked]
Date: Tue, 24 Sep 2002 11:57:49 +0900

>why you would run out of addresses in one case but not

	you can run IPv4 with NAT, and IPv6 globally-routable, on the same cloud.
	we don't need to fix IPv4 problem people are having - and better, IPv6
	will be able to provide a better applications experience than IPv4 with
	NAT.

itojun