Unable to use IPv6 on rootless container #15850

aoxiangtianji · 2022-09-18T06:29:01Z

My English is not good, so I used translation software.

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

/kind feature

Description

First create an ipv6 network:
podman network create --ipv6 test
And create a rootless container use this network:
podman run -it --rm --network test archlinux
But this container cannot connect to a ipv6 webserver.
I'm sure the host can connect to a ipv6 webserver.
And, a container created with option "--network slirp4netns:enable_ipv6=true" can use ipv6.
Is there something wrong with my settings?

Describe the results you expected:

Both the host and container 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.17.12
Built:        Tue Aug  2 15:53:14 2022
OS/Arch:      linux/amd64

Output of podman info:

host:
  arch: amd64
  buildahVersion: 1.26.2
  cgroupControllers: []
  cgroupManager: cgroupfs
  cgroupVersion: v1
  conmon:
    package: conmon-2.1.2-2.module+el8.6.0+997+05c9d812.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.2, commit: 98e028a5804809ccb49bc099c0d53adc43ef8cc4'
  cpuUtilization:
    idlePercent: 99.63
    systemPercent: 0.17
    userPercent: 0.21
  cpus: 4
  distribution:
    distribution: '"rocky"'
    version: "8.6"
  eventLogger: file
  hostname: localhost.localdomain
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 4.18.0-372.26.1.el8_6.x86_64
  linkmode: dynamic
  logDriver: k8s-file
  memFree: 2651201536
  memTotal: 3802693632
  networkBackend: netavark
  ociRuntime:
    name: runc
    package: runc-1.1.3-2.module+el8.6.0+997+05c9d812.x86_64
    path: /usr/bin/runc
    version: |-
      runc version 1.1.3
      spec: 1.0.2-dev
      go: go1.17.12
      libseccomp: 2.5.2
  os: linux
  remoteSocket:
    path: /run/user/1000/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_NET_RAW,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: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.2.0-2.module+el8.6.0+997+05c9d812.x86_64
    version: |-
      slirp4netns version 1.2.0
      commit: 656041d45cfca7a4176f6b7eed9e4fe6c11e8383
      libslirp: 4.4.0
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.2
  swapFree: 1610608640
  swapTotal: 1610608640
  uptime: 39m 0.13s
plugins:
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries:
  search:
  - registry.access.redhat.com
  - registry.redhat.io
  - docker.io
store:
  configFile: /home/aoxiangtianji/.config/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/aoxiangtianji/.local/share/containers/storage
  graphRootAllocated: 12777947136
  graphRootUsed: 5570002944
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 1
  runRoot: /run/user/1000/containers
  volumePath: /home/aoxiangtianji/.local/share/containers/storage/volumes
version:
  APIVersion: 4.1.1
  Built: 1659426794
  BuiltTime: Tue Aug  2 15:53:14 2022
  GitCommit: ""
  GoVersion: go1.17.12
  Os: linux
  OsArch: linux/amd64
  Version: 4.1.1

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

podman-4.1.1-2.module+el8.6.0+997+05c9d812.x86_64

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

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

Rocky Linux 8.6 in VirtualBox

The text was updated successfully, but these errors were encountered:

mheon · 2022-09-19T13:34:24Z

@Luap99 PTAL - probably a slirp4netns options issue?

Luap99 · 2022-09-19T13:43:45Z

We need to enable the slirp4netns ipv6 option in containers.conf (which should be already on by default)
@aoxiangtianji Please run ps uww | grep slirp and check if the --enable-ipv6 option is set.

I think there are some routing issues with the ipv6 slirp4netns support, the output from, podman unshare --rootless-netns ip -6 r would also help.

aoxiangtianji · 2022-09-20T11:10:57Z

@Luap99 PTAL - probably a slirp4netns options issue?

Yes, the option is already set:
/usr/bin/slirp4netns --disable-host-loopback --mtu=65520 --enable-sandbox --enable-seccomp --enable-ipv6 -c -r 3 --netns-type=path /run/user/1000/netns/rootless-netns-8812468e384cd9f4d2f1 tap0

And the podman unshare --rootless-netns ip -6 r outputs this:

fd31:1a1d:64a3:53a1::/64 dev cni-podman1 proto kernel metric 256 pref medium
fe80::/64 dev tap0 proto kernel metric 256 pref medium
fe80::/64 dev cni-podman1 proto kernel metric 256 pref medium
fe80::/64 dev vethb67c1f0d proto kernel metric 256 pref medium

