RFC 4919

IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals

📅 published August 2007, from ietf

IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals 🎀

Okay bestie, this is RFC 4919 💖 It's from the Network Working Group, and it's Informational, so it's explaining stuff, not setting a standard. It's dated August 2007 🦋 The authors are N. Kushalnagar (Intel Corp), G. Montenegro (Microsoft Corporation), and C. Schumacher (Danfoss A/S). The title block doesn't list anything it obsoletes or updates ✨

Status of This Memo 📜

This memo gives info to the Internet community. It is not a standard of any kind 🙈 You can distribute it freely, no limits.

Copyright (C) The IETF Trust (2007).

Abstract 🌸

This doc is all about the assumptions, problem statement, and goals for sending IP over IEEE 802.15.4 networks. The goals listed here are just a starting set, so expect more later 💅

Table of Contents 📖

   1. Introduction ....................................................2
   2. Overview ........................................................2
   3. Assumptions .....................................................3
   4. Problems ........................................................4
      4.1. IP Connectivity ............................................4
      4.2. Topologies .................................................5
      4.3. Limited Packet Size ........................................6
      4.4. Limited Configuration and Management .......................6
      4.5. Service Discovery ..........................................6
      4.6. Security ...................................................6
   5. Goals ...........................................................7
   6. Security Considerations .........................................9
   7. Acknowledgements ...............................................10
   8. References .....................................................10
      8.1. Normative References ......................................10
      8.2. Informative References ....................................10

1. Introduction 🧚

Okay so, LoWPANs (low-power wireless personal area networks) are made of devices that follow the IEEE 802.15.4-2003 standard from the IEEE [IEEE802.15.4] 📡 802.15.4 devices are short range, low bit rate, low power, and low cost. Lots of them have limited computing power, memory, and/or energy, which is so relatable ngl 🥺

This doc gives an overview of LoWPANs and explains how they benefit from IP, especially IPv6 🦋 It covers what LoWPANs need from the IP layer and the layers above it, and it spells out the underlying IP assumptions for LoWPANs. It also covers the problems with getting IP communication working with devices in a LoWPAN, and it sets goals to fix them in a prioritized order 📋 Honestly, not every item here may be a task for the IETF, and that's okay 💖 They're written down anyway so you can see the bigger picture. This helps structure the work inside the IETF and helps everyone figure out how to coordinate with outside organizations 🫶

2. Overview 🌈

A LoWPAN is a simple, low-cost network that gives wireless connectivity for apps with limited power and relaxed throughput needs. A LoWPAN usually has devices that team up to connect the physical world to real-world apps, like wireless sensors 🍓 LoWPANs follow the IEEE 802.15.4-2003 standard [IEEE802.15.4] ✨

Here are some of the main characteristics of LoWPANs 💅

  1. Small packet size. The max physical layer packet is 127 bytes, so the max frame size at the media access control layer is 102 octets. Link-layer security adds more overhead. In the worst case (21 octets of overhead for AES-CCM-128, versus 9 and 13 for AES-CCM-32 and AES-CCM-64, respectively), that leaves 81 octets for data packets 😭
  2. Support for both 16-bit short or IEEE 64-bit extended media access control addresses. Both address types are supported 🌸
  3. Low bandwidth. The data rates are 250 kbps, 40 kbps, and 20 kbps for each of the currently defined physical layers (2.4 GHz, 915 MHz, and 868 MHz, respectively) 🐢
  4. Topologies include star and mesh operation. Star and mesh both work 🕸️
  5. Low power. Typically, some or all devices run on batteries 🔋
  6. Low cost. These devices are usually tied to sensors, switches, etc. That drives other stuff like low processing and low memory. The numbers for "low" are left out on purpose, since costs change over time 💸
  7. Large number of devices expected to be deployed during the lifetime of the technology. This number is expected to dwarf the number of deployed personal computers, for example. Like, massive 🤯
  8. Location of the devices is typically not predefined, as they tend to be deployed in an ad-hoc fashion. Also, sometimes the location isn't easy to access. And these devices may move to new locations too 🗺️
  9. Devices within LoWPANs tend to be unreliable due to variety of reasons: uncertain radio connectivity, battery drain, device lockups, physical tampering, etc. Relatable 💀
  10. In many environments, devices connected to a LoWPAN may sleep for long periods of time in order to conserve energy, and are unable to communicate during these sleep periods. So they nap a lot to save power, and they can't chat while they're sleeping 😴

The next sections take all of these characteristics into account when they describe the assumptions, problem statement, and goals for LoWPANs. They pay special attention to 6LoWPANs, which are IPv6-based LoWPAN networks 👑

3. Assumptions 🎀

Since LoWPANs have such small packets, this doc assumes apps usually send small amounts of data 📦 That said, the protocols themselves don't block bulk data transfers, so big sends are still on the table.

