WIP: IPv6 support #59
Conversation
|
[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.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
It used by NDP protocol.
|
@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. |
|
@guillaumerose Are you still working on this? |
|
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 |
|
@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. |
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 😝. |
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. |
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 |
|
@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: crc-org/crc#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 😕 |
|
Feature is planned, but very low priority at the moment :-/ |
|
@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? |
Our company network is IPv6 only. Which makes pulling from our internal registry impossible using Podman Desktop (and Docker Desktop) on mac. Just found out the hard way. |
This PR adds IPv6 support. I still need to refactor some code esp. the 2 hacks needed.
At least, we have something working!