In cellular environments it can actually be the mobile phone that is provided IPv6-only connectivity by the network, and the mobile needs to act the role of CPE (to be more exact, the mobile with IPv6-only connectivity may be running IPv4-only apps and it may have IPv4 LAN behind it, for which mobile needs to provide (NATted) addresses).
[...]
- Availability of translation mechanism service SHOULD be quickly discoverable- Legacy IPv4-only applications on IPv6-nodes MUST continue working
The problem with IPv4-only applications in an IPv6 world is that there is no way to encode all possible IPv6 destinations into an IPv4 header. However, the case where the ultimate destination is also IPv4 and it's just the network in the middle that's IPv4 is much easier.
In a previous modified-nat-pt draft I wrote about the v4-v6-v4 case where IPv4 clients sit behind a CPE or layer in the stack that translates their IPv4 packets into IPv6 packets using SIIT (= stateless) and then the resulting IPv6 packets flow through the same NAT64 translators that IPv6 hosts that want to talk to the IPv4 world also use.
Expect to see a new or updated draft on this topic before Dublin.I'm currently looking at defining a new DHCPv6 option that would allow NAT464 devices/layers to discover the 96 upper bits used by the NAT64 translator. Would DHCPv6 be fast enough for your use case?
In a mobile environment, a NAT464 could obtain a new /96 for a new translator when it moves and send new sessions through the new translator while existing sessions keep using the previous translator. This is not ideal from a BEHAVE viewpoint but it would allow for a reasonable amount of route optimization without breaking too much stuff.