Available online at www.sciencedirect.

com
Available online at www.sciencedirect.com
Available online
Available at www.sciencedirect.com
online at www.sciencedirect.com

ScienceDirect
Procedia Computer Science 00 (2018) 000–000
Procedia
Procedia Computer
Computer Science
Science 13400 (2018)
(2018) 000–000
377–384
Procedia Computer Science 00 (2018) 000–000

The Fourth International Workshop on the Future of the Internet of Things (FIT 2018)
The Fourth International Workshop on the Future of the Internet of Things (FIT 2018)
A Qualitative Evaluation
The Fourth International of IPv6
Workshop on thefor theofIndustrial
Future the Internet ofInternet of2018)
Things (FIT Things
A Qualitative Evaluation of IPv6 for the Industrial Internet of Things
A Qualitative Evaluation of IPv6
Benjamin for
Feldnera,∗ the Industrial
a,∗
, Paula Herberbb Internet of Things
Benjamin Feldner , Paula Herber
a HARTING IT Software Development, Berlin, Germany
a,∗ b
Benjamin
b Software and Embedded Feldner
a HARTING IT Software
Systems ,Technische
Paula
Development,
Engineering, Herber
Berlin, GermanyBerlin, Germany
Universität
b Software and Embedded Systems Engineering, Technische Universität
a HARTING IT Software Development, Berlin, GermanyBerlin, Germany
b Software and Embedded Systems Engineering, Technische Universität Berlin, Germany

Abstract
Abstract
IPv6 is the most promising protocol for complex and distributed network applications in the era of the Internet of Things and
Abstract
IPv6 is4.0.
Industry theHowever,
most promising protocol
its industrial for complex
adoption, and distributed
in particular network applications
in smart manufacturing systems, in has
the been
era ofmuchthe Internet of Things
slower than and
expected.
Industry
IPv6 is4.0.
Although the However,
potential its industrial
advantages
most promising ofadoption,
protocol IPv6 for in
theparticular
for complex industrial ininternet
smart manufacturing
and distributed systems,
of thingsapplications
network in has
are well-known, the itbeen
era much
is of
not slower
easily
the than
usable
Internet inexpected.
practice.
of Things and
Although
Industry the However,
In this paper,
4.0. potential
we presentadvantages
itsa industrialofadoption,
qualitative IPv6 for in
evaluation the
of industrial
IPv6 forinthe
particular internet of things
industrial
smart are of
internet
manufacturing well-known, has it
things. We
systems, have
beenis not easily
conducted
much usable
thanininterviews
expert
slower practice.
expected.
In thisfive
with
Although paper,
the we present
industrial IPv6
potential ausers.
qualitative
advantages evaluation
OurofkeyIPv6results
for theof IPv6 for
indicate
industrial the
that industrial
the major
internet internet
are of
problems
of things arethings. We it
threefold:
well-known, have conducted
First,
is not tool expert
support
easily usable ininterviews
and existing
practice.
with
In thisfive
libraries industrial
are
paper, IPv6or
incomplete
we present ausers. Our key
immature.
qualitative results
Second,
evaluation indicate
users
of still for
IPv6 that
oftenthethe
havemajor problems
to manually
industrial ofare
internetconfigurethreefold:
things.theWeIPhaveFirst, tool support
communication.
conducted and
Third,
expert existing
there are
interviews
libraries
with fiveare
complicated incomplete
one-fits-all
industrial orusers.
immature.
IPv6protocols Our Second,
prevalent.
key We users
results stillrecommendations
derive
indicate often havemajor
that the to manually configure
for further
problems the IP communication.
developments
are threefold: to advance
First, andThird,
tool support ease there
andthe useare
of
existing
complicated
IPv6 for are
libraries smart one-fits-all protocols
manufacturing
incomplete prevalent.
systems.
or immature. Second,We derive
users stillrecommendations for further
often have to manually developments
configure to advance andThird,
the IP communication. ease the useare
there of
IPv6 for smart manufacturing systems.
complicated one-fits-all protocols prevalent. We derive recommendations for further developments to advance and ease the use of
c 2018
IPv6
 The
forThe
smart Authors. Published
manufacturing by Elsevier Ltd.
systems.
© 2018 Authors. Published by Elsevier Ltd.
c 2018
This is The
an Authors.
open access Published
article by Elsevier
under the CC Ltd.
CC BY-NC-ND
BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/3.0/)
(http://creativecommons.org/licenses/by-nc-nd/3.0/).
This is an open access article under the license
This
 is an
c 2018 Theopen access
Authors. article under
Published by ofthethe
CCscientific
Elsevier BY-NC-ND
Ltd. license (http://creativecommons.org/licenses/by-nc-nd/3.0/).
Keywords: Industrial Internet of Things, Distributed Applications, IPv6,ofSmart
Peer-review under responsibility committee the 13th International Conference on Future Networks and
Manufacturing
This is an open access
Communications, article under
FNC-2018 and thethe CCInternational
15th BY-NC-ND Conference
license (http://creativecommons.org/licenses/by-nc-nd/3.0/).
on Mobile Systems and Pervasive Computing, MobiSPC 2018.
Keywords: Industrial Internet of Things, Distributed Applications, IPv6, Smart Manufacturing
Keywords: Industrial Internet of Things, Distributed Applications, IPv6, Smart Manufacturing

1. Introduction
1. Introduction
1. Over
Introduction
time it got obvious that the IPv4 protocol, which enabled the internet spreading in the first place, would suffer
fromOver time itshortage
address got obvious
soonerthatorthe IPv4
later. Toprotocol,
overcome which enabled
this and otherthe internet
issues, thespreading in thespecification
IPv6 protocol first place, would suffer
was started
from address
Over
in 1996 [8]. itshortage
timeNot got
only, sooner
obvious
but thatordue
also later.
the IPv4
to Toprotocol,
the overcome thisaddress
which
much bigger and other
enabled issues,
the
space, IPv6the
internet IPv6 protocol
isspreading
seen as ofspecification
in the
one firstkey
the place, was for
would
enablers started
suffer
the
in
from1996
Internet [8].
address Not
of Things only,
shortage but alsoor
sooner
(IoT). This due
term to
later.
wasthe muchby
Tocoined
overcomebigger
thisaddress
Kevin and space,
other
Ashton inissues,
1999IPv6 isand
the
[2] seen
IPv6 as one of
protocol
describes the key enablers
a specification
scenario for the
wasphysical
where started
Internet
in
objects of Things
1996get
[8]. Not only,
extended (IoT).
inbutThis
a way term
alsothey
duecan was
to becoined
the muchby Kevin
bigger
connected Ashton
address
to the inas
space,
internet 1999 [2]
IPv6
own isand describes
seen
entities as one
and a scenario
of
actively where physical
thecommunicate
key enablers for the
through
objects
Internet get
it. The use extended
of of
Things
such (IoT). in a way
smart This they
objectstermincan
wasbecoined
networkedconnected to theAshton
by Kevin
applications internet
opensin upas aown
1999 entities
[2]
broad and andnew
actively
fielddescribes
for communicate
a scenario
use cases where
that through
physical
integrate the
it. The use
objects
physical get of suchintosmart
extended
world objects
in a way
software they incan
networked
applications. applications
be connected opens upasaown
to the internet broad field for
entities andnew use cases
actively that integrate
communicate the
through
physical
it. The
The useworld
of such
challenges intoto software
smart
realize applications.
objects
such in networked
systems applications
are ranging opens upto
from hardware a broad
softwarefield forinclude
and new use cases that
hardware integrate the
downsizing, re-
The challenges
physical
duction ofworld
energy tosoftware
realize such
intoconsumption, systems
applications.
IP network arelayer
ranging from hardware
integration of wirelessto software
networks and
of include
various hardware downsizing, re-
kinds, configuration-free
duction of energyresource
The challenges
communication, consumption,
to realize
and such IP
service network
systems arelayer
discovery integration
ranging
and of wireless
from hardware
suitable building to networks
software
blocks (e.g.andof include
various hardware
application kinds,
protocols configuration-free
downsizing, re-
or middleware
communication,
duction
systems)oftoenergy
enable resource and service
consumption,
distributed applicationdiscovery
IP network layerand suitable
integration
architectures withoutbuilding
of central
wireless blocks (e.g.
networks
control application
of various
elements. protocols
kinds,
Security or middleware
is configuration-free
another important
systems) to enable
communication, distributed
resource application
and service architectures
discovery without
and suitable centralblocks
building control elements.
(e.g. Security
application is another
protocols important
or middleware
systems) to enable distributed application architectures without central control elements. Security is another important
∗ Corresponding author. Tel.: +49-5772-47-9953 ; fax: +49-5772-47-909953.
∗ Corresponding
E-mail address:author. Tel.: +49-5772-47-9953 ; fax: +49-5772-47-909953.
Benjamin.Feldner@HARTING.com
∗ E-mail address:author.
Corresponding Benjamin.Feldner@HARTING.com
Tel.: +49-5772-47-9953 ; fax: +49-5772-47-909953.
E-mail address:
1877-0509 Benjamin.Feldner@HARTING.com
© 2018 The Authors. Published by Elsevier Ltd.
1877-0509
This is an c 2018
open The Authors.
access Published
article under the by
CCElsevier
BY-NC-NDLtd. license (http://creativecommons.org/licenses/by-nc-nd/3.0/)
This
1877-0509
Peer-review c 2018
is an open
 access
under article under
Theresponsibility
Authors. the of
CCthe
Published BY-NC-ND
by Elsevier license
Ltd.
scientific (http://creativecommons.org/licenses/by-nc-nd/3.0/).
committee of the 13th International Conference on Future Networks and
Communications,
This is an open
1877-0509 c 2018
 FNC-2018
access
Thearticle
Authors. and
under theCC
the
Published15th International
BY-NC-ND
by Elsevier licenseConference
Ltd. on Mobile Systems and Pervasive Computing, MobiSPC 2018.
(http://creativecommons.org/licenses/by-nc-nd/3.0/).
10.1016/j.procs.2018.07.195
This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/3.0/).
378 Benjamin Feldner et al. / Procedia Computer Science 134 (2018) 377–384
Feldner et al. / Procedia Computer Science 00 (2018) 000–000 2

Figure 1. Decomposition of the automation pyramid [10]

issue in many areas for such systems. There has been some progress towards realizing and improving the IoT in recent
years [1], but research and implementation in this wide field are still ongoing.
In the industrial domain the potential of IoT based applications was recognized as well. In the traditional automation
pyramid, as shown in Figure 1, the layers of a production control system are strictly hierarchical, where disparate
technologies are used for each layer. In contrast, the IoT allows every part (the whole way from the enterprise layer
down to sensors and actuators in the field) of a production process to communicate by means of the Internet Protocol
(IP). This means that we move from a layered automation hierarchy towards a cyber-physical system based network,
where all components can directly communicate with each other by means of the IP. This opens up new possibilities for
highly dynamic systems with decentralized process logic, distributed production and product intelligence. Important
terms known in this respect are Industry 4.0 [4], smart factory, as well as cyber-physical production systems (CPPS)
and IP based machine-to-machine (M2M) communication. In the following we will refer to such applications as
distributed applications for the industrial IoT, or in short, IIoT applications.
Despite promising concepts and specifications for IIoT systems, the industrial adoption and practical applicability
of IPv6 seems to progress only slowly. In this paper, we present the results of a qualitative evaluation of uses of IPv6
for IIoT applications. In particular, we have conducted expert interviews with five industrial IPv6 users and discuss
the results. With that, we gain an impression of the practical usability of IPv6 and IP based application protocols
for the IIoT application development life cycle, including the implementation, testing, configuration, deployment and
maintenance.
The remainder of this paper is structured as follows: first, we briefly introduce the preliminaries of this paper,
followed by an excerpt of related work. After that, the used approach and aimed goals are described, followed by a
description of the questionnaire we used in the expert interviews. Subsequently, we present and discuss the results of
the interviews. Finally, we conclude and derive recommendations for future work.

2. Preliminaries

In this section, we briefly introduce the IPv6 protocol and some application protocols that are often used in IIoT
applications, namely DNS-SD with mDNS, MQTT, HTTP based RPC APIs, HTTP based RESTful APIs, and CoAP.

2.1. IPv6 protocol

Address Syntax. An IPv6 address has a size of 128 bits instead of 32 bits making its address space 7, 9 · 1028 times
bigger than IPv4. In most cases, the first 64 bits are used as the network prefix and the remaining 64 bits are used
as an interface identifier. In hexadecimal notation, an example address is: 2001:0db8:1122:3344:5566:77ff. An
address has a scope and a type. The scope can be link-local (not routed at all, participants have to be connected to the
same data link layer), unique-local (routed only outside the internet, comparable to private IPv4 networks) and global
(routable in the internet). The type can either be anycast (one-to-one, group of receivers with same anycast address,
e.g. the routing protocol calculates the actual receiver), unicast (one-to-one communication) or multicast (one-to-many
communication). For more information see [12].
 Benjamin Feldner et al. / Procedia Computer Science 134 (2018) 377–384 379
Feldner et al. / Procedia Computer Science 00 (2018) 000–000 3

Multicast Addresses. Multicast addresses have a ff prefix, the second byte determines the address scope, and the
remaining 112 bits are used to identify the multicast group. An example multicast address is: ff01:0:0:0:0:0:0:1
Multicast is also used in the initial automatic IPv6 interface configuration.

Stateless Address Autoconfiguration (SLAAC). The initial automatic configuration is part of the stateless address auto-
configuration [23] feature. Basically, the configuration works as follows: In a first phase, the interface is automatically
configured with a IPv6 link-local address. In a second phase it looks for IPv6 routers. Routers may answer with a
routable scope network prefix that the interface uses to configure a corresponding IPv6 address.

2.2. Application Protocols

The following application protocols are often used in IIoT applications, and are referenced in our discussion of the
results from expert interviews about IPv6 uses in IIoT applications.

DNS-SD with mDNS. The multicast Domain Name System (mDNS) [6] is an application protocol that uses the
same data structures (resource records) as the hierarchical Domain Name System (DNS) and IP multicast to work
independent of a central server. While mDNS can be used to publish one name for a host, DNS Service Discovery
(DNS-SD) [5] extends this with the possibility to publish arbitrary services for a host using DNS resource records.

MQTT. The Message Queue Telemetry Transport (MQTT) protocol [3] is a lightweight TCP-based application pro-
tocol that decouples publisher and subscriber by a central broker component. Publisher use the broker to publish
messages with certain topics. These topics can be registered by the subscribers.

HTTP based RPC APIs. In remote procedure call (RPC) based approaches, the HTTP protocol and its request-
response mechanism is used to externally provide functions of a component to transmit the requested function and
parameters in a HTTP request, e.g. encoded in JSON or XML, and return the results as a HTTP response.

HTTP based RESTful APIs. RESTful APIs are another approach of externally providing functions of a component.
REST stands for “REpresentational State Transfer” [9]. There, the different HTTP methods are mapped to create,
query, update and delete resources, that represent functional aspects of a component. For example, a sensor reading
can be requested by sending a GET request to the component URL that identifies the sensor as a resource.

CoAP. The Constrained Application Protocol (CoAP) [20] is intended to make the RESTful paradigm available for
constrained devices with little hardware resources.

3. Related Work

There exist several surveys on the IoT and IIoT applications. For example, in [22], the authors survey fog computing
and embedded systems platforms as the building blocks of IoT. They discuss various platforms and technologies,
and they give some evidence why IPv6 is inherently more secure than IPv4. However, although they identify some
interesting challenges in the context of the rise of IoT, they do not focus on industrial uses of IoT and they do not
address the advantages and disadvantages of IPv6 for the application life cycle. In [11], the authors present a survey
of the latest trends in the communication domain of industrial distributed systems and emphasize important questions
as dependability, and standardization. Again, they do not address the advantages and disadvantages of IPv6 for the
application life cycle, and they do not provide an evaluation of existing industrial distributed systems. In [24], the
current state-of-the-art of IoT in industries is summarized. Again, they do not address the specific characteristics of
IPv6 and its uses for IIoT.
There also exist some domain-specific analyses and evaluations of IPv6. For example, in [17], the authors introduce
the requirements and issues to adapt the fieldbus protocols to IPv6. In particular, they thoroughly analyze the technical
effects of a transition to IPv6 with the Fieldbus protocol. However, their analysis is only applicable for the special case
of the Fieldbus protocol and the results can not be transferred to general IIoT applications. In [16], the authors propose
an analytical framework to evaluate the performance of IPv6-based mobility management protocols. However, the
380 Benjamin Feldner et al. / Procedia Computer Science 134 (2018) 377–384
Feldner et al. / Procedia Computer Science 00 (2018) 000–000 4

results are specific for mobility management protocols and the focus is on performance and not on the application life
cycle. In [7], the authors present an evaluation of IPv6 for low power and lossy networks. However, the evaluation is
very specific for low power and lossy networks, and the focus is again on performance. In [18], the IPv6 handover over
wireless LANs is analyzed and evaluated. Again, the evaluation is very specific for the considered domain and the
focus is on performance. In [19], the authors evaluate IPv4 and IPv6 on Windows Vista and Linux Ubuntu. However,
the focus is on performance of the protocols in general purpose computing and not on IIoT applications.
Finally, in [13], an evaluation of the transition from IPv4 to IPv6 in unmanaged networks is presented. Although
they raise some interesting issues, e.g. standardization requirements and security issues, the focus is explicitly on the
transition from IPv4 to IPv6 and not on the general applicability of IPv6. Furthermore, they consider small unmanaged
home networks and neither IIoT applications nor the application life cycle.

4. Goals and Approach

In this paper, we aim at qualitatively evaluating the gap between theoretical advantages of IPv6 protocol uses
for the industrial IoT domain and its practical applicability. We achieve this by conducting expert interviews with
professionals in the field of application development for the IIoT. Our main objectives are threefold: First, we aim at
finding out what approaches are used to implement IIoT applications in practice. Second, we want to evaluate the role
the IP protocol plays in that regard. Third, we aim at deriving recommendations to bridge or at least reduce the gap
between theory and practice.
To carry out the evaluation, we have conducted expert interviews with five professionals who are working in the
field of industrial IoT application development. Two of them are system architects with broad expertise in computer
networks, embedded software engineering and hardware engineering and the remaining are software developers that
are also experienced in the field of embedded software engineering, computer networks, as well as cloud computing
and web technologies.
The interviews were conducted face-to-face, complemented by audio recording, and we designed the questionnaire
such that one interview took between one and one and a half hours.

5. Questionnaire

Our questionnaire consists of four sections. We have designed the sections to contain partially overlapping topics
to make sure that we collect all interesting aspects from the interviewees. In total, we have formulated 38 open-ended
questions. In the following, we give a brief description of each section.

Distributed IIoT applications. In the first s ection o f t he i nterview, w e h ave f ocused o n e xample d istributed IIoT
applications where the interviewee was or is involved in the development life cycle. Besides the architectural concept
of the example application, we have inquired aspects like tool usage and the infrastructural setup used in various life
cycle stages. Also, we have inquired about the technical specifics of the application in operation, for example, initial
configuration, dynamic behavior and reconfigurability, and startup and shutdown.

Role of IP based communication in the application life cycle. In the second section, we have considered the role of
IP based communication in the development life cycle. In particular, we have inquired about the application protocols
that were used and which IP version was employed accordingly. In this section, we have also included some detailed
questions about the IP specific configuration of the application. We complemented this by inquiring whether concepts
like group communication, service-discovery or resource discovery are involved in the architectural concept.

IPv6 vs. IPv4. In the third section, we have covered experiences with the IPv6 protocol in general compared with
IPv4, discussed issues that arise from a transition from IPv4 to IPv6, and have inquired the experts general opinion on
IPv6 vs. IPv4.

IIoT application protocols. Finally, in the fourth section, we have gathered the interviewees experience with other
specific IIoT application protocols.
 Benjamin Feldner et al. / Procedia Computer Science 134 (2018) 377–384 381
Feldner et al. / Procedia Computer Science 00 (2018) 000–000 5

Modbus RTU / Modbus / RS485

binary TCP RFID data to MQTT MQTT events
RFID Reader
translator
00Sensor
Modbus
event translator 01

MQTT publish MQTT publish

MQTT publish
Other computer / MQTT subscribe Sensor Device +
Data Logging + MQTT broker MQTT publisher
Analysis

Embedded
computer with
lightweight
virtualization

Figure 2. Condition monitoring application

6. Evaluation

In this section, we present our qualitative evaluation of the results from the expert interviews. The structure of this
section corresponds to the structure of the questionnaire.

6.1. Distributed IIoT applications

In the first section of the interview, we have asked all expert interview partners to picture an example of distributed
IIoT applications they have been involved in, to discuss why they did or did not use IPv6, and to describe technical
details of the IIoT application, including the tools and infrastructure they have used. Amongst others, the following
applications have been described by the interviewees:

1. a Bluetooth Personal Area Network (PAN) based self-organizing wireless network application for directional
alarm forwarding,
2. an application that recognizes sensors attached to a programmable logic controller (PLC) by RFID tags and
publishes their readings to an MQTT broker,
3. a condition monitoring application where readings of Modbus RS485 based and USB based sensors are made
available as MQTT events.

Communication architecture. In the alarm forwarding system, the focus is on dynamic routing, and the Bluetooth
PAN profile i s u sed w ith I Pv4. P reconfigured no des ar e dy namically at tached an d de tached. IP v4 is us ed because
IPv6 is not available in the specific project setup. In the other two applications, diverse approaches are used to enable
IP communication for the application components. Some sensors are equipped with their own hardware and can
directly communicate IP based. The Modbus subsystem of sensors as well as the PLC are integrated by using a proxy
component that translates from Modbus respectively PLC to MQTT events. Components that contain business logic,
translate between IP protocols, or allow data storage are implemented as containers for an embedded linux based
computer system, which provides a lightweight virtualization. These containers have their own network interface as
well as an isolated runtime sandbox.
As an example, the architecture of the condition monitoring application (3.) is illustrated in Figure 2. Depicted
are the contained components and the involved communication channels. Starting in the upper left, an RFID reader
is connected to a container running on an embedded computer system as described above, and sends its data using a
proprietary binary TCP protocol. The container, which itself is registered as a MQTT publisher to the MQTT broker
container, translates incoming RFID data to MQTT events and publishes them to the broker. The Modbus/MQTT
translator container translates Modbus data of Modbus sensors connected to an RS485 interface of the embedded
system to MQTT events and sends them to the broker container. A workstation computer is connected to the MQTT
broker as a subscriber for all topics for analysis and logging purposes. Finally, there are sensors connected as MQTT
publishers to the broker, which are capable of sending MQTT events with their own hardware.
382 Benjamin Feldner et al. / Procedia Computer Science 134 (2018) 377–384
Feldner et al. / Procedia Computer Science 00 (2018) 000–000 6

Communication setup. The applications were mainly designed with a static setup containing predefined, initially
known components. However, a more dynamic approach was taken for the second application, which provides trans-
lated PLC sensor data as MQTT events. In that case, the components matching to a sensor are identified by an RFID
tag and are added or exchanged on the fly by an admin component. Two out of three applications are designed to work
without a specific startup sequence and to be able to cope with a power cycle.

Implementation languages and tools. The development was mainly carried out on Linux and Windows workstations,
the application components itself are mostly Linux-based . The implementation languages for components are partly
constrained due to the availability of libraries that had to be used, partly they were chosen to best fit the requirements.
Ultimately, a variety of languages was used, e.g. C, C++, NodeJS, and Python. Common for the actual development
of all three applications is the use of a version control system. Besides that, IDEs or bare text editors have been used.

Debugging support. The applications have been manually tested and debugged after deployment with the help of
tools like ssh to examine faulty components. Sometimes, also network analysis tools like Wireshark were used to
debug the communication between components. This was necessary due to the lack of a comprehensive facility to
debug or trace distributed applications, as known for conventional applications in IDEs like Visual Studio or XCode.

Reusability. The applications have been designed and implemented to work in specific setups. Adapting them to
varying setups like other PLCs or different production machines would involve component changes, partly by code
changes, partly by configurational changes. An important aspect of such an adaption that was repeatedly mentioned
is the need to reconfigure the communication part of the application.

Common issues. Besides IP-specific issues discussed in 6.2, the experts raised the following issues:

• It would be desirable to have a standard way to decouple the logical from the physical structure in IIoT appli-
cations.
• It would be desirable to be able to implement a truly distributed system without dependencies to central com-
ponents like e.g. a DHCP server or an MQTT broker.
• It would be desirable to have the ability to use IP based communication and standard application protocols at
every point in the production process and further reduce the use of specialized communication systems like
PLCs and fieldbuses for realtime control to subsystems where this is absolutely necessary.

6.2. Role of IP based communication in the application life cycle

For all applications discussed in the interviews, IP based communication is the key element. The application pro-
tocols used to implement the above-mentioned components and involved in the product development are, besides
proprietary TCP-based protocols, mainly MQTT, a JSON remote procedure call mechanism with WebSockets and
HTTPS, RESTful HTTP interfaces as well as mDNS. Besides that, several command line tools have been used for
development and debugging, e.g. ping, ssh, scp, ftp, avahi-resolve, netcat and wget.

Problems with IPv6. In two out of three of the distributed IIoT example applications, the initial idea was to use IPv6
link local addresses (2.1) in order to be able to use IP communication means without the necessity to configure.
However, during the implementation of the components, two major problems arose: First, the general IPv6 support
in some tools and libraries that had to be used for the linux based components were not mature and stable enough.
Second, although the zone ID part of IPv6 link local addresses is sufficient for the scope of the applications, some
browsers do not support them at all. As browsers are often used for maintenance etc., this is a major limitation of
IPv6 link local addresses. Also, many of the aforementioned tools could not be used with mDNS in combination
with IPv6 link local addresses. In the end, IPv4 was chosen to circumvent these issues. Additionally, constraints due
to IT regulations in most setups (e.g, DHCP server were not available) led to the situation that the whole network
communication part of the application had to be configured manually.
 Benjamin Feldner et al. / Procedia Computer Science 134 (2018) 377–384 383
Feldner et al. / Procedia Computer Science 00 (2018) 000–000 7

Application protocol integration. To decouple access from actual IP addresses on host level, two out of the three
example IIoT applications employ mDNS. The expert interviewees noted that the mDNS implementation Avahi had
to be patched to always publish the IPv6 link local addresses of the respective interface, independent of other IPv6
addresses of that interface. Apart from that, MQTT with its publish-subscribe-approach was often used to enable
group communication at the application layer to decouple component communication. Some interviewees suggested
the idea to use IPv6 multicast features to achieve this decoupling at the IP layer, to become independent of the central
MQTT broker component.

6.3. IPv6 vs. IPv4

Besides the most prominent IPv6 feature, its large address space, the stateless automatic address configuration
(SLAAC) is seen by all interviewees as one of the main building blocks for distributed IIoT applications without the
need to manually configure the communication setup. It was also noticed that for embedded systems, the simpler IPv6
header structure might be beneficial.
The biggest issues with IPv6 identified by our expert interviewees are immature tool support and the lack of
libraries, as well as the aforementioned pitfalls when using link local addresses that are complementary to local scope
protocols like mDNS. The steeper learning curve of IPv6 poses additional problems. A further disadvantage of IPv6
is the potential uncertainty of actual IPv6 support in other network environments where an application may be used
in the future. Our experts stated that adjustments to IT regulations or suitable administration tools seem to be needed
in order to better adapt to the IP protocol related requirements of distributed IIoT applications. The main advantages
of IPv4 are, in the experience of our expert interviewees, its mature tool and library support and the much bigger
likelihood that a developer knows it.
Although the wide-spread expertise and mature tool support makes the application development with IPv4 eas-
ier in the beginning, there were always drawbacks when it came to network interface configuration or issues with
components like DHCP servers.

6.4. IIoT application protocols

In this section of the interview, we asked our IIoT application experts about experiences with other IIoT specific
application protocols. One protocol that was not covered in the example applications but mentioned in the interviews
is the DNS-SD protocol, which enables real decentral service discovery. Being used in conventional computer sys-
tems for quite some time, e.g. for printer installation and configuration or discovery of music libraries in iTunes, its
applicability for smart objects has also been subject of research, e.g. in [14]. One of the interviewees explained that
they already conceptually included the integration of DNS-SD with link local IPv6 for being able to use automatic
configuration-less resource discovery in applications. However, they have not been able to implement it due to the
aforementioned IPv6 issues.
In general, the experts agreed that in their experience, it is more suitable to combine well-known protocols that can
be quickly learned and intuitively used by an average developer rather than using a complicated all-in-one protocol.

7. Conclusion

The potential advantages of IPv6 for implementing IIoT applications, especially the automatic communication
configuration a nd c onfiguration-less re source di scovery wi thout ad ditional de pendencies to ce ntral co mponents as
well as the large address-spaces, are well-known. However, there are still many obstacles that prevent its pervasive
use. The key problems identified in our qualitative evaluation are threefold: First, tool support and existing libraries
are incomplete or immature. Second, users still often have to manually configure the IP communication. Third, there
are complex one-fits-all protocols prevalent.
To advance and ease the use of IPv6 for smart manufacturing systems in particular and IIoT applications in general,
a generic approach to remove the discussed pitfalls is highly desirable. Some ideas to solve the IPv6 link local problem
are presented in [21]. Furthermore, the complexity could be reduced by combining simpler protocols.
At the same time, a crucial point is to provide an easy way to familiarize system architects and software developers
with the IPv6 protocol and its role in the application development life cycle. Configuration-less resource discovery,
 384 Benjamin Feldner et al. / Procedia Computer Science 134 (2018) 377–384
Feldner et al. / Procedia Computer Science 00 (2018) 000–000 8

e.g. with DNS-SD, provides a starting point for decoupling the logical from the physical structure. The MQTT pro-
tocol, while decoupling component communication, can not be used in a completely decentralized manner due to the
dependency to the central broker component.
In future work, we plan to investigate whether a true decentralized approach can be achieved with simple and
lightweight protocols like CoAP and how IPv6 features like multicast can help in that regard. The actor model intro-
duced by Lee et al. [15] could serve as theoretical foundation for such an approach. Furthermore, we plan to investigate
use cases for configuration-less IPv6 as a generalized means to debug distributed IIoT applications. Finally, while the
issues we discuss in this paper are mostly related to IP based machine to machine communication, we also plan to
investigate the human machine interface, e.g. the compatibility with existing browsers.

References

[1] Al-Fuqaha, A., Guizani, M., Mohammadi, M., Aledhari, M., Ayyash, M.: Internet of things: A survey on enabling technologies, protocols, and
applications. IEEE Communications Surveys Tutorials 17(4), 2347–2376 (Fourthquarter 2015)
[2] Ashton, K.: That internet of things thing. RFiD Journal 22(7) (2011)
[3] Banks, A., Gupta, R.: Mqtt version 3.1.1. Tech. rep. (April 2014), http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.
html
[4] Brettel, M., Friederichsen, N., Keller, M., Rosenberg, M.: How virtualization, decentralization and network building change the manufac-
turing landscape: An industry 4.0 perspective. International Journal of Mechanical, Aerospace, Industrial, Mechatronic and Manufacturing
Engineering 8(1), 37 – 44 (2014)
[5] Cheshire, S., Krochmal, M.: DNS-Based Service Discovery. RFC 6763 (Proposed Standard) (Feb 2013), http://www.ietf.org/rfc/
rfc6763.txt
[6] Cheshire, S., Krochmal, M.: Multicast DNS. RFC 6762 (Proposed Standard) (Feb 2013), http://www.ietf.org/rfc/rfc6762.txt
[7] Clausen, T., Herberg, U., Philipp, M.: A critical evaluation of the ipv6 routing protocol for low power and lossy networks (rpl). In: Wireless
and Mobile Computing, Networking and Communications (WiMob), 2011 IEEE 7th International Conference on. pp. 365–372. IEEE (2011)
[8] Deering, S., Hinden, R.: Internet Protocol, Version 6 (IPv6) Specification. RFC 1883 (Proposed Standard) (Dec 1995), http://www.ietf.
org/rfc/rfc1883.txt, obsoleted by RFC 2460
[9] Fielding, R.T.: Rest: architectural styles and the design of network-based software architectures. Doctoral dissertation, University of California
(2000)
[10] Foidl, H., Felderer, M.: Research Challenges of Industry 4.0 for Quality Management, pp. 121–137. Springer International Publishing, Cham
(2016)
[11] Gaj, P., Jasperneite, J., Felser, M.: Computer communication within industrial distributed environment - a survey. IEEE Transactions on
Industrial Informatics 9(1), 182–189 (Feb 2013)
[12] Hinden, R., Deering, S.: IP Version 6 Addressing Architecture. RFC 4291 (Draft Standard) (Feb 2006), http://www.ietf.org/rfc/
rfc4291.txt, updated by RFCs 5952, 6052, 7136, 7346, 7371
[13] Huitema, C., Austein, R., Satapati, S., Van der Pol, R.: Evaluation of ipv6 transition mechanisms for unmanaged networks. Tech. rep. (2004)
[14] Jara, A.J., Martinez-Julia, P., Skarmeta, A.: Light-weight multicast dns and dns-sd (lmdns-sd): Ipv6-based resource and service discovery for
the web of things. In: 2012 Sixth International Conference on Innovative Mobile and Internet Services in Ubiquitous Computing. pp. 731–738
(July 2012)
[15] Lee, E.A., Neuendorffer, S., Wirthlin, M.J.: Actor-oriented design of embedded hardware and software systems. Journal of circuits, systems,
and computers 12(03), 231–260 (2003)
[16] Makaya, C., Pierre, S.: An analytical framework for performance evaluation of ipv6-based mobility management protocols. IEEE Transactions
on wireless communications 7(3), 972–983 (2008)
[17] Miyata, H., Miyazawa, K., Akisada, Y., Endo, M.: The analysis of ipv6 adaptation to the industrial network protocol. In: 2009 7th IEEE
International Conference on Industrial Informatics. pp. 614–619 (June 2009)
[18] Montavont, N., Noël, T.: Analysis and evaluation of mobile ipv6 handovers over wireless lan. Mobile Networks and Applications 8(6), 643–653
(2003)
[19] Narayan, S., Shang, P., Fan, N.: Performance evaluation of ipv4 and ipv6 on windows vista and linux ubuntu. In: Networks Security, Wireless
Communications and Trusted Computing, 2009. NSWCTC’09. International Conference on. vol. 1, pp. 653–656. IEEE (2009)
[20] Shelby, Z., Hartke, K., Bormann, C.: The Constrained Application Protocol (CoAP). RFC 7252 (Proposed Standard) (Jun 2014), http:
//www.ietf.org/rfc/rfc7252.txt
[21] Smith, M.: How to use ipv6 link-local addresses in applications. Internet-Draft draft-smith-ipv6-link-locals-apps-00, IETF Secretariat (October
2015), http://www.ietf.org/internet-drafts/draft-smith-ipv6-link-locals-apps-00.txt
[22] Tayeb, S., Latifi, S., Kim, Y.: A survey on iot communication and computation frameworks: An industrial perspective. In: 2017 IEEE 7th
Annual Computing and Communication Workshop and Conference (CCWC). pp. 1–6 (Jan 2017)
[23] Thomson, S., Narten, T., Jinmei, T.: IPv6 Stateless Address Autoconfiguration. RFC 4862 (Draft Standard) (Sep 2007), http://www.ietf.
org/rfc/rfc4862.txt, updated by RFC 7527
[24] Xu, L.D., He, W., Li, S.: Internet of things in industries: A survey. IEEE Transactions on Industrial Informatics 10(4), 2233–2243 (Nov 2014)