ver, in practice, at least at this point of IPv6 transition, cellular network oper- ators often wish to control what type of bearer UEs request, and hence vendor specific additions to OMA's NAPDEF continue to be needed. The basis of this requirement is largely the untested nature of legacy network elements when encountering a new IPv4v6 type of request, which causes increased risks for connection establishment problems. In the Nokia's proprietary example, dual-stack connectivity can be provisioned by set- ting IFNETWORKS to 'IPV4, IPV6'. When both address families are set, a UE would first attempt to open an IPv4v6 dual-stack type of PDN Connection when possible, and otherwise use parallel IPv4 and IPv6 single address PDN Connections. 4.7.5 IPv6 Tethering A tethering UE that acts as a router, as described in Section 2.6.2, needs to implement router specific features from the generic IPv6 RFCs listed in Tables 4.10 and 4.11. For example, in the case of RFC 6106, a UE acting as host may listen for the DNS configura- tion option in Router Advertisements, but a UE that acts as router should send the option in the Router Advertisements that the UE emits to the Local Area Network (LAN). Addition- ally, a routing UE node needs to implement a set of router-only RFCs listed in Table 4.13. The exact RFCs needed depends on the supported 3GPP specification version and on the access network. The official 3GPP way for UEs to number networks below it is based on use of DHCPv6 PD, which requires RFCs 3315, 3633, and 6603. However, in 3GPP networks prior to Release-10, DHCPv6 PD is not supported as standard, and even in Release-10 based networks DHCPv6 PD support depends on the operator. If the DHCPv6 PD is not available, the UE has little choice but to implement Neighbor Discovery Proxy, as described in RFC 4389, or some variant of it. As well as DHCPv6 PD and Neighbor Discovery Proxy (or similar), there are two significant alternatives, which both come with significant issues. The first would be to implement IPv6 NAT, which sho