our addresses: 10.0.0.0, 10.0.0. 4, 10 0. etc. When a new IID is seen for one IPv6 prefix constructed out of the assigned pri- vate IPv4 address, then up to four simultaneous IIDs can be mapped back and forth to the same /64 IPv6 prefix and to four different private IPv4 addresses with minimal Deploying IPv6 in 3GPP Networks Table 5.3 IPv6 address for NAT64 and interface identifier mapping purposes UE IPv6 address Assigned IPv4 address Mapped IPv4 address for NAT44 2001:db8:1100:4::e/64 10.0.0.4 /30 10.0.0.4 2001:db8:1100:4::2/64 10.0.0.4 /30 10.0.0.5 2001:db8:1100:4::a/64 10.0.0.4 /30 10.0.0.6 2001:db8:1100:4::9/64 10.0.0.4 /30 10.0.0.7 2001:db8:1100:8::e/64 10.0.0.8 /30 10.0.0.8 2001:db8:1100:8::5/64 10.0.0.8 /30 10.0.0.9 2001:db8:1100:8::1/64 10.0.0.8 /30 10.0.0.10 2001:db8:1100:8::b/64 10.0.0.8 /30 10.0.0.11 state maintenance. The approach is slightly wasteful on IPv6 prefixes (which should not be an issue in practice) and still has some session state in the NAT64. Table 5.3 shows how the mapping works for a base IPv6 prefix 2001: db8 1100 : : /40, a pri- vate IPv4 pool 10.0.0.0/8 with four address increments, and two UEs with IPv6 prefixes 2001 db8 1100 : 64 and 2001 db8 : 1100 8 : : / 64. Four reserved IPv4 addresses actually equal a /30 subnet for one /64 IPv6 prefix. NAT64 and DNS64 Issues NAT64 (and also DNS64) has a number of issues that cast shadows on prominent IPv6 deployments. Two known problems relate to the use of IP literals as referrals or inside pay- load protocols, and how to deal with verifying DNSSEC [11] resolvers will be discussed in more detail in the following section. There is a class of applications that do not work through NAT64 [32]. Some of these applications may, on the other hand, work just fine through a normal NAT44. The problem is the assumption that the IP address family does not change, and therefore the NAT- traversal solution within the, typically closed, protocol and implementation just does not work. The inherent cause of these problems is embedding IP literals inside the