uld not be introduced to IPv6 as it would bring similar harm as IPv4 NAT. The second alternative is to perform stateful numbering of nodes in the local network with DHCPv6, but that approach would be applicable only if all nodes in the LAN were DHCPv6 enabled, which they are not. Hence, in practice modern implementations need to support DHCPv6 PD, and also may support the Neighbor Discovery Proxy, or similar, for the cases where the access network is not DHCPv6 PD enabled. Deploying IPv6 in 3GPP Networks Table 4.13 RFCs needed for tethering use cases Title Book Section Reference Transmission of IPv6 Packets over Ethernet Networks 3.6.2 [143] DHCPv6 for IPv6 3.5.2 IPv6 Prefix Options for DHCPv6 3.5.2 DNS Configuration options for DHCPv6 3.10.2 Neighbor Discovery Proxies 3.4.10 IPv6 RA Options for DNS Configuration 3.4.3 [140] Prefix Exclude Option for DHCPv6-based PD 3.5.2 Table 4.13 lists RFC 2464 as one of the required RFCs. This is because the tethering in 3GPP environments is most commonly implemented with Ethernet-based LAN - most notably, but not limited to, WLAN. Obviously, tethering can also be done with other access link types, which would then require the router to implement the corresponding RFCs. We have also included two RDNSS configuration options for serving hosts using either of those two for RDNSS discovery. DNS Issues in the Case of Tethering The PCO information element based RDNSS discovery comes with one significant drawback: it does not really work with Split-UEs. The problem arises as the PDN Connec- tion is terminated on the modem, and it is the modem that receives all the information in the PCO information elements. In a traditional UE architecture where the modem is tightly integrated with the UE's operating system, this is not a problem. However, in the Split-UE (see Section 2.6.2) cases where modem and operating system are loosely integrated, sometimes even running in different devices, the problem arises of how to deliver RDNSS addresses from the modem to the operating system. One appro