This is the "test" network configuration:

[
     {
          "name": "test",
          "id": "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08",
          "driver": "bridge",
          "network_interface": "cni-podman1",
          "created": "2022-09-18T14:27:36.396447937+08:00",
          "subnets": [
               {
                    "subnet": "10.89.0.0/24",
                    "gateway": "10.89.0.1"
               },
               {
                    "subnet": "fd31:1a1d:64a3:53a1::/64",
                    "gateway": "fd31:1a1d:64a3:53a1::1"
               }
          ],
          "ipv6_enabled": true,
          "internal": false,
          "dns_enabled": false,
          "ipam_options": {
               "driver": "host-local"
          }
     }
]

Anything wrong?

Luap99 · 2022-09-21T12:36:54Z

And the podman unshare --rootless-netns ip -6 r outputs this:

fd31:1a1d:64a3:53a1::/64 dev cni-podman1 proto kernel metric 256 pref medium
fe80::/64 dev tap0 proto kernel metric 256 pref medium
fe80::/64 dev cni-podman1 proto kernel metric 256 pref medium
fe80::/64 dev vethb67c1f0d proto kernel metric 256 pref medium

Looks like the default route is missing, try podman unshare --rootless-netns ip -6 route add default via <fd00 address from ip addr output>

I think slirp4netns should configure that.

aoxiangtianji · 2022-09-21T13:21:34Z

podman unshare --rootless-netns ip -6 r输出如下：
fd31:1a1d:64a3:53a1::/64 dev cni-podman1 proto kernel metric 256 pref medium
fe80::/64 dev tap0 proto kernel metric 256 pref medium
fe80::/64 dev cni-podman1 proto kernel metric 256 pref medium
fe80::/64 dev vethb67c1f0d proto kernel metric 256 pref medium
好像缺少默认路由，试试podman unshare --rootless-netns ip -6 route add default via <fd00 address from ip addr output>

我认为 slirp4netns 应该配置它。

fd00 address?
You mean the host ipv6 address or the 'test' network gateway?
Or something else?
Sorry I don't know that much about network and ipv6.

Luap99 · 2022-09-21T13:46:06Z

The fd... address in podman unshare --rootless-netns ip addr show tap0

aoxiangtianji · 2022-09-21T13:53:37Z

The command podman unshare --rootless-netns ip -6 route add default via fe80::2801:95ff:fe39:4a29 outputs:
Error: Egress device not specified.

aoxiangtianji · 2022-09-25T23:04:56Z

The fd... address in podman unshare --rootless-netns ip addr show tap0

Still interested in this question?

Luap99 · 2022-09-25T23:55:22Z

fd..., not fe80...

aoxiangtianji · 2022-09-26T11:11:01Z

fd..., not fe80...

Well, it doesn't have an fd... address.
podman unshare --rootless-netns ip addr show :

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: tap0: <BROADCAST,UP,LOWER_UP> mtu 65520 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether 32:50:4d:34:e6:f6 brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.100/24 brd 10.0.2.255 scope global tap0
       valid_lft forever preferred_lft forever
    inet6 fe80::3050:4dff:fe34:e6f6/64 scope link 
       valid_lft forever preferred_lft forever
3: cni-podman1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 06:ee:18:c5:97:19 brd ff:ff:ff:ff:ff:ff
    inet 10.89.0.1/24 brd 10.89.0.255 scope global cni-podman1
       valid_lft forever preferred_lft forever
    inet6 fd31:1a1d:64a3:53a1::1/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::4ee:18ff:fec5:9719/64 scope link 
       valid_lft forever preferred_lft forever
4: veth31302329@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master cni-podman1 state UP group default 
    link/ether b6:58:15:51:2d:61 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::b458:15ff:fe51:2d61/64 scope link 
       valid_lft forever preferred_lft forever

Is the cni-podman1 network you mean?

Luap99 · 2022-09-27T20:58:57Z

If there is no fd address on the tap0 interface then there is a problem with slirp4netns.

github-actions · 2022-10-28T00:09:12Z

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

MartinX3 · 2022-10-30T10:39:32Z

Still an issue with 4.3.
Enabling IPv6 breaks the containers.

They still can use ipv6, but DNS resolution (uses IPv6) and IPv6 access are broken.

tap0 only has the fe ipv6 like above.

Also see rootless-containers/slirp4netns#305