LoWPANs, as this doc describes them, are based on IEEE 802.15.4-2003. The spec might change in the future, and that could change some of the requirements above 🔄

A lot of these assumptions come from how limited LoWPAN devices are. As devices get more powerful and use less power, some of those requirements might get a bit more relaxed 🌱

Some LoWPAN devices are expected to be super limited. These are the so-called "Reduced Function Devices" or RFDs 🥹 The more capable "Full Function Devices" (FFDs) will also be around, just in way smaller numbers. FFDs usually have more resources and may be mains powered. So FFDs help RFDs out by doing things like network coordination, packet forwarding, and interfacing with other kinds of networks 🫶

Using IP is assumed to bring these benefits:

  1. The pervasive nature of IP networks lets you use existing infrastructure 🏗️
  2. IP-based technologies already exist, are well-known, and are proven to work ✅
  3. This one is admittedly non-technical but important: IP networking tech is specified in open, freely available specs. That's favorable, or at least easier for a wider audience to understand than proprietary solutions 📖
  4. Tools for diagnostics, management, and commissioning of IP networks already exist 🛠️
  5. IP-based devices can connect easily to other IP-based networks, with no need for in-between stuff like translation gateways or proxies 🙌

4. Problems 🚨

Based on the characteristics from the overview, the following sections go deeper into the main problems with IP for LoWPANs 🔍

4.1. IP Connectivity 🌐

IP connectivity inside a LoWPAN is driven by these things:

  1. There are so many devices in a LoWPAN that network auto configuration and statelessness are highly desirable. And IPv6 already has ready solutions for this 🙏
  2. The large number of devices means you need a large address space, which IPv6 handles well 🌌
  3. Because LoWPAN packets are limited in size, the IPv6 address format lets you subsume IEEE 802.15.4 addresses if you want to 🧩
  4. You get simple interconnectivity to other IP networks, including the Internet 🌍

Still, because packet size is limited, IPv6 headers and the headers of the layers above it must be compressed whenever possible 🗜️

4.2. Topologies 🕸️

LoWPANs must support different topologies, including mesh and star 💖

Mesh topologies mean multi-hop routing to a desired destination. In this case, the in-between devices act as packet forwarders at the link layer, which is kind of like routers at the network layer 🦋 These are usually "full function devices" with more power, computation, etc. The requirements on the routing protocol are:

  1. Packets are super small in LoWPANs, so the routing protocol must impose low (or no) overhead on data packets, hopefully no matter how many hops there are 🐣
  2. Routing protocols should have low routing overhead (low chattiness), balanced against topology changes and power conservation 🤫
  3. The computation and memory requirements in the routing protocol should be minimal, so you can hit the low cost and low power goals. That means storing and maintaining big routing tables is a no-go 🚫
  4. The network has to support topologies where FFDs or RFDs may be battery or mains powered. That means the routing has to handle sleeping nodes properly 😴

Like mesh topologies, star topologies include giving some devices packet forwarding functionality 🌟 If these devices also use other kinds of network interfaces, like ethernet or IEEE 802.11, the goal is to seamlessly integrate the networks built over those different technologies. Honestly, this is a big reason to use IP in the first place 💜

4.3. Limited Packet Size 📦

Apps within LoWPANs are expected to send small packets. Adding all the layers needed for IP connectivity should still let transmission fit in one frame, without causing too much fragmentation and reassembly 🧩 Also, protocols must be designed or chosen so that individual "control/protocol packets" fit within a single 802.15.4 frame. Along these lines, IPv6's requirement for sub-IP reassembly (see Section 5) may be a challenge for low-end LoWPAN devices that don't have enough RAM or storage for a 1280-octet packet 😬

4.4. Limited Configuration and Management ⚙️

As mentioned above, LoWPAN devices are expected to be deployed in super large numbers 🤯 They're also expected to have limited display and input capabilities, and some of them may be hard to reach. So protocols used in LoWPANs should have minimal configuration, ideally work "out of the box", be easy to bootstrap, and let the network self heal, given how unreliable these devices are 🩹 The size constraints of the link layer protocol should be considered too. Network management should have little overhead but still be powerful enough to control dense deployments of devices 🎀

4.5. Service Discovery 🔍✨

okay so LoWPANs need simple service discovery network protocols to discover, control and maintain the services devices provide 🧚 In some cases, especially in dense deployments, abstracting several nodes to provide one service can be super beneficial 💖 To make those features happen, new protocols may have to be designed 💅

4.6. Security 🔐

ngl this one is kind of a mess 😭 IEEE 802.15.4 mandates link-layer security based on AES, but it skips the details on bootstrapping, key management, and security at the higher layers. A complete security solution for LoWPAN devices has to think really carefully about what the applications need 🫶 Check out the Security Considerations section below for the deeper dive and the in-depth security requirements.

