On 5/11/12 9:21 AM, "Salvatore Orlando" <[email protected]> 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
