operators' packet core. NAT64 as a technology has received positive feedback among 3GPP operators for two main reasons: it requires no changes in UEs and it does not tunnel anything over the wireless part of the 3GPP network. The basic principle of NAT64 and DNS64, as already described in general terms in Section 5.2.1, is that a DNS64 returns a synthesized IPv6 address to the end host and packets sent to the said synthesized IPv6 destination get routed through a NAT64 device that knows how to handle the synthesized IPv6 address. Figure 5.2 illustrates a complete signaling flow where an IPv6-only UE sends ICMPv6 Echo Requests to an IPv4-only web server. Terms like Network Specific Prefix (NSP) are discussed in the following sections. For address translation to work, the NAT64 (or a pool of NAT64s) and the DNS64 need to have a common understanding of the used IPv6 topology and used addressing plan. Specific prefixes used to enable the translation must be routed through the NAT64 devices, whereas the native IPv6 traffic can, and actually should, bypass the NAT64 devices using alternative routes in the network. Address Formats In order to enable NAT64 translation, IETF has defined an IPv4-embedded IPv6 address format for the IPv6/IPv4 translation purposes [28]. The address format is shown in Figure 5.3. The Pref64 is an IPv6 prefix assigned by an operator for use in algorithmic mapping of addresses. The 'u' octet contains the familiar 'g' and 'U' bit positions from the modified EUI-64 based Interface IDentifier (IID) (see Section 3.1). The 'u' octet should always be set to zero. Depending on the Pref64 : /n length, which is always in steps of 8, the embedded IPv4 address may need to be split into two parts around the 'u' octet. The suffix part fills the remaining bits of the IPv4-embedded IPv6 address to reach 128 bits of total length. The content of the suffix is currently all zeros but implementations should be prepared for the fact that it may contain meaningful information in the future. The Well-Known Prefix (W