IPv4 -> IPv6 "bridge" ?

[Cameron Byrne]

On Tue, Oct 12, 2010 at 2:03 AM, Xavier Beaudouin <kiwi at oav.net> wrote:
> Hello,
>
> The thread about IPv6 Future, how will you solve IPv4 connectivity, is for me also a problem.
>
> I operate a new born cloud computing company in France (we do only this kind of business, exclusively), and we have the problem of IPv4 exhaustion...
>
> We had an idea to do IPv6 only on all hosts and create a kinda bridge with our /21 (at starting) to do IPv4 -> "internal" IPv6 host that must be reachable from IPv4 "old internet", also this mapping has to be done in direction IPv6 host -> IPv4 when this host needs to reach some IPv4 stuff.
>
> Unfortunatly it seems to be not easy, even in the free world (for example OpenBSD...)...
>
> Anybody has some pointers, rfc or what else to implement that ?
>
> Also we don't want dual stacks, VPN and some fscking from people that using too mutch RFC1918 networks will gave some ipv4 collisons... That's why we want to force end users to use IPv6 exclusively (since there is as least 2 ISP that provide native or near native IPv6 connectivity in France), this can be "the ipv6 killer application" to force the world to move really to IPv6....
>

Very cool.  Cloud is another space with a fast growing edge and thus
IPv6-only now is appropriate and fit for the long run.

That said, if i were you, i would focus on the simplest solution
possible. A lot of the cloud and IaaS services i have seen are managed
via  a web control panel.  If your sufficiently advanced control panel
is dual stack, you should not need to do any translation for admin
purposes.  The user and their APIs can interact with the middleware /
control panel that is dual stack,.  This would include uploading and
selecting VM images, data sets, and so on.  This allows the user to
interact with the cloud using v4 or v6, and the cloud to just be ipv6.
 Perhaps the middleware / control panel acts as an async drop box that
allows the shuttling of files (not tcp / udp streams) with scripts

I have seen control panels that have applets the emulate console
sessions, not the best, but a lot of cloud is just API automation....
depends on what your target market is.

If the cloud IaaS service has to be exposed to the IPv4 web (if the
IaaS is web servers), i believe many load balance vendors allows load
balancing based on HTTP header.  So, with 1 IPv4 address, you could
map to several HTTP URLs, which map to unique IPv6 machines.  All
heavy web sites have load balancers, this yet another trick to make
the IPv4 go further without mapping ipv4 directly to ipv6, use the URL
as a key for multiplexing.

And for customers that must have native access to the machine, they
can get IPv6 access via their ISP or a tunnel broker.... and you
should probably start a direct tunnel broker for your users.  Many
IaaS / clouds providers sell L1 and L2 WAN access into the cloud too.

I am only thinking high level, and the devil is in the details

Thinking long term, i would avoid IVI or any direct one to one IPv4 to
IPv6 mapping technologies since one to one does not scale, it does not
leverage the real advantage of ipv6.

Cameron