Hi, I am trying to setup dagger engines on an IPv6-only network. It seems the engine hardcode 10.87.0.0/16. Is there any snippet available to achieve that?
#Is Dagger working at all on IPv6 only networks?
terse sigil
kind fjord
Hi, I am trying to setup dagger engines on an IPv6-only network. It seems the en...
@terse sigil that CIDR is for the containers that Dagger manages internally. In your case is ipv4 completely disabled in your systems? Mostly asking since you can make ipv6 and ipv4 to live together within the same host. So basically all the Dagger internal traffic could be ipv4 and the moment that you need to access the outside world, route it through the machine's ipv6 interface.
terse sigil
@kind fjord thank you for your answer. Ipv4 is totally disabled in our network but not on the servers' stack. We are using podman which works out of the box with its default network, and from the dagger engine container we can access network resources over ipv6. Dagger engine pulls container images without issues but then problem appears when executing commands from the pulled container which seems to totally ignore ipv6. To me it looks like a CNI issue, however my experience in that domain is quite limited. Let me know if you need some traces that could help getting a better understanding of the issue.
kind fjord
<@336241811179962368> thank you for your answer. Ipv4 is totally disabled in our...
perfect, thx. Let me check if I can get an ipv6-only machine in AWS sometime this week and try there since it's not straightforward to test in my local setup
AFAIK AWS allows creating ipv6-only subnets so that should be enough for my test
terse sigil
Thank you. Let me know if you need anything. We're using podman version 5.7.1 if that matters
kind fjord
Thank you. Let me know if you need anything. We're using podman version 5.7.1 if...
@terse sigil I assume you don't have an ipv4 to ipv6 translation proxy, don't you?
I'm mostly thinking because the DNS resolver that dagger injects is currently ipv4 only.. so it can't really resolve ipv6 addresses
kind fjord
if images can be pulled from Dagger then I assume the work needed to make it work might be relatively scoped
do you have podman configured to setup ipv6 in the containers that it launches?
since I'd assume the engine container has an ipv6 address as well as an ipv6 DNS server configured
terse sigil
podman configuration is default one iirc, let me spin up an engine to confirm
kind fjord
podman configuration is default one iirc, let me spin up an engine to confirm
probably podman detects this automatically
do your hosts have both ipv6 addresses? Or just ipv6?
terse sigil
this is the logs from dagger execution
#[tokio::main]
async fn main() -> eyre::Result<()> {
dagger_sdk::connect(|client| async move {
let out = client.container().from("docker.io/nicolaka/netshoot:latest")
.with_exec(vec!["ping", "-c", "3", "2a04:4e42:200::644"])
.stdout().await?;
println!("{}", out);
Ok(())
})
.await?;
Ok(())
}
the code snippet
podman system info
podman inspect dagger-engine-v0.19.11
thank you again for the time you are taking on this issue
kind fjord
sure, np. The Networksettings in the podman inspect are somehow interesting.. it doesn't show anything π
do you mind execing in the dagger-engine pod and checking if you can ping from there?
and showing what ip a as well as ip route show?
terse sigil
ip a and ip route from the host?
kind fjord
from the engine container
podman exec -ti $engine-container sh
and running from there
terse sigil
ip is not installed on the default engine image
podman exec -it dagger-engine-v0.19.11 ping -c3 2a04:4e42:200::644 2026-02-24T23:37:49+0100
PING 2a04:4e42:200::644 (2a04:4e42:200::644): 56 data bytes
64 bytes from 2a04:4e42:200::644: seq=0 ttl=255 time=11.461 ms
64 bytes from 2a04:4e42:200::644: seq=1 ttl=255 time=10.865 ms
64 bytes from 2a04:4e42:200::644: seq=2 ttl=255 time=13.006 ms
--- 2a04:4e42:200::644 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 10.865/11.777/13.006 ms
also trying with docker.io/nicolaka/netshoot:latest which is giving me interesting results on my test environment, let me try somewhere else (i'm getting the ipv4 of my interface for virtual machines + the public ipv6 of the box)
abd9a811aa45 ξ° ~ ξ° 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: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65520 qdisc fq_codel state UNKNOWN group default qlen 1000
link/ether REDACTED brd ff:ff:ff:ff:ff:ff
inet 169.254.57.76/16 brd 169.254.255.255 scope global noprefixroute ens18
valid_lft forever preferred_lft forever
inet6 REDACTED/128 scope global nodad noprefixroute
valid_lft forever preferred_lft forever
inet6 fe80::e82a:e2ff:fe34:9bd8/64 scope link nodad proto kernel_ll
valid_lft forever preferred_lft forever
abd9a811aa45 ξ° ~ ξ° ip r l
default dev ens18 scope link metric 1001002
169.254.0.0/16 dev ens18 scope link metric 1002
this is from netshoot on a machine with only one interface. seems like podman is defaulting to ipv4 even when the only ipv4 available is a link-local address. :/