After I already read some bug reports (like podman and IPv6 · Issue #3245 · containers/podman · GitHub) and just to get this clear in my mind: Is it true the podman does not support IPv6 on a exposed (i.e. accessible from the host server port) port? Will this change in near future?
Hello @aanno2 ,
I would say it does work for some according to the discussions at the issue link you provided (which is closed and about Podman pre 0.8 release). If you read further down in the issue, there is a link to an issue for CNI which is still open, but again there comments indicate most are able to get it working. And podman uses slirp4nets in rootless containers I thought.
Well, I also read there are people who had been successful with ipv6. However, so far I haven’t joined them.
This is my testbed. I wrote a small script
#!/bin/bash -x CONTAINER=`podman run --net slirp4netns:allow_host_loopback=true,enable_ipv6=true --env HTTP_PORT=8081 --env HTTPS_PORT=8082 -p 8081:8081 -p 8082:8082 -d praqma/network-multitool` podman exec -it $CONTAINER bash podman rm -f $CONTAINER
But when I use it:
$ ./nettool.sh + '[' -z '' ']' + case "$-" in + __lmod_vx=x + '[' -n x ']' + set +x Shell debugging temporarily silenced: export LMOD_SH_DBG_ON=1 for this output (/usr/share/lmod/lmod/init/bash) Shell debugging restarted + unset __lmod_vx ++ podman run --net slirp4netns:allow_host_loopback=true,enable_ipv6=true --env HTTP_PORT=8081 --env HTTPS_PORT=8082 -p 8081:8081 -p 8082:8082 -d praqma/network-multitool + CONTAINER=8bc783bcc31cef37afb48a0fd9d9cb0a74861621e4735a442b613942f7def01a + podman exec -it 8bc783bcc31cef37afb48a0fd9d9cb0a74861621e4735a442b613942f7def01a bash bash-5.0# ping google.com PING google.com (220.127.116.11) 56(84) bytes of data. 64 bytes from muc11s04-in-f14.1e100.net (18.104.22.168): icmp_seq=1 ttl=255 time=9.20 ms 64 bytes from muc11s04-in-f14.1e100.net (22.214.171.124): icmp_seq=2 ttl=255 time=9.85 ms ^C --- google.com ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1002ms rtt min/avg/max/mdev = 9.196/9.521/9.846/0.325 ms bash-5.0# ping6 google.com PING google.com(muc11s04-in-x0e.1e100.net (2a00:1450:4016:807::200e)) 56 data bytes ^C --- google.com ping statistics --- 9 packets transmitted, 0 received, 100% packet loss, time 8191ms bash-5.0# exit exit + podman rm -f 8bc783bcc31cef37afb48a0fd9d9cb0a74861621e4735a442b613942f7def01a 8bc783bcc31cef37afb48a0fd9d9cb0a74861621e4735a442b613942f7def01a
Hence, the result so far: IPv4 is working. IPv6 is resolving the address, but the IPv6 ping does not work.
Any help on this would be appriciated!
I’ve found the solution on my own: While
tracepath6 have problems (like I reported), normal tcp/udp traffic is possible and hence the following works:
# curl -v6 google.com * Trying 2a00:1450:4001:810::200e:80... * Connected to google.com (2a00:1450:4001:810::200e) port 80 (#0) > GET / HTTP/1.1 > Host: google.com > User-Agent: curl/7.69.1 > Accept: */* > * Mark bundle as not supporting multiuse < HTTP/1.1 301 Moved Permanently < Location: http://www.google.com/ < Content-Type: text/html; charset=UTF-8 < Date: Fri, 05 Mar 2021 08:07:49 GMT < Expires: Sun, 04 Apr 2021 08:07:49 GMT < Cache-Control: public, max-age=2592000 < Server: gws < Content-Length: 219 < X-XSS-Protection: 0 < X-Frame-Options: SAMEORIGIN < <HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8"> <TITLE>301 Moved</TITLE></HEAD><BODY> <H1>301 Moved</H1> The document has moved <A HREF="http://www.google.com/">here</A>. </BODY></HTML> * Connection #0 to host google.com left intact