TrueNAS support for auto-configuration and IPv6-only/IPv6-preferred networks

Feature Requests
1

Problem/Justification
This suggests IPv6-only operation is supported: https://www.truenas.com/blog/truenas-facilitates-the-transition-to-ipv6-only/

However:

  • Disabling DHCP and not setting an IPv4 static address while leaving auto configure IPv6 enabled results in no networking

  • You can’t remove the IPv4 default route from the GUI

  • Not having an IPv4 default route causes Apps to fail initialisation

  • DHCP option 108 (IPv6-Only Preferred) is ignored

  • Does not support CLAT & XLAT464 for access to IPv4-only destinations from an IPv6-only TrueNAS

  • Cannot use SLAAC on multiple interfaces

  • Does not support DHCPv6

  • You can set IPv6 name servers under System→Network→Network Configuration, but if you try to do the above change to disable DHCP you will be taken to another screen that marks IPv6 name servers as incorrect syntax

Impact
Cannot realistically deploy an IPv6-only TrueNAS TrueNAS despite the news release stating otherwise.

User Story
Some ISPs are deploying only IPv6 to customers to minimise CGNAT, with XLAT464 providing access to IPv4. TrueNAS is the only IPv4-preferred device in my network.

TrueNAS limits on auto-configuration are too strict. There is no technical reason why multiple interfaces cannot support DHCP & SLAAC, and IPv6 in particular is meant to be configured via SLAAC. Debian Trixie supports multiple NICs with DHCP & SLAAC, even on the same subnet and with multiple default routes, and will use both with equal cost multi-path (ECMP) if the interfaces are assigned the same metric. Multiple NIC on same subnet can be desirable for storage networks and SMB multichannel.

2

just FYI in debian linux you can only have one interface defined as the default IPv6 route -ask me how i found that out the hardway :slight_smile:

also same for SLACC if they are the same broadcast domain…..

oh and don’t get me started on DHCPv6 vs DHCPD - there are serious debian incompatibilities (though haven’t checked out since trixie was first released)

tl;dr some of the issues you mention are debian upstream issues

i have run IPv6 for a long time, almost all distros and windows assume dual stack and never IPv6 only - so just FYI you might be waiting a while

however if you can fix the issues in native debian and not truenas you have a valid case for those as regressions from upstream

not to mentions downstream issues in things like docker and lxcs…..

i get your request and why you ask, but we are far from a world where the majority of linux can run ipv6 only for breadth scenarios…. great if you have it working….

1 Like
3

If TrueNAS is not going to support IPv6-only/preferred then the news article referenced should be removed.

At least Debian Trixie (which TrueNAS 26 is based on) is perfectly capable of supporting multiple NICs with DHCP and SLAAC and multiple default routes, even on the same LAN. This is a fresh install of Trixie with completely default config, other than adding the second NIC via KDE. No hacking required.

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: enp0s1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 5e:f7:0e:e9:47:32 brd ff:ff:ff:ff:ff:ff
    altname enx5ef70ee94732
    inet 192.168.10.159/24 brd 192.168.10.255 scope global dynamic noprefixroute enp0s1
       valid_lft 86299sec preferred_lft 86299sec
    inet6 2001:db8::a87f:d225:3979:8393/64 scope global dynamic noprefixroute 
       valid_lft 2591981sec preferred_lft 604781sec
    inet6 fe80::3f9b:504c:c5bb:4e1d/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: enp0s2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether f2:10:3e:ab:a2:9d brd ff:ff:ff:ff:ff:ff
    altname enxf2103eaba29d
    inet 192.168.10.160/24 brd 192.168.10.255 scope global dynamic noprefixroute enp0s2
       valid_lft 86300sec preferred_lft 86300sec
    inet6 2001:db8::3ae4:d584:203:f41b/64 scope global dynamic noprefixroute 
       valid_lft 2591981sec preferred_lft 604781sec
    inet6 fe80::4236:e8bc:cf3f:d65c/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

And two default routes for both IPv4 and IPv6. Note the second link has a higher metric automatically so that traffic prefers the first default route.

user@debian:~$ ip r
default via 192.168.10.1 dev enp0s1 proto dhcp src 192.168.10.159 metric 100 
default via 192.168.10.1 dev enp0s2 proto dhcp src 192.168.10.160 metric 101 
192.168.10.0/24 dev enp0s1 proto kernel scope link src 192.168.10.159 metric 100 
192.168.10.0/24 dev enp0s2 proto kernel scope link src 192.168.10.160 metric 101 
user@debian:~$ ip -6 r
2001:db8::/64 dev enp0s1 proto ra metric 100 pref medium
2001:db8::/64 dev enp0s2 proto ra metric 101 pref medium
fd30:dab4:c4c7::/64 via fe80::183f:c818:bca5:b7f1 dev enp0s1 proto ra metric 100 pref medium
fd30:dab4:c4c7::/64 via fe80::183f:c818:bca5:b7f1 dev enp0s2 proto ra metric 101 pref medium
fe80::/64 dev enp0s1 proto kernel metric 1024 pref medium
fe80::/64 dev enp0s2 proto kernel metric 1024 pref medium
default via fe80::ee38:73ff:fe63:ce81 dev enp0s1 proto ra metric 100 pref medium
default via fe80::ee38:73ff:fe63:ce81 dev enp0s2 proto ra metric 101 pref medium