5. Goals 🎯

The goals here are general and aren't limited to IETF activities 🌈 So they might point at work that can happen inside the IETF (like the specification needed to transmit IP, a profile of best practices for sending IP packets, and the upper-layer protocols that go with them), but they also point at work that's more relevant to other standards bodies (like changes to or profiles of IEEE 802.15.4, W3C, and so on). When the goals fall under the IETF's purview, they show what those efforts should aim for, whether they happen in one or more new or existing working groups. When they don't fall under the IETF's purview, writing them down here is input for other organizations [LIAISON] 🦋

Note that a common underlying goal is to reduce packet overhead, bandwidth consumption, processing requirements, and power consumption. This is the vibe for everything below 🔋

The following are the goals, in priority order, for LoWPANs:

  1. Fragmentation and Reassembly layer: As mentioned in the overview, the protocol data units may be as small as 81 bytes. That's obviously way below the minimum IPv6 packet size of 1280 octets 😳 So, in keeping with Section 5 of the IPv6 specification [RFC2460], a fragmentation and reassembly adaptation layer must be provided at the layer below IP.
  2. Header Compression: In the worst case, the maximum size available for transmitting IP packets over an IEEE 802.15.4 frame is 81 octets, and the IPv6 header is 40 octets long (without optional headers). That leaves only 41 octets for upper-layer protocols like UDP and TCP. UDP uses 8 octets in the header and TCP uses 20 octets, which leaves 33 octets for data over UDP and 21 octets for data over TCP. On top of that, as pointed out above, there's also a need for a fragmentation and reassembly layer, which uses even more octets and leaves very few for data. So if you used the protocols as-is, you'd get excessive fragmentation and reassembly, even when the data packets are only 10s of octets long 💀 This is why header compression is needed. There's already a lot of published and in-progress standardization work on header compression, so the 6LoWPAN community needs to look into using existing header compression techniques and, if necessary, specify new ones 🧠
  3. Address Autoconfiguration: [6LoWPAN] specifies methods for creating IPv6 stateless address autoconfiguration. Stateless autoconfiguration (compared to stateful) is very attractive for 6LoWPANs, because it cuts down the configuration overhead on the hosts 🙌 There's a need for a method to generate an "interface identifier" from the EUI-64 [EUI64] assigned to the IEEE 802.15.4 device.
  4. Mesh Routing Protocol: A routing protocol that supports a multi-hop mesh network is necessary 🕸️ There's a lot of published work on ad-hoc multi-hop routing for devices. Some examples are [RFC3561], [RFC3626], and [RFC3684], all experimental. The catch is that these protocols are designed to use IP-based addresses, which have large overheads. For example, the Ad hoc On-Demand Distance Vector (AODV) [RFC3561] routing protocol uses 48 octets for a route request based on IPv6 addressing. With the packet-size constraints, sending this packet without fragmentation and reassembly may be difficult 😤 So care should be taken when using existing routing protocols (or designing new ones) so the routing packets fit within a single IEEE 802.15.4 frame.
  5. Network Management: One of the whole points of transmitting IPv6 packets is to reuse existing protocols as much as possible 🔁 Network management is critical for LoWPANs. Still, management solutions need to meet the resource constraints, as well as the minimal configuration and self-healing functionality described in Section 4.4. The Simple Network Management Protocol (SNMP) [RFC3410] is widely used for monitoring data sources and sensors in conventional networks. SNMP functionality may be translated "as is" to LoWPANs, which means you get to use existing tools ✨ However, because of the memory, processing, and message size constraints, further investigation is required to figure out whether SNMPv3 is suitable, or whether an appropriate adaptation of SNMPv3 or a different protocol is in order.
  6. Implementation Considerations: Transmitting IP over IEEE 802.15.4 might become more beneficial if it's implemented in a "certain" way 👀 So implementation considerations are to be documented.
  7. Application and higher layer Considerations: As header compression becomes more prevalent, overall performance will depend even more on how efficient the application protocols are 📈 Heavyweight protocols based on XML, such as SOAP [SOAP], may not be suitable for LoWPANs. That means more compact encodings (and maybe protocols) may become necessary 🍓 The goal here is to specify or suggest modifications to existing protocols so they're suitable for LoWPANs. Application-level interoperability specifications may also become necessary in the future and may be specified then.
  8. Security Considerations: Security threats at different layers must be clearly understood and documented 🛡️ Bootstrapping devices into a secure network could also be considered, given the location, limited display, high density, and ad-hoc deployment of the devices.

6. Security Considerations 🔒

IPv6 over LoWPAN (6LoWPAN) applications often need confidentiality and integrity protection, and this can be provided at the application, transport, network, and/or link layer (that is, within the 6LoWPAN set of specifications) 💜 In all of these cases, the prevailing constraints will influence which protocol gets picked. Some of the most relevant constraints are small code size, low power operation, low complexity, and small bandwidth requirements.

