g-term solution for IPv4 exhaustion is IPv6-only networking. Special Considerations Regarding 6to4 The 6to4 protocol is designed to configure itself automatically in an environment where IPv6 is not present. The principle of the protocol is to configure itself, in a stateless manner, an IPv6 address out of the public IPv4 address it already has. The IPv6 address is created by using the 6to4 prefix 2002 : /16 (see also Figure 3.7), and adding the 32-bit IPv4 address behind it. This creates a 6to4 prefix of /48. The 6to4 operation is also made in a stateless manner: the packets from a 6to4 network or a 6to4 host are sent upstream with destination address set to the 6to4 router IPv4 anycast address 1. On downstream the packets are routed using the 6to4 network's, or host's, public IPv4 address that is embedded in the 6to4 IPv6 prefix. There are a number of disadvantages in the 6to4 technology in the 3GPP environment. The first is the use of public addresses. Because one 6to4 IPv6 prefix requires one public IPv4 address, it is an ill fit as a UE based transition tool. 6to4 automatic tunneling is prone to routing errors, and therefore, it does not provide a production grade tool for a gateway (Gateway GPRS Support Node (GGSN), or PGW) based transition solution. In addition, some early implementations needed one public address per UE also in the gateway, which wasted addresses. While the 6to4 technology is not adopted or recommended to be used in 3GPP networks, it is still beneficial for 3GPP operators to host 6to4 relays. This is due to the fact that an IPv6-enabled UE may be communicating with a destination that is using 6to4. The 6to4 is known for its vulnerability to issues caused by asymmetric routing and ingress filtering dropping packets coming via the 'wrong' path. To help avoid these issues, a network operator can deploy local 6to4 relay through which the packets traverse in both directions. This issue and the requirements for 6to4 relays are discussed in depth in RFC 6343 [24]. 5.3.2 Dual-stack The main trans