GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4919

Network Working Group N. Kushalnagar Request for Comments: 4919 Intel Corp Category: Informational G. Montenegro

                                                 Microsoft Corporation
                                                         C. Schumacher
                                                           Danfoss A/S
                                                           August 2007
  IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):
        Overview, Assumptions, Problem Statement, and Goals

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The IETF Trust (2007).

Abstract

 This document describes the assumptions, problem statement, and goals
 for transmitting IP over IEEE 802.15.4 networks.  The set of goals
 enumerated in this document form an initial set only.

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

Kushalnagar, et al. Informational [Page 1] RFC 4919 6LoWPAN Problems and Goals August 2007

1. Introduction

 Low-power wireless personal area networks (LoWPANs) comprise devices
 that conform to the IEEE 802.15.4-2003 standard by the IEEE
 [IEEE802.15.4].  IEEE 802.15.4 devices are characterized by short
 range, low bit rate, low power, and low cost.  Many of the devices
 employing IEEE 802.15.4 radios will be limited in their computational
 power, memory, and/or energy availability.
 This document gives an overview of LoWPANs and describes how they
 benefit from IP and, in particular, IPv6 networking.  It describes
 LoWPAN requirements with regards to the IP layer and the above, and
 spells out the underlying assumptions of IP for LoWPANs.  Finally, it
 describes problems associated with enabling IP communication with
 devices in a LoWPAN, and defines goals to address these in a
 prioritized manner.  Admittedly, not all items on this list may be
 necessarily appropriate tasks for the IETF.  Nevertheless, they are
 documented here to give a general overview of the larger problem.
 This is useful both to structure work within the IETF as well as to
 better understand how to coordinate with external organizations.

2. Overview

 A LoWPAN is a simple low cost communication network that allows
 wireless connectivity in applications with limited power and relaxed
 throughput requirements.  A LoWPAN typically includes devices that
 work together to connect the physical environment to real-world
 applications, e.g., wireless sensors.  LoWPANs conform to the IEEE
 802.15.4-2003 standard [IEEE802.15.4].
 Some of the characteristics of LoWPANs are as follows:
 1.   Small packet size.  Given that the maximum physical layer packet
      is 127 bytes, the resulting maximum frame size at the media
      access control layer is 102 octets.  Link-layer security imposes
      further overhead, which in the maximum case (21 octets of
      overhead in the AES-CCM-128 case, versus 9 and 13 for AES-CCM-32
      and AES-CCM-64, respectively), leaves 81 octets for data
      packets.
 2.   Support for both 16-bit short or IEEE 64-bit extended media
      access control addresses.
 3.   Low bandwidth.  Data rates of 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.

Kushalnagar, et al. Informational [Page 2] RFC 4919 6LoWPAN Problems and Goals August 2007

 5.   Low power.  Typically, some or all devices are battery operated.
 6.   Low cost.  These devices are typically associated with sensors,
      switches, etc.  This drives some of the other characteristics
      such as low processing, low memory, etc.  Numerical values for
      "low" elided on purpose since costs tend to 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.
 8.   Location of the devices is typically not predefined, as they
      tend to be deployed in an ad-hoc fashion.  Furthermore,
      sometimes the location of these devices may not be easily
      accessible.  Additionally, these devices may move to new
      locations.
 9.   Devices within LoWPANs tend to be unreliable due to variety of
      reasons: uncertain radio connectivity, battery drain, device
      lockups, physical tampering, etc.
 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.
 The following sections take into account these characteristics in
 describing the assumptions, problems statement, and goals for
 LoWPANs, and, in particular, for 6LoWPANs (IPv6-based LoWPAN
 networks).

3. Assumptions

 Given the small packet size of LoWPANs, this document presumes
 applications typically send small amounts of data.  However, the
 protocols themselves do not restrict bulk data transfers.
 LoWPANs, as described in this document, are based on IEEE
 802.15.4-2003.  It is possible that the specification may undergo
 changes in the future and may change some of the requirements
 mentioned above.
 Some of these assumptions are based on the limited capabilities of
 devices within LoWPANs.  As devices become more powerful, and consume
 less power, some of the requirements mentioned above may be somewhat
 relaxed.

