 is excessively simple, and for example does not support DHCPv6 or MLDv2 at all. An experimental RFC 5739 has been created to address the shortcomings [91]. Here we discuss only the experimental RFC's features, as that is the way IPv6 should probably be supported in the IKEv2 in the future. In the case of IKEv2, the IPsec gateway can assign IPv6 prefixes for clients that establish Virtual Private Network (VPN) tunnels [91]. This enables the use of IPv6 on top of a VPN link and presentation of IPv6 as a virtual interface. As the configuration information related to client's address configuration comes in IKEv2, there is no need to use SLAAC or DHCPv6 for address configuration purposes. However, a client may ask for additional configuration information with DHCPv6. The IKEv2 always assigns a unique /64 prefix for a client, and as the IIDs are negotiated, there is no need for a client to perform DAD procedures. Furthermore, as the IKEv2 configured link has only two nodes and no link-layer addressing, there is no need for Deploying IPv6 in 3GPP Networks ICMPv6 Redirects or link-layer address resolution either. In this regard, the connection negotiated with IKEv2 is very similar to Point to Point Protocol (PPP) and 3GPP Packet Data Network (PDN) Connection. 3.5.4 Address Selection IPv6 is designed to have fluent support for multiple simultaneously configured unicast addresses. Even in the simplest scenario, IPv6 hosts usually have at least two addresses configured: a link-local scoped address and a global scoped address. It is also very natural for a host to have multiple global addresses configured at the same time. For example, a network that a host is attached to may have multiple uplink Internet connection providers, each providing their own IPv6 prefixes for a host to configure addresses from. Another common example is a host with multiple network interfaces active at the same time: set of addresses will be configured from each interface. The problem that arises from the multitude of available addresses is called