idnits 2.17.1 draft-shin-6lowpan-mobility-01.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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 646. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 657. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 664. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 670. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 598 has weird spacing: '...le Node and...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (November 11, 2007) is 6011 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'I-D.ietf-6lowpan-problem' is mentioned on line 80, but not defined == Missing Reference: 'I-D.culler-rsn-routing-reqs' is mentioned on line 381, but not defined == Missing Reference: 'RFC 4831' is mentioned on line 400, but not defined == Missing Reference: 'I-D.ietf-nemo-requirements' is mentioned on line 497, but not defined == Unused Reference: 'RFC3756' is defined on line 555, but no explicit reference was found in the text == Unused Reference: 'RFC4831' is defined on line 568, but no explicit reference was found in the text == Unused Reference: 'RFC4886' is defined on line 571, but no explicit reference was found in the text == Unused Reference: 'RFC4919' is defined on line 574, but no explicit reference was found in the text == Unused Reference: 'I-D.dokaspar-6lowpan-routreq' is defined on line 579, but no explicit reference was found in the text == Unused Reference: 'I-D.chakrabarti-mobopts-lowpan-req' is defined on line 591, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Downref: Normative reference to an Informational RFC: RFC 3756 ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-08) exists of draft-dokaspar-6lowpan-routreq-02 == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-proxymip6-07 == Outdated reference: A later version (-03) exists of draft-ietf-netlmm-mn-ar-if-02 Summary: 4 errors (**), 0 flaws (~~), 17 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M-K. Shin 3 Internet-Draft ETRI 4 Expires: May 14, 2008 T. Camilo 5 J. Silva 6 University of Coimbra 7 D. Kaspar 8 ETRI 9 November 11, 2007 11 Mobility Support in 6LoWPAN 12 draft-shin-6lowpan-mobility-01 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on May 14, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 This draft lists mobility scenarios and suggests solutions of how to 46 provide mobility support in IPv6 Low-power Wireless Personal Area 47 Metworks (6LoWPANs). 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 53 1.2. Terms Used . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 3. Scenario Considerations . . . . . . . . . . . . . . . . . . . 6 56 3.1. Device Movement within a Single WPAN Domain . . . . . . . 6 57 3.2. Device Movement between Multiple WPAN Domains . . . . . . 7 58 3.3. Single WPAN Movement (NEMO) . . . . . . . . . . . . . . . 8 59 3.4. MANEMO - Nested NEMO . . . . . . . . . . . . . . . . . . . 9 60 4. Mobility Support in 6LoWPAN . . . . . . . . . . . . . . . . . 11 61 4.1. Device Movement within a Single WPAN Domain . . . . . . . 11 62 4.2. Device Movement between Multiple WPAN DomainsS . . . . . . 11 63 4.3. Single WPAN movement (NEMO) . . . . . . . . . . . . . . . 14 64 4.4. MANEMO - Nested NEMO . . . . . . . . . . . . . . . . . . . 14 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 69 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 70 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 72 Intellectual Property and Copyright Statements . . . . . . . . . . 21 74 1. Introduction 76 A 6LoWPAN is a simple low cost communication network that allows 77 wireless connectivity in applications with limited power and relaxed 78 throughput requirements. A 6LoWPAN typically includes devices that 79 work together to connect the physical environment to real-world 80 applications, e.g., wireless sensors [I-D.ietf-6lowpan-problem]. 82 6LoWPANs must support various topologies like mesh as well as star. 83 Mesh topologies imply multi-hop routing, to a desired destination. 84 Mesh networks are likely to consist of nodes with a certain degree of 85 mobility. Due to the low performance characteristics of 6LoWPAN 86 devices, mobility support should be provided without high signaling 87 involvement in end devices (e.g., RFD). Also, as recently seen in 88 discussions related to MANEMO (Network mobility for MANET), a similar 89 point was stated regarding network mobility in LoWPAN environments. 91 Fast mobility detection will be a huge challenge and LoWPAN nodes 92 might even change their location while being in state of hibernation. 94 This document presents mobility scenarios and suggests solutions of 95 how to provide mobility support in 6LoWPANs. 97 1.1. Requirements Notation 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 1.2. Terms Used 105 o Reduced-Function Device (RFD): RFDs are intended for applications 106 that are extremely simple, such as a light switch or a passive 107 infrared sensor; they can be implemented using minimal resources 108 and memory capacity. RFDs are not able to transmit MAC layer 109 beacons, and can only communicate with FFDs in a master/slave star 110 topology. RFDs may only associate with a single FFD at a time. 112 o Full-Function Device (FFD): A device implementing the complete 113 protocol set. FFDs have the possibility to send MAC layer beacon 114 frames in order to indicate their presence to other FFDs or RFDs. 115 FFDs can talk to RFDs or other FFDs, while an RFD can talk only to 116 an FFD. 118 o Coordinator-Function Device (CFD): A full-function device (FFD) 119 acting as the principal LoWPAN coordinator, configured to provide 120 synchronization services through the transmission of beacons. The 121 CFD is responsible for unique address allocation. A LoWPAN has 122 exactly one CFD. 124 2. Goals 126 Given the unique low-performance properties of 6LoWPANs, new 127 challenges arise of enabling mobility support to devices with highly 128 reduced memory and power. It is therefore crucial to reduce the 129 additional mobility related signaling overhead or to possibly avoid 130 it altogether. Especially to optimize power consumption, battery- 131 powered devices should be correctly discovered and handled by more 132 capable (and possibly mains-powered) devices in the network, such as 133 the CFD. The fundamental goals for mobility support in 6LoWPANs can 134 be listed as follows: 136 o Mobile 6LoWPAN devices must be addressable by any corresponding 137 node, independent of the current whereabouts. 139 o RFDs should not be involved in any mobility related signaling. 141 o Mobility related signaling for FFDs should be reduced, as much as 142 possible. 144 o Fast handover detection should be supported. 146 o Mobile 6LoWPAN devices should change their location while being in 147 state of hibernation. 149 o Existing mobility protocols should be re-used, if possible. 151 3. Scenario Considerations 153 Low-power WPAN technology is still in its early stage of development, 154 but the range of conceivable usage scenarios is tremendous. The 155 numerous possible applications of sensor networks make it obvious 156 that mesh topologies will be prevalent in LoWPAN environments and 157 mobility support will be a necessity. 159 Mobility based communication can also prolong the lifetime of devices 160 and increase the connectivity between nodes and clusters. Using 161 distributed LoWPANs (i.e. sensor networks), it is possible to sculpt 162 the devices density to cluster around areas of interest, cover large 163 areas, and work more efficiently by filtering local data at the node 164 level before it is transmitted or relayed peer-to-peer. Furthermore, 165 multiple controlled mobile elements can be used to provide load 166 balancing for gathering data. The required mobility is heavily 167 dependent on the individual service scenario and the LoWPAN 168 architecture. This document covers the following scenarios for 169 mobility support in 6LoWPAN. 171 Here are some of the key elements of an IEEE 802.15.4 network. 172 Figure 1 illustrates the key elements of typical mobile 802.15.4 173 deployments. 175 o Device movement within a single WPAN domain 177 o Device movement between multiple WPAN domains 179 o Single WPAN movement (NEMO) 181 o MANEMO (nested NEMO) 183 3.1. Device Movement within a Single WPAN Domain 185 Device movement within a single WPAN domain comprehends the change of 186 location of one LoWPAN device without losing connectivity between the 187 CFD/sink-node. Different behaviours can be expected depending on the 188 type of topology used in the LoWPAN. In star topologies, where there 189 is a direct communication between the RFD/FFD and the CFD/sink-node 190 (single-hop), the communication is not affected by the device 191 mobility if the mobile device stays in the radio range of the CFD/ 192 sink-node. 194 +----------------------------+ 195 | FFD | 196 +----+ | 197 |CFD | RFD | 198 +----+ | 199 | FFD | 200 | RFD | 201 | | 202 +----------------------------+ 204 Figure 1: Device mobility within a single WPAN domain 206 In mesh topologies where the communication between the RFD/FFD and 207 the CFD/sink-node is multi-hop the mobility needs to be supported by 208 the routing protocol used within the LoWPAN. In this scenario it is 209 important to distinct the RFD/FFD mobility from the CFD/sink-node 210 mobility. 212 3.2. Device Movement between Multiple WPAN Domains 214 In this scenario the LoWPAN devices move between different WPAN 215 domains as illustrated in the Fig. 2. By changing from the WPAN1 216 controlled by the CFD1 to the WPAN2 each device (e.g. RFD and FFD) 217 needs to advertise the CFD2 of its presence in order to receive new 218 interface configurations. Due to the 6LoWPAN devices characteristics 219 it is necessary to adjust exisiting IPv6 mobility protocol to such 220 networks. Moreover it is important to understand that RFD represents 221 several limitations regarding FFD, meaning that each one will have 222 different roles regarding the handover process. 224 +-----------------+ +------------------+ 225 | FFD | | FFD | 226 | +----+ +----+ | 227 | FFD |CFD1| |CFD2| RFD | 228 | +----+ +----+ | 229 | | | | 230 | RFD >---------> RFD | 231 | FFD >---------> FFD | 232 +-----------------+ +------------------+ 233 WPAN1 WPAN2 235 Figure 2: Device mobility between multiple WPAN domains(1) 237 Another consideration should be made if the moving LoWPAN device is 238 the CFD1. In this case, such device will act as a CFD until he finds 239 another CFD responsible for a new domain. Fig. 3 illustrates the 240 situation when the sink-node (CFD1) moves from his domain to another 241 domain becoming a common FFD, after negotiating with CFD2. The 242 former domain of CFD1 will need to elect a new CFD, in the example 243 the CFD3. 245 +-----------------+ +------------------+ 246 | FFD | | FFD | 247 | +----+ | +----+ | 248 | |CFD3| | |CFD2| RFD | 249 | +----+ | +----+ | 250 | +----+ | | 251 | RFD |CFD1|-------> FFD | 252 | +----+ | | 253 +-----------------+ +------------------+ 254 WPAN1 WPAN2 256 Figure 3: Device mobility between multiple WPAN domains(2) 258 3.3. Single WPAN Movement (NEMO) 260 In this scenario we consider the aggregation of nodes (FFDs and RFDs) 261 in clusters, with the introduction of an elected node that will work 262 as a Coordinator Function Device (CFD). This node will be 263 responsible for the management of the cluster communication with the 264 external networks. 266 +----------------------------+ 267 | FFD | 268 +----------+ +----+ | 269 | External |--- |CFD | RFD | 270 | Network | +----+ | 271 +----------+ | FFD | 272 | FFD | 273 | | 274 +----------------------------+ 276 Figure 4: WPAN movement 278 In this section the WPAN is considered indivisible and presents 279 mobility as an entity. Moreover, we consider a mobile WPAN as a leaf 280 network, as it does not carry transit traffic. 282 The CFD must be a FFD, as it requires supplementary functionalities 283 when compared with RFDs, as extra processing and energy power. None 284 of the FFDs and RFDs behind the CFD need to be aware of the WPAN 285 mobility, being its movement completely transparent to those devices 286 inside the mobile WPAN. The protocols that support the WPAN movement 287 are very dependent of the following issues: 289 - Application requirements 290 - Level of mobility of WPAN 292 The level of mobility of the WPAN requires different routing updates. 293 It is crucial that the routing protocol optimizes the traffic routes 294 as the energy consumption is critical in node forwarding. Using the 295 CFD concept is possible to create an architecture that reduces the 296 energy consumed in WPAN movement, and thus increasing performance in 297 these networks. 299 The IPv6 [RFC2460] supports natively the mobility. Moreover, in 300 contrast with IPv4, IPv6 offers extra functionalities for router 301 optimization. However, it presents overheads and the routing is not 302 optimal in the case of network mobility. The Nemo working group 303 [RFC3963] that studies these scenarios, has already proposed a simple 304 solution to transparently solve, part of the present needs. However 305 the applicability to LowPAN networks is not trivial and requires 306 extra adaptability to its limited characteristics. The new 307 challenges in providing mobility for WPANs include resource 308 management, network coverage, network lifetime, topology change, 309 routing protocols, security, data reliability, QoS and timely 310 dissemination. These challenges affect the performance of the mobile 311 WPANs. 313 3.4. MANEMO - Nested NEMO 315 In these scenarios, terminal devices or WPANs inside a WPAN could 316 present mobility support, travelling to other fixed or mobile WPANs. 317 These entities can move inside or outside high-level WPANs, forming 318 nested entities. Sink node mobility, as a unique entity, was 319 presented as a special case in sections 3.1 and 3.2. 321 +----------------------------+ 322 | FFD | 323 +----------+ +----+ | 324 | Exterior |--- |CFD | RFD | 325 +----------+ +----+ | 326 | FFD | 327 | FFD +--------+ | 328 | | WPAN | | 329 +------+ | +--------+ | 330 | WPAN | | RFD | 331 +------+ +----------------------------+ 333 Figure 5: MANEMO 335 In these scenarios, due to its properties, several issues need to be 336 covered (i.e. route optimization, bandwidth and encapsulation 337 overhead). 339 In nested networks - in more complex scenarios, the problems are more 340 accentuated and need several improvements and adaptations. Even if 341 we use the redirect IPv6 properties [RFC3775], there stills to exist 342 indirection and overhead, which is more critical when there are 343 several hierarchical levels. 345 Among the open research problems, real time solutions that result in 346 low mobile device speeds and cooperation between multiple mobile 347 devices stand out as challenges that have significant impact. 349 4. Mobility Support in 6LoWPAN 351 In this section, some solutions and optimization techniques for each 352 scenario described in section 3 will be discussed. 354 4.1. Device Movement within a Single WPAN Domain 356 In this scenario, there is no need to additionally define any new 357 mobility protocols. The mobility can be supported by the routing 358 protocol used within the 6LoWPAN. The first choice to achieve this 359 goal is to re-use existing MANET protocols without making any big 360 modifications. (e.g., AODV, OLSR, DYMO, etc.) 362 However, the modification or simplification of existing MANET routing 363 protocols may be required for dynamic routing to be feasible in a 364 LoWPAN domain, because other requirements apply to LoWPAN devices. 365 Unlike MANET devices, LoWPAN nodes are characterized by much lower 366 power supplies, smaller memory sizes, and lower processing power, 367 which create new challenges on obtaining robust and reliable dynamic 368 routing within LoWPANs. 370 There exists a trade-off relationship between routing effectiveness 371 and the requirements posed upon the devices participating in a 372 dynamic network. The challenge is to create a balance between 373 protocol simplicity and routing performance. But stripping down 374 existing protocols to power-aware, low-overhead protocols decreases 375 the efficacy and functionality of their sophisticated routing 376 techniques, or possibly even endangers the goals they were designed 377 for. The issues is being discussed now in [I-D.dokaspar-6lowpan- 378 routreq]. 380 The other way is to develop a new routing protocol for 6LoWPAN. The 381 work is also being discussed in [I-D.culler-rsn-routing-reqs] and is 382 especially focused on sensor networks (e.g., RL2N: Routing For Low 383 Power and Lossy Networks). Considering the variety of sensor based 384 applications, there may not be a single routing protocol satisfying 385 the entire list of requirements, in which case it may be decided to 386 define a limited set of routing protocols that could be combined to 387 satisfy the overall objective. 389 4.2. Device Movement between Multiple WPAN DomainsS 391 In this scenario, MIPv6 [RFC3775] could be considered for mobility 392 solution. However, as listed in goals, RFDs should not to be 393 involved in any MIPv6 mobility related signaling and mobility 394 signaling messages in FFD should be reduced if possible. 396 To support efficiently this scenario, network-based mobility 397 management approach (e.g., Proxy MIPv6 [I-D.ietf-netlmm-proxymip6]) 398 would be preferred. 400 The goals of network-based mobility management approach [RFC 4831] 401 are: 403 o Handover Performance Improvement 405 o Reduction in Handover-Related Signaling Volume 407 o Location Privacy 409 o Limit Overhead in the Network 411 o Simplify Mobile Node Mobility Management Security by Deriving from 412 IP Network Access and/or IP Movement Detection Security 414 o Link Technology Agnostic 416 o Support for Unmodified Mobile Nodes 418 o Reuse of Existing Protocols Where Sensible 420 o Localized Mobility Management Independent of Global Mobility 421 Management 423 o Configurable Data Plane Forwarding between Local Mobility Anchor 424 and Mobile Access Gateway 426 Almost of the goal above fits to our goals for mobility support in 427 6LoWPAN described in section 2. 429 Host-based mobility protocols (e.g., MIPv6) require a number of 430 periodic signaling messages (e.g, Binding Update in MIPv6) at end 431 devices. It can increase power consumption. Network-based mobility 432 protocol (e.g., PMIPv6) does not require any mobility protocols in 433 end devices. Instead, gateway (CFD) performs mobility functions 434 (e.g., Proxy BU). 436 At this phase, current PMIPv6 defines the MN-MAG interface applied in 437 a single-hop [I-D.ietf-netlmm-mn-ar-if]. However, in this scenario, 438 multi-hop and wireless mesh topologies should be additionnally 439 considered. So, to use PMIPv6 in 6LoWPAN, the interface for multi- 440 hop and mesh topologies between devices and gateway (CFD) should be 441 extended and defined (e.g., ad-hoc manner, MANET, L2 routing, RL2N 442 support, etc.). 444 Thus, MN-MAG interface extensions for PMIPv6-6LoWPAN as shown in 445 Figure 6. It allows the MAG and/or 6LoWPAN devices to detect network 446 attachment and detachment and forward this detection to the gateway 447 (MAG) using existing MANET, RL2N or L2 (e,g, IEEE 802.15.4) routing, 448 causing the MAG to use the PMIPv6 protocol to update routing at the 449 LMA (Local Mobility Anchor) so that the end sensor node stays 450 reachable when it roams across the WPAN domain. 452 In general, in the absence of a L2 specific mechanisms to implement 453 the 6LoWPAN devices - MAG interface, it is required to have a common 454 interface defined at the L3 layer. Because no PMIPv6 specific 455 software support is assumed to be present on 6LoWPAN devices, this 456 interface has to rely only on standard tracks IPv6 protocols such as 457 ND, DHCP, SEND, and DNA. However, for the interface for multi-hop 458 and mesh topologies between devices and gateway (CFD) existing MANET, 459 RL2N or L2 (e,g, IEEE 802.15.4) routing should be applied. 461 6LoWPAN-MAG 462 Interface extension 463 | 465 | +------------+ +----------+ 466 | | | | 467 | | +--------+ | | +------+ | 468 | | PMIPv6 |<-------->|PMIPv6| | 469 | | +--------+ | | +------+ | 470 | ^ ^ | | ^ | 471 +----------+ | | | | | | | | 472 | | | v | | | | | 473 | +------+ | | | +-----+ | | | | | 474 | | MANET| | | |MANET| | | | | | 475 | | L2 Rt|<------|------>|L2 Rt| | | | | | 476 | | RL2N | | | |RL2N | | | | | | 477 | +------+ | | +-----+ | | | | | 478 | ^ | | | ^ | | | | | 479 | | | | | | | | | | 480 | v | | | v | | | v | 481 | +------+ | | +----+ | | | +------+ | 482 | | | | | | | |<-+ | | | | | 483 | | | | IPv6 | | | | IPv6 | | | | 484 | | IPv6 |<------|------>|IPv6|<------------>| IPv6 | | 485 | +------+ | | +----+ | | +------+ | 486 | 6LoWPAN | | | | | | 487 | device | | MAG | | LMA | 488 +----------+ | +------------+ +----------+ 490 | 492 Figure 6: 6LoWPAN-MAG interface extensions 494 4.3. Single WPAN movement (NEMO) 496 This scenario is exactly the same as that of NEMO. NEMO support 497 [I-D.ietf-nemo-requirements] is concerned with managing the mobility 498 of an entire network, viewed as a single unit, which changes its 499 point of attachment to the Internet and thus its reachability in the 500 Internet topology. Such a network is referred to as a mobile network 501 and includes one or more mobile routers (MRs) which connect it to the 502 global Internet. So, in this scenario a mobility network and MRs are 503 mapped into WPAN and CFDs, respectively. 505 To support this scenario, basic NEMO support protocol [RFC3963] 506 should be supported in 6LoWPAN. 508 4.4. MANEMO - Nested NEMO 510 MANEMO is a special case for Nested NEMO. When mobile routers (CFDs) 511 and mobile nodes (RFDs/FFDs) converge at the edge of the Internet 512 using wireless interfaces, they can form a 6LoWPAN network in an ad- 513 hoc fashion and are able to provide Internet connectivity to one 514 another. Several issues exist in this network configuration such as 515 network loop, un-optimized path and multiple exit routers to the 516 Internet. They are well-known MANEMO' issues. While fixed routers 517 provide constantly connectivity, mobile routers (CFDs) can experience 518 intermittent connectivity to the Internet due to their movement. 519 When NEMO Basic Support [RFC3963] is used in this context, network 520 loops naturally occur. So, a new MANEMO solution is required in 521 6LoWPAN. 523 MANEMO solution is not finalized yet and it is at initial stage. 524 When it is done, to support this scenario, it should be also 525 supported in 6LoWPAN. 527 5. IANA Considerations 529 This document requests no action by IANA. 531 6. Security Considerations 533 RFD nodes must have a means of identifying friendly nodes and 534 distinguishing them from not trusted nodes. Especially if the RFDs' 535 mobility support is handled by an FFD or CFD, there must be some way 536 for the RFD to tell whether that more capable device can be trusted 537 or not. 539 More to be defined. 541 7. Acknowledgements 543 TBD 545 8. References 547 8.1. Normative References 549 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 550 Requirement Levels", BCP 14, RFC 2119, March 1997. 552 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 553 (IPv6) Specification", RFC 2460, December 1998. 555 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 556 Discovery (ND) Trust Models and Threats", RFC 3756, 557 May 2004. 559 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 560 in IPv6", RFC 3775, June 2004. 562 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 563 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 564 RFC 3963, January 2005. 566 8.2. Informative References 568 [RFC4831] Kempf, J., "Goals for Network-Based Localized Mobility 569 Management (NETLMM)", RFC 4831, April 2007. 571 [RFC4886] Ernst, T., "Network Mobility Support Goals and 572 Requirements", RFC 4886, July 2007. 574 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 575 over Low-Power Wireless Personal Area Networks (6LoWPANs): 576 Overview, Assumptions, Problem Statement, and Goals", 577 RFC 4919, August 2007. 579 [I-D.dokaspar-6lowpan-routreq] 580 Kaspar, D., "Problem Statement, Design Goals and 581 Requirements for 6LoWPAN Mesh Routing", 582 draft-dokaspar-6lowpan-routreq-02 (work in progress), 583 July 2007. 585 [I-D.ietf-netlmm-proxymip6] 586 Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 587 and B. Patil, "Proxy Mobile IPv6", 588 draft-ietf-netlmm-proxymip6-07 (work in progress), 589 November 2007. 591 [I-D.chakrabarti-mobopts-lowpan-req] 592 Park, S. and S. Chakrabarti, "LowPan Mobility Requirements 593 and Goals", draft-chakrabarti-mobopts-lowpan-req-01 (work 594 in progress), March 2007. 596 [I-D.ietf-netlmm-mn-ar-if] 597 Narayanan, S. and J. Laganier, "Network-based Localized 598 Mobility Management Interface between Mobile Node and 599 Mobility Access Gateway", draft-ietf-netlmm-mn-ar-if-02 600 (work in progress), May 2007. 602 Authors' Addresses 604 Myung-Ki Shin 605 ETRI 606 161 Gajeong-dong Yuseng-gu 607 Daejeon, 305-350 608 Korea 610 Phone: +82 42 860 4847 611 Email: myungki.shin@gmail.com 613 Tiago Camilo 614 University of Coimbra 616 Email: tandre@dei.uc.pt 618 Jorge Sa Silva 619 University of Coimbra 621 Email: sasilva@dei.uc.pt 623 Dominik Kaspar 624 ETRI 625 161 Gajeong-dong Yuseng-gu 626 Daejeon, 305-350 627 Korea 629 Phone: +82 42 860 1702 630 Email: dominik@etri.re.kr 632 Full Copyright Statement 634 Copyright (C) The IETF Trust (2007). 636 This document is subject to the rights, licenses and restrictions 637 contained in BCP 78, and except as set forth therein, the authors 638 retain all their rights. 640 This document and the information contained herein are provided on an 641 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 642 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 643 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 644 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 645 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 646 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 648 Intellectual Property 650 The IETF takes no position regarding the validity or scope of any 651 Intellectual Property Rights or other rights that might be claimed to 652 pertain to the implementation or use of the technology described in 653 this document or the extent to which any license under such rights 654 might or might not be available; nor does it represent that it has 655 made any independent effort to identify any such rights. Information 656 on the procedures with respect to rights in RFC documents can be 657 found in BCP 78 and BCP 79. 659 Copies of IPR disclosures made to the IETF Secretariat and any 660 assurances of licenses to be made available, or the result of an 661 attempt made to obtain a general license or permission for the use of 662 such proprietary rights by implementers or users of this 663 specification can be obtained from the IETF on-line IPR repository at 664 http://www.ietf.org/ipr. 666 The IETF invites any interested party to bring to its attention any 667 copyrights, patents or patent applications, or other proprietary 668 rights that may cover technology that may be required to implement 669 this standard. Please address the information to the IETF at 670 ietf-ipr@ietf.org. 672 Acknowledgment 674 Funding for the RFC Editor function is provided by the IETF 675 Administrative Support Activity (IASA).