At IOFLOOD, quite a lot of our customers run VPS hosting companies, so we try to be familiar with the technologies and control panels used for VPS hosting. We do this because we want to provide help when our customers face challenging server configuration issues. In today’s article, we’re going to discuss how to configure IPv6 support for SolusVM.
Traditional IPv4 IP addresses have been all-but-unavailable from regional authorities for many years now. This has caused pressure to steadily build for reducing their usage. Meanwhile, the rapid growth of Virtual Private Servers (VPS) and other online services continues unabated. These popular online services require IP addresses to function, and so with the restricted supply and growing demand, something has to give.
IPv6 – the successor to IPv4 – is designed to resolve this problem by providing a huge increase in the number of available IP addresses. IPv6 has existed for many years, but adoption of IPv6 has been slow coming. One reason for this is due to a lack of knowledge and experience in implementing this technology. In today’s article, we aim to address that problem by showing how to implement IPv6 for VPS hosting when using the popular SolusVM control panel.
The good news is, the setup of IPv6 is relatively straightforward if you follow the SolusVM documentation. However, there are a few “gotchas” that this guide can help you navigate. As well, your server provider may require you to set up your IPv6 addresses in one of two specific ways — this guide will help you with each of these scenarios.
There are essentially two ways to implement IPv6 with SolusVM. If you operate your own network, you can select whichever option you find most appropriate for your network and needs. However, if you use dedicated servers to host your VPS nodes, you must configure your services in the way dictated by your dedicated server hosting provider.
The first possibility is that your hosting provider provides you with a large IPv6 subnet, typically a /64, tells you what IP in that subnet to use as a gateway, and provides no restrictions on using multiple mac addresses within this IP space. We call this a “network hosted gateway”, because the default gateway that will be used by your virtual machines, is hosted by the provider’s network switch or router. This is the simplest way to configure IPv6 support, but it can put a heavy burden on the network switch or router, so not all providers will allow this.
In this configuration, IPv6 setup is not much different from the standard way to configure an IPv4 block for use by SolusVM:
Step 1 – Ensure your host node will forward IPv6 properly
By default, the kernel for your VPS host may not be set up to forward IPv6 through it. It is not necessary for the VPS host node to be configured with an IPv6 address. However, the Kernel will still have to be told to forward IPv6 traffic to the VPS’s.
To do this you need to set a few kernel flags for sysctl to handle on boot. Lets create a new file:
SolusVM, as a virtualization control panel, is responsible for assigning IP addresses to the virtual machines you create. For this to work, it needs to be told what IP details are appropriate for this task. So here, you will be taking the IPv6 subnet assigned to you, and configuring it in SolusVM.
Be sure to fill in the following fields with the information provided by your hosting provider:
Whatever name you find convenient or meaningful.
Given to you by your hosting provider
Check this, it is likely your default gateway
Select the subnet size by your hosting provider, usually /64
Normally it is best to just click “Google” or “OpenDNS” to have your VPS’s use those public DNS resolvers.
IPv6 Subnet Block
Uncheck this box when using a “network hosted gateway” like we are here
Select which node(s) this IP block should be used for.
You may have one IPv6 subnet for each dedicated server. If so, check only the box for the specific server the IPv6 block was assigned to.
Or, you might have one IPv6 subnet that is shared between multiple servers.
Step 3 – Generate some usable IPs for your new block.
Just like with a new IPv4 block, you need to add available addresses to your IPv6 pool. Since there are so many possible IPv6 addresses, Solus has a built-in tool for the pool to generate available unique addresses to your block.
You will need to fill in the full IPv6 range except the last two segments (which should be left as “auto), and click “Generate”. This will add 100 available IPv6 addresses to the pool to hand out to your VMs. Simply repeating this step can generate more addresses should you need more.
Step 4 – Setup your existing plans for IPv6
To allow your existing plans to take advantage of your IPv6 block, you have to allow for 1 or more IPv6 addresses during provisioning. Edit your plan and simply fill in the IPv6 Addresses block with how many you’d like to assign to each new VM.
If your hosting provider uses this more basic method, you should be done now! All new VMs should get an IPv6 address and any existing VMs can be edited manually to have an IPv6 address assigned. Keep in mind that if you edit an existing VM to have a new IPv6 address, the guest OS will still need to be configured manually or you will need to use the “reconfigure network” option in the VM control panel to be able to use it.
Type 2: ”Routed subnet” assignment method
The second major way that IPv6 could be implemented, is for your hosting provider to assign you a /64 subnet for use by your virtual machines, and also assign you a smaller “link subnet” such as a /126 for your host server’s primary interface. In this scenario, the /64 subnet would not have a gateway address assigned — the entire /64 subnet is forwarded / routed to a single IP address on the host server using the “link subnet”. Your server would then act as a router, passing traffic to your VMs in the /64 subnet, and back out to your hosting provider using the link subnet.
The reason for this type of configuration is to limit the number of IP addresses that a router needs to keep track of. A /64 subnet can have many billions of IP addresses, and the number of IPs a router can keep track of is usually only a few thousand. Because of this, having a router act as the default gateway can lead to network instability if a large number of IPv6 addresses are used at the same time. By routing the entire /64 as one whole block to your server, this can be avoided. In this scenario, your server keeps track of which VMs are using each IP address, and routing the traffic to your VMs accordingly.
In this type of network configuration, you would do all of the things mentioned above in the more basic scenario, as well as take the following additional steps:
Step 1 – Configure IPv6 addresses from each subnet onto your node
Unlike the basic configuration, in which it is not necessary to have your node configured to actually communicate on IPv6 with an address, this setup will require that you setup your networking to have a local IP address from the link subnet as well as a new “gateway” address from your large block setup on the host node. This is to ensure that your VMs have a target IP for their gateway and your node can communicate with the IPv6 router on the link subnet.
First, assuming your primary IP configuration for your node is on the bridge interface, we need to edit your network configuration file for it.
We need to add the following items to the configuration file.:
IPV6ADDR will be the IP inside of your link subnet, that your large block is static routed to.
IPv6_DEFAULTGW will be the gateway IP your host assigned you, that is within your link subnet.
IPV6ADDR_SECONDARIES will be the gateway address within your large block, that your VMs will be configured to use.
Once this is set, simply restart networking or reboot the node:
$systemctl restart network
Since the large block is static routed to your link subnet IP that is now on your node, the router will static route all IPv6 traffic to your server, so it needs this address to be reachable. This means you can pick any IP from your large block as the new ‘gateway’ for your VMs. For this example we simply use the ::1 address.
Step 2 – Add IPv6 block in SolusVM
This step is also identical to Step 2 in the simple method but the only difference here is that you need to specify the gateway address to be the IP address you set up as the ‘gateway’ on your node. This is what you picked for IPV6ADDR_SECONDARIES value
Using this process, I was able to set up 3 separate nodes with multiple /64 subnets all to provide an IPv6 networking pool to our clients all while keeping the potential heavy resource use off of the switch hardware.
All steps from here will be identical since your large block and link subnet are now set up on the node.
As stated before, these steps have your node handle the neighbor table / address resolution that normally happens on the default gateway. This will take strain off of the network router / switch, and allow for greater overall network scaling.
Following the process above, we were able to easily set up 3 separate nodes each with their own /64 subnet. This allows for providing an IPv6 networking pool to clients all while keeping the potential heavy resource use off of the switch hardware.
Whether your network requires the traditional “network hosted gateway” method or the ”routed subnet” assignment method, the steps above should have you in good shape.
I hope that this article has provided a useful rundown of how to implement IPv6 for your VPS customers using SolusVM. At IOFLOOD, we strive to provide “high impact help” like this, where we can leverage our knowledge to quickly solve customer problems in minutes that would take them hours or days to resolve on their own. Being an unmanaged host helps keep prices low for customers who can handle most things on their own, while we also do our best to provide help for common issues. This offers the best of both worlds for those customers who only need occasional assistance.
If that’s the type of hosting provider you’d like to do business with, please get in touch! We can be reached at sales[at]ioflood.com, or, take a look at our available servers on our homepage