al of Service (DoS), or other kinds of man-in-the-middle attacks. Luckily, for the 3GPP UEs, the 3GPP access is generally considered secure enough for these DHCPv6 options, and hence UEs can trust the information that they receive over the 3GPP link. Therefore, DNSSEC is not required if these new DHCPv6 options are only requested from the 3GPP access's DHCPv6 servers. Default Router and More-specific Route Selection The IETF standard 'Default Router Preferences and More-Specific Routes' [9] (RFC 4191) extends IPv6 NDP with two router preference flags in the Router Advertisement message header, and a Route Information Option (RIO). The former allows for a simple three- step prioritization of default routers in a host's default router list (LOW, MEDIUM - the default - and HIGH). The last allows for a Router Advertisement emitting router, even if not willing to be included into host's default router list, to mark up to 17 IPv6 destinations for which the router wants to serve as the first-hop. RFC 4191 can also be deployed in a multiple interfaces scenario. The only consideration is to limit the number of interfaces accepting RFC 4191 extensions to one interface that is both trusted and centrally managed by the operator. In our case, the 3GPP cellular connection fulfills these requirements. Sev- eral mainstream OSs already implement RFC 4191, including Linux, BSD variants, and Microsoft Windows, starting from XP. The interface(s) accepting an RFC 4191 extension can typically be specified just by using host side configuration. The 3GPP architecture relies on IPv6 Stateless Address Autoconfiguration (SLAAC) for its (un)trusted 3GPP access. The PGW must always send Router Advertisements for SLAAC purposes and therefore using the 3GPP access as a command channel for NDP- based offloading purposes is a small enhancement to the PGW functionality. Furthermore, Router Advertisement can always be sent unsolicited. The NDP-based solution is both extremely lightweight and also allows an on-demand push mode of operation from the