IPv6 SLAAC (autoconfig) for "management" only ?

vom513

New Member
Feb 18, 2024
4
4
3
Kind of hard to make a succinct title for what I'm trying to ask.

I have my PVE with vmbr0 and a static IPv4. I use this for management. None of my other vmbr*'s have any IPs at all (they are pure layer 2 for guests). I do have RAs coming in these VLANs as I have multiple segments here.

I see in the config, there doesn't seem to be a way to say auto/SLAAC. It seems like the GUI just wants a static address for IPv6.

I do know how to set this in /etc/network/interfaces. However with setting nothing, I noticed a random vmbr interface was configuring a SLAAC address from that VLAN.

Is there a way to lock this down to just SLAAC on vmbr0 ? So far the behavior of IPv6 on PVE itself seems kind of all over the place.

Should I manually put:

iface vmbr0 inet6 auto ??

Or do I need to fool with sysctl and turn off RA reception on all except vmbr0 ?

Thanks in advance for any info.
 
You are right about using iface vmbr0 inet6 auto in your interface file and you have to accept RA net.ipv6.conf.vmbr0.accept_ra=2 in your sysctl.conf file

I wrote a blog post for using IPv6 in Proxmox. https://saudiqbal.github.io/Proxmox/proxmox-IPv6-interface-setup-DHCPv6-or-static.html

Thanks for the reply. After posting this I also found this:

https://forum.proxmox.com/threads/ipv6-address-on-all-interfaces.122790/

Seems like the same thing I'm hitting as well.

Edit: the sysctls didn't seem to work for me. I appreciate your blog post but it seems that's for static and DHCP only (not SLAAC).

Also accept_ra=2 is really only for if your machine is also a router (ipv6 forwarding). A value of 1 should work in this case.

For now I just have it disabled on everything except loopback.

I tried disabling ipv6 globally (i.e. via GRUB config) but It seems like there is a constant spam in the logs about ip6tables with this config:

Code:
Feb 18 11:32:29 pve01 pve-firewall[1294]: status update error: iptables_restore_cmdlist: Try `ip6tables-restore -h' or 'ip6tables-restore --help' for more information.
Feb 18 11:32:40 pve01 pve-firewall[1294]: status update error: iptables_restore_cmdlist: Try `ip6tables-restore -h' or 'ip6tables-restore --help' for more information.
Feb 18 11:32:49 pve01 pve-firewall[1294]: status update error: iptables_restore_cmdlist: Try `ip6tables-restore -h' or 'ip6tables-restore --help' for more information.
Feb 18 11:32:59 pve01 pve-firewall[1294]: status update error: iptables_restore_cmdlist: Try `ip6tables-restore -h' or 'ip6tables-restore --help' for more information.
Feb 18 11:33:09 pve01 pve-firewall[1294]: status update error: iptables_restore_cmdlist: Try `ip6tables-restore -h' or 'ip6tables-restore --help' for more information.
Feb 18 11:33:19 pve01 pve-firewall[1294]: status update error: iptables_restore_cmdlist: Try `ip6tables-restore -h' or 'ip6tables-restore --help' for more information.

So I reverted that and am just using the sysctls. Seems like the log spam has stopped now.

I'm guessing multiple vmbr's receiving RAs from different subnets/segments isn't something the Proxmox team has tested. Hopefully one day there will be some knobs to more elegantly control this.
 
Last edited:
  • Like
Reactions: Jeffthomson890
I was able to get ipv6 working on my Proxmox host because of this topic and the linked topic! So thank you to both of you and the people in the other topic!

This is what I have in my sysctl configuration which I got from the linked topic.
Code:
# Disable IPv6 and RA on all interfaces
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.all.accept_ra = 0


# Enable IPv6 on Loopback/vmbr0 and RA on vmbr0
net.ipv6.conf.lo.disable_ipv6 = 0
net.ipv6.conf.vmbr0.disable_ipv6 = 0
net.ipv6.conf.vmbr0.accept_ra = 2
For the value accept_ra I used 2 as @encryptedserver mentioned because with value 1 as mentioned in the linked topic my host wouldn't get a public ipv6 adress. I'm using SLAAC as far as I know because I don't have DHCPv6 configured.

For my /etc/network/interfaces I have this set.
Code:
iface vmbr0 inet6 auto
 
Last edited:
What about setting following in /etc/network/interfaces:
Code:
iface vmbr0 inet6 auto
        accept_ra 2
        autoconf 1
Will it work and is `autoconf` needed?

Update:
I added above 3 lines in /etc/network/interfaces which wasn't enough. I had to create a file named /etc/sysctl.d/99-proxmox-host-ipv6-slaac.conf :
Code:
net.ipv6.conf.vmbr0.accept_ra = 2
 
Last edited:
  • Like
Reactions: Jeffthomson890
I followed this here:

https://blog.khmersite.net/p/configure-ipv6-for-proxmox-host-via-slaac/

this did work simply with adding the following on Proxmox 9.2.3:

Code:
iface vmbr0 inet6 static auto
        accept_ra 2

with a `ifreload -a` to apply the config.

The new addr looks like:
Code:
4: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.2/24 scope global vmbr0
       valid_lft forever preferred_lft forever
    inet6 2a02:xxx/64 scope global dynamic mngtmpaddr proto kernel_ra
       valid_lft 86396sec preferred_lft 86396sec
    inet6 fe80::xxx/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever

this allows the proxmox hypervisor to do system updates using ipv6.
 
  • Like
Reactions: Jeffthomson890
Thanks for sharing the update. It's helpful to see that accept_ra = 2 together with iface vmbr0 inet6 auto is still working on newer Proxmox versions.


One thing I noticed while testing SLAAC in a multi-VLAN environment is that Router Advertisements can easily lead to unexpected IPv6 addresses being assigned if RA reception isn't restricted to the intended management bridge. Limiting accept_ra to vmbr0 and disabling it on the remaining bridges made the host behavior much more predictable in my setup.


It's also interesting that newer versions seem to accept the configuration directly in /etc/network/interfaces, although I would still verify the effective sysctl values after every upgrade since networking behavior can change between releases.


Thanks to everyone for documenting their configurations—it makes troubleshooting much easier.