Support IPv6 port forwarding (libslirp 4.5)

[AkihiroSuda]

libslirp@master recently gained support for IPv6 port forwarding.

https://gitlab.freedesktop.org/slirp/libslirp/-/commit/0624fbe7d39b5433d7084a5096d1effc1df74e39

https://gitlab.freedesktop.org/slirp/libslirp/-/merge_requests/75/diffs

slirp4netns should support this.

[pfandl]

@AkihiroSuda hi, i could as a test get it working but it needs a patch to libslirp as well, as we possibly are listening to ipv4 already the bind with ipv6 has to happen with IPV6_V6ONLY socket option. Another option would be to listen to ipv6 in the guest only, and forward ipv4 there.

The guest ipv6 for the forwarding is also hardcoded to fd00::100 because we get the actual random? ip after we are trying to forward the ports, and it would probably need another ready fd or whatever mechanism to get this working on the guest ip.

[AkihiroSuda]

Thanks for working on this.
I think we want to avoid hard coding IPv6 addresses: #259

[AkihiroSuda]

And I think we want to prioritize IPv6-to-IPv4 forwarding rather than IPv6-to-IPv6 forwarding, although we will eventually need both.

[pfandl]

Thanks for working on this.
I think we want to avoid hard coding IPv6 addresses: #259

I saw that and tried to follow it first but I think there is much more work needed for it.
When I tried to read the IPv6 address from /proc/net/if_inet6 or whatever the path
was, can't remember, at the point of where we would bind the ports, the address is not
yet available. It comes later after NDP router advertisement. Therefore we kind of would
need to remember what ports we want to bind and delay it for after that moment and
also then I guess we want to inform the user that the IPv6 stack is ready?

Mind me being new to this and probably I got something wrong, that was my experience
so far.

EDIT:

It seems only the Global ID has to be random, the subnet and interface ID dont have to be, right?
If we can randomize the Global ID at startup and just add :100 to that for the internal interface
IP we should be good to go. Alternatively we can let the user choose a self generated random
prefix and possible even the internal interface IP and work with that. Then we would have to stop
the initial router advertisement so that we don't end up with two subnets, the automatic (currently)
one and the one the user chose.

[pfandl]

And I think we want to prioritize IPv6-to-IPv4 forwarding rather than IPv6-to-IPv6 forwarding, although we will eventually need both.

There is a problem when forwarding IPv6 to IPv4, the whole device gets kind of reset, and has no ip addresses anymore
as soon as you write something to the port. I am not sure where the problem is, could be in libslirp.

Anyway what works so far:

• we can pass --cidr6=fd00::/64 and a fd00:aaaa:.... network will be generated
  • we take the mac of "lo" device for random id generation, it is zero, we need something else
• we can pass --cidr6=fd00:aaaa:bbbb:cccc::/64 and this will be the network
• IPv6 to IPv6 forwarding works with a patch to libslirp.txt

Not sure how to proceed, any input?

Also, if somebody wants to take it from here, please just say so and go ahead.

[53c70r]

What is the status of this important issue?

[53c70r]

If there is another way to seamlessly signal the correct remote IP to the inner container and support IPv4 + IPv6 I would appreciate to know the solution.

[AkihiroSuda]

What is the status of this important issue?

Waiting for a PR

[su-ex]

If there is another way to seamlessly signal the correct remote IP to the inner container and support IPv4 + IPv6 I would appreciate to know the solution.

I guess pasta is the way to go: containers/podman#16141 🍝

[53c70r]

That's it, thx. @su-ex

[mstrauss]

I guess pasta is the way to go: containers/podman#16141 🍝

Little OT, but I have gone this road. I tested pasta this week and had nothing but troubles with it. Failed inbound TCP connections (with HAproxy), flapping services (falsely) reported by Nagios and so on. The only thing I got working fine so far under Pasta was hitch+varnish (with IPv6 on the frontend, yes!).

So please, I would really like to encourage the devs/maintainers of slirp4netns to tackle this important IPv6 related issue. Thank you.

[AkihiroSuda]

So please, I would really like to encourage the devs/maintainers of slirp4netns to tackle this important IPv6 related issue.

Feel free to submit a PR.