IoT Hurdles: Designing IPv6 Things in an IPv4 World

Jonny Doin

CEO – GridVortex Systems

Agenda

!   Introduction

!   IPv6

!  Mesh Networks

!  6loWPAN: Header Compression and Border Routers

!  UDP instead of TCP

!   IPv6 => IPv4 Transition Mechanisms

!  Example: Android App interfacing with IoT application –  P2P with embedded devices –  Integration with IPv6

!  Final Thoughts

Introduction

!  The Internet will see all kinds of Embedded Devices and new applications

!  While the data traffic of those systems may not be too large, there must be an unique address for each one

Source: http://www.satiztpm.it/internet-things

IPv6

!   The new Embedded Applications will add billions to trillions of new unique addresses to the Internet

!   Hard Fact: full depletion of the adress space for the IPv4 (32 bits worth of unique addresses – 4 bytes)

!   IPv6: 16 bytes (128 bits) of addressing, or 7.9 * 1028 times more addresses

!   Caveat: IPv6 headers are 4 times longer than IPv4 headers

http://www.digitaltrends.com/computing/world-ipv6-launch-day-explained-the-next-unseen-evolution-of-the-web/#!bG589T

IPv6 (2)

!  The new expanded address range is much better than expanding the effective address space of IPv4 using NAT (Network Address Translation)

!  Stateless Address Auto Configuration – SLAAC (RFC4862, RFC4941)

!  Neighbor Discovery – ND (RFC4861, RFC6775)

IPv6 (3)

!   IPv6 headers take 40 bytes, compared to 20 bytes for IPv4

source: Wikipedia

Why IPv6 ?

!   IPv6 is a lighter protocol than IPv4

!  Lower management overhead, important in embedded applications

!  No need for centralized node address configuration

!   IPv4 address space saturation will only get worse

!   IPv6 applications are simpler to design and deploy

Mesh Networks

Source: Industrial Ethernet Book, issue 49 / 36

!   Dynamic Self-Healing algorithms used to promote reorganization of node interconnections

!   Increased network reach at lower power radio

!   In Mesh Networks each mesh node takes part in the packet routing

6loWPAN

!   IPv6 over Low Power Wireless Personal Area Networks

!  Unique address for each node in the mesh

!  Designed to be implemented on 802.15.4 radio networks

!  Main feature is IPv6 header compression

!  Enables Internet connectivity for 802.15.4 networks

6loWPAN: Header Compression !  The standard IPv6 packet MTU is at least 1280

bytes

!  802.15.4 MTU is only 127 bytes

!  The standard headers for IPv6 leave a rather small room for user payload

!  The response to that problem is Header Compression

!  Header Compression schemes allow context-based compression downto 2 bytes of header

6loWPAN: Border Router

!  Connects 6loWPAN meshes to the Internet

!  Handles header compression/expansion

!  Gateway between at least two different network interfaces

24 6LoWPAN: THE WIRELESS EMBEDDED INTERNET

1.4 Network Example

In this section we give a short example of how 6LoWPAN works in practice, concentrating onthe basic things that occur during bootstrapping and operation. Figure 1.13 shows an exampledeployment of a Simple LoWPAN, connected through a backhaul link to the IPv6 Internet.The LoWPAN consists of an edge router, three LoWPAN Routers (R) and three LoWPANhosts (H). Additionally there is a remote server on the Internet. This LoWPAN is based onIEEE 802.15.4 and uses IP routing (which is why there are LoWPAN Routers). Fake IPv6subnet prefixes and addresses of nodes are included in the figure to make it easy to follow theexample (in reality addresses would be longer).

The router to the Internet advertises the IPv6 prefix 2001:300a::/32 on the backhaul link,which is used by the edge router for autoconfiguration. The edge router then configures theIPv6 prefix 2001:300a:1::/48 to its IEEE802.15.4 wireless interface. Note that the LoWPANand backhaul link are on different subnets as this uses the Simple LoWPAN model. TheIEEE 802.15.4 wireless devices in the LoWPAN assume a default channel and securitykey settings. The edge router starts advertising the IPv6 prefix, which is used by the threerouters to perform Stateless Address Autoconfiguration, and to register with the edge router

IPv6 Internet

