Jump to content

6LoWPAN

From Wikipedia, the free encyclopedia
(Redirected from 6loWPAN)

6LoWPAN (acronym of "IPv6 over Low-Power Wireless Personal Area Networks")[1] was a working group of the Internet Engineering Task Force (IETF).[2] It was created with the intention of applying the Internet Protocol (IP) even to the smallest devices,[3] enabling low-power devices with limited processing capabilities to participate in the Internet of Things.[1]

The 6LoWPAN group defined encapsulation, header compression, neighbor discovery and other mechanisms that allow IPv6 to operate over IEEE 802.15.4 based networks. Although IPv4 and IPv6 protocols do not generally care about the physical and MAC layers they operate over, the low-power devices and small packet size defined by IEEE 802.15.4 make it desirable to adapt to these layers.[4]

The base specification developed by the 6LoWPAN IETF group is RFC 4944 (updated by RFC 6282 with header compression, RFC 6775 with neighbor discovery optimization, RFC 8931 with selective fragment recovery and with smaller changes in RFC 8025 and RFC 8066). The problem statement document is RFC 4919. IPv6 over Bluetooth Low Energy using 6LoWPAN techniques is described in RFC 7668.

Application areas

[edit]

The targets for IPv6 networking for low-power radio communication are devices that need wireless connectivity to many other devices at lower data rates for devices with very limited power consumption. The header compression mechanisms in RFC 6282 are used to allow IPv6 packets to travel over such networks.

IPv6 is also in use on the smart grid enabling smart meters and other devices to build a micro mesh network before sending the data back to the billing system using the IPv6 backbone. Some of these networks run over IEEE 802.15.4 radios, and therefore use the header compression and fragmentation as specified by RFC6282.[citation needed]

Thread

[edit]

Thread is a standard from a group of more than fifty companies for a protocol running over 6LoWPAN to enable home automation. The specification is available at no cost as of 24 June 2022, but paid membership is required to implement the protocol.[5][6] Version 1.0 of the specification was published on 2015-10-29.[5] The protocol will most directly compete with Z-Wave and Zigbee IP.[7] In IoT device communications using the Matter standard, Thread is one of two possible wireless transport layers.

Functions

[edit]

As with all link-layer mappings of IP, RFC4944 provides a number of functions. Beyond the usual differences between L2 and L3 networks, mapping from the IPv6 network to the IEEE 802.15.4 network poses additional design challenges (see RFC 4919 for an overview).

Adapting the packet sizes of the two networks

[edit]

IPv6 requires the link maximum transmission unit (MTU) to be at least 1280 octets.[8] In contrast, IEEE 802.15.4's standard frame size is 127 octets. A maximum frame overhead of 25 octets and an optional but highly recommended security feature at the link layer poses an additional overhead of up to 21 octets are for AES-CCM-128. This leaves only 81 octets for the upper layers. Since this is so much less than 1280, 6LowPAN defines a fragmentation and reassembly layer. Further, the standard IPv6 Header is 40 octets long, so header compression is defined as well.

Address resolution

[edit]

IPv6 nodes are assigned 128 bit IP addresses in a hierarchical manner, through an arbitrary length network prefix. IEEE 802.15.4 devices may use either of IEEE 64 bit extended addresses or, after an association event, 16 bit addresses that are unique within a PAN. There is also a PAN-ID for a group of physically collocated IEEE 802.15.4 devices.

Differing device designs

[edit]

IEEE 802.15.4 devices are intentionally constrained in form factor to reduce costs (allowing for large-scale network of many devices), reduce power consumption (allowing battery powered devices) and allow flexibility of installation (e.g. small devices for body-worn networks). On the other hand, wired nodes in the IP domain are not constrained in this way; they can be larger and make use of mains power supplies.

Differing focus on parameter optimization

[edit]

IPv6 nodes are geared towards attaining high speeds. Algorithms and protocols implemented at the higher layers such as TCP kernel of the TCP/IP are optimized to handle typical network problems such as congestion. In IEEE 802.15.4-compliant devices, energy conservation and code-size optimization remain at the top of the agenda.

Adaptation layer for interoperability and packet formats

[edit]

An adaptation mechanism to allow interoperability between IPv6 domain and the IEEE 802.15.4 can best be viewed as a layer problem. Identifying the functionality of this layer and defining newer packet formats, if needed, is an enticing research area. RFC 4944 proposes an adaptation layer to allow the transmission of IPv6 datagrams over IEEE 802.15.4 networks.

Addressing management mechanisms

[edit]

The management of addresses for devices that communicate across the two dissimilar domains of IPv6 and IEEE 802.15.4 is cumbersome, if not exhaustingly complex.

Routing considerations and protocols for mesh topologies in 6LoWPAN

[edit]

Routing per se is a two phased problem that is being considered for low-power IP networking:

  • Mesh routing in the personal area network (PAN) space.
  • The routability of packets between the IPv6 domain and the PAN domain.

