idnits 2.17.1 draft-vilajosana-6lpwa-lora-hc-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 18 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 6, 2016) is 2878 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'LoRaSpec' is mentioned on line 480, but not defined == Unused Reference: 'RFC4944' is defined on line 438, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 469, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6lpwa X. Vilajosana, Ed. 3 Internet-Draft Worldsensing 4 Intended status: Standards Track M. Dohler 5 Expires: December 8, 2016 King's College London 6 June 6, 2016 8 Transmission of IPv6 Packets over LoRaWAN 9 draft-vilajosana-6lpwa-lora-hc-01 11 Abstract 13 This document describes how IPv6 is transmitted over LoRaWAN using 14 6LowPAN techniques. LoRaWAN is a wireless communication system for 15 long-range low-power low-data-rate applications. LoRaWAN networks 16 typically are laid out in a star topology in the field with gateways 17 relaying messages between end-devices and a central network server in 18 the backend, the complete system referred to as star of stars 19 network. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 8, 2016. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 57 3. Overview of LoRaWAN Technology . . . . . . . . . . . . . . . 3 58 4. Specification of IPv6 over LoRaWAN . . . . . . . . . . . . . 3 59 4.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . 4 60 4.2. Link Model . . . . . . . . . . . . . . . . . . . . . . . 4 61 4.3. Stateless Address Auto-configuration . . . . . . . . . . 5 62 4.3.1. LoRaWAN Addressing . . . . . . . . . . . . . . . . . 5 63 4.3.2. Address Auto-Configuration . . . . . . . . . . . . . 6 64 4.4. Neighbour Discovery . . . . . . . . . . . . . . . . . . . 7 65 4.5. Header Compression in LoRaWAN . . . . . . . . . . . . . . 9 66 4.6. Fragmentation in LoRaWAN . . . . . . . . . . . . . . . . 9 67 5. Internet Connectivity Scenarios . . . . . . . . . . . . . . . 9 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 73 9.2. External Informative References . . . . . . . . . . . . . 11 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 76 1. Introduction 78 LoRa is a wireless modulation for long-range low-power low-data-rate 79 applications developed by Semtech. The LoRa modulation is used in 80 LoRaWAN networks. LoRaWAN networks typically are organized in a 81 star-of-stars topology in which gateways relay messages between end- 82 devices and a central network server in the backend. Gateways are 83 connected to the network server via IP links while end-devices use 84 single-hop LoRaWAN communication to one or many gateways. All 85 communication is generally bi-directional, although uplink 86 communication from end-devices to the network server are strongly 87 favoured. 89 Communication between end-devices and gateways is spread out among 90 different frequency channels and so-called spreading factors. 91 Selecting a spreading factor is a trade-off between communication 92 range and data rate. Spreading factors create virtual and orthogonal 93 non-interfering communication channels that enable simultaneous 94 transmissions. Depending on the used spreading factor, LoRaWAN data 95 rates range from 0.3 kbps to 50 kbps. To maximize both battery life 96 of end-devices and overall network capacity, the LoRaWAN network 97 infrastructure manages the data rate and RF output for each end- 98 device individually by means of an adaptive data rate (ADR) scheme. 99 End-devices may transmit on any channel available at any time, using 100 any available data rate. 102 The consolidation of that technology and its important impact in the 103 M2M market, is triggering the need for end to end IP connectivity 104 from end devices to the backend server without the need of proxying 105 roles taken at LoRaWAN Managers or Gateways. Due to the constrained 106 nature of LoRaWAN devices, the compression techniques developed by 107 6LowPAN become mandatory. The present document specifies how IPv6 108 and the 6LowPAN architecture run on top of the LoRaWAN MAC layer. 110 2. Requirements Language 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [RFC2119]. 116 3. Overview of LoRaWAN Technology 118 TODO briefly describe the technology. Phy layer and modulation. MAC 119 operation and frame formats. 121 Figure 1: LoRaWAN Class A transmission and reception window. 123 |----------------------------| |--------| |--------| 124 | Tx | | Rx | | Rx | 125 |----------------------------| |--------| |--------| 126 |---------| 127 Rx delay 1 128 |------------------------| 129 Rx delay 2 131 4. Specification of IPv6 over LoRaWAN 133 The LoRaWAN technology enables low power wide area network coverage 134 at the cost of reduced data rate and to obey to strict spectrum 135 occupancy regulations. This imposes strict communication limitations 136 that make applications using LoRaWAN to contain the amount of data 137 that is transmitted. 6LoWPAN standards RFC4944, RFC6775, and RFC6282 138 enable IP connectivity while leverage the overhead of fully IPv6 139 headers. They also provides standard Internet connectivity by 140 enabling IPv6 adressing and stateless IPv6 address auto- 141 configuration, Neighbour Discovery and most importantly Header 142 Compression. The main difference between IEEE 802.15.4 and LoRaWAN 143 is that LoRaWAN builds stars and star of stars networks not requiring 144 a routing protocol nor multi-hop operation. At the same time LoRaWAN 145 is subject to bandwidth, data rate, radio duty-cycle regulations and 146 frame size constraints that impose strict limitation in the protocol 147 overhead that is supported when compared to IEEE 802.15.4. 149 4.1. Protocol stack 151 Figure 2: Protocol Stack for IPv6 over LoRaWAN 153 +----------------------------------------+ ------------------ 154 | | Transport and 155 | Upper Layer Protocols | Application Layer 156 +----------------------------------------+ ------------------ 157 | | | 158 | IPv6 | | 159 | | Network 160 +----------------------------------------+ Layer 161 |Adaptation Layer for IPv6 over LoRaWAN | | 162 +----------------------------------------+ ------------------ 163 | | 164 | IPv6-LOR Addressing Binding | LoRaWAN Link Layer 165 | | | 166 +----------------------------------------+ ------------------ 167 | | | 168 | Activities | LoRaWAN 169 | Digital Protocol | Physical Layer 170 | RF Analog | | 171 | | | 172 +----------------------------------------+ ------------------ 174 Adaptation layer for IPv6 over LoRaWAN SHALL support neighbour discovery, 175 address auto-configuration, header compression, and fragmentation and 176 reassembly. 178 4.2. Link Model 180 According to RFC 4861 [RFC4861] a link is "a communication facility 181 or medium over which nodes can communicate at the link layer, i.e., 182 the layer immediately below IPv6." 184 In LoRaWAN the IPv6 layer is designed to enable transmission of IPv6 185 packets over LoRaWAN links. The LoRaWAN protocol is in charge of 186 establishing the pairwise communication between the LoRaWAN gateway 187 and the LoRaWAN device. The IPv6 adaptation layer however is in 188 charge of managing header compression and packet fragmentation in 189 order to deal with different spreading factors and allowed packet 190 payload at the underlying MAC layer. 192 Per this specification, the IPv6 header compression format specified 193 in RFC 6282 MUST be used [RFC6282] but more drastic compression based 194 on provisioning an extended context in the NS is expected in the 195 upcoming revision. The IPv6 payload length can be derived from the 196 LoRaWAN MAC header length and the possibly elided IPv6 address can be 197 reconstructed from the link-layer address, used at the time of 198 LoRaWAN connection establishment. As described in Section 4.5 199 context information or more aggressive compression formats such as 200 RoHC [RFC3095] SHOULD be used at the 6LBR in order to compress well- 201 known network prefixes and indicated at the specific field of the 202 IPHC header. This compression will be defined in the upcomming 203 revisions. 205 LoRaWAN networks form star topologies or star of stars, having a 206 point-to-point nature. Address assignment is managed by the 6LBR 207 that ensures that collisions do not occur. Broadcast features are 208 used mainly by the 6LBR. 6LN to 6LN communications are always 209 carried out through the 6LBR and hence it is in charge of relaying 210 link local packets. 212 After the LoRaWAN node and the LoRaWAN gateway have established the 213 LoRaWAN connection, the link is enabled and IPv6 address 214 configuration and subsequent transmission are able to start. 216 4.3. Stateless Address Auto-configuration 218 Nodes (both hosts and routers) in a LoRaWAN network MAY use the 219 address auto-configuration process. This process relies in the 220 ability for a node to generate a link-local address for the 221 communication interface. A link-local address is formed by appending 222 an identifier of the interface to the well-known link-local prefix 223 [RFC4291]. Before the link-local address can be assigned to an 224 interface and used, a node must attempt to verify that this 225 "tentative" address is not already in use by another node on the 226 link. This section describes how LoRaWAN nodes determine the address 227 to be used and how this address is bound to the 6LBR node (or LoRaWAN 228 Manager or Gateway). 230 4.3.1. LoRaWAN Addressing 232 LoRaWAN device addressing can be conducted in two ways. Over the air 233 activation (OTAA) and Activation by personalization (ABP). The 234 former requires 2 MAC layer messages to establish the network address 235 and security keys. The latter assumes that device address and 236 security keys are pre-programmed at the nodes. In the case of OTAA 237 the joining negotiation establishes a unique 4 Bytes DevAddr. When 238 ABP is used the DevAddr is pre-configured at the node. 240 The LoRaWAN device address uses 32 bits and identifies the end-device 241 within the current network. The most significant 7 bits are used as 242 network identifier (NetworkID) to separate addresses of territorially 243 overlapping networks or networks managed by different network 244 operators. The least significant 25 bits are referred to as the 245 network address (NetworkAddress) of the end-device and can be 246 arbitrarily assigned by the network manager. 248 Figure 3: End Device Address 250 +------------+----------------+----------------+ 251 | Bit# | [31..25] | [24..0] | 252 +------------+----------------+----------------+ 253 | DevAddr | NetworkID | End Device | 254 | | | NetworkAddress | 255 +------------+----------------+----------------+ 257 4.3.2. Address Auto-Configuration 259 A LoRaWAN end device performs stateless address auto-configuration as 260 per [RFC4862]. A 64-bit Interface identifier (IID) for a LoRaWAN 261 interface MAY be formed by utilizing the 32-bit LoRaWAN DevAddr. 262 That IID MAY guarantee a stable IPv6 address and MUST be used along 263 the lifetime of the network. 265 According to [RFC7136], interface IIDs of all unicast addresses for 266 LoRaWAN-enabled devices MUST be formed on the basis of 64 bits long 267 and constructed using the EUI-64 format. LoRaWAN End Device 268 Addresses MUST follow a stateless address auto-configuration that 269 requires 32 zeros and 32 bit DevAddr. 271 [RFC4291] indicates the use of a "Universal/Local" scope bit that 272 identifies the network device to be locally accessible or globally 273 accessible. The former SHOULD be followed and LoRaWAN end-devices 274 SHOULD set to 0 the "Universal/Local" bit. In the case that a 275 Universally accessible IPv6 address needs to be used a Neighbor 276 Discovery mechanism and a network commissioning procedure is 277 required. This procedure is described in Section 4.4. 279 LoRaWAN IPv6 Network Prefix is build using the link-local prefix 280 FE80::/64. The IPv6 link-local address for a LoRaWAN-enabled device 281 is formed by appending the IID, to the prefix, as depicted in 282 Figure 4. 284 Duplicate address detection for link-local addresses is performed by 285 the 6LBR. 287 Once a 6LN has established its own link-local address, it starts 288 sending Router Solicitation messages as described in [RFC4861] 289 Section 6.3.7. 291 For non-link-local addresses a 64-bit IID MAY be formed by utilizing 292 the 32-bit LoRaWAN DevAddr as described in Section TODO. A 6LN can 293 also use a the EUI-64 generated IID from the MAC Layer. The non- 294 link-local addresses generated by the 6LN MUST be registered with the 295 6LBR. 297 The mechanism by which the 6LBR obtains an IPv6 prefix is out of 298 scope of this document but can for example be accomplished by using 299 Unique Local IPv6 Unicast Addresses (ULA) [RFC4193]. As 6LNs MUST 300 always communicate to the 6LBR, the "on-link" flag (L) MUST be set to 301 zero in the Prefix Information Option [RFC4861]. This will always 302 happen even when the destination is another 6LN using the same 303 prefix. 305 Figure 4: IPv6 link-local address in LoRaWAN 307 0 0 0 0 1 308 0 1 6 9 2 309 0 0 4 6 7 310 +----------+-----------------+---------------+----------------+ 311 |1111111010| zeros | zeros | DevAddr | 312 +----------+-----------------+---------------+----------------+ 313 | | 314 | /-------------------------- 128 bits ----------------------/| 315 | | 317 4.4. Neighbour Discovery 319 Neighbour Discovery is addressed following the classical ND approach 320 as defined by [RFC4861] , [RFC4862] and [RFC6775]. As LoRaWAN 321 networks can be organized in star topologies or star of stars 322 topologies the LoRaWAN manager can take two differentiated roles. 323 For single star topologies the LoRaWAN manager will act as a 6LBR and 324 MUST keep track of the nodes addresses within the link, otherwise it 325 acts as 6LR and forwards Node Solicitation and ARO requests to the 326 6LBR in the network. 328 Figure 5: ND Procedure for a single star topology 330 LoRaWAN node LoRaWAN 6LR/6LBR 331 | Router Solicitation (RS) | 332 |-------------------------------->| 333 | | 334 | Router Advertisement (RA) | 335 |<--------------------------------| 336 | | 337 | Neighbour Solicitation (NS) | 338 |-------------------------------->| 339 | | 340 | Neighbour Advertisement (NA) | 341 |<--------------------------------| 342 | | 344 When a LoRaWAN node joins a network, it sends an RS to the 6LR 345 containing its IID as described in Section 4.3.2. The 6LBR router 346 answers with a RA containing its IIDs and prefixes. Hosts receive 347 Router Advertisement messages containing the Authoritative Border 348 Router Option (ABRO), the IIDs of the 6LR or 6LBR and MAY optionally 349 contain one or more 6LoWPAN Context Options (6COs). They also 350 contain the existing Prefix Information Options (PIOs) as described 351 in [RFC4861]. 353 When a host has configured a non-link-local IPv6 address, it 354 registers that address with one or more of its default routers using 355 the Address Registration Option (ARO) in an NS message. The host 356 chooses a lifetime of the registration and repeats the ARO 357 periodically (before the lifetime runs out) to maintain the 358 registration. The host needs to refresh its prefix and context 359 information by sending a new unicast NS. As LoRaWAN might use very 360 low data rates it is recommended to use large Lifetime configurations 361 assuming that LoRaWAN devices are not mobile. According to [RFC6775] 362 the maximum Router Lifetime is about 18 hours, whereas the maximum 363 Registration Lifetime is about 45.5 days. 365 The ND Procedure for star of stars follows the multi-hop ND approach 366 described by [RFC6775]. The multihop distribution relies on RS 367 messages and RA messages sent between routers, and using the ABRO 368 version number to control the propagation of the information 369 (prefixes and context information) that is being sent in the RAs. 371 Figure 6: ND Procedure for star of stars in LoRaWAN. 373 LoRaWAN node LoRaWAN 6LR LoRaWAN 6LBR 374 | Router Solicitation (RS) | | 375 |------------------------------->| | 376 | | | 377 | Router Advertisement (RA) | | 378 |<-------------------------------| | 379 | | | 380 | Node Registration (NR) | | 381 |------------------------------->| | 382 | | Neighbour Solicitation (NS) | 383 | |--------------------------------->| 384 | | | 385 | | Neighbour Advertisement (NA) | 386 | |<---------------------------------| 387 | Node Confirmation (NC) | | 388 |<-------------------------------| | 389 | | | 391 4.5. Header Compression in LoRaWAN 393 TODO. 395 4.6. Fragmentation in LoRaWAN 397 TODO. 399 5. Internet Connectivity Scenarios 401 TODO. 403 6. Security Considerations 405 The transmission of IPv6 over LoRaWAN links has similar requirements 406 and concerns for security as for IEEE 802.15.4. LoRaWAN Link Layer 407 security considerations are covered by the LoRaWAN Specification 408 [LoRaSpec]. 410 7. IANA Considerations 412 There are no IANA considerations related to this document. 414 8. Acknowledgements 416 The authors would like to acknowledge the guidance and input provided 417 by Pascal Thubert. 419 9. References 421 9.1. Normative References 423 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 424 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 425 February 2014, . 427 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 428 Bormann, "Neighbor Discovery Optimization for IPv6 over 429 Low-Power Wireless Personal Area Networks (6LoWPANs)", 430 RFC 6775, DOI 10.17487/RFC6775, November 2012, 431 . 433 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 434 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 435 DOI 10.17487/RFC6282, September 2011, 436 . 438 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 439 "Transmission of IPv6 Packets over IEEE 802.15.4 440 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 441 . 443 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 444 Address Autoconfiguration", RFC 4862, 445 DOI 10.17487/RFC4862, September 2007, 446 . 448 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 449 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 450 DOI 10.17487/RFC4861, September 2007, 451 . 453 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 454 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 455 2006, . 457 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 458 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 459 . 461 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 462 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 463 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 464 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 465 Compression (ROHC): Framework and four profiles: RTP, UDP, 466 ESP, and uncompressed", RFC 3095, DOI 10.17487/RFC3095, 467 July 2001, . 469 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 470 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 471 December 1998, . 473 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 474 Requirement Levels", BCP 14, RFC 2119, 475 DOI 10.17487/RFC2119, March 1997, 476 . 478 9.2. External Informative References 480 [LoRaSpec] 481 LoRa Alliance, "LoRaWAN Specification Rev.3", April 2014. 483 Authors' Addresses 485 Xavier Vilajosana (editor) 486 Worldsensing 487 483 Arago 4th floor 488 Barcelona, Catalonia 08013 489 Spain 491 Email: xvilajosana@worldsensing.com 493 Mischa Dohler 494 King's College London 495 London, London 496 UK 498 Email: mischa.dohler@kcl.ac.uk