incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wido den Hollander <>
Subject Re: IPv6 support in Cloudstack
Date Mon, 14 May 2012 07:26:33 GMT

On 05/12/2012 03:11 AM, Thomas de Looff wrote:
> Hi,
> On 12 May 2012, at 2:20 AM, Chiradeep Vittal wrote:
>> On 5/11/12 9:21 AM, "Salvatore Orlando"<>
>> wrote:
>>> Hi,
>>> IPv6 would be a dramatic improvement for Cloudstack networking,
> I totally agree on that


>>> and I would like to spend some dev cycles on it in the upcoming weeks.
>>> However, "IPv6" is a fairly wide topic. So I would like to gather some
>>> feedback from the community in order to understand what is a priority,
>>> what is a "desirable plus", and what is instead a "meh".
>> I think the primary use case [P] would be so that tenants in the cloud can
>> offer services over the IPv6 network to IPv6 clients.
>> The secondary use case [S] is allowing IPv6 on the underlying physical
>> resources supporting the cloud.
> +1
>> I would exclude
>> 1) IPv4 clients accessing IPv6 services in the cloud
>> 2) IPv6 clients accessing IPv4 services in the cloud
> I agree on that  tunneling protocol such as 6to4, 6in4, or Teredo they do more harm then
they help, in my opinion native IPv6 is the way to go.
>> For the primary usecase, the question arises around
>> A) configuration of tenants: addressing, dns, dual-stack
>> B) support of different services [e.g., firewall using VR or hardware
>> devices vs security groups]
> +1
>> If we accept that [P], then it would seem that a good first step is to
>> support IPv6 on the loadbalancer public ip, while allowing the tenant VMs
>> to remain IPv4.
> I don't think this is a good idea. I think we have to make step one and two at the same
> Or maybe start with step two, so you can assign public ip's to your VM when you are using
basic networking.
> In my opinion the most imported thing is that the VM's it self have an public IPv6 connection.

I have to agree with Thomas on this one. Only doing IPv6 to the outside 
and doing IPv4 "inside" does not seem the best way to me.

In some countries IPv4 is really becoming a problem. Yes, we'll using 
private IP's for that internal communication, but I'd vote to come with 
a implementation where IPv6 works up until the instance itself.

The simplest way seems to begin with handing out IPv6 in basic 
networking, use DHCPv6 for handing out IP's.

Router Advertisements pose some problems, since they do not allow you to 
sent an alternative gateway, the RA should come from the gateway itself.

The only problem is that Ubuntu and Debian (Don't know about 
CentOS/RHEL) do not probe for DHCPv6 by default, but that's just a 
matter of creating a template which does.

>> A second step would be to enable IPv6 on the guest network (for example
>> for the web tier) and implement firewalls in the VR or hardware edge
>> device.

I'd say the second step is advanced networking where you tell the 
Virtual Router: "Well, I'm routing this /48 to you, you figure out what 
to do with it!"

The VR can then spit up this subnet into multiple /64's and hand them 
out to the underlying instances.

> +1
>> Presumably NAT, PAT, Source NAT and such things are not needed. VPN is
>> likely a desirable edge service as well.
>> A third step is to enable security groups on IPv6
> +1
>> .
>>> When I look at IPv6 in Cloudstack, I tend to look at it along two
>>> directions: nature of traffic and network protocols.
>>> For traffic types, do we want to support guest traffic only, or support
>>> IPv6 on storage and public traffic too? We might think of supporting it
>>> for management traffic as well, but I think we might end up with limited
>>> supported for IPv6 as some of the hypervisors cloudstack supports don't
>>> allow management on IPv6 addresses yet.

Currently only iSCSI supports IPv6, but when I'm done with the RBD/Ceph 
support that will also support IPv6 for storage communication.

In the long run you should be able to run a IPv6-only CloudStack cluster.

>> [see above]
> I think that public and guest traffic are the most imported once, but I think that we
also have to integrate it for storage and management networks too.
> I don't think there is a problem for KVM and Xen, what kind of problems do you suspect
with the hypervisors?
>>> As concerns Network protocols, I guess we want to make sure at least that
>>> the services which are running on the VR, mainly DHCP and DNS, keep
>>> working on IPv6 as well. Do you reckon this is a priority as well?

I'd say yes. It's not that hard to reconfigure DNS to work on v6 as well.

DHCPv6 is however completely different from v4 and will require a second 
DHCP server to run.

IPv6 doesn't use broadcast anymore.


View raw message