ported). This means that effectively the protocol translator cannot support 100 percent of unhelpful applications. The applications of course can be modified to work with protocol translators. However, a special case of protocol translation, called double translation and discussed in Section 5.4.4, can work with problematic applications. This is because for the applica- tions the translation looks like IPv4 NAT: the first protocol translator translates only the outermost header from IPv4 to IPv6, while the second protocol translator translates the header back from IPv6 to IPv4. Effectively the IPv4 address and port changes, and hence applications can cope with the same mechanisms that they use for IPv4 NAT traversal. Deploying IPv6 in 3GPP Networks Lying with Domain Name System The whole idea of protocol translation is founded on the idea that the destination is IPv4-only, and hence does not have an IPv6 address (AAAA) resource record in the Domain Name System (DNS). On the other hand, the host on the IPv6-only network definitely requires to get AAAA records for its DNS queries. Therefore, an entity called DNS Extensions for Network Address Translation (DNS64) synthesizes AAAA resource records having IPv6 addresses from real IPv4 address (A) resource records. The problems that a host will have with these synthesized addresses are the following: 1. Synthetic addresses cannot be verified with Domain Name System Security Extensions (DNSSEC) [11], as by design they are altered by a middlebox. 2. Synthetic addresses cannot be given as referrals to other nodes. 3. Synthetic addresses are only valid in the network where the address was received. Lost Header Information The IP and Internet Control Message Protocol (ICMP) header contents are different from IPv4 to IPv6. After a translation between address families there is no possibility reconstructing the original header anymore. The fragmentation related identification field serves as an example. In an IPv4 header, the identification field is 16 bits whereas in IPv6 it 