erver (RDNSS). The DNS64 functionality only gets triggered when the server is queried for AAAA resource records for destinations not having AAAA records. The A resource record queries are always handled in a 'traditional' way. 3. The subscriber is provisioned with a dual-stack APN for all its needs, that is, whether the UE activates an IPv4-only, IPv6-only, or IPv4v6 PDN Connection. The other Deploying IPv6 in 3GPP Networks configuration for the APN may be migrated from some existing APN configuration just by conducting a mass update for the PDN type. There is not necessarily a need to create a new APN and corresponding configuration. 4. Should plain IPv4 PDN Connection use be de-preferred, then the PGW can be made to reject PDN Type IPv4 context activation attempts. Such configuration would favor both IPv6 and dual-stack (IPv4 would only be possible when using dual-stack). In the above example, there are cases where the DNS64 server is accessed and AAAA resource records unnecessarily synthesized even if there is no need for any NAT64 service, that is, the dual-stack case. We argue that the effort to build an environment where this does not happen or adding other tricks to differentiate between a 'native' AAAA query versus IPv6-only query may not be worth it. Depending on the terminal capabilities and provisioning, there may not be any need to push new APN configuration into devices. There is probably a need to update an existing configuration for IPv6, though. It is, of course, possible to provision a separate APN for IPv6-only connectivity with a NAT64 service, and then push that into the mobile devices. Nearly Stateless NAT64 Deployment Reusing NAT44 Typically mobile operators have already deployed a highly scalable NAT44 service using mature technologies for their ever-increasing IPv4 demand when the numbering resources have in practice been already exhausted. There might be little incentive to invest in another flavor of high end NAT cluster - the NAT64 cluster. When the percentage of IPv6 traffic increases,