In an earlier post I'd mentioned NAT64 and how it allows IPv6 only hosts to communicate with the IPv4 internet by using DNS. 
Today I stumbled upon something great, a public NAT64 server. Rather than using the well known NAT64 prefix, this uses a globally routable prefix for IPv6 meaning that anyone can use this service. Check out NAT64 here: https://nat64.net/. Using them is very simple, all it requires is changing your DNS, and you can do it at home too if you have IPv6(though for speed reasons, you probably shouldn't, since it'll route basically all traffic that'd go over IPv4 through another ISP, which in my example ended up being Mythic Beasts UK, which is hosted in London, adding some time to my requests). If you have an IPv6 only server and would like to be able to connect to IPv4 services(ex github), by changing your DNS entries, you can access them.
I did try it out and guess what, I was able to connect to api.hive.blog over IPv6(come on 
That should be impossible right? When we grab the DNS for api.hive.blog, what we get is:
╰─○ host api.hive.blog
api.hive.blog has address 51.161.87.109
BUT if we set our DNS to one of the servers stated by the public NAT64 server, what we instead get is:
╰─○ host api.hive.blog 2a01:4f8:c2c:123f::1
Using domain server:
Name: 2a01:4f8:c2c:123f::1
Address: 2a01:4f8:c2c:123f::1#53
Aliases:
api.hive.blog has address 51.161.87.109
api.hive.blog has IPv6 address 2a00:1098:2b::1:33a1:576d
api.hive.blog has IPv6 address 2a00:1098:2c::5:33a1:576d
api.hive.blog has IPv6 address 2a01:4f8:c2c:123f:64:5:33a1:576d
Would you look at that, it's got some IPv6 addresses. The top 2 are Mythic Beats, and bottom one is Hetzner. You can also notice that they all end the same way, and if I do a lookup using 
host api.hive.blog
api.hive.blog has IPv6 address 64:ff9b::33a1:576d
Same ending. That's because they all use the same encoding, you can read this article to see more about how that's done.
Of course there are drawbacks to using NAT64, and as such we'd want native IPv6 support from all services.
First off, we are more likely to run into rate limits quicker. The requests still have to exit through an IPv4 address somewhere, and if it's a public NAT64 service, the chance of us running into the rate limit is very high, especially against popular services.
Secondly, we've got added latency. Now normally you'd want the NAT64 server to be very close to you to increase the chance of not having to deal with much added latency, but the public NAT64 service above has exit points in Germany and UK, both of which will add nearly 100ms of round trip latency to my requests. And thats per request, which is going to add up.
We can also trigger VPN detection and such and not even get access to some services that we want, since the exit IP will be the same again. By using it, it acts as a VPN for your IPv4 traffic, as you can see in the following screenshot. My request to grab my IPv4 address exited through a node in Germany.
We do add an additional point of failure. Our above example of the public NAT64 service isn't too great, but if NAT64 is sitting behind a single server, and that one goes down, so does your connection to the IPv4 world.
It only works for DNS driven stuff, if anything is still using hardcoded IP addresses, or attempts to make a connection to an IPv4 address, that will fail. It will only work where DNS works and the IPv6 address from the DNS query is actually used rather than being discarded(cough cough, hived).
