Please implement DHCPv6 Client

I agree, maybe instead of only focusing on DHCPv6, we should reconsider the current network implementation in general.

I am still on CORE and don’t know if SCALE switched to netplan or whatever, but I find it strange that I can only have one interface listening for DHCP and that I can’t set a random MAC for VLANs. Some Firewalls like OPNsense don’t accept multiple static DHCP leases with the same MAC, even they are in different VLANs. So you have to make use of static IPs on TrueNAS itself, which does not feel great IMHO.

1 Like

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.

I know you want to keep this focused on DHCPv6, but I am curious why something like DDNS-Updater running as a docker app wouldn’t work without DHCPv6?

To be honest, I’m a bit paranoid about the IPv6 prefix for my network changing, but haven’t had it happen yet and am just hoping that DDNS Updater will make it smoother. If I’m setting myself up for disaster, I’d like to know.

If I’m understanding your comment @zchrykng, a docker container that updates DHCPv6 for a single client sounds like a workaround at best, and a hack at worst. A container would need to have the cryptographic key to update DNS with the new DHCPv6 address of the TN host. If every device in your network required that, it would be a nightmare to administer. Why have such a cludegy workaround? Why not just have DHCPv6 properly integrated into TrueNAS Scale? As @owendelong said, Linux has mature packages that have solved this issue already. I know this is not my thread, but I’m very interested in this feature. I’d like to add IPv6 to my home network (ISP is Comcast). I want globally unique addresses for my internal services. I want to use GUA for all my devices and not ULA for internal access only. That’s a poor workaround. I’ve not seen any decent “arguments” (as in a civil discussion, not a personal attack) as to why a proper DHCPv6 client shouldn’t happen.

1 Like

To be clear, I was specifically not suggesting that what I was doing was a good option. I was asking because I wanted to understand if I was setting myself up for pain down the line and why it wouldn’t work. If you want to turn that into a rant about why I’m wrong, that is fine, but I’m not going to engage.

I’m also not suggesting that DHCPv6 shouldn’t be implemented.

@zchrykng apologies. I’m not trying to turn it into a rant regarding your post. I’m trying to (civilly, and maybe failing…) explain why solutions like yours (which I think at the moment, you have no choice but to implement) that others seem to be suggesting as “the way forward” are not a proper solution. So yeah, I think that you have to do this if you want to use GUA-able IPv6 on your TNS. But it shouldn’t be the solution. We need proper DHCPv6 in TNS.

1 Like

This idea has my vote. I’m in process of making IPv6 the primary protocol on my home network with DHCPv6 enabled. I was surprised that my TrueNAS Scale (Fangtooth) wasn’t getting an IPv6 address. it only shows a link local address will likely only work on one VLAN.

I haven’t checked all of my devices, but so far every other one that I’ve checked shows at least link local and 2 other addreses. My router, a Ubiquiti Unifi Dream Machine Pro, does have a note next to SLAAC saying that android devices need it enabled, so I enabled it.

I’ll socialize this feature request to see if I can drum up more support for it.

Whats interesting to me is once i add a static IPv6 alias, it also picks up a dynamic one… try putting a non-globally routable static in (for exampe FD00::50) and seeing what happens

On my network I have SLACC configired on my Unifi router and i have a true DHCPv6 server (windows server).

This is what my addresses look like, the static and dynamic.

    inet6 dead:beef:dead:1:be24:11ff:fe62:9fcc/64 scope global dynamic mngtmpaddr 
       valid_lft 1348sec preferred_lft 1348sec
    inet6 dead:beef:dead:1::86/64 scope global 
       valid_lft forever preferred_lft forever

(redacted my actual network prefix)

–edit-- stupid idea, doesnt work, still intersting i get dynamic globally routable address in addtion to my static

interesting, new rathole for me to go down

The mngtmpaddr IPv6 address is a temporary address. It is used for privacy extensions and is managed by the kernel. Unlike global addresses, it is not suitable for hosting websites or services.