sup39 · 2022-11-18T13:58:45Z

I had the same issue, but I solved it with the following commands in my environment:

# Add an fd00::/64 address on tap0 manually (if not presenting)
podman unshare --rootless-netns ip addr add fd00::100/64 dev tap0
# Set default route via fd00::2 (IPv6 Gateway of slirp4netns)
podman unshare --rootless-netns ip route add default via fd00::2 dev tap0

Although there seems to be an mtu-related issue. I have to set the mtu of the network used by the container to 65520 (same as the mtu of tap0) via podman (modifying mtu with ip link set mtu does not seem to work). Otherwise some packets may be dropped. One way to set the mtu of the network is by creating the network with podman network create NETWORK_NAME -o mtu 65520.

The version I am using

Output of podman version:

Client:       Podman Engine
Version:      4.3.1
API Version:  4.3.1
Go Version:   go1.17.5
Git Commit:   814b7b003cc630bf6ab188274706c383f9fb9915
Built:        Fri Nov 18 00:28:57 2022
OS/Arch:      linux/amd64

Output of slirp4netns --version:

slirp4netns version 1.2.0
commit: 656041d45cfca7a4176f6b7eed9e4fe6c11e8383
libslirp: 4.1.0
SLIRP_CONFIG_VERSION_MAX: 1
libseccomp: 2.5.1

daiaji · 2022-12-11T14:04:40Z

Is there honestly no ipv6 support out of the box? Like ipv4. Moreover, the premise of enabling ipv6 on the existing podman network is a fixed ipv6 prefix, which makes it impossible to use the random ipv6 prefix distributed by the ISP of the home network.

rhatdan · 2022-12-12T19:10:37Z

@Luap99 PTAL

github-actions · 2023-01-12T00:07:08Z

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

MartinX3 · 2023-01-12T00:08:08Z

/remove stale

daiaji · 2023-01-12T10:24:25Z

Frustrating, I really want to use IPV6.

hdonnay · 2023-02-17T17:14:11Z

Running into this today, on a v6-only LAN

Here's the version information:

Client:       Podman Engine
Version:      4.4.1
API Version:  4.4.1
Go Version:   go1.19.5
Built:        Thu Feb  9 10:58:53 2023
OS/Arch:      linux/amd64

slirp4netns version 1.2.0
commit: 656041d45cfca7a4176f6b7eed9e4fe6c11e8383
libslirp: 4.7.0
SLIRP_CONFIG_VERSION_MAX: 4
libseccomp: 2.5.3

Similar to @sup39 I was able to get some connectivity by adding an address and route, but then ran into connection problems when doing anything beyond trivial HTTP requests e.g. HEAD www.google.com would return data, but GET www.google.com would not.

ondrejbudai · 2023-06-04T19:24:41Z

This issue still exists on podman 4.5.

claraphyll · 2023-08-09T00:59:08Z

This issue, as stated originally, still exists in Podman 4.6. Rootless IPv6 networking with a set network (For example, passing --net=podman or --net=test after podman network create --ipv6 test) only works if --net=slirp4netns:enable_ipv6=true is passed, even if IPv6 is enabled in the network configuration file. I think this option should be set implicitly if enable_ipv6 is set in the network configuration.

rhatdan · 2023-08-09T11:38:28Z

@Luap99 Thoughts?

Luap99 · 2023-08-09T11:55:11Z

slirp4netns is already started with --enable-ipv6 by default, the problem is the missing route.

I am working on the pasta integration instead of slirp4netns so this should work work better when I am done with that.

sriram241294 · 2023-08-17T09:51:44Z

slirp4netns is already started with --enable-ipv6 by default, the problem is the missing route.

I am working on the pasta integration instead of slirp4netns so this should work work better when I am done with that.

Is there a way to use pasta now by setting options from run command instead of using slirp4netns?

MartinX3 · 2023-08-17T09:52:52Z

I also hope it for a future version.
Using only kube yaml files I am forced to use the old slirp4netns with podman rootless.

claraphyll · 2023-08-23T15:28:02Z

I just read on podman-run(1) that networking with a custom network is done via the bridge network mode without pasta or slirp4netns. (And indeed, IPv6 is functional when using --net=slirp4netns or --net=pasta but not when using a network created with podman network create --ipv6) Is this still accurate and if yes, does that mean that pasta or slirp4netns aren't involved in this bug? It might just be a bug with the bridge network mode in rootless mode then.

Luap99 · 2023-08-23T16:00:03Z

