Heya, Took the liberty of copying the proposal into email as this makes discussion much easier. Comment inline like a regular email.
> IPv6 Support > > 1 Background > CloudStack does not support IPv6 today. Users/Customers are starting to ask > for IPv6 support in CloudStack. With some users running out of IPv4 > addresses, this should be a important requirement. With complete IPv6 > support, customers would be able to deploy Public/Private clouds on both IPv4 > and IPv6 environments Agreed, we are already running out of IPv4 space today. So I've also been working on getting some IPv6 support into CloudStack, mainly for isolated networks. > > 2 Requirements > Moved all of the requirements from the following JIRA ticket. > > https://issues.apache.org/jira/browse/CLOUDSTACK-452 > > This is quite a large feature, but we are lacking complete IPv6 support at > this moment. > > We should support IPv6 for: > - The Management server itself > - Communication with the Hypervisors > - Communication with the System VMs > > Those three are probably the easiest work, we also need to support IPv6 for > instances. > > In both the Advanced and Basic zone Instances should be able to get a non-NAT > true and native IPv6 address. > > We should also not limit them to having one IP, they should be able to get > multiple IPv6 addresses. > > In the basic zone it can be done pretty easily by having the Virtual Router > also hand out IPv6 over DHCPv6 and have your router in the network handle the > gateway work. Technically this is a very sound idea, but scale needs to be discussed. Having static assignments in a database like we do for IPv4 could have potential impact as the address space available is multitudes bigger than in IPv4. Technically one can have 18.446.744.073.709.551.616 hosts in a single /64 network, you don't want to be doing a database query on such a table to lookup the IP for a host. (Not that it's very reasonable to assume this we would ever see networks this size) My thinking was more geared to using SLAAC for determining addressing to get this burden away from cloudstack management server, but this would make other configuration like the firewall a lot more difficult. The other issue with using DHCPv6 is the pseuso addressing that a lot of systems use a the moment, lots of relatively short lived IPv6 addresses on an interface in addition to the one IPv6 address that is based on the modified EUI-64. This might be a feature that we would want to encourage for security reasons, but again this makes firewalls potentially more difficult. > > > In the advanced zone it becomes more difficult. > > One way could be that the network admin creates a static route for a /48 > towards a Virtual Router and then the VR can hand out /64s to Instances. > > But static routing can become a problem, so you might want to use OSPF, LISP > or even iBGP for getting those prefixes to the VR. Not many network admins I know would be comfortable with dynamic routing protocols for this purpose. Especially in a cloud where the number of changes could potentially be very high. (People constantly creating and destroying networks and VR's) This would trigger to much calculations and require serious power of the routers dealing with those networks. With a sizable number of VRs this could cripple the device. Out of the three my vote would be the (i)BGP solution, but I foar more prefer a static setup. The admin prepares a set of "public ip", "route" mappings in the router(s) and the database, CloudStack can then allocate this public ip to a VR and the associated route will be there on the external router to route the traffic. A nice additional feature would be an option to add the external router to the orchestration and dynamically provision and remove the routes. > > This is a big feature, but I think the Basic zone is the easiest for now. I would vote for thinking up a good solution for both and doing the advanced zone in one go. But that is very simply because my use case is for advanced networking together with IPv6, we do not use basic networking in any of our deployments. > > In the Advanced Zone you COULD keep everything behind the VR IPv4 and have > the VR do IPv6 loadbalancing, but that would still not be true IPv6 > connectivity. This is probably not a good idea :-) In my experience this will work, but give all kinds of unexpected failures (like protocols where the IP is passed inside the protocol). Think about the application that is connected on an IPv4 socket but receives (or is requested to return) an IPv6 addy in the protocol. > > NAT in the VR seems like a firewall, but a true statefull firewall in the VR > could do the same while the Instances still have publicly routeable IPv6 > addresses. I think we should focus on true statefull firewalls. This would encourage people to think more on security and allows the use of IPv6 privacy extensions right from the host. > > There is no functional spec on this yet, but we have to keep this in mind > that we need IPv6 support. People are running out of IPv4 space. What would be considered a functional spec? I think that there are more than enough use cases to which I can add my personal use case that I can't get an IPv4 allocation to extend the public ip range on one of my clouds at the moment. The shortage is real and causing problems for me already. That said, simply enabling IPv6 will not "fix" the problem until there is a widespread adoption of IPv6 by endusers. Still let's not play the chicken and egg game, but fix IPv6 in CloudStack and take the lead. > > 3 UI / UX Requirements > All fields (input fields and display fields) that take IP Addresses would > need to support both IPv4 and IPv6 I think it's bigger than this. Do we need service offerings to tell if a network should have IPv6, IPv4 or both? In that case we need to be able to tell what kind of addressing needs to be configured and how. Depending on the solution we choose we need configuration for the static routes and mappings to public addresses. It probably also ties in with the multiple address per nic configuration and this also has UI implications. We would need configuration screens to configure privacy extensions (ipsec, replacing the VPNs). Firewall configurations will become more complex and might need additional screens for IPv6 statefull firewall configuration. Also the exisiting network configuration might need to be tuned to the type of networking, we don't need to give the user the possibility to configure portforwarding on an IPv6 only network for example. In addition simple stuff like the count for available public IP addresses might need to be revisited to make the difference between IPv4 and IPv6 clear in the UI. > > 4 Upgrade Scenarios > Following upgrade scenarios should be supported: > > No upgrade scenarios need to be handled, as this is a new functionality. We might need to consider a scenario where a user might want to add IPv6 support to an existing network. If we change service offerings to determine support for IPv4 or IPv6 we need to convert existing network offerings to support IPv4. > > -----Original Message----- > From: Manan Shah [mailto:manan.s...@citrix.com] > Sent: Wednesday, December 19, 2012 8:13 PM > To: cloudstack-dev@incubator.apache.org > Subject: [ASFCS41] IPv6 Support > > Hi, > > I would like to update the existing JIRA ticket on IPv6 support and I have > also > added a requirements page to track this feature. Please provide feedback on > the requirements. > > JIRA Ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-452 > Requirements: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+Support+in > +CloudStack > > Regards, > Manan Shah
