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"<salvatore.orla...@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
