Welcome to the messy world of the IPv6 transition.
IPv4 and IPv6 are two seperate protocols that do not directly interoperate.
The IPv6 proponents idea was that we would all move to dual stack, running IPv4 and IPv6 in parallel for a transition period. Then once IPv6 was ubiquitous IPv4 could be turned off.
Unfortunately deploying dual stack meant extra cost immediately for benefits at some unclear time in the future. Unsurprisingly takeup was extremely slow and IPv4 exhaustion hit without the world being dual-stacked.
Most IP transit providers nowadays will provide dual-stack, but with mobile and broadband ISPs the picture is often a lot less rosy.
So anyway back to the question of of interoperation. Since it is clear that in the real world IPv4 isn't going away any time soon a variety of mechanisms have been devised to try and bridge the gap.
The first and simplest is just a point to point tunnel, such tunnels can be pretty reliable and with the right tunneling technologies can work behind NAT. The problem is of course the tunnel has to terminate somewhere. There exist free tunneling providers but they are not without their issues in terms of performance and/or restrictions.
The next is 6to4. A host or network with non-natted IPv4 only connectivity can generate an IPv6 /48 from their public IPv4 IP. Packets from 6to4 clients are encapsulated in IPv4 and can be sent to other 6to4 clients or to a relay anycast address. Unfortunately it doesn't work behind NAT
The next thing to mention is teredo. Teredo tries to provide IPv6 addresses to clients behind NAT using NAT traversal techniques. Unfortunately it is pretty fragile and often fails. Also due to the way teredo finds relays it will only work if the IPv6 host responds to pings.
Also ISPs mostly don't seem to have stepped up to the plate and deployed 6to4 and teredo relays in their networks, so 6to4 and teredo traffic ends up going via one of a handful of networks who provide relays for the internet in general. This often ends up limiting performance.
Teredo and 6to4 have largely failed to achive increases in the ipv6-capable client base. It has become clear that while IPv6 deployment is growing, the burden of interoperability will have to be shouldered by those wanting to run IPv6 only networks.
Which brings us round to how they can do that. Probablly the most common approach for clients is NAT64/DNS64. The network translates DNS A responses into AAAA responses pointing at a range of IPv6 addresses that are routed to stateful NAT64 boxes. The NAT64 boxes translate the traffic from IPv6 to IPv4 allowing clients to reach servers on the IPv4 internet. An extension of this is 464XLAT where the client has a stateless NAT46 allowing IPv4 only applications to send requests via the NAT64.
On the server side NAT based approaches can also be possible, but they have the problem that you still need an IPv4 address for each server which defeats most of the point of running an IPv6 only network. Another option is reverse proxies which can direct traffic based on application layer headers.
Unfortunately trying to run services on your cellular modem is likely to be an excercise in frustration. As you say it doesn't have an IPv4 addresses and while it probablly does have a public IPv6 address you may still find there are firewalls present and that the IPv6 address is not very stable.
In general I find the best approach to administering devices that are in unknown network situations is to use a VPN. Have a server on the public internet (preferablly dual stack) to which all your devices can connect and then access the devices using their VPN IP addresses.
