idnits 2.17.00 (12 Aug 2021) /tmp/idnits42659/draft-ietf-6lo-use-cases-07.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 35 instances of too long lines in the document, the longest one being 4 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 (September 10, 2019) is 984 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '6lo' is mentioned on line 126, but not defined == Missing Reference: '6lo-ap-nd' is mentioned on line 516, but not defined == Outdated reference: A later version (-17) exists of draft-ietf-6lo-nfc-15 == Outdated reference: draft-ietf-6lo-blemesh has been published as RFC 9159 == Outdated reference: A later version (-11) exists of draft-ietf-6lo-plc-00 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6Lo Working Group Y-G. Hong 3 Internet-Draft ETRI 4 Intended status: Informational C. Gomez 5 Expires: March 13, 2020 UPC 6 Y-H. Choi 7 ETRI 8 AR. Sangi 9 Huaiyin Institute of Technology 10 T. Aanstoot 11 Modio AB 12 S. Chakrabarti 13 September 10, 2019 15 IPv6 over Constrained Node Networks (6lo) Applicability & Use cases 16 draft-ietf-6lo-use-cases-07 18 Abstract 20 This document describes the applicability of IPv6 over constrained 21 node networks (6lo) and provides practical deployment examples. In 22 addition to IEEE 802.15.4, various link layer technologies such as 23 ITU-T G.9959 (Z-Wave), BLE, DECT-ULE, MS/TP, NFC, and PLC (IEEE 24 1901.2) are used as examples. The document targets an audience who 25 like to understand and evaluate running end-to-end IPv6 over the 26 constrained node networks connecting devices to each other or to 27 other devices on the Internet (e.g. cloud infrastructure). 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on March 13, 2020. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 65 3. 6lo Link layer technologies . . . . . . . . . . . . . . . . . 4 66 3.1. ITU-T G.9959 . . . . . . . . . . . . . . . . . . . . . . 4 67 3.2. Bluetooth LE . . . . . . . . . . . . . . . . . . . . . . 4 68 3.3. DECT-ULE . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.4. MS/TP . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.5. NFC . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 3.6. PLC . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 3.7. Comparison between 6lo Link layer technologies . . . . . 7 73 4. 6lo Deployment Scenarios . . . . . . . . . . . . . . . . . . 8 74 4.1. G3-PLC usage of 6lo in network layer . . . . . . . . . . 8 75 4.2. Netricity usage of 6lo in network layer . . . . . . . . . 9 76 5. Guidelines for adopting IPv6 stack (6lo/6LoWPAN) . . . . . . 10 77 6. 6lo Use Case Examples . . . . . . . . . . . . . . . . . . . . 12 78 6.1. Use case of ITU-T G.9959: Smart Home . . . . . . . . . . 12 79 6.2. Use case of Bluetooth LE: Smartphone-based Interaction . 13 80 6.3. Use case of DECT-ULE: Smart Home . . . . . . . . . . . . 13 81 6.4. Use case of MS/TP: Building Automation Networks . . . . . 14 82 6.5. Use case of NFC: Alternative Secure Transfer . . . . . . 15 83 6.6. Use case of PLC: Smart Grid . . . . . . . . . . . . . . . 15 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 86 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 88 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 89 10.2. Informative References . . . . . . . . . . . . . . . . . 19 90 Appendix A. Design Space Dimensions for 6lo Deployment . . . . . 20 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 93 1. Introduction 95 Running IPv6 on constrained node networks has different features from 96 general node networks due to the characteristics of constrained node 97 networks such as small packet size, short link-layer address, low 98 bandwidth, network topology, low power, low cost, and large number of 99 devices [RFC4919][RFC7228]. For example, some IEEE 802.15.4 link 100 layers have a frame size of 127 octets and IPv6 requires the layer 101 below to support an MTU of 1280 bytes, therefore an appropriate 102 fragmentation and reassembly adaptation layer must be provided at the 103 layer below IPv6. Also, the limited size of IEEE 802.15.4 frame and 104 low energy consumption requirements make the need for header 105 compression. The IETF 6LoPWAN (IPv6 over Low powerWPAN) working 106 group published an adaptation layer for sending IPv6 packets over 107 IEEE 802.15.4 [RFC4944], which includes a compression format for IPv6 108 datagrams over IEEE 802.15.4-based networks [RFC6282], and Neighbor 109 Discovery Optimization for 6LoPWAN [RFC6775]. 111 As IoT (Internet of Things) services become more popular, IPv6 over 112 various link layer technologies such as Bluetooth Low Energy 113 (Bluetooth LE), ITU-T G.9959 (Z-Wave), Digital Enhanced Cordless 114 Telecommunications - Ultra Low Energy (DECT-ULE), Master-Slave/Token 115 Passing (MS/TP), Near Field Communication (NFC), and Power Line 116 Communication (PLC) have been defined at [IETF_6lo] working group. 117 IPv6 stacks for constrained node networks use a variation of the 118 6LoWPAN stack applied to each particular link layer technology. 120 In the 6LoPWAN working group, the [RFC6568], "Design and Application 121 Spaces for 6LoWPANs" was published and it describes potential 122 application scenarios and use cases for low-power wireless personal 123 area networks. Hence, this 6lo applicability document aims to 124 provide guidance to an audience who are new to IPv6-over-low-power 125 networks concept and want to assess if variance of 6LoWPAN stack 126 [6lo] can be applied to the constrained layer two (L2) network of 127 their interest. This 6lo applicability document puts together 128 various design space dimensions such as deployment, network size, 129 power source, connectivity, multi-hop communication, traffic pattern, 130 security level, mobility, and QoS requirements etc. In addition, it 131 describes a few set of 6LoPWAN application scenarios and practical 132 deployment as examples. 134 This document provides the applicability and use cases of 6lo, 135 considering the following aspects: 137 o 6lo applicability and use cases MAY be uniquely different from 138 those of 6LoWPAN defined for IEEE 802.15.4. 140 o It SHOULD cover various IoT related wire/wireless link layer 141 technologies providing practical information of such technologies. 143 o A general guideline on how the 6LoWPAN stack can be modified for a 144 given L2 technology. 146 o Example use cases and practical deployment examples. 148 2. Conventions and Terminology 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in [RFC2119]. 154 3. 6lo Link layer technologies 156 3.1. ITU-T G.9959 158 The ITU-T G.9959 Recommendation [G.9959] targets low-power Personal 159 Area Networks (PANs), and defines physical layer and link layer 160 functionality. Physical layers of 9.6 kbit/s, 40 kbit/s and 100 161 kbit/s are supported. G.9959 defines how a unique 32-bit HomeID 162 network identifier is assigned by a network controller and how an 163 8-bit NodeID host identifier is allocated to each node. NodeIDs are 164 unique within the network identified by the HomeID. The G.9959 165 HomeID represents an IPv6 subnet that is identified by one or more 166 IPv6 prefixes [RFC7428]. The ITU-T G.9959 can be used for smart home 167 applications. 169 3.2. Bluetooth LE 171 Bluetooth LE was introduced in Bluetooth 4.0, enhanced in Bluetooth 172 4.1, and developed even further in successive versions. Bluetooth 173 SIG has also published Internet Protocol Support Profile (IPSP). The 174 IPSP enables discovery of IP-enabled devices and establishment of 175 link-layer connection for transporting IPv6 packets. IPv6 over 176 Bluetooth LE is dependent on both Bluetooth 4.1 and IPSP 1.0 or 177 newer. 179 Many Devices such as mobile phones, notebooks, tablets and other 180 handheld computing devices which support Bluetooth 4.0 or subsequent 181 chipsets also support the low-energy variant of Bluetooth. Bluetooth 182 LE is also being included in many different types of accessories that 183 collaborate with mobile devices such as phones, tablets and notebook 184 computers. An example of a use case for a Bluetooth LE accessory is 185 a heart rate monitor that sends data via the mobile phone to a server 186 on the Internet [RFC7668]. A typical usage of Bluetooth LE is 187 smartphone-based interaction with constrained devices. Bluetooth LE 188 was originally designed to enable star topology networks. However, 189 recent Bluetooth versions support the formation of extended 190 topologies, and IPv6 support for mesh networks of Bluetooth LE 191 devices is being developed [I-D.ietf-6lo-blemesh] 193 3.3. DECT-ULE 195 DECT ULE is a low power air interface technology that is designed to 196 support both circuit switched services, such as voice communication, 197 and packet mode data services at modest data rate. 199 The DECT ULE protocol stack consists of the PHY layer operating at 200 frequencies in the 1880 - 1920 MHz frequency band depending on the 201 region and uses a symbol rate of 1.152 Mbps. Radio bearers are 202 allocated by use of FDMA/TDMA/TDD techniques. 204 In its generic network topology, DECT is defined as a cellular 205 network technology. However, the most common configuration is a star 206 network with a single Fixed Part (FP) defining the network with a 207 number of Portable Parts (PP) attached. The MAC layer supports 208 traditional DECT as this is used for services like discovery, 209 pairing, security features etc. All these features have been reused 210 from DECT. 212 The DECT ULE device can switch to the ULE mode of operation, 213 utilizing the new ULE MAC layer features. The DECT ULE Data Link 214 Control (DLC) provides multiplexing as well as segmentation and re- 215 assembly for larger packets from layers above. The DECT ULE layer 216 also implements per-message authentication and encryption. The DLC 217 layer ensures packet integrity and preserves packet order, but 218 delivery is based on best effort. 220 The current DECT ULE MAC layer standard supports low bandwidth data 221 broadcast. However the usage of this broadcast service has not yet 222 been standardized for higher layers [RFC8105]. DECT-ULE can be used 223 for smart metering in a home. 225 3.4. MS/TP 227 Master-Slave/Token-Passing (MS/TP) is a Medium Access Control (MAC) 228 protocol for the RS-485 [TIA-485-A] physical layer and is used 229 primarily in building automation networks. 231 An MS/TP device is typically based on a low-cost microcontroller with 232 limited processing power and memory. These constraints, together 233 with low data rates and a small MAC address space, are similar to 234 those faced in 6LoWPAN networks. MS/TP differs significantly from 235 6LoWPAN in at least three respects: a) MS/TP devices are typically 236 mains powered, b) all MS/TP devices on a segment can communicate 237 directly so there are no hidden node or mesh routing issues, and c) 238 the latest MS/TP specification provides support for large payloads, 239 eliminating the need for fragmentation and reassembly below IPv6. 241 MS/TP is designed to enable multidrop networks over shielded twisted 242 pair wiring. It can support network segments up to 1000 meters in 243 length at a data rate of 115.2 kbit/s or segments up to 1200 meters 244 in length at lower bit rates. An MS/TP interface requires only a 245 UART, an RS-485 [TIA-485-A] transceiver with a driver that can be 246 disabled, and a 5 ms resolution timer. The MS/TP MAC is typically 247 implemented in software. 249 Because of its superior "range" (~1 km) compared to many low power 250 wireless data links, MS/TP may be suitable to connect remote devices 251 (such as district heating controllers) to the nearest building 252 control infrastructure over a single link [RFC8163]. MS/TP can be 253 used for building automation networks. 255 3.5. NFC 257 NFC technology enables simple and safe two-way interactions between 258 electronic devices, allowing consumers to perform contactless 259 transactions, access digital content, and connect electronic devices 260 with a single touch. NFC complements many popular consumer level 261 wireless technologies, by utilizing the key elements in existing 262 standards for contactless card technology (ISO/IEC 14443 A&B and 263 JIS-X 6319-4). NFC can be compatible with existing contactless card 264 infrastructure and it enables a consumer to utilize one device across 265 different systems. 267 Extending the capability of contactless card technology, NFC also 268 enables devices to share information at a distance that is less than 269 10 cm with a maximum communication speed of 424 kbps. Users can 270 share business cards, make transactions, access information from a 271 smart poster or provide credentials for access control systems with a 272 simple touch. 274 NFC's bidirectional communication ability is ideal for establishing 275 connections with other technologies by the simplicity of touch. In 276 addition to the easy connection and quick transactions, simple data 277 sharing is also available [I-D.ietf-6lo-nfc]. NFC can be used for 278 secure transfer in healthcare services. 280 3.6. PLC 282 PLC is a data transmission technique that utilizes power conductors 283 as medium. Unlike other dedicated communication infrastructure, 284 power conductors are widely available indoors and outdoors. 285 Moreover, wired technologies are more susceptible to cause 286 interference but are more reliable than their wireless counterparts. 287 PLC is a data transmission technique that utilizes power conductors 288 as medium[I-D.ietf-6lo-plc]. 290 The below table shows some available open standards defining PLC. 292 +-------------+-----------------+------------+-----------+----------+ 293 | PLC Systems | Frequency Range | Type | Data Rate | Distance | 294 +-------------+-----------------+------------+-----------+----------+ 295 | IEEE1901 | <100MHz | Broadband | 200Mbps | 1000m | 296 | | | | | | 297 | IEEE1901.1 | <15MHz | PLC-IoT | 10Mbps | 2000m | 298 | | | | | | 299 | IEEE1901.2 | <500kHz | Narrowband | 200Kbps | 3000m | 300 +-------------+-----------------+------------+-----------+----------+ 302 Table 1: Some Available Open Standards in PLC 304 [IEEE1901] defines a broadband variant of PLC but is effective within 305 short range. This standard addresses the requirements of 306 applications with high data rate such as: Internet, HDTV, Audio, 307 Gaming etc. Broadband operates on OFDM (Orthogonal Frequency 308 Division Multiplexing) modulation. 310 [IEEE1901.2] defines a narrowband variant of PLC with less data rate 311 but significantly higher transmission range that could be used in an 312 indoor or even an outdoor environment. It is applicable to typical 313 IoT applications such as: Building Automation, Renewable Energy, 314 Advanced Metering, Street Lighting, Electric Vehicle, Smart Grid etc. 315 Moreover, IEEE 1901.2 standard is based on the 802.15.4 MAC sub-layer 316 and fully endorses the security scheme defined in 802.15.4 [RFC8036]. 317 A typical use case of PLC is smart grid. 319 3.7. Comparison between 6lo Link layer technologies 321 In above clauses, various 6lo Link layer technologies and a possible 322 candidate are described. The following table shows that dominant 323 paramters of each use case corresponding to the 6lo link layer 324 technology. 326 +--------------+---------+---------+---------+---------+---------+---------+ 327 | | Z-Wave | BLE | DECT-ULE| MS/TP | NFC | PLC | 328 +--------------+---------+---------+---------+---------+---------+---------+ 329 | | Home | Interact| | Building| Health- | | 330 | Usage | Auto- | w/ Smart| Meter | Auto- | care | Smart | 331 | | mation | Phone | Reading | mation | Service | Grid | 332 +--------------+---------+---------+---------+---------+---------+---------+ 333 | Topology | L2-mesh | Star | Star | MS/TP | P2P | Star | 334 | & | or | & | | | | Tree | 335 | Subnet | L3-mesh | Mesh | No mesh | No mesh | L2-mesh | Mesh | 336 +--------------+---------+---------+---------+---------+---------+---------+ 337 | | | | | | | | 338 | Mobility | No | Low | No | No | Moderate| No | 339 | Requirement | | | | | | | 340 +--------------+---------+---------+---------+---------+---------+---------+ 341 | | High + | | High + | High + | | High + | 342 | Security | Privacy |Partially| Privacy | Authen. | High | Encrypt.| 343 | Requirement | required| | required| required| | required| 344 +--------------+---------+---------+---------+---------+---------+---------+ 345 | | | | | | | | 346 | Buffering | Low | Low | Low | Low | Low | Low | 347 | Requirement | | | | | | | 348 +--------------+---------+---------+---------+---------+---------+---------+ 349 | Latency, | | | | | | | 350 | QoS | High | Low | Low | High | High | Low | 351 | Requirement | | | | | | | 352 +--------------+---------+---------+---------+---------+---------+---------+ 353 | | | | | | | | 354 | Data | Infrequ-| Infrequ-| Infrequ-| Frequent| Small | Infrequ-| 355 | Rate | ent | ent | ent | | | ent | 356 +--------------+---------+---------+---------+---------+---------+---------+ 357 | RFC # | | | | | draft- | draft- | 358 | or | RFC7428 | RFC7668 | RFC8105 | RFC8163 | ietf-6lo| ietf-6lo| 359 | Draft | | | | | -nfc | -plc | 360 +--------------+---------+---------+---------+---------+---------+---------+ 362 Table 2: Comparison between 6lo Link layer technologies 364 4. 6lo Deployment Scenarios 366 4.1. G3-PLC usage of 6lo in network layer 368 G3-PLC [G3-PLC] is a narrow-band PLC technology that is based on 369 ITU-T G.9903 Recommendation [G.9903]. G3-PLC supports multi-hop mesh 370 network, and facilitates highly-reliable, long-range communication. 371 With the abilities to support IPv6 and to cross transformers, G3-PLC 372 is regarded as one of the next-generation NB-PLC technologies. 374 G3-PLC has got massive deployments over several countries, e.g. 375 Japan and France. 377 The main application domains targeted by G3-PLC are smart grid and 378 smart cities. This includes, but is not limited to the following 379 applications: 381 o Smart Metering 383 o Vehicle-to-Grid Communication 385 o Demand Response (DR) 387 o Distribution Automation 389 o Home/Building Energy Management Systems 391 o Smart Street Lighting 393 o Advanced Metering Infrastructure (AMI) backbone network 395 o Wind/Solar Farm Monitoring 397 In the G3-PLC specification, the 6lo adaptation layer utilizes the 398 6LoWPAN functions (e.g. header compression, fragmentation and 399 reassembly) so as to enable IPv6 packet transmission. LOADng, which 400 is a lightweight variant of AODV, is applied as the mesh-under 401 routing protocol in G3-PLC networks. Address assignment and network 402 configuration are based on the bootstrapping protocol specified in 403 ITU-T G.9903. The network layer consists of IPv6 and ICMPv6 while 404 the transport protocol UDP is used for data transmission. 406 4.2. Netricity usage of 6lo in network layer 408 The Netricity program in HomePlug Powerline Alliance [NETRICITY] 409 promotes the adoption of products built on the IEEE 1901.2 Low- 410 Frequency Narrow-Band PLC standard, which provides for urban and long 411 distance communications and propagation through transformers of the 412 distribution network using frequencies below 500 kHz. The technology 413 also addresses requirements that assure communication privacy and 414 secure networks. 416 The main application domains targeted by Netricity are smart grid and 417 smart cities. This includes, but is not limited to the following 418 applications: 420 o Utility grid modernization 421 o Distribution automation 423 o Meter-to-Grid connectivity 425 o Micro-grids 427 o Grid sensor communications 429 o Load control 431 o Demand response 433 o Net metering 435 o Street Lighting control 437 o Photovoltaic panel monitoring 439 Netricity system architecture is based on the PHY and MAC layers of 440 IEEE 1901.2 PLC standard. Regarding the 6lo adaptation layer and 441 IPv6 network layer, Netricity utilizes IPv6 protocol suite including 442 6lo/6LoWPAN header compression, DHCPv6 for IP address management, RPL 443 routing protocol, ICMPv6, and unicast/multicast forwarding. Note 444 that the layer 3 routing in Netricity uses RPL in non-storing mode 445 with the MRHOF objective function based on the own defined Estimated 446 Transmission Time (ETT) metric. 448 5. Guidelines for adopting IPv6 stack (6lo/6LoWPAN) 450 The following guideline targets new candidate constrained L2 451 technologies that may be considered for running modified 6LoWPAN 452 stack on top. The modification of 6LoWPAN stack should be based on 453 the following: 455 o Addressing Model: Addressing model determines whether the device 456 is capable of forming IPv6 Link-local and global addresses and 457 what is the best way to derive the IPv6 addresses for the 458 constrained L2 devices. Whether the device is capable of forming 459 IPv6 Link-local and global addresses, L2-address-derived IPv6 460 addresses are specified in [RFC4944], but there exist implications 461 for privacy. For global usage, a unique IPv6 address must be 462 derived using an assigned prefix and a unique interface ID. 463 [RFC8065] provides such guidelines. For MAC derived IPv6 address, 464 please refer to [RFC8163] for IPv6 address mapping examples. 465 Broadcast and multicast support are dependent on the L2 networks. 466 Most low-power L2 implementations map multicast to broadcast 467 networks. So care must be taken in the design when to use 468 broadcast and try to stick to unicast messaging whenever possible. 470 o MTU Considerations: The deployment SHOULD consider their need for 471 maximum transmission unit (MTU) of a packet over the link layer 472 and should consider if fragmentation and reassembly of packets are 473 needed at the 6LoWPAN layer. For example, if the link layer 474 supports fragmentation and reassembly of packets, then 6LoWPAN 475 layer may skip supporting fragmentation/reassembly. In fact, for 476 most efficiency, choosing a low-power link layer that can carry 477 unfragmented application packets would be optimum for packet 478 transmission if the deployment can afford it. Please refer to 6lo 479 RFCs [RFC7668], [RFC8163], [RFC8105] for example guidance. 481 o Mesh or L3-Routing: 6LoWPAN specifications do provide mechanisms 482 to support for mesh routing at L2. [RFC6550] defines layer three 483 (L3) routing for low power lossy networks using directed graphs. 484 6LoWPAN is routing protocol agnostic and other L2 or L3 routing 485 protocols can be run using a 6LoWPAN stack. 487 o Address Assignment: 6LoWPAN requires that IPv6 Neighbor Discovery 488 for low power networks [RFC6775] be used for autoconfiguration of 489 stateless IPv6 address assignment. Considering the energy 490 sensitive networks [RFC6775] makes optimization from classical 491 IPv6 ND [RFC4861] protocol. It is the responsibility of the 492 deployment to ensure unique global IPv6 addresses for the Internet 493 connectivity. For local-only connectivity IPv6 ULA may be used. 494 [RFC6775] specifies the 6LoWPAN border router(6LBR) which is 495 responsible for prefix assignment to the 6lo/6LoWPAN network. 6LBR 496 can be connected to the Internet or Enterprise network via its one 497 of the interfaces. Please refer to [RFC7668] and [RFC8105] for 498 examples of address assignment considerations. In addition, 499 privacy considerations [RFC8065] must be consulted for 500 applicability. In certain scenarios, the deployment may not 501 support autoconfiguration of IPv6 addressing due to regulatory and 502 business reasons and may choose to offer a separate address 503 assignment service. 505 o Header Compression: IPv6 header compression [RFC6282] is a vital 506 part of IPv6 over low power communication. Examples of header 507 compression for different link-layers specifications are found in 508 [RFC7668], [RFC8163], [RFC8105]. A generic header compression 509 technique is specified in [RFC7400]. 511 o Security and Encryption: Though 6LoWPAN basic specifications do 512 not address security at the network layer, the assumption is that 513 L2 security must be present. In addition, application level 514 security is highly desirable. The working groups [ace] and [core] 515 should be consulted for application and transport level security. 516 6lo working group is working on address authentication [6lo-ap-nd] 517 and secure bootstrapping is also being discussed at IETF. 519 However, there may be different levels of security available in a 520 deployment through other standards such as hardware level security 521 or certificates for initial booting process. Encryption is 522 important if the implementation can afford it. 524 o Additional processing: [RFC8066] defines guidelines for ESC 525 dispatch octets use in the 6LoWPAN header. An implementation may 526 take advantage of ESC header to offer a deployment specific 527 processing of 6LoWPAN packets. 529 6. 6lo Use Case Examples 531 As IPv6 stacks for constrained node networks use a variation of the 532 6LoWPAN stack applied to each particular link layer technology, 533 various 6lo use cases can be provided. In this clause, various 6lo 534 use cases which are based on each particular link layer technology 535 are described. 537 6.1. Use case of ITU-T G.9959: Smart Home 539 Z-Wave is one of the main technologies that may be used to enable 540 smart home applications. Born as a proprietary technology, Z-Wave 541 was specifically designed for this particular use case. Recently, 542 the Z-Wave radio interface (physical and MAC layers) has been 543 standardized as the ITU-T G.9959 specification. 545 Example: Use of ITU-T G.9959 for Home Automation 547 Variety of home devices (e.g. light dimmers/switches, plugs, 548 thermostats, blinds/curtains and remote controls) are augmented with 549 ITU-T G.9959 interfaces. A user may turn on/off or may control home 550 appliances by pressing a wall switch or by pressing a button in a 551 remote control. Scenes may be programmed, so that after a given 552 event, the home devices adopt a specific configuration. Sensors may 553 also periodically send measurements of several parameters (e.g. gas 554 presence, light, temperature, humidity, etc.) which are collected at 555 a sink device, or may generate commands for actuators (e.g. a smoke 556 sensor may send an alarm message to a safety system). 558 The devices involved in the described scenario are nodes of a network 559 that follows the mesh topology, which is suitable for path diversity 560 to face indoor multipath propagation issues. The multihop paradigm 561 allows end-to-end connectivity when direct range communication is not 562 possible. Security support is required, specially for safety-related 563 communication. When a user interaction (e.g. a button press) 564 triggers a message that encapsulates a command, if the message is 565 lost, the user may have to perform further interactions to achieve 566 the desired effect (e.g. a light is turned off). A reaction to a 567 user interaction will be perceived by the user as immediate as long 568 as the reaction takes place within 0.5 seconds [RFC5826]. 570 6.2. Use case of Bluetooth LE: Smartphone-based Interaction 572 The key feature behind the current high Bluetooth LE momentum is its 573 support in a large majority of smartphones in the market. Bluetooth 574 LE can be used to allow the interaction between the smartphone and 575 surrounding sensors or actuators. Furthermore, Bluetooth LE is also 576 the main radio interface currently available in wearables. Since a 577 smartphone typically has several radio interfaces that provide 578 Internet access, such as Wi-Fi or 4G, the smartphone can act as a 579 gateway for nearby devices such as sensors, actuators or wearables. 580 Bluetooth LE may be used in several domains, including healthcare, 581 sports/wellness and home automation. 583 Example: Use of Bluetooth LE-based Body Area Network for fitness 585 A person wears a smartwatch for fitness purposes. The smartwatch has 586 several sensors (e.g. heart rate, accelerometer, gyrometer, GPS, 587 temperature, etc.), a display, and a Bluetooth LE radio interface. 588 The smartwatch can show fitness-related statistics on its display. 589 However, when a paired smartphone is in the range of the smartwatch, 590 the latter can report almost real-time measurements of its sensors to 591 the smartphone, which can forward the data to a cloud service on the 592 Internet. In addition, the smartwatch can receive notifications 593 (e.g. alarm signals) from the cloud service via the smartphone. On 594 the other hand, the smartphone may locally generate messages for the 595 smartwatch, such as e-mail reception or calendar notifications. 597 The functionality supported by the smartwatch may be complemented by 598 other devices such as other on-body sensors, wireless headsets or 599 head-mounted displays. All such devices may connect to the 600 smartphone creating a star topology network whereby the smartphone is 601 the central component. Support for extended network topologies (e.g. 602 mesh networks) is being developed as of the writing. 604 6.3. Use case of DECT-ULE: Smart Home 606 DECT is a technology widely used for wireless telephone 607 communications in residential scenarios. Since DECT-ULE is a low- 608 power variant of DECT, DECT-ULE can be used to connect constrained 609 devices such as sensors and actuators to a Fixed Part, a device that 610 typically acts as a base station for wireless telephones. Therefore, 611 DECT-ULE is specially suitable for the connected home space in 612 application areas such as home automation, smart metering, safety, 613 healthcare, etc. 615 Example: Use of DECT-ULE for Smart Metering 617 The smart electricity meter of a home is equipped with a DECT-ULE 618 transceiver. This device is in the coverage range of the Fixed Part 619 of the home. The Fixed Part can act as a router connected to the 620 Internet. This way, the smart meter can transmit electricity 621 consumption readings through the DECT-ULE link with the Fixed Part, 622 and the latter can forward such readings to the utility company using 623 Wide Area Network (WAN) links. The meter can also receive queries 624 from the utility company or from an advanced energy control system 625 controlled by the user, which may also be connected to the Fixed Part 626 via DECT-ULE. 628 6.4. Use case of MS/TP: Building Automation Networks 630 The primary use case for IPv6 over MS/TP (6LoBAC) is in building 631 automation networks. [BACnet] is the open international standard 632 protocol for building automation, and MS/TP is defined in [BACnet] 633 Clause 9. MS/TP was designed to be a low cost multi-drop field bus 634 to inter-connect the most numerous elements (sensors and actuators) 635 of a building automation network to their controllers. A key aspect 636 of 6LoBAC is that it is designed to co-exist with BACnet MS/TP on the 637 same link, easing the ultimate transition of some BACnet networks to 638 native end-to-end IPv6 transport protocols. New applications for 639 6LoBAC may be found in other domains where low cost, long distance, 640 and low latency are required. 642 Example: Use of 6LoBAC in Building Automation Networks 644 The majority of installations for MS/TP are for "terminal" or 645 "unitary" controllers, i.e. single zone or room controllers that may 646 connect to HVAC or other controls such as lighting or blinds. The 647 economics of daisy-chaining a single twisted-pair between multiple 648 devices is often preferred over home-run Cat-5 style wiring. 650 A multi-zone controller might be implemented as an IP router between 651 a traditional Ethernet link and several 6LoBAC links, fanning out to 652 multiple terminal controllers. 654 The superior distance capabilities of MS/TP (~1 km) compared to other 655 6lo media may suggest its use in applications to connect remote 656 devices to the nearest building infrastructure. for example, remote 657 pumping or measuring stations with moderate bandwidth requirements 658 can benefit from the low cost and robust capabilities of MS/TP over 659 other wired technologies such as DSL, and without the line-of-site 660 restrictions or hop-by-hop latency of many low cost wireless 661 solutions. 663 6.5. Use case of NFC: Alternative Secure Transfer 665 According to applications, various secured data can be handled and 666 transferred. Depending on security level of the data, methods for 667 transfer can be alternatively selected. 669 Example: Use of NFC for Secure Transfer in Healthcare Services with 670 Tele-Assistance 672 A senior citizen who lives alone wears one to several wearable 6lo 673 devices to measure heartbeat, pulse rate, etc. The 6lo devices are 674 densely installed at home for movement detection. An LoWPAN Border 675 Router (LBR) at home will send the sensed information to a connected 676 healthcare center. Portable base stations with LCDs may be used to 677 check the data at home, as well. Data is gathered in both periodic 678 and event-driven fashion. In this application, event-driven data can 679 be very time-critical. In addition, privacy also becomes a serious 680 issue in this case, as the sensed data is very personal. 682 While the senior citizen is provided audio and video healthcare 683 services by a tele-assistance based on LTE connections, the senior 684 citizen can alternatively use NFC connections to transfer the 685 personal sensed data to the tele-assistance. At this moment, hidden 686 hackers can overhear the data based on the LTE connection, but they 687 cannot gather the personal data over the NFC connection. 689 6.6. Use case of PLC: Smart Grid 691 Smart grid concept is based on numerous operational and energy 692 measuring sub-systems of an electric grid. It comprises of multiple 693 administrative levels/segments to provide connectivity among these 694 numerous components. Last mile connectivity is established over LV 695 segment, whereas connectivity over electricity distribution takes 696 place in HV segment. 698 Although other wired and wireless technologies are also used in Smart 699 Grid (Advance Metering Infrastructure - AMI, Demand Response - DR, 700 Home Energy Management System - HEMS, Wide Area Situational Awareness 701 - WASA etc), PLC enjoys the advantage of existing (power conductor) 702 medium and better reliable data communication. PLC is a promising 703 wired communication technology in that the electrical power lines are 704 already there and the deployment cost can be comparable to wireless 705 technologies. The 6lo related scenarios lie in the low voltage PLC 706 networks with most applications in the area of Advanced Metering 707 Infrastructure, Vehicle-to-Grid communications, in-home energy 708 management and smart street lighting. 710 Example: Use of PLC for Advanced Metering Infrastructure 711 Household electricity meters transmit time-based data of electric 712 power consumption through PLC. Data concentrators receive all the 713 meter data in their corresponding living districts and send them to 714 the Meter Data Management System (MDMS) through WAN network (e.g. 715 Medium-Voltage PLC, Ethernet or GPRS) for storage and analysis. Two- 716 way communications are enabled which means smart meters can do 717 actions like notification of electricity charges according to the 718 commands from the utility company. 720 With the existing power line infrastructure as communication medium, 721 cost on building up the PLC network is naturally saved, and more 722 importantly, labor operational costs can be minimized from a long- 723 term perspective. Furthermore, this AMI application speeds up 724 electricity charge, reduces losses by restraining power theft and 725 helps to manage the health of the grid based on line loss analysis. 727 Example: Use of PLC (IEEE1901.1) for WASA in Smart Grid 729 Many sub-systems of Smart Grid require low data rate and narrowband 730 variant (IEEE1901.2) of PLC fulfils such requirements. Recently, 731 more complex scenarios are emerging that require higher data rates. 733 WASA sub-system is an appropriate example that collects large amount 734 of information about the current state of the grid over wide area 735 from electric substations as well as power transmission lines. The 736 collected feedback is used for monitoring, controlling and protecting 737 all the sub-systems. 739 7. IANA Considerations 741 There are no IANA considerations related to this document. 743 8. Security Considerations 745 Security considerations are not directly applicable to this document. 746 The use cases will use the security requirements described in the 747 protocol specifications. 749 9. Acknowledgements 751 Carles Gomez has been funded in part by the Spanish Government 752 through the Jose Castillejo CAS15/00336 grant, and through the 753 TEC2016-79988-P grant. His contribution to this work has been 754 carried out in part during his stay as a visiting scholar at the 755 Computer Laboratory of the University of Cambridge. 757 Thomas Watteyne, Pascal Thubert, Xavier Vilajosana, Daniel Migault, 758 and Jianqiang HOU have provided valuable feedback for this draft. 760 Das Subir and Michel Veillette have provided valuable information of 761 jupiterMesh and Paul Duffy has provided valuable information of Wi- 762 SUN for this draft. Also, Jianqiang Hou has provided valuable 763 information of G3-PLC and Netricity for this draft. Kerry Lynn and 764 Dave Robin have provided valuable information of MS/TP and practical 765 use case of MS/TP for this draft. 767 Deoknyong Ko has provided relevant text of LTE-MTC and he shared his 768 experience to deploy IPv6 and 6lo technologies over LTE MTC in SK 769 Telecom. 771 10. References 773 10.1. Normative References 775 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 776 Requirement Levels", BCP 14, RFC 2119, 777 DOI 10.17487/RFC2119, March 1997, 778 . 780 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 781 over Low-Power Wireless Personal Area Networks (6LoWPANs): 782 Overview, Assumptions, Problem Statement, and Goals", 783 RFC 4919, DOI 10.17487/RFC4919, August 2007, 784 . 786 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 787 "Transmission of IPv6 Packets over IEEE 802.15.4 788 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 789 . 791 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 792 Routing Requirements in Low-Power and Lossy Networks", 793 RFC 5826, DOI 10.17487/RFC5826, April 2010, 794 . 796 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 797 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 798 DOI 10.17487/RFC6282, September 2011, 799 . 801 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 802 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 803 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 804 Low-Power and Lossy Networks", RFC 6550, 805 DOI 10.17487/RFC6550, March 2012, 806 . 808 [RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and 809 Application Spaces for IPv6 over Low-Power Wireless 810 Personal Area Networks (6LoWPANs)", RFC 6568, 811 DOI 10.17487/RFC6568, April 2012, 812 . 814 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 815 Bormann, "Neighbor Discovery Optimization for IPv6 over 816 Low-Power Wireless Personal Area Networks (6LoWPANs)", 817 RFC 6775, DOI 10.17487/RFC6775, November 2012, 818 . 820 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 821 Constrained-Node Networks", RFC 7228, 822 DOI 10.17487/RFC7228, May 2014, 823 . 825 [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for 826 IPv6 over Low-Power Wireless Personal Area Networks 827 (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 828 2014, . 830 [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets 831 over ITU-T G.9959 Networks", RFC 7428, 832 DOI 10.17487/RFC7428, February 2015, 833 . 835 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 836 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 837 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 838 . 840 [RFC8036] Cam-Winget, N., Ed., Hui, J., and D. Popa, "Applicability 841 Statement for the Routing Protocol for Low-Power and Lossy 842 Networks (RPL) in Advanced Metering Infrastructure (AMI) 843 Networks", RFC 8036, DOI 10.17487/RFC8036, January 2017, 844 . 846 [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- 847 Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, 848 February 2017, . 850 [RFC8066] Chakrabarti, S., Montenegro, G., Droms, R., and J. 851 Woodyatt, "IPv6 over Low-Power Wireless Personal Area 852 Network (6LoWPAN) ESC Dispatch Code Points and 853 Guidelines", RFC 8066, DOI 10.17487/RFC8066, February 854 2017, . 856 [RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt, 857 M., and D. Barthel, "Transmission of IPv6 Packets over 858 Digital Enhanced Cordless Telecommunications (DECT) Ultra 859 Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May 860 2017, . 862 [RFC8163] Lynn, K., Ed., Martocci, J., Neilson, C., and S. 863 Donaldson, "Transmission of IPv6 over Master-Slave/Token- 864 Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163, 865 May 2017, . 867 [RFC8352] Gomez, C., Kovatsch, M., Tian, H., and Z. Cao, Ed., 868 "Energy-Efficient Features of Internet of Things 869 Protocols", RFC 8352, DOI 10.17487/RFC8352, April 2018, 870 . 872 10.2. Informative References 874 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 875 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 876 DOI 10.17487/RFC4861, September 2007, 877 . 879 [I-D.ietf-6lo-nfc] 880 Choi, Y., Hong, Y., Youn, J., Kim, D., and J. Choi, 881 "Transmission of IPv6 Packets over Near Field 882 Communication", draft-ietf-6lo-nfc-15 (work in progress), 883 July 2019. 885 [I-D.ietf-6lo-blemesh] 886 Gomez, C., Darroudi, S., Savolainen, T., and M. Spoerk, 887 "IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP", 888 draft-ietf-6lo-blemesh-05 (work in progress), March 2019. 890 [I-D.ietf-6lo-plc] 891 Hou, J., Liu, B., Hong, Y., Tang, X., and C. Perkins, 892 "Transmission of IPv6 Packets over PLC Networks", draft- 893 ietf-6lo-plc-00 (work in progress), February 2019. 895 [IETF_6lo] 896 "IETF IPv6 over Networks of Resource-constrained Nodes 897 (6lo) working group", 898 . 900 [TIA-485-A] 901 "TIA, "Electrical Characteristics of Generators and 902 Receivers for Use in Balanced Digital Multipoint Systems", 903 TIA-485-A (Revision of TIA-485)", March 2003, 904 . 907 [G3-PLC] "G3-PLC Alliance", . 909 [NETRICITY] 910 "Netricity program in HomePlug Powerline Alliance", 911 . 913 [G.9959] "International Telecommunication Union, "Short range 914 narrow-band digital radiocommunication transceivers - PHY 915 and MAC layer specifications", ITU-T Recommendation", 916 January 2015. 918 [G.9903] "International Telecommunication Union, "Narrowband 919 orthogonal frequency division multiplexing power line 920 communication transceivers for G3-PLC networks", ITU-T 921 Recommendation", August 2017. 923 [IEEE1901] 924 "IEEE Standard, IEEE Std. 1901-2010 - IEEE Standard for 925 Broadband over Power Line Networks: Medium Access Control 926 and Physical Layer Specifications", 2010, 927 . 930 [IEEE1901.2] 931 "IEEE Standard, IEEE Std. 1901.2-2013 - IEEE Standard for 932 Low-Frequency (less than 500 kHz) Narrowband Power Line 933 Communications for Smart Grid Applications", 2013, 934 . 937 [BACnet] "ASHRAE, "BACnet-A Data Communication Protocol for 938 Building Automation and Control Networks", ANSI/ASHRAE 939 Standard 135-2016", January 2016, 940 . 943 Appendix A. Design Space Dimensions for 6lo Deployment 945 The [RFC6568] lists the dimensions used to describe the design space 946 of wireless sensor networks in the context of the 6LoWPAN working 947 group. The design space is already limited by the unique 948 characteristics of a LoWPAN (e.g. low power, short range, low bit 949 rate). In [RFC6568], the following design space dimensions are 950 described: Deployment, Network size, Power source, Connectivity, 951 Multi-hop communication, Traffic pattern, Mobility, Quality of 952 Service (QoS). However, in this document, the following design space 953 dimensions are considered: 955 o Deployment/Bootstrapping: 6lo nodes can be connected randomly, or 956 in an organized manner. The bootstrapping has different 957 characteristics for each link layer technology. 959 o Topology: Topology of 6lo networks may inherently follow the 960 characteristics of each link layer technology. Point-to-point, 961 star, tree or mesh topologies can be configured, depending on the 962 link layer technology considered. 964 o L2-Mesh or L3-Mesh: L2-mesh and L3-mesh may inherently follow the 965 characteristics of each link layer technology. Some link layer 966 technologies may support L2-mesh and some may not support. 968 o Multi-link subnet, single subnet: The selection of multi-link 969 subnet and single subnet depends on connectivity and the number of 970 6lo nodes. 972 o Data rate: Typically, the link layer technologies of 6lo have low 973 rate of data transmission. But, by adjusting the MTU, it can 974 deliver higher upper layer data rate. 976 o Buffering requirements: Some 6lo use case may require more data 977 rate than the link layer technology support. In this case, a 978 buffering mechanism to manage the data is required. 980 o Security and Privacy Requirements: Some 6lo use case can involve 981 transferring some important and personal data between 6lo nodes. 982 In this case, high-level security support is required. 984 o Mobility across 6lo networks and subnets: The movement of 6lo 985 nodes depends on the 6lo use case. If the 6lo nodes can move or 986 moved around, a mobility management mechanism is required. 988 o Time synchronization requirements: The requirement of time 989 synchronization of the upper layer service is dependent on the 6lo 990 use case. For some 6lo use case related to health service, the 991 measured data must be recorded with exact time and must be 992 transferred with time synchronization. 994 o Reliability and QoS: Some 6lo use case requires high reliability, 995 for example real-time service or health-related services. 997 o Traffic patterns: 6lo use cases may involve various traffic 998 patterns. For example, some 6lo use case may require short data 999 length and random transmission. Some 6lo use case may require 1000 continuous data and periodic data transmission. 1002 o Security Bootstrapping: Without the external operations, 6lo nodes 1003 must have the security bootstrapping mechanism. 1005 o Power use strategy: to enable certain use cases, there may be 1006 requirements on the class of energy availability and the strategy 1007 followed for using power for communication [RFC7228]. Each link 1008 layer technology defines a particular power use strategy which may 1009 be tuned [RFC8352]. Readers are expected to be familiar with 1010 [RFC7228] terminology. 1012 o Update firmware requirements: Most 6lo use cases will need a 1013 mechanism for updating firmware. In these cases support for over 1014 the air updates are required, probably in a broadcast mode when 1015 bandwith is low and the number of identical devices is high. 1017 o Wired vs. Wireless: Plenty of 6lo link layer technologies are 1018 wireless, except MS/TP and PLC. The selection of wired or 1019 wireless link layer technology is mainly dependent on the 1020 requirement of 6lo use cases and the characteristics of wired/ 1021 wireless technologies. For example, some 6lo use cases may 1022 require easy and quick deployment, whereas others may need a 1023 continuous source of power. 1025 Authors' Addresses 1027 Yong-Geun Hong 1028 ETRI 1029 161 Gajeong-Dong Yuseung-Gu 1030 Daejeon 305-700 1031 Korea 1033 Phone: +82 42 860 6557 1034 Email: yghong@etri.re.kr 1036 Carles Gomez 1037 Universitat Politecnica de Catalunya/Fundacio i2cat 1038 C/Esteve Terradas, 7 1039 Castelldefels 08860 1040 Spain 1042 Email: carlesgo@entel.upc.edu 1043 Younghwan Choi 1044 ETRI 1045 218 Gajeongno, Yuseong 1046 Daejeon 305-700 1047 Korea 1049 Phone: +82 42 860 1429 1050 Email: yhc@etri.re.kr 1052 Abdur Rashid Sangi 1053 Huaiyin Institute of Technology 1054 No.89 North Beijing Road, Qinghe District 1055 Huaian 223001 1056 P.R. China 1058 Email: sangi_bahrian@yahoo.com 1060 Take Aanstoot 1061 Modio AB 1062 S:t Larsgatan 15, 582 24 1063 Linkoping 1064 Sweden 1066 Email: take@modio.se 1068 Samita Chakrabarti 1069 San Jose, CA 1070 USA 1072 Email: samitac.ietf@gmail.com