network create: option parity with docker network create

[mayur-tolexo]

I was comparing nerdctl network create with docker network create (Docker 29.4.0) and figured it is worth tracking the gaps in one place. Docker reference for these flags: https://docs.docker.com/reference/cli/docker/network/create/

Most of it already lines up — --driver, --opt, --ipam-driver, --ipam-opt, --subnet, --gateway, --label, --internal and --ipv6 all behave like Docker.

A few things differ or are missing:

• --ip-range only takes a single value and applies it to every subnet, whereas Docker takes it per subnet (it is repeatable). So on a dual-stack network the IPv4 range ends up being checked against the IPv6 subnet and creation fails. Same shape as the --gateway problem fixed in fix(network): match each gateway to its subnet for dual-stack #5010, and the fix would be the same: make it repeatable and match each range to the subnet that contains it.
• There is no --ipv4. Docker uses it to disable IPv4 so you can create an IPv6-only network; nerdctl has no equivalent.
• --aux-address (per-subnet auxiliary addresses) is not implemented.

Happy to work on these - --ip-range, --ipv4 and --aux-address - if they sound reasonable.

[AkihiroSuda]

Happy to work on these - --ip-range, --ipv4 and --aux-address - if they sound reasonable.

Yes, thanks.
v6-only networking may need some changes on CNI plugins too?

[mayur-tolexo]

Thanks!

I went through pkg/netutil to see how much of v6-only is CNI vs nerdctl, and it looks mostly nerdctl-side — the standard plugins (bridge, host-local, portmap, firewall) already handle IPv6, so I don't think they need code changes:

• generateIPAM always appends a default IPv4 range when no v4 subnet is given (the !findIPv4 branch), so today every bridge network gets IPv4. --ipv4=false means skipping that and requiring/defaulting a v6 subnet instead.
• The host-local default route is hardcoded to 0.0.0.0/0; for a v6-only network it has to become ::/0, otherwise host-local adds a v4 default route with no matching gateway.

The plugin side is more about runtime prerequisites than code — the host needs net.ipv6.conf.all.forwarding=1, and IPv6 masquerade/portmap only kick in with reasonably recent containernetworking/plugins (ip6tables). I'll check the end-to-end path against a current plugins build as part of this.

Plan: start with --ip-range (same shape as the --gateway fix in #5010) and --aux-address, then --ipv4 / v6-only with the route and default-range changes above.