How to use flexible IP addresses with Instances

This page provides guidance on using flexible IP addresses with your Scaleway Instances.

When creating an Instance, you have options for network connectivity:

• Flexible routed IPv4 addresses: public IPv4 addresses routed directly to your Instance.
• Flexible routed IPv6 addresses: public IPv6 prefixes routed directly to your Instance.

Flexible IP addresses can be managed independently of any Instance. You can attach and detach them from any of your Instances and maintain multiple flexible IP addresses in your account simultaneously. They facilitate live migration of IP addresses between your Instances.

You can assign up to five (5) flexible routed IP addresses to each Instance.

Before you startLink to this anchor

To complete the actions presented below, you must have:

• A Scaleway account logged into the console
• Owner status or IAM permissions allowing you to perform actions in the intended Organization
• An Instance

How to detach a flexible IP address from an InstanceLink to this anchor

Detaching your Instance’s flexible (public) IP address cuts any ongoing public connection to the Instance. This feature gives you a lot of control if, for example, you want to put your Instances into a Private Network so that they can communicate between themselves without being exposed to the internet. This is particularly useful for Instances hosting databases, backups, or sensitive content. It also allows you to optimize your costs and fight the global IPv4 shortage.

1. Click Instances in the Compute section of the side menu. The Instances page displays.
2. Click the Instance whose IP address you want to detach. The Overview page for that Instance displays.
3. Click Detach next to Public IP.
4. Click Detach IP on the pop-up that asks you to confirm the action.
   Tip

   You can also detach a flexible IP by following step 1 above, then clicking on the Flexible IPs tab. From here, click «See more Icon» next to said Instance, and click Detach flexible IP from Instance.

How to create a new flexible IP addressLink to this anchor

1. Click Instances in the Compute section of the side menu. The Instances page displays.

2. Navigate to the Flexible IPs tab.

3. Click Create flexible IP. The flexible IP creation wizard displays.

4. Complete the following information in the wizard:

   • Choose an Availability Zone, which is the geographical region where your flexible IP will be created.
   • Optionally, select the Instance to which you want to attach this new flexible IP. You can only choose from Instances that do not already have a flexible IP attached to them.
   • Check the Estimated cost for the flexible IP.

5. Click Create flexible IP to finish.

   You are taken to the list of your flexible IPs, where the new flexible IP address you just created now appears.

How to attach an existing flexible IP address to an InstanceLink to this anchor

1. Click Instances in the Compute section of the side menu. The Instances page displays.
2. Navigate to the Flexible IPs tab.
3. Click «See more Icon» next to the flexible IP that you want to attach to an Instance. In the drop-down menu that opens, click Switch Instance.
   Note

   This option will only be clickable if you have existing Instances with no flexible IPs attached to them.

4. Confirm the Instance that you want to attach to this flexible IP in the pop-up window, and click Attach flexible IP to Instance.

How to delete a flexible IP addressLink to this anchor

When you no longer want one of your existing flexible IP addresses, you can delete it from your account, which releases it to be used by other users.

1. Click Instances in the Compute section of the side menu. The Instances page displays.

2. Navigate to the Flexible IPs tab.

3. Click «See more Icon» next to the flexible IP that you want to delete. In the drop-down menu which opens, click Delete.

4. Confirm that you want to delete the flexible IP in the pop-up window which opens, by clicking Delete flexible IP.

   The flexible IP is deleted. If it was attached to an Instance, that Instance now has no public IP address.

Flexible IPv6Link to this anchor

About routed IPv6Link to this anchor

Since mid 2023, we built a new network stack for Scaleway Instances to enable new features. One of those is the ability to have flexible/reserved IPv6 whose main purpose is to allow to keep the same IPv6 whenever you stop/start your Instance.

Before routed IPs, IPv6 addresses were statically routed to the hypervisors, which means your IP changed depending on which hypervisor your Instance was running on.

IPv6 prefix and SLAACLink to this anchor

Now, let’s dive into the routed IPv6. Whenever you book a routed_ipv6 IP type, you get assigned a full IPv6 prefix of 64 bits in length. According to section 2.4 of the RFC4291, except for a few prefixes, anything is a Global Unicast address type. Today’s best practice is to provide a /64 prefix.

Another reason we decided to provide you with a /64 prefix is to be able to use SLAAC as the configuration mechanism. But SLAAC has been designed to work exclusively with /64 prefixes.

We chose SLAAC over DHCPv6 because it doesn’t require any client-side configuration in most cases, allowing the feature to work with old Instances too.

LimitationsLink to this anchor

As you may have already noticed, there are some limitations to this design that we tried to minimize.

