< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/