 last IPv4-only device is sold it might become possible to turn IPv4 off, but we do not even see the day yet when the last such device would be made. Hence, for the foreseeable future, we are going to witness IPv4 and IPv6 coexistence with occasional pockets of IPv6-only deployments (with connectivity to IPv4 domain e.g., protocol translation). Technology Overview In this section, we will give a more detailed overview of IPv6 transition technologies and their pros and cons. A common benefit for both encapsulation and translation based solutions is that they avoid the need to deploy native dual-stack connectivity all the way. 5.2.1 Translation Protocol translation approach is attractive as it effectively avoids the issues related to tunneling (see Section 5.2.2) - except Maximum Transmission Unit (MTU) challenges remain due to the bigger IPv6 header size. The translation also provides access to the IPv4 Internet even if the host itself is in an IPv6-only domain. Unfortunately the translation comes with several major challenges. These challenges are SO major that they caused the original Network Address Translation - Protocol Translation (NAT-PT) technology, defined in 2000 in RFC 2766 [9], to be even declared 'historic' in 2007 by RFC 4966 [10]. However, since the NAT-PT, IETF has worked on to improve the translation technologies, and they have indeed got better, although they are still not perfect. The biggest current issues related to protocol translation, from 3GPP perspective when applicable, are listed below. Application Compatibility Application protocols that transport Internet Protocol (IP)-address literals in their payloads require explicit support to work through protocol translation. This means that the protocol translator would need to have an Application-Level Gateway (ALG) for each such protocol that has IP address family specific content in its protocol payload. In the worst case, the application protocol does not support change of the content by a protocol translator (encrypted, or protocol not sup