draft-ietf-lpwan-overview-04.txt   draft-ietf-lpwan-overview-05.txt 
lpwan S. Farrell, Ed. lpwan S. Farrell, Ed.
Internet-Draft Trinity College Dublin Internet-Draft Trinity College Dublin
Intended status: Informational June 13, 2017 Intended status: Informational July 1, 2017
Expires: December 15, 2017 Expires: January 2, 2018
LPWAN Overview LPWAN Overview
draft-ietf-lpwan-overview-04 draft-ietf-lpwan-overview-05
Abstract Abstract
Low Power Wide Area Networks (LPWAN) are wireless technologies with Low Power Wide Area Networks (LPWAN) are wireless technologies with
characteristics such as large coverage areas, low bandwidth, possibly characteristics such as large coverage areas, low bandwidth, possibly
very small packet and application layer data sizes and long battery very small packet and application layer data sizes and long battery
life operation. This memo is an informational overview of the set of life operation. This memo is an informational overview of the set of
LPWAN technologies being considered in the IETF and of the gaps that LPWAN technologies being considered in the IETF and of the gaps that
exist between the needs of those technologies and the goal of running exist between the needs of those technologies and the goal of running
IP in LPWANs. IP in LPWANs.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 15, 2017. This Internet-Draft will expire on January 2, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 14 skipping to change at page 2, line 14
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. LPWAN Technologies . . . . . . . . . . . . . . . . . . . . . 3 2. LPWAN Technologies . . . . . . . . . . . . . . . . . . . . . 3
2.1. LoRaWAN . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. LoRaWAN . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Provenance and Documents . . . . . . . . . . . . . . 4 2.1.1. Provenance and Documents . . . . . . . . . . . . . . 4
2.1.2. Characteristics . . . . . . . . . . . . . . . . . . . 4 2.1.2. Characteristics . . . . . . . . . . . . . . . . . . . 4
2.2. Narrowband IoT (NB-IoT) . . . . . . . . . . . . . . . . . 11 2.2. Narrowband IoT (NB-IoT) . . . . . . . . . . . . . . . . . 10
2.2.1. Provenance and Documents . . . . . . . . . . . . . . 11 2.2.1. Provenance and Documents . . . . . . . . . . . . . . 10
2.2.2. Characteristics . . . . . . . . . . . . . . . . . . . 11 2.2.2. Characteristics . . . . . . . . . . . . . . . . . . . 11
2.3. SIGFOX . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.3. SIGFOX . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.1. Provenance and Documents . . . . . . . . . . . . . . 16 2.3.1. Provenance and Documents . . . . . . . . . . . . . . 15
2.3.2. Characteristics . . . . . . . . . . . . . . . . . . . 16 2.3.2. Characteristics . . . . . . . . . . . . . . . . . . . 15
2.4. Wi-SUN Alliance Field Area Network (FAN) . . . . . . . . 20 2.4. Wi-SUN Alliance Field Area Network (FAN) . . . . . . . . 20
2.4.1. Provenance and Documents . . . . . . . . . . . . . . 20 2.4.1. Provenance and Documents . . . . . . . . . . . . . . 20
2.4.2. Characteristics . . . . . . . . . . . . . . . . . . . 21 2.4.2. Characteristics . . . . . . . . . . . . . . . . . . . 21
3. Generic Terminology . . . . . . . . . . . . . . . . . . . . . 24 3. Generic Terminology . . . . . . . . . . . . . . . . . . . . . 24
4. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 25 4. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1. Naive application of IPv6 . . . . . . . . . . . . . . . . 25 4.1. Naive application of IPv6 . . . . . . . . . . . . . . . . 25
4.2. 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.2. 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2.1. Header Compression . . . . . . . . . . . . . . . . . 26 4.2.1. Header Compression . . . . . . . . . . . . . . . . . 27
4.2.2. Address Autoconfiguration . . . . . . . . . . . . . . 27 4.2.2. Address Autoconfiguration . . . . . . . . . . . . . . 27
4.2.3. Fragmentation . . . . . . . . . . . . . . . . . . . . 27 4.2.3. Fragmentation . . . . . . . . . . . . . . . . . . . . 27
4.2.4. Neighbor Discovery . . . . . . . . . . . . . . . . . 28 4.2.4. Neighbor Discovery . . . . . . . . . . . . . . . . . 28
4.3. 6lo . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.3. 6lo . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.4. 6tisch . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.4. 6tisch . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.5. RoHC . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.5. RoHC . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.6. ROLL . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.6. ROLL . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.7. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.7. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.8. Mobility . . . . . . . . . . . . . . . . . . . . . . . . 30 4.8. Mobility . . . . . . . . . . . . . . . . . . . . . . . . 30
4.9. DNS and LPWAN . . . . . . . . . . . . . . . . . . . . . . 30 4.9. DNS and LPWAN . . . . . . . . . . . . . . . . . . . . . . 30
5. Security Considerations . . . . . . . . . . . . . . . . . . . 31 5. Security Considerations . . . . . . . . . . . . . . . . . . . 31
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
9. Informative References . . . . . . . . . . . . . . . . . . . 35 9. Informative References . . . . . . . . . . . . . . . . . . . 35
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 40 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 40
A.1. From -00 to -01 . . . . . . . . . . . . . . . . . . . . . 40 A.1. From -00 to -01 . . . . . . . . . . . . . . . . . . . . . 40
A.2. From -01 to -02 . . . . . . . . . . . . . . . . . . . . . 40 A.2. From -01 to -02 . . . . . . . . . . . . . . . . . . . . . 40
A.3. From -02 to -03 . . . . . . . . . . . . . . . . . . . . . 40 A.3. From -02 to -03 . . . . . . . . . . . . . . . . . . . . . 40
A.4. From -03 to -04 . . . . . . . . . . . . . . . . . . . . . 41 A.4. From -03 to -04 . . . . . . . . . . . . . . . . . . . . . 41
A.5. From -03 to -04 . . . . . . . . . . . . . . . . . . . . . 41
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 41 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
This document provides background material and an overview of the This document provides background material and an overview of the
technologies being considered in the IETF's Low Power Wide-Area technologies being considered in the IETF's Low Power Wide-Area
Networking (LPWAN) working group. We also provide a gap analysis Networking (LPWAN) working group. We also provide a gap analysis
between the needs of these technologies and currently available IETF between the needs of these technologies and currently available IETF
specifications. specifications.
skipping to change at page 8, line 13 skipping to change at page 8, line 13
gateways received the corresponding link request MAC command. gateways received the corresponding link request MAC command.
Some MAC commands are initiated by the network server. For example, Some MAC commands are initiated by the network server. For example,
one command allows the network server to ask an end-device to reduce one command allows the network server to ask an end-device to reduce
its duty-cycle to only use a proportion of the maximum allowed in a its duty-cycle to only use a proportion of the maximum allowed in a
region. Another allows the network server to query the end-device's region. Another allows the network server to query the end-device's
power status with the response from the end-device specifying whether power status with the response from the end-device specifying whether
it has an external power source or is battery powered (in which case it has an external power source or is battery powered (in which case
a relative battery level is also sent to the network server). a relative battery level is also sent to the network server).
A LoRaWAN network has a network identifier ("NwkID"), currently a
seven-bit value. A private network (common for LoRaWAN) can use the
value zero or one. If a network wishes to support "foreign" end-
devices then the NwkID needs to be registered with the LoRA Alliance,
in which case the NwkID is the seven least significant bits of a
registered 24-bit NetID. (Note however, that the methods for
"roaming" are defined in the upcoming LoRaWAN 1.1 specification.)
In order to operate nominally on a LoRaWAN network, a device needs a In order to operate nominally on a LoRaWAN network, a device needs a
32-bit device address, which is the catenation of the NwkID and a 32-bit device address, that is assigned when the device "joins" the
25-bit device-specific network address that is assigned when the network (see below for the join procedure) or that is pre-provisioned
device "joins" the network (see below for the join procedure) or that into the device. In case of roaming devices, the device address is
is pre-provisioned into the device. assigned based on the 24-bit network identifier (NetID) that is
allocated to the network by the LoRa Alliance. Non-roaming devices
can be assigned device addresses by the network without relying on a
LoRa Alliance-assigned NetID.
End-devices are assumed to work with one or a quite limited number of End-devices are assumed to work with one or a quite limited number of
applications, identified by a 64-bit AppEUI, which is assumed to be a applications, identified by a 64-bit AppEUI, which is assumed to be a
registered IEEE EUI64 value. In addition, a device needs to have two registered IEEE EUI64 value. In addition, a device needs to have two
symmetric session keys, one for protecting network artifacts symmetric session keys, one for protecting network artifacts
(port=0), the NwkSKey, and another for protecting application layer (port=0), the NwkSKey, and another for protecting application layer
traffic, the AppSKey. Both keys are used for 128-bit AES traffic, the AppSKey. Both keys are used for 128-bit AES
cryptographic operations. So, one option is for an end-device to cryptographic operations. So, one option is for an end-device to
have all of the above, plus channel information, somehow have all of the above, plus channel information, somehow
(pre-)provisioned, in which case the end-device can simply start (pre-)provisioned, in which case the end-device can simply start
skipping to change at page 9, line 13 skipping to change at page 8, line 43
values. values.
+---------+---------------------------------------------------------+ +---------+---------------------------------------------------------+
| Value | Description | | Value | Description |
+---------+---------------------------------------------------------+ +---------+---------------------------------------------------------+
| DevAddr | DevAddr (32-bits) = device-specific network address | | DevAddr | DevAddr (32-bits) = device-specific network address |
| | generated from the NwkID | | | generated from the NwkID |
| | | | | |
| AppEUI | IEEE EUI64 naming the application | | AppEUI | IEEE EUI64 naming the application |
| | | | | |
| NwkSKey | 128-bit network session key for use with AES | | NwkSKey | 128-bit network session key used with AES-CMAC |
| | | | | |
| AppSKey | 128-bit application session key for use with AES | | AppSKey | 128-bit application session key used with AES-CTR |
| | |
| AppKey | 128-bit application session key used with AES-ECB |
+---------+---------------------------------------------------------+ +---------+---------------------------------------------------------+
Table 3: Values required for nominal operation Table 3: Values required for nominal operation
As an alternative, end-devices can use the LoRaWAN join procedure in As an alternative, end-devices can use the LoRaWAN join procedure in
order to setup some of these values and dynamically gain access to order to setup some of these values and dynamically gain access to
the network. To use the join procedure, an end-device must still the network. To use the join procedure, an end-device must still
know the AppEUI, and in addition, a different (long-term) symmetric know the AppEUI, and in addition, a different (long-term) symmetric
key that is bound to the AppEUI - this is the application key key that is bound to the AppEUI - this is the application key
(AppKey), and is distinct from the application session key (AppSKey). (AppKey), and is distinct from the application session key (AppSKey).
skipping to change at page 10, line 13 skipping to change at page 9, line 46
channel information and from which the AppSKey and NwkSKey can be channel information and from which the AppSKey and NwkSKey can be
derived based on knowledge of the AppKey. This provides the end- derived based on knowledge of the AppKey. This provides the end-
device with all the values listed in Table 3. device with all the values listed in Table 3.
All payloads are encrypted and have data integrity. MAC commands, All payloads are encrypted and have data integrity. MAC commands,
when sent as a payload (port zero), are therefore protected. MAC when sent as a payload (port zero), are therefore protected. MAC
commands piggy-backed as frame options ("FOpts") are however sent in commands piggy-backed as frame options ("FOpts") are however sent in
clear. Any MAC commands sent as frame options and not only as clear. Any MAC commands sent as frame options and not only as
payload, are visible to a passive attacker but are not malleable for payload, are visible to a passive attacker but are not malleable for
an active attacker due to the use of the Message Integrity Check an active attacker due to the use of the Message Integrity Check
(MIC) described below.. (MIC) described below.
For LoRaWAN version 1.0.x, the NWkSkey session key is used to provide For LoRaWAN version 1.0.x, the NWkSkey session key is used to provide
data integrity between the end-device and the network server. The data integrity between the end-device and the network server. The
AppSKey is used to provide data confidentiality between the end- AppSKey is used to provide data confidentiality between the end-
device and network server, or to the application "behind" the network device and network server, or to the application "behind" the network
server, depending on the implementation of the network. server, depending on the implementation of the network.
All MAC layer messages have an outer 32-bit MIC calculated using AES- All MAC layer messages have an outer 32-bit MIC calculated using AES-
CMAC calculated over the ciphertext payload and other headers and CMAC calculated over the ciphertext payload and other headers and
using the NwkSkey. Payloads are encrypted using AES-128, with a using the NwkSkey. Payloads are encrypted using AES-128, with a
skipping to change at page 10, line 43 skipping to change at page 10, line 27
operation, but rather an AES-decrypt operation. The justification is operation, but rather an AES-decrypt operation. The justification is
that this means that the end-device only needs to implement the AES- that this means that the end-device only needs to implement the AES-
encrypt operation. (The counter mode variant used for payload encrypt operation. (The counter mode variant used for payload
decryption means the end-device doesn't need an AES-decrypt decryption means the end-device doesn't need an AES-decrypt
primitive.) primitive.)
The Join-accept plaintext is always less than 16 bytes long, so The Join-accept plaintext is always less than 16 bytes long, so
electronic code book (ECB) mode is used for protecting Join-accept electronic code book (ECB) mode is used for protecting Join-accept
messages. The Join-accept contains an AppNonce (a 24 bit value) that messages. The Join-accept contains an AppNonce (a 24 bit value) that
is recovered on the end-device along with the other Join-accept is recovered on the end-device along with the other Join-accept
content (e.g. DevAddr) using the AEs-encrypt operation. Once the content (e.g. DevAddr) using the AES-encrypt operation. Once the
Join-accept payload is available to the end-device the session keys Join-accept payload is available to the end-device the session keys
are derived from the AppKey, AppNonce and other values, again using are derived from the AppKey, AppNonce and other values, again using
an ECB mode AES-encrypt operation, with the plaintext input being a an ECB mode AES-encrypt operation, with the plaintext input being a
maximum of 16 octets. maximum of 16 octets.
2.2. Narrowband IoT (NB-IoT) 2.2. Narrowband IoT (NB-IoT)
Text here is largely from [I-D.ratilainen-lpwan-nb-iot] Text here is largely from [I-D.ratilainen-lpwan-nb-iot]
2.2.1. Provenance and Documents 2.2.1. Provenance and Documents
skipping to change at page 20, line 28 skipping to change at page 20, line 18
Due to constraints in the complexity of the Device, it is assumed Due to constraints in the complexity of the Device, it is assumed
that Devices host only one or very few device applications, which that Devices host only one or very few device applications, which
most of the time communicate each to a single network application at most of the time communicate each to a single network application at
a time. a time.
The radio protocol provides mechanisms to authenticate and ensure The radio protocol provides mechanisms to authenticate and ensure
integrity of the message. This is achieved by using a unique device integrity of the message. This is achieved by using a unique device
ID and a message authentication code, which allow ensuring that the ID and a message authentication code, which allow ensuring that the
message has been generated and sent by the device with the ID claimed message has been generated and sent by the device with the ID claimed
in the message. in the message. At the time of writing the algorithms and keying
details for this are not published.
Security keys are independent for each device. These keys are Security keys are independent for each device. These keys are
associated with the device ID and they are pre-provisioned. associated with the device ID and they are pre-provisioned.
Application data can be encrypted at the application level or not, Application data can be encrypted at the application level or not,
depending on the criticality of the use case, allowing hence to depending on the criticality of the use case, allowing hence to
balance cost and effort vs. risk. balance cost and effort vs. risk. The sigfox network itself provides
no support for application layer confidentiality mechanisms.
2.4. Wi-SUN Alliance Field Area Network (FAN) 2.4. Wi-SUN Alliance Field Area Network (FAN)
Text here is via personal communication from Bob Heile Text here is via personal communication from Bob Heile
(bheile@ieee.org) and was authored by Bob and Sum Chin Sean. Duffy (bheile@ieee.org) and was authored by Bob and Sum Chin Sean. Duffy
(paduffy@cisco.com) also provided additional comments/input on this (paduffy@cisco.com) also provided additional comments/input on this
section. section.
2.4.1. Provenance and Documents 2.4.1. Provenance and Documents
skipping to change at page 23, line 5 skipping to change at page 23, line 5
IEEE802.15.12 is completed IEEE802.15.12 is completed
The PHY service is derived from a sub-set of the SUN FSK The PHY service is derived from a sub-set of the SUN FSK
specification in IEEE802.15.4-2015. The 2-FSK modulation schemes, specification in IEEE802.15.4-2015. The 2-FSK modulation schemes,
with channel spacing range from 200 to 600 kHz, are defined to with channel spacing range from 200 to 600 kHz, are defined to
provide data rates from 50 to 300 kbps, with Forward Error Coding provide data rates from 50 to 300 kbps, with Forward Error Coding
(FEC) as an optional feature. Towards enabling ultra-low-power (FEC) as an optional feature. Towards enabling ultra-low-power
applications, the PHY layer design is also extendable to low energy applications, the PHY layer design is also extendable to low energy
and critical infrastructure monitoring networks. and critical infrastructure monitoring networks.
+------------------------------+------------------------------------+ +----------------------+--------------------------------------------+
| Layer | Description | | Layer | Description |
+------------------------------+------------------------------------+ +----------------------+--------------------------------------------+
| IPv6 protocol suite | TCP/UDP | | IPv6 protocol suite | TCP/UDP |
| | | | | |
| | 6LoWPAN Adaptation + Header | | | 6LoWPAN Adaptation + Header Compression |
| | Compression | | | |
| | | | | DHCPv6 for IP address management. |
| | DHCPv6 for IP address management. | | | |
| | | | | Routing using RPL. |
| | Routing using RPL. | | | |
| | | | | ICMPv6. |
| | ICMPv6. | | | |
| | | | | Unicast and Multicast forwarding. |
| | Unicast and Multicast forwarding. | | | |
| | | | MAC based on IEEE | Frequency hopping |
| MAC based on IEEE 802.15.4e | Frequency hopping | | 802.15.4e + IE | |
| + IE extensions | | | extensions | |
| | | | | |
| | Discovery and Join | | | Discovery and Join |
| | | | | |
| | Protocol Dispatch (IEEE 802.15.9) | | | Protocol Dispatch (IEEE 802.15.9) |
| | | | | |
| | Several Frame Exchange patterns | | | Several Frame Exchange patterns |
| | | | | |
| | Optional Mesh Under routing (ANSI | | | Optional Mesh Under routing (ANSI |
| | 4957.210). | | | 4957.210). |
| | | | | |
| PHY based on 802.15.4g | Various data rates and regions | | PHY based on | Various data rates and regions |
| | | | 802.15.4g | |
| Security | 802.1X/EAP-TLS/PKI | | | |
| | Authentication. | | Security | 802.1X/EAP-TLS/PKI Authentication. |
| | | | | TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 |
| | 802.11i Group Key Management | | | required for EAP-TLS. |
| | | | | |
| | Optional ETSI-TS-102-887-2 Node 2 | | | 802.11i Group Key Management |
| | Node Key Management | | | |
+------------------------------+------------------------------------+ | | Frame security is implemented as AES-CCM* |
| | as specified in IEEE 802.15.4 |
| | |
| | Optional ETSI-TS-102-887-2 Node 2 Node Key |
| | Management |
+----------------------+--------------------------------------------+
Table 5: Wi-SUN Stack Overview Table 5: Wi-SUN Stack Overview
The FAN security supports Data Link layer network access control, The FAN security supports Data Link layer network access control,
mutual authentication, and establishment of a secure pairwise link mutual authentication, and establishment of a secure pairwise link
between a FAN node and its Border Router, which is implemented with between a FAN node and its Border Router, which is implemented with
an adaptation of IEEE802.1X and EAP-TLS as described in [RFC5216] an adaptation of IEEE802.1X and EAP-TLS as described in [RFC5216]
using secure device identity as described in IEEE802.1AR. using secure device identity as described in IEEE802.1AR.
Certificate formats are based upon [RFC5280]. A secure group link Certificate formats are based upon [RFC5280]. A secure group link
between a Border Router and a set of FAN nodes is established using between a Border Router and a set of FAN nodes is established using
skipping to change at page 26, line 24 skipping to change at page 26, line 24
that case, if the network topology is a star, the solution and that case, if the network topology is a star, the solution and
considerations of section 3.2.5 of [RFC7668] may be applied. considerations of section 3.2.5 of [RFC7668] may be applied.
Other key protocols such as DHCPv6 [RFC3315], IPsec [RFC4301] and TLS Other key protocols such as DHCPv6 [RFC3315], IPsec [RFC4301] and TLS
[RFC5246] have similarly problematic properties in this context. [RFC5246] have similarly problematic properties in this context.
Each of those require relatively frequent round-trips between the Each of those require relatively frequent round-trips between the
host and some other host on the network. In the case of host and some other host on the network. In the case of
cryptographic protocols such as IPsec and TLS, in addition to the cryptographic protocols such as IPsec and TLS, in addition to the
round-trips required for secure session establishment, cryptographic round-trips required for secure session establishment, cryptographic
operations can require padding and addition of authenticators that operations can require padding and addition of authenticators that
are problematic when considering LPWAN lower layers. are problematic when considering LPWAN lower layers. Note that mains
powered Wi-SUN mesh router nodes will typically be more resource
capable than the other LPWAN techs discussed. This can enable use of
more "chatty" protocols for some aspects of Wi-SUN.
4.2. 6LoWPAN 4.2. 6LoWPAN
Several technologies that exhibit significant constraints in various Several technologies that exhibit significant constraints in various
dimensions have exploited the 6LoWPAN suite of specifications dimensions have exploited the 6LoWPAN suite of specifications
[RFC4944], [RFC6282], [RFC6775] to support IPv6 [I-D.hong-6lo-use- [RFC4944], [RFC6282], [RFC6775] to support IPv6 [I-D.hong-6lo-use-
cases]. However, the constraints of LPWANs, often more extreme than cases]. However, the constraints of LPWANs, often more extreme than
those typical of technologies that have (re)used 6LoWPAN, constitute those typical of technologies that have (re)used 6LoWPAN, constitute
a challenge for the 6LoWPAN suite in order to enable IPv6 over LPWAN. a challenge for the 6LoWPAN suite in order to enable IPv6 over LPWAN.
LPWANs are characterized by device constraints (in terms of LPWANs are characterized by device constraints (in terms of
skipping to change at page 34, line 38 skipping to change at page 34, line 42
Email: JuanCarlos.Zuniga@sigfox.com Email: JuanCarlos.Zuniga@sigfox.com
URI: http://www.sigfox.com/ URI: http://www.sigfox.com/
8. Acknowledgments 8. Acknowledgments
Thanks to all those listed in Section 7 for the excellent text. Thanks to all those listed in Section 7 for the excellent text.
Errors in the handling of that are solely the editor's fault. Errors in the handling of that are solely the editor's fault.
In addition to the contributors above, thanks are due to Arun In addition to the contributors above, thanks are due to Arun
(arun@acklio.com), Dan Garcia Carrillo, Paul Duffy, Thad Guidry, (arun@acklio.com), Dan Garcia Carrillo, Paul Duffy, Russ Housley,
Jiazi Yi, for comments. Thad Guidry, Jiazi Yi, for comments.
[[Ed: If I omitted anyone, sorry and just let me know and I'll add
you here.]]
Alexander Pelov and Pascal Thubert were the LPWAN WG chairs while Alexander Pelov and Pascal Thubert were the LPWAN WG chairs while
this document was developed. this document was developed.
Stephen Farrell's work on this memo was supported by the Science Stephen Farrell's work on this memo was supported by the Science
Foundation Ireland funded CONNECT centre <https://connectcentre.ie/>. Foundation Ireland funded CONNECT centre <https://connectcentre.ie/>.
9. Informative References 9. Informative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
skipping to change at page 37, line 28 skipping to change at page 37, line 28
2016. 2016.
[I-D.minaburo-lpwan-gap-analysis] [I-D.minaburo-lpwan-gap-analysis]
Minaburo, A., Gomez, C., Toutain, L., Paradells, J., and Minaburo, A., Gomez, C., Toutain, L., Paradells, J., and
J. Crowcroft, "LPWAN Survey and GAP Analysis", draft- J. Crowcroft, "LPWAN Survey and GAP Analysis", draft-
minaburo-lpwan-gap-analysis-02 (work in progress), October minaburo-lpwan-gap-analysis-02 (work in progress), October
2016. 2016.
[I-D.zuniga-lpwan-sigfox-system-description] [I-D.zuniga-lpwan-sigfox-system-description]
Zuniga, J. and B. PONSARD, "SIGFOX System Description", Zuniga, J. and B. PONSARD, "SIGFOX System Description",
draft-zuniga-lpwan-sigfox-system-description-02 (work in draft-zuniga-lpwan-sigfox-system-description-03 (work in
progress), March 2017. progress), June 2017.
[I-D.ratilainen-lpwan-nb-iot] [I-D.ratilainen-lpwan-nb-iot]
Ratilainen, A., "NB-IoT characteristics", draft- Ratilainen, A., "NB-IoT characteristics", draft-
ratilainen-lpwan-nb-iot-00 (work in progress), July 2016. ratilainen-lpwan-nb-iot-00 (work in progress), July 2016.
[I-D.garcia-dime-diameter-lorawan] [I-D.garcia-dime-diameter-lorawan]
Garcia, D., Lopez, R., Kandasamy, A., and A. Pelov, Garcia, D., Lopez, R., Kandasamy, A., and A. Pelov,
"LoRaWAN Authentication in Diameter", draft-garcia-dime- "LoRaWAN Authentication in Diameter", draft-garcia-dime-
diameter-lorawan-00 (work in progress), May 2016. diameter-lorawan-00 (work in progress), May 2016.
skipping to change at page 41, line 13 skipping to change at page 41, line 13
o Editor did an editing pass on the lot. o Editor did an editing pass on the lot.
A.4. From -03 to -04 A.4. From -03 to -04
o Picked up a PR that had been wrongly applied that expands UE o Picked up a PR that had been wrongly applied that expands UE
o Editorial changes wrt LoRa suggested by Alper o Editorial changes wrt LoRa suggested by Alper
o Editorial changes wrt SIGFOX provided by Juan-Carlos o Editorial changes wrt SIGFOX provided by Juan-Carlos
A.5. From -03 to -04
o Handled Russ Housley's WGLC review.
o Handled Alper Yegin's WGLC review.
Author's Address Author's Address
Stephen Farrell (editor) Stephen Farrell (editor)
Trinity College Dublin Trinity College Dublin
Dublin 2 Dublin 2
Ireland Ireland
Phone: +353-1-896-2354 Phone: +353-1-896-2354
Email: stephen.farrell@cs.tcd.ie Email: stephen.farrell@cs.tcd.ie
 End of changes. 22 change blocks. 
75 lines changed or deleted 86 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/