Lima binds only on IPv4

[heyvito]

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]

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]

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.