idnits 2.17.1 draft-chakrabarti-6lowpan-ipv6-nd-simple-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 and authors Copyright Line does not match the current year -- The document date (March 1, 2010) is 5170 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) -- Looks like a reference, but probably isn't: 'RFC 3756' on line 661 == Unused Reference: '4' is defined on line 696, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 702, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 708, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 718, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4919 (ref. '4') -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. '5') (Obsoleted by RFC 8200) == Outdated reference: A later version (-03) exists of draft-ietf-autoconf-adhoc-addr-model-02 == Outdated reference: A later version (-05) exists of draft-daniel-6lowpan-security-analysis-02 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6LoWPAN WG S. Chakrabarti 3 Internet-Draft IP Infusion 4 Expires: September 2, 2010 E. Nordmark 5 Oracle, Inc. 6 March 1, 2010 8 IPv6 LoWPAN Neighbor Discovery and Addressing Choices 9 draft-chakrabarti-6lowpan-ipv6-nd-simple-00.txt 11 Abstract 13 IETF 6LoWPAN working group defines IPv6 over low-power personal area 14 network (IEEE 802.15.4). IEEE 802.15.4 and other low-power wireless 15 networks have limited or no usage of broadcast or multicast signaling 16 due to energy conservation. Besides the wireless nodes may not 17 strictly follow traditional concept of IP subnet and IP-links while 18 connecting nodes and routers. This document describes simple 19 optimizations to IPv6 Neighbor Discovery protocol(RFC4861), and 20 addressing mechanisms that are useful for small scale 6LoWPAN 21 networks in star and mesh topologies. 23 The optimizations include reducing the amount of Neighbor Discovery 24 multicast traffic and allowing for a single subnet to span multiple 25 routers in a "route-over" topology. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on September 2, 2010. 50 Copyright Notice 52 Copyright (c) 2010 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the BSD License. 65 Table of Contents 67 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 68 1.1. IPv6 Neighbor Discovery shortcomings in low-power 69 wireless network . . . . . . . . . . . . . . . . . . . . . 3 70 1.2. Address Allocation Options in 6LoWPAN . . . . . . . . . . 4 71 1.3. Mesh-under and Route-over Concept and Behavior . . . . . . 4 72 2. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . 6 73 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 7 75 5. Autoconfiguration of 6LoWPAN Addresses . . . . . . . . . . . . 8 76 5.1. Address Assignment in Star Networks . . . . . . . . . . . 8 77 5.2. Address Assignment in Mesh Network . . . . . . . . . . . . 8 78 5.3. DHCPv6 Address and Resource Allocation . . . . . . . . . . 8 79 6. New Neighbor Discovery options . . . . . . . . . . . . . . . . 8 80 6.1. Authoritative Router option . . . . . . . . . . . . . . . 9 81 6.2. Node-lifetime option . . . . . . . . . . . . . . . . . . . 10 82 7. Optimized Neighbor Discovery for 6LoWPANs . . . . . . . . . . 10 83 7.1. Operations Overview . . . . . . . . . . . . . . . . . . . 11 84 7.2. Existing Neighbor Discovery Messages . . . . . . . . . . . 11 85 7.3. 6LoWPAN Optimized Neighbor Discovery Messages . . . . . . 11 86 7.4. Host Behavior . . . . . . . . . . . . . . . . . . . . . . 12 87 7.5. 6LBR Behavior . . . . . . . . . . . . . . . . . . . . . . 13 88 7.6. 6LR Behavior . . . . . . . . . . . . . . . . . . . . . . . 13 89 8. Remaining Multicast messages . . . . . . . . . . . . . . . . . 14 90 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 91 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 92 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 93 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 94 12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 95 12.2. Informative References . . . . . . . . . . . . . . . . . . 15 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 98 1. Introduction and Overview 100 The IPv6-over-IEEE 802.15.4 [3] document specifies IPv6 headers 101 carried over IEEE 802.15.4 network with the help of an adaptation 102 layer which sits between the MAC layer and the IP network layer. The 103 LoWPAN network is characterized by low-powered, low bit-rate, short 104 ranged, low cost nodes. Thus, all-node multicast defined in Neighbor 105 Discovery [2] may be unsuitable in the LoWPAN network which does not 106 have direct multicast support at the link-layer. Broadcast messages 107 could be used in some cases to represent all-node multicast messages, 108 but periodic broadcast messages should be minimized in the LoWPAN 109 network in order to conserve energy. 111 This document provides an overview of IPv6 Neighbor Discovery options 112 and describes a base mechanism for optimized 6LoWPAN neighbor 113 discovery mechanism. 115 The optimizations include reducing the amount of Neighbor Discovery 116 multicast traffic and allowing for a single subnet to span multiple 117 routers in a "route-over" topology. 119 1.1. IPv6 Neighbor Discovery shortcomings in low-power wireless network 121 IPv6 ND [2] is based on multicast signaling messages on the local 122 link in order to avoid broadcast messages. Following power-on and 123 initialization of the network in IPv6 Ethernet networks, a node joins 124 the solicited-node multicast address on the interface and then 125 performs duplicate address detection (DAD) for the acquired link- 126 local address by sending a solicited-node multicast message to the 127 link. After that it sends multicast router solicitation (RS) 128 messages to the all-router address to solicit router advertisements. 129 Once the host receives a valid router advertisement (RA) with the "A" 130 flag, it autoconfigures the IPv6 address with the advertised prefix 131 in the router advertisement (RA). Besides this, the IPv6 routers 132 usually send router advertisements periodically on the network. RAs 133 are sent to the all-node multicast address. Nodes send Neighbor 134 Solicitation (NS) and Neighbor Advertisement (NA) messages to resolve 135 the IPv6 address of the destination on the link. These NS/NA 136 messages are also often multicast messages and it is assumed that the 137 node is on the same link and relies on the fact that the destination 138 node is always powered and generally available. 140 In 6LoWPAN 802.15.4 network, primarily two types of configurations 141 are used - 1) Star network and 2) Mesh network. A star network is 142 similar to regular IPv6 subnet with a router and a set of nodes 143 connected to it via the same link. But in low-power mesh networks, 144 the nodes are capable of routing and forwarding packets but due to 145 lossy nature of wireless communication, the IPv6-link node sets may 146 change due to external physical factors and thus the link and 147 connection becomes unreliable. 149 Thus optimizing the regular IPv6 Neighbor Discovery [2] to minimize 150 total number of related signaling messages without loosing generality 151 of Neighbor Discovery and autoconfiguration and making host and 152 router communication reliable, is desirable in 6LoWPAN mesh 153 configuration. 155 1.2. Address Allocation Options in 6LoWPAN 157 As 6LoWPAN and IEEE 802.15.4 technologies are evolving we can 158 anticipate that regular IPv6 ND [2] might be used in some 159 configuration where the physical medium and hardware support higher 160 bandwidth and processing power with low-power consumption. 162 Thus the following options of address allocations are envisioned in a 163 6LoWPAN network depending on the configuration and network capacity. 165 o Address allocation through multicast IPv6 Neighbor Discovery [2] 166 and IPv6 Autoconfiguration [6] with tuned parameters for 6LoWPAN 167 usage. The Neighbor Discovery and autoconfiguration parameters 168 are configurable on the basis of deployment requirement(example: 169 when all 6LoWPAN nodes are one-hop away from the IPv6 router). 170 o A simplified DHCPv6 method for IPv6 address allocation in a 171 6LoWPAN network. This is useful for a star network and mesh 172 network where all the nodes are in reachable range of the DHCPv6 173 server. DHCPv6 services SHOULD be used for assigning IPv6- 174 addresses using 16-bit short MAC addresses described in IEEE 175 802.15.4 [9] in order to ensure uniqueness of IPv6 addresses. 176 o An optimized 6LoWPAN Neighbor Discovery is recommended for 177 efficiency and power savings for the low-power and lossy wireless 178 mesh networks. The simple optimization of IPv6 Neighbor 179 Discovery[2] for low-power network in this document. This 180 mechanism SHOULD be used for efficient handling of signaling 181 messages in the 6LoWPAN mesh and star networks using nodes with 182 EUI-64 MAC addresses. 184 It is noted that all the above address allocation methods MUST follow 185 the address allocation principles described in [8]. 187 1.3. Mesh-under and Route-over Concept and Behavior 189 In 6LoWPAN network context, often the link-layer mesh routing 190 mechanism for carrying IP packets as a data message is referred as 191 "mesh-under" while routing/forwarding packets using IP-layer 192 addresses are referred as "route-over". The difference between mesh- 193 under and route-over networks is similar to a bridged-network and IP- 194 routing network in the Ethernet. Thus, in a mesh-under network all 195 nodes are considered part of an IPv6 subnet when a 6LoWPAN network is 196 considered as one IPv6 subnet served by one or more 6LoWPAN border 197 routers (6LBR). The 6LBR could also be a gateway to the legacy IPv4 198 or IPv6 network. 200 In a route-over network, there are multiple IPv6 subnets connecting 201 to each other in a 6LoWPAN network. However, unlike fixed IP 202 networks, these subnet members may be changing due to the nature of 203 the low-power and lossy behavior of wireless LoWPANs. Thus a route- 204 over network is almost always a flexible set of mesh networks. The 205 design considerations are based on the above properties. The 206 optimized 6LoWPAN neighbor discovery are applicable to both "mesh- 207 under" and "route-over" implementations. However, in "route-over" 208 networks, we like to define two types of routers - 6LoWPAN border 209 Routers(6LBR) and 6LoWPAN-routers(6LR). 6LoWPAN border Routers sit at 210 the boundary of the 6LoWPAN and the backbone network while 6LoWPAN- 211 routers are inside the 6LoWPAN network and they can not communicate 212 to a different network routers directly. The 6LoWPAN-routers are 213 assumed to be running a routing protocol. In "route-over" 214 configuration, the hosts are unable to take part in routing and 215 forwarding packets and they are acting as simple IPv6 hosts. 217 These neighbor discovery optimizations for "mesh-under" configuration 218 where the 6LBR is acting as the IPv6 router where all the hosts in 219 6LoWPAN are part of one subnet and they are only one IP hop away and 220 no 6LR concept exist in "mesh-under" topology. Thus, the IPv6 packet 221 is carried as the data via a link-layer mesh routing protocol. 223 When "route-over" configuration is used, the IPv6 Neighbor Discovery 224 operation takes place between the requesting node and the 6LRs or 225 6LBRs. The 6LR nodes are able to send and receive Router 226 Advertisements, Router Solicitations as well as forward and route 227 IPv6 packets. The packet forwarding happens at the routing layer. 229 With "route-over" there is a need to allow a host to attach to 230 different 6LRs over time (e.g., to handle changes in the radio 231 conditions) while the host keeps the same IPv6 addresses. Thus one 232 (or more) subnet prefixes (see [8]) should be assigned to the 233 6LoWPAN. This implies that a 6LRs need to reliably know which IP 234 addresses are directly reachable from that particular 6LR; this 235 information will be used by the routing protocol that is used by the 236 6LRs and 6LBRs. 238 This document assumes that an implementation will have configuration 239 knobs to determine whether it is running in "mesh-under" mode or 240 "route-over" mode if the implementation supports both mechanisms. 242 2. Definition Of Terms 244 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 245 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 246 document are to be interpreted as described in [1]. 248 6LoWPAN-link: 249 It is a wireless link determined by single hop reachability of 250 neighboring nodes. 251 6LoWPAN-router (6LR): 252 These are the intermediate routers in the 6LoWPAN network who can 253 communicate with other 6LoWPAN-routers in the same 6LoWPAN 254 network. These are also the immediate first-hop router for 255 6LoWPAN hosts. 6LoWPAN routers are present only in "route-over" 256 topologies. 257 6LoWPAN Border Router (6LBR): 258 It is a border router located at the junction of separate 6LoWPAN 259 networks or between a 6LoWPAN network and a non-6LoWPAN IP 260 network. There may be one or more 6LBR at the 6LoWPAN network 261 border. 6LBR is the responsible authority for IPv6 Prefix 262 propagation for the 6LoWPAN network it is serving. An isolated 263 6LoWPAN network also contains a 6LBR in the network, which 264 provides the prefix(es) for the isolated network. 265 Host: 266 A host in 6LoWPAN network is considered a IPv6 node without 267 routing and forwarding capability. 268 Mesh-under: 269 It is a configuration topology where 6LoWPAN hosts are connected 270 to the 6LBR through a mesh using Layer-2 forwarding. Thus in a 271 "mesh-under" configuration all IPv6 hosts in a 6LoWPAN network are 272 only one IP hop away from the 6LBR. This topology simulates the 273 typical IP-subnet topology with one router with multiple nodes in 274 the same subnet. 275 Route-over: 276 It is a configuration topology where 6LoWPAN hosts are connected 277 to the 6LBR through the use of intermediate Layer-3 (IP) routing. 278 Here hosts are typically multiple IP hops away from the 6LBR. The 279 Route-over topology typically consists of a 6LBR, a set of 6LRs 280 and possibly some hosts. 282 3. Assumptions 284 o 6LBRs are capable of routing/forwarding packets between 6LoWPAN 285 networks and other networks. The 6LBRs are responsible for 286 assigning one or more /64 IPv6 prefix to the 6LoWPAN network. It 287 advertises this/these IPv6 prefixes to the 6LoWPAN network. 289 o The 6LR that are in range of 6LBR use the prefixes advertised by 290 the the 6LBR. The 6LRs store these prefixes and use them for 291 forming its own global autoconfigured addresses. When sending 292 Router Advertisements, 6LRs advertise the same prefix(es). A 293 6LoWPAN-router SHOULD relay any prefix related options received 294 from its parent router during Neighbor Discovery procedure. 295 o The 6LoWPAN hosts either autoconfigure their IPv6 address(es) 296 based on the prefix(es) received in the Router Advertisement, or 297 it uses DHCP service for address assignment. It can receive 298 multiple Router Advertisements and should be able to configure 299 multiple default routers as its immediate nexthop. The 6LoWPAN 300 hosts always send their packets to the default router. If one 301 default router becomes unavailable, it chooses the next available 302 default router. This behavior is the same as standard IPv6 hosts 303 behavior. 304 o In an isolated 6LoWPAN network an ULA prefix and address SHOULD be 305 generated by the 6LBR. Thus in this topology, 6LBR prefix is 306 formed according to [11]. 307 o The Prefix Options send by 6LBRs and 6LRs do not set the 'L' flag. 308 This is necessary to get the hosts to send packets to (one of) 309 their default router(s). 310 o The local mobility or mobility within a 6LoWPAN is supported in 311 this solution by using the same IPv6 prefix across the 6LoWPAN. 313 4. Applicability Statement 315 This document aims to guide the implementors to choose an appropriate 316 IPv6 neighbor discovery and Address configuration procedures suitable 317 for a 6LoWPAN network. If the 6LoWPAN network does not have 318 Multicast capability at the link-layer, then it SHOULD use the 319 Optimized IPv6 Neighbor Discovery for the 6LoWPAN network. 321 This document does not specify a method for ensuring address 322 uniqueness across a LoWPAN. In general such a mechanism is needed 323 for the IPv6 addresses autoconfigured in the subnet prefix(es). In 324 the general case of ND we use multicast Neighbor Solicitation to 325 perform Duplicate Address Detection (DAD) [6] but that is both 326 undesirable in a 6LoWPAN due to the undesirability of multicast 327 packets, and insufficient in the case of "route-over" when the subnet 328 prefix spans several links and 6LRs. 330 The scope of this document is limited to addresses that are 331 autoconfigured based on EUI-64 based Interface-ids. For such 332 addresses DAD is not required. Other IPv6 addresses, including those 333 based on 16-bit IEEE 802.15.4 short addresses, are out of scope. 334 Potentially DHCPv6 can be used to allocate unique addresses for short 335 addresses. 337 5. Autoconfiguration of 6LoWPAN Addresses 339 The following discussion will include address auto-configuration 340 procedure at the IP-layer. 342 5.1. Address Assignment in Star Networks 344 In a star network, all the nodes are one hop away from the IPv6- 345 router and from each-other. Upon starting a node sends an IPv6 ND 346 [2] Router Solicitation (RS) to the All-Routers multicast address. 347 The 6LBR sends unicast Router Advertisement (RA) and the node 348 configures its IPv6 address using autoconfiguration [6]. If the 349 nodes are using EUI-64 style MAC address, the Duplicate Address 350 Detection SHOULD be skipped. The 6LBR is assumed to be the only 351 router in the 6LoWPAN network - thus it should use a unique id, for 352 example IEEE 802.15.4 PAN-ID as its subnet-id of the IPv6-address. 354 If the node uses a short(16-bit) MAC addresses, address assignment 355 through DHCP is advised. 357 5.2. Address Assignment in Mesh Network 359 In a "mesh-under" configuration, the nodes are considered one hop 360 away. Thus address assignment/auto-configuration happens the same 361 way as in Star Network configuration. However, 6LBR is acts as an 362 Prefix authority and initial delegator of that prefix. 364 In a "route-over" configuration, one or more 6LBR advertise the 365 global prefix(es) along with a new IPv6 Router Advertisement option 366 called Authoritative Router option. This option contains information 367 about the 6LBR IP-address and a sequence number. The next-level 6LR 368 receive the RA from 6LBR and store/auto-config with the advertised 369 prefix. The received prefix from 6LBR and the new Authoritative 370 Router option option are then propagated throughout the 6LoWPAN 371 network hop by hop. The hosts use the address prefix to configure 372 the address when they receive the Router Advertisements from their 373 respective Neighborhood 6LR. 375 5.3. DHCPv6 Address and Resource Allocation 377 DHCP address allocation procedure for 6LoWPAN is out of scope of this 378 document. 380 6. New Neighbor Discovery options 382 The optimized ND uses two new Neighbor Discovery options - 383 Authoritative Router option option and Node-lifetime option. 385 6.1. Authoritative Router option 387 The Prefix Information options originate at the 6LBRs and are 388 propagated by the 6LRs. Thus 6LRs receive Prefix Information options 389 from other 6LRs. This implies that we can't just have the most 390 recently received RA win. In order to be able to reliably remove 391 prefixes from the 6LoWPAN we need to carry information from the 392 authoritative 6LBR. We do that by introducing a sequence number 393 which the 6LRs propagate as they propagate the prefixes. When there 394 are multiple 6LBRs they would have a separate sequence number spaces. 395 Thus we need to carry the IP address of the 6LBR that created the 396 sequence number. 398 The Authoritative Router option is included in Router Advertisement 399 messages. It is required in "route-over" configurations. 401 0 1 2 3 402 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Type | Length = 3 | Reserved | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Sequence Number | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | | 409 + + 410 | | 411 + 6LBR Address + 412 | | 413 + + 414 | | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 ~ Address[1] etc ~ 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 Fields: 420 Type: TBD [To be allocated by the IANA.] 421 Length: 8-bit unsigned integer. The length of the option in 422 units of 8 octets. Always 3. 423 Reserved: 16-bits. This field is unused. It MUST be 424 initialized to zero by the sender and MUST be ignored 425 by the receiver. 426 Registration Period: 32-bit unsigned integer. The amount of time in 427 seconds between successive registration messages for 428 the same IP address. 430 6LBR Address: IP address of 6LBR that is authoritative for the 431 sequence number. 433 6.2. Node-lifetime option 435 The 6LRs need to know the set of IP addresses that are directly 436 reachable. This needs to be maintained as the radio reachability 437 changes. We introduce a Node-Lifetime option that is carried in the 438 unicast NS and NA messages sent by hosts. Thus it can be used on the 439 unicast NS messages that that a host sends as part of NUD to 440 determine that it can still reach a default router. This Node- 441 Lifetime is used by the 6LR to reliably maintain its Neighbor Cache. 443 The Node-lifetime is required for 6LoWPAN network for reliability and 444 power saving to minimize frequent need for updating Neighbor status 445 with the neighboring 6LR for liveliness. Thus the requested Node- 446 lifetime provides flexibility to the requester to receive an address 447 which should be usable (continue to be advertised by the 6LR in the 448 routing protocol etc) during its intended of sleep schedule. 450 0 1 2 3 451 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Type | Length = 1 | Reserved | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Registration Lifetime | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 Fields: 459 Type: TBD [To be allocated by the IANA.] 460 Length: 8-bit unsigned integer. The length of the option in 461 units of 8 octets. Always 1. 462 Reserved: 16-bits. This field is unused. It MUST be 463 initialized to zero by the sender and MUST be ignored 464 by the receiver. 465 Registration Lifetime: 32-bit unsigned integer. The amount of time 466 in seconds that the 6LR should retain the Neighbor 467 Cache entry for the sender of the NS/NA that includes 468 this option. 470 7. Optimized Neighbor Discovery for 6LoWPANs 472 The goal of having an optimized Neighbor Discovery is to basically 473 use regular IPv6 Neighbor Discovery [2] with some optimization for 474 low-power networks. The main objective is to minimize the multicast 475 messages and use unicast messages instead of multicast messages when 476 possible. Note that IPv6 use multicast messages instead of broadcast 477 messages. But layer-2 technologies that do not support multicast but 478 provides broadcast support, usually map the IP multicast messages to 479 L2 broadcast messages. IEEE 802.15.4 networks do this. 481 7.1. Operations Overview 483 The mandatory part of the optimized Neighbor Discovery protocol is 484 described here. Upon starting up, a node figures out whether it is 485 configured as a router or a simple host. The procedure of 486 determining this node behavior is local to the system and it is 487 implementation specific. 489 The use of subnet and link-local address prefixes is specified in 490 [8]). In this case, the link-local addresses can only reach the set 491 of nodes that are reachable from the sender at the time it sends a 492 packet. We can define that as 6LoWPAN-link. 494 7.2. Existing Neighbor Discovery Messages 496 IPv6 Neighbor Discovery [2] protocol operates with Router 497 Solicitation(RS), Router Advertisement(RA), Neighbor 498 Solicitation(NS), Neighbor Advertisement (NA), and Redirect messages, 499 link-layer address options, prefix options, MTU options etc., and a 500 set of protocol constants. Moreover, duplicate address detection 501 (DAD) is performed during address assignment. 503 The following sections describe optimizations (if any) of the above 504 messages of IPv6 Neighbor Discovery Protocol[2] for 6LoWPAN. 506 7.3. 6LoWPAN Optimized Neighbor Discovery Messages 508 1. Router Advertisement(RA): Periodic RAs SHOULD be avoided. Only 509 solicited RAs are recommended for the 6LBRs (on their 6LoWPAN 510 interfaces) and 6LRs. An RA MUST contain the Source Link-layer 511 Address option containing Router's link-layer address (this is 512 optional in [2]. An RA MUST carry Prefix information option 513 with L bit being unset, so that hosts do not multicast any NS 514 messages as part of address resolution. In addition to the 515 Prefix option the RA should carry Authoritative Router option 516 option generated by the 6LBR. 517 2. Router Solicitation(RS): Upon system startup, the node sends a 518 multicast or link broadcast (when multicast is not supported at 519 the link-layer) RS to find out the available routers in the 520 wireless link. An RS may be sent at other times as described in 521 section 6.3.7 of RFC 4861. A Router Solicitation MUST carry 522 Source Link-layer Address option. Since no periodic RAs are 523 allowed in a 6LoWPAN network, the host may restart sending 524 multicast RS messages after NUD declares a default router 525 unreachable. 526 3. Default Router Selection: Same as in section 6.3.6 of RFC 4861. 527 4. Neighbor Solicitation (NS): Neighbor solicitation is used 528 between the hosts and the default-router as part of NUD and 529 registering the host's address(es). An NS messages MUST use the 530 Node-lifetime option in order to accomplish the registration. 531 5. Neighbor Advertisement (NA): As defined in [2] 532 6. Redirect Messages: A router in the 6LoWPAN network may send a 533 Redirect message to a host. When to send the redirect message 534 is implementation specific; a router may be overloaded or by 535 some means it can determine the proximity of source and 536 destination and decide that they should directly talk to each 537 other. The host behavior is same as described in section 8.3 of 538 RFC 4861 [2]. 539 7. Message Validation: Same as in RFC 4861[2] 540 8. MTU option: As per the RFC 4861. 541 9. Address Resolution: No multicast NS/NA are sent as the prefixes 542 are treated as off-link. Thus no address resolution is 543 performed at the hosts. The routers keep track of Neighbor 544 Solicitations with Node-Lifetime options and create a neighbor 545 cache of directly reachable addresses. The router also knows 546 the nexthop link-local address and corresponding link-layer 547 address when it wants to route a packet. 548 10. Neighbor Unreachability Detection(NUD): NUD is performed in 549 "forward-progress" fashion as described in section 7.3.1 of [2]. 550 The unicast Neighbor Solicitation and Advertisement messages 551 sent by a host as part of NUD include the Node-Lifetime option. 553 7.4. Host Behavior 555 A 6LoWPAN host sends Router Solicitation at the system startup and 556 also when it suspects that one of its default routers have become 557 unreachable (after NUD fails). The latter part is a behavioral 558 change from RFC 4861 [2], since RFC 4861 assumes that when NUD fails 559 for a router there will be some multicast RA messages that will make 560 the host find out a new set of working default routers. Here we 561 avoid multicast RA messages completely which implies that the host 562 needs to send a RS after NUD fails, just as it does in the case when 563 the interface is reinitialized after a temporary interface failure in 564 section 6.3.7 in [2]. Thus in essence we treat a NUD failure for a 565 default router the same way as a temporary interface failure, which 566 seems consistent with how [2] operates on a wired network. 568 A host SHOULD be able to autoconfigure its IPv6 addresses and 569 optionally it can act as a simple DHCPv6 client. 571 A host always sends packets to (one of) its default router(s). This 572 is accomplished by the 6LBRs and 6LRs never setting the 'L' flag in 573 the Prefix options. A router can control the host's selection of a 574 default router by sending Redirect messages, however care must be 575 taken to ensure that that router is indeed reachable from the host. 576 Should this not be the case then normal operation of NUD per RFC 4861 577 will end up deleting the redirect. 579 The host is unable to forward routes or participate in a routing 580 protocol. 582 7.5. 6LBR Behavior 584 A 6LBR normally has multiple interfaces and connects the 6LoWPAN to 585 other 6LoWPAN networks or to non-6LoWPAN network(s). The 6LBR is 586 responsible for distributing one or more /64 prefixes to the 6LoWPAN 587 nodes to identify a packet belonging to the particular 6LoWPAN 588 network. 590 When the 6LBR sends a Router Advertisement it SHOULD include a 591 Authoritative Router option that includes its own address and a 592 sequence number. (The Authoritative Router option is required in the 593 "route-over" configuration.) Each time the information in the RA 594 changes (such as adding or deleting prefixes, or changing the 595 lifetime of the prefixes) the sequence number should be increased by 596 one. The 6LBR SHOULD keep the sequence number in stable storage or 597 otherwise ensure that after a reboot it will not reuse "old" sequence 598 numbers. 600 A 6LBR keeps a cache for all the 6LoWPAN nodes' IP addresses, created 601 from the routing protocol. The 6LBR may act as a DHCPv6 server for 602 the 6LoWPAN network as well. It does not send unsolicited Router 603 Advertisements on 6LoWPAN interfaces. 6LBR holds the authority of 604 Prefix generation and initial Prefix allocation in the 6LoWPAN 605 network. 607 7.6. 6LR Behavior 609 6LRs are only present in "Route-over" mesh topology. They 610 participate in forwarding packets in from a host to another host or 611 to the nexthop router. They may configure their own address based on 612 the /64-bit prefix(es) they receive in RAs. 614 A 6LR keeps a cache of neighbor information collected from the Node- 615 Lifetime options in Neighbor messages. This information is made 616 available to the routing protocol. When receiving a packet the 6LR 617 compares the destination against this neighbor cache. If present the 618 host is directly connected to the 6LR and it can forward the packet 619 to the host. Otherwise the packet is forwarded using the routing 620 protocol. 622 A 6LR receives Router Advertisements from 6LBRs and 6LRs and uses the 623 received Prefix options and Authoritative Router option to construct 624 the Router Advertisements it sends. The 6LR MUST ignore any RA that 625 does not contain an Authoritative Router option. When a RA is 626 received it compares the sequence number and 6LBR Address against a 627 cache of such information. If it has information for the 6LBR 628 Address and the received sequence number is less or equal to last 629 sequence number, then it MUST ignore the received Prefix options. 630 Otherwise it updates the prefixes and the sequence number to what was 631 received. This mechanism needs to be able to handle different 6LBRs 632 advertising different prefixes. Among other things that implies that 633 a RA sent by the 6LR can only include prefixes (and the Authoritative 634 Router option) originated from one of the 6LBRs. 636 Unlike regular routers, 6LRs send multicast RS messages once upon 637 startup to receive a RA message. After that they are not required to 638 send RS messages, since they run a routing protocol. 640 8. Remaining Multicast messages 642 With the optimizations specified above the only place where Neighbor 643 Discovery messages are multicast is Router Solicitations. Such 644 messages must be conceptually multicast, both when a host is powered 645 on and also when the NUD indicates that a default router is 646 unreachable, since the host needs to be able to find at least one new 647 router at that point in time. 649 Potentially this could be further optimized if there is some L2 650 mechanism to perform some form of anycast, since all that is needed 651 is for the host to reach at least one router. However, it isn't 652 known to the authors whether 6LoWPAN has an L2 anycast address can be 653 used to reach routers. If such an address can be used, then the RS 654 messages can be multicast at L3 (sent to the "all-routers" IPv6 655 multicast address) while being anycast at L2. 657 9. Security Considerations 659 These optimizations are not known to introduce any new threats 660 against Neighbor Discovery beyond what is already documented for IPv6 661 [RFC 3756]. However, the effect of a rogue router is more severe in 662 Low-power wireless network than in the network of powered systems. 663 The 6LoWPAN security analysis [12] discusses possible threats. The 664 security of 6LoWPAN Neighbor Discovery will be handled in a separate 665 follow-up IETF publication. 667 10. IANA Considerations 669 If this document is approved then two Neighbor Discovery option types 670 need to be allocated. 672 11. Acknowledgements 674 The primary idea and inspiration of this document to note different 675 addressing mechanism and simple ND procedures are from Geoff 676 Mulligan. 678 Also thanks to the 6LoWPAN and 6man working group members to provide 679 ideas on simplification. Part of the ideas are also discussed at the 680 IETF mailing list as a summary of base 6LoWPAN-ND requirement. 682 12. References 684 12.1. Normative References 686 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 687 Levels", BCP 14, RFC 2119, March 1997. 689 [2] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 690 "Neighbor Discovery for IP version 6", RFC 4861, 691 September 2007. 693 [3] Montenegro, G. and N. Kushalnagar, "Transmission of IPv6 694 Packets over IEEE 802.15.4 networks", RFC 4944, September 2007. 696 [4] Kushalnagar, N. and G. Montenegro, "6LoWPAN: Overview, 697 Assumptions, Problem Statement and Goals", RFC 4919, 698 August 2007. 700 12.2. Informative References 702 [5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 703 (IPv6), Specification", RFC 2460, December 1998. 705 [6] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 706 Autoconfiguration", RFC 4862, September 2007. 708 [7] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "Secure 709 Neighbor Discovery", RFC 3971, March 2005. 711 [8] Baccelli, E. and M. Townsley, "IP Addressing Model in Adhoc 712 Networks", draft-ietf-autoconf-adhoc-addr-model-02.txt (work in 713 progress), December 2009. 715 [9] IEEE Computer Society, "IEEE Std. 802.15.4-2003", , 716 October 2003. 718 [10] Miwakawya, S., "Requirements for Prefix Delegation", RFC 3769, 719 June 2004. 721 [11] "Unique Local IPv6 Addresses", RFC 4193. 723 [12] Park, D., Kim, K., Seo, E., and S. Chakrabarti, "IPv6 over Low 724 Power WPAN Security Analysis", 725 draft-daniel-6lowpan-security-analysis-02.txt (work in 726 progress), January 2007. 728 Authors' Addresses 730 Samita Chakrabarti 731 IP Infusion 732 1188 Arquest Street 733 Sunnyvale, CA 734 USA 736 Email: samitac@ipinfusion.com 738 Erik Nordmark 739 Oracle, Inc. 740 17 Network Circle 741 Menlo Park, CA 94025 742 USA 744 Email: Erik.Nordmark@Sun.COM