Possible regression: NAT64 is no longer advertised after 0.62.3
It appears that hub firmware 0.62.3 has disabled—or at least stopped advertising—NAT64 on my SmartThings Thread network.
This is based on a direct before-and-after comparison of the Thread Network Data. The diagnostics were collected with the new Thread Network Diagnostic tool, which is still in alpha and does not always discover every device. However, the Network Data returned by the routers is consistent across the latest export.
Before 0.62.3
The SmartThings Thread Border Router at RLOC16 0x8000 advertised a separate NAT64 /96 route:
{
"prefixLength": 12,
"prefix": "fd1bc53a66af000200000000",
"hasRouteList": [
{
"macAddr": 32768,
"routerPreference": 3,
"isNat64": true
}
]
}
The encoded prefix corresponds to:
fd1b:c53a:66af:2::/96
After updating to 0.62.3
That entire /96 route is gone.
The current Network Data contains only:
- the normal on-mesh prefix
fd1b:c53a:66af:1::/64; - a default route from the SmartThings Border Router at
0x8000; - another default route from the second Border Router at
0xd400.
Both current route entries explicitly report:
"isNat64": false
Across all diagnostic nodes that returned Network Data, the result is consistent:
NAT64 route entries: 0
Non-NAT64 route entries: 22
So this does not appear to be a single router returning an incomplete response. The Thread partition currently contains no advertised NAT64 prefix.
This matches the behavior documented by OpenThread: an active NAT64 Border Router publishes a dynamically generated /96 prefix as a route in the Thread Network Data. Thread devices obtain that prefix from the Network Data and use it to synthesize IPv6 addresses for IPv4 destinations.
In other words:
Before 0.62.3:
::/0 default route
fd1b:c53a:66af:2::/96 NAT64 route
After 0.62.3:
::/0 default route
no NAT64 /96 route
The SmartThings Border Router stack has also changed. It now reports:
vendorSWVersion:
2.2.12-ST-GSDK
threadStackVersion:
OPENTHREAD/610f33e7c-dirty; POSIX; Jul 9 2026 14:53:31
SmartThings originally introduced NAT64 with firmware 0.58.10 and stated in the release notes that it was enabled by default. SmartThings staff also confirmed that each Border Router advertises NAT64 individually and that it can be controlled through the NAT64 Translation setting in the Advanced User Web Interface.
There is no mention of NAT64 in the 0.62.3 beta release notes.
Could the SmartThings team please confirm:
- Was NAT64 intentionally disabled in 0.62.3?
- Was the existing NAT64 setting reset during the update?
- Is this an unintended regression in the new Thread stack?
- Should the NAT64 Translation option still be available and enabled in the Advanced User Web Interface?
The diagnostics cannot prove whether the translator process itself has been removed, stopped or merely disabled. They do, however, provide strong evidence that the SmartThings Border Router no longer publishes a NAT64 prefix, which means Thread devices cannot discover and use SmartThings’ NAT64 service.
This happened before:
Nuki Ultra can’t access the Nuki cloud:
NAT64 is grayed out:
