IPv6 support in Cloudstack

[Salvatore Orlando <Sa...@eu.citrix.com>]

Hi, 

IPv6 would be a dramatic improvement for Cloudstack networking, 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".

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.

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?
Cloudstack however, allows some network services to be provided by external network elements. In your opinion, would support for IPv6 addressing of such network elements be part of the first implementation of IPv6 support?
Moreover, what is your opinion about IPv6-specific features such as stateless autoconfiguration, or intserv/diffserv (QoS)?

Regards,
Salvatore

Re: IPv6 support in Cloudstack

[Chip Childers <ch...@sungard.com>]

On Mon, May 14, 2012 at 3:26 AM, Wido den Hollander <wi...@widodh.nl> wrote:
>
> On 05/12/2012 03:11 AM, Thomas de Looff wrote:
>>
>> I don't think this is a good idea. I think we have to make step one and two at the same time.
>> 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.
>

Being focused on advanced networking myself, I'll limit my comments to
that model.  I really believe that the correct first phase would be to
implement a dual stack for the virtual router (and / or whatever other
network device the provider is using to act as a gateway), with IPv6
on the private network(s) being a second phase.  If you think about it
from a migration point of view, most systems are still designed around
IPv4.  The external connectivity being dual stack, but the internal
side still supporting IPv4, is a very desirable deployment approach
for users.

-chip

Re: IPv6 support in Cloudstack

[Wido den Hollander <wi...@widodh.nl>]

Hi,

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"<Sa...@eu.citrix.com>
>> wrote:
>>
>>> Hi,
>>>
>>> IPv6 would be a dramatic improvement for Cloudstack networking,
> I totally agree on that

+1

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

Wido

Re: IPv6 support in Cloudstack

[Thomas de Looff <th...@pcextreme.nl>]

Hi,

On 12 May 2012, at 2:20 AM, Chiradeep Vittal wrote:

> 
> 
> On 5/11/12 9:21 AM, "Salvatore Orlando" <Sa...@eu.citrix.com>
> 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 time.
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.

> 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.
+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.
> 
> [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?
> 
> +1 for DHCPv6. It seems that more and more OS support this natively, but
> feedback is welcome.
> +1 for dual-stack also. I think that even if the web-tier is IPv6, the
> backend tiers (DB, etc) will continue to be IPv4 for longer.
> 0 on SLAAC. Just feels a little "out-of-control" to me.

+1 for DHCPv6
0 SLAAC, router announcements are not giving you enough posibilities.
+1 for dual-stack

> 
>> Cloudstack however, allows some network services to be provided by
>> external network elements. In your opinion, would support for IPv6
>> addressing of such network elements be part of the first implementation
>> of IPv6 support?
> 
> As above, I feel that getting it on the LB would be a huge first step
> 
>> Moreover, what is your opinion about IPv6-specific features such as
>> stateless autoconfiguration, or intserv/diffserv (QoS)?
>> 
>> Regards,
>> Salvatore
> 
> For multi-tenant clouds, we would also need to avoid attacks on the
> physical infrastructure such as this one [1]. Hypervisor features such as
> port-locking can help.
> 
> --
> Chiradeep
> [1] 
> http://blog.ioshints.info/2011/05/ipv6-neighbor-discovery-exhaustion.html

I would like to help building IPv6 support for Cloudstack.

> 


Regards,

Thomas de Looff

Re: IPv6 support in Cloudstack

[Chiradeep Vittal <Ch...@citrix.com>]

On 5/11/12 9:21 AM, "Salvatore Orlando" <Sa...@eu.citrix.com>
wrote:

>Hi, 
>
>IPv6 would be a dramatic improvement for Cloudstack networking, 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.
I would exclude 
1) IPv4 clients accessing IPv6 services in the cloud
2) IPv6 clients accessing IPv4 services in the cloud

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]

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

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

[see above]

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

+1 for DHCPv6. It seems that more and more OS support this natively, but
feedback is welcome.
+1 for dual-stack also. I think that even if the web-tier is IPv6, the
backend tiers (DB, etc) will continue to be IPv4 for longer.
0 on SLAAC. Just feels a little "out-of-control" to me.

>Cloudstack however, allows some network services to be provided by
>external network elements. In your opinion, would support for IPv6
>addressing of such network elements be part of the first implementation
>of IPv6 support?

As above, I feel that getting it on the LB would be a huge first step

>Moreover, what is your opinion about IPv6-specific features such as
>stateless autoconfiguration, or intserv/diffserv (QoS)?
>
>Regards,
>Salvatore

For multi-tenant clouds, we would also need to avoid attacks on the
physical infrastructure such as this one [1]. Hypervisor features such as
port-locking can help.

--
Chiradeep
[1] 
http://blog.ioshints.info/2011/05/ipv6-neighbor-discovery-exhaustion.html