Accessing Openthread Node from outside the Sensor network

[Tobias Aunbøl]

I currently have everything OpenThread related up and running (Border Router, RCP and a end node) everything works fine inside the network, but now I am in doubt of how to access a node/sensor within the network from outside the network, from a cloud or other IPv4 based network. As far as I have understood there is  End-to-end IP connectivity via routing between Thread devices and other external IP networks through the Border Router, by using NAT64 and tayga. 

So my question is, and where I am bit confused: From outside the network if I want to send/receive message with CoAP or a simple ping, what IP address should I use to access a specific device? Is it the mesh local IPv6 address or the borderrouter IPv4 address and a port? And how what do I need to setup on host from outside the Thread network to support the IPv6 and prefix?

[Jonathan Hui]

To send packets from an external IP network to the Thread network, you must use an IP address that is routable from the external network. If that global network is the public internet, then the IP address must be globally routable on the public internet.

For IPv6, that means assigning an routable IPv6 prefix to the Thread network. On the global internet, the ISP will need to provide you with a globally routable IPv6 prefix. Some ISPs provide this service today, but not all.

When a Thread device communicates with an IPv4 host, you can use a stateful NAT64. As with any stateful NAT, the dynamic mappings are only configured when communication is initiated by the Thread device. The default OTBR configuration on Raspberry Pi already supports stateful NAT64. You should be able to ping a public IPv4 address (e.g. 8.8.8.8) with the following command: ping 64:ff9b::808:808

--

Jonathan Hui

On Mon, May 10, 2021 at 1:00 AM Tobias Aunbøl <taun...@gmail.com> wrote:

I currently have everything OpenThread related up and running (Border Router, RCP and a end node) everything works fine inside the network, but now I am in doubt of how to access a node/sensor within the network from outside the network, from a cloud or other IPv4 based network. As far as I have understood there is  End-to-end IP connectivity via routing between Thread devices and other external IP networks through the Border Router, by using NAT64 and tayga. 

So my question is, and where I am bit confused: From outside the network if I want to send/receive message with CoAP or a simple ping, what IP address should I use to access a specific device? Is it the mesh local IPv6 address or the borderrouter IPv4 address and a port? And how what do I need to setup on host from outside the Thread network to support the IPv6 and prefix?

--
You received this message because you are subscribed to the Google Groups "openthread-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/433b44b7-b03b-4bdc-84ed-5bf88ced0b09n%40googlegroups.com.

[Toby A]

Thanks for the reply Jonathan. So just be sure that i understand. If I had a global server, that server needs an globally routable IPv6 prefix to access the thread network? On the border router in the tayga.conf i have configured a different prefix than the well-known prefix. And with that prefix I can ping public IPv4 addreses as you mention, in case of a globally routable IPv6 prefix, should it be replaced in the tayga.conf, or is it two different prefixes?

[Jonathan Hui]

If you can assign a globally routable IPv6 prefix to the Thread network, then any device on the public internet can communicate end-to-end IPv6 and route directly to your Thread network without any need for NAT in between.

In the case that you cannot use IPv6 end-to-end, either because you do not have a globally routable prefix or you want to communicate with an IPv4 endpoint, then you will need some kind of NAT. If you want a Thread device to communicate with a global IPv4 host, then the default OTBR configuration with the well-known NAT64 prefix (64:ff9b::/96) should be sufficient.

--

Jonathan Hui

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/a293be16-c625-4c16-914d-50a4bf7f37bbn%40googlegroups.com.

[Toby A]

Okay that makes sense, but what is best practice then if you want to build a cloud solution with openthread lets say if the cloud is not hosted on the same server, especially if you want to have  both send and /receive to devices from a CoAP server f.x to support OTA DFU? Would it be to have a globally routable prefix? 

[Jonathan Hui]

It largely depends on your communication model. If all communication is initiated by the Thread device, then leveraging NAT64 will work. However, if you want the cloud to also initiate communication to a Thread device, then having globally routable infrastructure in place is generally preferred.

Note that this is not much different from how home networks work today. Many home networks use NAT, but that also means most interactions with cloud are client initiated.

--

Jonathan Hui

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/fb645917-ea4f-4100-8aeb-526a7f42de7en%40googlegroups.com.

[Toby A]

Thanks a lot for your help, Jonathan. 

[Aurélien Jarno]

Le lundi 10 mai 2021 à 18:03:58 UTC+2, Jonathan Hui a écrit :

To send packets from an external IP network to the Thread network, you must use an IP address that is routable from the external network. If that global network is the public internet, then the IP address must be globally routable on the public internet.

For IPv6, that means assigning an routable IPv6 prefix to the Thread network. On the global internet, the ISP will need to provide you with a globally routable IPv6 prefix. Some ISPs provide this service today, but not all.

 

I actually wonder how the border router is supposed to work in that case. I have a /60 assigned by my ISP, that I can split into multiple /64, and for each of them I can choose the next hop. In that case to provide full connectivity to OpenThread nodes, the idea would be to allocate one of those /64 prefixes for OpenThread and set it as the OMR prefix. In practice adding this prefix with "prefix add 2a01:xxxx:xxxx:xxxx::/64 paros med" just works. However this command just adds another prefix, but doesn't change the OMR prefix that has been allocated when the network has been formed, thus it is lost when the border router is restarted. How is that supposed to be configured properly, as it seems there is no CLI function for that?

Thanks

Aurelien

[Jonathan Hui]

In production, we expect prefix assignment to use a more automatic method such as DHCPv6 Prefix Delegation. In that case, we would automatically obtain the prefix and apply it to the Thread network any time the Thread interface is enabled. Unfortunately, we do not have that feature fully supported yet.

--

Jonathan Hui

--

You received this message because you are subscribed to the Google Groups "openthread-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/96095c90-bd16-459b-ae62-de148ea654d3n%40googlegroups.com.

[Stuart Longland]

On Tue, 11 May 2021 00:26:35 -0700 (PDT)
Toby A <taun...@gmail.com> wrote:

> Okay that makes sense, but what is best practice then if you want to build
> a cloud solution with openthread lets say if the cloud is not hosted on the
> same server, especially if you want to have both send and /receive to
> devices from a CoAP server f.x to support OTA DFU? Would it be to have a
> globally routable prefix?

One option is to have the Thread device "observe" a CoAP resource that
gives it instructions on what to do next. Your mileage may vary, but
testing at my workplace through two firewalls (one with NAT) to the
Californium test server (coap://californium.eclipseprojects.io:5683/)
showed it can work through IPv4 NAT firewalls.

The other (not mutually exclusive) option is to supply dedicated border
routers that provide a VPN link which is native IPv6.
--
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
...it's backed up on a tape somewhere.