Remote server

Router

H

H

H

R R

R

LoWPAN

P2P link

2001:300a:1::/48

2001:300a::/32

2001:a03f::1ffa

::1

::2

::3

::4::5

::6

::7

Edge router

Figure 1.13 A 6LoWPAN example.Source: SHELBY, Zach. BORMANN, Carsten. 6LOWPAN The Wireless Embedded Internet. Chichester, UK: Wiley, 2009

6loWPAN: Border Router (2)

!  Example: 6loWPAN / 802.3 gateway

!  Enables seamless P2P connectivity between loWPAN nodes and standard UDP/IP devices

!  Direct connection to, e.g., SmartPhones, Tablets, Computers and other 6loWPAN devices over the Internet

160 6LoWPAN: THE WIRELESS EMBEDDED INTERNET

6LoWPANinterface

Ethernetinterface

IPv6

eth0 6lowpan0

6LoWPAN driverEthernet driver

TCP UDP ICMP

Figure 6.8 Edge router with a 6LoWPAN network interface.

interface peripheral, e.g. in the form of a USB stick. The interface between the wirelessinterface and the edge router hardware is usually realized with UART, SPI or universal serialbus (USB) interfaces.

To support the wireless interface, a driver is needed for the edge router operating system.This driver implements the interface to the 6LoWPAN stack on the wireless interface. In orderto route 6LoWPAN to other IP networks the driver typically emulates a network interfacein the operating system, and would show up as e.g. 6lowpan0 in a Unix-based protocolstack. This network interface method is supported for example in Contiki uIP, TinyOSBLIP and NanoStack Linux support. To the standard IPv6 protocol stack this interfacelooks just like an Ethernet interface, with the exception of a 1280-byte MTU. The IPv6protocol stack expects to receive standard IPv6 frames from a network interface; thus in orderto avoid changing existing IPv6 stacks, 6LoWPAN-related functionality should mostly beimplemented below the network interface. Depending on the way that the wireless interfaceis realized, there may be more or less functionality handled by the OS driver. Some solutionsfor example implement only IEEE 802.15.4 in the wireless interface, and leave all 6LoWPANfunctionality to the driver.

In order to use a 6LoWPAN wireless interface with a standard IPv6 protocol stack, thefollowing functionality needs to be implemented:

LoWPAN Adaptation Layer: The 6LoWPAN frames received from the link-layer needto be decompressed as specified in [RFC4944] and [ID-6lowpan-hc], using knowninformation about the LoWPAN. In the other direction, full IPv6 frames from thenetwork interface need to be compressed. This step could be performed in the wirelessinterface or the edge router driver.

Source: SHELBY, Zach. BORMANN, Carsten. 6LOWPAN The Wireless Embedded Internet. Chichester, UK: Wiley, 2009

6loWPAN: UDP instead of TCP

!  6loWPAN meshes are low-bandwidth and low-power networks

!  CSMA-CA (collision avoidance): wait for free channel to talk

!  UDP have the smallest utilization of the channels

!  TCP is too heavy for these networks

!  This choice impacts how applications are designed

IPv6 => IPv4 Transition Mechanisms

•  6in4 •  6to4 •  NAT64 •  TEREDO •  6over4

IPv6 networks in a IPv4 World

REALITY: The Internet is still

predominantly IPv4

!  The switch to IPv6 is not a transparent move

!  Packets exchanged between IPv6 and IPv4 nodes need modifications

!  There are several options for the co-existence of IPv6 systems with the IPv4 backbone.

6in4 tunelling

!  Packet tunelling of IPv6 packets through IPv4 !  Transparent to the applications !  Requires End-to end control of the implementation

Source: http://www.sixscape.com/joomla/sixscape/index.php/technical-backgrounders/tcp-ip/ip-the-internet-protocol/ ipv6-internet-protocol-version-6/transition-mechanisms-from-ipv4-to-ipv6/tunneling/6in4-tunneling

6to4 translation/encapsulation

!  Use of prefix 2002: to identify 6to4 packets !  Connect IPv6 Islands and Internet sections through

IPv4 backbones !  Standard gateways can route 2002:: prefixed packets !  Packets have an overhead due to encapsulation

Source: Wikipedia