Kushalnagar, et al. Informational [Page 3] RFC 4919 6LoWPAN Problems and Goals August 2007

 While some LoWPAN devices are expected to be extremely limited (the
 so-called "Reduced Function Devices" or RFDs), more capable "Full
 Function Devices" (FFDs) will also be present, albeit in much smaller
 numbers.  FFDs will typically have more resources and may be mains
 powered.  Accordingly, FFDs will aid RFDs by providing functions such
 as network coordination, packet forwarding, interfacing with other
 types of networks, etc.
 The application of IP technology is assumed to provide the following
 benefits:
 1.  The pervasive nature of IP networks allows use of existing
     infrastructure.
 2.  IP-based technologies already exist, are well-known, and proven
     to be working.
 3.  An admittedly non-technical but important consideration is that
     IP networking technology is specified in open and freely
     available specifications, which is favorable or at least able to
     be better understood by a wider audience than proprietary
     solutions.
 4.  Tools for diagnostics, management, and commissioning of IP
     networks already exist.
 5.  IP-based devices can be connected readily to other IP-based
     networks, without the need for intermediate entities like
     translation gateways or proxies.

4. Problems

 Based on the characteristics defined in the overview section, the
 following sections elaborate on the main problems with IP for
 LoWPANs.

4.1. IP Connectivity

 The requirement for IP connectivity within a LoWPAN is driven by the
 following:
 1.  The many devices in a LoWPAN make network auto configuration and
     statelessness highly desirable.  And for this, IPv6 has ready
     solutions.
 2.  The large number of devices poses the need for a large address
     space, well met by IPv6.

Kushalnagar, et al. Informational [Page 4] RFC 4919 6LoWPAN Problems and Goals August 2007

 3.  Given the limited packet size of LoWPANs, the IPv6 address format
     allows subsuming of IEEE 802.15.4 addresses if so desired.
 4.  Simple interconnectivity to other IP networks including the
     Internet.
 However, given the limited packet size, headers for IPv6 and layers
 above must be compressed whenever possible.

4.2. Topologies

 LoWPANs must support various topologies including mesh and star.
 Mesh topologies imply multi-hop routing, to a desired destination.
 In this case, intermediate devices act as packet forwarders at the
 link layer (akin to routers at the network layer).  Typically these
 are "full function devices" that have more capabilities in terms of
 power, computation, etc.  The requirements on the routing protocol
 are:
 1.  Given the minimal packet size of LoWPANs, the routing protocol
     must impose low (or no) overhead on data packets, hopefully
     independently of the number of hops.
 2.  The routing protocols should have low routing overhead (low
     chattiness) balanced with topology changes and power
     conservation.
 3.  The computation and memory requirements in the routing protocol
     should be minimal to satisfy the low cost and low power
     objectives.  Thus, storage and maintenance of large routing
     tables is detrimental.
 4.  Support for network topologies in which either FFDs or RFDs may
     be battery or mains-powered.  This implies the appropriate
     considerations for routing in the presence of sleeping nodes.
 As with mesh topologies, star topologies include provisioning a
 subset of devices with packet forwarding functionality.  If, in
 addition to IEEE 802.15.4, these devices use other kinds of network
 interfaces such as ethernet or IEEE 802.11, the goal is to seamlessly
 integrate the networks built over those different technologies.
 This, of course, is a primary motivation to use IP to begin with.

Kushalnagar, et al. Informational [Page 5] RFC 4919 6LoWPAN Problems and Goals August 2007

4.3. Limited Packet Size

 Applications within LoWPANs are expected to originate small packets.
 Adding all layers for IP connectivity should still allow transmission
 in one frame, without incurring excessive fragmentation and
 reassembly.  Furthermore, protocols must be designed or chosen so
 that the individual "control/protocol packets" fit within a single
 802.15.4 frame.  Along these lines, IPv6's requirement of sub-IP
 reassembly (see Section 5) may pose challenges for low-end LoWPAN
 devices that do not have enough RAM or storage for a 1280-octet
 packet.