Given those constraints, first a threat model for 6LoWPAN devices needs to be developed. That way the risks can be weighed against the cost of mitigating them, while making meaningful assumptions and simplifications 🧐 Some threats that should be considered are man-in-the-middle attacks and denial of service attacks.

A separate set of security considerations applies to bootstrapping a 6LoWPAN device into the network (for example, for initial key establishment). This generally involves application-level exchanges or out-of-band techniques for the initial key establishment, and it may rely on application-specific trust models. So it's considered extraneous to 6LoWPAN and isn't addressed in these specifications 🙈 To be able to select (or design) this next set of protocols, there needs to be a common model of the keying material created by the initial key establishment.

Beyond initial key establishment, protocols for subsequent key management, as well as for securing the data traffic, do fall under the purview of 6LoWPAN 🚨 Here, the different alternatives (TLS, IKE/IPsec, and so on) must be evaluated in light of the 6LoWPAN constraints.

One argument for using link-layer security is that most IEEE 802.15.4 devices already support AES link-layer security. AES is a block cipher operating on blocks of fixed length, that is, 128 bits. To encrypt longer messages, several modes of operation may be used. The earliest modes described, such as ECB, CBC, OFB and CFB, provide only confidentiality, and that does not ensure message integrity. Other modes have been designed to ensure both confidentiality and message integrity, such as CCM* mode. 6LoWPAN networks can operate in any of the previous modes, but it's desirable to use the most secure modes available for link-layer security (for example, CCM*) and build upon them 🔥

For network-layer security, two models are applicable: end-to-end security, for example using IPsec transport mode, or security that's limited to the wireless portion of the network, for example using a security gateway and IPsec tunnel mode. The disadvantage of the latter is the larger header size, which is significant at the 6LoWPAN frame MTUs 😬 To simplify 6LoWPAN implementations, it's helpful to identify the relevant security model and a preferred set of cipher suites that are appropriate given the constraints.

7. Acknowledgements 🫶

Thanks to Geoff Mulligan, Soohong Daniel Park, Samita Chakrabarti, Brijesh Kumar, and Miguel Garcia for their comments and help in shaping this document 🌸

8. References 📚

8.1. Normative References

  • [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
  • [IEEE802.15.4] IEEE Computer Society, "IEEE Std. 802.15.4-2003", October 2003.

8.2. Informative References

  • [EUI64] "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) REGISTRATION AUTHORITY", IEEE, http://standards.ieee.org/regauth/oui/tutorials/EUI64.html.
  • [6LoWPAN] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", Work in Progress, May 2005.
  • [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
  • [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-Demand Distance Vector (AODV) Routing", RFC 3561, July 2003.
  • [RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing Protocol (OLSR)", RFC 3626, October 2003.
  • [RFC3684] Ogier, R., Templin, F., and M. Lewis, "Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)", RFC 3684, February 2004.
  • [SOAP] "XML Protocol Working Group", W3C, http://www.w3c.org/2000/xp/Group/.
  • [LIAISON] "IETF Liaison Activities", IETF, http://www.ietf.org/liaisonActivities.html.

Authors' Addresses 📮

Nandakishore Kushalnagar
Intel Corp

EMail: nandakishore.kushalnagar@intel.com


Gabriel Montenegro
Microsoft Corporation

EMail: gabriel.montenegro@microsoft.com


Christian Peter Pii Schumacher
Danfoss A/S

EMail: schumacher@danfoss.com

Okay bestie, the legal stuff is last, but it still matters 🫶 The IETF Trust holds the copyright on this one (2007) 📜 This document is subject to the rights, licenses and restrictions in BCP 78 🔒 Except for what BCP 78 sets out, the authors keep all their rights 🦋

The fine print is below, verbatim, because legal text needs to be exact 💅

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🌈

Okay so the IETF is staying neutral here 🙈 It takes no position on whether any IPR or other rights that someone might claim over the tech in this doc are valid or in scope 💅 It also doesn't say whether a license for those rights is available, and it hasn't done any independent digging to find out what rights exist ✨ If you want the procedures for rights in RFC documents, check BCP 78 and BCP 79 🎀

Copies of IPR disclosures sent to the IETF Secretariat are a thing 📬 So are assurances of licenses that might be made available, plus the results of any attempt to get a general license or permission for implementers or users to use the proprietary rights 🔥 All of that lives in the IETF's online IPR repository at http://www.ietf.org/ipr 🧚

The IETF also invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard 🦋 Send it to the IETF at ietf-ipr@ietf.org 💌

Acknowledgement 🫶

Last but not least, the RFC Editor function is currently funded by the Internet Society 🍓 Thank you for sticking with me through all three parts, bestie 😭💜

📦 where this page comes from