@maxi0604 No rootless bridge still uses slirp4netns, rootlesskit is only used for the port forwarding, see here for the architecture: https://web.archive.org/web/20211014184135/https://podman.io/community/meeting/notes/2021-10-05/Podman-Rootless-Networking.pdf
Look for Rootless CNI networking it is a bit dated but if you replace CNI with netavark it is basically the same thing we still do today.

To me this looks like slirp4netns does not configure a default ipv6 route but I wasn't able to verify that myself. However sounds like #15850 (comment) did confirm that it is indeed the missing default route.

claraphyll · 2023-08-23T16:23:21Z

@maxi0604 No rootless bridge still uses slirp4netns, rootlesskit is only used for the port forwarding, see here for the architecture: https://web.archive.org/web/20211014184135/https://podman.io/community/meeting/notes/2021-10-05/Podman-Rootless-Networking.pdf Look for Rootless CNI networking it is a bit dated but if you replace CNI with netavark it is basically the same thing we still do today.

Ah, I see. Is there a way to test pasta with a custom network?

To me this looks like slirp4netns does not configure a default ipv6 route but I wasn't able to verify that myself. However sounds like #15850 (comment) did confirm that it is indeed the missing default route.

I can't confirm the missing route either. podman run -it --rm --net=testing alpine ip -6 r gives me (on up-to-date Fedora 38)

fdf9:c068:c668:7593::/64 dev eth0  metric 256 
fe80::/64 dev eth0  metric 256 
default via fdf9:c068:c668:7593::1 dev eth0  metric 100 
multicast ff00::/8 dev eth0  metric 256

The default line seems to indicate that a route exists and the gateway matches with the output of podman network inspect testing. I can also ping the gateway IP from the container but curl -6v google.com times out when running as rootless (the verbose output confirms that the IPv6 of google.com is resolved successfully). IPv6 networking on my host works.

Luap99 · 2023-08-23T16:30:44Z

Ah, I see. Is there a way to test pasta with a custom network?

No that is WIP

I can't confirm the missing route either. podman run -it --rm --net=testing alpine ip -6 r gives me (on up-to-date Fedora 38)

Not the default route in the container the default route in podman unshare --rootless-netns!

claraphyll · 2023-08-23T16:53:08Z

Ah, I see. Is there a way to test pasta with a custom network?

No that is WIP

I guess I'll have to just wait and see then, thanks for the info.

I can't confirm the missing route either. podman run -it --rm --net=testing alpine ip -6 r gives me (on up-to-date Fedora 38)

Not the default route in the container the default route in podman unshare --rootless-netns

Sorry for the misunderstanding. I can confirm the issue now. Only while the container is running, podman unshare --rootless-netns ip -6 r gives

fd00::/64 dev tap0 proto kernel metric 256 expires 86273sec pref medium
fdf9:c068:c668:7593::/64 dev podman4 proto kernel metric 256 pref medium
fe80::/64 dev tap0 proto kernel metric 256 pref medium
fe80::/64 dev podman4 proto kernel metric 256 pref medium
fe80::/64 dev veth0 proto kernel metric 256 pref medium

and IPv6 connections fail from podman unshare --rootless-netns as well as the container. (Tested with curl -6)

After the container exits, an existing podman unshare --rootless-ns "session" gives no routes with ip -6 r. If I exit and reeenter the namespace, then it gives

fd00::/64 dev tap0 proto kernel metric 256 expires 86398sec pref medium
fe80::/64 dev tap0 proto kernel metric 256 pref medium
default via fe80::2 dev tap0 proto ra metric 1024 expires 1798sec hoplimit 64 pref medium

and IPv6 networking works

To summarize the reproduction:

podman unshare --rootless-ns
podman run -it --rm --net=testing alpine in another terminal
ip -6 r in the first terminal gives the broken output (no default route)
exit the container
ip -6 r in the rootless ns gives empty output

obarisk · 2023-09-01T03:28:46Z

podman unshare --rootless-netns ip -br -6 route

has three routes

fd00::/64 dev tap0
fe80::/64 dev tap0
default via fd80::2 dev tap0

why fd00::/64?

podman = 4.4.0
slirp4netns = 1.2.0

karuboniru · 2023-12-12T15:06:00Z

Since my issue was a dup of this, so I am putting informatio here:

Steps to reproduce the issue

Create ~/.local/share/containers/storage/networks/podman.json with content

