2018
August
23

IPv6-based Thread networks in an IPv4-based enterprise network

By Thread Group

When defining requirements for building automation, network designers want to make sure that their solution of choice operates well within the existing network. At the same time, they need assurance that the solution is both future proof and scalable. This is also true for developers defining smart products for the home.

Thread is based on existing and widely deployed standards, like IPv6, and has been specifically designed for technologies that provide long-term deployment. Due to its extremely large addressing space, IPv6 allows every single device to have its own unique address which has not been possible before.

IPv6 is the successor to IPv4, the "legacy" internet protocol. IPv4 is known for its xxx.xxx.xxx.xxx addressing structure, where xxx can be a number between 1 and 255. With IPv4, approximately 4 billion unique addresses are possible, which is not nearly enough to cover every device on the planet.

It has been clear for a long time that IPv4 no longer provides the addressable space that is required by the modern internet, and with more and more devices (including non-traditional computing equipment and connected "things") connecting to the internet, this problem has become increasingly critical. In several regions around the world, IPv4 addresses are no longer being provided as is shown on the below graph, which includes APNIC, LACNIC and ARIN, organizations that represent the Asia-Pacific, Latin-American and North-American regions for IP-address assignment.

To overcome the limitations of IPv4, local networks (including enterprise networks) use a technology called NAT (Network Address Translation) to act as an agent between the local network and the public Internet. NAT-functionality is included in a single device such as a router, allowing one IPv4 address to represent a larger group of computers to the outside network.

However, this form of address translation has a number of limitations which do not solve all the issues that arise due to IPv4's limited addressing-range. This is why IPv6 was developed.

IPv6 allows for 340,282,366,920,938,000,000,000,000,000,000,000,000 IP addresses, enough for every molecule in our solar system. On top of this extended addressing space, IPv6 adds several other benefits while fixing some shortcoming of IPv4. It has more efficient forwarding so it does not have to fragment packets (which slows down the network), has built-in Quality-of-Service allowing delay-sensitive packets to get priority in the data transfer, and includes automatic address configuration by default eliminating complicated manual address assignment. And its improved header structure results in less processing overhead.

More and more Internet Service Providers and enterprise networks are being upgraded to support IPv6. For these networks, Thread can be integrated simply without the need for any address translation. For networks that still run on the legacy IPv4 protocol, some adaptations are needed. Luckily, much of this is handled by the Thread Border Router(s) which is the wireless access point that connects the Thread network to the enterprise network and thus also the cloud.

Let's look into this in a bit more detail.

Thread defines an IPv6 transport over an IEEE 802.15.4 data-link layer. A 6LoWPAN adaptation layer in between implements IPv6 header compression for maximizing efficiency. In the context of the OSI layers, only the network layer is affected in a situation where IPv4 networks are being used, as all of the other layers are fully transparent to the existing network.

A Thread Border Router is a simple device that connects the Thread wireless network to the rest of the enterprise network. Unlike "gateways" found in many wireless solutions, it is fully transparent to the transport and application protocols that reside above. As a result, applications can communicate securely from end-to-end without any application-layer translation. Furthermore, since Border Routers do not maintain any application-layer state, there can be multiple Border Routers in a network, eliminating a "single point of failure" in the event one of them malfunctions.

The Border Router enables every Thread device to directly connect to global cloud services, both when enterprise networks run IPv6 and IPv4, or IPv4 only.

Home Network

Enterprise Network

So how can a Thread network connect to an IPv4 network?

A Thread Border Router typically handles all the requirements that are needed. A Border Router is not necessary to form a local Thread mesh-network. It is required to connect a Thread network to the outside world via the local home or enterprise network and the cloud.

Most Border Routers implement NAT64 communication between IPv6-based Thread devices and IPv4 networks. NAT64 is the mechanism that translates IPv6 packets to IPv4 and vice versa. The Border Router functions as an IPv4 host on the wide-area network, capable of obtaining an IPv4 interface and router address. It will acquire an address using DHCP from its IPv4 address pool. The Border Router may also implement Port Control Protocol (PCP) to control how incoming IPv4 packets are translated and forwarded and support static mappings.

In an enterprise network it is not necessary to first connect to the internet to set up the NAT table entries in order for the cloud service to connect back to the device (as is a typical characteristic of NAT64 in non-enterprise situations.) This is because service discovery can be used. The Border Router will report on what is available within its local network and the IPv4 address that can be used from its NAT64 entry.

Optionally, Thread Border Routers use DHCPv6. If they do, DNS64 must be included. Because they support the DNS Long-Live Queries, the Router is capable of locating public IPv4 services and therefore it can connect to devices on the local IPv4 network as well as the global internet.

An example of a Thread Border Router that includes all the necessary functionality is the D-Link DSH-G300-TBR, a home automation gateway used for applications such as intelligent lighting, indoor positioning and asset tracking.

In conclusion, most of the IPv4 to IPv6 (and vice versa) translations are often handled by the Thread Border Router, with minimal changes needed to the existing network. This means that Thread can be immediately implemented in current working situations, offering all of its benefits in terms of security and direct addressability, while ensuring that the Thread network is future proof when the time comes for a partial or full transition to IPv6.

Suggested reading:

For more information on the workings of a Thread Border Router, including all its mandatory and optional services, we suggest you review the following documents published by Thread Group:

Thread Border Routers - Overview
(Particularly p. 10 and p. 21)
https://www.threadgroup.org/Portals/0/documents/support/BorderRouterWhitePaper_657_2.pdf

Thread Border Routers - Best Practices
(Particularly p. 14-16 - This document also includes a list to the mentioned RFC-standards from the Internet Engineering Task Force)
https://www.threadgroup.org/Portals/0/documents/support/ThreadBorderRouterBestPractices_2530_1.pdf

OpenThread Border Router Reference
https://github.com/openthread/borderrouter/