I’m running a server with TrueNAS Scale v25.04. The server has a static IPv4 address, which is so configured in DNS. The DNS server is running Windows, updates are set to “secure only”.
The problem is the IPv6 address the TrueNAS server automatically obtains with SLAAC. It needs to be like that because the prefix is dynamic and changes regularily. The TrueNAS machine accepts the router advertisments and creates its own global IPv6. This is working fine.
But the IPv6 address is not entered into the DNS zone, thus the server is never reachable over IPv6. For a while, I entered the link-local IPv6 into DNS, but obviously this isn’t a good idea either once you’re dealing with a number of subnets.
Has anybody solved this dilemma? How can I get the IPv6 into DNS without changing the server to DHCPv6?
That is pretty bad and makes IPv6 pretty much useless for most software. I would seriously consider switching ISP if your ISP is too stupid to follow RIPE recommendations and does not give you a static /56 or /48 prefix.
I don’t know about Windows, maybe there is a radvd equivalent so you can use SLAAC. What is so bad about running DHCPv6, when you already run DHCPv4 on Windows Server?
That’s just the way it is. There is no provider I know of around here that handles it differently.
The problem is that TrueNAS doesn’t even make an attempt of entering its IPv6 into DNS. Windows clients do this, but Linux doesn’t. I read about the possibility of tying a script to the interface receiving a new IPv6, which in turn is complicated by the requirement that the DNS update needs to be “secure”, as in having to exchange keys first.
But isn’t there an easier way? I find it surprising that noone using Linux has ever considered this issue.
The Windows server’s DHCPv6 can’t handle the changing prefix. At least it couldn’t last time I checked. So I would need to use my router/firewall (OPNsense) to provide DHCPv6. But DHCPv4 is provided by Windows, and I fear the complexity of having two separate DHCP systems running on the same segment.
Not without a business plan, and I think that’s the point.
Same situation here (dynamic /60). I’ve been running TN with IPv4 only.
You can let TN auto-configure IPv6 and in OPNsense you can configure a dynamic host type alias to track the TN IP. However, if you want to restrict the TN GUI to a specific IPv6 address then that’s also a problem as the GUI config only takes a static IP.
Is that really the clients job? IMHO normally RA or DHCP writes it into DNS. AFAIK clients don’t even have to right to do any writes into DNS.
Totally agree. Also stuff like AD will get messed up by doing so.
Well, I hate to say it, but if your ISP does not offer you a static /56 prefix, IMHO you don’t have a working IPv6 internet connection and you should probably not use IPv6 at all.
If you say that to the masses of home internet subscribers who just lease a WiFi router from their ISP you will likely be met with blank stares.
It’s only a handful of us homelab geeks who look for these things, and that’s why the ISPs have no incentive to change. Furthermore, giving static /48s or /56s to residential customers weakens the pricing position of their business plans. It’s not the engineers who make these choices, most likely. It’s the corporate bosses. (And that’s a failure of imagination on the part of the engineers who wrote the specs assuming that just because the address space is so vast that nobody would choose to not follow the recommendation! They should have made it mandatory.)
I wish I lived in a country where ISPs followed the recommendations for all customers, but I don’t feel any less deserving of access to the IPv6 internet.
Good point. But how can this ever work with IPv6 SLAAC where the client picks its own IPv6?
I want IPv6 connectivity within my LAN, not (necessarily) externally. What little inbound IPv6 I have I can handle using the dynamic prefix just fine.
Maybe I should use site-local IPv6 that are assigned as static, just as the v4 addresses are. But that would mean yet another address on the interfaces, and I fear new trouble with that. If I assign site-local addresses on top of my current setup, I need to make sure each client uses the correct source address when transmitting, either externally (use the public IPv6) or internally (use the site-local IPv6.) Theoretically, the machines should select and use the correct address automatically.
Home internet subscribers also met me with blank stares, when I explain them CG-NAT, so that does not say much
Either way, does not make it any less true. There is a reason why RIPE recommends at least a static /56 (no technical reason against an even sleeker looking /48).
Not only you, anybody deserves IPv6. That does not make dynamic IPv6 prefix a workable IPv6 internet connection.
It doesn’t. Maybe it could theoretically if radv would tell the DNS, but I doubt anybody would ever want that.
Ahh now we are getting closer
For that you don’t even need internet at all.
You could use a link local IPv6, just like most printers do.
You can even use the same for multiple VLAN interfaces.
Something like
fe80::3eec:ffff:dddd:30f3/64
Why should that be a problem? Most OS use three IPv6 by default.
No, that’s where my problem started: The link-local can’t be reached from other subnets. For this reason, it’s impractical to put into DNS. That was exactly what I need to solve.
I’m not sure how a client will be able to select between its global IPv6 and its site-local ULA. The client will only see its router, and not have a concept of where his packet needs to end up. It doesn’t know if the packet is destined for the Internet (→ use global) or just another segment of my LAN (→ use ULA.)
Does the router have to publish known routes for my ULAs, and the global address is automatically selected by the client to reach everything else?
That one is pretty easy to solve. Just add the link local to every subnet. Then you don’t even have to jump trough the firewall to reach TrueNAS.
The client does not know and does not need to know anything. You either hardcode it in or you decide which one your DNS will hand out to the client. That is what local DNS overrides or split DNS is for.
I’m not sure I follow you: A client in subnet A of course doesn’t (directly) connect to subnet B, or else I wouldn’t neet the subnets in the first place. But if it doesn’t, the link-local address only goes so far as the next router, not into the other subnet.
Then how does it select the correct IP to use on outgoing transmissions?
I’ve heard about “scope matching”, which should be automatic: If a target IP is ULA as well, the host uses its own ULA to reach it, and the global address for everything else. Still sounds a little bit like black magic to me.
I would say the opposite. For only local services you could ignore IPv4.
Link local IPv6 are a match made in heaven for that use case and exactly the reason why stuff like printers use IPv6 instead of IPv4.
Let say you want a static IP, but don’t bother with mDNS or DNS.
For IPv4 you have two options.
A: Set a static IPv4 on the client itself.
B: Make a DHCP reservation on the DHCP server
Both options are not perfect. A is bothersome because you always have to check for collisions, it won’t show up in DHCP leases and so on. B: is annoying if you switch your router. Both are annoying if you have some site-to-site connection.
For IPv6 the option is sleek and simple. link local.
Your printer gets a ULA like fe80::3eec:ffff:dddd:30f3. That is unique, static and does not depend on the DHCP of the router, what subnetmask you are using and so on.
So locally printing will always work, no matter what changes in your network. That is why all printers I know, are installed with IPv6 under Windows.
For TrueNAS you can just use that. Or just use IPv4 with its downsides. Does not matter much.
I tried distributing ULAs by DHCPv6 on top of the existing global IPv6 addresses with Kea. This worked, but then I discovered that Kea can’t talk to the Windows DNS either because Windows secures with Kerberos authentication (GSS-TSIG), while Kea only supports TSIG.
So I tried to move DHCPv6 to the Windows Server instead of Kea. But then I also need to set a static IPv6 on the Windows server interface for DHCPv6 to work. To set this in the UI, you have to change the interface away from “IPv6 auto”, which in turn stops the generation of a global address with SLAAC. (You can do it on the command line, but modifications like this tend to be forgotten as soon as they are performed, and I want to keep my system clean.)
The last option I can think of now is to assign a static ULA on the Linux server, enter this into Windows DNS manually, and have all other machines access this server by using their global address (which in turn keeps changing with the dynamic prefix over SLAAC, but who cares.) This should work regardless of the scope change, shouldn’t it?
If the client is IPv6 capable (and may even detect an IPv6 link to its standard gateway at least), every name lookup will first be attempted for an IPv6 address, and only when that fails, a second lookup for the IPv4 address will be performed. That means a lot of waisted lookup attempts and added latency.
A client following the “happy eyeballs” standard will send out queries for A and AAAA simultaneously with a slight head start for AAAA. Then prefer whatever response it gets first.
Why not use the LL scope instead? Sorry, I wrongfully wrote ULA before.
That one does not depend on your prefix.
You can use fe80::3eec:ffff:dddd:30f3 on all your TrueNAS interfaces and create an AAAA record that points to that.
The TrueNAS is (directly) connected to a single subnet only. All other subnets are reachable over a router.
The link-local fe80:: would not traverse the router. If I entered it into DNS, all IPv6-capable clients in other subnets would get the fe80:: from DNS, but then timeout trying to reach it.
I actually had it running like this for a while, and it was working fine as long as this subnet was the only one running IPv6. As soon as other subnets got IPv6, and clients there started to reach for the TrueNAS over IPv6, errors started to pile up.
Why? Instead of traffic needlessly looping through your router, you could simply add multiple interfaces to TrueNAS and client could directly connect to it.
Does not have to.
Probably because it was not link local. After you added the interfaces in TrueNAS it is.
