OpenThread: Connecting Thread Devices to Internet

RE: OpenThread: Connecting Thread Devices to Internet

tejaChintalapati — Sun, 15 Nov 2020 14:22:00 GMT

Thanks Simonr. I appreciate your help (:

RE: OpenThread: Connecting Thread Devices to Internet

Simonr — Fri, 13 Nov 2020 09:29:43 GMT

Hi again

I'm not entirely sure how exactly these products do communication both ways. It might be by using the NAT46 protocol, but it also seems like it could be by using stateful NAT64 as well (I can not guarantee that this will work out-of-the-box in our BR solution).

"In the absence of preexisting state in a NAT64, only IPv6 nodes can initiate sessions to IPv4 nodes. This works for roughly the same class of applications that work through IPv4-to-IPv4 NATs." "Depending on the filtering policy used (Endpoint-Independent, or Address-Dependent), IPv4-nodes might be able to initiate sessions to a given IPv6 node, if the NAT64 somehow has an appropriate mapping (i.e., state) for an IPv6 node, via one of the following mechanisms:"

Other solutions include IPv6 tunneling, or running a local central gateway that handles packets to and from the cloud.

Best regards,

Simon

RE: OpenThread: Connecting Thread Devices to Internet

tejaChintalapati — Thu, 12 Nov 2020 14:21:00 GMT

Thanks Simonr for such a detailed explaination.

[quote userid="75734" url="~/f/nordic-q-a/68249/openthread-connecting-thread-devices-to-internet/279750#279750"]Cloud can't send data to the nodes on its own initiative.[/quote]

If this is the case, I couldn't understand how Nest and Eve devices communicate both ways to/from the cloud in countries where IPv6 penetration is low. How do you think this can be achieved? Is it through NAT46?

RE: OpenThread: Connecting Thread Devices to Internet

Simonr — Thu, 12 Nov 2020 13:48:54 GMT

1. That depends if you hav IPv6 connectivity to the end nodes or not. We have two Cloud examples in the Zigbee & Thread SDK. We have the Thread Google Cloud Platform CoAP example and the Thread thethings.iO Cloud CoAP client example. Both of these work over IPv4, but only sends requests to the Cloud. This means that the nodes can POST/PUT data to the Cloud server and GET data from the Cloud, but the Cloud can't send data to the nodes on its own initiative.

2. If you have native IPv6 connectivity with a large enough subnet to the border router for it to furher continue the subnet down to the requirements in Thread/64 prefix address space. Then each node will receive a global unique IPv6 address that the cloud can use to send data to. Without IPv6 connectivity, the communication will go through the NAT64 protocol, which translates IPv6 packets to IPv4 packets and vice versa. There's also a NAT46 protocol that can help with data the other way (cloud to node), but this is not supported in the Border Router solution we provide.

Best regards,

Simon