incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hugo Trippaers <>
Subject RE: [ASFCS41] IPv6 Support
Date Wed, 02 Jan 2013 09:01:34 GMT

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.
> 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
> 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 []
> Sent: Wednesday, December 19, 2012 8:13 PM
> To:
> 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:
> Requirements:
> +CloudStack
> Regards,
> Manan Shah

View raw message