If you want to help this service in the mission to promote IPv6 you can do so by running an IPv6 peer on a host with a suitable IPv6 connection.
Other reasons for running an IPv6 peer is that you need a NAT64 prefix. You and other people in the same position can share NAT64 prefixes among each other to have redundant network paths.
NAT64 prefixes operated by this software are public NAT64 prefixes. You get to choose how much bandwidth you will allow it to use.
The software offered on this page provides a proof-of-concept Python implementation of the protocol which has been tested on Ubuntu 20.04. The software may also work on other platforms.
In order to run an IPv6 peer you need a routed prefix. Your provider should already have provided you with such a prefix with a typical length being /48 or /56. If the provider only gave you a routed /64 they are cheap, but it's still sufficient to run a peer. In addition to the routed prefix you need access to a reliable Teredo relay because this service uses modified Teredo in order to establish communication between IPv6-only and IPv4-only peers. Your network provider may already have given you this access possibly through relays offered by a transit provider. If you have a public IPv4 address you can alternatively choose to run your own Teredo relay. I recommend the Miredo software which includes a very robust Teredo relay implementation.
The software is available as a .deb package for easy install. This package is tested on Ubuntu 20.04.
During install you will be asked for a /80 prefix to use for NAT64. It must be globally routable addresses RFC 4193 addresses will not work for this service.
If you are technically inclined you can also choose to download the source using this command:
hg clone https://p2p.nat64.dk/p2p-nat64-v6peer
There is a theoretical possibility that people who don't understand how NAT64 works will file false claims about you hosting content they dislike.
I regard this as a theoretical risk as I have no knowledge of this ever happening. However I still want to explain how I would respond to such claims.
Write a polite reply explaining that the complaint is based on a misunderstanding. Explain that the prefix in question is a NAT64 prefix and that using the prefix or not is their own choice. Additionally explain that complaints about content should be directed to the owner of the embedded IPv4 address which follows the specification in RFC 6052.
If the IPv4 address in question turns out to not be globally routable explain that in that case any further inqueries will have to be directed to the IPv4 peer. Mention that the specification in RFC 4380 can be used to find the IPv4 peer.
In all cases keep in mind that you have not violated any rights of the individual filing the complaint. They however have violated your rights by using your peer in violation with the terms of service.