he host has both IPv4 and IPv6 in use in parallel, it does not mean that they are both equally good. The IPv4 may suffer from the restrictions mentioned above, but also for communicating to Internet destinations different address families may be providing different characteristics, such as latency, bandwidth, and even lack of connectivity, when communicating towards a destination. This is due to fact that as IPv4 and IPv6 practically form different networks, the routing of IPv4 and IPv6 packets may use different routes. To tackle these sorts of issues hosts can utilize the Happy Eyeballs approach to find out which address family yields better results - generally or per destination - see more in Section 3.9.4. 5.3.3 NAT64 and DNS64 NAT64 [12, 14] and DNS64 [26] are based on the framework for IPv4/IPv6 translation [27]. For translation purposes a new set of IPv4-embedded IPv6 address formats has been defined [28]. The NAT64 comes in two flavors: stateless [12] and stateful [14]. The stateless NAT64 (IP/ICMP translation algorithm) replaces the Stateless IP/ICMP IPv6 Transition Mechanisms for 3GPP Networks Translator (SIIT) [29], which was used as the foundation for the now deprecated NAT-PT [9, 10]. Although NAT64 itself as a technology does not require DNS64 to work, these two usually go hand in hand, specifically for the stateful version of NAT64. Therefore, when- ever we mention NAT64 we actually assume that there is a DNS64 deployed somewhere in the same network unless specifically otherwise noted. The IPv4/IPv6 translation framework often refers to various translation scenarios. the context of this book and 3GPP architecture we are only going to cover Scenario 1 (an IPv6 network to the IPv4 Internet) and Scenario 5 (an IPv6 network to IPv4 network). Both stateless and stateful NAT64/DNS64 solutions can support Scenario 1 and Scenario 5. While the stateful flavor is the most suitable fit into the 3GPP architecture, we also describe a potential deployment architecture using a nearly stateless NAT64 within mobile 