My internet hub/router is the isp (Vodafone) provided hub. It has no ipv6 settings avail other than pin holes. The Aeotec home hub is connected to a 16 port switch directly connected to the isp hub, it’s always been this way, nothing new. I’ve rebooted the isp hub, it didn’t seem to help, and am now going to reboot Aeotec hub 2, if this doesn’t sort it it will have to wait till Sunday as I’m travelling
IPv6 settings screen 
Check, if there’s a /64 at the end of the Mesh Local Prefix:
And write down the complete Mesh Local Prefix, check again after 24, 48 hours if it has changed.
That’s the impression I have.
I have a ‘beta’ V3 hub which has a few Zigbee devices on it but nothing Matter at all, let alone Thread. That is all fine.
My main V3 hub has lots of Thread devices, The other two are on the same Thread network but don’t have any devices connected. So sort of like a primary and two secondaries but NOT in a hub group. All three have the issue with getting Thread info in the AWA and in the mobile app and it is a relatively recent issue.
I have Wi-Fi configured on at least two of the hubs though they also have wired connections. Curiously the router reports the same IP address (the Wi-Fi one) for both wired and wireless. I haven’t pondered that yet.
Can’t do that, this is all I see (screenshot), spotted ipv6 ULA was off, switched it on and rebooted, no difference.
Hi everyone!
The engineering team is already reviewing the issue. I’ll share any updates as soon as I have more information.
Thanks, appreciated 
Out if interest, what isp do you have and what router? I’m starting to consider that mine could be part of my issue. I have vodafone with the vodafone power hub.
I am on TalkTalk, largely because there isn’t a lot else around to choose from. I have the original version of what TalkTalk call their ‘Wi-Fi Hub’ (the first version was a Sagem, the second was a Huawei I believe, and they now have a Wi-Fi Hub 3) but I don’t use the Wi-Fi because TalkTalk remotely ‘optimise’ it. They used to turn that off if asked but they not only won’t do that now but they seem to have enabled it again. So you can wake up and find they’ve moved your Wi-Fi on top of your Zigbee channels.
The router appeared unsolicited quite a while back when it was relatively modern. Then last year a customer service bod announced they they were going to send me something much better than what I had. Yep, exactly the same now rather out of date model. Saved me dusting the old one …
I sent in a screen recording and my mobile app logs very recently to try and get that side of my issues addressed as it didn’t seem like it would fix itself, and that removes functionality. I chucked the error in the AWA in with it because it felt related.
Interesting. Isp provided hubs aren’t known in general for being terribly great. I dont use the WiFi on my vodafone at all, instead I use a bt whole home mesh WiFi system with 3 disks. My hub gets a lot of traffic including many hours of 4k video streaming per month as well as a lot of individual devices over and above smartthings.
I’d be surprised if it has anything to do with it. I recently transitioned to using Eero Pro 7 for my Wi-Fi hardwired to an AT&T BGW210-700 (Arris). Before that, it was the ST Wi-Fi Mesh Hub (Plume) similarly connected. The thread stack going to sleep has been a problem with both setups.
I’m hoping there’s a Configuration change that will resolve my issue. Id buy a new router if i was pretty certain that it would fix the issue, but I’m not certain it will. All investigation tends to point to ipv6 prefix delegation and either changing a setting on the router or possibly using ipv6 ULA. AI suggests prefix cycling by the isp can cause stale prefixes in the hub.
I’m travelling atm but will try following on my return
1 powering down smartthings hub
2 power cycling isp hub
3 waiting for isp hub to stabilise
4 starting smartthings hub
Id already enabled ula before going but might have not left it long enough before start st hub.
I could try power cycling each device too, but dont think that will work if ST AWA is still showing ipv6 prefix error
“Error loading hub Thread data: 500 NetworkManager error: Mesh
Local Prefix error”
in the thread section
Doubt it has anything to do with prefix delegation since that would likely only occur on the hardwired side of your Wi-Fi mesh device(s) or the Wi-Fi itself from your ISP router. Thread is on the “other" side of your ST hub and wouldn’t be using provider assigned space. In fact, looking at my other ST hubs, the Thread prefix starts with FD indicating it is Unique Local Address space which the device can choose itself. The device uses a pseudo-random algorithm to create a 40-bit Global ID, which is combined with the FD prefix to form a /48 local subnet.
I’m guessing what you are seeing is another symptom of the Thread stack being unresponsive.
Sounds like you have ULA enabled, which possibly overrides PD. I’m not sure all isp hubs support ULA, and if they do it’s not necessarily on by default. I only just discovered i had a ula setting before I went travelling on thursday (it was OFF by default) and Enabled it at that point but I’m not certain i waited long enough before power cycling st hub for it to have had an effect. It hasn’t worked thus far. will check again tomorrow.
I think you’re getting confused by what IPv6 addressing is being applied in what places. Your ISP router or other Wi-Fi device will be responsible for assigning IPv6 addresses only to the LAN or Wi-Fi side of the ST hub. In my network, my ISP router is still doing address assignment even though I have a mesh Wi-Fi network I’ve deployed. My ISP router is using a publicly routeable address block for devices that are hardwired to it and hence all my downstream devices are addressed from that block, namely 2600:1700:dce0::/64, including my ST hub.
The Thread network is a completely separate “LAN” segment that exists in the Thread radio space and the Thread “interface” on your ST hub is addressed independently from the Wi-Fi or hardwire Ethernet port on the hub. The ST hub self-assigns the ULA subnet as I mentioned above. It looks something like this:
The TBR function of the ST hub provides the “translation” between the non-Internet routeable IPv6 subnet on the Thread interface and the Internet routeable subnet on the Wi-Fi and/or Ethernet interface.
In fact, you can see the IPv6 address of your ST hub devices by doing DNS service discovery for the TBR service:
= ens33 IPv6 eero_thread #7957 _meshcop._udp local
hostname = [eero-08kx.local]
address = [2600:1700:dce0:4790:1aa9:edff:fe7d:8092]
port = [49155]
txt = ["omr=@\253\248\212H\160\163\000\001" "dn=DefaultDomain" "bb=\240\191" "sq=!" "pt=\163wjn" "at=\000\000iq\254\159\000\000" "sb=\000\000\012\177" "xa=\138;\247\194[3\161\003" "tv=1.4.0" "xp=\029c$#l{\240." "nn=eero-thread-9409" "mn=thread" "vn=eero" "id=8a3bf7c25b33a103" "rv=1"]
= ens33 IPv4 eero_thread #7957 _meshcop._udp local
hostname = [eero-08kx.local]
address = [192.168.1.126]
port = [49155]
txt = ["omr=@\253\248\212H\160\163\000\001" "dn=DefaultDomain" "bb=\240\191" "sq=!" "pt=\163wjn" "at=\000\000iq\254\159\000\000" "sb=\000\000\012\177" "xa=\138;\247\194[3\161\003" "tv=1.4.0" "xp=\029c$#l{\240." "nn=eero-thread-9409" "mn=thread" "vn=eero" "id=8a3bf7c25b33a103" "rv=1"]
= ens33 IPv6 eero_thread #6FE0 _meshcop._udp local
hostname = [eero-09ge.local]
address = [2600:1700:dce0:4790:1aa9:edff:fe7c:da92]
port = [49155]
txt = ["omr=@\253\248\212H\160\163\000\001" "dn=DefaultDomain" "bb=\240\191" "sq=[" "pt=\163wjn" "at=\000\000iq\254\159\000\000" "sb=\000\000\015\177" "xa=\130\204\247\165F\167o\224" "tv=1.4.0" "xp=\029c$#l{\240." "nn=eero-thread-9409" "mn=thread" "vn=eero" "id=82ccf7a546a76fe0" "rv=1"]
= ens33 IPv4 eero_thread #6FE0 _meshcop._udp local
hostname = [eero-09ge.local]
address = [192.168.1.163]
port = [49155]
txt = ["omr=@\253\248\212H\160\163\000\001" "dn=DefaultDomain" "bb=\240\191" "sq=[" "pt=\163wjn" "at=\000\000iq\254\159\000\000" "sb=\000\000\015\177" "xa=\130\204\247\165F\167o\224" "tv=1.4.0" "xp=\029c$#l{\240." "nn=eero-thread-9409" "mn=thread" "vn=eero" "id=82ccf7a546a76fe0" "rv=1"]
= ens33 IPv6 amazon #48E4 (37871) _meshcop._udp local
hostname = [none-15.local]
address = [2600:1700:dce0:4790:99fc:8e9c:8969:6eb6]
port = [49154]
txt = ["omr=@\253TcQK~\000\001" "dn=DefaultDomain" "bb=\240\191" "sq=j" "pt=;\201M" "at=\000\000\000\000h\233[\003" "sb=\000\000\001\177" "xa=\030\141\203\239\222\011H\228" "tv=1.3.0" "xp=\146\016\145\193n\226RH" "nn=AMZN-Thread-2c4b" "mn=echo" "vn=amazon" "id=+m\245\214\006\164\245\002\183O\249>\238\202\2022" "rv=1"]
= ens33 IPv4 amazon #48E4 (37871) _meshcop._udp local
hostname = [none-15.local]
address = [192.168.1.121]
port = [49154]
txt = ["omr=@\253TcQK~\000\001" "dn=DefaultDomain" "bb=\240\191" "sq=j" "pt=;\201M" "at=\000\000\000\000h\233[\003" "sb=\000\000\001\177" "xa=\030\141\203\239\222\011H\228" "tv=1.3.0" "xp=\146\016\145\193n\226RH" "nn=AMZN-Thread-2c4b" "mn=echo" "vn=amazon" "id=+m\245\214\006\164\245\002\183O\249>\238\202\2022" "rv=1"]
= ens33 IPv6 Samsung SmartThings-Station #A2DF _meshcop._udp local
hostname = [smartthings-station-3KWW-2.local]
address = [2600:1700:dce0:4790:2eba:baff:fe98:fb17]
port = [49154]
txt = ["omr=@\253\015w\238D\224\000\001" "dn=DefaultDomain" "bb=\240\191" "sq=\014" "pt=\246\015US" "at=\000\000h\230\186e\000\000" "sb=\000\000\015\177" "xa=R\019\031GN\229\162\223" "tv=1.4.0" "xp=s8\164ic>\251\191" "nn=ST-3KWW" "mn=SmartThings-Station" "vn=Samsung" "id=su\2406tm\210\221u[\194\01774'\255" "rv=1"]
= ens33 IPv4 Samsung SmartThings-Station #A2DF _meshcop._udp local
hostname = [smartthings-station-3KWW-2.local]
address = [192.168.1.141]
port = [49154]
txt = ["omr=@\253\015w\238D\224\000\001" "dn=DefaultDomain" "bb=\240\191" "sq=\014" "pt=\246\015US" "at=\000\000h\230\186e\000\000" "sb=\000\000\015\177" "xa=R\019\031GN\229\162\223" "tv=1.4.0" "xp=s8\164ic>\251\191" "nn=ST-3KWW" "mn=SmartThings-Station" "vn=Samsung" "id=su\2406tm\210\221u[\194\01774'\255" "rv=1"]
Note that each TBR has both an IPv4 and IPv6 address and that all the TBRs have an IPv6 address in the subnet I mentioned above including the ST Station which is the last in the list.
No setting on your ISP router is going to affect the Thread network IPv6 address assignment.
I dont profess to be an expert in networks, far from it, but ai suggests otherwise.
Cut and paste from chat gpt,and I know chat gpt isnt always reliable, so there’s thats too 
‐—‐-------‐----------------------------------
Short answer: The statement is not universally correct. Your ISP router can affect Thread IPv6 behaviour in several scenarios, especially when the Thread Border Router (TBR/OTBR) relies on upstream IPv6 configuration.
What the evidence shows
Final verdict
The statement is false in real‑world deployments.
While Thread itself is a self‑contained IPv6 mesh, the Thread Border Router’s IPv6 prefix assignment and routing can absolutely be influenced by your ISP router, especially when:
In short: Your ISP router can affect Thread IPv6 address assignment, depending on how your Thread Border Router is configured.
If you want, I can break down exactly how this applies to your own setup (e.g., UDM, Home Assistant OTBR, Apple TV/HomePod, etc.).
Context matters and I don’t think you’re asking the right question. Tell it “New context” and then ask “How does a thread border router assign the ipv6 subnet to the thread network”? Then ask “Does the ISP router play a role in how the thread network prefix is derived”?
Just an FYI…I do networking for a living 
Thanks Bruce, appreciate your advice. Any idea what’s causing this error on my hub,
and ultimately what the root cause is and how I might resolve it?
It’s been like this since Wednesday evening, and despite several reboots and power cycles it hasn’t self resolved. The hub has been up since Thursday morning now, well over 2.5 days and the error is persistently there, I haven’t tried but I’m assuming repairing matter devices won’t work either as it looks like the thread stack is down completely
pretty sure only ST can identify and resolve it. if you haven’t already, open a ticket with ST Support and allow access to your account in my.smartthings.com
I’ve raised a case, although earlier in the conversation @Itati mentioned that the engineering team were already looking at it.
Ok,back home from travelling. I powered down isp Vodafone hub for 15 mins powered down SmartThings hub for about 30 mins. Made sure the isp hub was fully rebooted and stable before restarting smarthingsv4 hub.
Unfortunately its made zero difference, I’m still getting the local prefix error. I think I’ve run out of things to try on my own here, will need suggestions from the engineering team. 
Edit: just for laughs I tried onboarding a new matter over thread bulb. I didn’t expect it to work and it didn’t, unsurprisingly. I guess that proves the issue isnt restricted to existing devices, but that doesn’t move me on much.