gvisor-tap-vsock
gvisor-tap-vsock copied to clipboard
containers
WIP: IPv6 support
This PR adds IPv6 support. I still need to refactor some code esp. the 2 hacks needed.
At least, we have something working!
[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: guillaumerose
The full list of commands accepted by this bot can be found here.
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment
![openshift-ci[bot] avatar](https://avatars.githubusercontent.com/in/91280?v=4 "Published by a pub.dev verified publisher"){kind=small}
@guillaumerose: PR needs rebase.
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
No, not anymore but it was working fine. A user tested it also with success.
I do not see a compelling benefit for our VM setup.
The rebase is quite trivial, but we do not have much time on our end to experiment with this. as mentioned it is not a compelling change for us. OpenShift has to run in a dual stack setup and has to use OVN-Kubernetes cluster network provider, which in our tests consumes a lot more resources (which causes the current defaults to be insufficient).
It need rebase and also WIP so better someone who have bit info around ipv6 test/review it.
@gbraad the value is that this would just prepare the codebase for the future. ipv4 is a relic of the past that's on life support because it's "good enough" right now while companies struggle to get subnet assignments.
I understand, but there is no one on my team who can reserve time for this in the coming weeks. As this is not something we can use now. It will actually adversely affect us if we fully support this. Our prio is on filesharing to running on Arm/M1.
Note: routes are exposed on the local machine for crc. The internal network (vm) is mostly abstracted from the user. This is why the benefits arent as big on our end.
The only requests we received were around 'testing' and 'getting experience', though our primary usecase is for development of applications running on the cluster.
Added to sprint 223 of CRC; but can't promise we will work on this.
It need rebase and also
WIPso better someone who have bit info around ipv6 test/review it.
The 'hacks' remains a commit without clear definition what made them called as such.
It's definitely nowhere near urgent to get this rolled out. In December, I could put some effort into this. This was something I tried working on last year, but I ran out of time last year.
We prioritized this as part of the crc Podman bundle. Definitely will happen before December. Might ask you for testing/confirmation. After my PTO have to reinstall my router and switch anyway due to a mistake so will make Ipv6 a priority 😝.
Might ask you for testing/confirmation.
Definitely happy to help out with that. Even though I left Red Hat earlier this year, I still have a vested personal interest in tools like gvproxy.
I still have a vested personal interest in tools like gvproxy.
What are you using it for?
Been working on using Apple's virtualization framework in place of QEMU for some stability + performance gains to be had with the virtiofs support. Qemu hasn't been very fun since upgrading to the M1 in my experience, but I have a desire to continue using podman over Docker Desktop.
Also have a code base that I'll be revisiting from last December where I began working on a re-write for gvproxy. It's not exactly secure, because of the access to 192.168.127.1 inside of containers.
@protosam We have a driver for this, vfkit that uses vz. However we recently had to fork this driver as the upstream owner is not very helpful: https://github.com/code-ready/crc/issues/3362 it might be an idea to talk to @cfergeau.
@gbraad Will follow up in that issue. I'm open to contributing on an eco-system around the vz code base, because I'm already using it.
I've rebased this branch in https://github.com/cfergeau/gvisor-tap-vsock/tree/ipv6 it builds but I haven't tested it.
Any plans for this feature ??
I tried this patch with latest but facing issues not able to resolve it 😕
@cfergeau Why is it low priority? IPv6 is very essential and basic on nowadays' Internet?
@sanmai-NL The nowadays internet is still mostly IPv4 based. As an example, GitHub does not even have an IPv6 address, so it means you have to run a hybrid stack (or proxy).
Since we have to prioritize tasks to work on, we have decided first to resolve the virtualization of Podman Machine on macOS and moving to vfkit (instead of Qemu); we experienced issues with qemu+virtio. After this we will first refactor the codebase and improve the buffers. IPv6 will happen at some point, just need to be more strategic. Hope you understand.
Do you have a specific usecase that otherwise will not work?