SLAAC config happens when it shouldn't

Rather annoyingly, “Bug Clerk” closed a ticket I raised when I believe it shouldn’t have.

Here is the detail.

Summary:

I have VLAN interfaces, and even with “autoconfigure IPv6” unchecked, SLAAC still occurs on the interfaces. I had to do a tunable for net.ipv6.conf.vlan1.accept_ra to set it to 0 to fix.

I saw Jira PR 16443, my system doesn’t have that PR but accept_ra was still set to 2 – a very bad default!

My further (probably onto deaf ears) response:

With “Autoconfigure IPv6” unticked, the interfaces should not autoconfigure, including listening to RA, and installing SLAAC addressing!

The documentation here clearly states:

Clear the DHCP checkbox, then select Autoconfigure IPv6 if you want to create the IP address using SLAAC. This automatically configures the IPv6 address. You can only use this option one time to configure an IPv6 address for the system.

And as I mentioned, you are setting accept_ra 2 to, and as per here, that means “2 Overrule forwarding behaviour. Accept Router Advertisements even if forwarding is enabled.”

Can the ticket be re-opened? Anyone else experiencing this issue?

1 Like

Same, and have also raised tickets for it but to no avail. IPv6 is broken and seems a low priority to fix.

1 Like

Thanks for your input. So you experience the exact same issue as I describe (re SLAAC), or related to other autoconf stuff like DHCPv6?

Would be nice for an IX person to stick their beak in here; I don’t think IPv6 is broken in TrueNAS, but some small issues need attention.

Several others have confirmed the issue and there has been threads on it, e.g. TrueNAS Scale and IPv6

1 Like

Just want to bump this and mention I am also seeing this behavior. Mistake me if I am wrong, but I believe this wasn’t an issue with TrueNAS 24.10. So it seems like a regression.

TrueNAS sets accept_ra = 2 by default so that SLAAC addresses are still autoconfigured when Docker apps are in use. Docker enabled IP forwarding, which would prevent SLAAC from working with accept_ra = 1.

This was indeed not the case in older TrueNAS versions, and it manifested as broken IPv6 (no address configured) when Docker was in use, so I’m glad it’s fixed. :slight_smile:

I suppose it would be nice if TrueNAS enabled accept_ra to be configured per-interface in the Web UI (though you can always just set the relevant sysctl in advanced settings, as you noted). But I’m curious… why do you want to disable SLAAC for the VLAN interaces? If the router’s advertising correct prefixes for them, then I wouldn’t expect any harm with them getting SLAAC addresses. (Indeed, this seems desirable so they have IPv6 connectivity.)

Ok, seems logical, but I don’t use Docker. I understand why you mention it though.

Well that’s my point, it already does:

Because usually, disabling SLAAC implies you’re setting fixed addresses on the interface, which I am. I don’t want unnecesary address pollution when setting a fixed address.

Over the years, with IPv6 speaking gear, I sometimes see weird or indeterminate behaviour over source address selection, etc.

Ah, I see your point. It is not clear what the “autoconfigure IPv6” checkbox does, then. :slight_smile: I don’t think it actually controls SLAAC, as you noted, and IIRC there’s still no DHCPv6 client support in TrueNAS.

In a perfect world, I guess maybe each interface would have three checkboxes, something like this:

Autoconfiguration Settings

  • :ballot_box_with_check: IPv4 (DHCP)
  • :ballot_box_with_check: IPv6 (SLAAC)
  • ☐ IPv6 (DHCPv6)

And there would be no limitation of which / how many interfaces could have each box checked.

See in my techo mind, I see it as meaning “all types”.

Two types of autoconfiguration with IPv6:

  • Stateless :arrow_right: SLAAC
  • Stateful :arrow_right: DHCPv6

So if I see language that just says “autoconfiguration”, I take that as meaning both.

Anyhoo, I’m quite allergic to DHCPv6, but still, yeah, it would be good if the option worked at all, even better if it was specific.

Only the interface with “Autoconfigure IPv6” checked performs SLAAC, here. And the UI even prevents enabling that feature on more than one interface.

I can double check later what exactly it does on my machine… but the one interface limitation seems weird in and of itself. Generally I’d expect to be able to get a SLAAC address on any interface that’s receiving RA broadcasts.

What if you get more than one router advertisement on more than one interface? Same for IPv4 DHCP, that’s why that is limited to one interface, too.

Disclaimer: I am not a networking expert, and I only have one (NAT’d) IPv4 and one IPv6 subnet on network at the moment. However, to my knowledge IPv6 supports multiple IP addresses per interface in a way that isn’t recommended on IPv4.

Indeed, any “auto configured” interface will have at least two, namely the SLAAC address and the link-local address. But it’s also fine for the router to advertise an additional prefix, e.g., if you want the host to have both a ULA and a GUA on the same interface. Source address selection becomes more complex, but there are rules for that as well.

(Note that ULAs have other drawbacks that make them unhelpful in dual stack networks, since private IPv4 addresses are preferred over ULAs, but I mention this as an easy example of multiple RAs on the same interface.)

AFAIK, it’s also fine for a host to get one address via SLAAC and another via DHCPv6. It’s just less relevant to TrueNAS since it doesn’t have a DHCPv6 client at all. :frowning:

You are correct. That is a restriction that is intentionally placed in TrueNAS because TrueNAS is considered not a router but a host. And a host should have a single default gateway.

Yes, with IPv6 you can have multiple prefixes and indeed a gateway for each. But what should a NAS do with that configuration?

Disclaimer: I am a networking expert :wink:

So what if you do? Perfectly legal, nothing wrong with that.

Yep, and also perfectly legal. Multiple “equivalent” routes, including defaults, are chosen based on a bunch of things, but in this context, it would be route preference and metric (amongst others).

Indeed, and this is exactly what I do on my network. ULA’s are super handy due to some ISPs being lame and not always guaranteeing you get the same upstream prefixes handed to you – network stability.

Not true/don’t agree. Again, perfectly fine for a host to have multiple interfaces, routes and default gateways. Just as my end workstation has two VLAN interfaces (one “normal” and one for my datastore VLAN), so too can (and has to) the NAS.

It should do as any host/router/multi interface’d box should do – follow the normal rules of routing (beyond basic route selection in the first place).

Specifically for IPv6 (and Linux):

  1. Highest route preference
  2. Lowest interface metric
  3. Longest remaining route lifetime
  4. Most recently learned route

RA preference is:

  • High (+ 1)
  • Medium (default, 0)
  • Low (- 1)

The point here is that the preference is usually driven by the network admin, and the choices are many; don’t send a default, send one with lower pref, tweak your RA advert lifetimes, etc etc.

Alas, this is all beside the point of my original post/bug report; SLAAC, nor DHCPv6 should happen, if a tickbox that says “autoconfigure IPv6” is unticked :wink:

Why I want this? Because this is another way to avoid duplicate routes etc… to manually configure an interface, instead of relying on automatic configuration (which for me personally, one should never do on servers, storage etc, only “user” devices like a workstation, mobile phone etc.)