Routable IPV6 with prefix Delegation

Hi, all. I have seen some older topics on the subject, but I thought that things have changed a lot in the past couple of years, and it would be good to have an authoritative thread for reference.

QUESTION

I have a working Incus installation, Version 6.2-202405310557-ubuntu24.04

I have an ISP that provides me with a /60 prefix delegation. I have a Unifi Router that can carve my internal networks into routable IPv6 ranges.

I would like for my Incus hosted containers and hosts to receive routable IPv6 addresses, and would like to have one of my internal networks to be reserved for the Incus network.

I can think of three basic ways for this to occur, but I’m not sure if there are any pros and cons or whether any of them are officially supported or documented.

POSSIBLE ANSWERS

1. Configure the linux host running the Incus Server to request a prefix from my home router, and apply it to the incus bridge.

I’m not sure if this is a built-in feature, but possibly some existing linux utilities could be cobbled together to automate this piece. Of the three, this might be the simplest, but it requires my home router to delegate a prefix to another device inside the network, and I’m not sure if it supports that.

The biggest downside that I see is that would make clustering difficult or impossible, since only one host would have the delegated ipv6 network.

2. Configure OVN to be obtain the prefix and configure Incus to managed the addresses on behalf of the hosted containers/VMs.

I expect that OVN would provide this kind of feature out of the box, and aside from the steep learning curve associated with configuring OVN, this would probably be the most effective long term solution. In addition, if I wanted to perform clustering, this would probably be the only option.

It also requires my home router to delegate a range internally

3. Option 3 is to not have an Incus managed network, but create a VLAN for the Incus network on my home router, and have the Incus managed nodes get their addresses from the router directly by leveraging the VLAN.

This wouldn’t require my home router to do anything special for internal prefix delegation, but would be the most complex from an Incus perspective, I suspect.

SUGGESTIONS?

Are there any official guides on this topic, or has anyone gotten it working that can share what they did? I’m happy to go do the research and update this thread with my findings if anyone can point me in the right direction.

Thanks!

  1. would definitely be the easiest of the bunch.

If you get a VLAN tag to your machines and are fine with the containers not being able to talk to their host, you can pretty trivially handle that with macvlan across your cluster.

incus network create public --type=macvlan parent=enp5s0 --target server1
incus network create public --type=macvlan parent=enp5s0 --target server2
incus network create public --type=macvlan parent=enp5s0 --target server3
incus network create public --type=macvlan vlan=1234

Assuming that the network interface is enp5s0 on all three servers and your VLAN id is 1234.

If it’s important to you that instances can interact with their host, then you’d need to create a bridge instead which can be done easily enough these days with something like:

incus network create public bridge.external_interfaces=enp5s0.1234/enp5s0/1234 --target server1
incus network create public bridge.external_interfaces=enp5s0.1234/enp5s0/1234 --target server2
incus network create public bridge.external_interfaces=enp5s0.1234/enp5s0/1234 --target server3
incus network create public ipv4.address=none ipv6.address=none

That again assumes enp5s0 on all three servers with the VLAN being 1234.
In this case it will create a new bridged interface on all 3 servers named public and then will create a enp5s0.1234 interface for VLAN ID 1234 on interface enp5s0 and then place that inside of the bridge.

IPV4/IPv6 is disabled at the Incus level given that your router will be acting as the gateway and DHCP server.

1 Like

Thanks, @stgraber I will try this and report back!