 the investment put into NAT64 probably cannot be that easily justified, as at the same time there is increasing amount of freed capacity in the existing NAT44 deployment. The authors have been thinking that it would be possible to capitalize the existing NAT44 by introducing a (lightweight) nearly stateless NAT64 function into the network. The driver behind this is that the fewer states a device has, the better it scales. If the translation were entirely algorithmic, it would enable it to have similar capability to MAP and 6RD anycast based reachability of NAT64 functions (see Section 5.3.6). Such a stateless NAT64 function could easily be implemented as an integrated feature into the PGW. The idea of (nearly) stateless NAT64 solution in a nutshell is the following. During the PDN Connection activation the UE is assigned a /64 IPv6 prefix that embeds both base IPv6 prefix and the lower bits of a private RFC 1918 address - see Table 5.2 for addressing examples. The APN where the stateless NAT64 has been enabled must be provisioned with the base IPv6 prefix, a private IPv4 address pool and prefix lengths for both. When using 10.0.0.0/8 range a maximum of 16 million mobile devices can be Table 5.2 IPv6 address for NAT64 purposes APN base prefix Private IPv4 Constructed IPv6 prefix Private IPv4 pool 2001:db8:1100::/40 10.0.32.1 2001:db8:1100:2001::/64 10.0.0.0/8 2001:db8:1120::/44 172.16.64.3 2001:db8:1120:4003::/64 172.16.0.0/12 2001:db8:1122::/48 192.168.128.2 2001:db8:1122:8002::/64 192.168.0.0/16 IPv6 Transition Mechanisms for 3GPP Networks DNS64 Stateless ((q)) NAT64 NAT44s Internet (4) Private IPv4 Public IPv4 (7) Private IPv4 Router Native IPv6 Figure 5.7 An example of DNS64 and a stateless NAT64 with a reused NAT44 function. numbered within one routing domain (since there can be overlapping private IPv4 address spaces, care must be taken that these areas are separated somehow). When each UE in a specific APN has a unique "IPv4-translatable IPv6 address'-like address (not exactly as such according to RFC 6052