You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note that this is inspired by microsoft/Windows-Containers#522 to allow CNI-based tools, e.g., buildkit, containerd-cri, to maintain parity with Docker. I don't have an IPv6-routable network at home, so I can't actually play with this myself right now.
Is your feature request related to a problem? Please describe.
This repo is the main interface between the container ecosystem and HNS/HCN outside moby/libnetwork, and so ensuring that part of the ecosystem is able to coexist and maintain feature parity with moby is important.
This will also help with issues like microsoft/Windows-Containers#386 where IPv4 rules and container networking combine badly with AWS's IMDS service, but where IPv6 is expected to not have the issue.
Describe the solution you'd like
Being able to IPv6-enable stand-alone CNI consumers similar to how IPv4 can be enabled for such consumers using the NAT plugin.
Assume the appropriate network has already been created and rigged to access resources it needs as appropriate.
e.g., something like docker network create if you want to share the same network setup with Docker, or something like nerdctl network create or New-HNSNetwork.
I will note that I haven't given deep thought to whether this should be making the nat plugin dual-stack, or be a new ipv6 plugin and dual-stack users would have two CNI entries. My initial leaning was the former since the existing dual-stack support in L2Bridge exists, but since (I hope) we don't expect NAT to be used in ipv6, that might be a little weird.
Also, we are going to need IPv6-only support at some point; that being "Dual stack with IPv4 configured" isn't necessarily the correct approach. (As noted in microsoft/Windows-Containers#522 HNS can't do IPv6-only right now; I didn't verify if this or any other HNS issue listed there also affects the newer HCN API used by this repo.)
Describe alternatives you've considered
Not doing anything, I guess?
Additional context
I suspect that the work required in this repo will be minimal, since dual-stack support exists for L2Bridge already, so it'll mainly be removing blockers and organising some testing and examples.
So this issue exists to also ensure visibility of microsoft/Windows-Containers#522 and particularly to ensure any decisions made there are not accidentally moby/libnetwork-specific, but can be used by this repo (and any other CNI drivers) too.
The text was updated successfully, but these errors were encountered:
Note that this is inspired by microsoft/Windows-Containers#522 to allow CNI-based tools, e.g., buildkit, containerd-cri, to maintain parity with Docker. I don't have an IPv6-routable network at home, so I can't actually play with this myself right now.
Is your feature request related to a problem? Please describe.
The US Government has a deadline for September 2025 for significant support of IPv6-only deployments and this has prompted the moby/moby maintainers to start a push on getting IPv6 support into their "nat" network driver, and feeding back requirements and pain-points with HNS.
This repo is the main interface between the container ecosystem and HNS/HCN outside moby/libnetwork, and so ensuring that part of the ecosystem is able to coexist and maintain feature parity with moby is important.
This will also help with issues like microsoft/Windows-Containers#386 where IPv4 rules and container networking combine badly with AWS's IMDS service, but where IPv6 is expected to not have the issue.
Describe the solution you'd like
Being able to IPv6-enable stand-alone CNI consumers similar to how IPv4 can be enabled for such consumers using the NAT plugin.
docker network create
if you want to share the same network setup with Docker, or something likenerdctl network create
orNew-HNSNetwork
.I will note that I haven't given deep thought to whether this should be making the nat plugin dual-stack, or be a new ipv6 plugin and dual-stack users would have two CNI entries. My initial leaning was the former since the existing dual-stack support in L2Bridge exists, but since (I hope) we don't expect NAT to be used in ipv6, that might be a little weird.
Also, we are going to need IPv6-only support at some point; that being "Dual stack with IPv4 configured" isn't necessarily the correct approach. (As noted in microsoft/Windows-Containers#522 HNS can't do IPv6-only right now; I didn't verify if this or any other HNS issue listed there also affects the newer HCN API used by this repo.)
Describe alternatives you've considered
Not doing anything, I guess?
Additional context
I suspect that the work required in this repo will be minimal, since dual-stack support exists for L2Bridge already, so it'll mainly be removing blockers and organising some testing and examples.
So this issue exists to also ensure visibility of microsoft/Windows-Containers#522 and particularly to ensure any decisions made there are not accidentally moby/libnetwork-specific, but can be used by this repo (and any other CNI drivers) too.
The text was updated successfully, but these errors were encountered: