Author’s pre-print, accepted for publication in the IEEE Communications Magazine (2017-7-13).
copyright 2017 IEEE. Please refer to the final version once published.
Personal use of this material is permitted. Permission from IEEE must be obtained for all other users, including
reprinting/ republishing this material for advertising or promotional purposes, creating new collective works for
resale or redistribution to servers or lists, or reuse of any copyrighted components of this work in other works.

From 6LoWPAN to 6Lo: Expanding the Universe of IPv6-Supported
Technologies for the Internet of Things
Carles Gomez1, Josep Paradells2, Carsten Bormann3, Jon Crowcroft4
1
Universitat Politècnica de Catalunya (UPC)
2
Universitat Politècnica de Catalunya (UPC)/i2CAT Foundation
3
Universität Bremen TZI
4
University of Cambridge
E-mail: {carlesgo, teljpa}@entel.upc.edu, cabo@tzi.org, jon.crowcroft@cl.cam.ac.uk
Abstract
Leveraging 6LoWPAN, the IETF 6Lo working group has targeted adaptation of IPv6
over a new generation of communication technologies for the IoT. These comprise
Bluetooth LE, ITU-T G.9959, DECT ULE, MS/TP, NFC, IEEE 1901.2, and
IEEE 802.11ah. This paper comprehensively analyzes the 6Lo technologies and
adaptation layers, giving the motivation for critical design decisions, highlighting
crucial aspects for performance, and presenting main challenges.

1. Introduction
The Internet of Things (IoT) is an emerging networking paradigm whereby daily life
objects, some of them equipped with sensors or actuators, are connected to the Internet.
The IoT vision promises a revolution, leading to substantial improvement in global
sustainability, efficient resource management, enhanced productivity and increased
human life quality, by enabling innovative applications in a wide variety of trending
domains. Examples of the latter include smart cities, home and building automation,
smart factories, smart grid, remote health, intelligent transportation systems, etc.
Making the IoT become a reality is a multiagent effort comprising advances in various
technical fields and the involvement of academia, industry, public administration and
standards development organizations. To enable the aforementioned IoT applications, a
plethora of inexpensive, network-capable IoT devices are being deployed worldwide. In
order to provide Internet connectivity to the vast number of IoT devices, estimated as a
few tens of billions by year 2020 [1], IPv6 is the optimal protocol given its large set of
available addresses, tools for unattended operation, and intrinsic interoperability.
However, IPv6 was designed for resource-rich networking scenarios (e.g. Ethernets),
whereas common IoT network environments are significantly more limited. The latter
comprehend devices with severe energy, memory, processing, and communication
constraints. Such devices use wireless (or wired) links characterized by low data rate,
short data unit length, high bit error rate and variable link quality. Therefore, adaptation
functionality is required to support and optimize IPv6 over constrained-node networks.
Such functionality is usually abstracted as an adaptation layer, that is, a protocol stack
layer inserted between IPv6 and a target technology, designed to efficiently enable IPv6
over that technology (Figure 1.a). An adaptation layer may provide lightweight
encoding formats (e.g. IPv6 header compression), support for data transport (e.g.
1

fragmentation and reassembly over technologies with short frame payload, multihop
data delivery for mesh topologies, etc.), and energy-frugal network parameter
configuration.
IPv6 packet

a)
IPv6 header

Compressed
IPv6 header

IPv6

· · ·

IP he

· · ·

Fragmentation
header

Adaptation layer
· · ·

payload

Link layer
(target technology)

· · ·

frame
a
IP he

b)

· · ·

b
· · ·

LLC / Adaptation

c

d

e

d

e

d

· · ·

f

g

h

PHY/MAC

f

g

≤g

f

h

h

· · ·

IEEE 802.15.4, Bluetooth LE, ITU-T G.9959, DECT ULE, NFC, IEEE 1901.2
11
IP he

c)

≤j

i

k

PHY/MAC
MS/TP, IEEE 802.11ah

Field
a
b
c
d
e
f
g
h

IEEE 802.15.4
11
0
4
0
5
29
102
2

Bluetooth LE
7
0
8
0
6
15
27
3

Field size (bytes)
ITU-T G.9959
DECT ULE
11
7
0
2
4
4
2
0
5
4
34
12
158
38
2
2.5

NFC
11
0
7
0
7
5
128
2

IEEE 1901.2
11
0
0
0
0
40
215
2

Field
i
j
k

Field size (bytes)
MS/TP
IEEE 802.11ah
8
30
1500
7951
5
4

Figure 1.a) An example of adaptation layer functionality; b) IPv6 datagram
encapsulation over 6Lo technologies, fragmentation needed; c) IPv6 datagram
encapsulation over 6Lo technologies, fragmentation not needed.

In late 2004, the IETF IPv6 over Low power Wireless Personal Area Networks
(6LoWPAN) Working Group (WG) started to produce the adaptation layer to support
IPv6 over IEEE 802.15.4, the de-facto low-rate, low-power wireless radio interface. The
6LoWPAN adaptation layer [2] was completed by the end of 2012, and thus the
6LoWPAN WG was subsequently closed. However, the panoply of communication
technologies for constrained devices had been (and still is) growing steadily. Therefore,
the need to extend IPv6 support to a new generation of wireless and wired
communication technologies for the IoT was identified. The IETF IPv6 over Networks
of Resource-constrained Nodes (6Lo) WG was created in 2013 with the main goal of
carrying out this crucial work, leveraging 6LoWPAN. As of the writing, the 6Lo WG
has targeted IPv6 adaptation for a wide and diverse set of communication technologies
2