{
     "name": "podman",
     "id": "2f259bab93aaaaa2542ba43ef33eb990d0999ee1b9924b557b7be53c0b7a1bb9",
     "driver": "bridge",
     "network_interface": "podman0",
     "created": "2022-08-27T13:25:16.808341191+08:00",
     "subnets": [
         {
             "subnet": "10.89.0.0/16",
             "gateway": "10.89.0.1"
         },
         {
             "subnet": "fccd::/64",
             "gateway": "fccd::1"
         }
     ],
     "ipv6_enabled": true,
     "internal": false,
     "dns_enabled": true,
     "ipam_options": {
         "driver": "host-local"
     }
}

Start a container with command podman run -it --rm --entrypoint=/bin/sh --network=podman alpine
Check ipv6 connectivity

Describe the results you received

I don't get ipv6 in container as expected. The address and route is configured in container but no connection.

And I did some inspection with podman unshare --rootless-netns

# ip a 
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host proto kernel_lo 
       valid_lft forever preferred_lft forever
2: tap0: <BROADCAST,UP,LOWER_UP> mtu 65520 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether 4a:9b:78:ad:16:32 brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.100/24 brd 10.0.2.255 scope global tap0
       valid_lft forever preferred_lft forever
    inet6 fd00::489b:78ff:fead:1632/64 scope global dynamic mngtmpaddr proto kernel_ra 
       valid_lft 86378sec preferred_lft 14378sec
    inet6 fe80::489b:78ff:fead:1632/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever
3: podman0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 4e:26:0e:40:47:13 brd ff:ff:ff:ff:ff:ff
    inet 10.89.0.1/16 brd 10.89.255.255 scope global podman0
       valid_lft forever preferred_lft forever
    inet6 fccd::1/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::d8a0:60ff:fe48:2f36/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever
4: veth0@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master podman0 state UP group default qlen 1000
    link/ether 4e:26:0e:40:47:13 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::4c26:eff:fe40:4713/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever

# ip -6 r
fccd::/64 dev podman0 proto kernel metric 256 pref medium
fd00::/64 dev tap0 proto kernel metric 256 expires 86373sec pref medium
fe80::/64 dev tap0 proto kernel metric 256 pref medium
fe80::/64 dev podman0 proto kernel metric 256 pref medium
fe80::/64 dev veth0 proto kernel metric 256 pref medium

The route here is weird as the default route is missing (and ipv6 is broken in this namespace too). I think this is the direct cause of the issue. Before running the container (or after the container has stopped) the route is

# ip -6 r
fd00::/64 dev tap0 proto kernel metric 256 expires 86397sec pref medium
fe80::/64 dev tap0 proto kernel metric 256 pref medium
default via fe80::2 dev tap0 proto ra metric 1024 expires 1797sec hoplimit 64 pref medium

Adding the route in the rootless namespace can grant ipv6 access to containers. So I believe the issue is netavark somehow removed the route or stopped slirp4netns from creating it.

But anyway, if just ipv6 access is needed, running podman with no explicit network flag and let slirp4netns to handle everything should work...

Luap99 · 2024-06-15T19:42:14Z

I assume this works with podman 5.0 when pasta is used for the rootless-netns which it is by default

openshift-ci bot added the kind/feature Categorizes issue or PR as related to a new feature. label Sep 18, 2022

Luap99 added slirp4netns Bug is in slirp4netns network Networking related issue or feature labels Sep 21, 2022

github-actions bot added the stale-issue label Oct 28, 2022

This was referenced Oct 30, 2022

rootless podman is not able to connect to the external ipv6 network rootless-containers/slirp4netns#305

Open

Enable IPv6 as soon as it is available and stable MartinX3-AdministrativeDevelopment/ServerContainerTemplate#45

Open

github-actions bot removed the stale-issue label Oct 31, 2022

MartinX3 mentioned this issue Nov 8, 2022

Declare and use networks in yaml with podman play kube #12965

Open

github-actions bot added the stale-issue label Jan 12, 2023

rhatdan removed the stale-issue label Jan 12, 2023

claraphyll mentioned this issue Aug 23, 2023

Add support for enable_ipv6 containers/podman-compose#749

Merged

dgibson added the pasta pasta(1) bugs or features label Aug 25, 2023

karuboniru mentioned this issue Dec 11, 2023

Broken rootless ipv6 with netavark #20993

Closed

Luap99 closed this as completed Jun 15, 2024

