, though), the stateless NAT64 can extract the private IPv4 address out of the IPv6 source address on the fast path and concatenate it with the provisioned upper bits of the private IPv4 address pool. The resulting IPv4 address is then used as the source address of the translated IPv4 packet. The rest of the NAT64/DNS64 operation for resolving the IPv4-converted IPv6 address for the destination node in the IPv4 Internet goes as with any NAT64/DNS64 deployment. The translated IPv4 packet is then routed towards the existing NAT44 - just as possible native IPv4 traffic UE might originate. Moreover, if the existing NAT44 device already performs other operator-specific functions (e.g. access control, charging, policy control) then this extra function remains there without any change and does not add any load to the PGW where the NAT64 is located. Figure 5.7 illustrates a possible (nearly) stateless NAT64 deployment that reuses the existing NAT44 function. Why then do we refer to the above idea as 'nearly stateless'? In 3GPP the network has no control over the IID that the UE is using beyond link-local addresses. And what we described earlier has no means of preserving the information of the IID that the UE was using. That is where the 'nearly stateless' originates. The NAT64 (preferably in the PGW) has to record the used IID for each translated IPv6 and IPv4 address pairs. That is still fairly resource conservative but adds some level of undesired connection tracking. Moreover, if the UE is using privacy addresses [31], there can potentially be multiple overlapping entries when the UE changes the source IPv6 address. That would mean that the NAT64 needs to start looking into additional information beyond the IP header, which basically destroys the whole idea of statelessness. If 3GPP architecture would allow using DHCPv6 for the address assignment, we could achieve the stateless NAT64 function. Another enhancement to the (nearly) stateless idea is to assign private IPv4 addresses from the pool, say, in increments of f