 Protocol V6 0000 be 27 eb la 83 d5 00 Dc 42 f7 ea 46 86 dd 60 00 0010 00 00 00 40 3a 3f 20 01 1b c8 01 01 f1 92 be 27 0020 eb ff fe CC a7 8e 20 01 1b c8 01 01 f1 90 02 00 16 17 18 19 la 1b 1c 1d le If 20 21 234567 File: "/Users/jounkorh/Docu Packets: 331 Displayed: 12 Marked: 0 Ignored: 128 Load time: 0 Profile: Default Figure 5.6 A NAT64 doing translation. port ranges for each source IPv6 address. Also, NAT64 translation with stateful sessions does need processing beyond swapping IP header and possible re-computation of IP and transport protocol checksums. When the session density is high, NAT64 processing also becomes computationally expensive and also something to consider. A standalone NAT64 is actually rather easy to scale up by increasing the number of functional NAT64 nodes. Assuming that each NAT64 function has its own dedicated NSP Pref64 : /n prefix, a simple DNS64 round-robin of multiple Pref64 : /n prefixes distributes the load among a cluster of NAT64 nodes. It should be noted that a 'standalone' NAT64 function can be within the same physical appliance as the rest of the PGW. The level of integration into the rest of the 3GPP system is very low. How NAT64 is then provisioned and deployed in the mobile operator network is another issue. The key information to provision to subscribers is the address of the DNS64-enabled DNS server. This information is typically part of the generic APN or session profile within the PGW. Another issue is then how the subscription profile gets provisioned. Will there be a separate NAT64-enabled APN among others and how is that then provisioned in a Home Location Register (HLR)/Home Subscriber Server (HSS)? One potential provisioning example is as follows: 1. The PGW is configured with a dual-stack capable APN. The APN configuration points to a DNS64 server, which gets assigned to any UE accessing this very APN, indepen- dent of whether the PDN Connection is IPv4-only, IPv6-only (the reason for all this), or IPv4v6. 2. The DNS64 server is used as a caching Recursive DNS S