stale-locking-app bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 14, 2024

stale-locking-app bot locked as resolved and limited conversation to collaborators Sep 14, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Unable to use IPv6 on rootless container #15850

Unable to use IPv6 on rootless container #15850

aoxiangtianji commented Sep 18, 2022

mheon commented Sep 19, 2022

Luap99 commented Sep 19, 2022

aoxiangtianji commented Sep 20, 2022 •

edited

Loading

Luap99 commented Sep 21, 2022

aoxiangtianji commented Sep 21, 2022

Luap99 commented Sep 21, 2022

aoxiangtianji commented Sep 21, 2022 •

edited

Loading

aoxiangtianji commented Sep 25, 2022

Luap99 commented Sep 25, 2022

aoxiangtianji commented Sep 26, 2022 •

edited

Loading

Luap99 commented Sep 27, 2022

github-actions bot commented Oct 28, 2022

MartinX3 commented Oct 30, 2022 •

edited

Loading

sup39 commented Nov 18, 2022

daiaji commented Dec 11, 2022 •

edited

Loading

rhatdan commented Dec 12, 2022

github-actions bot commented Jan 12, 2023

MartinX3 commented Jan 12, 2023

daiaji commented Jan 12, 2023

hdonnay commented Feb 17, 2023 •

edited

Loading

ondrejbudai commented Jun 4, 2023

claraphyll commented Aug 9, 2023 •

edited

Loading

rhatdan commented Aug 9, 2023

Luap99 commented Aug 9, 2023

sriram241294 commented Aug 17, 2023

MartinX3 commented Aug 17, 2023

claraphyll commented Aug 23, 2023 •

edited

Loading

Luap99 commented Aug 23, 2023

claraphyll commented Aug 23, 2023

Luap99 commented Aug 23, 2023

claraphyll commented Aug 23, 2023 •

edited

Loading

obarisk commented Sep 1, 2023

karuboniru commented Dec 12, 2023

Luap99 commented Jun 15, 2024

Unable to use IPv6 on rootless container #15850

Unable to use IPv6 on rootless container #15850

Comments

aoxiangtianji commented Sep 18, 2022

mheon commented Sep 19, 2022

Luap99 commented Sep 19, 2022

aoxiangtianji commented Sep 20, 2022 • edited Loading

Luap99 commented Sep 21, 2022

aoxiangtianji commented Sep 21, 2022

Luap99 commented Sep 21, 2022

aoxiangtianji commented Sep 21, 2022 • edited Loading

aoxiangtianji commented Sep 25, 2022

Luap99 commented Sep 25, 2022

aoxiangtianji commented Sep 26, 2022 • edited Loading

Luap99 commented Sep 27, 2022

github-actions bot commented Oct 28, 2022

MartinX3 commented Oct 30, 2022 • edited Loading

sup39 commented Nov 18, 2022

The version I am using

daiaji commented Dec 11, 2022 • edited Loading

rhatdan commented Dec 12, 2022

github-actions bot commented Jan 12, 2023

MartinX3 commented Jan 12, 2023

daiaji commented Jan 12, 2023

hdonnay commented Feb 17, 2023 • edited Loading

ondrejbudai commented Jun 4, 2023

claraphyll commented Aug 9, 2023 • edited Loading

rhatdan commented Aug 9, 2023

Luap99 commented Aug 9, 2023

sriram241294 commented Aug 17, 2023

MartinX3 commented Aug 17, 2023

claraphyll commented Aug 23, 2023 • edited Loading

Luap99 commented Aug 23, 2023

claraphyll commented Aug 23, 2023

Luap99 commented Aug 23, 2023

claraphyll commented Aug 23, 2023 • edited Loading

obarisk commented Sep 1, 2023

karuboniru commented Dec 12, 2023

Describe the results you received

Luap99 commented Jun 15, 2024

aoxiangtianji commented Sep 20, 2022 •

edited

Loading

aoxiangtianji commented Sep 21, 2022 •

edited

Loading

aoxiangtianji commented Sep 26, 2022 •

edited

Loading

MartinX3 commented Oct 30, 2022 •

edited

Loading

daiaji commented Dec 11, 2022 •

edited

Loading

hdonnay commented Feb 17, 2023 •

edited

Loading

claraphyll commented Aug 9, 2023 •

edited

Loading

claraphyll commented Aug 23, 2023 •

edited

Loading

claraphyll commented Aug 23, 2023 •

edited

Loading