The first one is that, in order not to break already deployed SDKs, or CLIs, we had to introduce a new prefix field to the /ips endpoint:

        {
            "address": null,
            "id": "153e451e-866b-4f58-9241-3bdbe98a0175",
            "ipam_id": "a81665be-0059-431f-bf44-8d7bdf1dac01",
            "organization": "8e214357-66e2-43ee-8898-0da03fd869e2",
            "prefix": "2025:bd8:911::/64",
            "project": "8e214357-66e2-43ee-8898-0da03fd869e2",
            "reverse": null,
            "server": null,
            "state": "detached",
            "tags": [],
            "type": "routed_ipv6",
            "zone": "fr-par-1"
        }

On the other hand, the /servers/<id> endpoint provides the public_ip (deprecated) field and its replacement public_ips. This struct also contains an address field of type IP that does not accept a prefix:

[
  {
    "id": "e37b038d-c5f7-4fc7-8ac2-407807f723dd",
    "address": "2025:bd8:911:46:dc00:ff:fe08:ab0c",
    "dynamic": false,
    "gateway": "fe80::dc00:ff:fe08:ab0c",
    "netmask": "64",
    "family": "inet6",
    "provisioning_mode": "slaac",
    "tags": [],
    "state": "attached",
    "ipam_id": "45791fdb-c576-4447-985b-19b45740714b"
  }
]

Instead, we return the SLAAC address based on the EUI-64 of the interface.

One consequence is that, if you move your routed_ipv6 prefix to another Instance (hence, with another MAC address), the public_ips list will show you a different address because its EUI-64 will differ.

WorkaroundLink to this anchor

Since the whole /64 prefix is routed to your Instance, it is possible to define a second IPv6 address within the prefix that may be used to reach your Instance. However, this requires some custom settings.

In order to do that, we will use the cloud-init mechanism to define the second IPv6 address.

Let’s say your prefix is: 2025:bd8:911::/64

We will use the following /128 address within this range: 2025:bd8:911:a7f1::1/128.

The cloud-init configuration can be uploaded with the Scaleway CLI:

scw instance server update <SERVER_UUID> cloud-init=@ipv6-cloud-init.txt

Debian >= 11 and Ubuntu >= 20.04Link to this anchor

First of all, create a file with the following content:

cat << EOF > ipv6-cloud-init.txt
#cloud-config
write_files:
  - path: /etc/netplan/100-ipv6-config.yaml
    owner: root
    permissions: '0400'
    content: |
      network:
          ethernets:
              ens2:
                  addresses:
                  - 2025:bd8:911:a7f1::1/128
runcmd:
  - ['netplan', 'apply']
EOF

This cloud-init configuration file will add the netplan definition of a second IPv6 address within the /64 prefix (you can choose any /128 contained in your prefix). It will then apply the netplan configuration so the new IPv6 address becomes available.

CentOS Stream 9, AlmaLinux >= 8 and RockyLinux >= 8Link to this anchor

For CentOS Stream 9, AlmaLinux >= 8, and RockyLinux >= 8, you must interact with NetworkManager instead of netplan.

cat << EOF > ipv6-cloud-init.txt
#cloud-boothook
#!/bin/sh
if ! nmcli connection show | grep eth0-ipv6; then
  nmcli connection clone --temporary "System eth0" eth0-ipv6
  nmcli connection modify eth0-ipv6 +ip6 2025:bd8:911:a7f1::1/128
else
  sleep 10
fi
nmcli connection up eth0-ipv6
EOF

FedoraLink to this anchor

Fedora also uses NetworkManager but with different configuration names.

There is also a little change between Fedora 40 and 41. The following cloud-init configuration is built for Fedora 40:

cat << EOF > ipv6-cloud-init.txt
#cloud-boothook
#!/bin/sh
if ! nmcli connection show | grep eth0-ipv6; then
  nmcli connection clone --temporary "cloud-init eth0" eth0-ipv6
  nmcli connection modify eth0-ipv6 +ip6 2025:bd8:911:a7f1::1/128
else
  sleep 10
fi
nmcli connection up eth0-ipv6
EOF

And the following one is built for Fedora 41:

cat << EOF > ipv6-cloud-init.txt
#cloud-boothook
#!/bin/sh
if ! nmcli connection show | grep eth0-ipv6; then
  nmcli connection clone --temporary "cloud-init eth0" eth0-ipv6
  nmcli connection modify eth0-ipv6 +ip6 2025:bd8:911:a7f1::1/128
else
  sleep 10
fi
nmcli connection up eth0-ipv6
EOF