 and Service 2 DNS rules DHCPv6 server B Figure 6.1 Example deployment scenario of new DHCPv6 options. New DHCPv6 Options During the last couple of years IETF has been working for improvements for multi-interfaced hosts suffering from problems listed in RFC 6418 [6]. This has already resulted in one new DHCPv6 option being published for improved Recursive DNS Server (RDNSS) selection in RFC 6731 [7]. The work is continuing for DHCPv6 improvements for more specific route information delivery [8]. An example scenario where these new options could be used is illustrated in Figure 6.1. In this example scenario, a host is connected to Internet via dual-stack WLAN and 3GPP accesses. DHCPv6 servers that provide the configuration information are needed in both access networks, although if all traffic from the WLAN network were tunneled to the operator's core there would be no need for a separate DHCPv6 server in the WLAN network. UE Implications The new DHCPv6 options, mentioned above, incur a set of changes for UEs in addition to simple DHCPv6 query changes. Namely, a UE implementing the improvements for RDNSS selection has to be able to decide to which RDNSS a Domain Name System (DNS) query should be sent. This logic is completely new for the host operating systems; however, some advanced DNS resolvers can partially support this feature with just smart and dynamic configuration. On the other hand, if the UE already supports RFC 4191 [9] described in Section 3.5.6, the DHCPv6 route option in the best case merely means having an additional source for more specific route information. Future of IPv6 in 3GPP Networks The improved RDNSS selection RFC recommends using Domain Name System Security Extensions (DNSSEC), or secure and trusted channel, to counter attackers send- ing malicious DHCPv6 options. By injecting malicious RDNSS selection rules attackers could cause targeted hosts to send only specific queries to attackers, hence making an ongoing attack more difficult to detect. This attack could enable eavesdropping, Deni