diff options
Diffstat (limited to 'doc/rfc/rfc4919.txt')
| -rw-r--r-- | doc/rfc/rfc4919.txt | 675 |
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc4919.txt b/doc/rfc/rfc4919.txt new file mode 100644 index 0000000..137f6fb --- /dev/null +++ b/doc/rfc/rfc4919.txt @@ -0,0 +1,675 @@ + + + + + + +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] + |