I didn't know BSD had an IPv4/IPv6 translation mechanism built-in. On Linux the state of the art seems to be Jool[1], which is unfortunately an out-of-tree kernel module. IIUC, they currently share the limitation of not being able to translate locally-originated packets, which can be annoying unless you have a machine to dedicate to the translation.
Wait this looks interesting. I am a biologist so I might get the terminology wrong. Would this allow me to run a ipv4 to ipv6 and back service?
I got some services with only ipv6 addresses and want clients with only ipv4 (sadly still exists) to at least be able to reach them. So could I dedicate a machine to translating for them using this tool?
Yes, translating packets between IPv6 and IPv4 is precisely what Jool does.
From what you're describing I think you have to options: if you have enough IPv4 addresses at your disposal to cover your IPv6-only machines, you can use the so called "SIIT-DC" mode [1].
Otherwise, if you have less IPv4 addresses, say just one on your router, and multiple IPv6 machine you can setup a stateful NAT64 [2] with some static BIB entries. NAT64 is basically the familiar NAT, just with IPv6 in the LAN instead of private IPv4 addresses (say 192.168.1.0), and static BIB entries are the equivalent of port forwarding.
In this case you would run Jool on your router.
I am using socat right now to achieve this translation but it is rather slow. So o hope a proper solution using tool might be more powerful. But it seems it requires at least a bit more networking insight than what I have at this moment.
It's an opportunity to learn something new for me
Right now I simply rent a hetzner machine including a v4 ip to route the traffic to my V6 services.
However, I personally would just do it in userspace, especially for that simple of a use. I'm doing the opposite; I have a webapp that somehow doesn't handle IPv6, so to access it over a pure-v6 network I just run this on the same host:
socat TCP6-LISTEN:8002,fork TCP4:127.0.0.1:8000
I believe you could trivially reverse this;
socat TCP4-LISTEN:8002,fork TCP6:[::1]:8000
should serve [::1]:8000 as 0.0.0.0:8002 (I don't remember if changing ports was strictly required; that may be a quirk of my exact setup).
The point of Jool and similar tools (there is also one called Tayga that runs in userspace, if you want) is to translate network traffic between multiple hosts, where some only have IPv6 and others only IPv4 addresses.
If your machine has both IPv6 and IPv4 addresses you don't need to any translation.
I interpreted "services with only IPv6 addresses" as IPv6-only servers, in which case some sort of translation is needed, but if these are just processes in a dual stack server, then yes.
6to4 solves a different problem: it's a way to provide IPv6 internet access to some host with only IPv4 internet access. It's basically a VPN you need to configure on the client.
NAT64 and SIIT (what Jool and af-to are implementing) instead are a way to let (potentially) any IPv4-only client to connect to some IPv6-only machine you control. The client need to be aware its actually talking to an IPv6 machine, because there is a translator (typicall a router between them) that transparently translate the packet so they understand each other.
The easiest change to make to pf is making BC breaks to everyone’s firewall config which OpenBSD has done multiple times. If you want to make ipv6 nice great. Please do not break users’ existing configs to do it. TDR is wrong and breaking BC for syntax sugar is not better for security it’s better for losing users.
I don't necessarily disagree that backwards compatibility is valuable, but (as you kind of note) if that's your priority then OpenBSD is probably a poor choice anyways.
I didn't know BSD had an IPv4/IPv6 translation mechanism built-in. On Linux the state of the art seems to be Jool[1], which is unfortunately an out-of-tree kernel module. IIUC, they currently share the limitation of not being able to translate locally-originated packets, which can be annoying unless you have a machine to dedicate to the translation.
[1]: https://nicmx.github.io/Jool/en/intro-jool.html
IIRC, that limitation of Jool can be avoided by running instances in different network namespaces. Some examples here: https://nicmx.github.io/Jool/en/usr-flags-instance.html
Jool’s site also has really great articles and diagrams on different translation techniques. Highly educational. I know it’s really helped me.
Wait this looks interesting. I am a biologist so I might get the terminology wrong. Would this allow me to run a ipv4 to ipv6 and back service?
I got some services with only ipv6 addresses and want clients with only ipv4 (sadly still exists) to at least be able to reach them. So could I dedicate a machine to translating for them using this tool?
Yes, translating packets between IPv6 and IPv4 is precisely what Jool does.
From what you're describing I think you have to options: if you have enough IPv4 addresses at your disposal to cover your IPv6-only machines, you can use the so called "SIIT-DC" mode [1].
Otherwise, if you have less IPv4 addresses, say just one on your router, and multiple IPv6 machine you can setup a stateful NAT64 [2] with some static BIB entries. NAT64 is basically the familiar NAT, just with IPv6 in the LAN instead of private IPv4 addresses (say 192.168.1.0), and static BIB entries are the equivalent of port forwarding. In this case you would run Jool on your router.
[1]: https://www.jool.mx/en/siit-dc.html
[2]: https://www.jool.mx/en/run-nat64.html
[3]: https://www.jool.mx/en/usr-flags-bib.html
I appreciate your reply. Thank you.
I am using socat right now to achieve this translation but it is rather slow. So o hope a proper solution using tool might be more powerful. But it seems it requires at least a bit more networking insight than what I have at this moment. It's an opportunity to learn something new for me
Right now I simply rent a hetzner machine including a v4 ip to route the traffic to my V6 services.
I think this would allow that, yes.
However, I personally would just do it in userspace, especially for that simple of a use. I'm doing the opposite; I have a webapp that somehow doesn't handle IPv6, so to access it over a pure-v6 network I just run this on the same host:
I believe you could trivially reverse this; should serve [::1]:8000 as 0.0.0.0:8002 (I don't remember if changing ports was strictly required; that may be a quirk of my exact setup).I did that with forwarding to another host but it's super slow (10 Mbit) on a cheap hetzner box. So I am looking for this functionality but faster
The point of Jool and similar tools (there is also one called Tayga that runs in userspace, if you want) is to translate network traffic between multiple hosts, where some only have IPv6 and others only IPv4 addresses.
If your machine has both IPv6 and IPv4 addresses you don't need to any translation.
Sure, but if your goal is
> I got some services with only ipv6 addresses and want clients with only ipv4 (sadly still exists) to at least be able to reach them.
then that seems like overkill. Although it depends on your network, of course.
I interpreted "services with only IPv6 addresses" as IPv6-only servers, in which case some sort of translation is needed, but if these are just processes in a dual stack server, then yes.
you could also try using 6to4 or somesuch but this is new to me as well. Interested!
6to4 solves a different problem: it's a way to provide IPv6 internet access to some host with only IPv4 internet access. It's basically a VPN you need to configure on the client.
NAT64 and SIIT (what Jool and af-to are implementing) instead are a way to let (potentially) any IPv4-only client to connect to some IPv6-only machine you control. The client need to be aware its actually talking to an IPv6 machine, because there is a translator (typicall a router between them) that transparently translate the packet so they understand each other.
Thanks!
The easiest change to make to pf is making BC breaks to everyone’s firewall config which OpenBSD has done multiple times. If you want to make ipv6 nice great. Please do not break users’ existing configs to do it. TDR is wrong and breaking BC for syntax sugar is not better for security it’s better for losing users.
I don't necessarily disagree that backwards compatibility is valuable, but (as you kind of note) if that's your priority then OpenBSD is probably a poor choice anyways.