idnits 2.17.1 draft-shelby-6lowpan-nd-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 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1642. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1653. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1660. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1666. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: P: 1-bit Primary flag. Set to indicate that the router is primary and MAY proxy for the node if Proxy ND is used on the backbone link in a request. If the flag is not set then the router MUST not proxy for the node. Flag is echoed in a confirmation. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: R: 1-bit Removal flag. When set, indicates that this particular address binding MUST be removed from a whiteboard (in a request) or MUST not be used any longer (in a confirmation). -- 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 17, 2008) is 5639 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) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-05) exists of draft-van-beijnum-multi-mtu-02 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6LoWPAN Z. Shelby, Ed. 3 Internet-Draft Sensinode 4 Intended status: Standards Track P. Thubert 5 Expires: May 21, 2009 Cisco 6 J. Hui 7 Arch Rock 8 S. Chakrabarti 9 IP Infusion 10 E. Nordmark 11 Sun 12 November 17, 2008 14 Neighbor Discovery for 6LoWPAN 15 draft-shelby-6lowpan-nd-01 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on May 21, 2009. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2008). 46 Abstract 48 This document specifies Neighbor Discovery optimized for 6LoWPAN. 50 The 6LoWPAN format allows IPv6 to be used over very low-power, low- 51 bandwidth wireless networks often making use of extended multihop 52 topologies. However, the use of standard IPv6 Neighbor Discovery 53 over 6LoWPAN networks has several problems. Standard Neighbor 54 Discovery was not designed for wireless links, the standard IPv6 link 55 concept and heavy use of multicast makes it inefficient. This 56 document spefies a new mechanism allowing efficient Duplicate Address 57 Detection over entire 6LoWPAN networks. In addition it specifies 58 prefix and context dissemination for use with router advertisements, 59 allows for stateless address assignment, and the use of Neighbor 60 Discovery Proxy. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.1. Goals & Assumptions . . . . . . . . . . . . . . . . . . . 5 66 1.2. Why not standard IPv6 ND? . . . . . . . . . . . . . . . . 6 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 69 3.1. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 12 70 3.2. Basic operation . . . . . . . . . . . . . . . . . . . . . 13 71 3.3. Optional features . . . . . . . . . . . . . . . . . . . . 13 72 4. 6LoWPAN ND Messages . . . . . . . . . . . . . . . . . . . . . 13 73 4.1. Router Registration/Confirmation Message . . . . . . . . . 14 74 4.2. Router Advertisement Message . . . . . . . . . . . . . . . 16 75 4.3. Neighbor Solicitation Message . . . . . . . . . . . . . . 18 76 4.4. 6LoWPAN ND Message Options . . . . . . . . . . . . . . . . 18 77 4.4.1. Address Option . . . . . . . . . . . . . . . . . . . . 18 78 4.4.2. 6LoWPAN Prefix Information Option . . . . . . . . . . 20 79 4.4.3. Multihop Information Option . . . . . . . . . . . . . 21 80 4.4.4. Host Interface Identifier Option . . . . . . . . . . . 21 81 5. LoWPAN Subnet . . . . . . . . . . . . . . . . . . . . . . . . 22 82 6. LoWPAN Node Specification . . . . . . . . . . . . . . . . . . 23 83 6.1. Forming addresses . . . . . . . . . . . . . . . . . . . . 23 84 6.2. Registration process . . . . . . . . . . . . . . . . . . . 24 85 6.3. Next-hop determination . . . . . . . . . . . . . . . . . . 25 86 6.4. Address lookup . . . . . . . . . . . . . . . . . . . . . . 25 87 7. LoWPAN Router Specification . . . . . . . . . . . . . . . . . 26 88 7.1. Router Configuration Variables . . . . . . . . . . . . . . 26 89 7.2. Becoming an Advertising Interface . . . . . . . . . . . . 27 90 7.3. Router Advertisement Message Content . . . . . . . . . . . 27 91 7.4. Sending Unsolicited Router Advertisements . . . . . . . . 29 92 7.5. Ceasing To Be an Advertising Interface . . . . . . . . . . 29 93 7.6. Processing Router Solicitations . . . . . . . . . . . . . 29 94 7.7. Router Advertisement Consistency . . . . . . . . . . . . . 29 95 7.8. Relaying a Router Registration Message . . . . . . . . . . 29 96 7.9. Relaying a Router Confirmation Message . . . . . . . . . . 29 98 8. LoWPAN Edge Router Specification . . . . . . . . . . . . . . . 29 99 8.1. Registration process . . . . . . . . . . . . . . . . . . . 30 100 8.2. Exposing the Edge Router . . . . . . . . . . . . . . . . . 31 101 8.3. Forwarding packets . . . . . . . . . . . . . . . . . . . . 33 102 8.4. Fault tolerance . . . . . . . . . . . . . . . . . . . . . 33 103 9. Ad-hoc LoWPAN Operation . . . . . . . . . . . . . . . . . . . 33 104 10. Message Examples . . . . . . . . . . . . . . . . . . . . . . . 33 105 11. Security Considerations . . . . . . . . . . . . . . . . . . . 33 106 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 107 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 108 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 109 14.1. Normative References . . . . . . . . . . . . . . . . . . . 34 110 14.2. Informative References . . . . . . . . . . . . . . . . . . 35 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 112 Intellectual Property and Copyright Statements . . . . . . . . . . 37 114 1. Introduction 116 The IPv6 over IEEE 802.15.4 [RFC4944] document has specified IPv6 117 headers carried over an IEEE 802.15.4 network with the help of an 118 adaptation header which comes before the IP header. A LoWPAN network 119 is characterized as a low-power, low bit-rate, short range, low cost 120 network. Thus, all-node multicast defined in IPv6 Neighbor Discovery 121 [RFC4861] is not often desirable in a wireless low-power, lossy 122 network. In addition IEEE 802.15.4 and similar wireless technologies 123 do not have multicast support, but supports broadcast. Broadcast 124 messages could be used in some cases to represent all-node multicast 125 messages, but periodic broadcast messages should be minimized in 126 LoWPANs in order to conserve energy. Moreover, LoWPAN nodes are 127 transient in nature; they are not always considered to be in a fixed 128 network nor they are bounded by our standard definition of a wired- 129 link. The link is in reality defined by reachability and radio 130 strength. The standard IPv6 neighbor discovery [RFC4861] control 131 messages and their default frequency also attribute to unnecessary 132 loss of power in the 6lowpan network. 134 The goal of this document is to minimize/remove periodic multicast 135 signals used by IPv6 Neighbor Discovery [RFC4861] while enabling the 136 LoWPAN to work as efficiently and optimally as possible and reducing 137 the complexity of LoWPAN node implementations. 139 Neighbor discovery for 6LoWPAN provides for basic bootstrapping, and 140 network operation, along with advanced features such as stateless 141 address assignment and ND-Proxy, while avoiding the use of multicast 142 and providing both mesh under and route over support. Unlike 143 standard IPv6 ND [RFC4861], this document takes the lossy 144 characteristics of wireless networks into account. 146 The concept of a LoWPAN whiteboard located at Edge Routers is 147 introduced, which allows for duplicate address detection and 148 stateless address assignment for the entire LoWPAN. Address 149 resolution simplifications are included to make LoWPAN operation 150 efficient and reduce LoWPAN Nodes complexity. A new registration/ 151 confirmation message sequence is specified, allowing nodes to 152 register their IPv6 addresses with an Edge Router, and to request 153 global unique address assignment. 155 The ER whiteboard makes use of soft bindings, thus nodes send 156 periodic registration messages in order to maintain their binding and 157 address assignments. Changes in network topology, and mobility 158 between ERs and subnets are supported. The dissemination of RA 159 information throughout multihop route over networks is also 160 discussed. 162 This paper also specifies the use of ND Proxy by Edge Routers, 163 allowing for the seamless integration of an extended LoWPAN and 164 multiple Edge Routers on a shared backbone link (e.g. Ethernet) to 165 form a single IPv6 subnet. This allows hosts to keep the same IPv6 166 address throughout a large network, and allows for easy 167 communications with backbone link IPv6 hosts. 169 This paper defines two new ICMPv6 messages: Router Registration and 170 Router Confirmation. In addition a new 6LOWPAN_ER anycast address is 171 introduced, allowing for nodes to send register without knowing the 172 specific Edge Router's or Router's unicast address. 174 1.1. Goals & Assumptions 176 This document has the following main goals and makes several 177 assumptions. 179 Goals: 181 o Avoid the use of multicast for ND messages inside the LoWPANs. 183 o Disseminate prefix and context information throughout the 184 LoWPAN. 186 o Minimize the complexity of LoWPAN nodes. 188 o Interconnect LoWPANs with backbone links seamlessly. 190 o Provide a mechanism for stateles address assignment. 192 Assumptions: 194 o Either [RFC4944] or [draft-ietf-6lowpan-hc] 6LoWPAN header 195 compression used. 197 o Link layer technology may be IEEE 802.15.4 as in [RFC4944], or 198 any other suitable link-layer. 200 o Link-local addresses are derived from an EUI-64 identifier. 202 o The use of optimistic DAD. 204 o Mesh-under nodes know the edge router link-layer addresses of 205 their mesh network from some L2 mechanism. 207 o A subnet covers all the LoWPANs and their backbone link with the 208 same IPv6 global or local prefix. 210 1.2. Why not standard IPv6 ND? 212 IPv6 Neighbor Discovery [RFC4861] provides several important 213 functions such as Router Discovery, Address Resolution, Duplicate 214 Address Detection, Redirect, Prefix and Parameter Discovery. 216 Following power-on and initialisation of the network in IPv6 ethernet 217 networks, a node joins the solicited-node multicast address on the 218 interface and then it performs duplicate address detection (DAD) for 219 the acquired link-local address by sending solicited-node multicast 220 message to the link. After that it sends multicast messages to all- 221 router address to solicit router advertisements. Once the host 222 receives a valid router advertisement with the "A" flag, it 223 autoconfigures the IPv6 address with the advertised prefix in the 224 rotuer advertisement (RA). Besides this, the IPv6 routers usually 225 send router advertisements periodically on the network. It sends the 226 RA to all-node multicast address. Nodes send Neighbor Solicitation/ 227 Neighbor Advertisement messages to resolve the IPv6 address of the 228 destination on the link. These NS/NA messages are also often 229 multicast messages and it assumes that the node is on the same link 230 and relies on the fact that the destination node is always powered 231 and generally reliable. 233 A LoWPAN network typically uses two types of L2 addresses - 16-bit 234 short addresses and 64-bit unique addresses as defined in [RFC4944]. 235 Moreover, the link bandwidth is often on the order of less than 100 236 bytes where we often might need to use header compression and use a 237 minimum payload. The network is lossy and low-powered, and it does 238 not provide multicast capability at the link-layer, thus simulating 239 multicast behavior by both using broadcast or sending a number of 240 unicast messages, both expensive for the low-powered network and the 241 low-processing capable nodes. Besides often these low-powered nodes 242 conserve energy by using sleep schedules; waking them up to receive 243 IPv6 signaling messages such as multicast messages for NS, and 244 periodic RA is not practical. Nor they are capable of processing 245 address-resolution for its neighbors effectively. Besides due to 246 radio strength of its neighboring router or its own strength, a node 247 may often move between one subnet to another without physically 248 moving from one place to another. Considering the above 249 characteristics in a LoWPAN, and IPv6 Neighbor Discovery [RFC4861] 250 base protocol requirements, it was concluded that standard Neighbor 251 Discovery is not suitable as it is and a 6lowpan-specific ND protocol 252 would be useful and efficient for wide deployment of IPv6 over low- 253 powered wireless networks of embedded devices. 255 2. Terminology 257 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 258 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 259 document are to be interpreted as described in [RFC2119]. 261 Readers are expected to be familiar with all the terms and concepts 262 that are discussed in "Neighbor Discovery for IP version 6" 263 [RFC4861], "IPv6 Stateless Address Autoconfiguration" [RFC4862], 264 "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): 265 Overview, Assumptions, Problem Statement, and Goals" [RFC4919] and 266 "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" [RFC4944]. 268 Readers would benefit from reading "Mobility Support in IPv6" 269 [RFC3775], "Neighbor Discovery Proxies (ND Proxy)" [RFC4389] and 270 "Optimistic Duplicate Address Detection" [RFC4429] prior to this 271 specification for a clear understanding of state of the art in ND 272 proxy and binding. 274 This document defines additional terms: 276 LoWPAN Host 278 A node that only sources or sinks IPv6 datagrams. Referred to as 279 a Host in this document. The term Node is used when the the 280 differentiation between Host and Router is not important. 282 LoWPAN Edge Router 284 An IPv6 router that interconnects the LoWPAN to another network. 285 Referred to as an Edge Router in this document. 287 LoWPAN Router 289 A node that forwards datagrams between arbitrary source- 290 destination pairs using a single 6LoWPAN/802.15.4 interface. A 291 LoWPAN Router may also serve as a LoWPAN Host - both sourcing and 292 sinking IPv6 datagrams. Refered to as a Router in this document. 293 All LoWPAN Routers perform ND message relay on behalf of other 294 nodes. 296 Mesh Under 298 A LoWPAN configuration where the link-local scope is defined by 299 the boundaries of the LoWPAN and includes all nodes within. 300 Multihop forwarding is achieved at L2 between mesh nodes. 302 Route Over 304 A LoWPAN configuration where the link-local scope is defined by 305 those nodes reachable over a single radio transmission. Due to 306 the time-varying characteristics of wireless communication, the 307 neighbor set may change over time even when nodes maintain the 308 same physical locations. Multihop is achieved using IP routing. 310 Backbone Link 312 This is an IPv6 link that interconnects 2 or more Edge Routers. 313 It is expected to be deployed as a high speed backbone in order to 314 federate a potentially large set of LoWPANS. 316 Backhaul Link 318 This is an IPv6 link that connects a single Edge Router to another 319 network. 321 Extended LoWPAN 323 This is the aggregation of multiple LoWPANs as defined in 324 [RFC4919] interconnected by a backbone link via Edge Routers and 325 forming a single subnet. 327 LoWPAN Subnet 329 A subnet including a LoWPAN or Extended LoWPAN, together with the 330 backbone link sharing the same prefix. 332 Binding 334 The association of the LoWPAN node IPv6 address and Interface ID 335 with associated whiteboard and proxy states including the 336 remaining lifetime of that association. 338 Registration 340 The process during which a LoWPAN node sends a Router Registration 341 ND message to an Edge Router causing a binding for the LoWPAN node 342 to be registered. 344 3. Protocol Overview 346 Neighbor discovery for 6LoWPAN provides additions and optimizations 347 to IPv6 ND [RFC4861] supporting 6LoWPAN low-power wireless stub 348 networks. Basic bootstrapping and network maintenenace mechanisms 349 are provided, and the use of multicast for ND messages is avoided. 350 Duplicate address detection and stateless address assignment are 351 supported as part of bootstrapping. This is achieved using a 352 whiteboard located on the 6LoWPAN Edge Routers of the LoWPAN network. 354 Multihop route-over networks are supported by relaying ND messages. 355 Finally, advanced features include the use of ND Proxy, and secondary 356 Edge Router registrations. ND for 6LoWPAN is designed to work with 357 many network topologies, including isolated ad-hoc networks, single 358 ER networks, and networks with multiple ERs interconnected by a 359 backbone link. The use of both IEEE 802.15.4 and other suitable 360 6LoWPAN link-layer technologies is considered. Both the use of mesh 361 under forwarding and route over routing are supported. 363 | 364 | 365 | 366 +-----+ 367 | | Edge 368 | | router 369 +-----+ 370 m m 371 m m 372 m m m m m: Mesh node 373 m m m m 374 m m m 376 LoWPAN 378 Figure 1: A Mesh under LoWPAN. 380 In a mesh under network, shown above, multihop forwarding is dealt 381 with below layer 3. Thus the entire LoWPAN forms a link-layer mesh. 382 This means that the IPv6 link-local scope includes all the nodes of 383 the LoWPAN. Link-local scope stops however at the ER, and does not 384 include any backbone link. The implication of this on ND for 385 6LoWPAN, is that it can always be assumed that the ER and hosts are 386 on the same link. Multicast with mesh under technologies most often 387 induces flooding, and therefore it is avoided. 389 | 390 | 391 | 392 +-----+ 393 | | Edge 394 | | router 395 +-----+ 396 r h 397 r r r 398 h r h r h h: Host 399 h r r h r: Router 400 h h h 402 LoWPAN 404 Figure 2: A Route over LoWPAN. 406 A route over network performs multihop using standard layer 3 IP 407 routing. The link-local scope is defined by those nodes reachable 408 over a single radio transmission. The implication for ND for 6LoWPAN 409 is that if the ER is out of radio range of a host, the ND messages 410 require relaying by intermediate Routers. Multicast may also involve 411 flooding in such networks, and is avoided. 413 Infrastructure 414 Cloud 415 z 416 z 417 z Backhaul link 418 z 419 z 420 +-----+ 421 | | Edge 422 | | router 423 +-----+ 424 o o 425 o o o 426 o o o o o o: Any node 427 o o o o 428 o o o 430 LoWPAN 432 Figure 3: A LoWPAN connected to a backhaul link. 434 The simplest topology is a LoWPAN connected by a single Edge Router 435 to another network, over a so-called backhaul link. The Edge Router 436 maintains a whiteboard of all hosts in the network, and assigns 437 addresses. The Edge Router terminates 6LoWPAN framing from the 438 LoWPAN, and forwards packets. Multiple such networks may also 439 overlap to form an Extended LoWPAN. 441 Infrastucture Cloud 442 | 443 | 444 +-----+ +-----+ 445 | | Gateway | | Host 446 | | | | 447 +-----+ +-----+ 448 | | 449 | Backbone link | 450 +--------------------+------------------+ 451 | | | 452 +-----+ +-----+ +-----+ 453 | | Edge | | Edge | | Edge 454 | | router | | router | | router 455 +-----+ +-----+ +-----+ 456 o o o o o o o o 457 o o o o o o o o o o o o o o o o o 458 o o o o o o o o o o o o o o o o 459 o o o o o o o o o o o o 460 o o o o o o o o o 462 Extended LoWPAN 464 Figure 4: Backbone link and edge routers with a 6LoWPAN subnet 466 In the backbone link topology, a backbone link federates multiple 467 LoWPANs as a single IP link, the Extended LoWPAN. Each LoWPAN is 468 anchored at one or more Edge Router. The Edge Routers interconnect 469 the LoWPANs over the backbone link. A node can move freely from a 470 LoWPAN anchored at an Edge Router to a LoWPAN anchored at another 471 Edge Router on the same backbone link and conserve its link local and 472 any other IPv6 address it has formed. If ND Proxy is used, a 473 standard IPv6 Host on the backbone link can communicate with any host 474 in the Extended LoWPAN and vice versa. 476 The following sections explain the basics of how ND for 6LoWPAN 477 works, starting with bootrapping on the network, maintenance of the 478 network, and finally optional features such as ND Proxy. 480 3.1. Bootstrapping 482 A Host first performs stateless autoconfiguration of its link-local 483 address for each 6LoWPAN interface from its EUI-64 as in [RFC4944]. 484 When a LoWPAN Host wants to join a LoWPAN network, it does so by 485 listening for Route Advertisements from Edge Routers or Routers, or 486 by broadcasting a Router Solicitations. If a local or global prefix 487 is included in the RA, the host may form an optimistic global unique 488 address with stateless autoconfiguration. 490 Next the Host registers with an on-link Edge Router or Router by 491 sending a Router Registration (RR) message to it, either unicast or 492 using the 6LOWPAN_ER anycast address. These message exchanges are 493 illustrated below. The RR contains the addresses the node wants to 494 register. If the network is configured to assign, e.g., short 495 addresses to nodes, this is incidated in the RA message with the M 496 flag. In such networks a node may request a stateless link-layer 497 address to be assigned to it by including an Address Option with the 498 A flag and an address of length 0 in the RR. Note that registration 499 must be performed separately for each interface of a Host. 501 The Edge Router replies either directly with a Router Confirmation 502 (RC), or through a Router by relaying. This Confirmation includes 503 the set of addresses now bound to the whiteboard of the ER, including 504 a possible assigned addresses. The Host is now capable of using the 505 LoWPAN, and the ER forwards on its behalf. 507 Node Edge Router 508 | | 509 | ---------- Router Registration --------> | 510 | | 511 | <--------- Router Confirmation --------- | 512 | | 514 Figure 5: Basic ND registration exchange. 516 Node Router (relay) Edge Router 517 | | | 518 | ---- RR ---> | ---- RR ---> | 519 | | | 520 | <---- RC ---- | <---- RC ---- | 521 | | | 522 Figure 6: Relay ND registration exchange. 524 3.2. Basic operation 526 The whiteboard address binding and assignment are soft, and thus must 527 be renewed periodically as indicated by the lifetime of the binding. 528 This is achieved by periodically sending a new RR to the ER. If a 529 host moves, or the network topology changes, and the current ER is no 530 longer available, the host then starts the registration process with 531 another ER. If the host is still in the same Extended LoWPAN, its 532 IPv6 addresses remain the same. As assigned addresses are stateless, 533 they must be remembered by the host and refreshed in order to keep 534 the address. If the host moves to a different LoWPAN, with a 535 different default prefix, the bootstrapping process is initiated 536 again. In route over networks, Routers that act as relays must 537 disseminate RAs to their neighbors. The Edge Router disseminates 538 RAs, and this information is included in the RAs of each Router. 540 3.3. Optional features 542 ND Proxy is specified in [RFC4389], and allows for two segments to be 543 merged into a single IPv6 link. This documents explains the 544 application of ND Proxy for use with Extended LoWPAN networks with 545 multiple ERs on a backbone link. This optional feature allows for 546 DAD across the entire Extended LoWPAN and backbone links, and for the 547 subnet to appear as a single IPv6 link. This document extends ND 548 Proxy to include an option to uniquely identify the LoWPAN Host on 549 the backbone, and override the claim on an address on behalf of a 550 LoWPAN Host. Thus a Host can keep the same address, and appears the 551 same to other Hosts on the backbone link, regardless of moving its 552 binding from one ER to another. Forwarding can be performed 553 automatically regardless of which ER the host is proxied by. 555 4. 6LoWPAN ND Messages 557 This section introduces message formats for all messages used in this 558 document. The new messages are all ICMPv6 messages and extend the 559 capabilities of "The IPv6 Neighbor Discovery Protocol" [RFC4861]. In 560 addition the ICMPv6 Router Advertisement is updated with a new flag 561 and options. 563 The following new ICMPv6 message types are defined: 565 Router Registration 567 Router Confirmation 569 In addition, the following new ICMPv6 options are defined: 571 Address Option 573 6LoWPAN Prefix Information Option 575 Multihop Information Option 577 Host Interface Identifier Option 579 4.1. Router Registration/Confirmation Message 581 The Router Registration (RR) and Router Confirmation (RC) messages 582 are used by a Host to register with an ER, and for the ER to confirm 583 the binding. Any option that is not recognized MUST be skipped 584 silently. The Router Registration message is sent by the LoWPAN Node 585 to an on-link ER or Router, and may be sent unicast or to the 586 6LOWPAN_ER anycast address. This same message format is also used 587 for Relay RR/RC messages, with an alternative code that is set when 588 the message has been relayed. 590 0 1 2 3 591 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 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Type | Code | Checksum | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | TID | Status |P|X| Reserved | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Reserved | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Lifetime | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | | 602 + Host Interface Identifier + 603 | | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | Binding option(s)... 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 Figure 7: Router Registration/Confirmation message format 610 IP Fields: 612 Source Address: The IPv6 address of the source. This address may 613 be an optimistic address. 615 Destination Address: The destination IPv6 address of an Edge 616 Router or Edge Router Relay. May be the 6LOWPAN_ER anycast 617 address. 619 Hop Limit: 255 621 ICMP Fields: 623 Type: TBD1 for Router Registration, TBD2 for Router Confirmation. 625 Code: 0 indicates a message sent directly from the orginating 626 host. 1 indicates that the message has been relayed by a 627 router. 629 Checksum: The ICMP checksum. 631 TID: A unique Transaction ID assigned by the host and used to 632 match replies. 634 P: 1-bit Primary flag. Set to indicate that the router is primary 635 and MAY proxy for the node if Proxy ND is used on the backbone 636 link in a request. If the flag is not set then the router MUST 637 not proxy for the node. Flag is echoed in a confirmation. 639 X: 1-bit Proxy Flag. Only used in a confirmation, indicates that 640 the router actually proxies for all of the addresses in the 641 option fields that are being assigned to the node. This can 642 only happen if the P flag is set as well. Set to 0 in a 643 request. 645 Status: 8-bit unsigned integer. Values TBD. 0 means unqualified 646 success. Any value below 128 is a positive status that means 647 that the binding was created or is being created 648 optimistically. Only used in a confirmation. 650 Lifetime: 32-bit unsigned integer. The amout of time in units of 651 seconds remaining before the binding of this node interface 652 identifier, and all associated address options and 653 configuration options, MUST be considered expired. A value of 654 zero indicates that the Binding Cache entries for the 655 registered host interface identifier MUST be deleted. 657 Reserved: This field is unused. It MUST be initialized to zero 658 by the sender and MUST be ignored by the receiver. 660 Host Interface Identifier: A globally unique identifier for the 661 requesting host's interface. Typically the EUI-64 dervied IID. 663 Possible Options: 665 Address Option(s): An Address Option is included for each address 666 the host wants to bind for this interface. 668 Configuration options: Other configuration information requests 669 and configuration settings may be carried in options of RR/RC 670 messages. Such options are not defined in this document. 672 Source link-layer address: Included in a Relay RR message in case 673 the Host Interface Identifier is not the same as the link-layer 674 address of the host interface. Used as defined in [RFC4861] 675 and [RFC4944]. If the RR was relayed, then this option is 676 included in the RC to indicate the identity of the ER. 678 Target link-layer address: Included in a Relay RC message in case 679 the Host Interface Identifier is not the same as the link-layer 680 address of the host interface. Used as defined in [RFC4861] 681 and [RFC4944]. 683 Future versions of this protocol may define new option types. 684 Receivers MUST silently ignore any options they do not recognized 685 and continue processing the message. 687 4.2. Router Advertisement Message 689 The RA message for 6LoWPAN is based on the [RFC4861] RA message with 690 the addition of a new flag "E". In addition new options are 691 identified. 693 0 1 2 3 694 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 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | Type | Code | Checksum | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | Cur Hop Limit |M|O|x|x|x|x|E|x| Router Lifetime | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | Reachable Time | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | Retrans Timer | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | Options ... 705 +-+-+-+-+-+-+-+-+-+-+-+ 706 Figure 8: Router Advertisement Message Format 708 IP Fields: 710 Source Address: MUST be the link-local address assigned to the 711 interface from which this message is sent. 713 Destination Address: Typically the Source Address of an invoking 714 Router Solicitation or the all-nodes multicast address. 716 Hop Limit: 255 718 ICMP Fields: 720 Type: 134 722 Code: 0 724 Checksum: The ICMP checksum. 726 Cur Hop Limit: As specified in [RFC4861]. 728 M: As specified in [RFC4861] with the exception that managed mode 729 here refers to the stateless address assignment mechanism 730 specified in this document, not DHCPv6 as in [RFC4861]. 732 O: As specified in [RFC4861]. 734 x: Bits currently reserved for existing RA flags as per [RFC5175]. 736 E: 1-bit "Edge Router" flag. When set, it indicates that the 737 router is an Edge Router. 739 Router Lifetime: As specified in [RFC4861]. 741 Reachable Time: As specified in [RFC4861]. 743 Possible Options: 745 6LoWPAN Prefix Information Option: This option includes 746 information about the default subnet prefix for the LoWPAN 747 along with other shared contexts for the subnet. 749 Multihop Information Option: This option provides a sequence 750 number associated with the current prefix options. It allows 751 the prefix options themselves to be sent only periodically in 752 unsolicited RAs. 754 Future versions of this protocol may define new option types. 755 Receivers MUST silently ignore any options they do not recognized 756 and continue processing the message. 758 4.3. Neighbor Solicitation Message 760 Neighbor Solicitation messages employed between ERs on the backbone 761 link when ND proxy is used. A unique identifier is required in the 762 message as an option to uniquely identify a host's interface. The 763 standard NS message is used in this document is as per [RFC4861] with 764 the an addition Host Interface Identifier Option defined in this 765 document. The Host Interface Identifier is the same as that carried 766 in RR/RC messages and associated with the bindings. 768 4.4. 6LoWPAN ND Message Options 770 This section defines the new ND for 6LoWPAN message options. 772 4.4.1. Address Option 774 The Address Option is used to indicate the address which a node wants 775 to register with an ER in an RR, and to indicate the success or 776 failure of that binding in an RC. Multiple Address Options can be 777 included in a message. In order to be as compact as possible, fields 778 are used to indicate the compression of the IPv6 address. The 779 Address Option also allows for duplicate addresses (e.g. anycasts), 780 the request of a stateless address assignment, or for an address to 781 be removed. 783 0 1 2 3 784 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 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | Type | Length | Status | P | S | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 |D|A|R| Reserved | IPv6 Address ... 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 Figure 9: Address Option format 793 Type: TBD3 795 Length: 8-bit unsigned integer. The length of the option (including 796 the type and length fields) in units of 8 octets. 798 Status: 8-bit unsigned integer. Values TBD. 0 means unqualified 799 success. Any value below 128 is a positive status that means that 800 the binding for this address was created or is being created 801 optimistically. Only used in a confirmation. 803 D: 1-bit Duplicate flag. When set, indicates that duplicates are 804 allowed for this address (to support anycast) in a request. 806 A: 1-bit Address Assignment flag. Set to indicate that the host is 807 requesting stateless address assignment. In a request when A is 808 set the IPv6 address length is 0. Set to indicate that an address 809 has been assigned in a confirmation. P and S are set to indicate 810 the type of address requested and assigned when A is set. 811 Otherwise must be 0. 813 R: 1-bit Removal flag. When set, indicates that this particular 814 address binding MUST be removed from a whiteboard (in a request) 815 or MUST not be used any longer (in a confirmation). 817 P: 4-bit unsigned integer. Identifies prefix compression in use, if 818 any. 820 0: Prefix is carried inline. 822 1: Prefix compressed and link-local (fe80:/10) is assumed. 824 2: Prefix compressed and the default prefix is assumed. 826 3-15: Reserved. 828 S: 4-bit unsigned integer. Identifies suffix compression in use, if 829 any. 831 0: Suffix carried inline. 833 1: Suffix compressed and assumes the same value as the Host 834 Interface Identifier field in the RR/RC message header. 836 2: Suffix compressed and is derived from the 6LoWPAN short address 837 option as defined in RFC 4944. 839 3-15: Reserved. 841 IPv6 Address: The IPv6 address to be registered with the ER, or 842 confirmed by the ER. Parts of the address may be elided as per 843 the P and S fields. 845 4.4.2. 6LoWPAN Prefix Information Option 847 This option carries prefix information for LoWPANs, and is similar in 848 use to the Prefix Information Option of [RFC4861]. However this 849 option allows for the dissemination of multiple contexts identified 850 by a Context Identifier (CID) for use in 6LoWPAN address compression. 852 0 1 2 3 853 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 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | Type | Length | Prefix Length |L|A| CID | r | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | Valid Lifetime | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 . . 860 . Prefix . 861 . . 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 Figure 10: 6LoWPAN Prefix Information Option format 866 Type: TBD4 868 Length: 8-bit unsigned integer. The length of the option (including 869 the type and length fields) in units of 8 octets. 871 Prefix Length: 8-bit unsigned integer. The number of leading bits 872 in the Prefix that are valid. The value ranges from 0 to 128. 873 The prefix length field provides necessary information for on-link 874 determination (when combined with the L flag in the prefix 875 information option). It also assists with address 876 autoconfiguration as specified in [RFC4862], for which there may 877 be more restrictions on the prefix length. 879 L: 1-bit on-link flag. When set, indicates that this prefix can be 880 used for on-link determination. When not set the advertisement 881 makes no statement about on-link or off-link properties of the 882 prefix. In other words, if the L flag is not set a host MUST NOT 883 conclude that an address derived from the prefix is off-link. 884 That is, it MUST NOT update a previous indication that the address 885 is on-link. 887 A: 1-bit autonomous address-configuration flag. When set indicates 888 that this prefix can be used for stateless address configuration 889 as specified in [RFC4861]. 891 CID: 4-bit Context Identifier for this prefix information. The use 892 of this Context Identifier is not specified in this document. 894 Prefix: The IPv6 Prefix indicated for this context. This may be a 895 partial prefix, or even an entire IPv6 address for use as a 896 context for compression. 898 4.4.3. Multihop Information Option 900 This option identifies the set of prefix information options by a 901 sequence number. This allows for the full set of prefix information 902 options to be sent only periodically in unsolicited RAs. If a host 903 detects a difference in the sequence number of this option, then the 904 prefix information has likely changed, and is then requested with an 905 RS. 907 0 1 2 3 908 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 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | Type | Length | Sequence Number | 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 |V| Reserved | 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 Figure 11: Multihop Information Option 917 Type: TBD5 919 Length: 1 921 Sequence Number: 16-bit signed integer. Indicates the freshness of 922 the information advertised by the RA. 924 V: 1-bit flag. Indicates if the sequence number is valid and the 925 router is advertising information obtained from another router. 927 Reserved: This field is unused. It MUST be initialized to zero by 928 the sender and MUST be ignored by the receiver. 930 4.4.4. Host Interface Identifier Option 932 This option is for use with standard NS and NA messages between ERs 933 over a backbone link together with ND-Proxy. By using this option, 934 the binding in question can be uniquely identified and matched with 935 the whiteboard entries of each ER. 937 0 1 2 3 938 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 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 | Type | Length | Reserved | 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | Reserved | 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 | | 945 + Host Interface Identifier + 946 | | 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 Figure 12: Host Interface Identifier Option 951 Type: TBD6 953 Length: 2 955 Reserved: This field is unused. It MUST be initialized to zero by 956 the sender and MUST be ignored by the receiver. 958 Host Interface Identifier: A globally unique identifier for the 959 host's interface associated with the binding for the NS/NA message 960 in question. 962 5. LoWPAN Subnet 964 In a LoWPAN, a link can be a very instable set of nodes, for instance 965 the set of nodes that can receive a packet that is broadcast over the 966 air. Such a set may vary from one packet to the next as the node 967 moves or as the radio propagation conditions change. As a result, a 968 link does not define the proper set of nodes to perform ND operations 969 such as Duplicate Address Detection and Neighbor lookup. So in ND 970 for 6LoWPAN, those operations are performed over a subnet. A subnet 971 is a collection of LoWPAN links interconnected by routers that may 972 share one or more local or global prefixes. In particular, DAD is 973 performed over a subnet for all types of addresses, inclucing link 974 local. 976 In the backhaul model, an Edge Router and all the LoWPAN Nodes 977 registered to that Edge Router form a subnet. In that model, the 978 Edge Router serves all the prefixes that are defined on its subnet 979 and can be connected to an IP routed infrastructure. 981 In the backbone model, a Backbone Link federates multiple LoWPANs 982 into a single IP subnet. Each LoWPAN is a collection of links 983 anchored at an Edge Router. The Edge Routers interconnect the 984 LoWPANs over the Backbone Link. A node can move freely from a LoWPAN 985 anchored at an Edge Router to a LoWPAN anchored at another Edge 986 Router in the same subnet and conserve its link local and any other 987 IPv6 address it has formed. 989 6. LoWPAN Node Specification 991 Instead of relying on multicast ND messages for DAD and neighbor 992 address resolution, LoWPAN Nodes make use of an Edge Router in the 993 LoWPAN which keeps a whiteboard of all bound addresses from nodes 994 attached to the same ER. In addition, ERs may perform ND proxy on a 995 backbone link, creating an extended LoWPAN sharing the same subnet 996 prefix. ND proxy allows nodes to change their point of attachment 997 without changing its IPv6 addresses. This specification simplifies 998 address resolution compared to standard IPv6 ND. Stateless address 999 assignment is also specified as part of the binding process. 1001 6.1. Forming addresses 1003 All nodes are required to autoconfigure at least one address, a link- 1004 local address that is derived from the IEEE 64-bit extended MAC 1005 address that is globally unique to the device as in [RFC4944]. As a 1006 result, knowledge of the 64-bit address of another node on the same 1007 extended LoWPAN is enough to derive its link-local address and reach 1008 it over IP. Another consequence is that the link local address is 1009 presumably unique on the Extended LoWPAN, which enables the use of 1010 Optimistic Duplicate Address Detection (oDAD) [RFC4429] over the 1011 Transit Link and the LoWPAN. The address SHOULD be created as 1012 optimistic to enable its use in the binding process with the Edge 1013 Router. 1015 Nodes MAY learn the address of Edge Routers or Routers using 1016 traditional means such as L2 configuration or Router Advertisement 1017 messages. This specification also introduces a new anycast address 1018 6LOWPAN_ER that the node can use to reach any Edge Router or Router 1019 on the link. This specification tolerates movement within the LoWPAN 1020 so the node does not have to stick with a given ER and MAY keep using 1021 the 6LOWPAN_ER anycast address for all its registrations. 1023 The node might also form Unique Local and Global Unicast addresses, 1024 for instance if it needs to be reachable from outside of the Extended 1025 LoWPAN. If a Global Prefix is available from an RA ('A' flag is 1026 set), then a Global Unicast address can be derived using SAA. This 1027 address is marked optimistic until confirmed by the ER. 1029 This specification includes a method for requesting a unique 1030 stateless address from the Edge Router by setting the 'A' flag in an 1031 Address Option during registration. This is useful in the case of 1032 e.g. short addresses and avoids the need for a separate mechanism 1033 such as DHCPv6 or manual assignment. The node can tell if address 1034 assignment is available if the 'M' flag of the RA from that router is 1035 set. Address assignment using the RR/RC mechanism is stateless. 1036 Although the address is generated by the ER and checked for 1037 uniqueness across the subnet using DAD, it is just like any other 1038 address binding in the whiteboard of the ER after assignment. Thus 1039 in order to keep using the assigned address the host must keep 1040 refreshing the address binding, including when moving to another ER 1041 in the same subnet. 1043 To simplify address resolution it is assumed that LoWPAN nodes are 1044 assigned addresses in a homogeneous so that the unicast IPv6 1045 addresses IID resolve directly to a corresponding link-layer address. 1046 Thus avoiding address resolution when possible. 1048 6.2. Registration process 1050 The binding process is very similar to that of a MIPv6 mobile node, 1051 though the messages used are new Neighbor Discovery ICMP messages. A 1052 LoWPAN Node address is tentative or optimistic as long as the binding 1053 is not confirmed by the Edge Router. 1055 The LoWPAN node uses unicast Router Registrations to perform the 1056 binding. The destination Address is that of an on-link Edge Router 1057 or Router or the 6LOWPAN_ER anycast address. Registration SHOULD be 1058 preferred with on-link ERs rather than Routers. The source address 1059 is the link local address of the node. A unique Host Interface 1060 Indentifier is included in the Router Registration so the binding can 1061 be identified throughout the subnet. This is usually the EUI-64 1062 identifier of the sending node. The RR message includes an Address 1063 Option for each address to be bound or requested. Thus the message 1064 is structured as follows. 1066 ICMPv6 (Router Registration (Address Options)) 1068 The acknowledgment to a Router Registration is a unicast Router 1069 Confirmation message that contains the status of the binding. The 1070 source of the packet is the link local address of the Edge Router or 1071 Router. The destination address is the link local address of the 1072 node. An Address Option for each confirmed or assigned address is 1073 included. Upon successful completion in the Router Confirmation 1074 message, the LoWPAN Node sets the address from optimistic or 1075 tentative to preferred. 1077 The 'X' flag in the Router Confirmation Indentity Reply Option 1078 indicates that the Edge Router has completed DAD and now owns the 1079 Binding Address over the Transit Link. 1081 This specification also introduces the concept of a secondary 1082 binding. For redundancy, a node might place a secondary binding with 1083 one or more other Edge Routers over a same or different LoWPANs. The 1084 'P' flag in the Router Registration Indentity Request Option 1085 indicates whether the binding is primary. 1087 ER bindings have a timeout associated with them, therefore nodes must 1088 periodically send a new Router Registration message to renew the 1089 bindings. If a node no longer receives RCs from any Router in the 1090 current subnet (with the same network prefix), the registration 1091 process begins from the beginning. 1093 6.3. Next-hop determination 1095 Next-hop determination is performed as in Section 5.2 of [RFC4861] 1096 with the following exceptions. Global and Local prefix are assumed 1097 to be off-link as the LoWPAN subnet with that prefix may be much 1098 larger than the link in route over topologies, unless the destination 1099 address exists in the neighbor cache. Link-layer information should 1100 be used to maintain the neighbor cahce whenever possible rather than 1101 using ND traffic. The ERs and Routers used for registration are kept 1102 in the Default Router List. Multicast addresses resolve to a 1103 broadcast as specified in [RFC4944]. 1105 6.4. Address lookup 1107 A LoWPAN node does not use multicast for its Neighbor Solicitation as 1108 prescribed by the ND protocol [RFC4861] and oDAD [RFC4429]. When 1109 lookup is necessary, all NS messages are sent in unicast to the Edge 1110 Router, that answers in unicast as well. The message is a standard 1111 Neighbor Solicitation but for the destination is set to the Edge 1112 Router address or the well known 6LOWPAN_ER anycast address as 1113 opposed to the solicited-node multicast address for the destination 1114 address. A LoWPAN Node SHOULD retain a small queue for packets to 1115 neighbors awaiting to be delivered while address lookup is being 1116 performed. The size of the queue should be suitable to the available 1117 RAM of the node, and is not required to be a minimum of one buffer 1118 per neighbor as in [RFC4861]. 1120 The Target link-layer address in the response is either that of the 1121 destination if a short cut is possible over the LoWPAN, or that of 1122 the Edge Router if the destination is reachable over the Transit 1123 Link, in which case the Edge Router will terminate 6LoWPAN and relay 1124 the packet. 1126 A LoWPAN Node does not need to join the solicited-node multicast 1127 address for its own addresses and SHOULD NOT have to answer a 1128 multicast Neighbor Solicitation. It MAY be configured to answer a 1129 unicast NS but that is not required by this specification. 1131 Care must be used with the 6LOWPAN_ER and other anycast addresses, as 1132 anycast resolution is normally performed with a multicast NS/NA 1133 exchange. As nodes are not required to answer NS messages, the next 1134 hop determination process SHOULD map the anycast address to the link 1135 layer address of a neighbor using available L2 or other ND 1136 information. 1138 7. LoWPAN Router Specification 1140 LoWPAN Routers are used in a route-over configuration where the 1141 network is composed of overlapping link-local scopes. As a result, 1142 we must extend ND as specified in [RFC4861] to operate over an entire 1143 subnet, specifically the subnet controlled by Edge Routers, rather 1144 than a single IP link. 1146 Network configuration parameters carried in Router Advertisements 1147 originate at Edge Routers and must disseminate to all Routers and 1148 Hosts within the LoWPAN. The Multihop Information option is used to 1149 support information dissemination from one or more Edge Routers to 1150 all other nodes in the LoWPAN. The option includes a "V" flag that 1151 indicates that the information contained in the Router Advertisement 1152 is valid. The option also includes a sequence number to ensure that 1153 all nodes converge on the same settings. 1155 Because Router Registration/Confirmation exchanges only occur over 1156 link-local scope, such messages must be relayed between Hosts and 1157 Edge Routers when separated by multiple IP hops. Every LoWPAN Router 1158 MUST also serve as a Relay to ensure that any neighboring node can 1159 successfully participate in the LoWPAN. 1161 7.1. Router Configuration Variables 1163 A router MUST allow the following conceptual variables to be 1164 configured by system management. The specific variable names are 1165 used for demonstration purposes only, and an implementation is not 1166 required to have them, so long as its external behavior is consistent 1167 with that described in this document. The meaning of these variables 1168 are as defined in Section 6.2.1 of [RFC4861]. Default values are 1169 specified to simplify configuration in common cases. 1171 - IsRouter 1172 - MaxRtrAdvInterval 1174 - MinRtrAdvInterval 1176 - AdvDefaultLifetime 1178 A router MUST allow the following conceptual variables to be 1179 configured by information received in Router Advertisement messages. 1180 The specific variable names are used for demonstration purposes only, 1181 and an implementation is not required to have them, so long as its 1182 external behavior is consistent with that described in this document. 1183 The meaning of these variables are as defined in Section 6.2.1 of 1184 [RFC4861]. However, default values are not relevant as a router 1185 should not be advertising such values until they have been received 1186 from other neighboring routers. 1188 - AdvManagedFlag 1190 - AdvOtherConfigFlag 1192 - AdvReachableTime 1194 - AdvRetransTimer 1196 - AdvCurHopLimit 1198 - AdvPrefixList 1200 7.2. Becoming an Advertising Interface 1202 An interface may become an advertising interace as specified in 1203 Section 6.2.2 of [RFC4861]. 1205 A LoWPAN Router's interface MAY become an advertising interface 1206 before all of its router variables have been initializes. The router 1207 MUST learn these variables (e.g. AdvCurHopLimit, AdvReachableTime, 1208 prefix information, etc.) from neighboring routers. While the 1209 variables are not initialized, the router MAY send Router 1210 Advertisement with the "Solicit" flag set to solicit Router 1211 Advertisements from neighboring routers. However, the router MUST 1212 set the Router Lifetime field to zero while one or more of its 1213 variables are uninitialized. 1215 7.3. Router Advertisement Message Content 1217 A router sends periodic as well as solicited Router Advertisements 1218 out its advertising interface. Outgoing Router Advertisements are 1219 filled with the following values constistent with the message format 1220 given in this document. 1222 - In the Router Lifetime field: if the router has a default route, 1223 the interface's configured AdvDefaultLifetime. If the router does 1224 not have a default route, zero. 1226 - In the M and O flags: the current value of AdvManagedFlag and 1227 AdvOtherConfigFlag, respectively. 1229 - The E flag is not set. 1231 - In the Cur Hop Limit field: the current value of CurHopLimit. 1233 - In the Reachable Time field: the current value of 1234 AdvReachableTime. 1236 - In the Retrans Timer field: the current value of 1237 AdvRetransTimer. 1239 - In the options: 1241 - Multihop Information option: to indicate if the information 1242 contained in the Router Advertisement is valid and, if so, the 1243 freshness of the information contained in the Router 1244 Advertisement message. The option fields are set as follows: 1246 - In the "valid" flag: the current value of 1247 AdvInformationValid. 1249 - In the Sequence Number field: the current value of 1250 AdvInformationSequence. 1252 - 6LoWPAN Prefix Information options: one 6LoWPAN Prefix 1253 Information option for each prefix listed in AdvPrefixList with 1254 the option fields set from the information in the AdvPrefxList 1255 entry as follows: 1257 - In the "on-link" flag: the entry's AdvOnLinkFlag. 1259 - In the "Autonomous address configuration" flag: the 1260 entry's AdvAutonomousFlag. 1262 - In the Valid Lifetime field: the entry's AdvValidLifetime. 1264 7.4. Sending Unsolicited Router Advertisements 1266 As specified in Section 6.2.4 of [RFC4861]. 1268 7.5. Ceasing To Be an Advertising Interface 1270 As specified in Section 6.2.5 of [RFC4861]. 1272 7.6. Processing Router Solicitations 1274 As specified in Section 6.2.6 of [RFC4861]. 1276 7.7. Router Advertisement Consistency 1278 TBD 1280 7.8. Relaying a Router Registration Message 1282 When a router receives a Router Registration message from a LoWPAN 1283 Node, it sets the Code to 1 indicating that the message has been 1284 relayed. The IPv6 source address is set to that of the router. 1286 By default, the router relays Router Registration messages to the 1287 6LOWPAN_ER anycast address. However, the router MAY be configured to 1288 use a list of destination addresses, which MAY include unicast 1289 addresses, the 6LOWPAN_ER anycast address, or other addresses 1290 selected by the network administrator. If the RR includes a Target 1291 link-layer address option, then that SHOULD be used to form the 1292 desination address as it indicates the ER which the LoWPAN node wants 1293 to prefer. 1295 7.9. Relaying a Router Confirmation Message 1297 When the router receives a Relay Router Confirmation message from an 1298 Edge Router, the Code field is set to 1. The Host Interface 1299 Identifier is used to form the IPv6 Destination Address for the 1300 Router Confirmation message. If a Target link-layer address option 1301 is included in the message, then that is used to form the IPv6 1302 destination address instead of the Host Interface Identifier. The 1303 IPv6 source address is set to that of the Router. The Hop Limit of 1304 the Router Confirmation message is set to 255. 1306 8. LoWPAN Edge Router Specification 1308 Edge Routers are introduced to scale the Neighbor Discovery 1309 Operations by reducing the amount of costly multicast ND messages 1310 over a subnet that may cover hundreds or thousands of nodes. 1312 Instead of multicasting ND messages, a LoWPAN Node performs unicast 1313 exchanges to its Edge Router to claim and lookup addresses using 1314 unicast and anycast addresses, and the Edge Router proxies the ND 1315 requests over the Backbone Link when necessary. 1317 This specification documents the extensions to IPv6 Neighbor 1318 Discovery that enables a LoWPAN Node to claim and lookup addresses 1319 using a Edge Router as an intermediate proxy. The draft also 1320 documents the use of EUI-64 based link-local addresses and the way 1321 they are claimed by the Edge Routers over the Backbone link. 1323 For the purpose of Neighbor Discovery proxying, this specification 1324 documents the LoWPAN registration table, a conceptual data structure 1325 that is similar to the MIPv6 binding cache. 1327 Another function of the Edge Router is to perform 6LoWPAN compression 1328 and uncompression between the LoWPAN and the Backbone Link and ensure 1329 MTU compatibility. Packets flow uncompressed over the Backbone Link 1330 and are routed normally towards a Gateway or an Application sitting 1331 on the Backbone link or on a different link that is reachable via IP. 1333 8.1. Registration process 1335 Upon a new registration for a link-local address based on an IEEE 64- 1336 bit extended MAC address, the Edge Router MAY use Optimistic DAD on 1337 the Transit Link. A positive acknowledgement can be sent to the 1338 6LoWPAN node right away if oDAD is used on the Transit Link. 1340 A LoWPAN Node should be able to join a different Edge Router at any 1341 time without the complexities of terminating a current registration 1342 and renumber. To enable this, the ND proxy operation upon a Router 1343 Registration/Confirmation flow wins the address ownership over a ND 1344 proxy operation that is done asynchronously, on behalf of the same 1345 LoWPAN Node, upon a prior registration. So an Edge Router that would 1346 happen to have a binding for that same address for the same LoWPAN 1347 Node identified by its EUI-64 address will yield and deprecate its 1348 binding. 1350 The new Host Interface Identifier Option in NS/NA messages that 1351 carries the node EUI-64 address enables to differentiate an address 1352 collision from a movement of a node from one Edge Router to the next. 1353 Upon a registration flow, a node doing DAD SHOULD ignore NA without 1354 the the override (O) bit, and set the override (O) bit in its own NA 1355 messages. Asynchronously to the registration, a node SHOULD NOT set 1356 the override (O) bit in its NA messages and should yield to an NA 1357 message with the override (O) bit set. 1359 So the Edge Router operation on the transit link is similar to that 1360 of a Home Agent as specified in "Mobility Support for IPv6" [RFC3775] 1361 yet different. In particular, the Neighbor Advertisement message is 1362 used as specified in section "10.4.1. Intercepting Packets for a 1363 Mobile Node" with the exception that the override (O) bit is not set, 1364 indicating that this Edge Router acts as a proxy for the LoWPAN and 1365 will yield should another Edge Router claim that address on the 1366 Backbone Link. 1368 This specification also introduces the concept of secondary binding. 1369 Upon a secondary binding, the Edge Router will not announce or defend 1370 the address on the backbone link, but will be able to forward packets 1371 to the node over its LoWPAN interface. 1373 The Edge Router responds to a Router Registration with a Router 1374 Confirmation. The source address is a link local address of the 1375 router and the destination is the optimistic address of the node from 1376 which the RR was received. The ER responds to relayed RR messages 1377 with an RC message, where the destination address is the address of 1378 the Router which sent the relayed RR message. 1380 If the Edge Router is primary for a registration as indicated by the 1381 'P' flag in the Identity Request Option and it is connected to a 1382 Backbone, then it SHOULD perform proxy ND operations on the backbone 1383 and indicate so in the Router Confirmation message using the 'X' flag 1384 of the Identity Reply Option. In particular the Egde Router SHOULD 1385 reject the registration if DAD fails on the backbone. When oDAD is 1386 used over the backbone the Edge Router MAY issue the Router 1387 Confirmation right away with a positive code, but if a collision is 1388 finally detected, it cancels the registration with an asynchronous 1389 Router Confirmation and a negative completion code on the same TID. 1391 If the RR message includes an Address Option with the 'A' flag set, 1392 this indicated the request of a stateless address assignment. If the 1393 ER supports managed address mode ('M' flag set in its RAs), then the 1394 ER aquires an appropriate, unique link-layer address for the network 1395 either by generating it and performing DAD, or with some other 1396 method. If successful, this address is returned in an Address Option 1397 of the RC with the 'A' flag set and the assigned IPv6 address formed 1398 from the assigned link-layer address and the defualt prefix inline. 1400 8.2. Exposing the Edge Router 1402 The Backbone link is used as reference for Neighbor Discovery 1403 operations. When an Edge Router does not have an entry in its 1404 registration table for a target node, it looks it up over the 1405 backbone using ND operation in place for that medium. Edge Routers 1406 also perform ND proxying for the LoWPAN Nodes that are proactively 1407 registered to them. That way, a lookup over the backbone is not 1408 propagated over the LoWPANs, but answered by the proxy that has the 1409 registration for the target, if any. 1411 To enable proxying over the backbone Link, an Edge Router must join 1412 the solicited-node multicast address on that link for all the 1413 registered addresses of the nodes in its LoWPANs. The Edge Router 1414 answers the Neighbor Solicitation with a Neighbor Advertisement that 1415 indicates its own link-layer address in the Target link-layer address 1416 option. 1418 An Edge Router expects and answers unicast Neighbor Solicitations for 1419 all nodes in its LoWPANs. It answers as a proxy for the real target. 1420 The target link-layer address in the response is either that of the 1421 destination if a short cut is possible over the LoWPAN, or that of 1422 the Backbone Router if the destination is reachable over the Transit 1423 Link, in which case the Backbone Router will terminate 6LoWPAN and 1424 relay the packet. 1426 The Edge Router forms a link-local address in exactly the same way as 1427 any other node on the LoWPAN. It uses the same link local address 1428 for the Backbone Link and for all the associated LoWPAN(s) connected 1429 to that Edge Router. 1431 The Edge Router configures the well known 6LOWPAN_ER anycast address 1432 on the LoWPAN interfaces where it serves as Edge Router. Note that 1433 the Edge Router will accept registration packets with a hop limit 1434 that is lower than 255 on that specific address. 1436 The Edge Router announces itself using Router Advertisement (RA) 1437 messages that are broadcasted periodically over the LOWPAN and the 1438 backbone link. 1440 A new (E) bit in the RA indicates the Edge Router capability. The 1441 Edge Router MAY also announce any prefix that is configured on the 1442 transit link, and serve as the default gateway for any node on the 1443 Transit Link or on the attached LoWPANs. 1445 The transit link Maximum Transmission Unit serves as base for Path 1446 MTU discovery and Transport layer Maximum Segment Size negotiation 1447 (see section 8.3 of [RFC2460]) for all nodes in the LoWPANs. To 1448 achieve this, the Edge Router announces the MTU of the transit link 1449 over the LoWPAN using the MTU option in the RA message as prescribed 1450 in section "4.6.4. MTU" of IPv6 Neighbor Discovery [RFC4861]. 1452 LoWPAN Nodes SHOULD form IPv6 packets that are smaller than that MTU. 1453 As a result, those packets should not require any fragmentation over 1454 the transit link though they might be intranet-fragmented over the 1455 LoWPAN itself as prescribed by [RFC4944]). 1457 More information on the MTU issue with regard to ND-proxying can be 1458 found in Neighbor Discovery Proxies [RFC4389] and 1459 [I-D.van-beijnum-multi-mtu]. 1461 8.3. Forwarding packets 1463 Upon receiving packets on one of its LoWPAN interfaces, the Edge 1464 Router checks whether it has a binding for the source address. If it 1465 does, then the Edge Router can forward the packet to another LoWPAN 1466 Node or over the Backbone link. Otherwise, the Edge Router MUST 1467 discard the packet. If the packet is to be transmitted over the 1468 Transit link, then the 6LoWPAN sublayer is terminated and the full 1469 IPv6 packet is reassembled and expanded. 1471 When forwarding a packet from the Backbone Link towards a LoWPAN 1472 interface, the Edge Router performs the 6LoWPAN sublayer operations 1473 of compression and fragmentation and passes the packet to the lower 1474 layer for transmission. 1476 8.4. Fault tolerance 1478 To be completed in the next revision. 1480 9. Ad-hoc LoWPAN Operation 1482 To be completed in the next revision. 1484 10. Message Examples 1486 This section provides examples of creating and processing messages 1487 and options from this document along with example messages. 1489 To be completed in the next revision. 1491 11. Security Considerations 1493 This specification expects that the link layer is sufficiently 1494 protected, either by means of physical or IP security for the 1495 backbone link or MAC sublayer cryptography. In particular, it is 1496 expected that the LoWPAN MAC provides secure unicast to/from Routers 1497 and secure broadcast from the Routers in a way that prevents 1498 tempering with or replaying the RA messages. However, any future 1499 6LoWPAN security protocol that applies to Neighbor Discovery for 1500 6LoWPAN protocol, is out of scope of this document. 1502 12. IANA Considerations 1504 This document requires two new ICMPv6 message types: 1506 Router Registration (TBD1) 1508 Router Confirmation (TBD2) 1510 The document also requires four new ND option types under the 1511 subregistry "IPv6 Neighbor Discovery Option Formats": 1513 Address Option (TBD3) 1515 6LoWPAN Prefix Information Option (TBD4) 1517 Multihop Information Option (TBD5) 1519 Host Interface Identifier Option (TBD6) 1521 A new flag is required for the IPv6 ND Router Advertisement called 1522 the "E - Edge Router Flag". There is also the need for a new link 1523 local anycast address, 6LOWPAN_ER for 6LoWPAN Edge Routers and 1524 Routers; used as a functional address. 1526 [TO BE REMOVED: This registration should take place at the following 1527 location: http://www.iana.org/assignments/icmpv6-parameters] 1529 13. Acknowledgments 1531 The authors thank Carsten Bormann, Geoff Mulligan and Julien Abeille 1532 for useful discussions and comments that have helped shaped and 1533 improve this document. 1535 14. References 1537 14.1. Normative References 1539 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1540 Requirement Levels", BCP 14, RFC 2119, March 1997. 1542 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1543 (IPv6) Specification", RFC 2460, December 1998. 1545 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1546 in IPv6", RFC 3775, June 2004. 1548 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 1549 for IPv6", RFC 4429, April 2006. 1551 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1552 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1553 September 2007. 1555 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1556 Address Autoconfiguration", RFC 4862, September 2007. 1558 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1559 "Transmission of IPv6 Packets over IEEE 802.15.4 1560 Networks", RFC 4944, September 2007. 1562 [RFC5175] Haberman, B. and R. Hinden, "IPv6 Router Advertisement 1563 Flags Option", RFC 5175, March 2008. 1565 14.2. Informative References 1567 [I-D.van-beijnum-multi-mtu] 1568 Beijnum, I., "Extensions for Multi-MTU Subnets", 1569 draft-van-beijnum-multi-mtu-02 (work in progress), 1570 February 2008. 1572 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 1573 Proxies (ND Proxy)", RFC 4389, April 2006. 1575 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 1576 over Low-Power Wireless Personal Area Networks (6LoWPANs): 1577 Overview, Assumptions, Problem Statement, and Goals", 1578 RFC 4919, August 2007. 1580 Authors' Addresses 1582 Zach Shelby (editor) 1583 Sensinode 1584 Kidekuja 2 1585 Vuokatti 88600 1586 FINLAND 1588 Phone: +358407796297 1589 Email: zach@sensinode.com 1590 Pascal Thubert 1591 Cisco Systems 1592 Village d'Entreprises Green Side 1593 400, Avenue de Roumanille 1594 Batiment T3 1595 Biot - Sophia Antipolis 06410 1596 FRANCE 1598 Phone: +33 4 97 23 26 34 1599 Email: pthubert@cisco.com 1601 Jonathan W. Hui 1602 Arch Rock Corporation 1603 501 2nd St. Ste. 410 1604 San Francisco, California 94107 1605 USA 1607 Phone: +415 692 0828 1608 Email: jhui@archrock.com 1610 Samita Chakrabarti 1611 IP Infusion 1612 1188 Arquest Street 1613 Sunnyvale, California 1614 USA 1616 Phone: 1617 Email: samitac@ipinfusion.com 1619 Erik Nordmark 1620 Sun Microsystems, Inc. 1621 17 Network Circle 1622 Menlo Park, California 94025 1623 USA 1625 Phone: 1626 Email: Erik.Nordmark@Sun.COM 1628 Full Copyright Statement 1630 Copyright (C) The IETF Trust (2008). 1632 This document is subject to the rights, licenses and restrictions 1633 contained in BCP 78, and except as set forth therein, the authors 1634 retain all their rights. 1636 This document and the information contained herein are provided on an 1637 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1638 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1639 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1640 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1641 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1642 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1644 Intellectual Property 1646 The IETF takes no position regarding the validity or scope of any 1647 Intellectual Property Rights or other rights that might be claimed to 1648 pertain to the implementation or use of the technology described in 1649 this document or the extent to which any license under such rights 1650 might or might not be available; nor does it represent that it has 1651 made any independent effort to identify any such rights. Information 1652 on the procedures with respect to rights in RFC documents can be 1653 found in BCP 78 and BCP 79. 1655 Copies of IPR disclosures made to the IETF Secretariat and any 1656 assurances of licenses to be made available, or the result of an 1657 attempt made to obtain a general license or permission for the use of 1658 such proprietary rights by implementers or users of this 1659 specification can be obtained from the IETF on-line IPR repository at 1660 http://www.ietf.org/ipr. 1662 The IETF invites any interested party to bring to its attention any 1663 copyrights, patents or patent applications, or other proprietary 1664 rights that may cover technology that may be required to implement 1665 this standard. Please address the information to the IETF at 1666 ietf-ipr@ietf.org. 1668 Acknowledgment 1670 Funding for the RFC Editor function is provided by the IETF 1671 Administrative Support Activity (IASA).