This is a 100% usable and stable / deterministic solution – the route metrics cause the first NIC to be preferred when going off-subnet, and both NICs are equally valid on-subnet. There are good reasons why TrueNAS should support auto-configuring multiple NICs even in the same LAN for multichannel SMB and iSCSI.

If you go one step further, with nmcli you can set both the interfaces to have the same metric and then use ECMP.

# nmcli connection modify "Wired connection 1" ipv4.route-metric 100
# nmcli connection modify "Wired connection 1" ipv6.route-metric 100
# nmcli connection modify "Wired connection 2" ipv4.route-metric 100
# nmcli connection modify "Wired connection 2" ipv6.route-metric 100
# reboot

### after reboot
user@debian:~$ ip r
default via 192.168.10.1 dev enp0s2 proto dhcp src 192.168.10.160 metric 100 
default via 192.168.10.1 dev enp0s1 proto dhcp src 192.168.10.159 metric 100 
192.168.10.0/24 dev enp0s2 proto kernel scope link src 192.168.10.160 metric 100 
192.168.10.0/24 dev enp0s1 proto kernel scope link src 192.168.10.159 metric 100 
user@debian:~$ ip -6 r
2001:db8::/64 dev enp0s2 proto ra metric 100 pref medium
2001:db8::/64 dev enp0s1 proto ra metric 100 pref medium
fd30:dab4:c4c7::/64 proto ra metric 100 pref medium
	nexthop via fe80::183f:c818:bca5:b7f1 dev enp0s2 weight 1 
	nexthop via fe80::183f:c818:bca5:b7f1 dev enp0s1 weight 1 
fe80::/64 dev enp0s1 proto kernel metric 1024 pref medium
fe80::/64 dev enp0s2 proto kernel metric 1024 pref medium
default proto ra metric 100 pref medium
	nexthop via fe80::ee38:73ff:fe63:ce81 dev enp0s2 weight 1 
	nexthop via fe80::ee38:73ff:fe63:ce81 dev enp0s1 weight 1 

### testing ECMP
### note IP flips between the two NICs
user@debian:~$ curl -6 icanhazip.com
2001:db8::a87f:d225:3979:8393
user@debian:~$ curl -6 icanhazip.com
2001:db8::3ae4:d584:203:f41b
user@debian:~$ curl -6 icanhazip.com
2001:db8::3ae4:d584:203:f41b
user@debian:~$ curl -6 icanhazip.com
2001:db8::a87f:d225:3979:8393
user@debian:~$ curl -6 icanhazip.com
2001:db8::a87f:d225:3979:8393
user@debian:~$ curl -6 icanhazip.com
2001:db8::a87f:d225:3979:8393
user@debian:~$ curl -6 icanhazip.com
2001:db8::a87f:d225:3979:8393
user@debian:~$ curl -6 icanhazip.com
2001:db8::3ae4:d584:203:f41b

ECMP is also perfectly reasonable. Sessions are bound to a NIC based on a source/dest IP or 5-tuple hash depending on how a sysctl is set.

I don’t know why TrueNAS doesn’t allow this, but it has had an opposition to DHCP for many years. It’s not reasonable with IPv6 to prevent auto-configuration, and as above shows is completely unnecessary. Maybe IPv6 will be the start of better networking in TrueNAS.

4

You post a Feature Request 10 days ago and that is the conclusion you come to? Wow.
The link you posted comes up 404.

image
image1254×857 415 KB

5

It appears to have been a blog post, the Wayback Machine captured it up until May this year:

6

Also regarding CLAT – Yes, Windows and Linux are behind. Support for CLAT is in the upcoming NetworkManager 1.58 and is coming to Fedora 45, so it won’t be long before it is generally available for Linux desktop. Linux servers / devices may not need CLAT in an otherwise all-IPv6 network depending on the use case. I don’t have an urgent need for CLAT on my TrueNAS, but someone noted that storj doesn’t support IPv6 so CLAT may help.

7

I guess by ninja-deleting their press release TrueNAS has told us their decision. Disappointing because this is really not hard.

8

The TrueNAS press release was up until at least 7 June 2026.

9

Perhaps, but I rather not jump to conclusions.
While it does appear as if that blog post has been removed we don’t know the reason.

10

I would be very interested to know what conclusion you think I should have come to so I can improve the feature request. A press release saying IPv6 is supported, an underlying OS that demonstrably has very good support for IPv6 and auto-configuration, and valid use cases seems like a good basis for a feature request.

11

You made a decent FR in the first post. You lost it when you started complaining about the article and going off track on the FR thread. Keep it a discussion and not a complaint session

12

I’m not sure I understand.

  • Post 1 is the FR that you acknowledge is fine
  • Post 2 is a reply saying that this is not possible on Debian Linux
  • Post 3 shows it is absolutely possible on Trixie at least, with a default configuration plus a ECMP-enabled configuration
  • Post 4 is you telling me I came to a wrong conclusion

I can only then assume I came to the wrong conclusion about auto-configuration and multiple default routes, which I don’t think is the case, but if I did I’d like to correct.

13

All this comes off poorly.

14

Thank you for confirming that the FR and technical response are fine. Thank you also to TrueNAS for taking down the article (whether as requested or otherwise) so that users have correct information on TrueNAS capabilities when searching for issues.

1 Like