t also comes with a cost of extra header overhead. Translating IPv4 to IPv6 does have less overhead, but it then requires a second pass of translation back from IPv6 to IPv4; hence it is often referred to as the double translation (see Section 5.4.4 for further discussion on this topic regarding 3GPP networks specifically). The first serious attempt to standardize a double translation solution in IETF was Prefix NAT (PNAT) [39]. However, at that time it faced a lot of opposition from both 3GPP and IETF communities. Eventually the authors abandoned the original idea and the solution evolved into BIH [34] (see Section 5.3.5 for a detailed discussion of BIH). The later attempt in IETF to enable dual-stack connectivity over an IPv6-only access network is called 464XLAT [19]. This time the overall IPv6 transition climate was more mature to accept a double translation based solution. Funnily enough, at both times the double translation solution was driven by a reputable mobile operator deploying 3GPP-based networks. 464XLAT can be deployed in fixed networks as well as in mobile networks. Our emphasis and interest is on the deployment on 3GPP networks. Figure 5.9 shows the basic 464XLAT architecture when deployed in 3GPP networks. 464XLAT heavily reuses existing IETF standards developed for IPv4/IPv6 translation and NAT64 [12, 14], DNS64 [26], and the companion IPv6 addressing [28]. 464XLAT supports three different con- nectivity scenarios for a dual-stack UE over an IPv6-only network access: 1) native IPv6 connectivity for IPv6 applications, 2) translated IPv6 access to IPv4 services for IPv6 applications, and 3) double translated access for IPv4 applications to IPv4 services. Table 5.4 shows all three scenarios and the nodes that are involved on each of those. The Provider Side Translator (PLAT) is basically a stateful NAT64 [26] and does the translation from IPv6 to IPv4 when IPv6 translated IPv4 traffic is sent over the Deploying IPv6 in 3GPP Networks IPv6 host/ server Dual-stack UE Operator core / PDN (S)Gi ((q)) I