IPv6 Support for Isolated and VPC Networks l CloudStack Feature First Look

The IPv6 protocol is a much-needed next step in the world of the Internet and networking in general. With the depletion of publicly routable IPv4 addresses, most providers will need to switch to IPv6, which not only provides a much bigger address space but also offers many other advantages over IPv4, such as improved security, efficient routing, better QoS, etc.

For a long time, Apache CloudStack has offered IPv6 support solely for Shared Networks. This will change with Apache CloudStack 4.17.0 LTS, which will add IPv6 support for isolated networks and VPCs making it possible for users to deploy dual stack networks. Initially only static routing will be supported, with dynamic routing in the roadmap for a future release. With that in mind, once an IPv6 enabled network is deployed, the cloud administrator will need to configure routing entries in the upstream network router, a process which can be automated with the help of CloudStack Event Notification framework.

Support for IPv6 for isolated networks and VPCs can be summarized into 3 broad steps:
• Configure CloudStack Zone to support IPv6 Networks (root admin)
• Adding Network and VPC Offerings with IPv6 support (root admin)
• Deploying Isolated and VPC Networks with IPv6 support (regular user)

Configuring a CloudStack Zone to support IPv6 Networks

The outside network is defined by specifying an IPv6 subnet along with its gateway and the desired VLAN, this can be done by adding a new IP range for the “Public” Traffic in the Physical Network of the CloudStack Zone (please note that by “Public we mean the outside interface of the ACS Virtual Router), this network must be a /64. As CloudStack only supports dual stack networks (both IPv4 and IPv6) and doesn’t yet support pure IPv6 networks, the IPv6 range must be added in the same VLAN as an existing IPv4 range.

In order to control the CloudStack Guest Network an IPv6 prefix with CIDR size of /64 (or larger) must be configured in ACS by adding a new IPv6 Prefix to the desired Zone. IPv6 Prefixes can be added for the Guest Traffic Type in the Physical Network of the CloudStack Zone. CloudStack will use this prefix to further split and allocate /64 IPv6 CIDRs to the Guest Networks. A larger IPv6 subnet enables CloudStack to create more IPv6 Guest Networks for the end users. Also, a set of new APIs – createGuestNetworkIpv6Prefix, deleteGuestNetworkIpv6Prefix and listGuestNetworkIpv6Prefixes have been added to facilitate this.

Adding Network and VPC Offerings with IPv6 support

Once the Public and Guest Physical Networks are configured, the root admin needs to create Network and VPC offerings with IPv6 support. In order to enable Network and VPC offerings with IPv6 support, the cloud admin must set the CloudStack Global Settings ipv6.offering.enabled to true.  When adding a Network or VPC Offering with IPv6 support, the root admin can select IPv4 + IPv6 (Dual Stack) in the Internet Protocol Session of the form.

In order to enable IPv6 in VPC networks the same must be selected for the VPC offering, together with the VPC option.

A new parameter – internetprotocol has been added in createNetworkOffering and createVpcOffering APIs to allow this.

Deploying Isolated and VPC Networks with IPv6 support

When deploying a new Isolated or a VPC Network users can use the Network and VPC Offerings with IPv6 support. When subnetting a VPC with IPv6 support the user must select a Network Offering for VPC with IPv6 enabled, no additional actions are required from the user. However, in order to allow network and instances to connect to the internet, the administrator must configure static routes in the upstream router pointing back to the Isolated or VPC networks via the Public (outside) IP of the ACS Virtual Router. Both VPCs and isolated networks list out the IPv6 routes that need to be configured.

Pre-existing IPv4 Isolated Networks and VPC tiers can also be migrated to dual stack by changing their Network Offering to an IPv6 enabled Offering. Such a change in offering will only work when the CloudStack zone has been assigned an IPv6 IP range in the same VLAN as the IPv4 address used by the network.

This feature also allows setting up IPv6 firewall rules for isolated networks and ACL rules for VPC tiers.

Configuring IPv6 Firewall rules for isolated networks

In order to configure IPv6 Firewall rules for an Isolated Network a new tab named IPv6 Firewall has been added in the UI. Both ingress and egress rules can be configured and, additionally to the UI, a new set of APIs (createIpv6FirewallRule, deleteIpv6FirewallRule, updateIpv6FirewallRule, listpv6FirewallRules) can be used in order to configure the Firewall. The default egress rule for IPv6 traffic is inherited from the default egress policy of the network offering used by the network.

IPv6 ACL rules for VPC tiers

Working with IPv6 ACL rules for VPC tiers is even simpler. Like IPv4 ACL rules, new IPv6 ACL rules can be added or pre-existing ACL rules can be updated by specifying IPv6 CIDRs in the ACL rules list. When using the default ACL rules list – default_allow and default_deny it should be noted that they do not contain any IPv6 rules and the behaviour in this case for the network tier is to block all IPv6 traffic.

Conclusion

With this new feature IPv6 support in Apache CloudStack has been extensively enhanced. It allows CloudStack operators to seamlessly migrate to IPv6 and offer IPv6 networking services to their users. It gives a good amount of control for them to enable IPv6 isolated networks and VPCs for desired use-cases and user-base. They can control access to IPv6 enabled offerings using zone and domain parameters for network and VPC offerings. For end-users the deployment of networks remains as-is, all that is needed in order to deploy an IPv6 enabled network is for the end-user to choose an IPv6 enabled offering during the deployment of their networks or while updating networks for new offerings. These changes are a part of the recent 4.17.0 LTS release.

Related Posts:

Apache CloudStack enables existing VMware users and gives an easy way for service providers to migrate to a fully open-source solution and eliminate vendor dependency.