Learn how to configure an Additional IPv6 address block within a vRack network.
The vRack network serves as a global private network bridging various OVHcloud products, enabling the creation of sophisticated network solutions. Beyond facilitating private connections, it also supports routing public IP addresses.
Introduction
IPv6 revolutionizes networking within OVHcloud's vRack by addressing IPv4's limitations and introducing features for the modern internet. Its rollout is a direct response to the need for more extensive, secure, and sophisticated internet architectures. Here are the key benefits of integrating IPv6 with vRack:
-
Flexibility for Advanced Networking: IPv6 significantly increases the address space, providing the flexibility needed to scale infrastructure, manage failover scenarios, and support larger solutions. This ensures that networks can grow and adapt without the space constraints of IPv4.
-
Hierarchical Routing and Segmentation: IPv6 enables efficient hierarchical routing and logical infrastructure segmentation. This improves network manageability and security, ideal for reselling VMs with dedicated subnets or organizing infrastructure into distinct segments.
-
Low latency: Native, end-to-end IPv6 connectivity can be an enabler for latency-sensitive services like media streaming, as many recent provider networks are built IPv6-native. In such networks, using IPv4 services brings additional latency (and costs).
By leveraging IPv6 within vRack, OVHcloud users can enjoy a more secure, efficient, and scalable network environment, ready to meet the demands of modern internet usage.
Requirements
- a vRack service activated in your account
- a vRack-compatible server attached to your vRack network
- the details of your server's private interface (see this guide for instructions on how to find it)
- access to the OVHcloud Control Panel
Instructions
Obtaining a new Additional IPv6 block
While requesting a new Additional IPv6 block, it's important to note that the allocation is regional. This means the IPv6 block you receive will be tied to a specific region, defining where public traffic enters your vRack network (thus, where the gateway is located).
▼ Order an Additional IPv6 block
From the OVHcloud Control Panel:
- Select
Bare Metal Cloudfrom the top navigation bar. - In the left-hand menu, choose
Networkand thenIP. - Click
+ Order IPs.
On the following screen, select IPv6. Complete the process by following the instructions and your new Additional IPv6 will be available on your vRack configuration page.
Configuring IPv6 in a vRack (basic mode)
This section will present a basic IPv6 setup for your vRack-connected hosts.
The example above shows two hosts with their vRack-side interfaces configured with IPv6 public addresses. One host is configured manually, while the other has an IP address assigned automatically using SLAAC. All IP addresses belong to the first /64 subnet from a given public /56 Additional IPv6 block. Both leverage the vRack interface for public IPv6 connectivity.
▼ Via the OVHcloud Control Panel
Go to Network, vRack private network, and select the vRack you want to manage.
The left block shows services eligible for configuration and the right side shows services already configured with your vRack.
Select your new Additional IPv6 and Add > it to your vRack.
Static IP configuration
Once the Additional IPv6 /56 block is attributed to a vRack network, there is a /64 subnet bridged with it.
This means you can easily use such IPs on your hosts with static IP configuration on vRack interfaces (see the next section for a host-side configuration example).
Automatic IP configuration (SLAAC)
To simplify IP addressing inside your network, you may want to use SLAAC. It can be enabled per-bridged-subnet only and can be enabled for the /64 of your block (this one is always bridged) at any time using the slider button.
Don't forget to configure SLAAC on your host machine.
▼ Via APIv6 (alternative way)
When you request an Additional IPv6, it is automatically assigned to your vRack. If you removed this new Aditional IPv6 from your vRack, you can assign it again using this command:
POST /vrack/{serviceName}/ipv6
Enter your vRack's serviceName and replace "block": with your block's IP address. Then click TRY.
You can verify it with the GET /vrack/{serviceName}/ipv6/{ipv6} API call.
Enter your ipv6 and your vRack's serviceName. Then click TRY.
Static IP configuration
Once the Additional IPv6 /56 block is attributed to a vRack network, there is always a /64 subnet that is bridged with it. This means you can easily use these IPs on your hosts. To see exactly which subnet is bridged, use the following API call:
GET /vrack/{serviceName}/ipv6/{ipv6}/bridgedSubrange
To get more details, use the following call:
GET /vrack/{serviceName}/ipv6/{ipv6}/bridgedSubrange/{bridgedSubrange}
In the results, note that IP autoconfiguration (SLAAC) is turned off by default.
Automatic IP configuration (SLAAC)
To simplify IP addressing inside of your network, you may want to use SLAAC. It can be enabled per-bridged-subnet only and can be enabled with the following API call:
PUT /vrack/{serviceName/ipv6/{ipv6}/bridgedSubrange/{bridgedSubrange}
Do not forget to configure SLAAC on your host machine.
Host-side commands
▼ Static IP configuration
In a basic configuration, you may want to set up an IP address and routing manually. This is also the suggested way when your machine acts as a router (see configuring routed subnet) and has ipv6.forwarding mode enabled.
First, let's add an IP address on the vRack interface (in our example "eth1"):
(Please note that the first IP address in a block, 2001:41d0:abcd:ef00::1/64 is gateway IP address and must not be used for host addressing).
Optionally, if you want to use the vRack interface as the main one for IPv6 traffic, the default route can be configured the following way:
Finally, bring up the interface (and verify the configured IP on it):
▼ Automatic IP configuration (SLAAC)
To use automatic configuration, please ensure you have configured your interface as follows:
First, let's allow our host to accept Router Advertisements (for autoconfiguration) on the vRack interface (in our example "eth1"):
Important to note is that this setting will not work if ipv6.forwarding is enabled in your system. In such case please refer to Automatic IP configuration for routed subnet for details.
Then, simply bring up the interface:
After a moment (the configuration must propagate), specific IPv6 address (with the flags global and dynamic) should be visible on the interface.
Setup verification
▼ Local
The most basic test is to ping a local IP address on a host:
▼ Remote
Next, let's verify the connectivity from remote:
Configuring an IPv6 in a vRack for routed mode
In this section we will present a more advanced IPv6 setup, where your vRack connected hosts are acting as a routers for hosted Virtual Machines. Such VMs have delegated subnets from the main IPv6 block (presented with an orange color in the schema below).
The traffic path is as follows: Inbound traffic to a given VM (with specified subnet) is routed through the customer's vRack, first to a specified host (with a next-hop address), then using a local link (or vSwitch - black link fd00::/64 on a diagram) to the particular VM. Traffic coming back from such a VM should use the default route via the first part of the local link (black one, fd00::1), then (possibly default) route from a host to its gateway.
For routed subnet definition any prefix size can be used between /57 and /64.
Defined routed subnet
▼ OVHcloud Control Panel actions
Go to Network, vRack private network, select the vRack you want to manage, and click Add >.
On the right, you have an IP section and you can add a new subnet by clicking + Add a subnet.
To create a routed subnet, we must first define:
- subnet in CIDR notation (size between /57 and /64)
- next-hop address (the host's IPv6 address)
Please note that a given subnet can not overlap with any other subnet defined and next-hop address must belong to the first part (bridged /64 subnet) of your Additional IPv6 prefix.
Click Confirm.
This created a routed subnet 2001:41d0:abcd:ef10::/60 that is reachable via next hop 2001:41d0:abcd:ef00::2 IP inside the first (bridged) subnet.
▼ APIv6 commands
To create a routed subnet, we must first define:
- subnet in CIDR notation (size between /57 and /64)
- next-hop address (the host's IPv6 address)
Please note that a given subnet can not overlap with any other subnet defined and next-hop address must belong to the first part (bridged /64 subnet) of your Additional IPv6 prefix.
Use the following API call to define such a subnet:
POST /vrack/{serviceName}/ipv6/{ipv6}/routedSubrange
Here, we defined a routed subnet 2001:41d0:abcd:ef10::/60 which will be delegated to the VM hosted on 2001:41d0:abcd:ef00::2.
Host-side configuration
▼ Static IP configuration for a host (recommended)
When hosting Virtual Machines, we strongly recommend to use static configuration on your host.
Set up an IPv6 address, bring up the interface and (optionally) add the default route over the vRack interface:
▼ Automatic IP configuration (SLAAC) for a host
In some cases, you may want to configure your interfaces with SLAAC and IP forwarding together.
Please note that this brings additional risks (such as losing access not only to the host but also to all VMs) and is not recommended.
Ensuring IPv6 forwarding is enabled:
Configuring Router Advertisements to be accepted (on vRack eth1 interface in our example):
▼ Routed subnet configuration on a host and inside a VM
To ensure that our host knows what to do with packets addressed to the new routed subnet (that will be on a VM), we must add a specific route for it.
In our example this is the veth link with the address fd00::2/64 inside a VM we will use for routing.
Please note that this is very specific to the hypervisor installed (it can be vSwitch or veth interfaces). Please refer to the specific hypervisor networking guide for this setup.
▼ Routed subnet configuration inside a VM
Again, please note that the link used between host and VMs is very specific to the hypervisor installed (it can be vSwitch or veth interfaces). Please refer to the specific hypervisor networking guide for this setup.
Add our routed IP block inside a VM to ensure it can accept packets:
Add the default route on a VM to ensure traffic can get back out of it:
Setup verification
▼ Local, on a host
Ping from the host into the container (using local link):
Ping from the host into the container (using routed subnet):
Check the route to our /60 subnet on a host:
▼ Local, on a VM
First, check the routing table:
Ping host link local interface:
Ping host global interface:
Finally, let's ping an external IPv6 from a VM:
Or, using a domain name:
▼ From remote host
Let's check connectivity to our VM from outside the OVHcloud network:
And traceroute from a remote host (somewhere in the internet):
In this example:
- hop 10 - our host's IP address
- hop 11 - our VM's IP address
Multiple region locations vs. global vRack
OVHcloud's vRack technology enables organizations to connect servers across different locations as if they were located within the same data center. On the other hand, services like Additional IPv6 are regional, which means their functionality is linked to a particular location.
Below, an architecture is presented for learning purposes with two different regions and different Additional IPv6 blocks announced from each. Also, there is a host presented with IP addresses from both networks as well as a suboptimal route example - a host in one region addressed with IPv6 address announced in another region:
Please note that in such setups (with Additional IPv6 from more than single region) SLAAC must be turned off in the whole vRack (as this may lead to unpredictable results and losing connectivity randomly).
Benefits
- Enhanced connectivity: By leveraging a vRack network together with public IP blocks routed in multiple locations, businesses can ensure seamless communication around the globe, regardless of the backend servers' physical locations.
- Move to cloud: vRack technology can be a great enabler of early steps toward a "move-to-cloud" organizational strategy, unblocking some legacy applications that still require local network communication.
Risks and Considerations
- No SLAAC support in multi-location setups: When there is more than one location acting in routing public IP traffic (both IPv4 and IPv6) into the same vRack, Stateless Address Autoconfiguration (SLAAC) should not be used. As an example, let's consider existing hosts using IPv4 addresses. Such hosts are becoming reconfigured automatically by SLAAC with an IPv6 gateway set up from another region. Together with IPv6 prioritization over IPv4 by some Operating Systems, this situation can lead to suboptimal routing or even total loss of connectivity for such hosts.
Known Limitations
Understanding the constraints of using Additional IPv6 within the vRack environment is crucial for effective network planning. Here are the key limitations to consider:
- Additional IPv6 goes only with vRack: Please note that Additional IPv6 addresses can only be configured with vRack-connected backends.
- SLAAC limitations in multi-location setups: Stateless Address Autoconfiguration (SLAAC) is not supported when there is public IP traffic (both IPv6 and IPv4) routed into vRack in multiple region locations.
- Up to 128 hosts inside bridged subnet: You can use up to 128 IP addresses directly on the vRack.
- Up to 128 next-hop routes: You can use up to 128 routes for routed subnets inside a vRack.
- Public bandwidth cap: Outbound traffic from OVHcloud to the internet is capped at 5Gbps per region location.
- IPv6 block allocation limits: Users can obtain up to three /56 Additional IPv6 blocks per region location.
- Mobility of Additional IPv6 blocks: Due to the hierarchical design of the IPv6 address space, Additional IPv6 blocks are region-specific. This means blocks cannot be transferred between regions, although they can be reassigned within any vRack-connected backend.
- No direct VLAN 802.1Q support in vRack by Additional IPv6: Configuration can only be done with the native VLAN of your vRack network. For packet forwarding inside a specific VLAN (of a vRack), a dedicated host on the customer side will be needed.
- APAC regions are not supported for the moment.
Go further
For more information and tutorials, please see our other Dedicated Server support guides or explore the guides for other OVHcloud products and services.