Please implement DHCPv6 Client

Feature Requests
,
1

Problem/Justification
I would like to be able to reserve specific IPv6 addresses on the TrueNAS without having to administer them statically on the TrueNAS box. In part, this is because the prefix portion of my IPv6 addresses is dynamically assigned by my ISP using DHCPv6-PD.

Impact
It will certainly impact a lot of TrueNAS administrators wanting to administer their devices on an IPv6-capable network, especially those with dynamic prefixes.

User Story
As an example, a customer getting their internet service from $CABLECO probably gets a dynamic /60 (or larger/shorter) prefix assigned through DHCPv6-PD (IA_PD).

If the IP address on the TrueNAS is configured statically, then the prefix will not update when the ISP changes the prefix and the box will have to be manually reconfigured, potentially through the console or the IPMI or worse yet, over IPv4 (if available on the network in question).

If the IP address of the TrueNAS is dynamic, then currently only SLAAC is implemented. Since TrueNAS does not use IPv6 privacy addresses, the address is, at least, somewhat predictable, as the suffix is based on the MAC address, but there’s no convenient way to get that suffix married with the dynamic prefix in DNS, as you can’t really do DDNS for SLAAC derived addresses.

With this feature, the TrueNAS could receive a predictable, shorter address (e.g. $PREFIX::4a5) based on it’s DUID configured in the DHCPv6 server and the DHCP server could send a DDNS update to the DNS server, providing forward lookup for the TrueNAS even across prefix changes.

1 Like
2

Just to make sure we get what you are asking for:

You want TrueNAS to use SLAAC, but always use the same interface id?

So for example you get a dynamic /48 prefix from your ISP.
Let’s say 2000:1234:1234:1234::/64.
TrueNAS now gets from SLAAC this IP:
2000:1234:1234:1234::2000
Now your prefix changes to:
2000:1234:1234:1111::/64
Now you want your TrueNAS to change to:
2000:1234:1234:1111::2000

Am I understanding that correct?

If yes, may I ask why you want that?
I am not trying to be a di**, the reason I am asking, is because I think there is a IPv6 misunderstanding on your part.
I don’t see any usecase where this should be necessary.

3

Wouldn’t having an additional DHCPv6 client on TN be the preferred solution here? DHCPv6 will listen for RAs and query the DHCPv6 Server. And the server would then perform the DDNS update for the new IP? I would also think that having a ULA address as well would be useful as well. That way you can access the NAS internally via the same IPv6/DNS name and the external IP would be updated separately. So essentially, treating IPv6 as a first class citizen just like IPv4.

1 Like
4

The truenas already does SLAAC with the same IID.

What I want is for truenas to implement DHCPv6.

Since DHCPv6 is already built into Linux and BSD, this really shouldn’t be very hard.

5

TrueNAS isn’t the only one that does not support DHCPv6.
Android also does not support it, since is it offers no serious benefit.

Whatever you try to achieve, you probably also would achieve the same result if not even better with SLAAC, DNS and link local addresses.

6

I’m sorry, Sara, but you are simply wrong. True, Android is broken in the same way, and I’ve had MANY spirited discussions with Lorenzo C. about this fact, that’s the only accurate statement in your post.

There is no way to get SLAAC to update its address in DDNS. Further, since I need to reach the device from a subnet that is not on the same link, link local addresses are a non-starter.

While I can make the suffix of the address static and configure DNS statically based on that, I have zero control over when the ISP changes the prefix. As such, I need TrueNAS (or the DHCPv6 server) to be sending its address upstream to the DNS server whenever the prefix changes.

I’m quite well versed in the capabilities of SLAAC and DHCPv6. I do prefer SLAAC where it is feasible. However, there are environments where it does not quite do the job and DHCPv6 becomes necessary. It does provide benefits in those situations, and the one I outlined above is a real world example.

If you’d like to confirm my IPv6 chops, feel free to google my name or check out the IPv6 Forum’s ipv6 hall of fame, where you will see I was inducted in 2020.

2 Likes
7

This was not meant as a personal attack, just hoping to maybe find an alternative.
Seems like you know much more about IPv6 than I do.

This is pretty interesting, can you describe a scenario?
Like in the case for TrueNAS, why won’t you assign another interface in the same subnet?

8

I have described a scenario in this very thread.

If your prefix is dynamic and you need the current address in DNS, you need DHCPv6 to make that work.

Please read up on DHCPv6 Prefix Delegation if you are not understanding what I mean by a dynamic prefix.

In the case in question, I have a SMALL BUSINESS CLIENT THAT HAS A TrueNAS mini-R. They are using both I terfaces in an LACP bundle for performance reasons.

Their router receives a prefix (/60 in this case) from their ISP. They have about 8 or so VLANS, each of which is assigned a /60 by the router. The router is a Linux box running systems-networks and I use networks-dispatcher to trigger the updates to the kea configuration. SLAAC is automated in systems-networks, so each interface hands out appropriate prefixes, with the M and O bits set.

However, even with a predictable suffix, there’s no mechanism for updating DNS for the TrueNAS outside of DHCPv6 and DDNS.

9

Could you not simply circumvent that by not using a prefix so you don’t have to update to begin with, just because your prefix changes?

Like adding multiple VLAN interfaces to TrueNAS, each with a LLA?

Will your config not break the connection anyway, if the prefix changes?

Would you mind telling what ISP your SMB client uses so I know who to avoid?
Having a none static IPv6 prefix and not getting a /48 or at least /56 seems would strike me as odd even for a none business line.

10

