idnits 2.17.1 draft-chakrabarti-mobopts-lowpan-req-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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 294. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 305. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 312. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 318. 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 -- 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 (March 1, 2007) is 6259 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) == Unused Reference: '4' is defined on line 256, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 259, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 262, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-6lowpan-format-10 == Outdated reference: A later version (-08) exists of draft-ietf-6lowpan-problem-07 ** Downref: Normative reference to an Informational draft: draft-ietf-6lowpan-problem (ref. '2') -- No information found for draft-chakrabarti-6lowpan-nd - is the name correct? -- Possible downref: Normative reference to a draft: ref. '3' -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. '4') (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 3041 (ref. '5') (Obsoleted by RFC 4941) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Chakrabarti 3 Internet-Draft Azaire Networks 4 Expires: September 2, 2007 S. Daniel Park 5 SAMSUNG Electronics 6 March 1, 2007 8 LowPan Mobility Requirements and Goals 9 draft-chakrabarti-mobopts-lowpan-req-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 2, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 IETF LowPan working group defines IPv6 over low-power personal area 43 network (IEEE 802.15.4). Lowpan architecture allows routing to take 44 place at the link layer in order to save payload overhead over the 45 IEEE 802.15.4 link and thus more efficient routing for low power, low 46 data-rate networks such as sensor networks. This document discusses 47 a few scenarios of mobility in LowPan network and states mobility 48 requirements and goals for LowPan networks. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Goals of mobility in LowPan . . . . . . . . . . . . . . . . . 4 54 3. Requirements of mobility in LowPan . . . . . . . . . . . . . . 5 55 4. Possible Scenarios of Mobility in 6lowPan . . . . . . . . . . 7 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 58 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 59 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 60 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 61 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 63 Intellectual Property and Copyright Statements . . . . . . . . . . 13 65 1. Introduction 67 The IPv6-over-IEEE 802.15.4 [1] document has specified IPv6 headers 68 carrying over IEEE 802.15.4 network with the help of a adaptation 69 layer which sits between the MAC layer and the network layer. The 70 LowPan network is characterized by low-powered, low bit-rate, short 71 ranged, low cost network. The LowPan payload capability is between 72 102 bytes to 81 bytes depending on usage of link-layer security. 73 Hence usage of 128bit uncompressed IPv6 address in undesirable in the 74 network. LowPan networks are typically ad-hoc in nature and several 75 multihop routing algorithms such as RFC3561, RFC3626, RFC3684 may be 76 partially applied to LowPan network. However, the above mentioned 77 mobile ad-hoc network protocols are designed for IP network which is 78 different from the nature of LowPan network including data-rate, 79 power efficiency, payload capability and routing layers. The LowPan 80 goals and requirements [2] also state that the routing packets should 81 fit within a single IEEE 802.15.4 frame. 83 The IPv6-over-IEEE 802.15.4 [1] document provides mesh routing 84 capability at the link layer. Yet each node is configured with IPv6 85 addresses. Thus a IEEE 802.15.4 may look like one single IPv6 subnet 86 to the IP layer. It may be an auto-configuration issue how IPv6 87 addresses are configured, the mobility cases still need to consider 88 IPv6 addresses and IEEE 802.15.4 MAC addresses for routing. 90 In this document, we are considering mobility within a isolated 91 network across different IEEE 802.15.4 Personal area networks and 92 movement across different IPv6-over-IEEE 802.15.4 networks. 94 2. Goals of mobility in LowPan 96 o A lowpan node which participates in forwarding packet from its 97 neighbor, may no longer be available to forward packet if it moves 98 away from its neighbor's range of wireless transmission. Thus the 99 sender of the packet needs to find an alternate route if the 100 forwarder node becomes unreachable. 102 o A lowpan node should be reachable by another lowpan node or a 103 global network node even if it moves from one personal area 104 network to another. 106 o A lowpan node or a group of lowpan nodes comprising a IEEE 107 802.15.4 network may be able to keep continuous connectivity while 108 moving across different personal area networks depending on the 109 application requirements. 111 o Due to the nature of instability in the LowPan or sensor networks, 112 the protocol design must take consideration in distributed storage 113 of inforamtion rather than conventional central repository or 114 server style architecture. 116 o In order to protect the resources in the low-power networks, node 117 authentication and authorization may be necessary for joining the 118 network. An efficient protocol design should consider security as 119 part of the features. 121 3. Requirements of mobility in LowPan 123 o A lowpan node has a IPv6 address (global or link-local) as well as 124 IEEE 802.15.4 MAC address. 126 o A lowpan node in a isolated IEEE802.15.4 network that has no 127 connectivity outside itself, does not require to have global IPv6 128 address configuration.If the routing of packets are performed at 129 the lowpan layer using M bit, then only link-local address 130 configuration is sufficient. 132 o When a lowpan node moves from one personal area network(6lowpan) 133 to another, it should immediately inform the new PAN co-ordinator 134 about its presence. The PAN co-ordinator through its IPv6 router 135 should inform the previous IPv6 router about the new IPv6 address 136 of the new node that was present in the old-lowpan network. Thus 137 it is possible that the roaming node can still talk to its 138 corresponder at the old-lowpan network. 140 o A inter-6lowpan gateway protocol is needed to comunicate the new 141 location (IPv6 global prefixes) of the roaming 6lowpan node which 142 moves across different 6lowpan networks 144 o The original IPv6 gateway is responsible for buffering and 145 forwarding packets directly destined to the moved lowpan node, if 146 there is already a communication in place during the node 147 movement. If the moved lowpan node was used as a L2-forwarder at 148 the previous location then it is no longer used as a forwarder for 149 the old-lowpan network. However, a moved lowpan node can continue 150 being a forwarder for the same packet-path, if it moves within the 151 same 6lowpan network and its reachability from the sender node 152 remains the same or better. 154 o For global connectivity with the Internet, a lowpan node or a 155 group of lowpan node must be addressed by a global IPv6 address. 156 Since 6lowpan network assumes that there is one IPv6 router per 157 6lowpan network, the IPv6 router is responsible for providing the 158 global addresses to each node in the 6lowpan network. 160 o The movement of a 6lowpan node with an IPv6 address can be 161 transparent to a correspondent IPv6 node external to the 6lowPan 162 network, if the movement happens within the 6lowpan network, i.e. 163 when the nodes IPv6 global address does not change. 165 o As with any network, the movement of a lowpan node may introduce 166 security threats in the old and new LowPan Networks. Thus, 167 authentication of mobile lowpan node is required when it updates 168 the movement information to the new and old IPv6 6lowpan routers 169 or local IPv6 routing group-leaders. 171 o The lowpan nodes must be able to detect its movement from one 172 wireless LowPan to another correctly. This may require multiple 173 hints from signal strength measurement to packet reception 174 capacity and location or neighborhood assessment. In addition, 175 the group security key and key distributor information may be used 176 as one of the attributes for movement across 6lowpan network. 178 o A 6lowpan network may be attached to a mobile network through a 179 IPv6 router. For example, in a vehicle, a few 6lowpan networks 180 are connected through some Wifi access points to the operator's 181 network or Internet. The vehicle transmits data to a central 182 location via Internet or operator's network. In this case, there 183 could be 2 scenarios - 1) the 6lowpan nodes are always inside the 184 vehicle and they are stationary. 2) the 6lowpan nodes move and 185 join/detatch different 6lowpan networks within the vehicle 3) A 186 6lowpan network may step out of the vehicle and find a different 187 wireless access point to talk to the Internet. 189 4. Possible Scenarios of Mobility in 6lowPan 191 Mobility within a 6LowPan - It is assumed that the LowPan network is 192 comprised of a single 6lowpan network. A 6lowpan network is composed 193 of one IPv6 router at the top and bunch of co-ordinators, full- 194 functional devices and reduced-functional devices. The data routing 195 from one node to another node happens at the L2-layer using IEEE 196 802.15.4 MAC addresses. The global IPv6 addresses are however 197 assigned by the IPv6 router and the IPv6 router is also responsible 198 for Neighbor discovery [3] process. A 6LowPan network can be a 199 isolated network or it may be connected to a global network with a 200 network layer gateway[3]. 202 Mobility across two different 6lowPan networks- A lowpan node moves 203 from IEEE802.15.4 network to a mesh network. Assume that these two 204 6LowPan networks are interconnected. Routing function takes place at 205 the network-layer between the two IPv6-routers or gateways and the 206 packet routing takes place at the link-layer within a 6lowpan network 207 across different 6lowpan nodes. 209 Mobility across LowPan and other wireless network - A multi- 210 interfaced node may have IEEE802.15.4 radio for LowPan network and 211 other wireless radio for communicating on the regular Internet or a 212 different type of wireless network. These devices often act as 213 gateways. A lowpan gateway can be mobile. 215 Moving of a 6lowpan node from one 6lowpan network to another 6lowpan 216 network across the Internet is another example of mobility across 217 6LowPan networks. 219 6lowpan networks may be attached to a mobile Wireless network (NEMO). 220 A 6lowpan network may be reachable by a fixed entity in the Internet 221 while it is moving along with the mobile network as in NEMO. 223 5. Security Considerations 225 Security considerations for the mobility in LowPan networks are 226 discussed in the "Requirements" section above. 228 6. IANA Considerations 230 No actions are required by IANA for this document. 232 7. Acknowledgements 234 The author likes to thank Rajeev Koodli for initial discussion about 235 this document. 237 8. References 239 8.1. Normative References 241 [1] Montenegro, G. and N. Kushalnagar, "Transmission of IPv6 Packets 242 over IEEE 802.15.4 networks", draft-ietf-6lowpan-format-10.txt 243 (work in progress), February 2007. 245 [2] Kushalnagar, N. and G. Montenegro, "6LoWPAN: Overview, 246 Assumptions, Problem Statement and Goals", 247 draft-ietf-6lowpan-problem-07.txt (work in progress), 248 February 2007. 250 [3] Chakrabarti, S. and N. Nordmark, "6LowPan Neighbor Discovery 251 Extensions", draft-chakrabarti-6lowpan-nd-03.txt (work in 252 progress), March 2007. 254 8.2. Informative References 256 [4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6), 257 Specification", RFC 2460, December 1998. 259 [5] Narten, T. and R. Draves, "Privacy Extensions for Stateless 260 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 262 [6] IEEE Computer Society, "IEEE Std. 802.15.4-2003", , 263 October 2003. 265 Authors' Addresses 267 Samita Chakrabarti 268 Azaire Networks 269 3121 Jay Street, Suite 210 270 Santa Clara, CA 271 USA 273 Email: Samita.Chakrabarti@azairenet.com 275 Soohong Daniel Park 276 Mobile Platform Laboratory, SAMSUNG Electronics. 278 Email: soohong.park@samsung.com 280 Full Copyright Statement 282 Copyright (C) The IETF Trust (2007). 284 This document is subject to the rights, licenses and restrictions 285 contained in BCP 78, and except as set forth therein, the authors 286 retain all their rights. 288 This document and the information contained herein are provided on an 289 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 290 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 291 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 292 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 293 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 294 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 296 Intellectual Property 298 The IETF takes no position regarding the validity or scope of any 299 Intellectual Property Rights or other rights that might be claimed to 300 pertain to the implementation or use of the technology described in 301 this document or the extent to which any license under such rights 302 might or might not be available; nor does it represent that it has 303 made any independent effort to identify any such rights. Information 304 on the procedures with respect to rights in RFC documents can be 305 found in BCP 78 and BCP 79. 307 Copies of IPR disclosures made to the IETF Secretariat and any 308 assurances of licenses to be made available, or the result of an 309 attempt made to obtain a general license or permission for the use of 310 such proprietary rights by implementers or users of this 311 specification can be obtained from the IETF on-line IPR repository at 312 http://www.ietf.org/ipr. 314 The IETF invites any interested party to bring to its attention any 315 copyrights, patents or patent applications, or other proprietary 316 rights that may cover technology that may be required to implement 317 this standard. Please address the information to the IETF at 318 ietf-ipr@ietf.org. 320 Acknowledgment 322 Funding for the RFC Editor function is provided by the IETF 323 Administrative Support Activity (IASA).