idnits 2.17.1 draft-williams-6lowpan-mob-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 476. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 487. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 494. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 500. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 19 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 8, 2008) is 5763 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3753' is defined on line 403, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Downref: Normative reference to an Informational RFC: RFC 3753 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6lowpan G. Mulligan 3 Internet-Draft Proto6 4 Intended status: Standards Track C. Williams 5 Expires: January 9, 2009 D. Huo 6 ZTE USA 7 July 8, 2008 9 Mobility Considerations for 6LoWPAN 10 draft-williams-6lowpan-mob-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 9, 2009. 37 Abstract 39 There has been discussion recently within the 6LoWPAN community 40 regarding mobile usage scenarios. Mobility considerations and 41 analysis is required to ensure proper performance for the mobile 42 usage cases. Also, mobility in 6LoWPAN sensor networks may present 43 unique challenges to the 6LoWPAN architecture. Hence it is best to 44 have mobility as a consideration upfront rather than an after thought 45 in the development of 6LoWPAN milestones. This document provides a 46 mobility perspective to the 6LoWPAN sensor network architecture. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 52 3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 6 53 3.1. Extensions of the PAN Framework . . . . . . . . . . . . . 6 54 3.2. Global reachability and changing connectivity . . . . . . 8 55 4. Changing connectivity points of attachments . . . . . . . . . 10 56 5. Security of the mobile access network . . . . . . . . . . . . 12 57 5.1. Mobile security for the extended PAN . . . . . . . . . . . 12 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 59 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15 60 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16 61 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 62 9.1. Normative references . . . . . . . . . . . . . . . . . . . 17 63 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 65 Intellectual Property and Copyright Statements . . . . . . . . . . 19 67 1. Introduction 69 The IETF 6LoWPAN working group was formed in 2004 to address the 70 challenge of enabling wireless IPv6 communication over the newly 71 standardized IEEE 802.15.4 low-power radio for devices with limited 72 space, power and memory, such as sensor nodes. IEEE 802.15.4 radio 73 links, coupled with the interoperability and ubiquity of IP, will 74 lead to exciting new deployment scenarios for these low-power 75 networks. Sensor wireless networks will be integrated into wired 76 and/or wireless fixed infrastructure. The integration of these 77 sensor networks with the Internet and wireless infrastructure 78 networks increases the network capacity, coverage area and 79 application domains. Such an integration requires that 6LoWPAN 80 networks handle mobility scenarios. 82 Mobility in 6LoWPAN networks is being examined because users that are 83 interested in sensor data will not always be stationary. In 84 addition, mobile users will need to inject a sensor query into the 85 6LoWPAN network while they are mobile. Mobile users will also need 86 to retrieve a sensor response from the 6LoWPAN network while they are 87 mobile. 89 It has also been shown that sensor mobility can be exploited to 90 compensate for the lack of sensors and improve network coverage. 91 [MOBCOVERAGE] It has also been shown that mobility helps with 92 localization requirements by wireless sensor applications that depend 93 on nodes accurately determining their locations [MOBLOCAL]. 94 Moreover, there has been a desire to deploy sensors mounted on mobile 95 platforms such as automobiles and planes. 97 Mobility will also play a role in the future interconnection 98 framework for 6LoWPAN networks as it is expected that internetworking 99 will not necessarily be limited to a way to transport information 100 from and to remote hosts. The foreseen degree of integration between 101 sensor networks may reach upper levels of the protocol stack, where 102 one network may offer services to others (including communication 103 services). In such a setting, even 6LoWPAN sensor network components 104 may be heterogeneous, consisting of sensors with varied 105 functionalities, capabilities and interconnection requirements. 106 Currently, wireless sensor networks are beginning to be deployed at 107 an accelerated pace. It is not unreasonable to expect that in the 108 near future, many segments of the world will be covered with wireless 109 sensor networks that will be accessible via the Internet. 110 Integration of wireless sensor networks with wireless local area 111 networks and the Internet, while being important, comes with 112 connectivity and security issues. 114 What the authors have concluded through their extensive prototyping 115 and deployment, it is best to have mobility as a consideration 116 upfront rather than an after thought in the development of 6LoWPAN 117 milestones. This document provides a mobility perspective to the 118 6LoWPAN sensor network architecture. 120 2. Terminology 122 See RFC3753 [RFC3753]for mobility terminology used in this document. 124 3. Framework 126 3.1. Extensions of the PAN Framework 128 In practical deployment scenarios, 6LowPAN networks may not be 129 isolated independent PANs. A personal network will be logical 130 networks, defined by appropriate security associations. In practice 131 personal networks will have potential huge geographical and 132 topological span. Personal networks will consists of both ad-hoc and 133 infrastructure networks. It will be user centric with the PAN (i.e., 134 Core PAN) as the central entity. An extension of the PAN framework 135 is provided in the diagram below. 137 Extensions of the PAN Concept: 139 (Personal Network) 141 Local Foreign Devices Remote personal Devices 142 | | | 143 | | | 144 | ***********|*******|** 145 | * +-------|-----+ | * 146 * | V | | * 147 **********|********** * | Home Network| | * 148 * +------|----+ * *********** +-------------+ | * 149 * |Smart |Bldg | * * / | * 150 * | 0 V | * * / ************|** 151 * | 0 | * * / * | 152 * +-----------+ * +------------*----------------*----+ | 153 * * | * * | | 154 * | ***************** ************|*** 155 * | | Interconnecting Structure | | * 156 * \ |(Internet, WLAN, 3G, Ad-hoc, etc) | +----|-+* 157 * | | | | V |* 158 * | | |-|Corp |* 159 * | | ****** | Network|* 160 * +-*----*---------------------------+ +------+* 161 * * * ***** 162 * (user) ***** * ___ * 163 * +-------------+ * * /___ ***** 164 * | Core PAN | * * +-----------+ +--------------+ * 165 * | 0 | *_____ * | PAN |__ |Vehicular Area| * 166 * | 0 0 | * /___*__| 0 | /__ | Network | * 167 * | 0 | * * | 0 0 | | 0 | * 168 * +-------------+ * * +--------\--+ +/-------------+ * 169 * * * \ / * 170 ********************** **************\*****/****************** 171 \ / 172 \ / 173 | 174 Remote Foreign Devices 176 Figure 1 178 In this extended PAN framework a diverse personal network is 179 presented. The illustration local foreign devices in a smart 180 building which are only accessed through the user's core PAN. No 181 direct permanent connectivity is provided to these devices. The 182 diagram also illustrates a PAN connected to a 3G network as well as a 183 vehicular area network of sensors. Individual sensor nodes from the 184 PAN and Vehicular Area network may join and change PANs. Remote 185 foreign devices may be accessed either by the Core PAN directly 186 connecting to these ad-hoc networks or through the interconnecting 187 structure. The corporate and home network are connected to the 188 Interconnecting structure and may have remote personal devices. The 189 extension of the PAN framework presented shows a diverse and huge 190 geographical and topological span with a mobility presence various 191 aspects of the architecture. 193 3.2. Global reachability and changing connectivity 195 6LoWPAN networks may require to be fully integrated into a dynamic 196 mobile heterogeneous framework for ensuring global reachability to 197 the individual 6LoWPAN nodes 199 Sensor networks share several characteristics of ad-hoc scenarios in 200 that sensor nodes are capable of receiving and forwarding packets to 201 their peers. However, tiny sensor devices may have more stringent 202 processing power, memory and energy constraints than other types of 203 ad hoc networks. These constraints generally imply the need for a 204 hierarchical ad-hoc network structure in which low-tier sensor nodes 205 connect to the Internet via one or more levels of gateway devices. 206 In this draft, we assume that each autonomous network of wireless 207 sensor devices will have one gateway device. This gateway device is 208 responsible for media conversion (from 802.15.4 to another link layer 209 technology, such as 802.11, and vice versa) and for route advertising 210 to the outside world, which may be a wireless local area network 211 connected to the Internet. 213 There will be deployment scenarios where 6LoWPAN networks have 214 persistent connectivity to the outside world via its gateway device. 215 At the same time, there may be deployment scenarios that require that 216 a 6LoWPAN network change its point of attachment to the outside world 217 from an IP perspective. This may occur, for example, when a sensor 218 network is part of a moving vehicle which may roam from one wireless 219 local area network to another wireless local area network with 220 different IP network prefixes. By the same token, an autonomous 221 sensor network may be deployed in a location with no wireless (or 222 wired) local area networks. In this case, its connectivity to the 223 outside world, when it exists, will be intermittent. Also, the 224 intermittent connectivity to the Internet may have different 225 characteristics each time they occur. For example, connectivity of 226 the 6LoWPAN network to the internet may be realized via an agent 227 (e.g., a vehicle) which features a satellite interface. At different 228 points in time, different agents may provide connectivity functions; 229 in which case the point of attachment of the sensor network may 230 correspond to a different IP address prefix. Note that the two 231 scenarios depicted above are equivalent from an IP connectivity point 232 of view. In the first scenario, the sensor network moves from one 233 access network to another. In the second scenario, agents with 234 different IP addresses provide access functions to a stationary 235 sensor network. In either case, the IP address of the point of 236 attachment will change over time. 238 Here, the requirement is to provide global reachability to the 239 6LoWPAN nodes no matter where the correspondent peers are located, 240 and no matter what their point of attachment is. The 6LoWPAN nodes 241 must still be reachable with their originally prescribed IPv6 242 addresses. 244 4. Changing connectivity points of attachments 246 Mobility is a fundamental characteristic of a wireless network with 247 mobile users, and it is therefore anticipated that future networks 248 will provide mobility support as an integrated and ubiquitous 249 service. Mobility scenarios anticipated in future networks include 250 simple end-user migration from one subnetwork to another (as in 251 cellular or WLAN hot-spot services), as well as more complex mobility 252 patterns involving movement of radio routers and sensor network 253 clusters. Collections of sensor networks must be reachable as they 254 move across different wireless domains. Scalable and accurate 255 indirection schemes need to be devised to allow for this 256 functionality. 258 Mobile IPv6 network mobility (NEMO) [RFC3963] defines a process that 259 enables Mobile Networks to attach to different points in the 260 Internet. The protocol is an extension of Mobile IPv6 and allows 261 session continuity for every node in the Mobile Network as the 262 network moves. Use of NEMO will enable all 6LoWPAN nodes to be 263 accessible, no matter what the current point of attachment to the 264 wide area IP network is. 266 Diagram of NEMO and 6LoWPAN integration is provided. [RFC4944] , 267 e.g., 269 (Nodes in the 6LoWPAN network) 270 * * * ... * * * 272 6LoWPAN 273 network 274 | 275 | 276 +-------------+ 277 | NEMO Client | 278 +-------------+ 279 | 280 | 281 +--------------------+ 282 |Access Network (AR) | 283 +--------------------+ 284 | 285 +-------------------+ 286 | Internet | 287 +-------------------+ 288 | 289 | 290 +---------------+ 291 | Correspondent | 292 | Node | 293 +---------------+ 295 Figure 2 297 The NEMO client integration enables the sensor application residing 298 on some correspondent node provides global reachability to the 299 6LoWPAN nodes even when the access network for the 6LoWPAN network 300 changes. 302 5. Security of the mobile access network 304 6LoWPAN networks may be deployed remotely in non-traditional 305 scenarios. Access networks for these 6LoWPAN networks may be 306 intermittently available, and their IP address prefixes may change 307 over time. This means that the IP layer has new requirements to be 308 able to provide access to these 6LoWPAN networks via changing access 309 networks and to do so in a secure manner. 311 5.1. Mobile security for the extended PAN 313 IPv6 nodes use the Neighbor Discovery protocol (ND) [RFC2461] to 314 discover other nodes on the link, to determine the link-layer 315 addresses of other nodes on the link, to find routers, and to 316 maintain reachability information about the paths to active 317 neighbors. If proper authentication mechanisms are not in place, 318 straight use ND in sensor networks may introduce security 319 vulnerabilities. The IETF has created the Secure Neighbor Discovery 320 Protocol (SeND) [RFC3971] to provide authentication services for the 321 ND. SeND may be used as a solution between the NEMO client residing 322 in the Sensor network and the access network which will have a SeND 323 service for providing authenticated NEMO autoconfiguration. In this 324 solution, NEMO with SeND may provide a means by which the access 325 network is properly authorized to connect to the sensor network. 327 Diagram of NEMO, SEND and 6LoWPAN integration is provided. [RFC3971] 328 , e.g., 330 (Nodes in the 6LoWPAN network) 331 * * * ... * * * 333 6LoWPAN 334 network 335 | 336 | 337 +---------+ 338 | NEMO & | 339 | SEND | 340 +---------+ 341 | 342 | 343 +--------------------+ 344 |Access Network (AR) | 345 | With SEND | 346 +--------------------+ 347 | 348 +-------------------+ 349 | Internet | 350 +-------------------+ 351 | 352 | 353 +---------------+ 354 | Correspondent | 355 | Node | 356 +---------------+ 358 Figure 3 360 Authentication process specified in SeND may involve the use of 361 server infrastructure for certificate management purposes. It may be 362 impractical to have a server infrastructure in place for 363 authentication in the deployment scenarios discussed in this draft. 364 Therefore, the Cryptographically Generated Addresses (CGA) [RFC3972] 365 option of SeND may be a useful tool for 6LoWPAN networks in providing 366 authentication services. 368 6. Security Considerations 370 Security assumptions for stationary 6LoWPAN networks are inadequate 371 for scenarios whereby mobility is introduced. Mobile users injecting 372 sensor queries into the 6LoWPAN network while they are mobile pose 373 new security considerations. This is also true when mobile users are 374 retrieving sensor responses from the 6LoWPAN network while they are 375 mobile. Privacy and authentication is also an area for mobile 376 security analysis. For example, privacy between the 6LoWPAN network 377 point of attachment and the local area access network may be 378 established using IPsec. More security analysis is required. 380 7. Conclusion 382 Practical deployment scenarios require mobility of both individual 383 sensor nodes but also connectivity points for the PANs. Mobility as 384 an architectural consideration for 6LowPAN must be consider upfront 385 rather than an after thought in the development of 6LoWPAN 386 milestones. Finally, techniques developed for other mobile networks 387 may not be applicable in all usage cases, as in these networks power 388 conservation is not a requirement. 390 8. Acknowledgement 392 Acknowledgement of Derya Cansever for his input and contributions to 393 initial discussion on mobility for sensors. 395 9. References 397 9.1. Normative references 399 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 400 Discovery for IP Version 6 (IPv6)", RFC 2461, 401 December 1998. 403 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 404 RFC 3753, June 2004. 406 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 407 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 408 RFC 3963, January 2005. 410 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 411 Neighbor Discovery (SEND)", RFC 3971, March 2005. 413 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 414 RFC 3972, March 2005. 416 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 417 "Transmission of IPv6 Packets over IEEE 802.15.4 418 Networks", RFC 4944, September 2007. 420 9.2. Informative References 422 [MOBCOVERAGE] 423 Liu, B., Brass, P., Dousse, O., Nain, P., and D. Towsley, 424 "Mobility Improves Coverage of Sensor Networks", Mobihoc 425 2005, Proceedings of MobiHoc 2005, May 2005. 427 [MOBLOCAL] 428 Hu, L. and D. Evans, "Localization for Mobile Sensor 429 Networks", MobiCom 2004, Tenth Annual International 430 Conference on Mobile Computing and Networking, 431 September 2004. 433 Authors' Addresses 435 Geoff Mulligan 436 Proto6 437 Consultant 438 Colarodo Springs, CO 80901 439 USA 441 Phone: 719.593.2992 442 Email: geoff@proto6.com 444 Carl Williams 445 ZTE USA 446 Consultant 447 Palo Alto, CA 94306 448 USA 450 Phone: +1.650.279.5903 451 Email: carlw@mcsr-labs.org 453 David Huo 454 ZTE USA 455 33 Wood Ave S 456 Metuchen, NJ 08840 457 USA 459 Phone: +1.732.632.9880 460 Email: david.huo@zteusa.com 462 Full Copyright Statement 464 Copyright (C) The IETF Trust (2008). 466 This document is subject to the rights, licenses and restrictions 467 contained in BCP 78, and except as set forth therein, the authors 468 retain all their rights. 470 This document and the information contained herein are provided on an 471 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 472 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 473 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 474 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 475 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 476 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 478 Intellectual Property 480 The IETF takes no position regarding the validity or scope of any 481 Intellectual Property Rights or other rights that might be claimed to 482 pertain to the implementation or use of the technology described in 483 this document or the extent to which any license under such rights 484 might or might not be available; nor does it represent that it has 485 made any independent effort to identify any such rights. Information 486 on the procedures with respect to rights in RFC documents can be 487 found in BCP 78 and BCP 79. 489 Copies of IPR disclosures made to the IETF Secretariat and any 490 assurances of licenses to be made available, or the result of an 491 attempt made to obtain a general license or permission for the use of 492 such proprietary rights by implementers or users of this 493 specification can be obtained from the IETF on-line IPR repository at 494 http://www.ietf.org/ipr. 496 The IETF invites any interested party to bring to its attention any 497 copyrights, patents or patent applications, or other proprietary 498 rights that may cover technology that may be required to implement 499 this standard. Please address the information to the IETF at 500 ietf-ipr@ietf.org. 502 Acknowledgement 504 Funding for the RFC Editor function is provided by the IETF 505 Administrative Support Activity (IASA).