Several routing protocols have been proposed by the 6LoWPAN community such as LOAD,[9] DYMO-LOW,[10] HI-LOW.[11] However, only two routing protocols are currently legitimate for large-scale deployments: LOADng[12] standardized by the ITU under the recommendation ITU-T G.9903 and RPL[13] standardized by the IETF ROLL working group.[14]

Device and service discovery

[edit]

Since IP-enabled devices may require the formation of ad hoc networks, the current state of neighboring devices and the services hosted by such devices will need to be known. IPv6 neighbour discovery extensions is an internet draft proposed as a contribution in this area.

Security

[edit]

IEEE 802.15.4 nodes can operate in either secure mode or non-secure mode. Two security modes are defined in the specification in order to achieve different security objectives: Access Control List (ACL) and Secure mode[15]

See also

[edit]

References

[edit]
  1. ^ a b Zach Shelby and Carsten Bormann (2011-05-23). "6LoWPAN: The wireless embedded Internet – Part 1: Why 6LoWPAN?". eetimes. John Wiley & Sons, Ltd. Retrieved 2022-06-24. in '6LoWPAN: The Embedded Internet', Shelby and Bormann redefine the 6LoWPAN acronym as "IPv6 over lowpower wireless area networks," arguing that "Personal" is no longer relevant to the technology.
  2. ^ "IPv6 over Low power WPAN (6lowpan)". IETF. Retrieved 10 May 2016.
  3. ^ Mulligan, Geoff, "The 6LoWPAN architecture", EmNets '07: Proceedings of the 4th workshop on Embedded networked sensors, ACM, 2007
  4. ^ Kushalnagar, N.; Intel Corp; Montenegro, G.; Microsoft Corporation; Schumacher, C.; Danfoss A/S (August 2007). "Problems". IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals. IETF. doi:10.17487/RFC4919. RFC 4919. Retrieved 2022-06-24.
  5. ^ a b "Thread 1.1 Specification Request Form". Thread Group. Retrieved 2022-06-24.
  6. ^ "Thread Membership Benefits". Thread Group. Retrieved 2022-06-24.
  7. ^ Sullivan, Mark (15 July 2014). "Nest, Samsung, ARM and others launch 'Thread' home automation network protocol". venturebeat.com. venture beat. Retrieved 30 January 2015.
  8. ^ Deering, A.; Cisco; Hinden, R.; Nokia (December 1998). "Packet Size Issues". IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals. IETF. doi:10.17487/RFC2460. RFC 2460. Retrieved 2022-06-24. IPv6 requires that every link in the internet have an MTU of 1280 octets or greater.
  9. ^ Kim, K.; Daniel Park, S.; Montenegro, G.; Yoo, S.; Kushalnagar, N. (June 2007). 6LoWPAN Ad Hoc On-Demand Distance Vector Routing (LOAD). IETF. I-D draft-daniel-6lowpan-load-adhoc-routing-03. Retrieved 10 May 2016.
  10. ^ Kim, K.; Montenegro, G.; Park, S.; Chakeres, I.; Perkins, C. (June 2007). Dynamic MANET On-demand for 6LoWPAN (DYMO-low) Routing. IETF. I-D draft-montenegro-6lowpan-dymo-low-routing-03. Retrieved 10 May 2016.
  11. ^ Kim, K.; Yoo, S.; Daniel Park, S.; Lee, J.; Mulligan, G. (June 2007). Hierarchical Routing over 6LoWPAN (HiLow). IETF. I-D draft-daniel-6lowpan-hilow-hierarchical-routing-01. Retrieved 10 May 2016.
  12. ^ Clausen, T.; Colin de Verdiere, A.; Yi, J.; Niktash, A.; Igarashi, Y.; Satoh, H.; Herberg, U.; Lavenu, C.; Lys, T.; Dean, J. (January 2016). The Lightweight On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng). IETF. I-D draft-clausen-lln-loadng-14. Retrieved 10 May 2016.
  13. ^ Winter, T.; Thubert, P.; Brandt, A.; Hui, J.; Kelsey, R.; Levis, P.; Pister, K.; Struik, R.; Vasseur, JP.; Alexander, R. (March 2012). RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks. IETF. doi:10.17487/RFC6550. RFC 6550. Retrieved 10 May 2016.
  14. ^ "Routing Over Low power and Lossy networks (roll)". IETF. Retrieved 10 May 2016.
  15. ^ Park, S.; Kim, K.; Haddad, W.; Chakrabarti, S.; Laganier, J. (March 2011). IPv6 over Low Power WPAN Security Analysis. IETF. I-D draft-daniel-6lowpan-security-analysis-05. Retrieved 10 May 2016.

Further reading

[edit]
[edit]
Retrieved from "https://wiki.riteme.site/w/index.php?title=6LoWPAN&oldid=1263049301"