(here
einafter, 6L technologies), rangi from generic-purp
Lo
ing
g
pose to app
plication-specific
solut
tions, which comprise Bluetooth Low Energy (Bluet
h
es
th
tooth LE), ITU-T G.9959,
DEC Ultra Lo Energy (DECT UL
CT
ow
LE), Master
r-Slave/Tok
ken-Passing (MS/TP), Near
g
Field Communi
d
ication (NFC), IEEE 1 901.2, and IEEE 802.11ah. Figur 2 summa
re
arizes
the t
timespan of the 6LoW
f
WPAN and 6Lo WGs activity, an the chro
nd
onology of their
f
produ
uced specif
fications.
The work carrie out by th 6Lo WG which co
ed
he
G,
omprises bo complete and on-g
oth
ted
going
stand
dardization items, is ex
xpected to c
connect sev
veral billion devices to the Internet (of
n
o
Thin
ngs). Howev it has only been co
ver,
onsidered to a very lim
o
mited extent in the literature.
For t first tim to our be knowled
the
me
est
dge, this pap provide a compre
per
es
ehensive ana
alysis
of th 6Lo techn
he
nologies an adaptatio layers. Th remainder of the pa
nd
on
he
aper is orga
anized
as fo
ollows. Sec
ction 2 ove
erviews the wireless and wired interfaces targeted by the
e
6LoW
WPAN and 6Lo WG Section 3 descri
d
Gs.
n
ibes the main 6LoW
m
WPAN and 6Lo
comp
ponents, an discusses the design solutions adopted to enable an optimize IPv6
nd
s
n
o
nd
over the 6Lo te
echnologies. Section 4 presents main 6Lo ch
.
m
hallenges. F
Finally, sect
tion 5
concludes the pa
aper.

Fig
gure 2. Chro
onology and timespan of the 6LoW
d
WPAN and 6Lo WGs ad
6
daptation la
ayer
specific
cations and activity.

2. W
Wireless and wired technolog for th Internet of Thin
gies
he
ngs
This section int
troduces an discusses the wirele and wir technol
nd
s
ess
red
logies for which
w
IPv6 support has been or is being deve
eloped by th 6LoWPA and 6Lo WGs. The main
he
AN
o
3

features of each technology, highlighting those especially relevant for IPv6 adaptation,
are shown in Table I.

2.1. IEEE 802.15.4
IEEE 802.15.4 is the seminal standard defining physical layer (PHY) and Medium
Access Control layer (MAC) functionality for low-power wireless applications. The
original version of this standard was published in 2003, constituting a milestone in its
application space. Shortly after, the IETF established the 6LoWPAN WG with the aim
of enabling IPv6 support over IEEE 802.15.4 networks. Since then, several IEEE
802.15.4 amendments have been released, and a plethora of on-going amendment
efforts for specialized environments are currently in progress. Remarkably, a specific
IETF WG called 6TiSCH was established in 2013 to define the mechanisms and
architecture to enable IPv6 over Time Slotted Channel Hopping (TSCH), a salient mode
of IEEE 802.15.4e [3]. This intense activity is a sign of IEEE 802.15.4 technology’s
good health.

2.2. Bluetooth LE / Bluetooth Smart
Bluetooth LE, also marketed as Bluetooth Smart, is the hallmark feature in the
Bluetooth 4.0 specification, published in 2010. Bluetooth LE is a protocol stack that
was designed in order to enable multi-year operation for battery-powered devices such
as sensor nodes. Most smartphones are currently being manufactured with Bluetooth LE
support, therefore the potential space for Bluetooth LE is counted in billions of units.
With Bluetooth LE, the smartphone may act as a gateway able to collect data from
sensors, wearables, and other consumer electronics devices, and to send those data to
the Internet (e.g. via 4G or Wi-Fi). Bluetooth LE extensions have been recently
provided in subsequent Bluetooth specifications. The functionality required to enable
IPv6 over Bluetooth LE comprises the IPv6 over Bluetooth LE specification, recently
published as RFC 7668, and the Bluetooth SIG Internet Protocol Support Profile (IPSP)
[4]. RFC 7668 has served as a model for 6Lo specifications over technologies that
define simple network topologies such as star or point-to-point.

2.3. ITU-T G.9959
Z-Wave is a protocol stack developed more than a decade ago by ZenSys (now, Sigma
Designs) for wireless home automation. Z-Wave has gained significant market presence
in this domain, in fact having been available in products earlier than competing
technologies such as ZigBee [5]. Born as a proprietary solution, Z-Wave PHY and
MAC layers were first standardized by the ITU-T in 2012 as the G.9959 specification.
The first adaptation layer specification produced by the 6Lo WG, published as RFC
7428, defines the adaptation of IPv6 over ITU-T G.9959 networks. These
standardization efforts extend the Internet connectivity possibilities of this technology
beyond existing Z-Wave-to-IP (Z/IP) protocol translation gateways.

4

2.4. DECT ULE
The Digital Enhanced Cordless Telecommunications (DECT) radio interface has been
used for more than two decades for wireless telephony and data applications in indoor
scenarios. Recently, a new variant of this technology called DECT ULE has been
standardized by the ETSI to enable low-power wireless applications. DECT ULE
introduces MAC layer changes to the original DECT standard, while it retains PHY
compatibility. Therefore, DECT ULE has significant potential given the strong DECT
deployment base, especially in the home area. The 6Lo WG has created RFC 8105, a
specification to support IPv6 over DECT ULE.

2.5. MS/TP
MS/TP is a MAC layer mechanism defined for the RS-485 PHY. These MAC and PHY
layers are a subset of the options defined in BACnet, an ANSI/ASHRAE standard
extensively used in the building automation domain. Remarkably, RS-485 defines a
Shielded Twisted Pair (STP) wired, low-error rate multidrop bus. Furthermore, devices
in MS/TP networks have a continuous power source. On the other hand, such networks
offer limited data rates, and MS/TP devices are often constrained in processing power
and memory; to benefit from IPv6, the IETF 6Lo WG has produced a specification
(RFC 8163) to adapt IPv6 over MS/TP networks, even if the latter are relatively
different environments compared with those of other communication technologies for
constrained devices.

2.6. NFC
Near Field Communication (NFC) comprises a set of standard technologies for shortrange (i.e. below 20 cm) wireless communication. NFC is available in a variety of
devices, including tags and the main smartphone platforms. Since sales of the latter are
currently being counted in hundreds of millions per year, the potential of NFC is
enormous. Its short range provides intrinsic security properties, as in fact, electronic
payment has become a popular application for this technology. When two NFC
endpoints are powered, a peer-to-peer NFC mode can be used. A specification to
support IPv6 over the peer-to-peer mode of NFC is being developed by the 6Lo WG.

2.7. IEEE 1901.2
Power Line Communication (PLC) has been used for decades for home automation,
telemetry and broadband Internet access. IEEE 1901.2 is a PLC standard approved in
2013 (amended in 2015), intended for smart grid applications, that defines PHY and
MAC functionality for narrowband communications. IEEE 1901.2 is designed to
overcome harsh conditions such as adverse Signal-to-Noise-Ratio (SNR) and variable
characteristics (e.g. line impedance) in space, time and frequency. In fact, IEEE 1901.2
links share a significant degree of commonality with low-power wireless links, such as
high bit error rate. A specification to support IPv6 over IEEE 1901.2 has been proposed

5

in the 6Lo WG, although the IEEE 1901.2 specification also describes how to configure
an IPv6-based IEEE 1901.2 multihop network.

2.8. IEEE 802.11ah
IEEE 802.11ah is an IEEE 802.11 amendment whose standardization process is
expected to be completed in the near future. It addresses the lack of low-power support
for sensor networks in the IEEE 802.11 standard. Target applications of IEEE 802.11ah
comprise metering, and backhaul links for data collected by sensors. IEEE 802.11ah is
favored by the massive popularity of Wi-Fi, but it cannot make use of currently
deployed access points, since IEEE 802.11ah is not backwards compatible with
previous versions of IEEE 802.11. As of the writing, IEEE 802.11ah has been the most
recent one to join the set of technologies for which IPv6 support is being developed by
the 6Lo WG.

2.9. Discussion
Most of the introduced technologies are wireless, which provides flexibility and low
deployment cost. Nevertheless, wireless technologies are subject to interference and
radio propagation issues. Even if IEEE 1901.2 is wired, it also has low installation cost,
since it reuses existing power grid lines, and naturally suffers interference due to
coexistence with the electricity signal. In contrast, MS/TP uses a high-quality field bus.
Supported network topologies range from simple point-to-point (NFC) or star
topologies (BLE, DECT ULE, IEEE 802.11ah) to mesh networks (IEEE 802.15.4, ITUT G.9959, IEEE 1901.2). The latter involve greater complexity to enable end-to-end
communication, however they better overcome coverage limitations and offer path
diversity. For example, nowadays home automation deployments are mainly based on
mesh network technologies. On the other hand, MS/TP, IEEE 1901.2 and IEEE
802.11ah offer greater link range than the rest of technologies. MS/TP has been
designed to reach devices throughout large buildings via a shared bus, while the latter
two technologies support smart grid and metering use cases, which involve
communication between distant devices such as meters and concentrators that aggregate
data from several households. Finally, NFC and BLE exploit their widespread presence
in smartphones, which transform the smartphone into both an Internet connectivity
gateway and a remote control for direct interaction with sensors or actuators.

3. 6LoWPAN and 6Lo: IPv6 over IoT technologies
In order to enable IPv6 over IEEE 802.15.4 networks, the adaptation layer called
6LoWPAN was developed. Subsequently, 6Lo made use of 6LoWPAN as a basis to
support IPv6 over Bluetooth LE, ITU-T G.9959, DECT ULE, MS/TP, NFC, IEEE
1901.2, and IEEE 802.11ah. This section analyses the following fundamental technical
elements and mechanisms of 6LoWPAN and 6Lo: locus of the adaptation layer in the
protocol stack, routing, addressing, header compression, fragmentation, encapsulation,
6

neigh
hbor discov
very, and multicast su
m
upport. Tabl 1 includes a summ
le
mary of the main
featu of the 6
ures
6LoWPAN and 6Lo ada
a
aptation lay
yers.

3.1. Locus of t adapta
the
ation layer in the pro
r
otocol stac
ck
When designing a solution to enable I
g
IPv6 over a communications techn
nology, a cr
rucial
decis
sion is the locus of th adaptatio layer in the protoco stack of that techno
he
on
ol
ology.
Since IPv6 is a network la
e
ayer protoco the 6Lo layer must be placed a
ol,
atop a link layer
proto
ocol. When a link layer comprises several su
s
ublayers (e.g a MAC s
g.
sublayer and also
d
a Lin Layer Co
nk
ontrol (LLC sublayer), one of the sublayers has to be ch
C)
,
h
hosen to inte
erface
the 6Lo layer This sel
r.
lection dep
pends on criteria in
ncluding he
eader over
rhead,
comp
patibility w previous technolog versions, upper laye multiplex
with
gy
,
er
xing capabilities,
and s
segmentatio and reassembly sup
on
pport (the la
atter avoids the need fo fragment
for
tation
at th 6Lo layer). Figure 3 shows t IPv6-based protoc stack f each 6L or
he
the
col
for
Lo
6LoW
WPAN tech
hnology.
Bluetooth LE, DECT UL and NF define complete protocol st
LE
FC
tacks up to the
o
appli
ication laye When IP is used on top of these, the native upper layer prot
er.
Pv6
t
n
r
tocols
used in each technology are replaced b IP-based upper-layer protocols (e.g. UDP, TCP,
e
by
etc.) and applica
ation-layer protocols (e CoAP [6], HTTP, etc.).
p
e.g.
e

F
Figure 3. Pro
otocol stack and exam
k,
mple network topology, for each 6L
k
f
Lo/6LoWPA
AN
te
echnology when using I
w
IPv6. BLE stands for Bluetooth LE
s
B
E.
7

Medium
Frequency band (MHz)
Range (m)
Bit rate (kbit/s)
Max. single-frame L2
payload (bytes)
ACKs and retries
Technology

MAC mechanism
Address size (bits)
L2 fragmentation
Network topology
Protocol stack
Application
Standardization
organization

Adaptation
Layer

Routing required
Mesh under support
Fragmentation
6LoWPAN
Header
Compression
6LoWPAN
Neighbor Discovery
Multicast
Privacy addresses
L2 security used

6LoWPAN
IEEE
802.15.4
Wireless
868/915/2400
10-100
20/40/250
105

DECT ULE

6Lo
MS/TP

NFC

Wireless
2400
10-100
1000
23

ITU-T
G.9959
Wireless
868/915
100
9.6/40/100
158

Wireless
1900
< 300
1152
38

Wired
Base-band
1000
115.2
2032

Wireless
13.56
< 0.2
106/212/424
125

Optional

Yes

Optional

Yes

No

ACK/NACK

CSMA/CA,
TDMA
16/64
No
Star and mesh

TDMA

CSMA/CA

TDMA

48
Yes
Star

40
Yes
Mesh

20/40/48
Yes
Star

Token
passing
8
No
Multi-drop
bus

PHY/Link
Generic
purpose
IEEE

PHY to App.
Smartphonecentric
Bluetooth SIG

PHY/Link
Home
automation
ITU-T

PHY to App.
Home
automation
ETSI

TDMA link
initialization
6
Yes
Point-topoint
PHY to App.
Contactless
exchange
NFC Forum

Yes
Yes
Yes
Yes

No
No
No
Yes
(star topol.)

No
No
No
Yes
(star topology)

Yes

Yes
(no multihop)
L2 unicast
Random IID
Yes

Yes
Yes
No
Yes
(address
adaptation)
Yes

L2 broadcast
Not specified
Yes

Bluetooth LE

L2 broadcast
DHCPv6
Yes

Yes
(no multihop)
L2 unicast
Random IID
Yes

PHY/Link

Building
automation
ANSI/
ASHRAE

No
No
No
Yes
(address
adaptation)
Partially
L2 broadcast
Random IID
No

No
No
No
Yes
(address
adaptation)
With
DHCPv6
L2 broadcast
Random IID
No

IEEE
1901.2
Wired
< 0.5
> 1000
≤ 500
215
(worst case)
ACK/NACK
(optional)
CSMA/CA
16/64
Yes
Star and
mesh
PHY/Link
Smart grid,
home autom.
IEEE
Yes
No
No
Yes
DHCPv6
only
No
DCHPv6
Yes

IEEE
802.11ah
Wireless
< 1000
< 1000
150-7800
7951
Yes
CSMA/CA
48
Yes
Star
PHY/Link
Sensors,
backhaul
IEEE
No
No
No
Yes
(address
adaptation)
Yes
(no multihop)
L2 multicast
Random IID
Yes

Table 1. Main features of IPv6-supported IoT technologies and their adaptation layers. L2 stands for Layer 2.

8

3.2. Routing
IEEE 802.15.4 networks may follow a multihop topology. To support network
connectivity in such a topology, 6LoWPAN offers two routing approaches: mesh-under,
whereby routing is performed below IP (thus a multihop path appears as a single link to
IP), and route-over, which relies on IP routing (thus each physical hop is an IP hop).
In the latter, intermediate forwarders are IP routers called 6LoWPAN Routers (6LRs).
In both approaches, the router that connects a 6LoWPAN network to another IP
network is a 6LoWPAN Border Router (6LBR).
Most 6Lo technologies define network topologies whereby there is a single physical
link between a host and the 6LBR. In these, a routing protocol is not needed. However,
ITU-T G.9959 and IEEE 1901.2 support mesh networks. The 6Lo adaptation layers for
these two technologies reuse 6LoWPAN route-over functionality (in both cases) or
mesh-under (only in the former).

3.3. Addressing
In 6LoWPAN, as in more classic networking scenarios such as Ethernet, IPv6 address
generation typically relies on embedding the link layer address in the Interface Identifier
(IID) for stateless address autoconfiguration. In 6LoWPAN, this approach is also
leveraged for total or partial address compression for IPv6 header compression. For the
same reasons, all 6Lo adaptation layers initially assumed the same mechanism for IID
generation. However, recent activity in the IETF, published in RFC 8065, has provided
advice on privacy issues due to link-layer-address-based IIDs, including correlation of
activities over time, location tracking or vendor-specific vulnerability exploitation. To
mitigate such threats, IPv6 addresses should be frequently changed and should avoid the
use of globally unique characteristics. To this end, different approaches to derive
privacy IIDs or addresses have also been adopted for the 6Lo adaptation layers.

3.4. Header compression
When communicating an IPv6 packet over IEEE 802.15.4 or a 6Lo technology, a
typical 40-byte IPv6 header would consume a significant fraction of frame payload, as
well as precious energy and bandwidth resources. 6LoWPAN header compression
(6LoWPAN HC) was defined to produce a lightweight encoding for the IPv6 header
over IEEE 802.15.4. 6LoWPAN HC leverages stateless and stateful techniques. The
former exploits the fact that some IPv6 header fields (e.g., IIDs, and datagram length)
are derivable from the link layer header, and an optimistic expectation that several IPv6
header fields will be set to typical values. The latter requires 6LoWPAN nodes to share
context that allows to substitute address prefixes or complete addresses by a short
identifier.

9

Subsequently, 6LoWPAN HC has served as the basis for header compression over the
6Lo technologies. 6LoWPAN HC has needed some tailoring to the specific
characteristics of each technology, with the exception of IEEE 1901.2, which does not
need any changes, since it endorses the IEEE 802.15.4 MAC frame and address formats.
The 6Lo specifications of IPv6 over ITU-T G.9959, MS/TP, NFC, and IEEE 802.11ah
only introduce a minimal change to 6LoWPAN HC: the adaptation of the link layer
address/identifier sizes in these technologies to the ones assumed in 6LoWPAN HC.
For Bluetooth LE and DECT ULE, 6LoWPAN HC is more deeply modified. The star
topology of these networks (see Figure 3) is exploited to optimize header compression.
In such a topology, when the central device (a 6LBR) receives a packet from one of its
neighboring hosts, it can infer that the host that sent the packet is its source. Likewise,
when a host receives a packet from the central device, the host can derive that the host
itself is the destination of the packet. Therefore, in the two described situations, the
source or the destination IPv6 addresses can be fully omitted from the IPv6 header,
respectively.
Another header compression mechanism suitable for 6LoWPAN- or 6Lo-based
networks, which can be used as an addition to 6LoWPAN HC, is the 6LoWPAN
Generic Header Compression (GHC). In contrast with 6LoWPAN HC, which is limited
to IPv6 (and UDP) headers, GHC compresses headers of any kind, at the expense of a
slight compression efficiency decrease.

3.5. Fragmentation
Most of the 6Lo/6LoWPAN target technologies exhibit a short maximum PHY/MAC
data unit size, typically in the range between a few tens and a few hundreds of bytes
(i.e. two to one orders of magnitude below the characteristic 1500-byte Maximum
Transmission Unit (MTU) of Ethernet, respectively). This feature simplifies error
control mechanisms, decreases processing and memory requirements, allows lower
energy consumption and is suitable for the typically short-sized application-layer
payloads in this space. However, IPv6 requires every Internet link to have a 1280-byte
MTU. If the link layer technology supports fragmentation (and reassembly), such
functionality can be exploited to overcome the problem. Otherwise, fragmentation must
be performed at the 6LoWPAN/6Lo adaptation layer.
Among the set of 6LoWPAN/6Lo technologies, only IEEE 802.15.4 requires the use of
adaptation layer fragmentation (which was defined by 6LoWPAN). As shown in Table
1, the rest of technologies provide their own fragmentation, with the exception of
MS/TP, which supports an MTU of 2032 bytes and thus allows transmitting
unfragmented 1280-byte IPv6 packets. IEEE 802.11ah also supports long frames.
Typical header/footer sizes and encapsulation of a large IPv6 datagram over each
6Lo/6LoWPAN technology are shown in Figure 1.b-1.c.

10

3.6. Encapsula
ation
IPv6 datagram e
encapsulatio over a 6L
on
Lo/6LoWPA technol
AN
logy incurs overhead, which
w
comp
prises heade and/or footers of p
ers
f
physical, lin and adap
nk,
ptation laye As show in
ers.
wn
Figur 4, Blueto
re
ooth LE and DECT UL exhibit the highest encapsulati overhea for
d
LE
ion
ad
medi
ium and lar size packets, due to their reduced link lay packet s
rge
o
yer
size, which leads
to se
evere fragm
mentation. IEEE 802
2.15.4, ITU
U-T G.9959 IEEE 19
9,
901.2 and NFC
experience mod
derate overh
head increas for large packets. Th encapsula
se
p
he
ation overhe is
ead
1
const
tant with th IPv6 data
he
agram size f MS/TP and IEEE 802.11ah, w
for
which suppo an
ort
MTU greater tha 1280 byt
U
an
tes.
der
ces
mber of IPv header transmitted bytes, and also
v6
t
d
Head compression reduc the num
helps decrease p
s
physical- an link-laye overhead as it allow to reduc fragmentation.
nd
er
d,
ws
ce
This is especiall beneficia in Bluetoo LE and DECT ULE, where fr
ly
al
oth
ragmentatio can
on
be av
voided for short IPv6 datagrams . When fra
agmentation headers (e
n
either adapt
tation
layer or link lay ones) ar needed, t
r
yer
re
their relativ size is sh in com
ve
hort
mparison wit the
th
other headers, as well as wi the data payload siz that requi fragmen
r
ith
ze
ires
ntation.

Figu 4. IPv6 datagram encapsulatio and Hea
ure
e
on
ader Compression (HC) overhead over
C)
IEE 802.15.4 and the 6L technolog
EE
4
Lo
gies.

1

MS/ uses an en
/TP
ncoding that allows to escap preamble sequences in other frame fie
pe
elds, which
rhead of 1 in 254.
introd
duces an addit
tional linear worst-case over
w
2

11

