RR response: 2001:db8:0:64::192.0.0.170 2001:db8:0:64::192.0.0.171 Validate the received response with DNSSEC and compare the IPv6 addresses to those previously learned. If match is found, UE can fetch the Pref64::/n and continue. After Pref64::/n discovery the UE may perform connectivity checks to vendor specific or operator hosted servers. Not shown here. Figure 5.8 Message flow for Pref64 : : /n discovery. IPv6 Transition Mechanisms for 3GPP Networks While one reason for the Pref64 discovery is the local synthesis of IPv6 addresses based on IPv4 address literals, there are also other uses. If a node implements a validating DNSSEC [11, 38] resolver, all synthetic AAAA responses would be rejected, as by definition they are modified by a middlebox. This would yield in undesirable user experience. Hence, a UE having a validating DNSSEC resolver would want to find out the Pref64 : n, and then use the prefix to perform local IPv6 address synthesis based on DNSSEC validated IPv4 addresses. A third reason is to use the Pref64 : /n in double protocol translation schemes as described in Section 5.3.4. 5.3.4 464XLAT Sections 5.1 and 5.4.2 stated that dual-stack is the 3GPP transition mechanism of choice. As we know from Sections 4.2.2 and 4.5 dual-stack is currently not readily available, especially for the 3rd Generation (3G) General Packet Radio Service (GPRS) systems. The 3GPP standardized fallback from the PDN Type IPv4v6 (i.e. dual-stack bearer) would be using two bearers to mimic a dual-stack behavior. However, two bearers come at a cost. Each 3GPP bearer and connection consumes both radio network and core network resources that are typically subject to licensing, while the equivalent functionality could be accomplished just by allowing multiple addresses on a single dual-stack bearer. There are economic and deployment timing reasons for trying to come up with transition solutions that would allow a dual-stack UE to work over an IPv6-only access such as PDN Type IPv6. Tunneling IPv4 over IPv6 is one approach, but i