systems provide IP version agnostic APIs, which considerably simplifies transition for applications that correctly use the provided APIs (see more in Deploying IPv6 in 3GPP Networks Section 3.9.2). However, there are many cases where either a significant portion of the applications have not correctly used the provided APIs, or the operating system has different APIs for IPv4 and IPv6. Until recently, some mobile operating systems did not support IPv6 at all. Therefore, there are still a significant number of (legacy) applications that work only with IPv4. The lack of IPv6 deployment in 3GPP networks has not helped either, as application developers have not had good opportunities for verifying IPv6 support of their applications. A solution for allowing a UE to have IPv6-only PDN Connection while still serving IPv4-only applications is to implement a double translation scheme. Double translation works by combining BIH-like functionality on a UE with NAT64 on a network. The IPv4-only applications send IPv4 packets to IPv4 addresses as usual, but before sending the packet out from the UE it is translated into IPv6. The resulting IPv6 packet is sent over 3GPP access and then translated back to IPv4 at the NAT64. While the double translation approach is not part of the official transition scenarios listed in 23.975 [55], it is used in some pre-commercial deployments and trials. It is well possible that it will be used as part of commercial transition from IPv4-only 3GPP access to IPv6-only access. The benefits of double translation when compared to dual-stack is the lack of need for parallel PDN Connections or support for the new IPv4v6 type of PDN Connection. 464XLAT [19], that was discussed in Section 5.3.4, is another example of a double translation solution. It has been trialed in some IPv6-only mobile networks as a possible consumer-grade solution. Like many other transition solutions, 464XLAT has its deploy- ment reality issues. It is not part of the official 3GPP architecture and UE requirements, which makes net