uld be set to zero to turn the DAD off. However, doing DAD does no harm other than generating unnecessary traffic. The situation might change if the UE starts acting as an IPv6 tethering device using a Neighbor Discovery Proxy [23]. NDP Neighbor Unreachability Detection (NUD) is not particularly necessary but it is recommended to enable it. The situation might change if UEs start tethering using a Neighbor Discovery Proxy [23]. Renumbering the IPv6 prefixes on the link without re-establishing the PDN Connection is not supported. NUD is particularly interesting on the 3GPP link referring to the specifics of the 3GPP link above (point-to-point and no link-layer addresses). The NUD algorithm using uni- cast Neighbor Solicitations and Advertisements as described in RFC 4861 [24] does not actually work without additional assumptions on links that have no link-layer addresses, like the 3GPP link. What there is left is then upper-layer confirmation, which specifically from the router point of view (e.g. the PGW) may not be adequate except for bidirectional and active transport layer flows. Furthermore, should the PGW ever initiate a router-host NUD using addresses configured out of the /64 prefix advertised on the link as a destina- tion? Since the /64 prefix is routed as whole to the UE and the PGW Neighbor Discovery Protocol implementation would have no other reasons to maintain additional neighbor state for anything derived from the /64 prefix we are justified in stating that NUD should be no exception in that regard. If the PGW insists on initiating a router-host NUD using Deploying IPv6 in 3GPP Networks a unicast Neighbor Solicitation then it should use the network side assigned unicast link- local address of the UE as the destination. NUD over the 3GPP link, either initiated by the UE or the PGW, must handle the Neighbor Discovery Protocol state transition prop- erly irrespective the lack of the link-layer addressing. For example, the UE and the PGW could treat the NUD originated Neighbor Discovery Protocol messag