The limitations of other firewalls dhcp servers really isn’t relevant to this thread. If you want to be able to set soft MAC addresses per VLAN, open a different feature request.
If you want to discuss a broader range of network features or the entire networking UI in TrueNAS, again, that belongs in a different feature request and is a different topic.
My initial explanation did not go into gory details, but would have been sufficient for anyone with a reasonable understanding of the interplay between SLAAC (router solicitations, router advertisements, M and O bits, etc.), DHCPv6, recursive DNS servers (RDNSS), and Dynamic DNS (DDNS) to grok the problem.
It’s obvious that there was a lot of conflating aspects of these various stages in the process, especially misunderstandings of the difference between RDNSS and DDNS above.
Nonetheless, the fact remains that the intended design of IPv6 and the existing IPv4 implementation uses DHCP to enable DDNS. IPv4’s implementation of a SLAAC equivalent is so dysfunctional (generating only link local addresses and not able to provide GUA) that most people regard it as primarily a mechanism to indicate a DHCP failure rather than any sort of usable tool, so we take DHCPv4 for granted as a necessary process.
In IPv6, on the other hand, SLAAC is pretty good and quite usable in many (most?) scenarios. I personally have several networks using SLAAC without DHCPv6 and it works just fine if you don’t need things like deterministic endpoint identifiers or dynamic dns or network time server information or network booting or…
However, in the cases where you do need any of those (and many other) features that are expressly part of DHCPv6, the correct, IETF prescribed mechanism is, indeed, DHCPv6.
A lot of thought and development effort went into applying many of the lessons learned from years of experience expanding on BOOTP and developing DHCPv4 and the DHCPv6 process is quite a bit cleaner and with support for rapid commit provides significantly less overhead as well.
Bottom line, the failure of android to implement DHCPv6 is annoying, but android is NOT intended to run on devices providing infrastructure or services. TrueNAS is strictly intended as infrastructure and therefore should (arguably must) provide a full featured network stack allowing administrators to take full advantage of those abilities.
So if you want to discuss other features, please open appropriate threads for them. I’d really prefer to keep this thread focused on the relatively simple task of adding DHCPv6 client support to TrueNAS as that is really the only clean solution to a scenario that will become increasingly common in the residential, small and medium enterprise, branch office, and probably other environments as those environments start to deploy and depend more on IPv6.