SmartThings v3 Hub SLAAC Prefix Announcement

Good afternoon everyone.

I have been making some changes to my network recently and ran into an interesting issue. In my network, I have enabled DHCP for IPv6. I have explicitly disabled SLAAC prefix announcements, so my devices will rely on the address they are assigned.

However, it appears that in the absence of a prefix announcement, the SmartThings Hub v3 will send out its own. I have captured a network trace where I see the prefix announcement and used the MAC address to track it back to the hub.

I have not seen a way to disable this feature and wanted to check here if there was a known way to disable SLAAC prefix announcements from the hub. Any help is appreciated. Thanks.


Tagging @posborne, probably the best person to ask about it.

1 Like

Hi, @mikeshappell

I am Andres, a member of the Developer Support team.

I already share your concern with the Engineering team. I will let you know as soon as I have an answer.

1 Like

Great! Thanks for the help.


1 Like

Hi @mikeshappell

Great observation. So in 0.45.9, we rolled out our Thread Border Router support. One of the main functionality of the Border Router is assigning a local link address for the nodes on the Thread Network and in order to accomplish this, SLAAC is used. The feature itself within the Open Thread ( Border Router is called “Border Routing”. I admit the documentation around this is not strong, so I can try to do my best to help answer any questions or point you to the Repo itself which has a very strong and supportive community (GitHub - openthread/ot-br-posix: OpenThread Border Router, a Thread border router for POSIX-based platforms.).

As for turning it off, that will only be disabled if we disable Thread on your Hub which is currently not an option for the users. I was wondering if this is causing any issues with your setup because we do not expect that which is why we use SLAAC for this feature, please do let me know if there is anything we can help with.


1 Like

Hi @Kianoosh_Karami

Thanks for the response.

Sadly, yes, this does cause issues in my network. As I mentioned, we specifically don’t allow devices on the network to assign themselves an autoconf address (see below for a longer explanation why).

In the case of the hub, it advertises a ULA prefix, which is fine. However, devices on the network are using it for all IPv6 traffic. It appears that at least in the case of Apple devices, the first ULA it gets is the one it uses for network traffic. The addresses assigned by the DHCP server have the right routes in place to reach the internet. The ones from the hub do not. So, when the hub address is used (randomly), the internet stops working for that device.

So, that begs the question, why not use a GUA prefix. Well, the short answer is I can’t. I don’t own a GUA prefix and the one assigned by our ISP is dynamic. That would mean that prefix would change frequently.

OK, so what’s the issue with that? I route traffic in the network based on the prefix and the device in some cases. I need to direct traffic to or bypass a VPN tunnel based on the subnet or device that is communicating with the internet. Obviously, a dynamic prefix doesn’t work well in this case. So, I’ve used a ULA, which I can control. However, if a device uses its autoconf address instead, it does not get captured by the rule and traffic goes out the wrong interface or nowhere at all.

I noticed that the hub will not issue a RA if there is already a prefix advertised, which is part of the right answer. However, for the reasons above, I don’t want to advertise my prefix. I guess I’d hope the hub would realize it’s in a managed network (DHCP server is available and advertised) and it would not send out prefix announcements of its own. That would resolve the issue, assuming the devices have a DHCPv6 client. Short of that it feels like there needs to be a way to disable this.

I hope that all made sense. Please let me know if something is unclear. I did make a significant edit to this to try and clarify things. Thanks.


@mikeshappell The only way I could disable this for you is by disabling Thread, and I can do that remotely if you provide me your Hub ID by way of DM.

I can help answer the GUA prefix this week or next, is that OK?

1 Like

@Kianoosh_Karami, thanks for the offer.

At the moment, I have put the hub in its own VLAN, where it can’t do anything bad. That resolved the immediate problem, but I was already defining a new network architecture that better segmented my network. I will consider how to deal with this device in the new plan. Thanks.


1 Like

OMG, I just ran into the same issue because IPv6 on my network had turned unreliable. I noticed a ULA /48 prefix that I did not recognize as one I issue from my own router (using DHCPv6). I monitored the network traffic and found that my SmartThings hub was sending out Router Advertisements.

Why is it doing that? Traffic cannot be routed through the hub to the internet. The hub should request a IPv6 address from the network, but should not be assigning IPv6 addresses (or prefix) to other devices.

This breaks my IPv6 network. I chose to use ULA rather than GUA in my network and also chose to use DHCPv6 rather than SLAAC. Now it looks like I need to change my smart devices VLAN to at least enable SLAAC and possibly GUA as well. Just because SmartThings Hub is misbehaving.