 in an IPv6-only net- work receives an IPv4 address literal as referral (e.g. with HyperTe Transfer Protocol (HTTP) or Session Initiation Protocol (SIP)), it cannot directly use the IPv4 address for communications. An application, or in some cases a DNS stub resolver on a host, could synthesize an IPv6 address out of an IPv4 address in the same way as DNS64 performs, if only the Pref64 : /n were known. IETF is in the late stages of defining a solution that uses a heuristic algorithm to find the Pref64 : /n used in an access network [37]. The heuristic approach is based on the idea that if a node asks for an IPv6 address for a name that has only an IPv4 address in the DNS, the possible DNS64 in an access network will synthesize the IPv6 address using the Pref64 : /n in use in the access network. After the node receives the synthesized IPv6 address, it can dig out the Pref64 Deploying IPv6 in 3GPP Networks as the node knows the IPv4 address used in the synthesis and also the possible synthetic address formats illustrated in Figure 5.3. The heuristic-based solution Internet-Draft, currently includes definitions for a well-known name ipv4only.arpa and well-known IPv4 addresses 192.0.0.170 and 192.0.0.171. These are the pieces of information on which nodes performing heuristic discovery will base their algorithm. Figure 5.8 shows an example message flow for the NAT64 discovery and the Pref64 : : /n learning. DNS64 server 'AAAA' RR query for 'ipv4only.arpa' 'A' RR query for 'ipv4only.arpa' 'A' response: 192.0.0.170 192.0.0.171 Creation of synthetic 'AAAA' RR by using Pref64::/n of the access network: 2001:db8:0:64::/64 'AAAA' response: 2001:db8:0:64::192.0.0.170 2001:db8:0:64::192.0.0.171 An UE not performing Pref64::/n validation can fetch the Pref64::/n at this point and skip the validation steps in the box below 'PTR' RR query for 2001:db8:0:64::192.0.0.17 'PTR' response "nat64.example.com" Compare the received domain with trusted domains list, and continue if trusted. 'AAAA' RR query for 'nat64.example.com' 'AAAA' 