 payload protocol. The obvious correction to such applications and protocols is to make them independent of IP literals or deploy protocol-specific ALGs on NAT64 [33]. Another class of failing applications are IPv4-only applications. There is not much else you can do to correct the situation other than implementing IPv6 support for those when used in IPv6-only end host and networking environment. If the failing IPv4-only application is closed source, there is little that can be done other than wait for the appli- cation maintainer to provide an update (if ever). Recently, IETF has worked on a protocol solution for running IPv4-only legacy applications in a dual-stack end host that has IPv6- only network access. We will present a solution called 464XLAT [19] in Section 5.3.4. Another solution approach for IPv4-only legacy applications is called Bump-In-the-Host (BIH) [34], which is discussed further in Section 5.3.5. Both 464XLAT and BIH require end host modifications. Currently there is no protocol level means to distinguish between a 'vanilla' DNS server and a DNS64 capable DNS server. At the same time there could be network operations driven desires to use the same DNS server for all IPv4-only, IPv6-only, and IPv6 Transition Mechanisms for 3GPP Networks dual-stack end hosts. And why is this of any concern? When the DNS64 server receives an AAAA query from an end host, it does not know whether it has to apply normal DNS server operations or act as a DNS64 server (and therefore be prepared to do the address synthesis when needed). An unfortunate packet reordering or a glitch in the network can cause the DNS64 server to receive just an A response instead of an AAAA response. Unnecessarily synthesized AAAA records cause dual-stacked end hosts to use synthesized IPv6 addresses instead of native IPv4. While preferring IPv6 has nothing wrong with it, it causes unnecessary load on the NAT64 cluster. Also a certain class of applications may work better through a NAT44 than a NAT64. There was a proposal in IETF that had 