3.7. Neighbor discovery
The IPv6 Neighbor Discovery (ND) protocol offers router and subnet prefix discovery,
address resolution and duplicate address detection. ND was designed for transitive, high
energy and bandwidth networking scenarios, where nodes’ network interfaces are
always on, and where the ND aggressive use of multicast is a good fit. While ND is
useful to minimize human operational tasks (a good property for IoT environments), it
is not well suited to constrained-node networks, which are often duty-cycled, offer nontransitive links, and map IPv6 multicast to network-wide broadcast. The optimized ND
for 6LoWPAN (6LoWPAN ND), supports sleeping hosts by providing host-initiated
interaction with routers, and minimizes the use of multicast. In addition, 6LoWPAN ND
provides optional context dissemination for 6LoWPAN HC.
In 6Lo, the adaptation layer for each specific technology selects the most appropriate
components of 6LoWPAN (or even classic) ND in each case, with the exception of
IEEE 1901.2, which solely appears to rely on DHCPv6 for address autoconfiguration.
Among the rest of 6Lo technologies, only ITU-T G.9959 supports mesh networks, and
thus its 6Lo adaptation layer requires the use of 6LoWPAN ND multihop functionality.
The 6Lo adaptation layer for MS/TP follows a different scheme, as for prefix discovery
and address resolution it uses the classic IPv6 ND. The continuous power source of the
devices, and the multidrop bus topology of MS/TP are a natural fit for this approach.

3.8. Multicast
An important consideration is how IPv6 multicast traffic is transported over a lower
layer technology. Most 6Lo/6LoWPAN technologies support broadcast at the link layer,
but not multicast. This is intrinsically inefficient since then the transmission of a
multicast IPv6 packet may eventually lead to flooding a whole subnet. Among the
considered technologies, only IEEE 802.11ah supports multicast in addition to
broadcast at the link layer. The problem with IPv6 multicast aggravates over Bluetooth
LE and DECT ULE. Bluetooth LE data channels only support unicast, while in DECT
ULE the available MAC layer broadcast service is considered inadequate for IP
multicast. Therefore, in these technologies, an IPv6 multicast packet may have to be
unicast several times by the same node, e.g. when the 6LBR sends an IPv6 multicast
packet to a subset of its neighbors. To mitigate the impact of this behavior on energy
consumption and bandwidth, the 6LBR must only forward IPv6 multicast packets to
nodes that have registered for the intended multicast group.

12

4. Challenges in 6Lo
This section discusses two main challenge areas for 6Lo: applicability and security.

4.1. Applicability
6LoWPAN was originally designed to enable IPv6 over IEEE 802.15.4 networks.
Subsequently, 6Lo has adapted 6LoWPAN for other IoT technologies. Such adaptation
can be successfully done when an intended IoT technology is relatively similar to, or
less constrained than, IEEE 802.15.4. This is a very recent finding, as only the emerging
category of IoT technologies called Low-Power Wide Area Networks (LPWAN) has
evidenced the existence of 6Lo applicability limits.
LPWAN technologies offer long-range links (and thus low infrastructure cost) at the
expense of extreme constraints that challenge IPv6 support. These comprise: i) MTU
and bit rate up to several orders of magnitude below those in 6LoWPAN/6Lo
technologies, ii) lack of layer-two fragmentation, iii) severe message rate limitations
due to regulatory constraints, and iv) uplink/downlink asymmetry. Overall, transmission
resources are drastically limited in relevant LPWAN technologies (Figure 5). For
example, a flagship LPWAN technology called Sigfox typically offers uplink and
downlink sustained capacities of 155 mbit/s (i.e., millibit per second!) and 3.7 mbit/s,
respectively. Other LPWAN technologies with similar constraints in some of their
PHY/MAC options comprise LoRaWAN and IEEE 802.15.4k.
In order to enable IPv6 over such extraordinarily challenging scenarios, the level of
adaptation provided by 6Lo is insufficient. Over LPWAN, 6LoWPAN/6Lo mechanisms
for header compression, ND and fragmentation would all incur a too high overhead,
even rendering deployments impractical in some cases. Therefore, a new IETF working
group has been recently created to enable IPv6 over LPWAN technologies. While initial
solution proposals are currently at an early development stage, there exists already a
consensus to go significantly beyond 6Lo-style IPv6 adaptation for LPWAN.

13

Figu 5. Clus
ure
sters of 6Lo and LPWA technolog in term of their w
AN
gies
ms
worst-case MTU
M
a capacity
and
y.

4.2. Security
Secu
urity is a critical subjec in IoT, sin attacks in this area may comp
ct
nce
a
promise acti
ivities
in a vast numb of scen
ber
narios. End
d-to-end se
ecurity mec
chanisms ar availabl for
are
le
const
trained dev
vices. On the other han 6Lo adap
e
nd,
ptation laye enforce u of linkers
use
-layer
secur
rity, which is supporte by most 6Lo techn
ed
t
nologies. Ex
xceptions co
omprise MS/TP,
whic is anyway harder to attack than a wireless technology, and NFC, which gene
ch
y
n
erally
relies on its ve short ra
s
ery
ange for se
ecurity. Bo end-to-e and lin
oth
end
nk-layer sec
curity
mech
hanisms off confiden
fer
ntiality, dat integrity and authen
ta
ntication se
ervices. A major
m
chall
lenge in net
tworks that employ link
k-layer secu
urity is avoi
iding doubl setup cos for
le
sts
both the link-lay and the end-to-end security req
yer
quired.
le
ptation laye are requ
ers
uired to sup
pport IPv6 over the 6L technolo
Lo
ogies,
Whil 6Lo adap
they also introd
duce additio
onal securit threats. Main 6Lo mechanism exploitab by
ty
M
m
ms
ble
malic
cious entities comprise ND, frag
gmentation, and routing, as prese
ented in the next
e
subse
ections. Not that the related secur challen
te
r
urity
nges are solv by linkved
-layer secur as
rity
long as nodes d not beco
do
ome compr
romised. Ot
therwise, no
odes may b subject to the
be
t
threa and attac describe below.
ats
cks
ed
4.2.1 Neighbor Discovery
1.
r
y
An a
attacker ma mount Denial of S
ay
D
Service (Do attacks to ND. Ex
oS)
xamples in
nclude
masq
querading a a legitimate router b sending apparently correct ND messages and
as
by
D
s,
flood
ding bogus traffic at a victim node Counterm
e.
measures co
omprise prio
oritizing existing
route and limiting the ND message r
ers,
D
rate, respec
ctively. How a previous trusted router
w
sly
r
that b
becomes co
ompromised can be han
d
ndled is an open questio
o
on.

14

4.2.2. Fragmentation/Reassembly
A malicious node may periodically send a first fragment to reserve receiver reassembly
buffer space for a relatively long time, causing other incoming fragments (from
legitimate nodes) to be discarded by the receiver. An attacker may also transmit spoofed
fragment duplicates, which lead to incorrect IPv6 packet reassembly. Countermeasures
have been proposed [7], but have not been standardized.
4.2.3. Routing
A routing protocol, which is needed by some 6Lo technologies, may suffer brute-force
attacks to disclosure and integrity of routing information. AES-CCM with a 128-bit key
is considered a secure block cipher against such attacks. Further security measures
comprise routing message rate limitation to avoid flooding DoS attacks, and path
diversity to mitigate traffic analysis or traffic-discarding nodes. The main related open
issue is key provisioning.

5. Conclusion
6Lo leverages 6LoWPAN to significantly increase the spectrum of IPv6-supported
technologies. In comparison with 6LoWPAN, 6Lo adaptation layers tend to be more
lightweight. Fragmentation at the 6Lo layer so far is not needed, while routing is
required only for two 6Lo technologies. Another common feature of 6Lo adaptation
layers is a customized use of 6LoWPAN neighbor discovery and header compression.
The latter is crucial to reduce IPv6 datagram encapsulation overhead.
6Lo is only applicable for technologies relatively similar to IEEE 802.15.4 in terms of
transmission capacity and MTU constraints. On the other hand, 6Lo introduces security
challenges. Nevertheless, with a wide set of adaptation layers for a new generation of
diverse technologies, 6Lo provides a fundamental cornerstone towards the 100-billion
node Internet (of Things).

Acknowledgments
Carles Gomez has been funded in part by the Spanish Government through the Jose
Castillejo grant CAS15/00336. His contribution to this work has been carried out in
part during his stay as a visiting scholar at the Computer Laboratory of the University of
Cambridge. Carles Gomez and Josep Paradells have been partially supported by the
ERDF and the Spanish Government through project TEC2016-79988-P, AEI/FEDER,
UE. The authors would like to thank the members of the IETF 6LoWPAN and 6Lo
WGs.

15

References
[1]

A. Betzler, C. Gomez, I. Demirkol, J. Paradells, “CoAP Congestion Control for
the Internet of Things”, IEEE Communications Magazine, vol. 54, no. 7,
Jul. 2016, pp. 154-160.

[2]

Z. Sheng, S. Yang, Y. Yu, A.V. Vasilakos, J.A. Mccann, K.K. Leung, “A Survey
on the IETF Protocol Suite for the Internet of Things: Standards, Challenges, and
Opportunities”, IEEE Wireless Communications Magazine, vol. 20, no. 6,
Dec. 2013, pp. 91-98.

[3]

D. Dujovne, T. Watteyne, X. Vilajosana, P. Thubert, “6TiSCH: Deterministic
IP-Enabled Industrial Internet (of Things)”, IEEE Communications Magazine,
vol. 52, no. 12, Dec. 2014, pp. 36-41.

[4]

J. Nieminen, C. Gomez, M. Isomaki, T. Savolainen, B. Patil, Z. Shelby, M. Xi,
J. Oller, “Networking Solutions for Connecting Bluetooth Low Energy Enabled
Machines to the Internet of Things”, IEEE Network Magazine, vol. 28, no. 6,
Nov.-Dec. 2014, pp. 83-90.

[5]

C. Gomez, J. Paradells, "Wireless Home Automation Networks: A Survey of
architectures and technologies", IEEE Communications Magazine, vol. 48,
no. 6, Jun. 2010, pp. 92-101.

[6]

C. Bormann, A. Castellani, Z. Shelby, “CoAP: An Application Protocol for
Billions of Tiny Internet Nodes”, IEEE Internet Computing, vol. 16, no. 2,
Mar. 2012, pp. 62-67.

[7]

J. Granjal, E. Monteiro, J.S. Silva, “Security for the Internet of Things: A Survey
of Existing Protocols and Open Research Issues”, IEEE Communications
Surveys & Tutorials, vol. 17, no. 3, Aug. 2015, pp. 1294-1312.

Biographies
Carles Gomez received his Ph.D. degree from Universitat Politècnica de Catalunya in
2007. He is an associate professor at the same university. He is a co-author of numerous
technical contributions including papers published in journals and conferences, IETF
RFCs, and the book “Sensors Everywhere — Wireless Network Technologies and
Solutions”. His current research interests focus mainly on the Internet of Things. He
serves as Associate Editor of the Journal of Ambient Intelligence and Smart
Environments.
Josep Paradells is a professor at Universitat Politècnica de Catalunya and director of the
i2CAT Foundation. He has participated in national and European publicly funded
16

research projects, and collaborated with the main Spanish telecommunications
companies. He has published his research results in conferences and journals. His
expertise area is wireless Internet combining theoretical studies with real
implementations. His main focus is IoT, radio wake-up, and visible light
communication.
Carsten Bormann is Honorarprofessor for Internet technology at the Universität Bremen
and a board member of its Center for Computing and Communications Technology
(TZI). He is a protocol designer by heart, a standardization geek by necessity, and a
coauthor of the book entitled “6LoWPAN: The Wireless Embedded Internet” (Wiley,
2009).
Jon Crowcroft has been the Marconi Professor of Communications Systems in the
Computer Laboratory, University of Cambridge since October 2001. He has worked in
the area of Internet support for multimedia communications for over 30 years. Three
main topics of interest have been scalable multicast routing, practical approaches to
traffic management, and the design of deployable end-to-end protocols. Current active
research areas are opportunistic communications, social networks, and scaling
infrastructure-free mobile systems.

17

IPv6 packet

a)
IPv6 header

Compressed
IPv6 header

IPv6

· · ·

IP he

· · ·

Fragmentation
header

Adaptation layer
· · ·

payload

Link layer
(target technology)

· · ·

frame
a
IP he

b)

· · ·

b
· · ·

LLC / Adaptation

c

d

e

d

e

d

· · ·

f

g

h

PHY/MAC

f

g

≤g

f

h

h

· · ·

IEEE 802.15.4, Bluetooth LE, ITU-T G.9959, DECT ULE, NFC, IEEE 1901.2
11
IP he

c)

≤j

i

k

PHY/MAC
MS/TP, IEEE 802.11ah

Field
a
b
c
d
e
f
g
h

IEEE 802.15.4
11
0
4
0
5
29
102
2

Bluetooth LE
7
0
8
0
6
15
27
3

Field size (bytes)
ITU-T G.9959
DECT ULE
11
7
0
2
4
4
2
0
5
4
34
12
158
38
2
2.5

NFC
11
0
7
0
7
5
128
2

IEEE 1901.2
11
0
0
0
0
40
215
2

Field
i
j
k

Field size (bytes)
MS/TP
IEEE 802.11ah
8
30
1500
7951
5
4

Figure 1.a) An example of adaptation layer functionality; b) IPv6 datagram
encapsulation over 6Lo technologies, fragmentation needed; c) IPv6 datagram
encapsulation over 6Lo technologies, fragmentation not needed.

18

Fig
gure 2. Chronology and timespan of the 6LoW
o
d
WPAN and 6Lo WGs ad aptation la
6
d
ayer
specific
cations and activity.

19

Figure 3. Pro
otocol stack and exam
k,
mple network topology, for each 6L
k
f
Lo/6LoWPA
AN
te
echnology when using I
w
IPv6. BLE stands for Bluetooth LE
s
B
E.

20

Figu 4. IPv6 datagram encapsulatio and Hea
ure
e
on
ader Compression (HC) overhead over
C)
IEE 802.15.4 and the 6L technolog
EE
4
Lo
gies.

21

Figu 5. Clusters of 6Lo and LPWA technolog in term of their w orst-case MTU
ure
s
AN
gies
ms
M
a capacity
and
y.

22

View publication stats

Medium
Frequency band (MHz)
Range (m)
Bit rate (kbit/s)
Max. single-frame L2
payload (bytes)
ACKs and retries
Technology

MAC mechanism
Address size (bits)
L2 fragmentation
Network topology
Protocol stack
Application
Standardization
organization

Adaptation
Layer

Routing required
Mesh under support
Fragmentation
6LoWPAN
Header
Compression
6LoWPAN
Neighbor Discovery
Multicast
Privacy addresses
L2 security used

6LoWPAN
IEEE
802.15.4
Wireless
868/915/2400
10-100
20/40/250
105

DECT ULE

6Lo
MS/TP

NFC

Wireless
2400
10-100
1000
23

ITU-T
G.9959
Wireless
868/915
100
9.6/40/100
158

Wireless
1900
< 300
1152
38

Wired
Base-band
1000
115.2
2032

Wireless
13.56
< 0.2
106/212/424
125

Optional

Yes

Optional

Yes

No

ACK/NACK

CSMA/CA,
TDMA
16/64
No
Star and mesh

TDMA

CSMA/CA

TDMA

48
Yes
Star

40
Yes
Mesh

20/40/48
Yes
Star

Token
passing
8
No
Multi-drop
bus

PHY/Link
Generic
purpose
IEEE

PHY to App.
Smartphonecentric
Bluetooth SIG

PHY/Link
Home
automation
ITU-T

PHY to App.
Home
automation
ETSI

TDMA link
initialization
6
Yes
Point-topoint
PHY to App.
Contactless
exchange
NFC Forum

Yes
Yes
Yes
Yes

No
No
No
Yes
(star topol.)

No
No
No
Yes
(star topology)

Yes

Yes
(no multihop)
L2 unicast
Random IID
Yes

Yes
Yes
No
Yes
(address
adaptation)
Yes

L2 broadcast
Not specified
Yes

Bluetooth LE

L2 broadcast
DHCPv6
Yes

Yes
(no multihop)
L2 unicast
Random IID
Yes

PHY/Link

Building
automation
ANSI/
ASHRAE

No
No
No
Yes
(address
adaptation)
Partially
L2 broadcast
Random IID
No

No
No
No
Yes
(address
adaptation)
With
DHCPv6
L2 broadcast
Random IID
No

IEEE
1901.2
Wired
< 0.5
> 1000
≤ 500
215
(worst case)
ACK/NACK
(optional)
CSMA/CA
16/64
Yes
Star and
mesh
PHY/Link
Smart grid,
home autom.
IEEE
Yes
No
No
Yes
DHCPv6
only
No
DCHPv6
Yes

IEEE
802.11ah
Wireless
< 1000
< 1000
150-7800
7951
Yes
CSMA/CA
48
Yes
Star
PHY/Link
Sensors,
backhaul
IEEE
No
No
No
Yes
(address
adaptation)
Yes
(no multihop)
L2 multicast
Random IID
Yes

Table 1. Main features of IPv6-supported IoT technologies and their adaptation layers. L2 stands for Layer 2.

23