I need an ipv6 and a normal ipv4 bridge in the same container

Hello,
new user here. I’m trying to give ipv4 AND ipv6 connectivity to the same container and i’m not getting anywhere :slight_smile:
i tried with a macvlan connection for ipv6 and a bridge interface for ipv4 (where i have some ports to be natted): ipv6 works (but i had to manually assign an ip since slaac did not do that for me), but ipv4 does not work anymore (it seems i can just ping the host, but not reach the rest of the world) (and ports seem not to be natted anymore)
so i tried adding ipv6 to the default bridge, and this breaks ipv6 connectivity of the host itself
atm, im with a network: host config and it “works”, but not how i’d like so i’m asking help for some hints on how to achieve the double connectivity with a docker compose.
thanks

Maybe you share some more context. Which OS, how was Docker installed, docker version and docker info.

sure, my question was more a “give me something to read assuming my need is not impossible”, but if you can help me directly it’s also better :slight_smile:
docker version and info:

root@Services:~# docker version
Client: Docker Engine - Community
 Version:           29.2.1
 API version:       1.53
 Go version:        go1.25.6
 Git commit:        a5c7197
 Built:             Mon Feb  2 17:17:24 2026
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          29.2.1
  API version:      1.53 (minimum version 1.44)
  Go version:       go1.25.6
  Git commit:       6bc6209
  Built:            Mon Feb  2 17:17:24 2026
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v2.2.1
  GitCommit:        dea7da592f5d1d2b7755e3a161be07f43fad8f75
 runc:
  Version:          1.3.4
  GitCommit:        v1.3.4-0-gd6d73eb8
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0
root@Services:~# docker info
Client: Docker Engine - Community
 Version:    29.2.1
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.31.1
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v5.0.0
    Path:     /usr/local/lib/docker/cli-plugins/docker-compose
  model: Docker Model Runner (Docker Inc.)
    Version:  v1.0.10
    Path:     /usr/libexec/docker/cli-plugins/docker-model

Server:
 Containers: 7
  Running: 7
  Paused: 0
  Stopped: 0
 Images: 7
 Server Version: 29.2.1
 Storage Driver: overlayfs
  driver-type: io.containerd.snapshotter.v1
 Logging Driver: journald
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 CDI spec directories:
  /etc/cdi
  /var/run/cdi
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: dea7da592f5d1d2b7755e3a161be07f43fad8f75
 runc version: v1.3.4-0-gd6d73eb8
 init version: de40ad0
 Security Options:
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.17.2-1-pve
 Operating System: Debian GNU/Linux 13 (trixie)
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 4GiB
 Name: Services
 ID: 0b2709d3-95de-4d71-9e53-ec08f2c42ea2
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  ::1/128
  127.0.0.0/8
 Live Restore Enabled: false
 Firewall Backend: iptables

i could manage to have a macvlan ipv6 connection working (even if i had to give myself the ipaddress, slaac not working), but no way to leave this connection up and adding a ipv4 bridge connection.
Thanks

I have no idea what causes the problem, though I have still some questions

Are you running docker-ce directly on the proxmox host, or are you running it in an lxc container? I am asking because last time I checked docker-ce on the host had problems with AppArmor profiles (if I remember right) and the Proxmox docs specifically did not recommend using lxc containers as docker hosts.

Are you trying to use GUA ipv6 addresses using a static prefix because you want to it to be accessible from the internet? Or are your configuring ULA ipv6 addresses and only want it to be accessible in the subnet (and whatever subnets have routes to it)?

using docker in a lxc (i have 6 in my homelab). Yes recently a specifig docker update broke almost everything, time for proxmox to fix the issue.. and yes, i’ve also read about not recommend to use docker in a lxc, but honestly this is a really common usecase (and most of all i’ve no problems using docker in lxc..)

its about GUA address. Probably explaining the use case it’s easier :slight_smile: i’ve installed an asterisk based PBX with web gui, but my provider is fully ipv6 based: i need the pbx to have a GUA ipv6 to allow the sip connection to work, but on the other end i’d need ipv4 to access locally the GUI. I used for the specific vlan where the docker lxc is a /64 subnet of the prefix delegated by the provider. Again, with “host” network all works, but i can’t make any step forward
really if you want to give me any docker doc i can try (this is totally an homelab use, nothing serious)
thanks!

You mean the update to docker v29? What broke are docker client apps (like Portainer or Traefik) that needed to access the docker.socket, but used old docker api versions while doing so. Docker v29 required the api version 1.44, which was first introduces with Docker v25 two years ago. Most of the client apps should have been updated to use newer api version by now.

Must be a static prefix then. I assume you already realized that dynamic prefix are not supported.

You should be able to configure your subnets as default-address-pools with a size of /64 in the daemon.json or if you create a custom bridge network and use the subnet argument.

I am unclear whether you can use your lan subnet here, or require prefix delegation on the router and distinct subnets for the docker networks. I don’t have the luxury of a static prefix, so I never cared to configure it.

If I am not mistaken sip sends its ip address embedded in responses to instruct which ports to use for follow-up communication by the client, so you HAVE to use a GUA, right? Aunt Google says it is possible. So this might be a solution as well, but it would require your router to support nat66 (which is frowned upon by ipv6 purists).