IPv6 SLAAC (autoconfig) for "management" only ?

[vom513]

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.

 

[encryptedserver]

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

 

[vom513]

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:

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.

 

[V3nom]

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.

# 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.

iface vmbr0 inet6 auto

 

[anutrix]

What about setting following in /etc/network/interfaces:

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 :

net.ipv6.conf.vmbr0.accept_ra = 2

 

[fmaurer]

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:

iface vmbr0 inet6 static auto
        accept_ra 2

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

The new addr looks like:

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.

 

[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.

 

[callMeConnor]

ok, just had this issue, maybe in a littlebit different setup - as this forum was a helpful resource in fixing, here my notes (markdown)on what I observed today:

# Proxmox vmbr0 IPv6 (SLAAC) — working config & issue notes

## TL;DR — what works

1. **IPv4 must be static** on `vmbr0` — a bug/feature (?) (see below) makes ifupdown2
   treat both IPv4 and IPv6 with DHCP. Logically unexpected: different network protocols
   with different config options, but both end up on DHCP.
2. **IPv6 via SLAAC** (`inet6 auto` + `accept_ra 2` + `autoconf 1` in the stanza).
3. **Sysctls must be persisted** in `/etc/sysctl.d/` for **both** `nic0` (bridge port)
   and `vmbr0`. The stanza-level `accept_ra 2` is a separate ifupdown2 option that
   does not enforce the sysctl setting - the kernel parameter must be set independently.

## Working `/etc/network/interfaces`

```bash
auto lo
iface lo inet loopback

# The physical interface must be defined as manual to be used in a bridge
iface nic0 inet manual

# The bridge interface
auto vmbr0
iface vmbr0 inet static
    address 192.168.178.150/24
    gateway 192.168.178.1
    bridge-ports nic0
    bridge-stp off
    bridge-fd 0
iface vmbr0 inet6 auto
    accept_ra 2
    autoconf 1
```

## Persisted sysctl settings (`/etc/sysctl.d/proxmox-accept-ra-and-max-plen-ipv6.conf`)

```
net.ipv6.conf.nic0.accept_ra = 2
net.ipv6.conf.nic0.accept_ra_rt_info_max_plen = 64
net.ipv6.conf.vmbr0.accept_ra = 2
net.ipv6.conf.vmbr0.accept_ra_rt_info_max_plen = 64
```

Both interfaces need it: on a bridge, RA handling can depend on the port interface's
settings; `nic0` is what actually receives RAs from the router.

Note: these settings ensure that router advertisements are correctly forwarded to the
actual interfaces of **any VM or LXC container**. If IPv6 is required on any managed
network interface, the above settings might need to be set for that specific
nw-interface of the Proxmox VM or LXC container as well.

## Result (verified after full reboot)

```bash
$ ip -br a
lo               UNKNOWN        127.0.0.1/8 ::1/128
nic0             UP
[...]
vmbr0            UP             192.168.178.150/24 fd3a:3cb9:5e4b:0:1e83:41ff:fe30:f626/64 2a03:b580:ab75:5301:1e83:41ff:fe30:f626/64 fe80::1e83:41ff:fe30:f626/64
```

## Root cause — ifupdown2 squash: ipv4 dhcp + ipv6 auto → both dhcp

ifupdown2 merges multiple `iface <name>` stanzas (/configuration blocks) for the same interface into one object
via `iface.squash()` (`/usr/share/ifupdown2/ifupdown/iface.py`):

- The **first** stanza sets `addr_method` (e.g. `'dhcp'`).
- Squashing the second stanza extends `addr_family → ['inet','inet6']` but does **not
  override** `addr_method`.

The dhcp addon (`/usr/share/ifupdown2/addons/dhcp.py`) gates on `addr_method`:

```python
if (ifaceobj.addr_method != 'dhcp' and ifaceobj.addr_method != 'dhcp6'):
    return   # would skip — but addr_method IS 'dhcp', so it does NOT skip
```

→ With `inet dhcp` + `inet6 auto`, dhclient6 is launched unconditionally, solicits
DHCPv6 forever (no server → no address), and `networking.service` fails with a signal,
blocking boot. With `inet static` the dhcp addon is not triggered at all, so the service
completes and SLAAC (kernel RA handling) assigns the global addresses independently.

## Side quest: AppArmor blocking dhclient at boot

Initial state: IPv4 was already DHCP on `vmbr0` (not Proxmox-recommended, but working up until adding ipv6). Adding IPv6 was a (in hindsight uninformed and wrong) one-liner:

```bash
iface vmbr0 inet6 dhcp
```

Reboot → stuck. `networking.service` failed because AppArmor was denying `dhclient`
socket creation (`apparmor="DENIED" ... profile="/{,usr/}sbin/dhclient"`). This had to
be resolved **first** before the actual IPv6 problem could even be analyzed.

Fix: `aa-teardown` (`apparmor-utils` wasn't installed initially). After that, networking
came up — and the real IPv6 issue (squash bug + no DHCPv6 server) became visible.

After Fix of Root cause:

```bash
# dhclient is no longer running (static IPv4 + SLAAC), so AppArmor can be enforced on dhclient:
ps aux | grep dhclient
aa-enforce /sbin/dhclient
```

## What was tried / ruled out

- `aa-complain` was only available after installing `apparmor-utils`. `aa-teardown` as workaround
- `aa-complain /sbin/dhclient` - reenable "non functional ipv6-dhcp" - noise stays
- `inet6 dhcp` → `inet6 auto` in the file — took hold but dhclient6 still launched (squash bug).
- `interfaces` ipv6 settings `accept_ra 2` / `autoconf 1` alone not sufficient
  `sysctl.d` file is required (see top of document)

## Rescue mode for network testing without breaking boot

If networking fails at boot and you lose SSH access:

```bash
# Option A: rescue target (one-off testing — do NOT leave as permanent default)
systemctl set-default rescue.target
# ... debug / disable ipv6 settings, then:
systemctl set-default multi-user.target

# Option B: mask networking so boot completes even if it fails
systemctl mask networking.service
systemctl reboot
# After debugging:
systemctl unmask networking.service
```

## Online testing

### network tests

```bash
systemctl restart networking
```

works as long as you're connected via IPv4/SSH and don't change the resulting IPv4 address.

### sysctl online adjustments

e.g.

```bash
MY_INTERFACE=nic0
sysctl -w net.ipv6.conf.$MY_INTERFACE.accept_ra=2
sysctl -w net.ipv6.conf.$MY_INTERFACE.accept_ra_rt_info_max_plen=64
MY_INTERFACE=vmbr0
sysctl -w net.ipv6.conf.$MY_INTERFACE.accept_ra=2
sysctl -w net.ipv6.conf.$MY_INTERFACE.accept_ra_rt_info_max_plen=64
```

## Environment

- Proxmox: 9.2.18
- ifupdown2 3.3.0-1+pmx12
- Router: Fritz!Box, SLAAC-only IPv6 (RA), DHCPv4 present (192.168.178.1)

## References

https://pve.proxmox.com/wiki/Network_Configuration

 

[Threaded]

@callMeConnor thanks for all your notes and glad you got it sorted. I have done considerable testing with IPv6 and Proxmox VE 9.2.11 interfaces and bridge and have some finding. They seems simpler than yours, so not sure it if it is because of newer version?

1) I didn't need to do any 'sysctl' changes, purely done in 'interfaces' file.

2) "autoconf 1" is the global default, doesn't hurt, but you don't need it.

