Configure the routed IPv6 /64

What “routed” means here

The prefix is routed to your instance rather than shared on a segment with other customers. Nothing else on the network answers for those addresses, there is no neighbour discovery proxy in the middle, and you may bind anything inside the /64 without asking first. It also means router advertisements are not the mechanism: address and gateway are static, and waiting for SLAAC will get you nothing at all.

The panel prints three values per instance — the prefix, the address inside it we pre-assign, and the gateway. Take all three from there. The gateway differs by site.

Debian 13

The images use systemd-networkd. Write your own unit and leave the packaged one alone:

cat > /etc/systemd/network/20-wan-v6.network <<EOF
[Match]
Name=enp1s0

[Network]
Address=<ipv6>/64
Gateway=<gateway6>
IPv6AcceptRA=no
EOF
networkctl reload
networkctl status enp1s0

Where the gateway is a link-local address, the interface it sits on has to be known. The stanza is already scoped to one interface by [Match], so nothing further is needed.

AlmaLinux 10

There are no ifcfg- files any more. AlmaLinux 10 keeps connections as NetworkManager keyfiles, and the supported way to edit them is nmcli:

nmcli -f NAME,DEVICE connection show
nmcli connection modify "System eth0" ipv6.method manual ipv6.addresses <ipv6>/64 ipv6.gateway <gateway6> ipv6.may-fail no
nmcli connection up "System eth0"

ipv6.may-fail no stops the boot declaring the network ready before v6 is configured. That matters for any service that binds a v6 address at start and gives up if it is not there yet.

Check it

ip -6 addr show dev enp1s0
ip -6 route show
ping -6 -c 3 paragonvps.com

Address present, default route present, nothing answering? The firewall is the usual culprit, and ICMPv6 is the usual reason. Neighbour discovery and packet-too-big both live in ICMPv6; filtering them selectively breaks IPv6 in a way that looks exactly like an application bug for a day and a half. Small packets work, large ones vanish. The nftables article has a rule that does not do this.

Using the rest of the prefix

Extra addresses on the same interface:

ip -6 addr add <ipv6-2>/64 dev enp1s0 nodad

Make it survive a reboot with another Address= line, or a second entry in ipv6.addresses. For containers, carve a slice out of the /64, assign it to the bridge and route it on the host. A /80 is more than any bridge will ever need. There is no NAT step and no proxy step, because the whole prefix already points at you.

If you need several routed subnets, behind several bridges or a nested hypervisor, order the /48 add-on. It is delegated rather than proxied, so the routing design on your side is genuinely yours.

Two things that quietly break it

• Something turning RA acceptance back on. Tools that “fix” networking often do, and you end up with a second default route that flaps between the two. Pin IPv6AcceptRA=no.
• Enabling forwarding. Setting net.ipv6.conf.all.forwarding=1 makes the kernel stop processing router advertisements on every interface. Harmless here, since RA is already off, but worth knowing before you blame the site.

Full per-site detail, including which locations carry v6 to the edge, is on the network page.