Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Lima binds only on IPv4 #1540

Open
heyvito opened this issue May 15, 2023 · 2 comments · May be fixed by #1541
Open

Lima binds only on IPv4 #1540

heyvito opened this issue May 15, 2023 · 2 comments · May be fixed by #1541

Comments

@heyvito
Copy link

heyvito commented May 15, 2023

Description

Hey there, folks!
I just stumbled on a rather odd thing, and at the time I wasn't sure what was happening:

I’m using Colima, and for some reason, after starting a container through docker compose run --rm -p 3000:3000 service-name, another process managed to bind to the same port.

Initially, I thought the process was incorrectly indicating that it was listening on the port the container allocated, but no. If I tried to curl to port 3000, I hit the container, but my browser (tested with Arc and Safari) hits the other process!

Upon further inspection (thanks to Colima creator), I understood Lima's port-forwarding mechanism was only binding to the host's IPv4 address, leaving the IPv6 address free, and so allowing other applications to bind to this other address.
After finding this I thought it was just a matter of allowing IPv4 bindings to also use the IPv6 address, but I guess I'm wrong.

PS: I'm totally willing to contribute with code, if it's okay; I woudl need some directions, though.
@jandubois
Copy link
Member

In general it is completely reasonable that the same port on different interfaces can be bound to different applications.

But I can see at least for binding to INADDR_LOOPBACK and INADDR_ANY it makes sense to have an option to forward to INADDR6_LOOPBACK or INADDR6_ANY as well.

Is that what you are looking for?

Generalizing the issue, here are a couple of questions we should think about:

  • Do we need to support forwarding from IPv6 inside the guest?

    I think not, but please let me know if there are use-cases.

  • Do we need to support forwarding to a specific IPv6 port on the host, that is neither :: nor ::1?

    I have no idea. If we do, then hostIP needs to support IPv6 addresses.

  • Do we need to support forwarding to a dual stack address that is neither 0.0.0.0/:: or 127.0.0.1/::1?

    If we don't, then we could just add a dualStack: true setting to the forwarding rules that only works for 0.0.0.0 and 127.0.0.1. But if we do, then we would need an extra hostIPv6 field.

    Again, I don't know if this complexity is necessary.

Mostly unrelated, but it occurred to me that it could be useful to specify a host interface name as the hostIP value, e.g. hostIP: en0. The user would no longer need to lookup the host IP address, and we could bind to all the addresses for this interface (if we implement multi-interface forwarding).

@jandubois
Copy link
Member

After discussion this further on Slack with @heyvito it became clear that the goal is just to support forwarding IPv6 ports to the host, and not about forwarding a single port to multiple interfaces.

This will be much simpler and #1538 almost implements this, so should be re-opened. I was just confused because the original PR was trying to forward a single IPv4 port to both an IPv4 and an IPV6 port on the host (which wouldn't work), but that was a bug and not intentional.

@heyvito heyvito linked a pull request May 15, 2023 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

feat(ipv6): Add support to IPv6 port-forwarding heyvito/lima
2 participants
@heyvito @jandubois