I’m not sure how you expect me to use IPv6 without a prefix. The prefix in question is the first N (60 in this case) bits of the IPv6 address.

LLA doesn’t help, I need to be able to remotely administer this thing from other sites via the internet.

Yes, the connection breaks when the prefix changes, but if DDNS doesn’t work, then I don’t know how to re-establish it, because I don’t know the new address.

I’m in California. The device in question is in Georgia. It’s kind of inconvenient to get in front of it to learn the new prefix.

Virtually EVERY ISP does not give out static IPv6 prefixes unless you’re paying $ALOT for your service. In this case, it’s Comcast, but AT&T, Cox, Verizon FIOS (in the places where they do IPv6), Brighthouse, etc. all do the same thing.

I agree with you about the /48 and I had that conversation with John B. at Comcast while he was there several times. His excuse was that they’d need a /12 to give all of their customers a /48, to which I responded “and?”. He thought I was being unreasonable. I thought the same of his response. c’est la vie.

Most SMB buy internet service that is either at or just barely above residential service because it costs a lot less than the kinds of services you’re imagining.

I’m not defending the addressing policies of ISPs, but I am trying to make my customer’s site work reliably despite them. All of the other critical devices I need to manage at the Georgia site do DHCPv6 with the exception of the TrueNAS. This includes PDUs, UPSs, Routers, even the ethernet switches.

I have an IPv4 VPN as a backup plan, but I’d rather skip that overhead and additional failure points where feasible.

11

If you don’t have a static IPv4 and no static prefix and don’t want to rely on DDNS, this is a problem.

If that really is the case, I am sorry to have bothered you and I am sorry that your ISPs really are that bad.

12

I DO want to rely on DDNS. But you can’t do DDNS with SLAAC, you need DHCPv6.

13

I really don’t want to get on your nerves, but since you seem to be way more knowledgeable about IPv6 than me, I’ll bite.

Why should DDNS not work with SLAAC?
Why should you need DHCPv6 for DDNS?

14

I’d like to understand this as well, please.

I know there are differences in how OSs handle DNS. DNS assignment via DHCPv6 or RDNSS. See also https://ernw.de/download/ERNW_Whitepaper_IPv6_RAs_RDNSS_DHCPv6_Conflicting_Parameters.pdf

So let’s say we have SLAAC and RDNSS. Can DDNS now happen? And if not, why not?

RFC2136 is the relevant one for DDNS. Alas googling that RFC with SLAAC or RDNSS didn’t get me very far to understanding the limitations here.

1 Like
15

RDNSS in SLAAC is a mechanism to tell the host where to go to ask DNS questions. It provides information about Revursive DNS Servers (RDNSS).

Dynamic DNS (DDNS) is a mechanism by which the DHCP server (using a stored cryptographic key) sends new DNS resource records (A, AAAA, PTR) to the server. SLAAC provides no mechanism for these updates. It is completely stateless and the client never tells the router what address(es) it selected, and there’s no place else for the client host to send such updates in the SLAAC process.

It is possible for clients to send their own updates to DDNS, but this is also not implemented in TrueNAS. Further, the need to have the crypto key configured on every end host that doesn’t do DHCPv6 is a maintenance problem.

Hence, the right answer is to make DHCPv6 available. The device already supports DHCPv4 and is built on Linux which has several good DHCPv6 implementations available. As such, implementing DHCPv6 should be fairly trivial as such things go. That’s not to say I think it’s effortless… there’s UI changes needed, code changes to integrate DHCPv6 client, testing, etc.

Nonetheless, I think this is a feature that significantly increases the utility of the device in a multitude of environments and thus should be worth while.

2 Likes
16

Got it thanks for the explanation, that makes sense!

Yes I’d seen the option to have the host device do it, and I agree having the keys on TrueNAS is sub-optimal - having the DHCPv6 option is reasonable.

When DHCPv6 is used to only assign DNS and SLAAC is still used for address allocation - does that give the DHCP server enough to do DDNS? I am lowkey assuming yes because it’d learn the address of the host while handing out that DNS, and can use that for DDNS even if DHCP didn’t assign addresses.

Is that so?

17

Would a Hurricane Electric tunnel (to their router) work for what you need here?

My ISP does not support any ipv6 connectivity currently so it is what I use. It gives you (for free) 5 tunnels with fixed prefixes any of which can be /64 and one of which can be a /48.

1 Like
18

No… DDNS requires stateful DHCP with address assignment.

20

An HE tunnel could be a viable workaround in that it provides a static IPv6 prefix. However, given that the current isp is already providing native IPv6, adding an HE tunnel to the mix and the resultant source routing nightmare necessary to make sure the right source address gets sent through the correct isp also seems suboptimal.

Really, I appreciate everyone’s efforts to determine workarounds for me, but the simple reality is that TrueNaS really should support DHCPv6 client.

Full disclosure, since the TrueNAS suffix is static, I have a workaround which involves a script on the router which uses networks-dispatcher to detect prefix changes and update the dhcp server configuration file as well as do some other things. For now, I’ve embedded the TrueNAS suffix in that script and it does the needed DDNS registrations for the TrueNAS, but it’s a horrible kludge which shouldn’t be necessary.

2 Likes
21

It’s not so much workarounds as understanding the problem statement and proposed solution.

I am thinking updating the original ask with more detail around how things interact, what other ideas were considered and why they don’t work or are sub optimal, may be helpful. And a contrast to how things would work with dhcpv6, and a couple user stories for users that do want to use dhcpv6 and those that don’t and rely on SLAAC.

1 Like