Skip to content

network create: match each --ip-range to its subnet for dual-stack#5018

Open
mayur-tolexo wants to merge 1 commit into
containerd:mainfrom
mayur-tolexo:fix/network-dual-stack-ip-range
Open

network create: match each --ip-range to its subnet for dual-stack#5018
mayur-tolexo wants to merge 1 commit into
containerd:mainfrom
mayur-tolexo:fix/network-dual-stack-ip-range

Conversation

@mayur-tolexo

Copy link
Copy Markdown
Contributor

Follow-up from #5012. nerdctl network create took a single --ip-range and applied it to every subnet, so on a dual-stack network the IPv4 range was checked against the IPv6 subnet and creation failed with "no matching subnet". This makes --ip-range repeatable and matches each range to the subnet that contains it, the same way --gateway does.

Checked against Docker 29.4.0: docker network create --ip-range is an ipNetSlice (repeatable, one per subnet) and pairs each range with the subnet that contains it, order-independent; a range that matches no subnet errors. nerdctl now behaves the same.

Based on #5010 — it reuses the parseIPAMRanges per-subnet matching from that PR, so until #5010 merges this shows both commits. I'll rebase to the single ip-range commit once it lands.

$ go test ./pkg/netutil/ -run TestParseIPAMRangesIPRange -count=1 -v
=== RUN   TestParseIPAMRangesIPRange
--- PASS: TestParseIPAMRangesIPRange (0.00s)
    --- PASS: TestParseIPAMRangesIPRange/each_ip-range_pairs_with_its_subnet_regardless_of_order (0.00s)
    --- PASS: TestParseIPAMRangesIPRange/an_ip-range_matching_no_subnet_errors (0.00s)
    --- PASS: TestParseIPAMRangesIPRange/an_IPv4_ip-range_with_only_an_IPv6_subnet_errors (0.00s)
    --- PASS: TestParseIPAMRangesIPRange/a_second_ip-range_claiming_the_same_subnet_errors (0.00s)
    --- PASS: TestParseIPAMRangesIPRange/a_malformed_ip-range_errors (0.00s)
PASS
ok  	github.com/containerd/nerdctl/v2/pkg/netutil	0.643s

The dual-stack end-to-end path is covered by a new network create integration subtest (dual-stack with explicit ip-ranges).

@mayur-tolexo mayur-tolexo marked this pull request as ready for review June 27, 2026 16:08
@mayur-tolexo mayur-tolexo marked this pull request as draft June 27, 2026 16:11
@mayur-tolexo mayur-tolexo force-pushed the fix/network-dual-stack-ip-range branch 2 times, most recently from 5b9ee6a to e0eb1c7 Compare June 29, 2026 15:20
network create applied a single --ip-range to every subnet, so on a
dual-stack network the IPv4 range was checked against the IPv6 subnet
and creation failed with "no matching subnet". Accept --ip-range more
than once and match each range to the subnet that contains it, the same
way --gateway is handled.

Signed-off-by: Mayur Das <mayur.das@neevcloud.com>
@mayur-tolexo mayur-tolexo force-pushed the fix/network-dual-stack-ip-range branch from e0eb1c7 to 9f7761b Compare June 29, 2026 16:14
@mayur-tolexo

Copy link
Copy Markdown
Contributor Author

Ran this locally against Docker to make sure the dual-stack behaviour lines up. Each --ip-range gets matched to the subnet that contains it, so the v4 address comes out of the v4 range and the v6 address out of the v6 range.

Docker:

$ docker network create --ipv6 \
    --subnet 10.50.0.0/16 --ip-range 10.50.1.0/24 \
    --subnet fd00:50::/64 --ip-range fd00:50::/120 demo-ds
$ docker run --rm --network demo-ds alpine ip -o addr show eth0
eth0    inet 10.50.1.1/16
eth0    inet6 fd00:50::2/64

nerdctl with this PR:

$ nerdctl network create --ipv6 \
    --subnet 10.50.0.0/16 --ip-range 10.50.1.0/24 \
    --subnet fd00:50::/64 --ip-range fd00:50::/120 demo-ds
$ nerdctl run --rm --network demo-ds alpine ip -o addr show eth0
eth0    inet 10.50.1.1/16
eth0    inet6 fd00:50::2/64

Same addresses on both. And the host-local ranges nerdctl writes out, to show each range landed under the right subnet instead of being checked against the wrong family:

[
 [{"subnet":"10.50.0.0/16","ipRange":"10.50.1.0/24","rangeStart":"10.50.1.1","rangeEnd":"10.50.1.255","gateway":"10.50.0.1"}],
 [{"subnet":"fd00:50::/64","ipRange":"fd00:50::/120","rangeStart":"fd00:50::1","rangeEnd":"fd00:50::ff","gateway":"fd00:50::1"}]
]

@mayur-tolexo mayur-tolexo marked this pull request as ready for review June 29, 2026 16:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant