On Thu, 6 Jan 2011, Matthew Kaufman wrote:
If one end is behind a NAT64 and there is no mechanism for discovering the NAT64's IPv6 interface prefix and mapping algorithm (and at present there is not), there is no way to send IPv6 IP packets from the IPv6-only host to IPv4 literal addresses (that is to say, addresses learned via a mechanism other than DNS responses synthesized by the DNS64 part of the NAT64 "solution") on the IPv4 Internet through said NAT64.
There has been discussions on v6ops mailinglist about BIH (Bump In Host) for mobile applications, so that one could create a client on the machine behind NAT64 and make it work work with programs that use v4 literals (or have no v6 support at all). It though seems there is considerable resistance within the IETF community against such solutions as (I've been told) history has shown there to be a lot of problems with this kind of double translation. Therefore the IETF seems to lean towards tunneling of IPv4 over IPv6 to give such a host literal IPv4 connextivity (could be called 4RD) instead of doing translation. For mobile applications, single stack on the access is to only realistic method in the next few years, therefore this needs to be solved somehow. 3GPP doesn't like tunnels though (since they already do tunneling), so right now there isn't really broad agreement on how to solve this. Personally I think we need some kind of transitioning mechanism to handle v4 only applications and v4 literals in the forseeable future, just like we needed trumped winsock in the 90ties, we're going to need full v4 connectivity for Windows XP (applications + dns transport) over v6only access. -- Mikael Abrahamsson email: swmike@swm.pp.se