Network Working Group C. Gomez Internet-Draft J. Paradells Intended status: Informational UPC/i2CAT Expires: September 22, 2016 J. Crowcroft University of Cambridge March 21, 2016 Analysis of IPv6 over LPWAN: design space and challenges draft-gomez-lpwan-ipv6-analysis-00 Abstract Connecting Low Power Wide Area Networks (LPWANs) to the Internet is expected to provide significant benefits to these networks in terms of interoperability, application deployment, and management, among others. However, the constraints of LPWANs, often more extreme than those of typical 6Lo(WPAN) technologies, constitute a challenge for the 6LoWPAN suite in order to enable IPv6 over LPWAN. Considering the typical characteristics of LPWAN technologies, this document analyzes the design space and challenges related with enabling IPv6 over LPWAN. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 22, 2016. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Gomez, et al. Expires September 22, 2016 [Page 1] Internet-Draft IPv6 over LPWAN analysis March 2016 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Conventions used in this document . . . . . . . . . . . . 3 2. Protocol stack . . . . . . . . . . . . . . . . . . . . . . . 3 3. Network topology and device roles . . . . . . . . . . . . . . 3 4. IPv6 subnet model . . . . . . . . . . . . . . . . . . . . . . 4 5. Address autoconfiguration . . . . . . . . . . . . . . . . . . 4 6. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 5 7. Neighbor discovery . . . . . . . . . . . . . . . . . . . . . 5 8. Header compression . . . . . . . . . . . . . . . . . . . . . 6 9. Unicast and multicast mapping . . . . . . . . . . . . . . . . 7 10. Security Considerations . . . . . . . . . . . . . . . . . . . 7 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 12. Annex A. RFC 6775 message size analysis . . . . . . . . . . . 7 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 13.1. Normative References . . . . . . . . . . . . . . . . . . 8 13.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction Low Power Wide Area Network (LPWAN) technologies define long range, low bit rate and low power wireless interfaces that are used for control and monitoring applications. Examples of LPWAN technologies include LoRa, SigFox, IEEE 802.15.4k LECIM, Weightless, etc. [I-D.minaburo-lp-wan-gap-analysis]. Connecting LPWANs to the Internet is expected to provide significant benefits to these networks in terms of interoperability, application deployment, and management, among others. Therefore, the support of IPv6 over LPWAN is a fundamental aspect to be examined for LPWAN Internet connectivity. Several technologies that exhibit significant constraints in various dimensions have exploited the 6LoWPAN suite of specifications ([RFC4944][RFC6282][RFC6775]) to support IPv6 [I-D.hong-6lo-use-cases]. 6LoWPAN, which was originally designed for IEEE 802.15.4 networks, provides a frame format, address autoconfiguration, fragmentation, header compression, and optimized IPv6 neighbor discovery. Gomez, et al. Expires September 22, 2016 [Page 2] Internet-Draft IPv6 over LPWAN analysis March 2016 However, the constraints of LPWANs, often more extreme than those of typical 6Lo(WPAN) technologies, constitute a challenge for the 6LoWPAN suite in order to enable IPv6 over LPWAN. LPWANs are characterized by device constraints (in terms of processing capacity, memory, and energy availability), and specially, link constraints, such as i) very low layer two payload size (from ~10 to ~100 bytes), ii) very low bit rate (from ~10 bit/s to ~100 kbit/s), and iii) in some specific technologies, further message rate constraints (e.g. between ~0.1 message/minute and ~1 message/minute) due to regional regulations that limit the duty cycle. In some cases the 6LoWPAN functionality may be used to enable IPv6 over specific LPWAN technologies (with the level of adaptation done in the IPv6 over foo documents produced by the IETF 6lo WG), maintaining good performance. However, in the most challenged LPWAN technologies and/or configurations, further optimization and/or tuning of the 6LoWPAN functionality is required for efficient operation. This document analyzes the design space and challenges of enabling IPv6 over LPWAN. 1.1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 2. Protocol stack In the design of an IPv6 over foo adaptation layer, if more than one layer (other than the physical layer) is supported by the target technology, a crucial decision is which lower layer will interface with the adaptation layer. The layer(s) below the adaptation layer must provide the functionality to enable a link, i.e. "a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IP" [RFC4861]. In addition to the above requirement, further aspects to consider in the mentioned decision include lower layer support of fragmentation (see Section 5), overhead, and the ability of multplexing upper layer protocols. 3. Network topology and device roles As of the writing, LPWAN technologies typically follow the star topology, whereby the end devices are connected through a direct link with a central device. In that case, the end devices and the central device will act as 6LoWPAN Nodes (6LN) and 6LoWPAN Border Router Gomez, et al. Expires September 22, 2016 [Page 3] Internet-Draft IPv6 over LPWAN analysis March 2016 (6LBR), respectively. The 6LBR may provide Internet connectivity (see Figure 1). 4. IPv6 subnet model As IPv6 over LPWAN is intended for constrained nodes, and for Internet of Things use cases and environments, the complexity of implementing a separate subnet on each link and routing between the subnets appears to be excessive. For LPWAN, the benefits of treating the collection of links of the network as a single multilink subnet rather than a multiplicity of separate subnets are considered to outweigh the multilink model's drawbacks as described in [RFC4903]. / .---------------. / / 6LN \ / / \ \ / | \ | / | 6LN ----------- 6LBR ----- | Internet | <--Link--> / | \ \ / / \ \ 6LN / \ '---------------' \ \ <------ Subnet -----><-- IPv6 connection --> to Internet Figure 1: LPWAN connected to the Internet In the multilink subnet model, link-local multicast communications can happen only within a single link; thus, 6LN-to-6LN communications using link-local addresses are not possible. 6LNs connected to the same 6LBR have to communicate with each other by using the shared prefix used on the subnet. 5. Address autoconfiguration In the ambit of 6Lo(WPAN) technologies, traditionally, Interface Identifiers (IIDs) have been derived from link layer identifiers [RFC4944] . This allows optimizations such as header compression. Nevertheless, due to privacy concerns, LPWAN devices should not be configured to embed their link layer address in the IID by default (see Section 3.2.2 of [RFC4903], and [I-D.ietf-6man-default-iids]). Gomez, et al. Expires September 22, 2016 [Page 4] Internet-Draft IPv6 over LPWAN analysis March 2016 6. Fragmentation IPv6 requires an MTU of 1280 bytes [RFC2460] . Therefore, given the low maximum payload size of LPWAN technologies, fragmentation is needed. If a layer of an LPWAN technology supports fragmentation, proper analysis has to be carried out to decide whether the fragmentation functionality provided by the lower layer or fragmentation at the adaptation layer should be used. Otherwise, fragmentation functionality shall be used at the adaptation layer. 6LoWPAN defined a fragmentation mechanism and a fragmentation header to support the transmission of IPv6 packets over IEEE 802.15.4 networks [RFC4944] . While the 6LoWPAN fragmentation header is appropriate for IEEE 802.15.4-2003 (which has a frame payload size of 81-102 bytes), it is not suitable for several LPWAN technologies, many of which have a maximum payload size that is one order of magnitude below that of IEEE 802.15.4-2003. The overhead of the 6LoWPAN fragmentation header is high, considering the reduced payload size of LPWAN technologies and the limited energy availability of the devices using such technologies. Furthermore, its datagram offset field is expressed in increments of eight octets. In some LPWAN technologies, the 6LoWPAN fragmentation header plus eight octets from the original datagram exceeds the available space in the layer two payload. To overcome these limitations, an optimized 6LoWPAN fragmentation header for LPWAN has been defined in [I-D.gomez-lpwan-fragmentation-header]. 7. Neighbor discovery 6LoWPAN Neighbor Discovery [RFC6775] defined optimizations to IPv6 Neighbor Discovery [RFC4861] , in order to adapt functionality of the latter for networks of devices using IEEE 802.15.4 or similar technologies. The optimizations comprise host-initiated interactions to allow for sleeping hosts, replacement of multicast-based address resolution for hosts by an address registration mechanism, multihop extensions for prefix distribution and duplicate address detection (note that these are not needed in a star topology network), and support for 6LoWPAN header compression. 6LoWPAN Neighor Discovery may be used in LPWAN networks. However, the relative overhead incurred will depend on the LPWAN technology used (and on its configuration, if appropriate). In certain LPWAN setups (with a maximum payload size above ~60 bytes, and duty-cycle- free or equivalent operation), an RS/RA/NS/NA exchange may be completed in a few seconds, without incurring packet fragmentation. In others (with a maximum payload size of ~10 bytes, and a message Gomez, et al. Expires September 22, 2016 [Page 5] Internet-Draft IPv6 over LPWAN analysis March 2016 rate of ~0.1 message/minute), the same exchange may take a few hours, leading to severe fragmentation and consuming a significant amount of the available network resources. See Annex A for an analysis of the 6LoWPAN Neighbor Discovery message sizes. 6LoWPAN Neighbor Discovery behavior may be tuned through the use of appropriate values for the default Router Lifetime, the Valid Lifetime in the PIOs, and the Valid Lifetime in the 6CO, as well as the address Registration Lifetime. The Router Lifetime, which is present in RAs, may be as high as 18.2 hours. The Valid Lifetime in the PIO indicates the time of validity of the prefix indicated in the PIO, and it is possible to encode a value of infinity for this lifetime. The Valid Lifetime in the 6CO, which indicates the time of validity of the related context for header compression, may be as high as 45 days. A 6LN should unicast an RS to the router before expiration of any of these lifetimes. On the other hand, the address Registration Lifetime determines the periodicity with which a 6LN has to perform address reregistration with the router, and may be as high as 45 days. Therefore, 6LoWPAN Neighbor Discovery supports relatively high periods without generating messages (the shortest being the maximum Router Lifetime). However, there exists a trade-off between Neighbor Discovery message overhead and reactivity to network changes (potentially affecting network connectivity) that must be assessed. On the other hand, the most challenged LPWAN setups may require the definition of functionality beyond the limits of [RFC6775]. 8. Header compression [RFC6282] defines stateless and stateful header compression for 6LoWPAN networks. This functionality is highly required in LPWAN, given the extreme resource constraints of these networks. [RFC6282] defines a two-byte base encoding. To enable context-based compression of global addresses, a further byte is needed to encode source and destination context. Such compression may cover prefixes or complete, 128-bit IPv6 addresses. In the most minimalistic case, assuming that the IPv6 header fields allow the maximum possible degree of compression, an IPv6 header comprising global IPv6 addresses may be compressed to a size of 3 bytes. Contexts may be disseminated by using the 6CO in RA messages. Up to 16 contexts may be defined. However, note that each 6CO for a full IPv6 address context adds 24 bytes to the RA message (Annex A), which incurs an amount of overhead which is not negligible for certain LPWAN setups. Gomez, et al. Expires September 22, 2016 [Page 6] Internet-Draft IPv6 over LPWAN analysis March 2016 If the network follows the star topology, optimizations for header compression that leverage this type of network topology may be used (see section 3.2.4 of [RFC7668]). 9. Unicast and multicast mapping In some LPWAN technologies, layer two multicast is not supported. In that case, if the network topology is a star, the solution and considerations of section 3.2.5 of [RFC7668] may be applied. 10. Security Considerations TBD 11. Acknowledgments In section 4, the authors have reused part of the content available in section 3.2.1 of RFC 7668, and would like to thank the authors of that specification. Carles Gomez has been funded in part by the Spanish Government (Ministerio de Educacion, Cultura y Deporte) through the Jose Castillejo grant CAS15/00336. His contribution to this work has been carried out during his stay as a visiting scholar at the Computer Laboratory of the University of Cambridge. 12. Annex A. RFC 6775 message size analysis -- Router Solicitation (RS), without options: 8 bytes -- Router Advertisement (RA), without options: 16 bytes -- Neighbor Solicitation (NS), without options: 24 bytes -- Neighbor Advertisement (NA), without options: 24 bytes -- Source Link-Layer Address Option (SLLAO): 2 bytes + link layer address size (bytes) -- Prefix Information Option (PIO): 16 bytes + prefix size (bytes) -- 6LoWPAN Context Option (6CO): 8 bytes + context prefix size (bytes) -- Address Registration Option (ARO): 16 bytes For the following calculations, a Link Layer Address (LLA) of 4 bytes, a prefix of 8 bytes, and a context prefix of 16 bytes (for Gomez, et al. Expires September 22, 2016 [Page 7] Internet-Draft IPv6 over LPWAN analysis March 2016 maximum compression) have been assumed. A single 6CO is assumed, as a minimalistic use of header compression. (Note: the Authoritative Border Router Option (ABRO) will not be present in networks that follow the star topology.) Message sizes: -- Size of RS with SLLAO = 14 bytes -- Size of RA with SLLAO, PIO and 6CO = 62 bytes -- Size of NS with ARO and SLLAO = 46 bytes -- Size of NA + ARO = 40 bytes 13. References 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, . [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, . [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, DOI 10.17487/RFC4903, June 2007, . [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, . [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011, . Gomez, et al. Expires September 22, 2016 [Page 8] Internet-Draft IPv6 over LPWAN analysis March 2016 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012, . [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, . 13.2. Informative References [I-D.gomez-lpwan-fragmentation-header] Gomez, C., Paradells, J., and J. Crowcroft, "Optimized 6LoWPAN Fragmentation Header for LPWAN", draft-gomez- lpwan-fragmentation-header-01 (work in progress), March 2016. [I-D.hong-6lo-use-cases] Hong, Y. and C. Gomez, "Use cases for IPv6 over Networks of Resource-constrained Nodes", draft-hong-6lo-use- cases-01 (work in progress), March 2016. [I-D.ietf-6man-default-iids] Gont, F., Cooper, A., Thaler, D., and S. LIU, "Recommendation on Stable IPv6 Interface Identifiers", draft-ietf-6man-default-iids-10 (work in progress), February 2016. [I-D.minaburo-lp-wan-gap-analysis] Minaburo, A., Pelov, A., and L. Toutain, "LP-WAN GAP Analysis", draft-minaburo-lp-wan-gap-analysis-01 (work in progress), February 2016. Authors' Addresses Carles Gomez UPC/i2CAT C/Esteve Terradas, 7 Castelldefels 08860 Spain Email: carlesgo@entel.upc.edu Gomez, et al. Expires September 22, 2016 [Page 9] Internet-Draft IPv6 over LPWAN analysis March 2016 Josep Paradells UPC/i2CAT C/Jordi Girona, 1-3 Barcelona 08034 Spain Email: josep.paradells@entel.upc.edu Jon Crowcroft University of Cambridge JJ Thomson Avenue Cambridge, CB3 0FD United Kingdom Email: jon.crowcroft@cl.cam.ac.uk Gomez, et al. Expires September 22, 2016 [Page 10]