4.4. Limited Configuration and Management

 As alluded to above, devices within LoWPANs are expected to be
 deployed in exceedingly large numbers.  Additionally, they are
 expected to have limited display and input capabilities.
 Furthermore, the location of some of these devices may be hard to
 reach.  Accordingly, protocols used in LoWPANs should have minimal
 configuration, preferably work "out of the box", be easy to
 bootstrap, and enable the network to self heal given the inherent
 unreliable characteristic of these devices.  The size constraints of
 the link layer protocol should also be considered.  Network
 management should have little overhead, yet be powerful enough to
 control dense deployment of devices.

4.5. Service Discovery

 LoWPANs require simple service discovery network protocols to
 discover, control and maintain services provided by devices.  In some
 cases, especially in dense deployments, abstraction of several nodes
 to provide a service may be beneficial.  In order to enable such
 features, new protocols may have to be designed.

4.6. Security

 IEEE 802.15.4 mandates link-layer security based on AES, but it omits
 any details about topics like bootstrapping, key management, and
 security at higher layers.  Of course, a complete security solution
 for LoWPAN devices must consider application needs very carefully.
 Please refer to the security consideration section below for a more
 detailed discussion and in-depth security requirements.

Kushalnagar, et al. Informational [Page 6] RFC 4919 6LoWPAN Problems and Goals August 2007

5. Goals

 The goals mentioned below are general and not limited to IETF
 activities.  As such, they may not only refer to work that can be
 done within the IETF (e.g., specification required to transmit IP,
 profile of best practices for transmitting IP packets, and associated
 upper level protocols, etc).  They also point at work more relevant
 to other standards bodies (e.g., desirable changes to or profiles
 relevant to IEEE 802.15.4, W3C, etc).  When the goals fall under the
 IETF's purview, they serve to point out what those efforts should
 strive to accomplish, regardless of whether they are pursued within
 one (or more) new (or existing) working groups.  When the goals do
 not fall under the purview of the IETF, documenting them here serves
 as input to other organizations [LIAISON].
 Note that a common underlying goal is to reduce packet overhead,
 bandwidth consumption, processing requirements, and power
 consumption.
 The following are the goals according to priority for LoWPANs:
 1.  Fragmentation and Reassembly layer: As mentioned in the overview,
     the protocol data units may be as small as 81 bytes.  This is
     obviously far below the minimum IPv6 packet size of 1280 octets,
     and 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: Given that in the worst case the maximum size
     available for transmitting IP packets over an IEEE 802.15.4 frame
     is 81 octets, and that the IPv6 header is 40 octets long,
     (without optional headers), this leaves only 41 octets for
     upper-layer protocols, like UDP and TCP.  UDP uses 8 octets in
     the header and TCP uses 20 octets.  This leaves 33 octets for
     data over UDP and 21 octets for data over TCP.  Additionally, as
     pointed above, there is also a need for a fragmentation and
     reassembly layer, which will use even more octets leaving very
     few octets for data.  Thus, if one were to use the protocols as
     is, it would lead to excessive fragmentation and reassembly, even
     when data packets are just 10s of octets long.  This points to
     the need for header compression.  As there is much published and
     in-progress standardization work on header compression, the
     6LoWPAN community needs to investigate using existing header
     compression techniques, and, if necessary, specify new ones.

