Sometimes, one or other (not updated/lazy) application does not support usage when the starting point is an IPv6 address, and all they know is to use an IPv4-formatted address. Despite this, they usually are tolerant to the IPv4 range you're using, allowing you to specify internal IPv4s (which are in the range 10.x.x.x/8, 172.16.x.x/12 - 172.32.x.x/12, or 192.168.x.x/16), since they don't distinguish between addresses.
Due to technology execution specifics, and in order to provide the most automated and effective setup possible, routing IPv6-to-IPv4 and IPv4-to-IPv6 has to happen external to the VPS, at the dedicated server level really, and we do not provide right away an internal (10.x, 172.x, 192.x) IPv4-formatted address, rather immediately giving the external IPv4 NAT and your public IPv6 (the public IPv6 effectively also acting as an IPv4).
However, if your application only accepts IPv4-formatted addresses (and allows internal ones), you are always free, as you can do with any Linux box, to add your own internal IPv4 under that address range, and then use socat to directly route, socket-to-socket, traffic that comes or goes to the IPv6 into your internal IPv4 (and the other way around, 4-to-6) in a per-port, per-protocol basis.
Packets that arrive in your VPS from IPv6 are already complete, the redirection is entirely internal at the TCP/IP stack level, and this has been a solution used for quite a while now.
Socat works TCP/UDP, from IPv4 to IPv6, and from IPv6 to IPv4. Examples of commands are:
socat UDP4-LISTEN:10683,fork,su=nobody UDP6:[aaaa::212:4b00:615:a1f7]:10683 » says to listen for UDP at port 10683 on the internal IPv4 VPS IP, routes to IPv6 at the given address and at the same port.
socat TCP6-LISTEN:10022,fork TCP4:172.16.0.2:10022 » says to listen for TCP under IPv6 at port 10022 on the given IPv6 address, routes to IPv4 VPS internal IP stack at the same port.
Bear in mind that if what you need to do is permanent and needs to stay after reboots, you will need to script that the IPv4 is included upon every boot on your VPS, so that it gets persistence when restarting, and it may be also a good idea to do the same to socat.
Solus VM 2 has cloud-init, which provides the network info upon every boot, erasing the previous information unless a user automates the process of including an IP upon boot on their VPS (which, since it originates from userspace, never collides with cloud-init). crontab or similar scripting tools may be interesting for this.
This solution will fix most issues with IPv4-only applications.