> I wasn't quite precise, because there are cases where you do DHCPv6, but as Android doesn't support it the protocol is a bit dead in the water. Arguably, it'

> I wasn't quite precise, because there are cases where you do DHCPv6, but as Android doesn't support it the protocol is a bit dead in the water. Arguably, it's alive and well for the use case where it actually makes sense: For prefix delegation. > With IPv4 you are typically assigned a single IP address via DHCP. Well, sure, and with IPv6 you are "typically assigned a single IPv6 address via SLAAC"!? I mean, if you are talking about a controlled environment, that's not exactly difficult to achieve, by either using MAC-address based v6 addresses, or by configuring a fixed host suffix on the respective machine, just as you would configure DHCP. If you are talking about random people/devices on your network, neither case prevents them from assigning themselves whatever addresses they please. > Filtering individual hosts by IP has always been leaky, but IPv6 makes it more or less impossible. You have to filter by subnet. But that is what you are doing with IPv4 as well? Just because you can't see the individual addresses of individual machines, and thus have no other choice but to block the whole subnet (that is, the NAT gateway address that proxies for it), doesn't mean you aren't blocking whole subnets!? > SLAAC didn't have a way to communicate the local DNS server address to hosts Well, yeah, but that's been resolved, as you seem to know. > nor a way for hosts to update the DNS with their selected addresses and hostnames. Except it does? If you ask me, it does not make any sense for the DHCP server to update the DNS server anyway: It's the host that owns the host name and that knows where it is reachable, and also a host in principle could be getting its connectivity from anywhere, not just a particular fixed DHCP server. The host should have the credentials for updating its DNS name, should select the address to publish for inbound connections based on its local policy, and then publish that address to the DNS. It makes no sense to tightly couple naming services and connectivity: When my laptop switches from ethernet to LTE, it should just update its DNS name to point to the address it obtained from the LTE provider, and obviously that should not involve the DHCP server of the LTE provider.