Kushalnagar, et al. Informational [Page 7] RFC 4919 6LoWPAN Problems and Goals August 2007

 3.  Address Autoconfiguration: [6LoWPAN] specifies methods for
     creating IPv6 stateless address auto configuration.  Stateless
     auto configuration (as compared to stateful) is attractive for
     6LoWPANs, because it reduces the configuration overhead on the
     hosts.  There is 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 to support a multi-hop
     mesh network is necessary.  There is much published work on ad-
     hoc multi hop routing for devices.  Some examples include
     [RFC3561], [RFC3626], [RFC3684], all experimental.  Also, these
     protocols are designed to use IP-based addresses that 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.  Given the packet-size
     constraints, transmitting this packet without fragmentation and
     reassembly may be difficult.  Thus, care should be taken when
     using existing routing protocols (or designing new ones) so that
     the routing packets fit within a single IEEE 802.15.4 frame.
 5.  Network Management: One of the points of transmitting IPv6
     packets is to reuse existing protocols as much as possible.
     Network management functionality is critical for LoWPANs.
     However, 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 with the
     benefit to utilize existing tools.  However, due to the memory,
     processing, and message size constraints, further investigation
     is required to determine if the use of SNMPv3 is suitable, or if
     an appropriate adaptation of SNMPv3 or use of different protocols
     is in order.
 6.  Implementation Considerations: It may be the case that
     transmitting IP over IEEE 802.15.4 would become more beneficial
     if implemented in a "certain" way.  Accordingly, 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 efficiency of application protocols.
     Heavyweight protocols based on XML such as SOAP [SOAP], may not
     be suitable for LoWPANs.  As such, more compact encodings (and
     perhaps protocols) may become necessary.  The goal here is to
     specify or suggest modifications to existing protocols so that

Kushalnagar, et al. Informational [Page 8] RFC 4919 6LoWPAN Problems and Goals August 2007

     they are suitable for LoWPANs.  Furthermore, application level
     interoperability specifications may also become necessary in the
     future and may thus be specified.
 8.  Security Considerations: Security threats at different layers
     must be clearly understood and documented.  Bootstrapping of
     devices into a secure network could also be considered given the
     location, limited display, high density, and ad-hoc deployment of
     devices.

6. Security Considerations

 IPv6 over LoWPAN (6LoWPAN) applications often require confidentiality
 and integrity protection.  This can be provided at the application,
 transport, network, and/or at the link layer (i.e., within the
 6LoWPAN set of specifications).  In all these cases, prevailing
 constraints will influence the choice of a particular protocol.  Some
 of the more relevant constraints are small code size, low power
 operation, low complexity, and small bandwidth requirements.
 Given these constraints, first, a threat model for 6LoWPAN devices
 needs to be developed in order to weigh any risks against the cost of
 their mitigations while making meaningful assumptions and
 simplifications.  Some examples for threats that should be considered
 are man-in-the-middle attacks and denial of service attacks.
 A separate set of security considerations apply to bootstrapping a
 6LoWPAN device into the network (e.g., for initial key
 establishment).  This generally involves application level exchanges
 or out-of-band techniques for the initial key establishment, and may
 rely on application-specific trust models; thus, it is considered
 extraneous to 6LoWPAN and is not addressed in these specifications.
 In order 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 to secure the data traffic do fall under the
 purview of 6LoWPAN.  Here, the different alternatives (TLS, IKE/
 IPsec, etc.) 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 have support for AES link-layer security.  AES is a
 block cipher operating on blocks of fixed length, i.e., 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 this does not ensure message integrity.  Other
 modes have been designed which ensure both confidentiality and

Kushalnagar, et al. Informational [Page 9] RFC 4919 6LoWPAN Problems and Goals August 2007

 message integrity, such as CCM* mode. 6LoWPAN networks can operate in
 any of the previous modes, but it is desirable to utilize the most
 secure modes available for link-layer security (e.g., CCM*), and
 build upon it.
 For network layer security, two models are applicable: end-to-end
 security, e.g., using IPsec transport mode, or security that is
 limited to the wireless portion of the network, e.g., 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 is beneficial to
 identify the relevant security model, and to identify 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.

Kushalnagar, et al. Informational [Page 10] RFC 4919 6LoWPAN Problems and Goals August 2007

 [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

Kushalnagar, et al. Informational [Page 11] RFC 4919 6LoWPAN Problems and Goals August 2007

Full Copyright Statement

 Copyright (C) The IETF Trust (2007).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 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

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at
 ietf-ipr@ietf.org.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Kushalnagar, et al. Informational [Page 12]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4919.txt · Last modified: 2007/08/14 17:02 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki