It's a little different because all the ipv4 tunneling protocols were invented either for or to counter that. NAT64 is usually done at the ISP's gateway and the

It's a little different because all the ipv4 tunneling protocols were invented either for or to counter that. NAT64 is usually done at the ISP's gateway and the public IPv4 (at least) is shared with thousands of other customers. (With such internet connections you are always classified as a bot/spam with captcha services that don't understand IPv6 btw) As a customer, you cannot influence the IPs and neither the ports that get routed through, so you have to connect to a server that you host somewhere else, just for the purpose of tunneling the traffic. So the server at home is actually a client that reconnects to the reverse proxy as there's no other way to have the open connection. I saw a big chance for WebRTC data channels to fix exactly that, but I've given up because Google and Mozilla both put a lot of restrictions in the protocol to make it unfeasible for this use case. And this kinda applies for most cable internet providers in Europe because RIPE ran out of IPs a long time ago. On one hand we got Daimler blocking a whole /8 subnet, and on the other hand we have ISPs that have less than 16 IPv4s. Doesn't make sense to me how this is handled tbh. [1] https://en.wikipedia.org/wiki/NAT64 https://en.wikipedia.org/wiki/NAT64