Podman machine on MacOS does not forward IPv6 TCP traffic

[sanmai-NL]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

Podman machine on MacOS does not forward IPv6 TCP traffic.

Regardless of limitations on IPv6 functionality for Podman containers (e.g., #14491), the machine should be ready for IPv6 connectivity.

Steps to reproduce the issue:

1. podman machine init
2. podman machine start

$ curl --fail --head --silent 'http://[2a10:3781:233a:1:ed58:85e1:ea82:dbef]:8000/''
HTTP/1.0 200 OK
Server: SimpleHTTP/0.6 Python/3.10.5
Date: Mon, 01 Aug 2022 14:25:28 GMT
Content-type: text/html; charset=utf-8
Content-Length: 344

$ curl --fail --head --silent 'http://192.168.178.57:8000/'
HTTP/1.0 200 OK
Server: SimpleHTTP/0.6 Python/3.10.5
Date: Mon, 01 Aug 2022 14:40:30 GMT
Content-type: text/html; charset=utf-8
Content-Length: 344

$ podman machine ssh curl --fail --head --silent 'http://[2a10:3781:233a:1:ed58:85e1:ea82:dbef]:8000/'
Warning: Permanently added '[localhost]:64233' (ED25519) to the list of known hosts.
Error: exit status 7

$ podman machine ssh curl --fail --head --silent 'http://192.168.178.57:8000/'
Warning: Permanently added '[localhost]:64233' (ED25519) to the list of known hosts.
HTTP/1.0 200 OK
Server: SimpleHTTP/0.6 Python/3.10.5
Date: Mon, 01 Aug 2022 14:39:30 GMT
Content-type: text/html; charset=utf-8
Content-Length: 344

Describe the results you received:

The Podman machine cannot connect to a webserver by its IPv6 address, but the host machine can. The Podman machine can connect to the webserver by its IPv4 address, as can the host machine.

Describe the results you expected:

Both the host and Podman machine can connect to the webserver by either its IPv4 or IPv6 address.

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

Client:       Podman Engine
Version:      4.1.1
API Version:  4.1.1
Go Version:   go1.18.3
Built:        Tue Jun 14 22:12:46 2022
OS/Arch:      darwin/amd64

Server:       Podman Engine
Version:      4.1.1
API Version:  4.1.1
Go Version:   go1.18.3
Built:        Wed Jun 22 18:17:44 2022
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.26.1
  cgroupControllers:
  - cpuset
  - cpu
  - io
  - memory
  - hugetlb
  - pids
  - misc
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.0-2.fc36.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.0, commit: '
  cpuUtilization:
    idlePercent: 96.78
    systemPercent: 0.93
    userPercent: 2.29
  cpus: 1
  distribution:
    distribution: fedora
    variant: coreos
    version: "36"
  eventLogger: journald
  hostname: localhost.localdomain
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 5.18.13-200.fc36.x86_64
  linkmode: dynamic
  logDriver: journald
  memFree: 1619922944
  memTotal: 2064896000
  networkBackend: netavark
  ociRuntime:
    name: crun
    package: crun-1.4.5-1.fc36.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.4.5
      commit: c381048530aa750495cf502ddb7181f2ded5b400
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    exists: true
    path: /run/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: false
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.2.0-0.2.beta.0.fc36.x86_64
    version: |-
      slirp4netns version 1.2.0-beta.0
      commit: 477db14a24ff1a3de3a705e51ca2c4c1fe3dda64
      libslirp: 4.6.1
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.3
  swapFree: 0
  swapTotal: 0
  uptime: 2h 33m 20.27s (Approximately 0.08 days)
plugins:
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries:
  search:
  - docker.io
store:
  configFile: /usr/share/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: overlay
  graphOptions:
    overlay.mountopt: nodev,metacopy=on
  graphRoot: /var/lib/containers/storage
  graphRootAllocated: 106825756672
  graphRootUsed: 2336190464
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "true"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 8
  runRoot: /run/containers/storage
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 4.1.1
  Built: 1655914664
  BuiltTime: Wed Jun 22 18:17:44 2022
  GitCommit: ""
  GoVersion: go1.18.3
  Os: linux
  OsArch: linux/amd64
  Version: 4.1.1

Package info (e.g. output of rpm -q podman or apt list podman):

$ brew info podman
podman: stable 4.1.1 (bottled), HEAD
Tool for managing OCI containers and pods
https://podman.io/
/usr/local/Cellar/podman/4.1.1 (174 files, 47.7MB) *
  Poured from bottle on 2022-06-16 at 14:32:43
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/podman.rb
License: Apache-2.0
==> Dependencies
Build: go ✘, go-md2man ✘
Required: qemu ✔
==> Options
--HEAD
        Install HEAD version
==> Caveats
fish completions have been installed to:
  /usr/local/share/fish/vendor_completions.d

==> Analytics
install: 15,516 (30 days), 57,503 (90 days), 178,436 (365 days)
install-on-request: 15,396 (30 days), 57,084 (90 days), 178,007 (365 days)
build-error: 46 (30 days)

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/main/troubleshooting.md)

Yes/No

Additional environment details (AWS, VirtualBox, physical, etc.):

MacOS 12.5

[vrothberg]

@flouthoc @Luap99 @baude PTAL

[Luap99]

This needs to be implemented in gvproxy: https://github.com/containers/gvisor-tap-vsock/pull/59

[github-actions[bot]]

A friendly reminder that this issue had no activity for 30 days.

[github-actions[bot]]

A friendly reminder that this issue had no activity for 30 days.

[sanmai-NL]

Not stale

[dnmvisser]

Hi, we're almost a year further and this issue appears to be unchanged... I would be fine with using podman run --network=host ... but that requires IPv6 connectivity on the podman machine... I tried to check on the podmad machine and make that do IPv6 but it is very unclear how to do changes there as nothing is documented about that. Using another distro for the podman machine is also not supported nor documented. Which leaves me back to square one with exactly... nothing.

[Luap99]

This is an open source project you are are more then welcome to contribute ipv6 support for podman machine if that is important to you. As mentioned above this needs to be implemented in gvproxy, see https://github.com/containers/gvisor-tap-vsock/pull/59 as a starting point.

[paul8046]

This is still a problem in version 5.0.0. Currently one cannot push or pull to a registry residing on an IPv6-only network. It is a shame that in 2024 podman still requires IPv4 in order to use basic functions. For those of us on IPv6-only networks this is a show-stopper and is thus a real problem. Also, the conversation at https://github.com/containers/gvisor-tap-vsock/pull/59 makes it clear that they have no intention of fixing this in the foreseeable future (its "low priority"). Is there any work-around?

Sorry I can't offer a fix myself; and I'm grateful for all the time volunteered by others to make this project happen.

[Luap99]

Note podman on linux supports ipv6 (well more or less it is not tested that well but it should work). In this case the issue is really in gvproxy which is used for podman machine VMs networking.

Nothing should stop you from setting up your own VM with ipv6 networking and then use podman there, of course the convince factor might be much lower.