3) Anywhere an 'inet6' interface exists, kernel RA support is going to work by default (because default value is "accept_ra 1"), EXCEPT for bridge interfaces, since they have IP forwarding enabled by default, which disables RA, unless you add "accept_ra 2".

4) You don't need to enable RA down the chain, just enabling it on the bridge with "accept_ra 2" is enough, or doing nothing on a regular interfaces. Kernel RA is going to work everywhere by default unless you stop it or ip forwarding is enabled (like on bridges).

5) If you want to prevent RA assigning GUA/ULA addresses on an non-bridge interface with an IPv6 address, then you'd add "accept_ra 0" and/or "autoconf 0" to that interface (though don't know why you would).

6) RA and autoconf works, whether you use auto or specific a static address, either way you'll get your delegated prefix and LLA gateway from RA. So you'll get an automatic GUA/ULA address - even if you specify a static one too, e.g. both of these bridges below will get an LLA gateway, LLA and GUA/ULA address, the "static" one will get the static address(es) as well.

iface vmbr1 inet6 auto
        accept_ra 2

or

iface vmbr1 inet6 static
        address 2003:cafe:beef:200::10/64
        accept_ra 2

If you want the static address, but _no_ automatic SLAAC address then this combo does that, but then you have to manually hard code the gateway LLA.

iface vmbr1 inet6 static
        address 2003:cafe:beef:200::10/64
        gateway fe80:cafe:beef:cafe::beef
        autoconf 0
        accept_ra 2

6) You can safely do all this configuration via the Network GUI _EXCEPT_ there is now way to add "accept_ra 2" to bridges and the GUI will try to delete it. We need a bug report for that!

7) I tried but gave up on IPv6 for Proxmox cluster functions. Lots of Proxmox bugs with IPv6 LLA parsing (no support for scoped addresses), problems joining clusters with GUA. ULA might work but nto relevant for my environment. So I keep the local cluster-internal comms on IPv4 and added a bridge with IPv6 for management GUI (and other bridges for guest VMs). I found the best way to do that is to bridge directly off the physical interface for just that VLAN. This means for guests on the bridge you don't specify a vlan id, since the default for the bridge is that vlan. So far that seems the cleanest and clearest to me, e.g.

auto vmbr1
iface vmbr1 inet static
        address 10.10.200.10/24
        bridge-ports nic0.35
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 35
#Guest and UI bridge on vlan 35

iface vmbr1 inet6 static
        address 2003:cafe:beef:200::10/64
        accept_ra 2

8) IMO stay away from DHCP6, only dragons lie there. DHCP is an IPv6 anti-pattern. It's the some of stuff we left IPv4 behind to avoid!

9) IMO stay away from DHCP6, only dragons lie there. DHCP is an IPv6 anti-pattern. It's the some of stuff we left IPv4 behind to avoid!