6lowpan G. Mulligan Internet-Draft Proto6 Intended status: Standards Track C. Williams Expires: January 9, 2009 D. Huo ZTE USA July 8, 2008 Mobility Considerations for 6LoWPAN draft-williams-6lowpan-mob-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 9, 2009. Mulligan, et al. Expires January 9, 2009 [Page 1] Internet-Draft Mobility Considerations for 6LoWPAN July 2008 Abstract There has been discussion recently within the 6LoWPAN community regarding mobile usage scenarios. Mobility considerations and analysis is required to ensure proper performance for the mobile usage cases. Also, mobility in 6LoWPAN sensor networks may present unique challenges to the 6LoWPAN architecture. Hence it is best to have mobility as a consideration upfront rather than an after thought in the development of 6LoWPAN milestones. This document provides a mobility perspective to the 6LoWPAN sensor network architecture. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Extensions of the PAN Framework . . . . . . . . . . . . . 6 3.2. Global reachability and changing connectivity . . . . . . 8 4. Changing connectivity points of attachments . . . . . . . . . 10 5. Security of the mobile access network . . . . . . . . . . . . 12 5.1. Mobile security for the extended PAN . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. Normative references . . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19 Mulligan, et al. Expires January 9, 2009 [Page 2] Internet-Draft Mobility Considerations for 6LoWPAN July 2008 1. Introduction The IETF 6LoWPAN working group was formed in 2004 to address the challenge of enabling wireless IPv6 communication over the newly standardized IEEE 802.15.4 low-power radio for devices with limited space, power and memory, such as sensor nodes. IEEE 802.15.4 radio links, coupled with the interoperability and ubiquity of IP, will lead to exciting new deployment scenarios for these low-power networks. Sensor wireless networks will be integrated into wired and/or wireless fixed infrastructure. The integration of these sensor networks with the Internet and wireless infrastructure networks increases the network capacity, coverage area and application domains. Such an integration requires that 6LoWPAN networks handle mobility scenarios. Mobility in 6LoWPAN networks is being examined because users that are interested in sensor data will not always be stationary. In addition, mobile users will need to inject a sensor query into the 6LoWPAN network while they are mobile. Mobile users will also need to retrieve a sensor response from the 6LoWPAN network while they are mobile. It has also been shown that sensor mobility can be exploited to compensate for the lack of sensors and improve network coverage. [MOBCOVERAGE] It has also been shown that mobility helps with localization requirements by wireless sensor applications that depend on nodes accurately determining their locations [MOBLOCAL]. Moreover, there has been a desire to deploy sensors mounted on mobile platforms such as automobiles and planes. Mobility will also play a role in the future interconnection framework for 6LoWPAN networks as it is expected that internetworking will not necessarily be limited to a way to transport information from and to remote hosts. The foreseen degree of integration between sensor networks may reach upper levels of the protocol stack, where one network may offer services to others (including communication services). In such a setting, even 6LoWPAN sensor network components may be heterogeneous, consisting of sensors with varied functionalities, capabilities and interconnection requirements. Currently, wireless sensor networks are beginning to be deployed at an accelerated pace. It is not unreasonable to expect that in the near future, many segments of the world will be covered with wireless sensor networks that will be accessible via the Internet. Integration of wireless sensor networks with wireless local area networks and the Internet, while being important, comes with connectivity and security issues. What the authors have concluded through their extensive prototyping Mulligan, et al. Expires January 9, 2009 [Page 3] Internet-Draft Mobility Considerations for 6LoWPAN July 2008 and deployment, it is best to have mobility as a consideration upfront rather than an after thought in the development of 6LoWPAN milestones. This document provides a mobility perspective to the 6LoWPAN sensor network architecture. Mulligan, et al. Expires January 9, 2009 [Page 4] Internet-Draft Mobility Considerations for 6LoWPAN July 2008 2. Terminology See RFC3753 [RFC3753]for mobility terminology used in this document. Mulligan, et al. Expires January 9, 2009 [Page 5] Internet-Draft Mobility Considerations for 6LoWPAN July 2008 3. Framework 3.1. Extensions of the PAN Framework In practical deployment scenarios, 6LowPAN networks may not be isolated independent PANs. A personal network will be logical networks, defined by appropriate security associations. In practice personal networks will have potential huge geographical and topological span. Personal networks will consists of both ad-hoc and infrastructure networks. It will be user centric with the PAN (i.e., Core PAN) as the central entity. An extension of the PAN framework is provided in the diagram below. Mulligan, et al. Expires January 9, 2009 [Page 6] Internet-Draft Mobility Considerations for 6LoWPAN July 2008 Extensions of the PAN Concept: (Personal Network) Local Foreign Devices Remote personal Devices | | | | | | | ***********|*******|** | * +-------|-----+ | * * | V | | * **********|********** * | Home Network| | * * +------|----+ * *********** +-------------+ | * * |Smart |Bldg | * * / | * * | 0 V | * * / ************|** * | 0 | * * / * | * +-----------+ * +------------*----------------*----+ | * * | * * | | * | ***************** ************|*** * | | Interconnecting Structure | | * * \ |(Internet, WLAN, 3G, Ad-hoc, etc) | +----|-+* * | | | | V |* * | | |-|Corp |* * | | ****** | Network|* * +-*----*---------------------------+ +------+* * * * ***** * (user) ***** * ___ * * +-------------+ * * /___ ***** * | Core PAN | * * +-----------+ +--------------+ * * | 0 | *_____ * | PAN |__ |Vehicular Area| * * | 0 0 | * /___*__| 0 | /__ | Network | * * | 0 | * * | 0 0 | | 0 | * * +-------------+ * * +--------\--+ +/-------------+ * * * * \ / * ********************** **************\*****/****************** \ / \ / | Remote Foreign Devices Figure 1 In this extended PAN framework a diverse personal network is presented. The illustration local foreign devices in a smart building which are only accessed through the user's core PAN. No direct permanent connectivity is provided to these devices. The diagram also illustrates a PAN connected to a 3G network as well as a vehicular area network of sensors. Individual sensor nodes from the Mulligan, et al. Expires January 9, 2009 [Page 7] Internet-Draft Mobility Considerations for 6LoWPAN July 2008 PAN and Vehicular Area network may join and change PANs. Remote foreign devices may be accessed either by the Core PAN directly connecting to these ad-hoc networks or through the interconnecting structure. The corporate and home network are connected to the Interconnecting structure and may have remote personal devices. The extension of the PAN framework presented shows a diverse and huge geographical and topological span with a mobility presence various aspects of the architecture. 3.2. Global reachability and changing connectivity 6LoWPAN networks may require to be fully integrated into a dynamic mobile heterogeneous framework for ensuring global reachability to the individual 6LoWPAN nodes Sensor networks share several characteristics of ad-hoc scenarios in that sensor nodes are capable of receiving and forwarding packets to their peers. However, tiny sensor devices may have more stringent processing power, memory and energy constraints than other types of ad hoc networks. These constraints generally imply the need for a hierarchical ad-hoc network structure in which low-tier sensor nodes connect to the Internet via one or more levels of gateway devices. In this draft, we assume that each autonomous network of wireless sensor devices will have one gateway device. This gateway device is responsible for media conversion (from 802.15.4 to another link layer technology, such as 802.11, and vice versa) and for route advertising to the outside world, which may be a wireless local area network connected to the Internet. There will be deployment scenarios where 6LoWPAN networks have persistent connectivity to the outside world via its gateway device. At the same time, there may be deployment scenarios that require that a 6LoWPAN network change its point of attachment to the outside world from an IP perspective. This may occur, for example, when a sensor network is part of a moving vehicle which may roam from one wireless local area network to another wireless local area network with different IP network prefixes. By the same token, an autonomous sensor network may be deployed in a location with no wireless (or wired) local area networks. In this case, its connectivity to the outside world, when it exists, will be intermittent. Also, the intermittent connectivity to the Internet may have different characteristics each time they occur. For example, connectivity of the 6LoWPAN network to the internet may be realized via an agent (e.g., a vehicle) which features a satellite interface. At different points in time, different agents may provide connectivity functions; in which case the point of attachment of the sensor network may correspond to a different IP address prefix. Note that the two scenarios depicted above are equivalent from an IP connectivity point Mulligan, et al. Expires January 9, 2009 [Page 8] Internet-Draft Mobility Considerations for 6LoWPAN July 2008 of view. In the first scenario, the sensor network moves from one access network to another. In the second scenario, agents with different IP addresses provide access functions to a stationary sensor network. In either case, the IP address of the point of attachment will change over time. Here, the requirement is to provide global reachability to the 6LoWPAN nodes no matter where the correspondent peers are located, and no matter what their point of attachment is. The 6LoWPAN nodes must still be reachable with their originally prescribed IPv6 addresses. Mulligan, et al. Expires January 9, 2009 [Page 9] Internet-Draft Mobility Considerations for 6LoWPAN July 2008 4. Changing connectivity points of attachments Mobility is a fundamental characteristic of a wireless network with mobile users, and it is therefore anticipated that future networks will provide mobility support as an integrated and ubiquitous service. Mobility scenarios anticipated in future networks include simple end-user migration from one subnetwork to another (as in cellular or WLAN hot-spot services), as well as more complex mobility patterns involving movement of radio routers and sensor network clusters. Collections of sensor networks must be reachable as they move across different wireless domains. Scalable and accurate indirection schemes need to be devised to allow for this functionality. Mobile IPv6 network mobility (NEMO) [RFC3963] defines a process that enables Mobile Networks to attach to different points in the Internet. The protocol is an extension of Mobile IPv6 and allows session continuity for every node in the Mobile Network as the network moves. Use of NEMO will enable all 6LoWPAN nodes to be accessible, no matter what the current point of attachment to the wide area IP network is. Mulligan, et al. Expires January 9, 2009 [Page 10] Internet-Draft Mobility Considerations for 6LoWPAN July 2008 Diagram of NEMO and 6LoWPAN integration is provided. [RFC4944] , e.g., (Nodes in the 6LoWPAN network) * * * ... * * * 6LoWPAN network | | +-------------+ | NEMO Client | +-------------+ | | +--------------------+ |Access Network (AR) | +--------------------+ | +-------------------+ | Internet | +-------------------+ | | +---------------+ | Correspondent | | Node | +---------------+ Figure 2 The NEMO client integration enables the sensor application residing on some correspondent node provides global reachability to the 6LoWPAN nodes even when the access network for the 6LoWPAN network changes. Mulligan, et al. Expires January 9, 2009 [Page 11] Internet-Draft Mobility Considerations for 6LoWPAN July 2008 5. Security of the mobile access network 6LoWPAN networks may be deployed remotely in non-traditional scenarios. Access networks for these 6LoWPAN networks may be intermittently available, and their IP address prefixes may change over time. This means that the IP layer has new requirements to be able to provide access to these 6LoWPAN networks via changing access networks and to do so in a secure manner. 5.1. Mobile security for the extended PAN IPv6 nodes use the Neighbor Discovery protocol (ND) [RFC2461] to discover other nodes on the link, to determine the link-layer addresses of other nodes on the link, to find routers, and to maintain reachability information about the paths to active neighbors. If proper authentication mechanisms are not in place, straight use ND in sensor networks may introduce security vulnerabilities. The IETF has created the Secure Neighbor Discovery Protocol (SeND) [RFC3971] to provide authentication services for the ND. SeND may be used as a solution between the NEMO client residing in the Sensor network and the access network which will have a SeND service for providing authenticated NEMO autoconfiguration. In this solution, NEMO with SeND may provide a means by which the access network is properly authorized to connect to the sensor network. Mulligan, et al. Expires January 9, 2009 [Page 12] Internet-Draft Mobility Considerations for 6LoWPAN July 2008 Diagram of NEMO, SEND and 6LoWPAN integration is provided. [RFC3971] , e.g., (Nodes in the 6LoWPAN network) * * * ... * * * 6LoWPAN network | | +---------+ | NEMO & | | SEND | +---------+ | | +--------------------+ |Access Network (AR) | | With SEND | +--------------------+ | +-------------------+ | Internet | +-------------------+ | | +---------------+ | Correspondent | | Node | +---------------+ Figure 3 Authentication process specified in SeND may involve the use of server infrastructure for certificate management purposes. It may be impractical to have a server infrastructure in place for authentication in the deployment scenarios discussed in this draft. Therefore, the Cryptographically Generated Addresses (CGA) [RFC3972] option of SeND may be a useful tool for 6LoWPAN networks in providing authentication services. Mulligan, et al. Expires January 9, 2009 [Page 13] Internet-Draft Mobility Considerations for 6LoWPAN July 2008 6. Security Considerations Security assumptions for stationary 6LoWPAN networks are inadequate for scenarios whereby mobility is introduced. Mobile users injecting sensor queries into the 6LoWPAN network while they are mobile pose new security considerations. This is also true when mobile users are retrieving sensor responses from the 6LoWPAN network while they are mobile. Privacy and authentication is also an area for mobile security analysis. For example, privacy between the 6LoWPAN network point of attachment and the local area access network may be established using IPsec. More security analysis is required. Mulligan, et al. Expires January 9, 2009 [Page 14] Internet-Draft Mobility Considerations for 6LoWPAN July 2008 7. Conclusion Practical deployment scenarios require mobility of both individual sensor nodes but also connectivity points for the PANs. Mobility as an architectural consideration for 6LowPAN must be consider upfront rather than an after thought in the development of 6LoWPAN milestones. Finally, techniques developed for other mobile networks may not be applicable in all usage cases, as in these networks power conservation is not a requirement. Mulligan, et al. Expires January 9, 2009 [Page 15] Internet-Draft Mobility Considerations for 6LoWPAN July 2008 8. Acknowledgement Acknowledgement of Derya Cansever for his input and contributions to initial discussion on mobility for sensors. Mulligan, et al. Expires January 9, 2009 [Page 16] Internet-Draft Mobility Considerations for 6LoWPAN July 2008 9. References 9.1. Normative references [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007. 9.2. Informative References [MOBCOVERAGE] Liu, B., Brass, P., Dousse, O., Nain, P., and D. Towsley, "Mobility Improves Coverage of Sensor Networks", Mobihoc 2005, Proceedings of MobiHoc 2005, May 2005. [MOBLOCAL] Hu, L. and D. Evans, "Localization for Mobile Sensor Networks", MobiCom 2004, Tenth Annual International Conference on Mobile Computing and Networking, September 2004. Mulligan, et al. Expires January 9, 2009 [Page 17] Internet-Draft Mobility Considerations for 6LoWPAN July 2008 Authors' Addresses Geoff Mulligan Proto6 Consultant Colarodo Springs, CO 80901 USA Phone: 719.593.2992 Email: geoff@proto6.com Carl Williams ZTE USA Consultant Palo Alto, CA 94306 USA Phone: +1.650.279.5903 Email: carlw@mcsr-labs.org David Huo ZTE USA 33 Wood Ave S Metuchen, NJ 08840 USA Phone: +1.732.632.9880 Email: david.huo@zteusa.com Mulligan, et al. Expires January 9, 2009 [Page 18] Internet-Draft Mobility Considerations for 6LoWPAN July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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 provided by the IETF Administrative Support Activity (IASA). Mulligan, et al. Expires January 9, 2009 [Page 19]