idnits 2.17.1 draft-vilajosana-lpwan-lora-hc-00.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 (July 8, 2016) is 2846 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 479, but not defined == Unused Reference: 'RFC4944' is defined on line 437, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 468, 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: January 9, 2017 King's College London 6 A. Yegin 7 Actility 8 July 8, 2016 10 Transmission of IPv6 Packets over LoRaWAN 11 draft-vilajosana-lpwan-lora-hc-00 13 Abstract 15 This document describes how IPv6 is transmitted over LoRaWAN using 16 6LowPAN techniques. LoRaWAN is a wireless communication system for 17 long-range low-power low-data-rate applications. LoRaWAN networks 18 typically are laid out in a star topology in the field with gateways 19 relaying messages between end-devices and a central network server in 20 the backend, the complete system referred to as star of stars 21 network. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 9, 2017. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 59 3. Overview of LoRaWAN Technology . . . . . . . . . . . . . . . 3 60 4. Specification of IPv6 over LoRaWAN . . . . . . . . . . . . . 3 61 4.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . 4 62 4.2. Link Model . . . . . . . . . . . . . . . . . . . . . . . 4 63 4.3. Stateless Address Auto-configuration . . . . . . . . . . 5 64 4.3.1. LoRaWAN Addressing . . . . . . . . . . . . . . . . . 5 65 4.3.2. Address Auto-Configuration . . . . . . . . . . . . . 6 66 4.4. Neighbour Discovery . . . . . . . . . . . . . . . . . . . 7 67 4.5. Header Compression in LoRaWAN . . . . . . . . . . . . . . 9 68 4.6. Fragmentation in LoRaWAN . . . . . . . . . . . . . . . . 9 69 5. Internet Connectivity Scenarios . . . . . . . . . . . . . . . 9 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 75 9.2. External Informative References . . . . . . . . . . . . . 11 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 78 1. Introduction 80 LoRa is a wireless technology for long-range low-power low-data-rate 81 applications developed by Semtech, which is used in LoRaWAN networks. 82 LoRaWAN networks typically are organized in a star-of-stars topology 83 in which gateways relay messages between end-devices and a central 84 network server in the backend. Gateways are connected to the network 85 server via IP links while end-devices use single-hop LoRaWAN 86 communication to one or many gateways. All communication is 87 generally bi-directional, although uplink communication from end- 88 devices to the network server are strongly favoured. 90 Communication between end-devices and gateways is spread out among 91 different frequency channels and so-called spreading factors. 92 Selecting a spreading factor is a trade-off between required link 93 budget and data rate. Spreading factors create virtual and 94 orthogonal non-interfering communication channels that enable 95 simultaneous transmissions. Depending on the used spreading factor, 96 LoRaWAN data rates range from 0.3 kbps to 50 kbps. To maximize both 97 battery life of end-devices and overall network capacity, the LoRaWAN 98 network infrastructure manages the data rate and RF output for each 99 end-device individually by means of an adaptive data rate (ADR) 100 scheme. End-devices may transmit on any channel available at any 101 time, using any available data rate. 103 The consolidation of that technology and its important impact in the 104 M2M market, is triggering the need for end to end IP connectivity 105 from end devices to the backend server without the need of proxying 106 roles taken at Gateways. Due to the constrained nature of LoRaWAN 107 devices, the compression techniques developed by 6LowPAN become 108 mandatory. The present document specifies how IPv6 and the 6LowPAN 109 architecture run on top of the LoRaWAN MAC layer. 111 2. Requirements Language 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119 [RFC2119]. 117 3. Overview of LoRaWAN Technology 119 TODO briefly describe the technology. Phy layer and modulation. MAC 120 operation and frame formats. 122 Figure 1: LoRaWAN Class A transmission and reception window. 124 |----------------------------| |--------| |--------| 125 | Tx | | Rx | | Rx | 126 |----------------------------| |--------| |--------| 127 |---------| 128 Rx delay 1 129 |------------------------| 130 Rx delay 2 132 4. Specification of IPv6 over LoRaWAN 134 The LoRaWAN technology enables low power wide area network coverage 135 at the cost of reduced data rate and to obey to strict spectrum 136 occupancy regulations. This imposes strict communication limitations 137 that make applications using LoRaWAN to contain the amount of data 138 that is transmitted. 6LoWPAN standards RFC4944, RFC6775, and RFC6282 139 enable IP connectivity while leverage the overhead of fully IPv6 140 headers. They also provides standard Internet connectivity by 141 enabling IPv6 addressing and stateless IPv6 address auto- 142 configuration, Neighbour Discovery and most importantly Header 143 Compression. The main difference between IEEE 802.15.4 and LoRaWAN 144 is that LoRaWAN builds stars and star of stars networks not requiring 145 a routing protocol nor multi-hop operation. At the same time LoRaWAN 146 is subject to bandwidth, data rate, radio duty-cycle regulations and 147 frame size constraints that impose strict limitation in the protocol 148 overhead that is supported when compared to IEEE 802.15.4. 150 4.1. Protocol stack 152 Figure 2: Protocol Stack for IPv6 over LoRaWAN 154 +----------------------------------------+ ------------------ 155 | | Transport and 156 | Upper Layer Protocols | Application Layer 157 +----------------------------------------+ ------------------ 158 | | | 159 | IPv6 | | 160 | | Network 161 +----------------------------------------+ Layer 162 |Adaptation Layer for IPv6 over LoRaWAN | | 163 +----------------------------------------+ ------------------ 164 | | 165 | IPv6-LOR Addressing Binding | LoRaWAN Link Layer 166 | | | 167 +----------------------------------------+ ------------------ 168 | | | 169 | Activities | LoRaWAN 170 | Digital Protocol | Physical Layer 171 | RF Analog | | 172 | | | 173 +----------------------------------------+ ------------------ 175 Adaptation layer for IPv6 over LoRaWAN SHALL support neighbour discovery, 176 address auto-configuration, header compression, and fragmentation and 177 reassembly. 179 4.2. Link Model 181 According to RFC 4861 [RFC4861] a link is "a communication facility 182 or medium over which nodes can communicate at the link layer, i.e., 183 the layer immediately below IPv6." 185 In LoRaWAN the IPv6 layer is designed to enable transmission of IPv6 186 packets over LoRaWAN links. The LoRaWAN protocol is in charge of 187 establishing the pairwise communication between the LoRaWAN gateway 188 and the LoRaWAN device. The IPv6 adaptation layer however is in 189 charge of managing header compression and packet fragmentation in 190 order to deal with different spreading factors and allowed packet 191 payload at the underlying MAC layer. 193 Per this specification, the IPv6 header compression format specified 194 in RFC 6282 MUST be used [RFC6282] but more drastic compression based 195 on provisioning an extended context in the Neighbor Solicitation (NS) 196 is expected in the upcoming revision. The IPv6 payload length can be 197 derived from the LoRaWAN MAC header length and the possibly elided 198 IPv6 address can be reconstructed from the link-layer address, used 199 at the time of LoRaWAN connection establishment. As described in 200 Section 4.5 context information or more aggressive compression 201 formats such as RoHC [RFC3095] SHOULD be used at the 6LBR in order to 202 compress well-known network prefixes and indicated at the specific 203 field of the IPHC header. This compression will be defined in the 204 upcomming revisions. 206 LoRaWAN networks form star topologies or star of stars, having a 207 point-to-point nature. Address assignment is managed by the 6LBR 208 that ensures that collisions do not occur. Broadcast features are 209 used mainly by the 6LBR. 6LN to 6LN communications are always 210 carried out through the 6LBR and hence it is in charge of relaying 211 link local packets. 213 After the LoRaWAN node and the LoRaWAN gateway have established the 214 LoRaWAN connection, the link is enabled and IPv6 address 215 configuration and subsequent transmission are able to start. 217 4.3. Stateless Address Auto-configuration 219 Nodes (both hosts and routers) in a LoRaWAN network MAY use the 220 address auto-configuration process. This process relies in the 221 ability for a node to generate a link-local address for the 222 communication interface. A link-local address is formed by appending 223 an identifier of the interface to the well-known link-local prefix 224 [RFC4291]. Before the link-local address can be assigned to an 225 interface and used, a node must attempt to verify that this 226 "tentative" address is not already in use by another node on the 227 link. This section describes how LoRaWAN nodes determine the address 228 to be used and how this address is bound to the 6LBR node (or 229 Gateway). 231 4.3.1. LoRaWAN Addressing 233 The DevEUI is a global end-device ID in IEEE EUI64 address space that 234 uniquely identifies the end-device. The DevEUI is preconfigured at 235 each node. 237 A LoRaWAN device addressing can be conducted in two ways. Over the 238 air activation (OTAA) and Activation by personalization (ABP). The 239 former requires 2 MAC layer messages to establish the network address 240 and security keys (join-request and join-response). The latter 241 assumes that device address and security keys are pre-programmed at 242 the nodes and the DevEUI is not mandatory. Lately, the LoRa Alliance 243 is considering to mandate DevEUI in ABP mode. 245 Figure 3: DevEUI 247 +------------+----------------+ 248 | Bit# | [63..0] | 249 +------------+----------------+ 250 | DevEUI | DevEUI | 251 +------------+----------------+ 253 4.3.2. Address Auto-Configuration 255 A LoRaWAN end device performs stateless address auto-configuration as 256 per [RFC4862]. A 64-bit Interface identifier (IID) for a LoRaWAN 257 interface MAY be formed by utilizing the 64-bit LoRaWAN DevEUI. That 258 IID MAY guarantee a stable IPv6 address and MUST be used along the 259 lifetime of the network. 261 According to [RFC7136], interface IIDs of all unicast addresses for 262 LoRaWAN-enabled devices MUST be formed on the basis of 64 bits long 263 and constructed using the EUI-64 format. LoRaWAN End Device 264 Addresses MUST follow a stateless address auto-configuration with the 265 64 bit DevEUI. 267 [RFC4291] indicates the use of a "Universal/Local" scope bit that 268 identifies the network device to be locally accessible or globally 269 accessible. The former SHOULD be followed and LoRaWAN end-devices 270 SHOULD set to 0 the "Universal/Local" bit. In the case that a 271 Universally accessible IPv6 address needs to be used a Neighbor 272 Discovery mechanism and a network commissioning procedure is 273 required. This procedure is described in Section 4.4. 275 LoRaWAN IPv6 Network Prefix is build using the link-local prefix 276 FE80::/64. The IPv6 link-local address for a LoRaWAN-enabled device 277 is formed by appending the IID, to the prefix, as depicted in 278 Figure 4. 280 Duplicate address detection for link-local addresses is performed by 281 the 6LBR. 283 Once a 6LN has established its own link-local address, it starts 284 sending Router Solicitation messages as described in [RFC4861] 285 Section 6.3.7. 287 For non-link-local addresses a 64-bit IID MAY be formed by utilizing 288 the 64-bit LoRaWAN DevEUI as described in this section. A 6LN can 289 also use a the EUI-64 generated IID from the MAC Layer. The non- 290 link-local addresses generated by the 6LN MUST be registered with the 291 6LBR. 293 The mechanism by which the 6LBR obtains an IPv6 prefix is out of 294 scope of this document but can for example be accomplished by using 295 Unique Local IPv6 Unicast Addresses (ULA) [RFC4193]. As 6LNs MUST 296 always communicate to the 6LBR, the "on-link" flag (L) MUST be set to 297 zero in the Prefix Information Option [RFC4861]. This will always 298 happen even when the destination is another 6LN using the same 299 prefix. 301 Figure 4: IPv6 link-local address in LoRaWAN 303 0 0 0 0 1 304 0 1 6 9 2 305 0 0 4 6 7 306 +----------+-----------------+---------------+----------------+ 307 |1111111010| zeros | DevEUI | 308 +----------+-----------------+---------------+----------------+ 309 | | 310 | /-------------------------- 128 bits ----------------------/| 311 | | 313 4.4. Neighbour Discovery 315 Neighbour Discovery is addressed following the classical ND approach 316 as defined by [RFC4861] , [RFC4862] and [RFC6775]. As LoRaWAN 317 networks can be organized in star topologies or star of stars 318 topologies the LoRaWAN manager can take two differentiated roles. 319 For single star topologies the LoRaWAN manager will act as a 6LBR and 320 MUST keep track of the nodes addresses within the link, otherwise it 321 acts as 6LR and forwards Node Solicitation and ARO requests to the 322 6LBR in the network. 324 Figure 5: ND Procedure for a single star topology 326 LoRaWAN node LoRaWAN 6LR/6LBR 327 | Router Solicitation (RS) | 328 |-------------------------------->| 329 | | 330 | Router Advertisement (RA) | 331 |<--------------------------------| 332 | | 333 | Neighbour Solicitation (NS) | 334 |-------------------------------->| 335 | | 336 | Neighbour Advertisement (NA) | 337 |<--------------------------------| 338 | | 340 When a LoRaWAN node joins a network, it sends an RS to the 6LR 341 containing its IID as described in Section 4.3.2. The 6LBR router 342 answers with a RA containing its IIDs and prefixes. Hosts receive 343 Router Advertisement messages containing the Authoritative Border 344 Router Option (ABRO), the IIDs of the 6LR or 6LBR and MAY optionally 345 contain one or more 6LoWPAN Context Options (6COs). They also 346 contain the existing Prefix Information Options (PIOs) as described 347 in [RFC4861]. 349 When a host has configured a non-link-local IPv6 address, it 350 registers that address with one or more of its default routers using 351 the Address Registration Option (ARO) in an NS message. The host 352 chooses a lifetime of the registration and repeats the ARO 353 periodically (before the lifetime runs out) to maintain the 354 registration. The host needs to refresh its prefix and context 355 information by sending a new unicast NS. As LoRaWAN might use very 356 low data rates it is recommended to use large Lifetime configurations 357 assuming that LoRaWAN devices are not mobile. According to [RFC6775] 358 the maximum Router Lifetime is about 18 hours, whereas the maximum 359 Registration Lifetime is about 45.5 days. 361 Future versions of this document should consider the ND approach 362 described in [efficient-nd] 364 The ND Procedure for star of stars follows the multi-hop ND approach 365 described by [RFC6775]. The multihop distribution relies on RS 366 messages and RA messages sent between routers, and using the ABRO 367 version number to control the propagation of the information 368 (prefixes and context information) that is being sent in the RAs. 370 Figure 6: ND Procedure for star of stars in LoRaWAN. 372 LoRaWAN node LoRaWAN 6LR LoRaWAN 6LBR 373 | Router Solicitation (RS) | | 374 |------------------------------->| | 375 | | | 376 | Router Advertisement (RA) | | 377 |<-------------------------------| | 378 | | | 379 | Node Registration (NR) | | 380 |------------------------------->| | 381 | | Neighbour Solicitation (NS) | 382 | |--------------------------------->| 383 | | | 384 | | Neighbour Advertisement (NA) | 385 | |<---------------------------------| 386 | Node Confirmation (NC) | | 387 |<-------------------------------| | 388 | | | 390 4.5. Header Compression in LoRaWAN 392 TODO. 394 4.6. Fragmentation in LoRaWAN 396 TODO. 398 5. Internet Connectivity Scenarios 400 TODO. 402 6. Security Considerations 404 The transmission of IPv6 over LoRaWAN links has similar requirements 405 and concerns for security as for IEEE 802.15.4. LoRaWAN Link Layer 406 security considerations are covered by the LoRaWAN Specification 407 [LoRaSpec]. 409 7. IANA Considerations 411 There are no IANA considerations related to this document. 413 8. Acknowledgements 415 The authors would like to acknowledge the guidance and input provided 416 by Pascal Thubert. 418 9. References 420 9.1. Normative References 422 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 423 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 424 February 2014, . 426 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 427 Bormann, "Neighbor Discovery Optimization for IPv6 over 428 Low-Power Wireless Personal Area Networks (6LoWPANs)", 429 RFC 6775, DOI 10.17487/RFC6775, November 2012, 430 . 432 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 433 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 434 DOI 10.17487/RFC6282, September 2011, 435 . 437 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 438 "Transmission of IPv6 Packets over IEEE 802.15.4 439 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 440 . 442 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 443 Address Autoconfiguration", RFC 4862, 444 DOI 10.17487/RFC4862, September 2007, 445 . 447 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 448 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 449 DOI 10.17487/RFC4861, September 2007, 450 . 452 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 453 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 454 2006, . 456 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 457 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 458 . 460 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 461 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 462 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 463 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 464 Compression (ROHC): Framework and four profiles: RTP, UDP, 465 ESP, and uncompressed", RFC 3095, DOI 10.17487/RFC3095, 466 July 2001, . 468 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 469 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 470 December 1998, . 472 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 473 Requirement Levels", BCP 14, RFC 2119, 474 DOI 10.17487/RFC2119, March 1997, 475 . 477 9.2. External Informative References 479 [LoRaSpec] 480 LoRa Alliance, "LoRaWAN Specification Rev.3", April 2014. 482 [efficient-nd] 483 Thubert, P., Nordmark, E., and S. Chakrabarti, "An Update 484 to 6LoWPAN ND", draft-thubert-6lo-rfc6775-update-00 , May 485 2016. 487 Authors' Addresses 489 Xavier Vilajosana (editor) 490 Worldsensing 491 483 Arago 4th floor 492 Barcelona, Catalonia 08013 493 Spain 495 Email: xvilajosana@worldsensing.com 497 Mischa Dohler 498 King's College London 499 London, London 500 UK 502 Email: mischa.dohler@kcl.ac.uk 503 Alper Yegin 504 Actility 505 Paris, Paris 506 FR 508 Email: alper.yegin@actility.com