NAT64 translation

!   Connects IPv6 clients to IPv4 servers !   Is frequently a stateful dynamic translation !   Can be paired with DNS64 to provide the stateful translation !   The IPv4 address is carried into a 32bit field on the 64:ff9b::/96

IPv6 address

Source: Wikipedia

TEREDO

!  Host-to-Host tunelling for IPv6 over IPv4 !  Uses standard IPv4 UDP packets for encapsulation !  Can withstand multiple layers of standard NAT !  Completely transparent for the routing IPv4

environment

Source: http://technet.microsoft.com/en-us/library/bb457011.aspx

6over4 Virtual Link Layer

!   IPv4 used as a virtual Link Layer !  Supports IPv6-ND over the IPv4 network !  Requires IPv4 Multicast which is not widely used

Source: http://www.cisco.com/web/about/ac123/ac147/downloads/customer/internetprotocoljournal/ipj_3-1/images/Fig_IV1.gif

IPv6 networks in a IPv4 World (2)

!   Integration of IPv6 applications into the IPv4 Internet is not a transparent issue

!  Designers must decide what translation mechanism to use during Design Time

!  Depending on the choice, specific physical routing gear must be deployed

!   IPv6 address selection impacts on the chosen translation mechanisms

!  Specific configuration of the gateways and host applications must be applied

Application Example Integration of an Android App with a 6loWPAN Embedded

Application

(Smart Lighting)

Application Example

!  The application example is a simple Android App that employs direct P2P connection with a 6loWPAN network of Smart Street Lampposts.

!   In this application, a WiFi router is used to connect to the loWPAN

!  The chosen transition mechanism in this case is 6to4

!  Device enumeration and service discovery using 2002:: prefixes for the loWPAN nodes

!  This is a contrived example, that limits the Android node to link-local due to current Android limitations

Device and Service Discovery

Devices:

!  Discovery of 6loWPAN border routers via multicast IPv6 (ad-Hoc)

!  FF02::1 – link local multicast address used by Android app

!  All border routers present in the same link will respond and enumerate

Device and Service Discovery (2)

Services:

!  SSDP – Simple Service Discovery Protocol

!  Uses HTTPU (HTTP over UDP)

!  Devices advertise services by multicast IPv6 at port 1900

!  SSDP is a powerful means of interoperability

!  Supported by all major Operating Systems

Android and IPv6

Current version (Kitcat 4.4.4) has partial support for IPv6

!  There is a race condition between the Kernel and dhcpcd in Android, which leads to conflict between DHCPv6 and the link-local address configured by the kernel

!   In this example application, we decided to disable DHCPv6, and used the SLAAC configured fe80:: link local address

!  This is a least-effort implementation

!  The resulting connection is limited to link-local, i.e., to the WiFi router visibility

CoAP

!  Constrained Application Protocol

!  UDP-based

! RESTful (Representational State Transfer)

!  Binary encoding –  Small frames –  Easy to parse

!  Supports Multicast

!  Application-layer: must be designed into the App as an End-to-end concern

CoAP

!  Easily translated to HTTP

!  Extensible

!  TLV – Type-Length-Value

! jCoAP –  https://code.google.com/p/jcoap/

%QPUVTCKPGF�#RRNKECVKQP�2TQVQEQN

$KPCT[�RTQVQEQNƔ .QY�RCTUKPI�EQORNGZKV[

Ɣ 5OCNN�OGUUCIG�UK\G

1RVKQPUƔ 0WODGTU�YKVJ�+#0#�TGIKUVT[

Ɣ 6[RG�.GPIVJ�8CNWG

Ɣ 5RGEKCN�QRVKQP�JGCFGT�OCTMU�RC[NQCF�KH�RTGUGPV

Source: KOVATSCH, Matthias. VERMILLARD, Julien. Hands-on with CoAP. France: EclipseCon, 2014.

Example App

Final Thoughts Integration of IPv6 Embedded Applications require informed Design-Time decisions regarding the Network deployment

The choices have an impact on the Embedded Application and the peer connected application

Knowledge of idiosyncratic behaviors of the Network elements (stacks, OS, routers) is necessary

Thank You

Jonny Doin CEO - GridVortex

jonnydoin@gridvortex.com